On Wed, Aug 10, 2011 at 4:57 AM, Hans de Goede <hdegoede@xxxxxxxxxx> 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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
