One monitor won't wake up after swayidle

[plattfot]

sway version

sway version v1.5

log

log

Note the log is quite big as sway was running for a few hours before it happened.

config

config

Description

Using a dual monitor setup and about 1 in 10 times one of the monitors wont wake up after swayidle have put them to sleep. Which monitor that fails to wake up varies. After I've unlocked the swaylock screen it usually comes back but will blink every 10s or so. This time it didn't come back after unlock. I have a mode in my config:

mode "$toggle_outputs" {
     bindsym l output $left toggle; mode "default"
     bindsym r output $right toggle; mode "default"

     bindsym Escape mode "default"
}

That allows me to toggle each monitor off and on. And toggling the monitor that failed to wake up off and on will fix the issue.
It's really hard to reproduce, only seem to happen after swayidle have put them to sleep. I have had no issue toggling a monitor off and on manually using the mode above.

Thanks

[LaserEyess]

Potentially https://gitlab.freedesktop.org/drm/amd/-/issues/1368

I've been trying to find a way to debug this, specifically to get timestamps of when it happens so I can correlate drm logs with sway logs.

[jokeyrhyme]

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

[jokeyrhyme]

Here we go:

Nov 19 13:49:08 hostname /usr/lib/gdm-wayland-session[3632]: 04:52:21.706 [ERROR] [backend/drm/atomic.c:36] eDP-1: Atomic commit failed (modeset): Invalid argument
Nov 19 13:49:08 hostname /usr/lib/gdm-wayland-session[3632]: 04:52:21.715 [ERROR] [backend/drm/atomic.c:36] eDP-1: Atomic commit failed (modeset): Invalid argument
Nov 19 13:49:08 hostname /usr/lib/gdm-wayland-session[3632]: 04:52:21.715 [ERROR] [backend/drm/drm.c:744] Failed to initialize renderer on connector 'eDP-1': initial page-flip failed
Nov 19 13:49:08 hostname /usr/lib/gdm-wayland-session[3632]: 04:52:21.715 [ERROR] [backend/drm/drm.c:817] Failed to initialize renderer for plane
Nov 19 13:49:08 hostname /usr/lib/gdm-wayland-session[3632]: 04:52:21.715 [sway/config/output.c:414] Failed to commit output eDP-1

And my config has:

set $swaylock 'swaylock --daemonize'
set $swaydpmsoff 'swaymsg "output * dpms off"'
set $swaydpmson  'swaymsg "output * dpms on"'

exec swayidle -w \
  idlehint 300              \
   timeout 300 $swaylock    \
   timeout 300 $swaydpmsoff resume $swaydpmson \
  before-sleep $swaylock    \
          lock $swaylock    \
  after-resume $swaydpmson  \
        unlock $swaydpmson

set $laptop eDP-1

output * adaptive_sync on

# https://github.com/swaywm/sway/wiki#multihead

output DP-4 scale 1
output DP-4 subpixel none
output DP-4 position 0 0 res 3440x1440

output $laptop scale 2
output $laptop subpixel none
output $laptop position 3440 360 res 3840x2400

# https://github.com/swaywm/sway/wiki#clamshell-mode

bindswitch --reload --locked lid:on output $laptop disable
bindswitch --reload --locked lid:off output $laptop enable

I wonder if it's a timing issue or race between enabling the output and turning on DPMS?
I might play with putting some sleeps in to see if that helps

[plattfot]

I managed to simplify how to reproduce this bug with what @LaserEyess suggested in this thread: https://gitlab.freedesktop.org/drm/amd/-/issues/1376

swaymsg "output * dpms off" && sleep 60 && swaymsg "output * dpms on"

It will not happen every time I run these commands but every second or third time.

One session when I tried these commands, the first time both monitors came back. Second time only the left (DP-2), I toggled the right (DP-1) off and on using this mode in my configuration:

