Description of problem: Gnomeo n wayland appears aunabel to use dpms to put the monitor to sleep Version-Release number of selected component (if applicable): xorg-x11-server-Xwayland-21.1.2.901-1.fc34.x86_64 How reproducible: Use Fedora, do not touch the keyboard nor move mouse for at least the timeout periods Actual results: monitor not going into 'sleep' Expected results: monitor going to sleep after timout(s) of screensaver Additional info: $ xset -q Keyboard Control: auto repeat: on key click percent: 0 LED mask: 00000000 XKB indicators: 00: Caps Lock: off 01: Num Lock: off 02: Scroll Lock: off 03: Compose: off 04: Kana: off 05: Sleep: off 06: Suspend: off 07: Mute: off 08: Misc: off 09: Mail: off 10: Charging: off 11: Shift Lock: off 12: Group 2: off 13: Mouse Keys: off auto repeat delay: 500 repeat rate: 33 auto repeating keys: 00ffffffdffffbbf fadfffefffedffff 9fffffffffffffff fff7ffffffffffff bell percent: 50 bell pitch: 400 bell duration: 100 Pointer Control: acceleration: 2/1 threshold: 4 Screen Saver: prefer blanking: no allow exposures: no timeout: 0 cycle: 0 Colors: default colormap: 0x3f BlackPixel: 0x0 WhitePixel: 0xffffff Font Path: catalogue:/etc/X11/fontpath.d,built-ins DPMS (Energy Star): Server does not have the DPMS Extension It is a blatant failure to even save power when it easily can be saved
And this page mentions a QA contact? I do not see effects of any QA here due to bugs like this one.
With `busctl --user set-property org.gnome.Mutter.DisplayConfig /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode i 1` I can get the monitor to go black and show a message about going to sleep, after which the desktop returns. So this dpms thing is a mutter thing? If so, please change accordingly.
With Wayland, Xwayland is not the the display server (unlike Xorg with an Xorg session) - Xwayland is just a compatibility layer for legacy X11 applications which cannot be ported to Wayland natively, it's an X11 server for X11 applications but also a fairly standard Wayland client like any other. All that to say that Xwayland has no control over the display power management itself, this is a function implemented in the display server which with Wayland is the Wayland compositor, i.e. GNOME Shell/mutter for GNOME. So of course, using an X11 specific tool such as xset to cotnrol DPMS cannot work, whereas using GNOME specific interfaces to control DPMS in the Wayland compositor will work. No bug here, unless I misunderstand what you meant.
I do not claim to understand the whole GUI stack; I jsut want the system to use dpms. You imply that mutter is the right spot? (for gnome on wayland etc)
(In reply to udo from comment #4) > I do not claim to understand the whole GUI stack; I jsut want the system to > use dpms. This is why I take the time to give a lengthy explanation. > You imply that mutter is the right spot? (for gnome on wayland etc) Yes, but I fail to understand the bug itself.
I am assuming that you've setup the expected power saving options in GNOME Control center. If, configured correctly, the screen is not put to sleep when it should then yes, chances are this would be a bug in mutter indeed. Could be https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4114
I am moving this to gnome-shell instead as this is where the lock screen is actually implemented (comment 2 states that forcing the state with DBus correctly put the monitor to sleep, which would rule out a bug in mutter, most likely).
My 'power' gnome control center page shows no explicit DPMS mention. Just 'blanking' whatever that means.
(In reply to Olivier Fourdan from comment #7) > I am moving this to gnome-shell instead as this is where the lock screen is > actually implemented (comment 2 states that forcing the state with DBus > correctly put the monitor to sleep, which would rule out a bug in mutter, > most likely). Thanks!
(In reply to udo from comment #8) > My 'power' gnome control center page shows no explicit DPMS mention. > Just 'blanking' whatever that means. Yes, you're right, that setting actually (should) control(s) the sleep time as well.
(In reply to udo from comment #0) > Actual results: > monitor not going into 'sleep' Can you clarify this? Does the screen turn black, but the backlight stays on? Or does the session remain visible normally? (In reply to udo from comment #2) > With `busctl --user set-property org.gnome.Mutter.DisplayConfig > /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode > i 1` I can get the monitor to go black and show a message about going to sleep, after which the desktop returns. FWIW, it might turn back on immediately because the enter key is released after the command runs. Try something like sleep 1 && busctl ... to avoid that.
For some backgrounds: https://en.wikipedia.org/wiki/Energy_Star I.e.: It has been a while.
In the technical field: https://en.wikipedia.org/wiki/VESA_Display_Power_Management_Signaling I.e.: It has been a while. So who decided that functional DPMS support was less of a priority than the rest of stuff that is pushed onto our systems? (weak designs and absurd choices like documented in my bugzilla) In other words: when (approximately) can we expect this basic feature to be ready?
(In reply to Michel Dänzer from comment #11) > (In reply to udo from comment #0) > > Actual results: > > monitor not going into 'sleep' > > Can you clarify this? Does the screen turn black, but the backlight stays > on? Yes.
(In reply to Michel Dänzer from comment #11) > FWIW, it might turn back on immediately because the enter key is released > after the command runs. Try something like > > sleep 1 && busctl ... > > to avoid that. This does not appear to fix the situation.
still happening in F36 running this command only turn off the screens for roughly 5 seconds and then the screens turned back on busctl --user set-property org.gnome.Mutter.DisplayConfig /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode i 1 gpu: RX6650XT with amdgpu Wayland version: xorg-x11-server-Xwayland-22.1.3-1.fc36.x86_64
(In reply to Izhar Firdaus from comment #16) > […] > Wayland version: xorg-x11-server-Xwayland-22.1.3-1.fc36.x86_64 FTR, Xwayland is just a compatibility layer for X11 applications, nothing to do with the version of Wayland, but anyhow it's a problem with neither Xwayland nor Wayland. > running this command only turn off the screens for roughly 5 seconds and then the screens turned back on Maybe a stoopid idea, but could that be just a notification waking up the screen? For example, this will wake up my screen after 10 seconds here: sleep 10; notify-send -u critical "Wake up NOW!"
Running this, screen still turns on after 5 seconds or so. So I don't think it is notification. busctl --user set-property org.gnome.Mutter.DisplayConfig /org/gnome/Mutter/DisplayConfig org.gnome.Mutter.DisplayConfig PowerSaveMode i 1 && sleep 2 && notify-send -u critical "Wake up NOW!"
You are right, I just confirmed that this is not Wayland. Disabled wayland by setting WaylandEnable=false in /etc/gdm/custom.conf and restarted gdm. in Xorg, this issue is also replicatable when running: xset dpms force off. My laptop in office running F35 + Xorg + IntelUHD does not have this issue, but let me confirm if i can replicate this issue after upgrading that to F36 in a week time.
An update. Tested on my laptop after upgrading to F36. Seems like issue is not replicatable on this laptop. Could it be issue in amdgpu driver?.
Created attachment 1904224 [details] monitor not turning off IntelUHD with external monitor Just noticed that when external monitor is connected to laptop (intelUHD), both monitors stops turning off. So the issue is replicatable in this condition.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.