Re: [libusb] windows support for LIBUSB_REQUEST_TYPE_VENDOR

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

Alan Stern wrote:
> On Thu, 27 Aug 2015, Tim Roberts wrote:
>>
>> But, that question is meaningless, right?  Drivers don't process
>> requests.  Drivers SUBMIT requests.
> No, libusb submits requests.  Drivers like WinUSB take the submissions
> and massage them into a form that core OS will accept.  At least,
> that's my understanding -- otherwise why would libusb need any 
> particular driver to be associated with a device?

Because libusb is just an application.  It doesn't really participate in
the kernel USB subsystems.  It can't, because user-mode applications
aren't allowed to do that.

When I said "requests", I meant "URBs".  Only drivers can submit URBs. 
The libusb/driver interface is merely a private convention between a
kernel driver and its user-mode client.  It happens to have the same
information one would find in a URB, but that's just a convenient
accident.  It's not part of the USB core on any of the operating systems..


> (Or if you want to put it another way, libusb asks a driver to submit a 
> request on its behalf.  They amount to the same thing.)

I would argue that it is NOT the same thing.  It is merely an accident
of the design of the WinUSB API.  Libusb is just one of a plethora of
clients that feed to myriad private kernel driver interfaces that get
translated into URBs, where the USB stack really begins.  However, this
is just unimportant semantic nitpicking, something I enjoy more than
most rational people.

 
> So if you had a composite device, with WinUSB bound to one interface, 
> libusbK bound to another, and some other driver bound to a third, what 
> would happen when libusb submits a control request like the one 
> described above?

There can't possibly be any automatic routing, if that's what you're
asking.  In a composite device, on Windows at least, it isn't until you
get down to the generic composite parent driver (usbccgp) that any of
the components are even aware that there ARE multiple interfaces. 
Usbccgp rewrites the descriptors that it hands upwards, so that the
individual interface drivers are fooled into thinking they are a
single-interface device.

All of the interface drivers have access to the control endpoint, and a
driver can certainly create a control transfer URB with a different
interface number than the one it was assigned.  In earlier systems,
Windows would allow this.  Starting in Windows 8, such a request fails
with an "incorrect parameter" error, just as Linux has always done.

HOWEVER, with WinUSB in particular, there is an additional twist to
this.  When you call WinUsb_ControlTransfer with a "to interface" or
"from interface" request, WinUSB will automatically fill in the wIndex
field with the interface that you own.  Thus, it is impossible to submit
a cross-interface request through WinUSB.

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