> On Jun 1, 2015, at 10:06 AM, Dmitry Fleytman <dmi...@daynix.com> wrote: > >> >> On Jun 1, 2015, at 24:26 AM, Marc-André Lureau <mlur...@redhat.com> wrote: >> >> >> >> ----- Original Message ----- >>>> On May 28, 2015, at 19:03 PM, Christophe Fergeau <cferg...@redhat.com> >>>> 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.
libGusb of course. > >> >>> 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
