fix: no longer input locks when TTY is switched before full compositor#3593
fix: no longer input locks when TTY is switched before full compositor#3593Atan-D-RP4 wants to merge 1 commit intoniri-wm:mainfrom
Conversation
|
Do other compositors do something similar? |
|
I can only confirm that Hyprland has the same problem, from my own experience and testing for this. From what I can tell, both Mutter and Kwin use systemd-logind to manage inactive VT and defer input processing until it sends active session signal to them. |
That's also what niri does |
|
Maybe it doesn't do so at startup? Does mutter also call libinput suspend at startup? |
I checked and no it does not. Which might be why it also has this same issue, from my testing. |
|
Huh. I want to be careful here then if this is a bit of an uncharted ground. Perhaps a better solution is, when the session is inactive at startup, call |
f723854 to
2673383
Compare
Seems to be the case, though I don't know why. Do devs not use separate TTY during development? I ran into this right away when I started hacking on Niri. Anyway, now using |
|
Any reason for using an idle rather than calling it in init()? |
|
I didn't know better. I've played around with the |
2673383 to
f723854
Compare
This fixes the case of starting Niri from a separate TTY (via Tmux or a TTY switch before full startup) and then switching to that Niri session causing an input lock.
I hack on Niri mostly in separate TTY and this behavior was a super annoying blocker. Resolving it required either restarting my computer (since all input was blocked) or
sshing into my machine and killing that Niri session.