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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

On Mon, Jun 13, 2011 at 5:20 AM, Theodore Kilgore
<kilgota@xxxxxxxxxxxxxxxxxxxxxx> 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


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux