Improve report descriptor parsing #18
Conversation
This lifts previously existing restictions on where the button and motion bits can reside within the input reports. The data no longer has to start on byte boundary and doesn't have to be contiguous. Should now work with any report ID.
|
Hi @jfedor2 thanks for all your contributions! I've actually stumbled across your blog a while ago, and found your projects very interesting. Cool to see PRs from you appear here, too. I'll need some time to have a close look at all of them. About this specific PR: have you actually seen any HID descriptors where the button and motion bits are not byte-aligned or non-continuous? I haven't on any of the mice I tested, but maybe you have? It sounds a like weird thing to do. |
|
I don't know about mice, but for example a DualShock 4 has button data starting at bit 4. Gamepads typically have a 4-bit field for the d-pad, so this is natural, depending on the order of fields and willingness to sacrifice bits for padding. Also gamepads often have more than 8 buttons, which the current implementation doesn't support. |
This lifts previously existing restictions on where the button and motion bits can reside within the input reports.
The data no longer has to start on byte boundary and doesn't have to be contiguous.
Should now work with any report ID.