On Tuesday 09 August 2011, Hans de Goede wrote: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.
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
1) You are wrong wrt gvfs, it does keep the libgphoto2 context open all the
time, and through that the usbfs device nodes.
It seems that that depends, on my system gvfs isn't actually automounting the
camera after it detects it and the file is only open (according to lsof) when
the device is actually mounted.
As soon as you unmount it the device gets
closed again. Because it does do a brief open, USBDEVFS_DISCONNECT then close
at connection time it does still disable the kernel driver.
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).
This does seem like a situation where your approach could potentially give a
better user experience. I'm wondering slightly how you define busy though. For
webcams the streamon and streamoff ioctls tell you if you are using mmap or
userptr transfers but you don't know if when the user has finished if they
just use read. For stillcam mode it is again hard to determine a busy
condition other than being in the middle of transfering an individual picture.
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
This again needs a usable concept of busy
If we come up with a solution that whilst it would be
perfect there isn't enough effort available to implement then that is worse
than a solution that fixes most of the problem.
This is an even greater
concern when the technically superior solution has a higher long term
maintenance overhead (as we no longer get Win32 and OSX users helping to
maintain the stillcam drivers).