Red screen & unable to unlock when changing screen

[jvanbruegge]

This is with ext-session-lock (swaylock 1.7) and sway 1.8. If I lock my laptop, suspend it by closing it, then connect it to my docking station with two external monitors and resuming it, I get greeted by completely red screens on both monitors and no way to unlock except rebooting the machine.

I can see this in the logs:

[main.c:1188] Parsing CLI Args
[main.c:489] Loaded image <path> for output *
[main.c:1245] Using ext-session-lock-v1

<other logs>

ext_session_lock_surface_v1@33: error 2: committed surface dimensions do not match last acked configure

Not sure if that is related, but shortly after, waybar dumps core.

[kennylevinsen]

This means that swaylock hit a protocol error, stemming from this check: https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/types/wlr_session_lock_v1.c#L145

If you can reproduce with swaylock 1.7.2 (or master), run swaylock manually with WAYLAND_DEBUG=1 set in the environment, collecting output to a file as it crashes. This should show what causes the protocol error..

[jacksgt]

I am facing the exact same issue and started debugging, but then I realized that I'm in fact using swaylock-effects (1.6.10) instead of the regular swaylock.
With vanilla swaylock (1.7) screen locking works without issues on sway 1.8.

I see that there is another discussion for swaylock-effects: mortie#97

[mstoeckl]

ext_session_lock_surface_v1@33: error 2: committed surface dimensions do not match last acked configure

Note: this error can be caused by get_next_buffer() failing at render.c#L44, after which render_frame can commit the background surface with an old buffer (and old size) despite having acknowledged the new buffer size that should be used. I've encountered this error in a different scenario, but it is the sort of thing that can happen with output property changes, multiple configure events, and high CPU load producing a race condition.

[jvanbruegge]

Yes, it is really hard for me to reproduce and I am not even sure if 1.7.2 might have fixed it, can't remember if the last red screen was before or after the upgrade

[jvanbruegge]

Ok, I just had this today again, so it is indeed still an issue. Sadly I had no time for investigation so I have to wait until the next time this happens

[mstoeckl]

Sadly I had no time for investigation so I have to wait until the next time this happens

With sporadic bugs like this, I'd recommend always recording output with WAYLAND_DEBUG=1, and when you do get a crash, just attach the logs for the run leading up to the ext_session_lock_surface_v1 error. One way to do this is to run a swaylock-logged script containing something like:

#!/bin/sh
(echo -e "\n\nStarting swaylock:\n"; WAYLAND_DEBUG=1 swaylock 2>&1 | sed  's/\[.......\....\]/\[XXXXXXX.YYY\]/') | grep -v keyboard | grep -v pointer >> ~/swaylock_logfile

(In the script, the sed and grep -v ensure that neither timestamps, key press events, nor pointer motion events are recorded, so even if you do accidentally provide logs from a time where you typed in a password, the password can't be recovered from the logs.)

[fberg]

This happens fairly frequently to me, and I captured logs with WAYLAND_DEBUG=1. Happened under similar circumstances as in the OP (suspend with internal display, wakeup with external monitors attached). I'm on swaylock 1.7.2.

Btw: you can unlock the session by switching to a different TTY and starting swaylock there (with appropriate WAYLAND_DISPLAY set).

swaylock.error.log

[kennylevinsen]

With sporadic bugs like this, I'd recommend always recording output with WAYLAND_DEBUG=1

Be very careful with this as such log also includes key codes of keypresses made during the execution of the application.