11

[Note: Noticed a similar question but it never received a response.]

I am using i3 on archlinux. I have setup DPMS to suspend my display after 2 minutes of inactivity (xset dpms 0 120 180). However, I've noticed that it doesn't always kick in automatically. I don't think it's a hardware issue as performing an xset dpms force works without a problem.

My settings:

$ 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: 660 repeat rate: 25 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: yes allow exposures: yes timeout: 0 cycle: 600 Colors: default colormap: 0x22 BlackPixel: 0x0 WhitePixel: 0xffffff Font Path: /usr/share/fonts/TTF/,/usr/share/fonts/OTF/,built-ins DPMS (Energy Star): Standby: 0 Suspend: 120 Off: 180 DPMS is Enabled Monitor is On

How can I determine what is preventing my display from suspending as per the DPMS settings?

Improve this question
4
  • Some mediaplayers disable DPMS, you have to configure those to not do that. It will also help to narrow down under what circumstances it doesn't kick in (which applications are running etc.) - without that information, we are basically guessing . You can also use xset dpms force to test if your hardware is acting up. Commented Mar 31, 2018 at 10:52
  • I've tried a DPMS force and that works fine. I don't have any dedicated media player although I usually have chromium running which is what I suspect is the culprit. However, I was hoping for a more deterministic way (e.g., a log or a command I could run in the background) to figure out which app is causing the problem. Aware of anything like that? Commented Mar 31, 2018 at 12:37
  • You can use an application like xscope to monitor traffic between the X server and clients like chromium, but AFAIK you can't filter for protocol extensions like DPMS (what xset uses), so you'd probably end up with a lot of data to wade through. Commented Mar 31, 2018 at 14:26
  • @dirkt: Unless I misunderstand, xscope is something you need to opt-in to using before you run applications. In the problem cases, you already have some running applications causing havok and you are trying to find which one it is. I think xscope would not help with that? Commented Jan 4, 2023 at 16:54

3 Answers 3

Reset to default
5

You can use this small program to check whether it may be a result of some user input (overly sensitive mouse?) or an app actively resetting the XScreenSaver extension idle timer:

#include <stdio.h> #include <X11/Xlib.h> #include <X11/extensions/scrnsaver.h> /* Report amount of X server idle time. */ /* Build with- */ /* cc xidle.c -o xidle -lX11 -lXext -lXss */ int main(int argc, char *argv[]) { Display *display; int event_base, error_base; XScreenSaverInfo info; float seconds; display = XOpenDisplay(""); if (XScreenSaverQueryExtension(display, &event_base, &error_base)) { XScreenSaverQueryInfo(display, DefaultRootWindow(display), &info); seconds = (float)info.idle/1000.0f; printf("%f\n",seconds); return(0); } else { fprintf(stderr,"Error: XScreenSaver Extension not present\n"); return(1); } }
Improve this answer
1
  • On Debian this needs apt install build-essential libx11-dev libxss-dev to build. Commented Mar 26, 2020 at 3:49
3

To anyone hitting this in 2022, check .xsession_errors in your $HOME and see if something isn't preventing standby. In my case, one video in chrome was preventing the monitor turning off by DPMS

powerdevil: Enforcing inhibition from ":1.23" "/usr/bin/google-chrome-stable" with cookie 3821 and reason "Video Wake Lock" powerdevil: Added change screen settings powerdevil: Added interrupt session powerdevil: Disabling DPMS due to inhibition
Improve this answer
0

To improve on @L29Ah's answer, there is a program on Github to print how long X has gone without input events: https://github.com/g0hl1n/xprintidle

So to isolate whether an X input is preventing the monitor from suspending you do:

$ xset dpms 3 3 3 # Set your monitor to turn off after 10 seconds: $ while true; do sleep 1 && xprintidle; done

If the time keeps increasing even after 3 seconds then it's not X input that's preventing the monitor going off.

In my case it was a stray SMPlayer window that must've thought it was focused when it really wasn't. So keep closing windows until you find the one that's preventing suspend.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.