Re: USB mini-summit at LinuxCon Vancouver

[Hans de Goede]

Hi,

On 08/09/2011 10:31 PM, Adam Baker wrote:
> On Tuesday 09 August 2011, Hans de Goede wrote:

<snip>

> 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.

<sigh>

This has been discussed over and over and over again, playing clever
tricks with USBDEVFS_[DIS]CONNECT like adding a new USBDEVFS_TRYDISCONNECT
which the v4l2 driver could intercept won't cut it. We need some central
manager of the device doing multiplexing between the 2 functions, and you
can *not* assume that either side will be nice wrt closing file descriptors.

Examples:
1) You are wrong wrt gvfs, it does keep the libgphoto2 context open all the
time, and through that the usbfs device nodes.

2) Lets say a user starts a photo managing app like f-spot, and that opens
the device through libgphoto2 on startup, then the user switches to another
virtual desktop and forgets all about having f-spot open. Notice that if
the user now tries to stream he will not get a busy error, but the app trying
to do the streaming will simply not see the camera at all (kernel driver
unbound /dev/video# node is gone).

3) Notice that little speaker icon in your panel on your average Linux
desktop, that keeps the mixer of the audio device open *all the time* it
is quite easy to imagine a similar applet for v4l2 device controls (see
for example gtk-v4l) doing the same. Or a user could simply start up a
v4l2 control panel app like gtk-v4l, qv4l2 or v4l2ucp, and leave it running
minimized ...

4) Some laptops have a Fn + F## key which enables / disables the builtin
webcam by turning its power on / off. Effectively plugging it into / out
of a usb port. We would like to have an on screen notification of this one
day like we have now for brightness and volume controls, based on udev
events. But the current dual mode cam stuff causes udev events for
a *new* video device being added / an existing one being removed
each time libgphoto2 releases / takes control of the camera.

5) More in general, more and more software is dynamically monitoring the
addition / removal of (usb) devices using udev, our current solution
suggests to this software the /dev/video device is being unplugged /
re-plugged all the time, not pretty.


All in all what we've today is a kludge, and if we want to provide
a "seamless" user experience we need to fix it.

Don't get me wrong usbfs is a really nice solution for driving
usb devices from userspace, like scanners and all other sorts of
devices. But what all these devices have in common is that they
have no kernel driver. Having a userspace based driver and a kernel
driver "fight it out" just does not work well.

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/