Possibly incorrect expectations on hid_get_feature_report

[jonasmalacofilho]

When looking into libusb/hidapi#229, I noticed that the behavior of hid_get_feature_report when report IDs are not used is not as clear as I thought, and perhaps not even well defined.

This doesn't currently affect any of our drivers, but it's different than the expectations that are documented in HidapiDevice.get_feature_report (and asserted in test_gets_feature_report).

For now, let's just follow how this is resolved in hidapi, and proceed from there.

Additional information about the system:

• Affected device: none at the moment
• Operating system: undetermined
• Liquidctl version: HEAD

Related: libusb/hidapi#229 Related: libusb/hidapi#232

[jonasmalacofilho]

Actually, the bug appears to be in hidraw's documentation:

• HIDIOCGFEATURE simply calls hidraw_get_report() ^1
• ... which calls hid_hw_raw_request() ^2
• ... which calls the low level driver's raw_request() ^3
• ... which, in the case of USB HIDs, calls usbhid_get_raw_report() ^4
• ... which ensures that byte 0 will be the report number (or zero) ^5

It is possible that other types of HIDs behave differently, but that would still mean a bug in the kernel (in that case, in the actual code, not just in the documentation).

Leaving this open until I report (or maybe fix) it upstream.