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).

Charles Lepple

Nut-upsdev mailing list

Reply via email to