search for: hiddumptree

Arnaud, you changed the "if" part, perhaps you'd like to change the "else" part, too? Changing the output format of HIDDumpTree() has the potential to break the functionality of scripts/subdriver/path-to-subdriver.sh; I don't think it does in this instance, but I have not checked it. Perhaps it would be good to add a comment in the source code as a caution. -- Peter Arnaud Quette wrote: > > Author: aquette >...

...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 at gmail

...Summary.PresentStatus.00000000, Type: Input, ReportID: 0x32, Offset: 0, Size: 1, Value: 0.000000 NUT doesn't use this HID object The 'Path' reported here looks like this (one bit) variable isn't used. Of the possible 24 bit positions in this report, only 9 appear in the output from HIDDumpTree(). After a lot of head scratching, I found out that paths with more than six consecutive zero's in the hexadecimal notation of the node number in them (anywhere in the path) are disregarded by the HIDDumpTree() debugging function (see below). /* FIXME: enhance this or fix/change the HID parser...

...01, /* HID_REPORT_GET */ ReportId+(0x03<<8), /* HID_REPORT_TYPE_FEATURE */ 0, raw_buf, ReportSize, USB_TIMEOUT); Hence, libusb_get_report() always requests the report ID as a feature report, and never uses the report type that was stored. This means that when HIDDumpTree() iterates over all reports that were gathered from in the USB report descriptor, it tries to obtain their values irrespective of whether they are input, output or feature reports as if they were all feature reports. The USB HID specification says: Input items define input reports accessible via...

...on-feature report IDs as feature IDs may lead to undesirable results and errors. --- drivers/libhid.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/libhid.c b/drivers/libhid.c index f6ec644..1cec74a 100644 --- a/drivers/libhid.c +++ b/drivers/libhid.c @@ -301,6 +301,13 @@ void HIDDumpTree(hid_dev_handle_t udev, usage_tables_t *utab) continue; } #else + /* Skip non-feature reports, primarily for OpenUPS - but + * as HIDGetItemData() only cares about feature items, + * do it for all. + */ + if (pData->Type != ITEM_FEATURE) + continue; + if ((vendorID == 0x0463)...

Hi Arjen, thanks for today's changes to usbhid-ups. These are very sensible changes and were long overdue. It was of course suboptimal to parse the usage strings each time, rather than doing it once and putting them in a data structure. I am beginning to believe that when you are finished, usbhid-ups will actually be (gasp) elegant! The difference between Features and Inputs has been on my

Hi, I've been checking out NUT with an OpenUPS board over the last couple of weekends, and have noticed that it doesn't seem to report sensible values. This lead me to investigate usbhid-ups and delve into various issues. As mentioned in a github issue, one of the problems is with the report descriptor - dumping this from the usbhid-ups debug output and picking through it reveals that

...arser bug (before and after fixing it). Note that after the places marked ###, the parser shifts all Usages by one, which mangles the tree. This bug is fixed in nut-cvs-patch-PARSER-2005-08-24. ---------------------------------------------------------------------- Before fixing the HIDParser bug: HIDDumpTree... Path: UPS.PowerSummary.iSerialNumber Path: UPS.PowerSummary.iDeviceChemistry Path: UPS.PowerSummary.iOEMInformation Path: UPS.PowerSummary.Rechargeable Path: UPS.PowerSummary.APCStatusFlag Path: UPS.PowerSummary.APCStatusFlag Path: UPS.PowerSummary.ManufacturerDate Path: UPS.PowerSummary.Config...