Control transfer through Windows HID driver?

[Renate]

There are two generic built-in drivers in Windows, WinUSB and HID.
In WinUSB we have WinUsb_ControlTransfer to send control transfers.
For HID there does not seem to be any way to send a control transfer (from user space).
Ive looked at all the HidD_, HidP_ and even IOCTLs.
Considering that HidD_SetReport uses endpoint zero anyway (in the absence of an out endpoint), this seems like an omission.
Is there anything?
I've even tried WinUsb_Initialize on a HID handle.

The application is using a vendor control message to put a device into bootloader mode without using an out endpoint or even a report.

P.S. I did notice the undocumented DWORD WINAPI HidD_Hello(char *buf, DWORD size)

[Jan Axelson]

With device firmware support, hosts can do control transfers with:

HidD_GetInputReport
HidD_SetOutputReport
HidD_GetFeature
HidD_SetFeature

[Renate]

Yes, those are control transfers, but they are not my control transfers.
How do I send {0x40, 0xb0, 0x0000, 0x0000, 0x0000}?

[Jan Axelson]

All data to and from HIDs is contained in defined reports.

To send a vendor-defined message to a device, define an Output or Feature report of the desired length and use  HidD_SetOutputReport or HidD_SetFeature to send it. The device must have firmware support to receive the report and take the desired action.

[Renate]

I guess that the long and short of it is that hidusb.sys does not allow custom control transfers.
Of course, you could make this a composite device with an interface bound to WinUSB, then you could WinUsb_ControlTransfer to the same darn control endpoint.

There are other limitations that don't make particular sense too.
Why can't hidusb.sys pass through IOCTL_HID_GET_REPORT_DESCRIPTOR?
You can trivially get the report descriptor in Linux with HIDIOCGRDESCSIZE/HIDIOCGRDESC.

[Jan Axelson]

IOCTL_HID_GET_REPORT_DESCRIPTOR - don't know why it wasn't implemented but other APIs, HidP_GetCaps etc., can return report descriptor information.

A HID control transfer can be vendor defined as long as it has a report descriptor that at minimum defines the report length.

[Renate]

Well, all the HidP_ stuff works with "preparsed" report descriptors.

Dealing with all this stuff on Windows leads to insanity.
You can go from the top down instead (just an overview, not actual code):

Code: [Select]

SetupDiGetClassDevs(&GUID_DEVINTERFACE_USB_HOST_CONTROLLER
DeviceIoControl(IOCTL_USB_GET_ROOT_HUB_NAME
CreateFile
DeviceIoControl(IOCTL_USB_GET_NODE_CONNECTION_INFORMATION
DeviceIoControl(IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTIONBut even here MS did something annoying that wasn't necessary.
IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION hard-wires the type & request of the setup packet to 0x80 (device in), 0x06.
If they had been looser and allowed 0x81 (interface in), 0x06, 0x2200 we could have gotten report descriptors.
As a matter of fact, on some sloppy devices, I ask for 0x81, 0x06, 0x2200, MS relays that as 0x80 and the device (incorrectly) responds with the report descriptor.
Sheesh.

Not only that, you can't easily correlate a NODE_CONNECTION with a DEVINST.

[Jan Axelson]

Interesting! I agree with the complaints!

[Renate]

Not to beat a dead horse (ok, I am)...

usbview.exe source code seems to always be the point of reference when someone has a USB question for Windows.
I found an ancient copy from 1997-1998 which purportedly gets HID report descriptors.
https://www-user.tu-chemnitz.de/~heha/viewzip.cgi/hs/usbview.zip/src/enum.c
See: LocateHidDesc()

Looking at the code, I see that it tries to unpack that from the configuration descriptor.
Who, when, why did anyone ever put HID report descriptors inside the configuration descriptor?

That whole code is a work in progress. They also discovered that you can't 0x81, 0x06:

Code: [Select]

if (DeviceIoControl(h,IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION, // <-- TODO: Search the right IOCTL for this!
Twenty-odd years and still waiting for this to get fixed...

[Jan Axelson]

Interesting, thanks for posting!

[ulao]

I had this same issue and got around it by making a polymorphic like descriptor.

                //get data
      0x85, 0x16,                    //   REPORT_ID (22)
      0x96, 0x00, 0x01,              //   REPORT_COUNT (256) one less then rid
      0x09, 0x00,                    //   USAGE (Undefined)
      0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)
            
      //send data for anythign 8 or less. Also has support more data via header
      0x85, 0x12,                    //   REPORT_ID (18)
      0x95, 0x08,                    //   REPORT_COUNT ( 7 + report ID
      0x09, 0x00,                    //   USAGE (Undefined)
      0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)

I then can send a byte and received data. When I send data from the PC the first byte tells me what type of data I need.  When returning I can use a length byte.  You could adjust as you need.