On Monday 08 August 2011, Mauro Carvalho Chehab wrote: > > I will send a second reply to this message, which deals in particular > > with the list of abilities you outlined above. The point is, the > > situation as to that list of abilities is more chaotic than is generally > > realized. And when people are laying plans they really need to be aware > > of that. > > From what I understood from your proposal, "/dev/camX" would be providing a > libusb-like interface, right? > > If so, then, I'd say that we should just use the current libusb > infrastructure. All we need is a way to lock libusb access when another > driver is using the same USB interface. > I think adding the required features to libusb is in general the correct approach however some locking may be needed in the kernel regardless to ensure a badly behaved libusb or libusb user can't corrupt kernel state. > Hans and Adam's proposal is to actually create a "/dev/camX" node that will > give fs-like access to the pictures. As the data access to the cameras > generally use PTP (or a PTP-like protocol), probably one driver will > handle several different types of cameras, so, we'll end by having one > different driver for PTP than the V4L driver. I'm not advocating this approach, my post was intended as a "straw man" to allow the advantages and disadvantages of such an approach to be considered by all concerned. I suspected it would be excessively complex but I don't know enough about the various cameras to be certain. Adam -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