set $left 'Unknown ASUS VG289 0x00009D06'
set $right 'Unknown ASUS VG289 0x000085B4'

set $toggle_outputs Toggle: [l]eft [r]ight

bindsym --locked $mod+Shift+o mode "$toggle_outputs"

mode "$toggle_outputs" {
     bindsym --locked l output $left toggle; mode "default"
     bindsym --locked r output $right toggle; mode "default"

     bindsym --locked Escape mode "default"
}

It came back, no issue with the resolution. No errors in dmesg.

The third time I tried, the same monitor didn't come back. Did the same toggle and it came back but with a resolution of 640x480. When physically turning the monitor off and back on it just showed a black screen. Did the sway toggle again and it came back with it's native resolution. This time dmesg showed a trace back from the amdgpu drivers as described in this bug report: https://gitlab.freedesktop.org/drm/amd/-/issues/1376

I don't see any errors in my sway log about this. Here are some snippets from my log after the third run:

00:04:10.674 [DEBUG] [backend/session/session.c:45] udev event for card0 (change)
00:04:10.675 [DEBUG] [backend/drm/backend.c:112] /dev/dri/card0 invalidated
00:04:10.675 [INFO] [backend/drm/drm.c:1256] Scanning DRM connectors
00:04:10.675 [INFO] [backend/drm/drm.c:1431] 'DP-1' disconnected
00:04:10.675 [INFO] [backend/drm/drm.c:1621] Emitting destruction signal for 'DP-1'
00:04:10.675 [DEBUG] [backend/drm/drm.c:1062] De-allocating CRTC 4 for output 'DP-1'
00:04:10.871 [sway/tree/output.c:259] Disabling output 'DP-1'

Then when I've toggled the monitor off and on

00:21:05.291 [DEBUG] [backend/session/session.c:45] udev event for card0 (change)
00:21:05.291 [DEBUG] [backend/drm/backend.c:112] /dev/dri/card0 invalidated
00:21:05.291 [INFO] [backend/drm/drm.c:1256] Scanning DRM connectors
2020-11-20 10:07:14 - [swaybg-1.0/main.c:167] Destroying output DP-2 (Unknown ASUS VG289 0x00009D06)
00:21:05.292 [INFO] [backend/drm/drm.c:1351] 'DP-1' connected
00:21:05.292 [DEBUG] [backend/drm/drm.c:1352] Current CRTC: -1
00:21:05.292 [INFO] [backend/drm/drm.c:1357] Physical size: 620x340
00:21:05.292 [INFO] [backend/drm/drm.c:1375] Detected modes:
00:21:05.292 [INFO] [backend/drm/drm.c:1397]   640x480@59940 
00:21:05.292 [INFO] [backend/drm/drm.c:1397]   640x480@59940 
00:21:05.292 [DEBUG] [backend/drm/drm.c:1088] Reallocating CRTCs
00:21:05.292 [DEBUG] [backend/drm/drm.c:1099] State before reallocation:
00:21:05.292 [DEBUG] [backend/drm/drm.c:1105]   'DP-1' crtc=-1 state=1 desired_enabled=1
00:21:05.292 [DEBUG] [backend/drm/drm.c:1105]   'DP-2' crtc=-1 state=0 desired_enabled=1
00:21:05.292 [DEBUG] [backend/drm/drm.c:1105]   'DP-3' crtc=-1 state=0 desired_enabled=0
00:21:05.292 [DEBUG] [backend/drm/drm.c:1105]   'HDMI-A-1' crtc=-1 state=0 desired_enabled=0
00:21:05.292 [DEBUG] [backend/drm/drm.c:1157] State after reallocation:
00:21:05.292 [DEBUG] [backend/drm/drm.c:1164]   'DP-1' crtc=5 state=1 desired_enabled=1
00:21:05.292 [DEBUG] [backend/drm/drm.c:1164]   'DP-2' crtc=-1 state=0 desired_enabled=1
00:21:05.292 [DEBUG] [backend/drm/drm.c:1164]   'DP-3' crtc=-1 state=0 desired_enabled=0
00:21:05.292 [DEBUG] [backend/drm/drm.c:1164]   'HDMI-A-1' crtc=-1 state=0 desired_enabled=0
00:21:05.292 [INFO] [backend/drm/drm.c:1463] Requesting modeset for 'DP-1'
00:21:05.292 [sway/desktop/output.c:915] New output 0x555726105cd0: DP-1
00:21:05.292 [sway/config/output.c:348] Turning on output DP-1
00:21:05.292 [sway/config/output.c:379] Auto-detected output scale: 1.000000
00:21:05.292 [sway/config/output.c:387] Set DP-1 adaptive sync to 1
00:21:05.292 [sway/config/output.c:409] Committing output DP-1
00:21:05.292 [INFO] [backend/drm/drm.c:811] Modesetting 'DP-1' with '640x480@59940mHz'
00:21:05.292 [DEBUG] [backend/drm/drm.c:693] Initializing renderer on connector 'DP-1'

