Closed Joop-Schilder closed 1 year ago
Hi! Thanks for the very detailed report and analysis! I appreciate the time you take to look into these issues. I am aware that the Windows report parsing is not implemented correctly, this is already reported in #15. Please capture the USB communication with WireShark or equivalent, and post the offending raw report descriptors, so any fixes can be verified.
Hi! I have posted the report descriptor of the device in the other issue #15 . I see you marked this as duplicate, I can see why. I thought you might want to keep the other issue for collecting report descriptors which HidSharp fails to parse. I figured since I don't know wether my proposed changes fix the issue for all the devices I'd better open a new issue.
Unfortunately I do not have enough time to really dive into the report parsing logic for HidSharp on Windows so these "ignore unusable stuff" fixes will have to do for us for now.
Description
While developing with HidSharp on Windows, we encountered an issue where parsing the report descriptor of certain devices would fail with a
NotSupportedException
or aNotImplementedException
. This renders the device unaccessible with HidSharp.Two parts
This issue consists of two parts.
1. The report descriptor contains overlapping report items.
Appearantly on some devices constructing the report descriptor fails (specifically on Windows) because HidSharp notices some report items overlap. HidSharp throws an exception - leaving us with no way to access the device through HidSharp. By ignoring (discarding) overlapping sections, we get HidSharp to somewhat succesfully parse a report descriptor. This leads to a second issue when using a HidDeviceInputReceiver and a DeviceItemInputParser.
2. The report descriptor contains device items with usage index 0.
Some items in the report descriptor have usage index 0. This might be due to the aforementioned fix. This means the usage can not effectively be interpreted by the software. What's more is that on some devices, these inputs with usage index 0 produce periodically changing values (seemingly at random), leading the DeviceItemInputParser to think an input has changed while it has not. By ignoring report items with usage index 0, we only get valid usable reports.
The fix
The fix has been mentioned in the previous section - we should discard overlapping report items as well as usages with a usage index of 0 (undefined?). This has to be done while initially parsing the device report descriptor and while parsing input reports with this descriptor from the device.
An implementation of this fix will follow.