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