Re: [Libusb-devel] Improving kernel -> userspace (usbfs) usb device hand off

[Michael Bender <Michael.Bender@oracle.com>]

On Jun 12, 2011, at 7:03 PM, Xiaofan Chen wrote:

> On Mon, Jun 13, 2011 at 5:20 AM, Theodore Kilgore
> <kilgota@banach.math.auburn.edu> wrote:
>> On Sun, 12 Jun 2011, Hans de Goede wrote:
>>> Actually libusb and libgphoto have been using the rebind orginal  
>>> driver
>>> functionality of the code for quite a while now,
>>
>> Oh? I can see that libusb is doing that, and I can also see that  
>> there is
>> a "public" function for _unbinding_ a kernel driver, namely
>>
>> int usb_detach_kernel_driver_np()
>>
>> found in usb.h
>>
>> and it is used in libgphoto, as well.
>>
>> I am not sure that there is any corresponding rebind function which  
>> is
>> public. Is it perhaps
>>
>> int usb_get_driver_np()
>>
>> ???
>>
>> By context (looking at libgphoto2-port/usb/libusb.c) I would think  
>> that
>> this function is not the rebind function, but is only checking  
>> whether or
>> not there is any potential conflict with a kernel driver. If I am  
>> right,
>> then where is the publicly exported rebind function, and where does  
>> it
>> currently get used in libgphoto2?
>
> http://gphoto.svn.sourceforge.net/viewvc/gphoto/trunk/libgphoto2/libgphoto2_port/usb/libusb.c?revision=13652&view=markup
>
> The rebind happened under the function "static int gp_port_usb_close
> (GPPort *port)".
> Since libgphoto2 is still using libusb-0.1, the unbind is using  
> usbfs IOCTL
> directly (USBDEVFS_CONNECT).
>
>> So frankly after my eagerness yesterday I do not see how it can  
>> easily be
>> made to work, after all.
>>
>>> unfortunately this
>>> does not solve the problem, unless we somehow move to 1 central
>>> coordinator for the device the user experience will stay subpar.
>
> Now I understand what Hans is saying. It will be a lot of work trying
> to sort out this issue in userspace. What can be the single central
> coordinator? A device manager applet listing the program or service
> which hold the device?

Something like that. Have a user-space device allocation mechanism so
that apps are not constrained by a particular interface semantic (i.e.  
not
required to open /dev/video and have a kernel driver deliver pixels to  
the
apps).

Or hid that behind a library API and let instances of the library  
coordinate
with each other; as long as an app uses the documented public library  
API
to access a webcam, then everyone will play fair with each other.

Look at the mess that this userspace/kernel driver issue has for code in
an application like gphoto - that's insane that a photo manipulation app
needs to know anything about userspace/kernel switching!

>>> Example, user downloads pictures from the camera using shotwell,
>>> gthumb, fspot or whatever, keeps the app in question open and the  
>>> app
>>> in question keeps the gphoto2 device handle open.
>>>
>>> User wants to do some skyping with video chat, skype complains it
>>> cannot find the device, since the kernel driver currently is  
>>> unbound.
>>>
>>> -> Poor user experience.
>>
>> Poor user experience, or merely poor user? The user ought to know  
>> better.
>> Of course, I do agree that there are lots of such people, and it is  
>> a good
>> idea to try to put up warning signs.
>
> It is difficult to call the users "poor users" in this case. Since  
> they may
> not know that the other open program is holding the device. Some
> warning message may help, not "I can not find the device" though. It
> would be better to pinpoint which program is holding the device
> and then ask the user to close that program. I understand this is
> easily said than done...
>
> Similar experiences for Windows about the serial port, sometimes
> it is difficult for the user to know that some program or service
> are holding the serial port so that the other program or will fail or
> Windows complain that it is still open when you want to undock
> the computer.
>
>>>
>>> With having both functions in the kernel, the kernel could actually
>>> allow skype to use the dual mode cameras as video source, and if
>>> the user then were to switch to f-spot and try to import more  
>>> photo's
>>> then he will get an -ebusy in f-spot. If he finishes skyping and
>>> then returns to f-spot everything will just continue working.
>>>
>>> This is the kind of "seamless" user experience I'm aiming for here.
>>>
>> Yes, I can see where you are coming from. But if the camera really  
>> will
>> not let you run skype and fspot at the same time, which I do not  
>> believe
>> it would allow on _any_ operating system, then each app should give  
>> an
>> error message which says it cannot be run unless and until the  
>> other app
>> has been closed. If that has to happen at the kernel level, then OK.
>>
>
> Yes. From what I read, to solve it in kernel or to solve it in user  
> space
> are both a lot of work.

Yes and a kernel-based solution locks you into a kernel-based webcam
driver paradigm, or an even uglier loopback driver.

> Personally I tend to think to solve it in user space is more feasible.

I agree.

mike