Re: [libusb] Windows composite device fix

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

Hi Philip.

How do you send the DFU_DETACH command? If the device is composite with say
HID and WinUSB, then WinUSB can't open it to send the DFU_DETACH command.
At least that's my experience here with Windows 7 x64.

How are you opening the runtime device with WinUSB? Is it via a CreateFile
handle or via the OpenDevice library function and a custom
DeviceInterfaceGUID?

Do you perhaps have any example code demonstrating this?

Regards,
Paul


On Wed, 30 May 2018 at 16:15, <Phi...@mi...> wrote:

> 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