On Feb 3, 2018, at 7:19 PM, Russell King wrote:
> Input and Output reports are used for interrupt endpoints rather than
> control endpoints. HIDGetItemData() only ever requests feature
> report IDs, and requesting non-feature report IDs as feature IDs may
> lead to undesirable results and errors.
This one made me scratch my head a bit.
I don't think it's unreasonable to send a control request for an Input report
value-- it seems to be the recommended way for a host to fetch the initial
value (before the device sends updates over the interrupt pipe).
Also, HIDGetItemData() searches the parsed descriptor to match the type as well
as the Usage path, so I'm not sure if I can figure out a way that it would get
an Input report ID confused with a Feature report ID (unless interrupt_only is
set, as it is for powercom devices).
That said, if I am overlooking a case where that might happen, I think we might
need to put this check somewhere deeper in the call tree. HIDDumpTree() is
effectively a NOP if debugging is not enabled, so this is mostly just removing
some partially redundant information from the debug output (redundant in that
most descriptors have both Input and Feature entries for the same Usage IDs).
Nut-upsdev mailing list