[WORKAROUND] GNOME/Plasma wake up display, standby mode

lpr1 · 2023-09-29 15:50:35

I basically got this issue since I changed my old display, old display was using VGA connector, new one HDMI, tried different cable, tried disabling DDC/CI (suggested in other posts).

When using "xset dpms force standby", display goes into the standby mode as expected, shows no signal msg, LED indicator change it's color, all fine, and then, it wakes up with input msg, backlight got on, LED indicator returns to the ON color and screen shows black until mouse/kb input.

In LXDE, MATE, Cutefish everything works as expected, when using "xset dpms force standby", display does all the same things, except it doesn't wake up until user input.

The only relevant difference I can see in journal is that modelist lines are repeated in GNOME etc., while it's not repeated on working DEs. These lines:

/usr/lib/gdm-x-session[1004]: (II) modeset(0): EDID vendor "AUS", prod id 9426
 /usr/lib/gdm-x-session[1004]: (II) modeset(0): Using hsync ranges from config file
 /usr/lib/gdm-x-session[1004]: (II) modeset(0): Using vrefresh ranges from config file
 /usr/lib/gdm-x-session[1004]: (II) modeset(0): Printing DDC gathered Modelines:
 /usr/lib/gdm-x-session[1004]: (II) modeset(0): Modeline "1920x1080"x0.0  148.50....

and then again, at the same time stamp

 /usr/lib/gdm-x-session[1004]: (II) modeset(0): EDID vendor "AUS", prod id 9426
 /usr/lib/gdm-x-session[1004]: (II) modeset(0): Using hsync ranges from config file...

and this afterwards:

 /usr/lib/gdm-x-session[1004]: (WW) modeset(0): Present-flip: queue async flip during flip on CRTC 0 failed: Invalid argument

while on LXDE etc. it shows it only once.

I doubt this is relevant, but these issues are also present in gnome-shell

 gnome-shell[1106]: Can't update stage views actor <unnamed>[<MetaWindowActorX11>:0x55dfeaf89b00] is on because it needs an allocation.
 gnome-shell[1106]: Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:0x55dfea6a1db0] is on because it needs an allocation.
 /usr/lib/gdm-x-session[1004]: (II) modeset(0): EDID vendor "AUS", prod id 9426....

It happens with or without xf86-video-amdgpu installed. In Windows it also works without any issue, same as on LXDE etc. Really annoying thing, any suggestion?
PS: If in wrong section, please move it.
PS1: Forgot to mention, I did try different login managers, no difference, LXDE with GDM works properly for example.

Last edited by lpr1 (2023-10-15 03:04:06)

Skidout · 2023-10-01 04:55:43

GNOME & Plasma are probably using Wayland by default, while the other DEs you tried are all using X11. See if it happen on something like Sway or Deepin Wayland.

lpr1 · 2023-10-01 05:13:15

Skidout wrote:

GNOME & Plasma are probably using Wayland by default, while the other DEs you tried are all using X11. See if it happen on something like Sway or Deepin Wayland.

Sorry, I forgot to mention, it's X11, on GNOME for sure, but I think when I tested it was on Plasma as well. It happens on Cinnamon, I didn't try Deepin because it's based on GNOME even more than Cinnamon so it will likely have the same issue, Sway I can't test.

Last edited by lpr1 (2023-10-01 12:38:25)

lpr1 · 2023-10-15 02:59:55

So, this is the only workaround that actually works for my case, enforce-dpms script for GNOME:
https://github.com/dwagelaar/enforce-dpms

It's unbelievable that this issue isn't resolved after 4+ years, some basic functionality..., more details and potential solutions for Plasma and other DEs having the same issue in bug report ("HDMI connected monitors fail to sleep and instead turn back on when amdgpu.dc=1") here:
https://gitlab.freedesktop.org/drm/amd/-/issues/662

I can't mark it as solved, since this workaround isn't really an actual solution, so I would mark it as "WORKAROUND" if that is fine.

Last edited by lpr1 (2023-10-15 03:05:35)

seth · 2023-10-15 07:21:59

https://gitlab.freedesktop.org/drm/amd/-/issues/662

tl;dr, but the problem is systematic and cannot be "fixed"
The output is put to sleep, the output unregisters, some overzealous "screen management that just works" daemon kicks in to reconfigure the screens, polls all outputs, that wakes the HDMI, it re-registers and the screen management daemon either accespts the status quo or ends up configuring the output twice.
This is also why this doesn't happen in less smart™ environments.

The only way out of this is to mute the screen management daemon b/c you can likely not influence the behavior of the panel (typically a Tv) and it is probably not an option for the server to simply block all randr calls during DPMS in order to fix some client that's kinda stupidsmart.

lpr1 · 2023-10-15 19:27:43

seth wrote:

