Summary
Stopping inputplumber.service leaves the evdev nodes it had grabbed at mode 000, so the machine is left with no usable pointer at all until they are corrected by hand. The service does not restore them on shutdown, and udevadm trigger does not either.
Environment
- Lenovo Legion Go 2 (
83N0001ALM, Z2 Extreme / 8ASP2)
- CachyOS Handheld, kernel
7.1.8-1-cachyos-deckify
- InputPlumber 0.78.1, stock
50-legion_go_2.yaml, no custom config in /etc/inputplumber
Steps to reproduce
-
Boot with inputplumber.service running. It grabs the controller's evdev nodes and logs:
Blocking input events from /dev/input/event3
Blocking input events from /dev/input/event4
Blocking input events from /dev/input/event5
At this point all three are mode 000, which is expected while the daemon owns them.
-
sudo systemctl stop inputplumber
-
Inspect the same nodes.
Observed
event3 Legion Controller Keyboard 000 -> 660 released
event4 Legion Controller Mouse 000 -> 000 still blocked
event5 Legion Controller Touchpad 000 -> 000 still blocked
event10 Generic X-Box pad 000 -> 060 partially restored
The virtual target devices disappear with the daemon, and the physical mouse and touchpad are still unreachable, so the desktop session has no pointer device left. Only the built-in touchscreen (a device InputPlumber never touched) keeps working.
udevadm trigger --action=change on those nodes does not restore the mode or ownership — udev does not reapply permissions for a change event on an already-present device.
Expected
On shutdown, the daemon should release its grabbed source devices and leave their mode and ownership as it found them (normally 660 root:input), so the system falls back to using them directly.
Workaround
sudo chown root:input /dev/input/event4 /dev/input/event5
sudo chmod 660 /dev/input/event4 /dev/input/event5
Or reboot.
Notes
This may share a root cause with #562 ("Composite Device sources may not fully clean up during /dev reset"), but the trigger is different: that one is about /dev being reset during boot, this one is a plain systemctl stop of the service.
It also makes the "stop inputplumber.service" workaround suggested in #538 and #604 harder to use than it looks: on this device stopping the service leaves you with no pointer until the permissions are fixed manually, and once they are, the touchpad's absolute node is misclassified as a touchscreen — described in my comment on #538.
Investigation assisted by Claude (Opus 5) via Claude Code.
Summary
Stopping
inputplumber.serviceleaves the evdev nodes it had grabbed at mode000, so the machine is left with no usable pointer at all until they are corrected by hand. The service does not restore them on shutdown, andudevadm triggerdoes not either.Environment
83N0001ALM, Z2 Extreme / 8ASP2)7.1.8-1-cachyos-deckify50-legion_go_2.yaml, no custom config in/etc/inputplumberSteps to reproduce
Boot with
inputplumber.servicerunning. It grabs the controller's evdev nodes and logs:At this point all three are mode
000, which is expected while the daemon owns them.sudo systemctl stop inputplumberInspect the same nodes.
Observed
The virtual target devices disappear with the daemon, and the physical mouse and touchpad are still unreachable, so the desktop session has no pointer device left. Only the built-in touchscreen (a device InputPlumber never touched) keeps working.
udevadm trigger --action=changeon those nodes does not restore the mode or ownership — udev does not reapply permissions for achangeevent on an already-present device.Expected
On shutdown, the daemon should release its grabbed source devices and leave their mode and ownership as it found them (normally
660 root:input), so the system falls back to using them directly.Workaround
Or reboot.
Notes
This may share a root cause with #562 ("Composite Device sources may not fully clean up during /dev reset"), but the trigger is different: that one is about
/devbeing reset during boot, this one is a plainsystemctl stopof the service.It also makes the "stop
inputplumber.service" workaround suggested in #538 and #604 harder to use than it looks: on this device stopping the service leaves you with no pointer until the permissions are fixed manually, and once they are, the touchpad's absolute node is misclassified as a touchscreen — described in my comment on #538.Investigation assisted by Claude (Opus 5) via Claude Code.