Missing one byte feature report read under Windows for devices without report id #328
Labels
No labels
3rdparty
Android
API
Author does not respond
bsd
bug
build system/CI
ci-virtual-device
CMake
Contributions Welcome
Core
dependencies
device-specific
documentation
don't_merge
duplicate
enhancement
Example
Haiku
hidraw
hotplug
info required
invalid
libusb
macOS
Misc
Not an issue
question
Release
Test
Test GUI
Windows
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libusb/hidapi#328
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Reference here:
https://github.com/libusb/hidapi/issues/285
Now I start to question the commit
github.com/libusb/hidapi@6fcb0bb228which I proposed in #232 with regard to feature report. It seems to be correct when the report id is not zero. However, it seems to report one less byte when there is no report id. It seems to me for Windows, we may need to report one more byte for reading of feature report when the report id is zero.https://github.com/libusb/hidapi/issues/285#issuecomment-907570047
Just tried hidapitester with hidapi-0.10.1 release and hidapi git head, with regard to input report, the result is the same since it is using hid_read_timeout(). So #232 does not matter in that case.
https://github.com/todbot/hidapitester/blob/master/hidapitester.c#L379
With regard to feature report, then the result will be different as it uses hid_get_feature_report(). So commit
github.com/libusb/hidapi@6fcb0bb228does matter for getting the feature report. In this particular case without report id (report id zero), it seems to me the commit is not correct.https://github.com/todbot/hidapitester/blob/master/hidapitester.c#L403
Do you think we need to do the same as we do for macOS?
Yes I think that will fix this issue.
I think this one is worth fixing before releasing v0.11.0
After reading the documentation for
IOCTL_HID_GET_INPUT_REPORTandIOCTL_HID_GET_FEATUREone more time, combined with your test results, I believeinput_reportis as broken asfeature_reportLet me test out #334 over the weekend.
Firstly for feature report for device without report ID.
I think #334 is correct since it reports reading 3 bytes. Release 0.10.1 is actually correct but then
github.com/libusb/hidapi@6fcb0bb228introduced the regression. #334 fixes the issue in the current master.Secondly for devices with report ID. No regression from the current master. Release 0.10.1 is not correct and it was fixed by
github.com/libusb/hidapi@6fcb0bb228.hdiapitester can not be used to test #334 though as it uses hid_read_timeout().
https://github.com/libusb/hidapi/issues/285#issuecomment-907570047
Even though I can not use hidapitester to test the input report, but I agree with you after reading the documentation one more time.
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/hidclass/ni-hidclass-ioctl_hid_get_feature
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/hidclass/ni-hidclass-ioctl_hid_get_input_report