Messages in this thread |  | | Date | Sun, 10 May 2020 01:12:39 +0200 | From | Samuel Čavoj <> | Subject | Re: [GIT PULL] HID for 5.7 |
| |
On 03.04.2020 12:05, Jiri Kosina wrote: > It would still be possible to access the report via hidraw, and maybe > that's analogy of what the Windows driver/special Glorious software :) > does, I don't know. It's hard to believe that Windows would be actually > willing to report any changes coming through HID_MAIN_ITEM_CONSTANT > reports, but who knows.
I did some research of what other HID implementations do in this situation and would like to share it here.
Windows, as we already know, does not seem to mind the CONST flag and accepts the reports just fine. Of course, whether this is the general behaviour or only a special case, we can only speculate, short of emulating devices with the descriptors incorrect in some way or another, either in software or with some sort of microcontroller. I haven't yet set out to do this, but I might eventually.
macOS (tested a 10.13 hackintosh) accepts the reports just fine. This platform is an interesting case, because Apple's HID stack is open-source. Assuming I understand the code correctly, the logic which filters out padding is found in HIDIsButtonOrValue.c of the IOHIDFamily component. The file can be found here[1]. The author(?) helpfully provides a description in the changelog:
11/1/99 BWS [2405720] We need a better check for 'bit padding' items, rather than just is constant. We will check to make sure the item is constant, and has no usage, or zero usage.
I am not particularly well-versed in HID, but this sounds like a reasonable solution. Is there anything preventing this approach in Linux? While doing the initial research when I was working on the original patch, I noticed some code was purposefully setting the CONST flag in order to get reports ignored. Food for thought, especially for someone who knows what they are doing, unlike me :D
FreeBSD, to my limited knowledge, only includes a basic HID driver in the kernel, capable of boot protocol mice and keyboards. There is a userspace daemon, uhidd, which grabs the raw ugen device and submits keycodes to a virtual keyboard (or mouse) with more comprehensive support for consumer control and such. It ignores the reports as can be seen on L318 of uhidd_cc.c [2].
I don't currently have access to other platforms, although I don't even know of any with a comprehensive HID implementation. Maybe game consoles?
Of course, I am not sure this is worth the effort in the first place, I was just curious. Also, not sure if I mentioned this before, I reached out to the hardware manufacturer about this issue, they haven't responded. Not a surprise.
Sam
[1]: https://opensource.apple.com/source/IOHIDFamily/IOHIDFamily-1446.61.2/IOHIDSystem/IOHIDDescriptorParser/ [2]: https://github.com/kaiwang27/uhidd/blob/master/uhidd/uhidd_cc.c#L318
|  |