[Spice-devel] [PATCH 0/5] RFC: Support UsbDk backend

[Marc-André Lureau]

----- Original Message -----
> > On May 28, 2015, at 19:03 PM, Christophe Fergeau <cfergeau at 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.

> 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.

> >> 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.

>
> > 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.

> 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.