Re: [libusb] Windows composite device fix

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

Hi Philip.

On Mon, 30 Apr 2018 at 18:51, <Phi...@mi...> wrote:

> Actually, WinUSB does handle EP0 (control point) communications. We use
it here in DFU operations. You just have to make sure your DFU mode VID/PID
is given in an INF file that directs Windows to use WinUSB for that combo.

Sorry, my mistake. I meant to say that libusb does not support it. As in,
it doesn't support sending SETUP packets to interfaces on composite devices
on Windows.

The issue is that while it is possible with WinUSB, libusb is built on the
Linux model of treating composite devices as a single device. On Windows
they appear as at least three devices - a composite device using the
composite driver, and then sub devices which can be WinUSB, HID, CDC or
whatever. And libusb opens the composite device and can't pass SETUP
requests to it because it has the wrong driver.

I don't think it is possible to replace the composite driver with WinUSB,
but please correct me if I am wrong because that might be a good solution.

I don't use INF files, I use WCID but if there is a solution here it is
probably possible with WCID too. As far as I can tell though WCID only lets
you assign the WinUSB driver to interfaces, not the composite device. You
can certainly replace it with a libusb driver via Zadig, but that isn't
possible via WCID...

> To clarify a bit. We do not use libusb on Windows. We use WinUSB directly
(and for HID, we use the standard user-level HID system calls). We do use
libusb on Linux and on OS X.

Indeed, that is an option. I could add WinUSB support to dfu-util when
built on Windows.

In summary I think there is no way to fix either the runtime DFU firmware
or libusb to support runtime DFU.

Regards,
Paul