srdusr
aboutsummaryrefslogtreecommitdiffstats
path: root/crates/wayland/src/udev/mod.rs
diff options
context:
space:
mode:
authorsrdusr <[email protected]>2025-03-06 23:13:00 +0200
committersrdusr <[email protected]>2025-03-06 23:13:00 +0200
commit4c97f8647b9543abefbed3ece209d335de6aa9d6 (patch)
tree991fc480f2cb53c30a640a5ab343846542ba36b3 /crates/wayland/src/udev/mod.rs
parentf83082a3b9b75e6f1bc4187850bea1b7408cffca (diff)
downloadsrdwm-4c97f8647b9543abefbed3ece209d335de6aa9d6.tar.gz
srdwm-4c97f8647b9543abefbed3ece209d335de6aa9d6.zip
Fix total input death after VT switch back (libinput never resumed)
The kernel revokes every input device fd across a VT switch away. libinput has a documented pair of calls for this exact case, suspend()/resume() (libinput_suspend/libinput_resume), which reopen every device through the session once it is reactivated. This codebase never called either one, so after switching back to the compositor's VT, libinput's device list stayed pointed at fds the kernel had already revoked - reads on them don't error, they just silently stop producing events, forever. Rendering, DRM/KMS, and libseat's own session activation all recovered on their own, which is what made this look like a display bug rather than an input one; it took three real forced reboots today, with no visible input from keyboard or mouse for 30+ minutes after switching back to tty1 each time, to isolate it as this specific missing call. register_libinput now returns the Libinput context (a clone of the one already handed to LibinputInputBackend - it's a reference-counted handle, not a deep copy, and LibinputInputBackend only exposes an immutable accessor once it's moved into the calloop event source). register_session_notifier takes that handle and calls suspend() on PauseSession, resume() on ActivateSession.
Diffstat (limited to 'crates/wayland/src/udev/mod.rs')
0 files changed, 0 insertions, 0 deletions