On Thu, 2010-09-16 at 16:44 +0200, Laurent Pinchart wrote: > > I'm aware that this is a really ugly hack right now, but maybe it > > provides a starting point for those of you with more insight into how > > the driver works. I'd be glad for some hints as to how to proceed! > The patch looks good to me, except of course that it's a hack :-) Good to hear :-)
> The real question we need to answer is how to expose the still image capture > function to userspace. Should a new video node be created for still image > capture ? The new video node could be linked to the existing one using the > media controller API. Or should we use multiple open on a single video node ? > In that case, how would we select video/still image capture ? Good point - I'd say that a second device node, e.g. /dev/stillX would be the best solution. Otherwise, you'd have to rewrite every piece of video software to include the new ioctl (or something like that). With a separate dev node, it _should_ "just work" (TM).... BTW, if the new node would be just a link, how would the driver know about it? > I'm really open to suggestions here. We also need to remember that capturing > a > still image with method 2 (unlike method 3) will stop the live video stream > for a brief time. Is that acceptable ? I think so, it's acceptable that one video camera can only be used by one application at a time (which would otherwise probably trigger all kinds of interference anyway). Florian _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
