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

On 9/18/26 7:18 PM, Benjamin Tissoires wrote:

On Sep 17 2026, Ruzal wrote:

quoted

On 9/17/26 10:30 AM, Benjamin Tissoires wrote:

quoted

Hi,

sorry it looks like this one fell through the cracks.

On Aug 19 2026, Ruzal Daminov wrote:

quoted

The Goodix GXTP7863 touchpad controller (VID: 0x27c6, PID: 0x01e0)
found on Honor MagicBook laptops (e.g. FMI-76 / X14 Plus)
was missing from the mt_devices[] table.

[...]

quoted

quoted

quoted

 
+	/* Goodix GXTP7863 Touchpad */
+	{ .driver_data = MT_CLS_WIN_8,
+	  HID_DEVICE(BUS_I2C, HID_GROUP_ANY, I2C_VENDOR_ID_GOODIX,

I'm puzzled here: HID_GROUP_ANY? How can this even be working with hid-multitouch?

Are you sure the touchpad part is not already handled by hid-multitouch, but only
the telemetry/phantom event gets assigned to hid-generic?

Can you share the report descriptors of all nodes with hid-recorder so I
can understand why we suddenly have to map to non multitouch devices.

Cheers,
Benjamin

Hi Benjamin,

Thanks for pointing that out. You were completely right, and I apologize
for the inaccurate explanation in my previous commit messages.

no need to apologize, we can make mistakes, and that's our job as
maintainers to catch them :)

quoted

I re-checked the device binding: the touchpad is indeed claimed by
hid-multitouch out of the box under HID_GROUP_MULTITOUCH_WIN_8 (using
MT_CLS_WIN_8). It was never claimed by hid-generic.

Well, I guess it was the first time you started the laptop, until
hid-multitouch gets loaded.

quoted

The actual root cause is that MT_CLS_WIN_8 sets `.export_all_inputs = true`.
Because of this, hid-multitouch exports the vendor application collection
(Usage Page 0xFF01, Usage 0x01, Report ID 8) to an input node.

Actually, it's even worse than that.

Because some vendors are not using standard HID usages, we do have a
`HID_UP_HPVENDOR2` definition of (Usage Page 0xFF01). And hid-input.c
considers that this is only used by HP laptops/keyboards, and then we
have some fancy mapping of non standard usages.

The real fix would be to actually ensure this mapping is only triggered
for:
- keyboards
- HP platforms

But, there is always a but, `HID_UP_HPVENDOR` was there since the origin
of time (git conversion IIRC), and `HID_UP_HPVENDOR2` appeared in 2012.

We do have some info on the affected devices (VID/PID) but nothing else
like the report descriptor. So it's the typical case of "damn, we can't
fix this without possibly regressing a lot of existing hardware".

quoted

As captured in the hid-recorder trace below, the firmware sends a 1-Hz
heartbeat packet on Report ID 8:
  E: 000000.000000 30 08 ab 00 00 2a ...
  E: 000001.006503 30 08 ab 00 00 2a ...
  E: 000002.012748 30 08 ab 00 00 2a ...

hid-input interprets these changing payload bytes as key events, resulting
in the endless KEY_BRIGHTNESSUP autorepeat loop.

So, adding the device entry with HID_GROUP_ANY to mt_devices[] is indeed
completely redundant. The only thing needed is to ignore the 0xFF01 vendor
collection so that no phantom input node is created for it.

Here is the report descriptor and event recording from hid-recorder:

# GXTP7863:00 27C6:01E0
# 0x05, 0x01,                    // Usage Page (Generic Desktop)        0
# 0x09, 0x02,                    // Usage (Mouse)                       2

[...]

quoted

# 0xc0,                          // End Collection                      624
# 0x06, 0x01, 0xff,              // Usage Page (Vendor Usage Page 0xff01) 625
# 0x09, 0x01,                    // Usage (Vendor Usage 0x01)           628
# 0xa1, 0x01,                    // Collection (Application)            630
# 0x85, 0x08,                    //  Report ID (8)                      632
# 0x09, 0x01,                    //  Usage (Vendor Usage 0x01)          634
# 0x19, 0x00,                    //  Usage Minimum (0)                  636
# 0x29, 0xff,                    //  Usage Maximum (255)                638
# 0x15, 0x00,                    //  Logical Minimum (0)                640
# 0x25, 0xff,                    //  Logical Maximum (255)              642
# 0x95, 0x40,                    //  Report Count (64)                  644
# 0x75, 0x08,                    //  Report Size (8)                    646
# 0x91, 0x02,                    //  Output (Data,Var,Abs)              648
# 0x09, 0x01,                    //  Usage (Vendor Usage 0x01)          650
# 0x19, 0x00,                    //  Usage Minimum (0)                  652

Technically, we could simply convert these 0x01 and 0x00 into 0x05 and
this would make the mapping ignored by hid-input.c

However, when changing those bytes in the hid-recorder output and
replaying the device this creates a 10 seconds freeze on my desktop
because some component is not happy about the empty input node it creates.

I'm trying to investigate what is going on, without much success. I'll
continue working on it on Monday.

quoted

# 0x29, 0xff,                    //  Usage Maximum (255)                654
# 0x15, 0x00,                    //  Logical Minimum (0)                656
# 0x25, 0xff,                    //  Logical Maximum (255)              658
# 0x95, 0x1d,                    //  Report Count (29)                  660
# 0x81, 0x02,                    //  Input (Data,Var,Abs)               662
# 0xc0,                          // End Collection                      664

[...]

quoted

Would you prefer handling this by simply dropping the 0xff010001 collection
in mt_input_mapping() in hid-multitouch, or should this device quirk be
implemented via HID-BPF instead?

So:
- mt_input_mapping() in hid-multitouch -> probably not. Having such
  quirk in the hid-multitouch code would be better handled with a proper
  quirk, not a random check in mt_input_mapping().
- HID-BPF: so far, if it weren't for that 10s freeze, I would have said
  yes, go for it. But right now there is something fishy in the code
  that creates empty input devices that are not properly cleaned up by
  hid-input and that messes up userspace.
 
Ideally we should fix the generic mapping, but that has a strong chance
of regressing existing HW, which is a PITA.

And to add to the bucket, when replaying your device, I see that fwupd
is trying to communicate with the device, so we should be sure to not
break this as well :(

Hopefully I'll have a better understanding next week.

Cheers,
Benjamin

Hi Benjamin,

I did some testing to investigate the freeze you
experienced.

I tried two different descriptor modifications to see how userspace reacts:

1. Test A (Your approach: changing Usage Page 0xFF01 to 0xFF05):
   Changing the usage page indeed strips the keyboard keys
   (KEY_BRIGHTNESSUP/DOWN disappear), but hid-input still registers the
   third input node ("GXTP7863:00 27C6:01E0 UNKNOWN").

   Checking /proc/bus/input/devices during the replay shows that this node
   is created with an anomalous capability set:
     N: Name="GXTP7863:00 27C6:01E0 UNKNOWN"
     H: Handlers=event15
     B: PROP=0
     B: EV=9 (EV_SYN | EV_ABS)
     B: ABS=10000000000 (ABS_MISC only, zero keys, no X/Y axes)

   This triggered the desktop freeze for ~15 seconds until the timeout
   expired and the system recovered.

2. Test B (Changing the 29-byte payload to Constant/Padding):
   I also tried keeping the original Usage Page 0xFF01 but changing
   `Input (Data,Var,Abs)` (0x81, 0x02) to `Input (Cnst,Var,Abs)` (0x81, 0x03)
   in Report ID 8, hoping hid-input would ignore the fields.

   Running `libinput debug-events` during this test captured the exact
   watchdog trace during the stall:
     event13  DEVICE_ADDED                 GXTP7863:00 27C6:01E0 Mouse
     client bug: timer event6 keyboard: scheduled expiry is in the past (-14747ms), your system is too slow
     client bug: timer event6 hold: scheduled expiry is in the past (-14396ms), your system is too slow
     client bug: timer event6 hold: scheduled expiry is in the past (-14389ms), your system is too slow
     client bug: timer event6 hold: scheduled expiry is in the past (-14369ms), your system is too slow
     event14  DEVICE_ADDED                 GXTP7863:00 27C6:01E0 Touchpad

   libinput explicitly confirms that the compositor's event loop was
   completely blocked for 14,747 ms (~15 seconds) during enumeration.
   Notice that the third node (UNKNOWN) is never even announced as
   DEVICE_ADDED.

Conclusion:
Both descriptor-level approaches confirm what you suspected: modifying the
descriptor still leaves the application collection instantiated as an empty/
broken input node, which trips up libinput and blocks the compositor event
loop for ~15 seconds.

Hope this empirical data helps you track down the hid-input cleanup issue on
Monday!

Cheers,
Ruzal