Re: [Workshop-2011] Media Subsystem Workshop 2011

[Adam Baker <linux@baker-net.org.uk>]

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