On Thu, 11 Aug 2011, Mauro Carvalho Chehab wrote: > Em 11-08-2011 17:01, Theodore Kilgore escreveu: > > > As I said, I am agnostic, though leaning in the direction that Hans de > > Goede is pointing. What he says about a single control mechanism seems to > > make a lot of sense. If you can come up with an outline of the "easier to > > code" solution, that would be interesting, though. > > > > I assume you are also going to be in Vancouver? If you will be there on > > Monday, then Hans and I are already planning to meet and discuss. > > > > BTW, as to using V4L with "tweaks" to handle still mode, it would probably > > be more difficult than is imagined. For, though the operations required to > > process still images and webcam frames are in principle similar, the > > priorities and constraints are too different. Therefore, my understanding > > is that the libgphoto2 image processing routines, not the libv4l image > > processing routines, would still be used for still images. > > I agree with Alan Cox: most of the code that the driver needs is already there: > register read/write routines, bulk transfer support, etc. The amount of extra > code for adding still cam functionality is probably not big. > > >From the kernel driver's perspective, it doesn't matter if the access will come > via libv4l, libgphoto2 or whatever. The driver should be able to allow simultaneous > open, while protecting the data access when userspace requests data stream or > still image retrieve. > > instead of using the V4L2 device node to access the stored images, it probably makes > more sense to use a separate device for that, that will handle a separate set of > ioctl's, and just use read() to retrieve the image data, after selecting the desired > image number, via ioctl(). > > It probably makes sense to add a new set of callbacks at the gspca core in order > to handle the new device node, and letting it to avoid start streaming while the > store access is happening, and vice-versa. Alternatively, we may create a separate > "still cam" core library to handle the new device node,. > > If all agree around such solution, I suggest to take the most complex case and try > to map it into the driver and core, and see how it behaves, testing with some simple > command line applications, only changing the libgphoto2 code after those initial > tests. Writing a simple code for reading still images should be easy, and we have > already some testing tools for V4L2. > > After coding the core changes that are common to all drives, I suspect that adding > the remaining 4 drivers will be quick. > > With regards to libgphoto2, all it needs to do is to test if the new device nodes > exist. If they exist, then the new code will be used. Otherwise, it will fallback > to the libusb. This way, we can incrementally add the Dual mode drivers into the > kernel. > > There is one advantage on using this strategy: if, in the future, new Dual Cams > arise, one can write first a still cam kernel driver, adding V4L support later. > > Cheers, > Mauro > Try it out with one camera seems to me to be a reasonable way forward. Theodore Kilgore -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