Then after I physically toggled the monitor off and on

00:21:37.921 [DEBUG] [backend/session/session.c:45] udev event for card0 (change)
00:21:37.921 [DEBUG] [backend/drm/backend.c:112] /dev/dri/card0 invalidated
00:21:37.921 [INFO] [backend/drm/drm.c:1256] Scanning DRM connectors
00:21:37.922 [INFO] [backend/drm/drm.c:1351] 'DP-1' connected
00:21:37.922 [DEBUG] [backend/drm/drm.c:1352] Current CRTC: -1
00:21:37.922 [INFO] [backend/drm/drm.c:1357] Physical size: 620x340
00:21:37.922 [INFO] [backend/drm/drm.c:1375] Detected modes:
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   3840x2160@59997 (preferred)
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   3840x2160@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   3840x2160@59940 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   3840x2160@50000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   3840x2160@30000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   3840x2160@29970 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   3840x2160@25000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   3840x2160@24000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   3840x2160@23976 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   2560x1440@59951 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1920x1200@59997 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1920x1080@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1920x1080@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1920x1080@59940 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1920x1080@50000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1920x1080@24000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1920x1080@24000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1920x1080@23976 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1920x1080@23976 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1600x1200@59997 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1680x1050@59954 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1280x1024@60020 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1440x900@59887 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1280x960@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1280x800@59810 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1280x720@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1280x720@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1280x720@59940 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1280x720@50000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1440x576@50000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1440x576@50000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1024x768@60004 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1440x480@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1440x480@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1440x480@59940 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   1440x480@59940 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   800x600@60317 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   800x600@56250 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   720x576@50000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   720x480@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   720x480@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   720x480@59940 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   720x480@59940 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   640x480@60000 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   640x480@59940 
00:21:37.922 [INFO] [backend/drm/drm.c:1397]   640x480@59940 
00:21:37.923 [DEBUG] [backend/drm/drm.c:1088] Reallocating CRTCs
00:21:37.923 [DEBUG] [backend/drm/drm.c:1099] State before reallocation:
00:21:37.923 [DEBUG] [backend/drm/drm.c:1105]   'DP-1' crtc=-1 state=1 desired_enabled=1
00:21:37.923 [DEBUG] [backend/drm/drm.c:1105]   'DP-2' crtc=4 state=3 desired_enabled=1
00:21:37.923 [DEBUG] [backend/drm/drm.c:1105]   'DP-3' crtc=-1 state=0 desired_enabled=0
00:21:37.923 [DEBUG] [backend/drm/drm.c:1105]   'HDMI-A-1' crtc=-1 state=0 desired_enabled=0
00:21:37.923 [DEBUG] [backend/drm/drm.c:1157] State after reallocation:
00:21:37.923 [DEBUG] [backend/drm/drm.c:1164]   'DP-1' crtc=5 state=1 desired_enabled=1
00:21:37.923 [DEBUG] [backend/drm/drm.c:1164]   'DP-2' crtc=4 state=3 desired_enabled=1
00:21:37.923 [DEBUG] [backend/drm/drm.c:1164]   'DP-3' crtc=-1 state=0 desired_enabled=0
00:21:37.923 [DEBUG] [backend/drm/drm.c:1164]   'HDMI-A-1' crtc=-1 state=0 desired_enabled=0
00:21:37.923 [INFO] [backend/drm/drm.c:1463] Requesting modeset for 'DP-1'
00:21:37.923 [sway/desktop/output.c:915] New output 0x555726105cd0: DP-1
00:21:37.923 [sway/config/output.c:348] Turning on output DP-1
00:21:37.923 [sway/config/output.c:326] Output DPI: 157.316129x161.364706
00:21:37.923 [sway/config/output.c:379] Auto-detected output scale: 1.000000
00:21:37.923 [sway/config/output.c:387] Set DP-1 adaptive sync to 1
00:21:37.923 [sway/config/output.c:409] Committing output DP-1
00:21:37.923 [INFO] [backend/drm/drm.c:811] Modesetting 'DP-1' with '3840x2160@59997mHz'
00:21:37.923 [DEBUG] [backend/drm/drm.c:693] Initializing renderer on connector 'DP-1'

