Re: [libusb] Windows composite device fix

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

I'm back now, and have spent a bit more time on this problem.

In short I think composite devices are not well supported on Windows, and
full DFU support is probably impossible with WinUSB.

The issue is that WinUSB only supports composite devices where all the
interfaces use the WinUSB driver. If you try to have something like an HID
device with WinUSB for the DFU interface, it just doesn't work. You can't
open the WinUSB interface. Therefore, DFU cannot be supported for another
other than pure WinUSB devices.

I also looked at ways to create a new but at least consistent runtime
bootloader protocol, but because of this limitation of WinUSB there isn't
one. You would need to have a separate protocol for HID, CDC, mass storage
and every other type of device. This has also scuppered my plan to have an
HID device with WinUSB bulk endpoints.

There is nothing that can be done to fix libusb because the problem is with
WinUSB. The only solutions all involve installing alternative drivers.

I'm giving up.

Regards,
Paul Qureshi

On Thu, 3 May 2018 at 09:05, Paul Qureshi <pa...@wo...> wrote:

> Hi Tim.

> On Wed, 2 May 2018 at 18:41, Tim Roberts <ti...@pr...> wrote:

> > Of course it is.  WinUSB handles composite devices and multiple
> > interfaces.  It just requires an INF.

> Yes, I was talking in the context of having the alternative driver
selected
> via WCID. This does not seem to be possible, only WinUSB can be selected.

> INF files are an unsatisfactory solution, especially for open source
> projects where the cost of getting them signed is prohibitive. More over,
> users prefer devices that "just work" and don't require manual driver
> installation. That is particularly true of things like keyboards and mice.

> So the goal here is to find a solution that works with WCID. Ideally
> without GUIDs too, because code space in a 4k bootloader is tight.

> > Now, there may be a slimy way to handle this.  In the Enum tree of the
> > registry, each device has a "Service" entry that identifies the driver
> > service that will handle the device.  It is possible to overwrite that
> > entry on the fly, then restart the device.  When it comes back it, it
> > will load the alternative driver.  You could do the DFU thing, then
> > rewrite the Service entry back to "usbccgp".  You'd have to make sure
> > the entries for WinUsb were properly set up, but it might work.

> At the moment I am prototyping some WinUSB code to see what is possible
and
> if it could possibly be integrated into libusb somehow. libusb is aware of
> the sub-interfaces, but it sees them as already being claimed by the
> composite driver. Perhaps there is a way to find the correct sub-device at
> that stage. Alternatively, perhaps it would be possible to open the sub
> device with a special open function that takes the interface number.

> If none of that proves possible then a new WinUSB based DFU utility is the
> next option. I will be away for a few weeks so there won't be any progress
> this month.

> Regards,
> Paul