On Feb 16, 2018, at 6:55 AM, Russell King wrote: > > Hence, libusb_get_report() always requests the report ID as a feature > report, and never uses the report type that was stored. > My apologies. I saw the HIDData_t pointer (with its report type field) getting passed down to HIDGetItemData(), and did not look much further down the tree. Thank you for your patience in explaining this.
Side note: we have been trying to make sure that all of the libusb code works with libusb 1.0 as well as 0.1. I will probably merge these commits to master, which is currently 0.1-only, after doing a quick test merge to the 0.1+1.0 branch, while this discussion is fresh in my mind. >> 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. [snipping out my incorrect assumptions about HIDDumpTree's callees] > > So, if we want to read input items, then we should at the very least > request them using input reports rather than feature reports. I guess this is the part that I didn't want to just paper over without a bit more explanation. It is entirely possible for a broken UPS to have different values for the Input and Feature versions of a given Usage, so that is something I would like the HIDDumpTree() function to show (even though we currently always fetch the feature report via EP0). I'll create an issue so we don't forget about that later, but in the mean time, I might fold in some of this discussion into the code comments. _______________________________________________ Nut-upsdev mailing list Nut-upsdev@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