I do see a bunch of these errors:

00:21:37.739 [DEBUG] [xwayland/xwm.c:1425] unhandled X11 event: MappingNotify (34)
00:21:37.739 [DEBUG] [xwayland/xwm.c:1425] unhandled X11 event: MappingNotify (34)
The XKEYBOARD keymap compiler (xkbcomp) reports:
> Warning:          Unsupported maximum keycode 569, clipping.
>                   X11 cannot support keycodes above 255.
Errors from xkbcomp are not fatal to the X server

[emersion]

00:21:05.292 [INFO] [backend/drm/drm.c:1375] Detected modes:
00:21:05.292 [INFO] [backend/drm/drm.c:1397]   640x480@59940 
00:21:05.292 [INFO] [backend/drm/drm.c:1397]   640x480@59940 

Sure sounds like a driver bug.

[Sviests]

I am too experiencing the same issue, my laptop screen does not turn back on after the screen turns off with swayidle. Ive copy-pasted the swayidle config from the OP. If I can be of any help with logs or etc, please let me know, Im glad to help!

[dvzrv]

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.

[plattfot]

@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.

[ErikReider]

I'm experiencing this issue on my 5700XT and on my Intel 10th gen laptop. This issue only affects my HDMI connected monitor on both setups (Displayport + HDMI connections)
When looking at swaymsg -t get_outputs, it shows that my HDMI monitor is inactive.

I usually just reload the config or re-enable the monitor in wdisplays to fix this issue

[Kabbone]

Just for reference for people being annoyed by this bug as I was, this module parameter worked around it for me:
snd_hda_codec_hdmi.enable_acomp=off snd_hda_codec_hdmi.enable_silent_stream=off

[plattfot]

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.

[sethidden]

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:

WLR_DRM_NO_MODIFIERS=1 sway -d > sway.log 2>&1

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

wlroots-git is at commit https://github.com/swaywm/wlroots/commit/3364eec07e91eb51f770f2f7d619a07d96c0b5c4

Most relevant part:

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

Full logs: https://gist.github.com/3nuc/6c9112485258b0dab36ce2a67e0594dc

[ErikReider]

@3nuc I'm experiencing the same issue. I've just resorted to just sleep instead of just powering off my monitors to save on some electricity 😄🌳

[sethidden]

Oh, I think this is caused by having a custom output mode.

I had output DP-2 pos 1366 0 res 2560x1440@59.951Hz in my sway/config, but when I commented it out and restarted sway, monitors wake up normally - the repro steps from #5759 (comment) now make all monitors wake up correctly

