Re: [libusb] Windows composite device fix

[<Phi...@mi...>]

We have the capability of using WinUSB and DFU when updating composite devices.

The device's firmware would be bumped into DFU mode by the normal DFU_DETACH (setup) command or by any other mechanism you might want to employ. When your device re-enumerates into DFU mode (which will have a different PID), then that VID/PID can be specified in an INF file to use WinUSB (which can be used to access EP0, which is the only endpoint that DFU uses).
 
This is regardless of the configuration of the device in non-DFU (normal operation) mode, be that HID, CDC, bulk or whatever other endpoints that configuration might contain (as a composite device). Your "normal" device's configurations no longer apply when your device is in DFU mode.

Yes, you need an INF that specifies the VID and DFU PID to be handled by WinUSB, but this is a pretty trivial matter (unless you want absolutely no drivers involved).

Am I missing something here?

________________________________________
From: Paul Qureshi [pa...@wo...]
Sent: Wednesday, May 30, 2018 7:19 AM
To: lib...@li...
Subject: Re: [libusb] Windows composite device fix

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

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