Re: Improving kernel -> userspace (usbfs) usb device hand off
On Sat, Jun 11, 2011 at 6:43 AM, Theodore Kilgore wrote: > I do not believe that we have found the optimal solution, yet. The ideal > thing would be some kind of hack which allows the kernel to be used when > it is needed, and when it is not needed it does not interfere. Just wondering if you can use libusb-1.0 for the user space still image functionality. libusb-1.0 offers the following functions to do that for you under Linux. int libusb_kernel_driver_active (libusb_device_handle *dev, int interface) Determine if a kernel driver is active on an interface. int libusb_detach_kernel_driver (libusb_device_handle *dev, int interface) Detach a kernel driver from an interface. int libusb_attach_kernel_driver (libusb_device_handle *dev, int interface) Re-attach an interface's kernel driver, which was previously detached using libusb_detach_kernel_driver(). So you can detach the kernel v4l2 driver at the beginning and later re-attach it when you finish. -- Xiaofan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Improving kernel -> userspace (usbfs) usb device hand off
On Mon, Jun 13, 2011 at 5:20 AM, Theodore Kilgore 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? >> 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. Personally I tend to think to solve it in user space is more feasible. -- Xiaofan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB mini-summit at LinuxCon Vancouver
On Wed, Aug 10, 2011 at 4:57 AM, Hans de Goede wrote: > 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. So it seems to be both good and bad for Linux's ability to do multiplexing between the two drivers (one purpose-built kernel driver and one generic usbfs driver to be used libusb). The good thing is that it is quite useful in many use cases. The ability to detach the existing kernel driver and use usbfs is the base for many libusb based program under Linux and it beats Windows and Mac OS X handsomely in this aspect. On the other hand, based on the discussions, it seems to adds quite some issues/complexities in some other use cases. Windows typically does not have such an issue. You can use only one driver. In order to use libusb-win32 or libusb-1.0 Windows backend, you have to replace the existing kernel driver with libusb-win32 kernel driver (libusb0.sys) or libusb-1.0 Windows backend driver (currently winusb.sys). The exception is the libusb0.sys filter driver. In that case, you use libusb0.sys as the upper filter driver on top of the existing kernel driver. On the other hand, libusb-win32 filter driver is not really widely used due to issues with older versions. > 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. > All in all, I think this is a good summary. There are cases where a kernel driver and a usbfs are both used, an example is FTDI device where ftdi-sio driver and the user space libftdi (based on libusb) are used, but there are problems with that as well with regard to switching between the two drivers. There are a few discussions here. http://libusb.6.n5.nabble.com/Patch-libusb-os-linux-usbfs-c-Distingush-between-usbfs-and-other-kernel-mode-drivers-td3199947.html http://libusb.6.n5.nabble.com/open-device-exclusively-td4524397.html And there are no good solutions to a "simple" issue as the above mentioned. Not so sure if this is a good suggestion or not: just wondering how the other side (eg Windows) deal with these dual mode cameras? Does Windows use single driver or does Windows use two drivers for these dual mode cameras? Since they are customized device, then there must be a vendor driver for them. And since they will function as a video cam and a still cam device, I assume there will be standard Windows drivers on top of the vendor drivers. So there will be more than one drivers associated with them. -- Xiaofan -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
