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 clepple@gmail _______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
