Re: [libusb] Windows composite device fix

[Tim R. <ti...@pr...>]

Paul Qureshi wrote:
> The short version is that Windows treats composite devices as multiple
> different devices from a driver point of view, where as Linux treats them
> as one device. As a result, libusb is unable to open the parent device as
> it does not have a supported driver.

The situation is more complicated than that.  You can certainly write an
INF that claims the composite device, in which case you have full
control over all of the interfaces.  In the typical case, the interfaces
really are separate devices, so the device manufacturer will write his
INF so it does not claim the composite device.  Windows then supplies a
default composite driver, which exposes the interfaces as separate
devices, each of which gets its own driver.

The problem comes when you try switch between the two.  If the DFU state
comes up with the same VID and PID as the functional state, Windows has
already configured itself to apply the composite parent to that device. 
It takes some hackery to override that.

The ideal situation would be to use one of the backends as a filter
driver, but I'm not sure that's supported any more.


> Is adding support for the Windows composite driver likely to work?
> Unfortunately, as Pete Batard notes, the Windows back-end is a bit of a
> jungle because it tries to fit the libusb model. The goal would be to allow
> libusb to seamlessly open any interface on the composite device,
> automatically selecting the correct child device.

Windows does not make that easy, because it is directly contrary to the
Windows device management philosophy.  The libusb philosophy is "I want
this VID and PID, now give it to me."  The Windows philosophy abstracts
all that through plug-and-play.  Windows discovers new hardware, and
immediately searches to find a suitable driver.

I'm not sure there is an easy answer.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.