Re: [libusb] Windows composite device fix

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

On Sat, Apr 28, 2018 at 5:27 PM, Paul Qureshi <pa...@wo...> wrote:
> Hi Xiaofan.
>
> On Sat, 28 Apr 2018 at 05:44, Xiaofan Chen <xia...@gm...> wrote:
>
>> 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.
>
> I will try this on Monday when I'm back at work. If that fixes it then that
> would be a good solution for me.
>
> Thinking about it, I wonder if I could add DFU functionality to the HID
> interface... Windows will probably not like it, but really all it needs is
> the descriptors and some code to handle the control requests to that
> endpoint.

Actually I think DFU class and HID are mutual exclusive. You
can of course use HID for firmware upgrade, but then it will not
be called DFU. In fact, Microchip is using HID class for its bootloader
function and they use HIDAPI and QT to build the cross-platform
host program.

HIDAPI is the cross platfrom API for HID device.

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

Take note this is still using libusb API.

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

Take note this is still using libusb API.

> I would prefer to keep it cross platform.

Take note that Option 4/5 are still using libusb API.

>
>> 6) To rework the Windows backend code to better deal with
>> USB composite device.
>
> I would be happy to do that, but it's a rather complex a poorly documented
> bit of code with heavy abstraction that makes it difficult to work with.
>
> Can anyone suggest a good way to modify the backend? It seems like it needs
> some way to interact with the composite driver and redirect attempts to
> access other interfaces.
>



-- 
Xiaofan