[Nut-upsdev] [nut-commits] svn commit r1210 - in trunk: . drivers

[Arjen de Korte]

> I agree with the rest of your logic about complexity, but they are
> less like placeholders, and more like bugs in the parser. A common
> idiom in HID report descriptors is to have an array of bytes or
> bitstrings, and the hidparser code tends to show the first array
> element properly, then it prints several duplicates of the first
> element with 0x00000000 instead of the last usage ID.

Question is, is this worth to be fixed? Even if it used the last usage ID,
this would mean that we'll have a one (HID path) to many (values) mapping.
Correct me if I'm wrong, but it doesn't make a whole lot of difference if
we have

Path: UPS.PowerSummary.PresentStatus.WhatEver, Type: Input, ReportID: 0x32,
Offset: 0, Size: 1, Value: 0.000000
Path: UPS.PowerSummary.PresentStatus.00000000, Type: Input, ReportID: 0x32,
Offset: 1, Size: 1, Value: 0.000000
Path: UPS.PowerSummary.PresentStatus.00000000, Type: Input, ReportID: 0x32,
Offset: 2, Size: 1, Value: 0.000000
Path: UPS.PowerSummary.PresentStatus.00000000, Type: Input, ReportID: 0x32,
Offset: 3, Size: 1, Value: 0.000000

or

Path: UPS.PowerSummary.PresentStatus.WhatEver, Type: Input, ReportID: 0x32,
Offset: 0, Size: 1, Value: 0.000000
Path: UPS.PowerSummary.PresentStatus.WhatEver, Type: Input, ReportID: 0x32,
Offset: 1, Size: 1, Value: 0.000000
Path: UPS.PowerSummary.PresentStatus.WhatEver, Type: Input, ReportID: 0x32,
Offset: 2, Size: 1, Value: 0.000000
Path: UPS.PowerSummary.PresentStatus.WhatEver, Type: Input, ReportID: 0x32,
Offset: 3, Size: 1, Value: 0.000000

In both cases, whatever these reports are pointing at, they are not of any
use (we'd only use the first one that matches).

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57