Re: [libusb] Windows composite device fix

[David G. <dav...@gm...>]

Hello Paul Qureshi and others,

I made a new library named libusbp[1] which was developed with
Windows, Linux, and macOS in mind, and it has a different model for
connecting to devices that works OK on all of them, at least for my
limited uses:

1) You call libusbp_list_connected_devices to get a list of physical
USB devices with a vendor ID, product ID, revision number, and serial
number.

2) You use libusbp_generic_interface_create to create an object
representing a USB interface with a generic driver (like WinUSB).
This function takes a USB device, an interface number, and a boolean
saying whether the device is composite.

3) You use libusbp_generic_handle_open to open a handle to the generic
interface object so you can actually do I/O.

So for my limited use cases, which basically consist of connecting to
an interface and sending some control transfers, I don't have to do
any platform specific code outside of the library.

By the way, it seems like the main point of using DFU is so your
device can be compatible with some existing software, but if that
software doesn't fit your needs and must be modified, you might
consider making a custom bootloader with custom software tailored for
your needs.

--David

[1]: https://github.com/pololu/libusbp


On Fri, Apr 27, 2018 at 1:16 AM, Paul Qureshi <pa...@wo...> wrote:
> Hi.
>
> I've been trying to get dfu-util to work properly on Windows. After
> submitting a patch to fix the control transfer interface selection (
> https://github.com/libusb/libusb/pull/398) it can now write firmware in DFU
> mode. Unfortunately, it still can't work with runtime mode because libusb
> does not support composite devices on Windows.
>
> The only fix at the moment is to replace the composite parent driver with
> Zadig, but this is unsatisfactory as it means composite devices can't "just
> work" on Windows.
>
> Pete Batard provides great insight into this issue here:
> https://sourceforge.net/p/libusb/mailman/message/33176212/
>
> The short version is that Windows treats composite devices as multiple
> different devices from a driver point of view, where as Linux treats them
> as one device. As a result, libusb is unable to open the parent device as
> it does not have a supported driver.
>
> 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.
>
> Regards,
> Paul
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel