> On Jun 1, 2015, at 24:26 AM, Marc-André Lureau <mlureau@xxxxxxxxxx> wrote: > > > > ----- Original Message ----- >>> On May 28, 2015, at 19:03 PM, Christophe Fergeau <cfergeau@xxxxxxxxxx> >>> wrote: >>> >>> On Thu, May 28, 2015 at 01:23:59PM +0300, Kirill Moizik wrote: >>> Hey, >>> >>>> This set of patches add UsbDk backend support to spice-gtk. This series >>>> currently cannot be applied since it require next patches series in >>>> libusb >>>> http://marc.info/?l=libusb-devel&m=142532078226137&w=2 . >>>> We are waiting for this patches to be commited to libusb soon and then >>>> this series can be applied. >>> >>> What happens when spice-gtk is built/run against a libusb version >>> without the patches? Is there a way to detect this situation at runtime? >>> Or do we need a configure check on the libusb version which is being >>> used in order to disable usbdk if it's too old? >> >> Since UsbDk patches introduce no changes to libusb interface I see no way to >> detect this in runtime. > > What happens then? If you need something specific from libusb, perhaps you should introduce the API there to check dynamically. Hi Marc-Andre, Then libusb itself will try to work via WinUsb and in case WinUsb installed for the device everything will be ok, the problem is spice-gtk will not install WinUsb driver for the device being redirected because it will think it is working with UsbDk backed libusb. > >> The same problem exists for the compile time verification - libusb, even >> withUsbDk patches, may be >> compiled without UsbDk support, so checks based on libusb version will be not >> trusted. >> >> Surely it is a good idea to verify consistency of configuration between >> spice-gtk and libusb, >> so any idea of how to do it in a robust way is highly welcomed. > > As long as it can build, it's enough check. Runtime checks are often unnecessary, especially for cross-compilation. I’m basically for this approach unless spice-gtk is linked with libusb dynamically... > >>>> Dmitry Fleytman (3): >>>> build: add build option for non-winusb redirection backends >>>> usbdk: Add UsbDk hider interface wrapper >>>> usb-device-manager: Configure UsbDk hiding rules on auto-redirection >>>> >>>> Pavel Gurvich (2): >>>> windows: fix device matching for non-WinUSB configurations >>>> usbdk: make backend selection dynamic > > Do we need to have multiple runtime backends on windows? I would prefer if it would support only one at runtime. Even better would be to have only one in spice-gtk source code. The idea is to have support both backends for transitional period. At some point of time usbclerk-related code should be dropped of course. > >> >>> Last but not least, I think you mentioned some freeze occurring when >>> redirecting some devices, and said it would be best to fix it in >>> spice-gtk. Can you give more details as to when this freezing occurs, >>> where exactly in the code this occurs (eg spice-gtk method name, and >>> libusb function which freezes) ? Do you need help with fixing that? >> >> >> Yes, the issue is libusb_open/libsub_close functions take 2-3 seconds with >> UsbDk because they now reset USB device internally. >> With current patches spice-gtk freezes for that period of time which is a >> slight problem from UX point of view. >> >> Since the issue is spice-gtk specific, i.e. it is not relevant for >> non-interactive or CLI applications, we believe it should be fixed in >> spice-gtk. > > That doesn't mean that libusb isn't used elsewhere. A good alternative to solve it would be in libgusb. Thanks. We’ll take a look into libusb. > >> Our current idea is to spawn separate thread(s) for start/stop redirection >> operations to allow spice-gtk process user input and behave smoothly. >> >> Of course we will be glad if you help deal with that issue. What would you >> suggest? > > This is typically a job for g_simple_async_result_run_in_thread / g_task_run_in_thread. Cool. We will check. Thanks for your advices, Dmitry _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel