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

[Dmitry Fleytman]

> On Jun 1, 2015, at 10:06 AM, Dmitry Fleytman <dmitry at daynix.com> wrote:
> 
>> 
>> 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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20150601/ce2297c0/attachment-0001.html>