DPMS not powering off monitors

darenw · 2019-12-20 14:44:33

It used to work...

How things worked a month or two ago: After 20 minutes of inactivity, Xscreensaver (ver 5.43) runs. Abstract art shows. After 45 minutes, the monitors turned off. Off means no backlight, no faint glow, pure darkness in the room overnight (not counting LEDs on computer and UPS).

How things work now, though I didn't change any settings: Screensaver starts after 20 minutes. It runs forever. Monitors never power off or go into any backlight-off mode. Glow of screen lights room all night long.

I tried 'xset s 60 90 120' to see if the normal sequence, sped up, would happen. Nothing happened, not even the normal screensaver. I killed the screensaver process, in case it was messing with things, but no difference.

Only changes that happened that might affect how something works was running pacman -Syu every few weeks.

Here is relevant portions of the output of 'xset q':

Screen Saver:
prefer blanking: yes allow exposures: yes
timeout: 600 cycle: 600
DPMS (Energy Star):
Standby: 61 Suspend: 71 Off: 82
DPMS is Enabled
Monitor is On

V1del · 2019-12-20 15:45:24

It's always amazing how people can list syptoms and not lose a single word about which actual system or hardware they are seeing this on.

Shot in the dark, you are using nvidia, they've switched to an alternate DPMS implementation try setting the relevant option to false with e.g.

/etc/X11/xorg.conf.d/10-nvidia.conf

Section "Device"
  Driver "nvidia"
  Option "HardDPMS" "false"
EndSection

seth · 2019-12-20 16:03:57

Also try "xset dpms force off" and check "loginctl session-status" to see whether you're maybe on a wayland session.

darenw · 2019-12-20 16:59:08

The xset command makes the screens go black for a couple seconds, then they're back to normal, without the keyboard or mouse being touched.

The loginctl status spews a lot of stuff (I have a lot of images, browsers, text editors up) but grep shows mention of x11, no mention of wayland. The start of it goes:

darenw-arsenic 0=> head ~/temp/S -n22
1 - darenw (1000)
Since: Sun 2019-12-08 11:03:21 MST; 1 weeks 4 days ago
Leader: 533 (login)
Seat: seat0; vc3
TTY: tty3
Service: login; type tty; class user
State: active
Unit: session-1.scope
├─ 533 login -- darenw
├─ 545 -bash
├─ 48159 /bin/sh /usr/bin/startx
├─ 48181 xinit /etc/X11/xinit/xinitrc -- /etc/X11/xinit/xserverrc :0 vt3 -keeptty -auth /tmp/serverauth.gvg6EXYF4X
├─ 48182 /usr/lib/Xorg -nolisten tcp :0 vt3 -keeptty -auth /tmp/serverauth.gvg6EXYF4X
├─ 48188 icewm --replace
├─ 48193 conky
├─ 48277 /usr/bin/python2 /usr/bin/mirage /home/darenw/temp/CR0.png
├─ 48279 /usr/bin/python2 /usr/bin/mirage /home/darenw/temp/CR1.png
├─ 48281 /usr/bin/python2 /usr/bin/mirage /home/darenw/temp/CR2.png
├─ 48283 /usr/bin/python2 /usr/bin/mirage /home/darenw/temp/CR3.png

seth · 2019-12-20 19:24:56

It would seem something™ periodically(?) breaks the DPMS state, either explicitly or through some spurious (synthetic?) input.
Please post the complete loginctl session-status (use code tags or https://wiki.archlinux.org/index.php/Pastebin to feed the output into a pastebin service) so we can start a random blame-game on the culprit.
Also maybe run "sudo libinput debug-events" to look out for spurious HW events.

krutoileshii · 2019-12-21 01:34:30

had similar issues with amdgpu which was a result of the monitors pulling the inputs.

https://bbs.archlinux.org/viewtopic.php?id=243452. found a workaround, but not a solution to this. what hardware are you running?

darenw · 2019-12-21 01:40:37

I'm using an Nvidia GTX 1050. Nothing that smells like AMD within a mile of here.

krutoileshii · 2019-12-21 01:43:54

Mine had issues with NVIDIA as well on a GTX 1070, see if your monitor has input pooling (on mine input selection=auto). that was pooling the inputs and waking it up every time. also, just a note this only manifested it for me when two monitors were connected, worked as expected with just 1.

darenw wrote:

I'm using an Nvidia GTX 1050. Nothing that smells like AMD within a mile of here.

Last edited by krutoileshii (2019-12-21 01:44:52)

darenw · 2019-12-21 01:45:50

Now that I think about it, this could be related to Wayland. There was a time about two (?) months ago I tried switching from my usual X11 + icewm, no login manager setup to KDE with a login manager. Just to try it out. After two days I removed most of the KDE stuff, went back to icewm. I'm not sure, I didn't write down any notes, but maybe the monitor power-off was okay before then, and functioned no more after.

seth · 2019-12-21 07:56:12

Unlikely, the wayland problem would have been that xdpms doesn't work on wayland and xset operates on a meaningless xwayland dummy.

seth wrote:

Please post the complete loginctl session-status (use code tags or https://wiki.archlinux.org/index.php/Pastebin to feed the output into a pastebin service) so we can start a random blame-game on the culprit.
Also maybe run "sudo libinput debug-events" to look out for spurious HW events.

You can also clean up your xinit, just "exec xterm" (after the mandatory include block that's supposed to be in your ~/.xinitrc) and see whether you can force dpms there w/o any interference (pointing to some client causing this, eg. by faking mouse events to prevent a screensaver or so)

Arch Linux

#1 2019-12-20 14:44:33

DPMS not powering off monitors

#2 2019-12-20 15:45:24

Re: DPMS not powering off monitors

#3 2019-12-20 16:03:57

Re: DPMS not powering off monitors

#4 2019-12-20 16:59:08

Re: DPMS not powering off monitors

#5 2019-12-20 19:24:56

Re: DPMS not powering off monitors

#6 2019-12-21 01:34:30

Re: DPMS not powering off monitors

#7 2019-12-21 01:40:37

Re: DPMS not powering off monitors

#8 2019-12-21 01:43:54

Re: DPMS not powering off monitors

#9 2019-12-21 01:45:50

Re: DPMS not powering off monitors

#10 2019-12-21 07:56:12

Re: DPMS not powering off monitors

Board footer