Possibly related to

• drm: the wlr_output_commit after commiting mode fails  wlroots#2492

Here are similar old WLC issues but since wlroots exist now they don't matter that much:

• Output * resolution doesn't set the monitor resolution #423 (comment)
• sway doesn't set the secondary monitor properly #1212 (comment)

[jancespivo]

I'm also experiencing the same issue.

sway version 1.6.1

sway log:

Nov 14 11:51:35 hostname sway[845]: 00:25:57.710 [ERROR] [wlr] [backend/drm/drm.c:725] connector eDP-1: Failed to initialize renderer: initial page-flip failed
Nov 14 11:51:35 hostname sway[845]: 00:25:57.710 [ERROR] [wlr] [backend/drm/drm.c:813] connector eDP-1: Failed to initialize renderer for plane
Nov 14 11:51:35hostname sway[845]: 00:25:57.710 [ERROR] [sway/config/output.c:417] Failed to commit output eDP-1

There are no related messages in dmesg

snd_hda_codec_hdmi.enable_acomp=off snd_hda_codec_hdmi.enable_silent_stream=off haven't helped.

[dmayle]

I'm not sure whether to just add here, or to file my own bug. I've got the same problem described, but this happens on two different machines, plugged into two different sets of monitors. The first is a laptop with an intel CPU/GPU plugged into two lenovo thinkvision monitors, and the second is a desktop with an AMD CPU and Nvidia GPU (running GBM) plugged into a TCL TV. Given that this is two different machines with two different brands of graphics cards, it's hard to simply call this a driver problem.

For the desktop, the log line I see is:

09:00:45.588 [ERROR] [wlr] [backend/drm/atomic.c:35] connector HDMI-A-1: Atomic commit failed (pageflip): Permission denied

All I have to do to trigger it is change inputs on the TV/monitor and then come back. My workaround is to change virtual terminals to the one where gdm is running, which brings the monitor back to live, and then back to the sway vt.

Tomorrow or tuesday, when I have the laptop connected, I'll add the log lines for that as well.

[adamcstephens]

My workaround is to change virtual terminals to the one where gdm is running, which brings the monitor back to live, and then back to the sway vt.

This the same workaround I use with my Dell P2715Q

[dmayle]

I've had a chance to test on the laptop with an intel cpu and gpu. I'm in a state right now where one of the outputs won't come on, and this is what I see in the log when I try swaymsg output DP-3 enable:

Dec 15 14:07:15 doug-laptop /usr/libexec/gdm-wayland-session[2495]: 01:30:48.790 [ERROR] [wlr] [backend/drm/drm.c:725] connector DP-3: Failed to initialize renderer: initial page-flip failed
Dec 15 14:07:15 doug-laptop /usr/libexec/gdm-wayland-session[2495]: 01:30:48.790 [ERROR] [wlr] [backend/drm/drm.c:813] connector DP-3: Failed to initialize renderer for plane
Dec 15 14:07:15 doug-laptop /usr/libexec/gdm-wayland-session[2495]: 01:30:48.790 [ERROR] [sway/config/output.c:417] Failed to commit output DP-3

[sethidden]

My workaround is to change virtual terminals to the one where gdm is running, which brings the monitor back to live, and then back to the sway vt.

Did this workaround stop working for anyone else with the recent sway 1.7 and wlroots 0.15 releases? On 1.6 I was doing CTRL+ALT+F2 to switch to the non-sway tty (it wasn't running gdm, it's just the default login tty) then switch back with CTRL+ALT+F1 and the external monitor would work

[TheNamelessWonderer]

Just for reference for people being annoyed by this bug as I was, this module parameter worked around it for me:
snd_hda_codec_hdmi.enable_acomp=off snd_hda_codec_hdmi.enable_silent_stream=off

I have the same issue on 1.7. Only one of my monitors will turn back on. Does this work for amd and intel GPUs?

[sethidden]

Here I said that this is caused by setting a non-default mode, but today I realized that this is related to #6711 (comment)
My monitor is 4K, but my iGPU only supports 4k@30fps, so I set it to the closest available 60fps mode 2560x1440@60hz, but seems that this mode doesn't work, even tough it appears in sway -t get_outputs normally.

The solution for me was to go to an even lower resolution mode - 1920x1080. Now that is pretty crowded, so I change the scaling. This is not a great solution, but it's a lot better than having the monitor not turn on at all. I'm on sway 1.7 and wlroots 0.15.1. All environment vars are disabled, so WLR_DRM_NO_ATOMIC and WLR_DRM_NO_MODIFIERS are not present in /etc/environment

output DP-2 res 1920x1080
output DP-2 scale 0.75

[camoz]

I have the same (or similar) problem with sway 1.7 and one external monitor connected to an X200 (Intel GMA X4500MHD), where the external monitor and the laptop screen would not wake up after swaylock and DPMS off/on. In my case, the laptop lid is closed all the time during normal usage. My config:

exec swayidle -w \
    timeout 3600 'swaylock -f' \
    timeout 3597 'swaymsg "output * dpms off"' \
    resume 'swaymsg "output * dpms on"'

My current workaround (to bring both monitors back online):

• open laptop lid (does nothing yet)
• switch to virtual console by pressing Ctrl-Alt-F2 and log in
• SWAYSOCK=<path-to-sway-socket> swaymsg output '*' toggle
• switch back to sway (still nothing)
• close and open lid -> sway shows up
• 2x swaymsg output HDMI-A-2 toggle -> external monitor back online

[cartok]

I have a similar issue with a Notebook which has an Intel CPU. My screens (3) are connected to a Dell docking station. Left and Right function properly, connected via DP but the HDMI screen in the middle is black after the first time I disabled dpms. I do not get it back on and if I connect it directly to the HDMI port it works but then one of the other screens stays off.

May case was solved through #5008 by swaywm/wlroots#1877

[akhiljalagam]

I am having the same issue. screen won't wakeup after swaylocked and dpms off. I have to reboot it.
using waylock now and no issues.

[Iss-in]

@akhiljalagam does your monitor wakes up after running swaymsg "output * dpms off" && sleep 60 && swaymsg "output * dpms on" in a terminal after a minute ?

[akhiljalagam]

@Iss-in yes.

this is what worked for me with waylock. (sleep only when locked)

revert() {
	dunstctl set-paused false
}

dunstctl set-paused true
trap revert HUP INT TERM
killall swayidle
swayidle -w \
timeout 10 'if pgrep waylock; then swaymsg "output * dpms off"; fi' \
resume 'swaymsg "output * dpms on"' &
waylock --init-color "#000000" --input-color "#0000FF" --fail-color "#FF0000" --fail-command "im-msg.sh failed authentication"
killall swayidle
revert

[Iss-in]

@akhiljalagam can you pls explain it a bit more, you are using this script to lock sway session manually , right ?
what are your settings for auto suspend on inactivity ? can you pls share your sway config as well

edit: turns out to be an issue in nouveau driver which was solved after adding nouveau.runpm=0 to kernal params, all's well now " :)

[akhiljalagam]

@akhiljalagam can you pls explain it a bit more, you are using this script to lock sway session manually , right ? what are your settings for auto suspend on inactivity ? can you pls share your sway config as well

this is my config for auto suspend. this is working too. (but iam not using this now)

swayidle -w \
	timeout 300 'swaylock -e -u -f -c #000000' \
	timeout 600 'swaymsg "output * dpms off"' \
		resume 'swaymsg "output * dpms on"' \
	before-sleep 'swaylock -e -u -f -c #000000' &

the problem is that if i lock manually using this -> #5759 (comment) with swaylock then screen is not waking up. i replaced it with waylock and it worked.

