Relevant DRM/AMD (kernel driver) bug for the people still subscribed to this issue: https://gitlab.freedesktop.org/drm/amd/-/issues/1376

Please react to this comment with a thumbs up if you are experiencing this bug on AMD hardware or a thumbs down if you are experiencing it on non-AMD hardware

Repro steps:

1. Laptop is in dock, both LVDS-1 (laptop internal monitor) and DP-2 (external monitor) are on and working ifne
2. Take out laptop out of dock
3. systemctl suspend, and wait for the screen to turn off
4. put laptop in dock
5. press laptop power button to wake from suspend
6. DP-2 won’t turn on because of: 00:04:55.805 [DEBUG] [wlr] [backend/drm/atomic.c:35] connector DP-2: Atomic test failed (modeset): Invalid argument 00:04:55.806 [ERROR] [sway/config/output.c:435] Failed to commit output DP-2

A dpms toggle doesn’t turn it back on either, eg:

swaymsg "output DP-2 dpms off" && sleep 2 && swaymsg "output DP-2 dpms on"                                                                             

swaymsg reload also doesn’t fix it I need to swaymsg exit then start sway again.

The DP-2 will start fine on wake if the laptop was suspended in the docking station:

1. Laptop is in dock, both LVDS-1 and DP-2 working ok
2. systemctl suspend, laptop still in dock
3. wait for both screens to turn off
4. press power button to wake
5. both LVDS-1 and DP-2 turn on

Logs here:

t430 :: ~ % sway --version                                                                                                                                              
sway version 1.6-c9060bcc (Aug 15 2021, branch 'master')

