https://bugs.kde.org/show_bug.cgi?id=523463
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from [email protected] --- I'm hitting what looks like the same bug, or at least a close sibling of it, and managed to capture some information while it was actively broken. I also found a recovery that narrows the issue down to device hotplug alone, no physical replug needed. Setup: Dell Precision 7680 with the internal Cirque touchpad (VEN_0488:00 0488:1064, i2c-hid on i2c_designware, /dev/input/event5) Ubuntu 26.04 LTS, kernel 7.0.0-29-generic KWin 6.6.6 Wayland, Qt 6.10.2, libinput 1.31.1 s2idle suspend, triggered by lid close After resume, the touchpad stops moving the cursor. Keyboard still works. One difference from comment 0: in my case the compositor-side cursor position itself is frozen, not just event delivery to clients. I polled the cursor twice a second with kdotool getmouselocation (KWin scripting DBus) and got the exact same pixel (x:701 y:579) for 60 straight samples while actively swiping on the pad. While it was stuck, everything below KWin looked healthy: Kernel resume log was clean. No i2c_hid or i2c_designware errors, and the evdev node was never removed or recreated. A raw capture from /dev/input/event5 showed a normal multitouch stream: BTN_TOUCH / BTN_TOOL_FINGER transitions and distinct ABS_MT_POSITION_X/Y values. Hardware and driver were fine. KWin's own DBus object at /org/kde/KWin/InputDevice/event5 reported enabled=true the whole time. Recovery attempts, in order: Toggling the InputDevice enabled property off and back on over DBus did nothing visible. Creating a virtual pointer through /dev/uinput (an EV_REL device) and emitting some REL_X/REL_Y motion fixed it immediately. The injected motion moved the cursor, and the physical touchpad started working again afterwards. Since nothing was physically unplugged, the recovery trigger has to be the libinput device-added path (or first motion from a new device) inside KWin. That lines up with the USB receiver replug workaround others have mentioned in this bug. -- You are receiving this mail because: You are watching all bug changes.