[dzintars]

Similar issue happens on just one of my MDP display when i turn it off physically. Sometimes, rarely, it won't wake up after turning it on. Basically only full reboot helps. Never had no issues with swayidle (in 2 years or so).

[rplanchuelo]

I use "suspend" instead of dpms off:
timeout 300 'systemctl suspend'
In addition, it is better because it consumes less power

[sethidden]

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

[RunningDroid]

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

[dzintars]

Not sure is it related there, but sometimes I can't get one of my displays wake up after i turn it off in the middle of work.
AMD GPU. MiniDP.
If lock the screen with swaylock and then turn off then I never had issues to wake it up. But if i will turn right now, most likely I will not be able to get it back to life. Only full reboot helps. echo detect | sudo tee /sys/class/drm/card0-DP-1/status does nothing. But had not noticed the same issue with other HDMI display.

[RunningDroid]

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

[Kabbone]

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

so far it looks like the sound is not broken, just the enumeration of HDMI outputs changes.

Here is also a discussion about it.

[mnd999]

The amdgpu / mesa bug is a thing and very annoying but this bug massively predates it and is present on Intel and Nvidia as well.

[dzintars]

I had noticed that display turns on after a while. Like... 3-5 minutes. SOMETIMES

[ahartik]

I experienced this same problem with current master branch version of sway (90c2d63). 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.

[emersion]

@ahartik, if you cannot reproduce with latest release, then it's a different bug. Please open a separate issue with full debug logs.

[dimosped]

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

[abrahm]

Running ubuntu lunar 13.10 and sway 1.7, had this issue. Installed sway 1.8.1 and swayidle 1.8.0 to see if the problems were resolved, but this bug is still there.

When I resume from swayidle -w timeout 300 'swaymsg "output * power off"' resume 'swaymsg "output * power on", one monitor usually does not resume. If both do resume, often one monitor has the wrong resolution.

The following set of commands reliably restores both of my displays displays to their pre-idle states:

swaymsg reload
swaymsg output DP-2 enable
swaymsg output DP-2 power on
swaymsg output DP-2 mode 3840x2160@60Hz pos 0 0
swaymsg output DP-3 enable
swaymsg output DP-3 power on
swaymsg output DP-3 mode 3840x2160@60Hz pos 3840 0

I put those commands in a script and run something like swayidle -w timeout 300 'swaymsg "output * power off"' resume '$HOME/.local/bin/restore-sway-outputs.sh'. It works like it should now!

Thanks @dimosped for the inspiration. swaymsg reload was key to making this work.

[itaranto]

I'm experiencing a similar issue but in my case it's not a laptop but a desktop with only one monitor. I can reproduce it 100% of the time by running:

swaymsg "output * dpms off" && sleep 60 && swaymsg "output * dpms on"

I didn't know where to post the debug logs since I'm not sure it's the same issue or not. I posted my results here.

[dzintars]

Some time ago in Bios I changed SOME CPU related setting which I don't remember which one it was exactly. Since then (6+ months) I never encountered this monitor thing anymore. Same GPU. Same configs. Same everything.

[itaranto]

Some time ago in Bios I changed SOME CPU related setting which I don't remember which one it was exactly. Since then (6+ months) I never encountered this monitor thing anymore. Same GPU. Same configs. Same everything.

I doubt this could be a BIOS config issue, since I have Windows installed in this system too and resuming from DPMS works fine there.

[dzintars]

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.

[jgarvin]

Still seeing this in sway 1.9. swayidle putting all my outputs to sleep (2 monitors, 1 laptop screen), left monitor doesn't come back. Running the off->sleep->on reproducer above puts them all to sleep, then on wake both monitors are on but now the laptop screen is off.

Is this possibly a race where sway is reacting to the first event for the outputs coming back, but the others may or may not get coalesced depending on scheduler timing?