Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report descriptor reconstruction fails on Windows #18

Closed
Joop-Schilder opened this issue Feb 1, 2023 · 2 comments
Closed

Report descriptor reconstruction fails on Windows #18

Joop-Schilder opened this issue Feb 1, 2023 · 2 comments
Labels
bug Something isn't working duplicate This issue or pull request already exists

Comments

@Joop-Schilder
Copy link
Contributor

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 a NotImplementedException. 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.

@benedekkupper
Copy link
Member

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.

@benedekkupper benedekkupper added bug Something isn't working duplicate This issue or pull request already exists labels Feb 1, 2023
@Joop-Schilder
Copy link
Contributor Author

Joop-Schilder commented Feb 2, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working duplicate This issue or pull request already exists
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants