Below is an excerpt from the debug output for a Tripplite UPS:
HIDGetEvents: too many events (truncated)
Got 16 HID objects...
Report[get]: (4 bytes) => 32 00 00 09
Path: UPS.PowerSummary.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 (see libhid project) */
if (strstr(path, "000000") != NULL) {
continue;
}
Would there be anything against skipping these reports while parsing the
report descriptor, instead of ignoring them in HIDDumpTree()? In theory,
this might break subdrivers where the nodes 0x000000??, 0x?000000? and
0x??000000 are used, but so far I have not seen any that does (if it is
allowed at all). For the moment, I think skipping reports that end in node
0x00000000 (0) is sufficient.
Best regards, Arjen
--
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B 7A FE 7E C1 EE 88 BC 57
