Applications ignore USB device's incoming data packet while using default HID driver

2
votes

I am writing a controlling software for a generic USB HID device within a team, working on Windows 7. Due to my status as an intern, my possibilities are limited:

  • the software must work on Windows
  • the software must use the default HID driver Windows supplies

My problem is that however I try to access the device while using the HidUSB driver (according to Zadig) my interrupt transfer read attempts always result with a timeout while the device actually does send data. Writing to the device works all the time, whether I use HIDAPI, whether I use libusb, only reading fails. (this is a primitive device atm and even the final packet data specification isn't done, currently it just sends an ON or an OFF string towards the host, and writing to the device changes the state of a LED between 7 colors and off state, so that one's certainly working)

I can't think of the device being faulty, because if I replace the driver on Windows to the WinUSB driver with Zadig, it works with libusb (and hidapi can't open the device thereafter) and on Linux, just by reading /dev/hidraw also returns the data fine. I have also read the HID and the USB specifications and I know that the device descriptors state that the USB packetsizes are 8, while the HID input report's size is capped at 20, tho I don't know what report ID the device uses.

Checking the Windows communications with USBPcap and Wireshark, the sole difference I can notice among the handling of the device is the host packets asking for data is filled with 00s against the HidUSB driver compared to the CCs when used with the WinUSB driver.

For the record, I have already tried libusb, hidapi, HidLibrary and noone within the team has an idea what to do now.

I have also read that Windows disables access to HID keyboards and mice but I found no actual example of a device config ending up as an USB mice. The Device Manager lists my device twice under HID tho, once as HID-compliant device or how it calls (localized Win7 here) and once as USB Input Device, but doesn't list it among the Mouse or Keyboard option.

1
windowshidlibusbhidapi

1 Answers

2
votes

Sorted it out a while ago, but I think I'll write it down here if someone ends up with a similar issue in the future.

The Windows HID driver invalidates any incoming packet if the report's data size does not match the length of the sent data iow the size within the report descriptor. Linux and the device itself didn't cared that's why I also ruled that out as source during the time I brought the question here. In the above example the on/off message being 4-5 byte vs the reported 20 byte length was the problem, now that the device sends 20B messages, all the solutions which could write via HidUSB can read as well.