Re: USB mini-summit at LinuxCon Vancouver

From: Adam Baker
Date: Tue Aug 09 2011 - 16:38:21 EST

On Tuesday 09 August 2011, Hans de Goede wrote:
> Hi,
> On 08/09/2011 04:19 PM, Alan Stern wrote:

> > Does it really make sense to combine 5 drivers into one?
> Right, that is not the plan. The plan is to simply stop having 2 drivers
> for 1 logical (and physical) block. So we go from 10 drivers, 5 stillcam
> + 5 webcam, to just 5 drivers. We will also likely be able to share
> code between the code for the 2 functionalities for things like generic
> set / get register functions, initialization, etc.

Unfortunately as Theodore recently pointed out you don't go from 10 to 5, you
go from 10 to 10 where 5 of the new 10 are only used on Win32, FreeBSD and OSX
(but they aren't any simpler because they still rely on libusb) and the other
5 that are only used on Linux become significantly more complicated than they
currently are.

It has also just occured to me that it might be possible to solve the issues
we are facing just in the kernel. At the moment when the kernel performs a
USBDEVFS_DISCONNECT it keeps the kernel driver locked out until userspace
performs a USBDEVFS_CONNECT. If the kernel reattached the kernel driver when
the device file was closed then, as gvfs doesn't keep the file open the
biggest current issue would be solved instantly. If a mechanism could be found
to prevent USBDEVFS_DISCONNECT from succeeding when the corresponding
/dev/videox file was open then that would seem to be a reasonable solution.

Hans had expressed the opinion that merely having the device open to control
the camera not to stream shouldn't prevent stillcam operation - I disagree
because if you are setting up the controls you are probably already streaming
so you can see what you are doing and if not you are probably about to.

Of course changing the behaviour of USBDEVFS_DISCONNECT is not something to be
done lightly. I don't know how many other users there are for it and if the
current behaviour is actually correct for any of them. Cleaning up on file
close does have the useful side effect though that applications no longer need
to worry about the fact that even if they clean up properly on a normal exit,
if they crash they leave the kernel driver permanently disabled


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at