hid_get_report_descriptor: missing unnumbered feature report #703
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#703
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?
On some devices, unnumbered feature reports seem omitted from the parsed
HIDP_PREPARSED_DATA. Thehid_pp_caps_infoheader indicates the count and size correctly, but marks it empty/unused.github.com/libusb/hidapi@750bf201ae/windows/hidapi_descriptor_reconstruct.h (L109-L114)If I anyhow print the trailing
phid_pp_capout, it consists entirely of zeros.This is likely an existing bug/undocumented aspect of
HidD_GetPreparsedDataon MS side, and I am unsure if it could be worked around in userspace.HID report descriptor (dumped on Linux with
hid-decode)Full
1532_00A3_0002_0001.pp_dataFull
HIDP_PREPARSED_DATA(Followed by all
0x00untilHID_API_MAX_REPORT_DESCRIPTOR_SIZE)This is a known limitation of the reconstructor: All bits in the feature report are const, and Windows removes any information about const caps during the pre-parsing step. The reconstructor determines these const padding bits from the bit position of the next non-const cap, but this does not work for additional const bytes at the end of the report.
But your example shows that in this particular case there is the possibility, to improve this. While we have no information about additional const bytes for a particular report, Windows tells us the needed buffer size for input, output and feature reports. This is the size of the largest report + one byte. In case of devices that don't use ReportIDs, we know that there can be only one report of each type. So we could determine the number of additional const bytes at the end of the report from hid_pp_caps_info->ReportByteLength.
@SuibianP would you be able to check if #707 brings any improvement for your case?
@Youw Tried dumping from the device just now and
hid_report_reconstructor_testadds the last const report correctly. Usage page and usage are gone for good as expected.@JoergAtGithub Thanks for the implementation!