Re: [PATCH v4] HID: multitouch: add support for Goodix GXTP7863 touchpad

[Ruzal <daminovruzal7@gmail.com>]

On 9/22/26 4:24 PM, Benjamin Tissoires wrote:
> Actually, after a lot of debugging, it turns out that the session stall
> was a red herring: it's hid-replay's behavior which basically only
> listen for SET_REPORT events before it is ready, but then ignores
> everything else.
> 
> And in the case where the UNKNOWN input node didn't have the KEY_*,
> systemd-logind would not keep the hid node opened, and would further
> re-open it, 3 times, and 3 times we have a timeout of 5 seconds due to
> uhid not responding to SET_REPORT.
> 
> TL;DR: changing the report descriptor is doable, and there won't be this
> session lock with a real device.
> 
> Regarding the `map_abs(ABS_MISC)`, you are almost correct. The solution
> is simply to not use an unknown vendor usage. the second vendor
> collection is 0xff00, which matches HID_UP_MSVENDOR which goes to
> ignore.
> 
> So making the 0xff01 bogus collection 0xff09 (HID_UP_LOGIVENDOR2) or any
> other HID_UP_LOGIVENDOR* also goes to ignore, and the phantom node just
> disappears.
> 
> And TL;DR of rest, changing the usage page of the report ID 8 from
> 0xff01 to 0xff09 solves the problem entirely :)
> 
> 
> Thanks for this attempt, however, this is not great because there are
> multiple checks for MT_CLS_WIN_8 throughout the code, and so your patch
> misses them.
> 
> It is not great to have a BPF to work around a kernel bug, but in that
> case I think that's the most sensible thing to do. A proper fix is to
> restrict the parsing of 0xff01 for non keyboards or for non HP machines,
> but as mentioned previously, this is prone to regressions :(
> 
> Also, I've just checked the fwupd sources, and I think changing the
> vendor collection is fine. Hopefully this won't break any user space
> program, but OTOH the touchpad is pretty unusable at the moment.
> 
> Cheers,
> Benjamin
Hi Benjamin,

Got it, the uhid SET_REPORT explanation makes a lot of sense.

Are you already working on the BPF fixup, or should I write it and open a merge request in the udev-hid-bpf repo?

I can test it anytime.

Cheers,
Ruzal