00:04:55.798 [INFO] [sway/commands.c:257] Handling command 'output DP-2 pos 1366 0 res 2560x1440'
00:04:55.798 [DEBUG] [sway/commands.c:428] Subcommand: pos 1366 0 res 2560x1440
00:04:55.798 [DEBUG] [sway/commands.c:428] Subcommand: res 2560x1440
00:04:55.798 [DEBUG] [sway/config/output.c:204] Merging on top of existing output config
00:04:55.798 [DEBUG] [sway/config/output.c:227] Config stored for output DP-2 (enabled: -1) (2560x1440@59.951000Hz position 1366,0 scale -1.000000 subpixel unknown trans
form -1) (bg #3f3f3f solid_color) (dpms 1) (max render time: -1)
00:04:55.798 [DEBUG] [sway/config/output.c:351] Turning on output DP-2
00:04:55.798 [DEBUG] [sway/config/output.c:355] Set DP-2 mode to 2560x1440 (59.951000 Hz)
00:04:55.798 [DEBUG] [sway/config/output.c:269] Assigning configured mode to DP-2
00:04:55.798 [DEBUG] [sway/config/output.c:329] Output DPI: 69.174468x69.011321
00:04:55.798 [DEBUG] [sway/config/output.c:400] Auto-detected output scale: 1.000000
00:04:55.798 [DEBUG] [sway/config/output.c:430] Committing output DP-2
00:04:55.798 [DEBUG] [wlr] [backend/drm/drm.c:464] connector DP-2: Can't enable an output without a buffer
00:04:55.798 [DEBUG] [wlr] [types/wlr_output.c:689] Attaching empty buffer to output for modeset
00:04:55.798 [DEBUG] [wlr] [render/swapchain.c:105] Allocating new swapchain buffer
00:04:55.805 [DEBUG] [wlr] [render/gbm_allocator.c:127] Allocated 2560x1440 GBM buffer (format 0x34325258, modifier 0xFFFFFFFFFFFFFF)
00:04:55.805 [DEBUG] [wlr] [render/gles2/renderer.c:142] Created GL FBO for buffer 2560x1440
00:04:55.805 [DEBUG] [wlr] [backend/drm/atomic.c:35] connector DP-2: Atomic test failed (modeset): Invalid argument
00:04:55.806 [ERROR] [sway/config/output.c:435] Failed to commit output DP-2

Could the people affected please check:

• their monitor’s firmware version in the built-in overlay menu (aka “OSD” menu)
• and make sure the product page of their monitor manufacturer doesn’t provide a newer version for download and flash? (You may need a windows pc to flash, my installer was .exe)

It didn’t solve this problem for me (this is a long time issue for me), but I use an old-school non-usb-c dock.

I noticed my monitor firmware version (in the built-in overlay monitor menu) is M2103, but then I went to Dell’s page for my 4317Q model and there was a M2104 version whose changelog says “fix issue with wake-up with USB-C docks” so I was hopeful, but as I said, it didn’t work.

Please react with thumbs down to this comment if either your firmware is the newest possible and this issue is still happening, or if you updated from old FW (where it didn’t work) to newest, and the issue persists

I’ve noticed that after upgrading to sway 1.8 & wlroots 0.16.0 this issue occurs every time the monitor goes to sleep, regardless of the delay between dpms off and dpms on. i.e.: with sway 1.7 & wlroots 0.15.1 running swaymsg "output * dpms off" && swaymsg "output * dpms on" causes this bug 0/10 times with sway 1.8 & wlroots 0.16.0 running swaymsg "output * dpms off" && swaymsg "output * dpms on" causes this bug 10/10 times

Please react with a thumbs up if you experience this change in behavior after upgrading to sway 1.8 and/or wlroots 0.16.0 or a thumbs down if you have both sway 1.8 and wlroots 0.16.0 and you are not seeing this change in behavior

Hi chaps, until there is an actual solution, I got a perfectly working (for me) workaround ( Debian 11 bullseye / Kernel: 6.1.0-0.deb11.5-amd64) :

In your sway config: swayidle -w timeout 300 'swaylock -f -c 000000' timeout 480 'swaymsg "output * dpms off"' resume '$HOME/.config/sway/sway-resume.sh' before-sleep 'swaylock -f -c 000000'

And the sway-resume.sh contains:

#!/usr/bin/env bash

sway_tty=$(ps aux | grep '[0-9] sway$' | tr ' ' '\n' | grep tty | head -n 1 | xargs | sed 's/tty//g') 

other_tty=$(ps aux  | grep -v tty$sway_tty | grep '^root.* tty' | tr ' ' '\n' | grep ^tty | sort | uniq | head -n 1 | xargs | sed 's/tty//g')


swaymsg "output * dpms on"

if [ ! -z "$sway_tty" ]; then
	if [ -z "$other_tty" ]; then
		other_tty=$(($sway_tty+1))
	fi

	#echo $other_tty
	#echo $sway_tty
	
	sudo chvt $other_tty && sleep 2
	sudo chvt $sway_tty
fi

swaymsg "output * dpms on"
swaymsg "reload"

If for your system the sway_tty number is known, you can replace the logic in the script with static assignments. You can confirm if your system’s tty number for sway is the same across reboots number using LShift + LAlt + [F1, F2, F3, F4].

Don’t forget to visudo and make the use of ‘chvt’ not requiring a passwd for your user (or sudoers group): %sudo ALL=(root) NOPASSWD: /usr/bin/chvt

Sorry, I didn’t meant my comment as response to @itaranto. I just got notified and decided to leave this breadcrumb. I see such issue mentioned there and there in the WEB, but no clear answer to it. Might be some Kernel thing. Not an expert. But what I said above definitely influenced the behavior of my system. I will try to explore it on my next reinstall.

I experienced this same problem with current master branch version of sway (90c2d631). The problem started occurring after I updated my (archlinux) AUR sway-git package.

The fix for me was to build and install sway from 1.8 release branch combined with wlroots release 0.16.2.

Simplest repro: $ swaymsg “output * dpms off” && sleep 1 && swaymsg “output * dpms on”

With the newest version I got this error in sway log:

Mar 16 19:58:54 tikari /usr/lib/gdm-wayland-session[1426]: 00:01:50.178 [ERROR] [wlr] [types/output/swapchain.c:100] Swapchain for output 'eDP-1' failed test
Mar 16 19:58:54 tikari /usr/lib/gdm-wayland-session[1426]: 00:01:50.180 [ERROR] [wlr] [types/output/swapchain.c:100] Swapchain for output 'eDP-1' failed test
Mar 16 19:58:54 tikari /usr/lib/gdm-wayland-session[1426]: 00:01:50.183 [ERROR] [wlr] [types/output/swapchain.c:100] Swapchain for output 'eDP-1' failed test
Mar 16 19:58:54 tikari /usr/lib/gdm-wayland-session[1426]: 00:01:50.183 [ERROR] [sway/config/output.c:531] Failed to commit output eDP-1

The machine is Lenovo Thinkpad X1C Gen 7, Intel Whiskey Lake, UHD 620 iGPU using “i915” kernel driver. I tested with kernels 6.2 (6.2.6-arch1-1) and 6.1 (arch “linux-lts”).

Interestingly this is different from @RunningDroid 's issue, since they experienced problems with sway version 1.8 while for me going from 1.9=>1.8 fixed the issue.

When I have some free time I might try bisecting this further.

Just to give a brief update, it’s still happening to me with sway-1.6 using liunx-5.11.16-arch1-1 and mesa-21.0.3-2 on Arch Linux. But it is less frequent, I think this is the second time this is happening in a span of a month, before this was happening everyday. Just a quick dpms on/off brings it back, no issue with resolution.

@dvzrv I tested your waylock configuration and sadly it is still happening to me. Power cycling the sleeping monitor brings it back, but sometimes I need to turn it off and on again with sway to get the correct resolution back.

FWIW: I have experienced the same(?) issue using swayidle (1.6) and swaylock (1.5) on sway (1.5.1) on two separate machines (one intel/nvidia based laptop, one amdgpu based desktop) using a dual monitor setup (the same monitors in both setups). One of the monitors (Dell Inc. DELL P2715Q 32R1F52CAMBL) would sometimes not wake up (note: it generally takes around 1s longer to wake up, than the 2nd monitor) and I would have to switch it off and on again to have it wake up and being used again. The other monitor (Dell Inc. DELL2407WFPHC DR47478U0TMS) in that setup did not exhibit this behavior (and is generally the one waking up faster).

I have switched to waylock about two weeks ago and I have not experienced this behavior since.

My config currently includes:

exec [ -x /usr/bin/swayidle ] && [ -x /usr/bin/waylock ] && swayidle -w \
  timeout 300 'setsid -f waylock' \
  timeout 600 'swaymsg "output * dpms off"' \
  resume 'swaymsg "output * dpms on"' \
  before-sleep 'setsid -f waylock'

With swaylock it used to include:

exec [ -x /usr/bin/swayidle ] && [ -x /usr/bin/swaylock ] && swayidle -w \
  timeout 300 'swaylock -F -f -e -c 000000' \
  timeout 600 'swaymsg "output * dpms off"' \
  resume 'swaymsg "output * dpms on"' \
  before-sleep 'swaylock -f -c 000000'

This can of course also be a red herring, but so far the above setup has been stable for my hardware setup.

I’m having what might be the same issue on and off with a Dell Precision 5550 (Intel GPU) with an external monitor When it happens again, I’ll try to grab some logs from dmesg