Re: USB mini-summit at LinuxCon Vancouver
From: Theodore Kilgore
Date: Thu Aug 11 2011 - 19:09:21 EST
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
> 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.
Try it out with one camera seems to me to be a reasonable way
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/