diff options
| author | srdusr <[email protected]> | 2025-03-06 23:13:00 +0200 |
|---|---|---|
| committer | srdusr <[email protected]> | 2025-03-06 23:13:00 +0200 |
| commit | 4c97f8647b9543abefbed3ece209d335de6aa9d6 (patch) | |
| tree | 991fc480f2cb53c30a640a5ab343846542ba36b3 /crates/platform | |
| parent | f83082a3b9b75e6f1bc4187850bea1b7408cffca (diff) | |
| download | srdwm-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/platform')
0 files changed, 0 insertions, 0 deletions