Hi, this is a repost of a misplaced issue I posted about on the HIDAPI Github repo: github[DOT]com/libusb/hidapi/issues/752
I've got a device with a firmware bug that means it returns a malformed report descriptor. In practice, this means that in Windows, the built-in HID driver fails with the device and I get a little exclamation mark in device manager with an error message like
This device cannot start. (Code 10)
Extra end collection found or end collection not found.
eg. github[DOT]com/user-attachments/assets/10c31b7a-4079-4cfc-9c59-b9311730932d
Similarly in Linux, when I plug the device in, the journal shows:
[ 2.258067] hid-generic 0003:3746:FFFF.0001: unbalanced collection at end of report description
[ 2.258092] hid-generic 0003:3746:FFFF.0001: probe with driver hid-generic failed with error -22
After some digging, I've figured out that the device seemingly leaves off three 0xC0 (end collection indicator) bytes from its HID report descriptor, and that's why everyone's generic HID drivers don't work.
I've figured out how to patch the report descriptor on-the-fly in Linux: github[DOT]com/greyltc/r3pcomms/blob/8bd4e65655d546fb53ddde6b30d8380a4e53cb99/hid_fixes/r3p_rd_patch.c#L23-L29
and the hid-generic driver there starts working again and I can communicate with device as normal.
Do you know any similar workarounds I can apply in Windows to fix up the malformed report descriptor so that the generic windows HID driver (and thus the HIDAPI project) will work there too
Why are you doing this, instead of fixing the firmware, as you should?
Yes, it is possible to write a lower filter driver to replace the report descriptor on the fly, but it's a hell of a lot more trouble than just fixing the device.
1 Like
Why are you doing this, instead of fixing the firmware, as you should?
I doubt the manufacturer would share the firmware's source code and teach me how to build and flash it. I think it's fair to say that fixing it myself isn't a realistic option. This is just some hardware that I bought that I'm writing some open source software for for fun.
Shame there's no simple workaround for a device with a non-compliant HID report descriptor!
I see. No, there is no generic path for fixing broken hardware, because there are just too many ways for hardware to be broken. The keyword in your post is "non-compliant". We don't reward flawed hardware.
As I said, you CAN do this with a lower filter driver. Assuming you understand USB, it's not all that much code.
1 Like
I used to not know so much about how USB works, but I've learned a lot recently, mostly specifically related to HID as I've been troubleshooting this issue. I'm sniffing the raw USB packets with wireshark to learn how things work.
As I said, you CAN do this with a lower filter driver. Assuming you understand USB, it's not all that much code.
I've already taken a similar approach with success in Linux by following this nicely documented example: libevdev.pages.freedesktop[DOT]org/udev-hid-bpf/tutorial.html#modifying-the-hid-report-descriptor I had hoped to be able to do a similar thing in Windows (not much code there either, I just needed to learn the workflow).
The manufacturer uses a custom driver for the hardware. Part of me wonders if they're purposefully shipping firmware with three missing 0xC0 bytes in order to break the generic HID driver to force users to use their special driver for some reason; because like you said, it makes so much more sense to do a super simple fix in the firmware than to do all this custom driver work!