Re: [libusb] Windows composite device fix

[Xiaofan C. <xia...@gm...>]

On Fri, Apr 27, 2018 at 4:16 PM, Paul Qureshi <pa...@wo...> wrote:
> I now have to choose between writing a new, Windows only DFU tool or fixing
> libusb. So I thought fixing libusb would be the better option. When
> researching this issue it seems to be affecting a lot of people.
>
> What is the best way to sort this out once and for all?
>
> Is adding support for the Windows composite driver likely to work?
> Unfortunately, as Pete Batard notes, the Windows back-end is a bit of a
> jungle because it tries to fit the libusb model. The goal would be to allow
> libusb to seamlessly open any interface on the composite device,
> automatically selecting the correct child device.
>
> What other options exist?
>
> To be clear I'm willing to do the work here, I'm just looking for some
> discussion of the best way to implement this.
>

Ref: https://github.com/libusb/libusb/issues/422

I think there are a few options, from easy to more difficult based on
my own view.

1) If you have the control of the FW, make the DFU to be of interface 0
and the HID interface to be of Interface 1. This will probably work for
your use case.

2) Write a DFU application based on WinUSB or libusbK API, still
use the WinUSB driver

3) Write a DFU driver (ST has one, Atmel has one as well).
http://www.st.com/en/development-tools/stsw-stm32080.html

4) Try to use libusb0.sys filter driver with libusb, I think it may work
even though there were issues with it. libusbK works fine with it
and therefore supposedly the Windows backend should work fine
but apparently there are something not right here.
https://github.com/libusb/libusb/issues/94

5) Try to check if usbdk works or not, if not extend it to support
USB composite device

6) To rework the Windows backend code to better deal with
USB composite device.


-- 
Xiaofan