windows: Base HID device descriptor on cached values #1378
Conversation
Instead of filling in the blanks with hard-coded made-up values that are sometimes correct, use the cached descriptor values retrieved during enumeration, which should be a better fallback. References libusb#1360 Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
I agree. This PR should be good to go. |
|
For little bit of background here, the code with these hard-coded values haven't been touched since the HID backend was (re?)introduced in 2012. It is pretty much the same in the oldest libusb-win32 git entry I could find from 2007. Back then it was maybe not practical to get the "true" device descriptor from the hub drivers, I don't know exactly. But no one has complained all this time, so we are not in a rush to change it, and definitely not now while we are in release freeze for 1.0.27. We cannot know what downstream code is dependent on the "made-up" values. It is also interesting that some HID devices seem to display e.g. a non-standard bcdUSB value. I don't know if it is the device itself or a Windows driver that comes up with these values. |
Some device descriptor fields are hard-coded by the HID backend, so they will often not match. It is complicated to narrow this down to HID devices, so we simply ignore these fields on Windows wholesale. Hopefully we will fix the HID backend later, and this workaround can then be reverted. References #1360 References #1378 Signed-off-by: Tormod Volden <debian.tormod@gmail.com>
|
We recommend users to use HIDAPI anyway for USB HID devices. So indeed no rush to change the codes before 1.0.27 release. |
Instead of filling in the blanks with hard-coded made-up values that are sometimes correct, use the cached descriptor values retrieved during enumeration, which should provide more correct values.
References #1360