The possibility to change to a different TTY when the compositor in unresponsive to keyboard presses

[maxigaz]

While I was using sway, now and again, I would run into an issue: after my monitor was turned off through swayidle, it would refuse to turn on in spite of any mouse or keyboard input. This seems to be a long-standing issue with no fix yet. Whenever this happened, I could only do a hard reset or log in through SSH and initiate a reboot from there (provided the SSH server was running, which I generally didn't and still don't want to do on this PC if possible).

Today, the same thing happened with scroll. However, this time, before thinking of doing a hard reset as a last resort, I tried pressing Ctrl + Alt + F2 so that maybe I could switch to TTY2 and do something there. To my surprise, it made the monitor wake up and everything became functional! Then, I tried switching back to TTY1 by pressing Ctrl + Alt + F1. It also worked, so I could continue the scroll session from where I left off!

Has anything changed recently in wlroots or sway, and by extension, scroll in this regard? In other words, in case the compositor doesn't react to any input due to an error, is it now expected to be able to to use various low-level keyboard shortcuts like switching TTYs on Linux?

[dawsers]

I really couldn't say. If your screen was locked, then, there were some changes to what kind of input should the compositor accept when the screen is locked.

If it was just a matter of the monitor being off, then input should work unless your monitor also drives the USB port for the keyboard. So pressing a key combination that changes graphics mode (like when switching to a TTY) could wake your monitor up.

I haven't had the monitor problem with swayidle yet, but I use Ctrl+Alt+FX frequently, and it works.

In case it helps, these are my configurations for swayidle and swaylock:

In ~/.config/scroll/config

exec swayidle -w

set $lock_cmd "pidof swaylock || swaylock"
bindsym $mod+l exec $lock_cmd

~/.config/swayidle/config

timeout 600 'swaylock -f'
timeout 605 'scrollmsg "output * power off"' resume 'scrollmsg "output * power on"'
timeout 30 'if pgrep swaylock; then scrollmsg "output * power off"; fi' resume 'if pgrep swaylock; then scrollmsg "output * power on"; fi'
before-sleep 'swaylock -f'
lock 'swaylock -f; sleep 5s; scrollmsg "output * power off"'

~/.config/swayilock/config

daemonize
show-failed-attempts
color=000000
ignore-empty-password

[maxigaz]

I forgot to mention my ~/.config/scroll/config. Here's the relevant part:

exec swayidle -w \
         timeout 1800 'swaymsg "output VGA-1 dpms off"' \
              resume 'swaymsg "output VGA-1 dpms on"'

(I'll replace swaymsg with scrollmsg and also move the event steps into ~/.config/swayidle/config.)

The output is specified by name so that out of my two displays, only one of them is switched off automatically after the timeout. (The other display is an AV receiver, used only for audio through HDMI.)

Since swaylock hasn't been part of the configuration, another thing I could think of is that I may have actually run into two separate issues in the past few years:

1. Only the display remains switched off, but the compositor recognises all keyboard and mouse input. (This would explain why Ctrl+Alt+Fx worked the other day.)
2. The compositor freezes so the entire computer becomes unresponsive to any keyboard or mouse input, including Ctrl+Alt+Fx. (I wonder if this is even possible on Wayland.)

By the way, I just remembered something else. When the display would refuse to turn on, I would now and again try to press Ctrl+Alt+Backspace, thinking it would kill the compositor just like it would kill x.org in an X session. It looks like I've been wrong this whole time, since it doesn't do anything on scroll.

I still believe I have tried Ctrl+Alt+Fx at least once and I didn't notice any change. At any rate, at least I'm somewhat relieved that it wakes up the monitor should it happen again.