Re: [libusb] Windows composite device fix

[Paul Q. <pa...@wo...>]

Okay, I have tried the simple fix of making the DFU interface zero instead
of one, but it didn't help. Libusb still gives the same unsupported error.

One other option I thought of is to support DFU on interface 0 without the
descriptor. You can't have a DFU descriptor on interface 0 while it is also
being used for something else like HID, but you can respond to DFU setup
packets anyway. The down side is that there is no way to detect a DFU
capable device if it lacks the descriptors, but at least it will work on
Windows. Some kind of override flag will need to be added to dfu-util.

Regards,
Paul

On Sat, 28 Apr 2018 at 18:54, Paul Qureshi <pa...@wo...> wrote:

> Hi David.

> Thank you for this. I shall try it on Monday.

> You are right, I am using DFU so that I can take advantage of dfu-util and
> other software that supports it. But given the situation, where I will
> either have to do a massive amount of work to fix libusb or re-write
> dfu--util anyway, maybe creating a new bootloader system is the way to go.

> DFU is kinda rubbish anyway... Very limited in what it can do, resulting
in
> incompatible extensions by several manufacturers.

> The down-side is that libusb is the most popular option, and this
> limitation prevents a lot of otherwise great software like dfu-tool from
> working on the most popular OS. I guess you have to pick your battles
> though, and from the sounds of it fixing libusb won't be easy.

> In any case, I will try your library.

> Regards,
> Paul


> On Sat, 28 Apr 2018 at 18:21, David Grayson <dav...@gm...>
wrote:

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