After monitors were off, gdm is shown instead of sway

main() · 2022-05-11 14:27:05

I'm running sway 1.7-2 with gdm 42.0+r11+g4a52f026-1 on linux-mainline 5.18rc6-1 with an AMD RX 6600 GPU. This works fine, except for the following problem:

When my moniturs turn off (e.g. because I'm idle) and then turn back on, I see gdm instead of my desktop. I then have to press Ctrl+Alt+F2 to switch to tty2 where my desktop is. So basically it seems like something is causing a switch from tty2 (sway) to tty1 (gdm) either when the screens are shutting off or right before they turn back on.

I can reproduce this problem reliably like this:
swaymsg "output * dpms off" && sleep 10 && swaymsg "output * dpms on"

Any ideas what might be causing this?

V1del · 2022-05-11 15:18:33

GDM can and does register itself as a lockscreen maybe some behaviour from that? I think there is (or at least used to be, never know with GNOME) a gsetting to disable that, a cursory googler threw up

gsettings set org.gnome.desktop.lockdown disable-lock-screen true

main() · 2022-05-11 15:43:35

Hm, looks like that didn't do the trick. Even after restarting gdm I'm still seeing the same problem.

I've been running sway+gdm for years and it only started doing this a couple of months ago. Unfortunately I can't remember when exactly. I was having sporadic issues with my old GPU as well, so I used to just blame it on that. But since I got the new RX 6600, all my graphics issues are gone - except for this one.

main() · 2022-05-16 23:06:22

Looks like it is some weird Monitor/GPU interaction. Relevant Sway log: https://gist.github.com/main--/8d0cac86 … eb1ba0585e

Sway is turning the Monitor back on, but in response to this the Monitor interrupts the connection. This causes sway to disable it and eventually hit some kind of timeout in libseat (?) which then disables the seat. I'm guessing that this causes the switch to seat0 where gdm lives. Now the question is: Is this a bug in sway? wlroots? libseat? How can I investigate this further?

seth · 2022-05-17 06:04:58

I assume it's sway being smart and responsive when you "unplug" and output (just that you're not really unplugging it)
There seem to be two outputs (DP-1 and HDMI-A-1): are both affected (independently or together) and can you swap the outputs (attach the DP panel to HDMI and vv.)?

main() · 2022-05-17 10:00:47

The two monitors always switch together. The DP-1 Monitor (Samsung Odyssey G9) seems to be the culprit though. If I unplug it, everything works. If I unplug the other monitor instead, the issue is back. Interestingly, plugging in my other monitor while the G9 is on also takes me straight to gdm (on both displays). So that seems to put the blame back on sway or wlroots?

Some users report on reddit that they are seeing vaguely similar issues (black screen when turning the monitor back on) on Windows (!), and point out specific firmware versions that work for them. I tried all of them and can't see any difference though. So maybe this is related (monitor does strange things on waking up) but not actually the root cause of the problem. The Monitor has always had a habit of sometimes pretending to unplug itself when waking up. I could observe this by seeing sway move all of my workspaces to the other monitor for a split second, and then back to the G9. But until I switched to the RX6600, it never sent me back to gdm (unless sway outright crashed of course, which it did a couple of times, but very rarely).

Swapping the cables is not an option because my HDMI output can't do 5120x1440@120Hz AFAIK.

seth · 2022-05-17 16:14:27

The dbus timeout would be 25 seconds… do those messages show up more frequently (and unrelated to the issue)?
The bus might just be blocked and then unspool the events, triggering a pause in response to a pending PauseDevice from org.freedesktop.login1 /org/freedesktop/login1/session/self

How does this behave w/o GDM?

main() · 2022-05-17 16:41:57

Good point. While the message about the dbus timeout doesn't show up very frequently, it's probably unrelated because it doesn't always appear.

When disabling gdm and starting sway directly from the tty, I see sway moving workspaces to the secondary monitor and then back to the G9. So it looks like it's doing the same thing, but without the seat switch - I'm guessing because there is no other seat so there is nothing to switch to.

seth · 2022-05-17 19:31:36

The more interesting question is whether the seat is also paused w/o GDM (or whether GDM is causing the pause)
The fudamental problem is that the output disappears and that's not being ignored, but idk whether sway allows to quirk that (it's certainly not "wrong" to respond to the output loss - just undesired for this spurious loss)

main() · 2022-05-18 08:25:36

More logs, this time using journalctl -fx: https://gist.github.com/main--/bdbcd492 … 68ef5afd54

Looking at line 504, gdm is starting to launch while sway is still reacting to the DP-1 disconnect event. Sadly, I can't see anything in the logs that would indicate WHY gdm is launching here. But at least this suggests that sway isn't erroneously disabling the seat but that instead gdm is actively taking control somehow.

Why gdm is randomly spamming the logs with xkbcomp errors is also beyond me. It never even runs in X11 mode, my system is strictly Wayland only AFAIK.

seth · 2022-05-18 11:26:15

Don't use "-x", it's spam.
Does GDM do this to other sessions (eg. weston or gnome)?

fwwi, you (very most likely) get the xkbcomp "errors" from xwayland (which is in the logs)
The "error" itself is harm- and meaningless (xkb operates on a symbol range that exceeds previous X11 limits, but was expanded for wayland)

main() · 2022-05-18 17:16:14

seth wrote:

Does GDM do this to other sessions (eg. weston or gnome)?

Indeed, I can reproduce the same behavior with both Weston and Gnome! So it looks like sway is innocent after all.

seth wrote:

fwwi, you (very most likely) get the xkbcomp "errors" from xwayland (which is in the logs)
The "error" itself is harm- and meaningless (xkb operates on a symbol range that exceeds previous X11 limits, but was expanded for wayland)

Sounds reasonable, but it still leaves me wondering why gdm is randomly starting instances gdm-wayland-session in the background for no apparent reason (since the PID almost always different with these log entries).

seth · 2022-05-19 12:55:10

https://man.archlinux.org/man/extra/xor … ients.1.en - could be as simple as frequent xrandr polls…

Arch Linux

#1 2022-05-11 14:27:05

After monitors were off, gdm is shown instead of sway

#2 2022-05-11 15:18:33

Re: After monitors were off, gdm is shown instead of sway

#3 2022-05-11 15:43:35

Re: After monitors were off, gdm is shown instead of sway

#4 2022-05-16 23:06:22

Re: After monitors were off, gdm is shown instead of sway

#5 2022-05-17 06:04:58

Re: After monitors were off, gdm is shown instead of sway

#6 2022-05-17 10:00:47

Re: After monitors were off, gdm is shown instead of sway

#7 2022-05-17 16:14:27

Re: After monitors were off, gdm is shown instead of sway

#8 2022-05-17 16:41:57

Re: After monitors were off, gdm is shown instead of sway

#9 2022-05-17 19:31:36

Re: After monitors were off, gdm is shown instead of sway

#10 2022-05-18 08:25:36

Re: After monitors were off, gdm is shown instead of sway

#11 2022-05-18 11:26:15

Re: After monitors were off, gdm is shown instead of sway

#12 2022-05-18 17:16:14

Re: After monitors were off, gdm is shown instead of sway

#13 2022-05-19 12:55:10

Re: After monitors were off, gdm is shown instead of sway

Board footer