On Thu, 11 Aug 2011, Alan Stern wrote: > On Thu, 11 Aug 2011, Alan Cox wrote: > > > Actually there are more issues than that - you've also got to worry about > > a security/permission model, and that is hard to get right, especially if > > you are not very careful that anything that can be retrieved which might > > violate the security model (eg the last frame on the capture) has been > > blanked before handover etc. > > As far as I can tell, these same security issues exist today. I don't > see them getting any worse than they are now. > > > And applications that are touching both video (even indirectly) and still > > camera may get surprise deadlocks if they accidentally reference both the > > still and video device even via some library or service. > > No, not deadlocks. Just -EBUSY errors. > > > > > Well, a user program can assume that the kernel driver left the device > > > > in a clean state. The reverse isn't always true, however -- it's one > > > > Not it cannot - the user program doesn't know > > > > a) if the kernel driver has ever been loaded > > b) the values the kernel driver leaves set (and those will change no > > doubt at times) > > c) if the camera has been plugged and unplugged and not yet had the > > kernel driver loaded > > That's true. The program can't assume that a kernel driver was ever > bound to the device; all it can assume is that _if_ a kernel driver was > bound then it left the device in a sane state -- whatever "sane" might > mean in this context. > > > To me it sounds like a recipe for disaster. For those tiny number of > > devices involved just use V4L and if need be some small V4L tweaks to > > handle still mode. In most cases the interface is basically identical and > > I'd bet much of the code is identical too. > > I'm not against moving the whole thing into the kernel. I'm just > pointing out that an easier-to-code-up solution will accomplish much > the same result. > > Alan Stern > Alan, 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. 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