<div dir="auto"><div>I did not dig deep into that part of code yet and am a bit vague on USB internals in general, but from your description and data sample it seems the proper solution is to raise a flag upon seeing any of those 3 conditions, and keep processing (looking for?) until nearest "end of collection", and then save (memcpy to process in detail) that whole memory block to have all the context?</div><div dir="auto"><br></div><div dir="auto">I'd love to see comments from the experts, but a PR with developer-tests that it fixes the issue (and commented logic for "future us") would be also great :)</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Jim Klimov</div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, Nov 16, 2021, 17:14 Dave Williams <<a href="mailto:dave@opensourcesolutions.co.uk">dave@opensourcesolutions.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would welcome a little assistance. I am debugging the issue affecting<br>
CyberPower CP*PFCLCD devices as per<br>
<a href="https://github.com/networkupstools/nut/issues/439" rel="noreferrer noreferrer" target="_blank">https://github.com/networkupstools/nut/issues/439</a> and others.<br>
<br>
<br>
The parser HIDParse() in drivers/hidparser.c appears to terminate<br>
processing of a HID report when an INPUT, OUTPUT, or FEATURE item is<br>
encountered (or the data expires) and then saves it for later recall<br>
with a memcpy().<br>
<br>
In the case of the CyberPower HID the FEATURE item that is the normal<br>
trigger is half way through the reports which means that any subsequent<br>
items are not associated with the correct HID report. Worse still any<br>
unprocessed items from the preceding report are used instead.<br>
<br>
Here is an excerpt (from a CP900EPFCLCD) as an example:<br>
<br>
Report ID (16),<br>
...<br>
Usage (54h),<br>
Logical Minimum (260),<br>
Logical Maximum (270),<br>
Feature (Variable, No Preferred, Volatile),<br>
Usage (54h),<br>
Input (Constant, Variable, No Preferred),<br>
End Collection,<br>
Usage (1Ch),<br>
Collection (Physical),<br>
Report ID (18),<br>
Usage (30h),<br>
Feature (Constant, Variable, No Preferred, Volatile),<br>
Report Size (8),<br>
Logical Minimum (0),<br>
Logical Maximum (255)<br>
<br>
LogMin and LogMax items from Report ID 16 (with values 260 and 270) are<br>
associated with reportID 18 not values 0 and 255 as should be the case.<br>
<br>
This results in the erroneous behaviour raised in the GitHub issue.<br>
<br>
The question is "What are the assumptions or requirements of the Parser<br>
and the HID data that the code supports or should support?"<br>
<br>
I understand this may or may not be consistent with the USB Usage Tables for<br>
Power Devices spec but without having any real examples of vendor usb HID's<br>
available it is not possible to work out how to proceed to develop a solution<br>
that doesn't break support for other devices.<br>
<br>
Have I missed something? - As it stands it doesnt seem like a reliable way of<br>
delimiting each report.<br>
<br>
Thanks<br>
Dave<br>
<br>
_______________________________________________<br>
Nut-upsdev mailing list<br>
<a href="mailto:Nut-upsdev@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsdev@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev</a><br>
</blockquote></div></div></div>