Hi, On 05/21/2012 11:26 AM, Xiaofan Chen wrote: > On Wed, May 2, 2012 at 4:28 PM, Hans de Goede<hdego...@redhat.com> wrote: >> Hi, >> >> On 05/01/2012 10:29 PM, Pete Batard wrote: >>> On 2012.05.01 16:52, Uri Lublin wrote: >>>> Only if old backend api is UNSUPPORTED. >>>> >>>> This happens when a libusb driver (e.g. WinUSB) is installed >>>> after a device has been setup/discovered (with get_device_list). >>>> >>>> --- >>>> >>>> We want to install libusb driver for USB devices dynamically following a >>>> request by users. There is a problem however to access such devices >>>> after libusb driver is installed as the backend api is UNSUPPORTED. >>>> >>>> With this patch, after the WinUSB libusb driver has been installed, an >>>> application >>>> only needs to call libusb_get_device_list again such that it can >>>> access the device. >>> >>> I must say that having a new libusbx/Windows supported driver being >>> installed after get_device_list is not something that was anticipated >>> when designing the Windows backend, as the expectation on Windows was >>> that, during the course of usage of libusbx (init -> exit), drivers are >>> not going to be installed/uninstalled. The reason is that, unlike other >>> OSes, the installation of drivers on Windows is a very intrusive >>> operation that you want to complete before launching any application >>> that relies on said driver. >>> >>> Is there a specific reason why you can't go through a libusbx reinit >>> (exit then init) after having installed your driver? This is what I >>> would expect any application to do, that installs a driver with the aim >>> of it being used in libusbx/Windows, and I don't expect any issue if you >>> do that. >> >> The problem is that with usb device redirection we can have 1 device >> already redirected, and then the user asks to redirect another device >> to the virtual machine, so we install a driver for the other device, >> and then need to be able to use the other device without re-init, since >> we still have the first device open. Note that we use one context for >> all devices, which from our pov makes sense since we also do "device >> management" and for this we have one context where we enumerate devices, >> once we've the device enumerated in this context, it is easiest to >> keep using the same context for actually talking to the device. > > Just wondering how usbredir works. If you replace the existing > non-winusb driver with the winusb driver. In that case, the existing > function of the device is no longer valid under the host. For example, > you keyboard, mouse and flash drive will no longer work as a > keyboard, mouse or flash drive.
Correct, you are in effect plugging the device out of the host and into the vm. Regards, Hans ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
