Re: [libusb] windows support for LIBUSB_REQUEST_TYPE_VENDOR

[Peter H. <ph...@gm...>]

Notice all my knowledge about USB is only from reading a few tutorials 
(like USB in a NutShell) and the experience I got modifying the keyboard 
firmware and the associated QT client PC application. I did not even 
write the original source code there. My goal si so that the PC 
application works well for both Linux and Windows and preferably using 
the same code path (without ifdefs). Sometimes I may be quite wrong in 
my thinking how it works. Thanks for patience.

On 08/26/2015 09:27 PM, Tim Roberts wrote:
> Peter Hercek wrote:
>> Thanks for pointing all my mistakes. I think I understand now. I should
>> be sending vendor requests to my new interface (instead of the device).
> Are you talking about the bmRequest field?  That isn't related to what
> we're talking about here.  The device neither knows nor cares what the
> driver configuration is like.  It just gets requests.  What you need to
> know is how to get that request.  To do that, you need to open a
> driver.  To get a driver you can open, you need an interface, which
> doesn't need any endpoints.
Yes, I meant bmRequestType. I'm not sure what you mean by device here. 
Is it a windows abstraction of a physical device (like a keyboard) in 
the corresponding driver or do you mean the firmware in the physical 
device (e.g. keyboard firmware).
Looks like you mean the physical device. And yes the keyboard firmware 
in my case does not have any clue about drivers on the PC side.

>> What happens when one sends vendor request to a device which has more
>> interfaces and the interfaces use different drivers (and therefore
>> backends). Which backend would process requests to the device?
> I don't understand the question.  Interfaces are merely used to collect
> endpoints together and trigger driver loading.  The traffic on the wire
> is concerned only with endpoints.  The only time an interface number
> goes across the wire is when you enable an interface or change an
> alternate setting.  The device just sees traffic for endpoint 0 or
> endpoint 0x81, etc.
>
I'm talking about mbRequestType here. As far as I know the QT 
application just:
* enumerates the usb devices (libusb_get_device_list);
* selects the descriptor it knows (using checks on result of 
libusb_get_device_descriptor);
* gets handle for the descriptor (libusb_open)
* sends vendor requests to the keyboard (libusb_control_transfer)

The vendor requests are targeted as:
LIBUSB_REQUEST_TYPE_VENDOR |
     LIBUSB_RECIPIENT_DEVICE |
     LIBUSB_ENDPOINT_{IN,OUT}

By sending a request to the device I mean LIBUSB_RECIPIENT_DEVICE.
By sending to an interface I mean LIBUSB_RECIPIENT_INTERFACE (and the 
interface id being in wIndex).

I assumed that libusb does dispatching to the proper backend (driver) 
based on the selected interface. If that would be so, then of course 
there is a question how requests targeted as LIBUSB_RECIPIENT_DEVICE or 
LIBUSB_RECIPIENT_ENDPOINT (for the shared endpoint 0) would be 
dispatched. Which backend would be selected if there are more 
backends/drivers associated with the device? From your response it feels 
like I must select the backend explicitly somehow.

What linux driver would correspond to WinUSB driver in Windows? Lets 
assume I want to extend the keyboard device by adding a logging 
interface and an input interrupt endpoint with it. I.e. the added 
interface would not use only endpoint 0 but also its own *endpoint**N*. 
What would be a good driver on linux (I assume it is WinUSB on windows) 
to read the raw data from *endpoint**N*?