Re: USB mini-summit at LinuxCon Vancouver

[Mauro Carvalho Chehab <mchehab@infradead.org>]

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