Re: [libusb] Windows composite device fix

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

Hi Philip.

On Mon, 30 Apr 2018 at 17:05, <Phi...@mi...> wrote:

> Xiaofan is correct concerning DFU mode. When a host instructs a device,
which is in "run-mode" (normal operation). to go into DFU mode via the
DFU_DETACH command, the device will eventually go off-line and re-enumerate
into DFU mode. I would highly recommend that the "DFU device" have a unique
PID. In this case, under Windows, you can provide an INF that will direct
Windows to use WinUSB or whatever you want to allow you access to EP0
(endpoint zero) on that device (which is the only endpoint that will be
available).

> Information regarding DFU can be found in the document, "Universal Serial
Bus Device Class Specification for Device Firmware Upgrade", Version 1.1,
dated 05 August 2004 (which is the latest revision), taken from
http://www.usb.org/developers/docs/devclass_docs and the item "Device
Firmware Upgrade Group".

That is correct. The way it normally works is you have a DFU runtime
descriptor in the main firmware, along side the HID one. The DFU descriptor
is on a different interface; it can't share with HID so the device must be
composite.

The host asks the DFU runtime interface to detach and re-enumerate into DFU
mode, after which it loads the firmware. The DFU mode will normally have a
different PID. dfu-util handles this by allowing you to specify both the
runtime and DFU mode VID/PID pairs.

Unfortunately, none of this helps in this instance. Providing INF files
defeats the purpose of all this - that the device works simply by plugging
it in. Customers are expecting things to "just work" these days.

Regards,
Paul Qureshi