Re: [Workshop-2011] Media Subsystem Workshop 2011

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

I've addec Hans de Geode and linux-usb to the CC as this response picks up on 
a related discussion about the usb mini summit.

On Friday 05 August 2011, Theodore Kilgore wrote:
> > If you can solve the locking problem between devices in the kernel then
> > it  shouldn't matter if one of the kernel devices is the generic device
> > that is used to support libusb.
> 
> Hmmm. Perhaps not. While we are on the topic, what exactly do you mean by 
> "the generic device that is used to support libusb." Which device is that, 
> exactly?

The file drivers/usb/core/devio.c registers itself as a driver called 
usb_device which is used to provide all of the device drivers that live under 
/proc/bus/usb

If you look in there for the code to handle the ioctl() USBDEVFS_DISCONNECT 
then you will find the code that is called when you make a 
usb_detach_kernel_driver_np() call through libusb. That code, according to the 
documentation and my testing needs to acquire a lock before it calls 
usb_driver_release_interface(). Based on my testing to date (using cheese to 
start a camera streaming and then gphoto2 -L to trigger the disconnect ioctl) 
I would suggest that the fact it doesn't is a kernel bug that needs fixing 
regardless of whether there is any user space solution to camera mode 
switching because that code could potentially get called on any in use USB 
device and if it does even thing like lsusb don't work correctly afterwards 
and completely unrelated devices don't work if they are later plugged into the 
same USB port.

With regard to userspace then stealing the device, 

Hans de Geode wrote
> Getting a bit offtopic here, but no a try_disconnect will fix the
> userspace stillcam mode driver being able to disconnect the device
> while the webcam function is active. If the webcam is not active
> userspace will still "win", and possibly never return the device
> back to the kernel driver (this already happens today with
> gvfs-gphoto creating a fuse mount and keeping the device open
> indefinitely, locking out the webcam function

With the current design gvfs-photo doesn't even need to keep the device open. 
The kernel provides an ioctl (USBDEVFS_CONNECT) that needs to be called before 
the kernel mode driver can use the interface again but libusb 0.1 doesn't 
expose it. Even if you use gphoto2 rather than gvfs that will cleanly close 
all the devices it used when it has finished with them it doesn't release the 
device back to the kernel but that is a failure of user space to call the 
provided API. I did once hack libgphoto to call USBDEVFS_CONNECT and it does 
then hand the device back correctly but it was a messy hack as it needed 
knowledge of the internals of libusb.

Regards

Adam