https://gitlab.freedesktop.org/drm/amd/-/issues/662
tl;dr, but the problem is systematic and cannot be "fixed"
The output is put to sleep, the output unregisters, some overzealous "screen management that just works" daemon kicks in to reconfigure the screens, polls all outputs, that wakes the HDMI, it re-registers and the screen management daemon either accespts the status quo or ends up configuring the output twice.
This is also why this doesn't happen in less smart™ environments.
The only way out of this is to mute the screen management daemon b/c you can likely not influence the behavior of the panel (typically a Tv) and it is probably not an option for the server to simply block all randr calls during DPMS in order to fix some client that's kinda stupidsmart.

Exactly, but it can be "fixed", proof for that is WIndows, as well as other DEs, such as MATE for example, or XFCE (I think it works there properly as well, I forgot what I tested, MATE for sure), LXDE etc.

Why reinventing the wheel when you can apply already working solutions? Either way, this is temporary workaround, until (if ever) it actually gets addressed.

seth · 2023-10-15 19:31:55

proof for that is WIndows, as well as other DEs

Because those environments don't try to be overly smart and respond to changes to the outputs with fooling around with the outputs (notably polling them)

The workaround you linked effectively enters a race with such daemon - isntead you could just just disable the daemon (possible for KDE, "kscreen" - not sure about gnome)

lpr1 · 2023-10-15 19:41:15

seth wrote:

proof for that is WIndows, as well as other DEs
Because those environments don't try to be overly smart and respond to changes to the outputs with fooling around with the outputs (notably polling them)
The workaround you linked effectively enters a race with such daemon - isntead you could just just disable the daemon (possible for KDE, "kscreen" - not sure about gnome)

Yes, but GNOME is more "smart" than that, so yeah, killing/disabling kscreen in Plasma would be a solution I guess. I suspect this does affect more users than what we actually see, with newer hardware, avoiding AMDGPU.DC is not even possible (my case), and some displays (my case as well) do not offer the option to select manual input..., so yeah, going into "smart(tm)" stuff, I expect this will have to be addressed at some point, I'm honestly surprised it isn't for such a long time.

seth · 2023-10-15 19:44:51

amdgpu.dc is mandatory for a while now, but I kinda doubt that this is amdgpu specific. There're many instances of it and I'm pretty sure at least some had intel chips.

Enter a "dumb" environment and run "xset dpms force off; sleep 5; xrandr -q", does that (xrandr call) wake the output?

lpr1 · 2023-10-15 19:55:00

seth wrote:

amdgpu.dc is mandatory for a while now, but I kinda doubt that this is amdgpu specific. There're many instances of it and I'm pretty sure at least some had intel chips.
Enter a "dumb" environment and run "xset dpms force off; sleep 5; xrandr -q", does that (xrandr call) wake the output?

True, but potential "solution" offered for the issue by multiple users is disabling DC (pre Vega hardware), It mostly happens on AMD GPUs for some reason, there are very few Intel users, and only one post I saw related to nvidia, someone explained that it's either hardware "less sensitive" to those calls made by "smart" display, so they got ignored, but that can't be the case because of "dumb" environments work properly. Another suggestion was related to polling rate of the GPU, but I didn't really understand it TBH.

Any "dumb" environment seems to work fine in my case, example MATE DE with it's own default compositor and login manager, as well with mix of GDM + MATE. I did not try that command, but with standard "xset dpms force standby" or "xset dpms force off", display does not wake up in MATE for example, so I'm not sure if after that there's a particular reason why to try that, but if there is one, it's not an issue to do it in ttyx for example.

seth · 2023-10-15 20:39:54

The relevant part is the xrandr call that'll most likely "accidentally" wake your output after the dpms activation - apparently it's no longer possible to disable this in gnome because "if made a feature, would be a nightmare for most users", https://askubuntu.com/questions/1397092 … f-displays

lpr1 · 2023-10-15 22:18:19

seth wrote:

The relevant part is the xrandr call that'll most likely "accidentally" wake your output after the dpms activation - apparently it's no longer possible to disable this in gnome because "if made a feature, would be a nightmare for most users", https://askubuntu.com/questions/1397092 … f-displays

I'm not holding my breath for GNOME "features", since even standard stuff is broken, RetroArch doesn't work properly in fullscreen mode for quite some time already, so yeah, it's either using this workaround or changing DE, the former solution is a better one for my workflow. I don't see how having an option would be a nightmare for most users, but oh well..., until someone is annoyed enough with this issue and have a knowledge to make a working solution and a chance to upstream it in GNOME, it's like this sadly.

Arch Linux

#1 2023-09-29 15:50:35

[WORKAROUND] GNOME/Plasma wake up display, standby mode

#2 2023-10-01 04:55:43

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#3 2023-10-01 05:13:15

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#4 2023-10-15 02:59:55

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#5 2023-10-15 07:21:59

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#6 2023-10-15 19:27:43

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#7 2023-10-15 19:31:55

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#8 2023-10-15 19:41:15

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#9 2023-10-15 19:44:51

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#10 2023-10-15 19:55:00

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#11 2023-10-15 20:39:54

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

#12 2023-10-15 22:18:19

Re: [WORKAROUND] GNOME/Plasma wake up display, standby mode

Board footer