Re: USB mini-summit at LinuxCon Vancouver

[Theodore Kilgore <kilgota@banach.math.auburn.edu>]

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