[Bug 221774] New: hid-multitouch: report ID mismatch check breaks touchpad palm detection on ASUS ROG Flow Z13 (2025) GZ302EA (0b05:1a30)

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221774

            Bug ID: 221774
           Summary: hid-multitouch: report ID mismatch check breaks
                    touchpad palm detection on ASUS ROG Flow Z13 (2025)
                    GZ302EA (0b05:1a30)
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: drivers_usb@kernel-bugs.kernel.org
          Reporter: mayhemandcoffee@gmail.com
        Regression: No

Created attachment 310482
  --> https://bugzilla.kernel.org/attachment.cgi?id=310482&action=edit
touch registers while typing

Component: Drivers / Input Devices (or USB, whichever's closest)

Kernel Version: 7.1.4-arch1-1 (regression); confirmed working on 6.18.39-1-lts

Description:

On the ASUS ROG Flow Z13 (2025), model GZ302EA, the detachable keyboard cover's
touchpad (USB 0b05:1a30) loses its onboard palm-detection capability on kernels
containing commit e716edafedad4952fe3a4a273d2e039a84e8681a ("HID: multitouch:
Check to ensure report responses match the request").

dmesg shows:

hid-multitouch 0003:0B05:1A30.0004: Returned feature report did not match the
request

Effect: the touchpad falls back to a legacy single-touch-style report — missing
ABS_MT_SLOT, ABS_MT_TOOL_TYPE, and multi-finger BTN_TOOL_* capabilities —
instead of the full Precision Touchpad protocol. This means palm rejection
stops working entirely in userspace (libinput has no tool-type/slot data to
reject a palm contact with).

Working baseline: on linux-lts 6.18.39 (predates the commit), evtest on the
touchpad node shows the full protocol, including ABS_MT_TOOL_TYPE correctly
reporting value 2 (MT_TOOL_PALM) when a palm contact is detected, and 0
(MT_TOOL_FINGER) for normal touches.

Suspected root cause: in mt_feature_mapping(), the vendor-specific usage
0xff0000c5 triggers a mt_get_feature() call described in the driver source as
"Retrieve the Win8 blob once to enable some devices." This device's firmware
appears to respond to that specific GET_FEATURE request with a mismatched
report ID, causing the new check to goto free and abort before the device gets
switched into its full-capability reporting mode.

Steps to reproduce:

Boot a kernel containing commit e716edafedad4952fe3a4a273d2e039a84e8681a
sudo evtest on the touchpad's /dev/input/eventN node
Observe missing ABS_MT_SLOT / ABS_MT_TOOL_TYPE in the capabilities list, and
dmesg | grep hid-multitouch showing the mismatch error

Requested fix: a vendor/product-ID based quirk in hid-multitouch.c (similar to
the existing MT_CLS_ASUS handling) to bypass or tolerate the report-ID mismatch
for 0b05:1a30, restoring the device to full-capability mode.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.