Re: [GIT PULL] HID for 5.7

[Samuel Äavoj]

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