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

[Dmitry Fleytman]

> On Jun 1, 2015, at 24:26 AM, Marc-André Lureau <mlureau at redhat.com> wrote:
> 
> 
> 
> ----- 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.

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