Touchpad pointer dies after resume on linux-omarchy 7.2.8-9: hid-multitouch reports every contact as tool-palm, so libinput drops all pointer motion (clicks + touchscreen unaffected)

System details

Lenovo Yoga C940-14IIL (model 81Q9), Intel — Omarchy 4.0.6-1, linux-omarchy 7.2.8-9-omarchy (upgraded 7.2.5-3 → 7.2.8-9 at 00:32 on 2026-10-21), Hyprland 0.56.2 / aquamarine 0.15.1, libinput 1.32.0-1

Touchpad: SYNA2B31:00 06CB:CD3E (Synaptics I2C-HID) on i2c-SYNA2B31:00, Intel DesignWare i2c-1, driver chain i2c_hid_acpi → hid-multitouch, exporting event7 ("Mouse") + event8 ("Touchpad"). The touchscreen is a separate device (i2c-WCOM51E2:00, Wacom) and is unaffected throughout.

What's wrong?

After resuming from suspend, the trackpad clicks but never moves the pointer. The touchscreen keeps working normally. A rebind of just this one device fixes it instantly, and nothing runs one on resume.

Root cause is at the tool-type level: hid-multitouch hands libinput MT_TOOL_PALM for 100% of contacts, so libinput palm-rejects every touch and suppresses pointer motion. Button events bypass palm rejection, which is why clicks still register — that asymmetry is the giveaway.

Evidence from hyprctl rollinglog while the pad was broken:

DEBUG from aquamarine ]: [libinput] event8  - palm: touch 0 (TOUCH_BEGIN), palm detected (tool-palm)
DEBUG from aquamarine ]: [libinput] event8  - button state: touch 0 from BUTTON_STATE_NONE event BUTTON_EVENT_IN_AREA to BUTTON_STATE_AREA
DEBUG from aquamarine ]: [libinput] event8  - palm: touch 0 (TOUCH_END), palm detected (tool-palm)

Tally: 7 TOUCH_BEGIN, 15 palm detected, 0 accepted touches — every one tool-palm. The tool-palm source tag means the tool type came from the kernel rather than libinput's size/edge heuristics (palm detected (edge), palm detected (size exceeded) are the other tags), so this is the kernel reporting the contact as a palm, not libinput guessing.

Cursor position sampled every 0.5 s with hyprctl cursorpos:

GESTURE_EVENT_POINTER_MOTION_START → GESTURE_STATE_POINTER_MOTION reappears in the log immediately after the rebind, with zero further palm events.

Timeline

• 00:32 — linux-omarchy upgraded 7.2.5-3 → 7.2.8-9
• 16:15:08 — suspended
• 19:53:15 — resumed (PM: suspend exit); no i2c_hid / i2c_hid_acpi / hid-multitouch errors in the journal, at any point in the boot
• ~20:07 — trackpad found dead, touchscreen fine
• 20:08:57 — targeted rebind, immediate recovery

Steps to reproduce

1. Boot linux-omarchy 7.2.8-9
2. systemctl suspend, wait, resume
3. Move one finger on the trackpad → cursor does not move; physical click still works
4. hyprctl rollinglog | grep palm → repeating palm detected (tool-palm) on event8
5. Rebind (below) → pointer movement returns immediately

Fix (manual, run by hand after resume)

echo i2c-SYNA2B31:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/unbind
echo i2c-SYNA2B31:00 | sudo tee /sys/bus/i2c/drivers/i2c_hid_acpi/bind

Notes

• omarchy restart trackpad also recovers it, but it unbinds every device under i2c_hid_acpi — here that also resets the touchscreen (i2c-WCOM51E2:00). A device-scoped hook in the shape of PR #10926 fits better.
• Per @omarchybot on #12409, shipped sleep hooks don't touch input devices, and post hooks ran too early for that pad — a settle delay would presumably be needed here too.
• This answers @jandrusk's question on #12409: yes, still reproducible on current linux-omarchy 7.2.8-9.
• Same "kernel looks healthy" confusion as #12409: no errors anywhere in journalctl, device stays bound, both input nodes stay present with full capability sets.
• Not yet A/B-tested against stock linux — it isn't installed on this box. Happy to pacman -S linux, repeat the suspend/resume cycle and report back if that would isolate this build from upstream. (#12181 did exactly that for its regression.)
• Incidental: libinput debug-events needs libinput-tools, which isn't installed here, so hyprctl rollinglog was the diagnostic path.

Related

• #12409 — same vendor (06CB), same i2c_hid_acpi → hid-multitouch chain, same "manual reseat fixes it, nothing runs one on resume" conclusion — but the inverse symptom: there multitouch dies while pointer motion survives, here pointer motion dies while clicks survive.
• #10924 + PR #10926 — tested sleep-hook workaround scoped to a single I2C HID device
• PR #5453 — same pattern for Razer 06CB:CDA3
• #12181 — linux-omarchy touchpad regression, A/B-tested against stock linux