0

I'm controlling screensaver (well, locking in my case) via xss-lock and xset:

$ xset s 600 30 $ xss-lock --notifier=screenlock-notifier.sh --transfer-sleep-lock -- locker.sh

where

  • screenlock-notifier.sh provides dimming and other logic, gets executed after 600s of inactivity;
  • locker.sh switches the screens off via xset dpms force off and launches xsecurelock; this happens after 30s of inactivity upon screenlock-notifier execution: 
    $ xset dpms force off $ /usr/bin/env XSECURELOCK_SAVER=saver_blank xsecurelock

My question is, why do xset dpms * commands also trigger the execution of locker.sh, given dpms flags should have nothing to do with screensaver?

E.g. executing xset dpms 5 0 0 will cause locker.sh to run in 5seconds, although the command should've simply set the standby flag to 5 seconds -- nothing to do with screensaver.

xss-lock manual states:

The locker is executed in response to events from these two sources: • X signals when screen saver activation is forced or after a period of user inactivity (as set with xset s TIMEOUT). In the latter case, the notifier command, if specified, is executed first. • The login manager can also request that the session be locked; as a result of loginctl lock-sessions, for example. Additionally, xss-lock uses the inhibition logic to lock the screen before the system goes to sleep.

xset manual states the following regarding dpms:

The dpms option allows the Display Power Management Signaling (DPMS) parameters to be set. The option can take up to three numerical values, or the force flag followed by a DPMS state. The force flags forces the server to immediately switch to the DPMS state specified. The DPMS state can be one of standby, suspend, off, or on. When numerical values are given, they set the inactivity period (in units of seconds) before the three modes are activated. The first value given is for the standby mode, the second is for the suspend mode, and the third is for the off mode. Setting these values implicitly enables the DPMS features. A value of zero disables a particular mode.

From here I gather xss-lock runs locker only upon screen saver activation flags (and login manager events), and xset dpms does not modify screensaver flags.

What's going on?

Improve this question

1 Answer 1

Reset to default
1

X11 by default includes two screensavers. One is manipulated with xset s and the other with xset dpms.

xset s has a handful of commands and two parameters, the first sets the screen blank timeout, the second is the number of seconds between background changes to prevent burn in; however, it can also be told to just blank the screen.

xset dpms is intended to be a hardware blanker that turns the monitor off in stages, and takes timeout parameters to reach each stage. With CRT screens, this made sense, as you could turn off the ray without powering down the high voltage circuits, and then later turn off everything which then required a warm up time to turn it back on. (DPMS actually supports 3 stages which in a CRT correspond to modes with progressively longer warmup times.) Of course, modern hardware can turn on and off pretty much instantly, so this is now irrelevant.

The idea was that these two methods would work in concert, first displaying a pretty background, then after a longer delay, put the monitor in standby mode, and then eventually turning it off completely.

Also, your graphical session manager could implement its own screensaver. Traditionally, this would be something like XScreensaver which would be activated by the xset s timeouts draw pretty patterns on the screen or something. Later on, the screensaver was also used to activate a screen lock. The xss-lock utility taps into the hooks for what was intended to be the session manager's screensaver and lock. So, as the basic screensaver and DPMS work in concert, either one of them can activate your add-on screensaver and session lock.

Note also that the timeouts are not the only way to activate it. The xset s activate or xset dpms force ... commands should also activate it.

Modern session managers (like gnome) implement their own independent screensaver that replaces, works with, and interferes with these older mechanisms.

Improve this answer
4
  • xset dpms is intended to be a hardware blanker - that's my point - it's to do with hardware, not software side of things such as screensavers. Commented Nov 4 at 13:15
  • [xset dpms force] command should also activate it -- had no idea about that. Super messy stuff. Commented Nov 4 at 13:15
  • Modern session managers (like gnome) implement their own independent screensaver that replaces, works with, and interferes with these older mechanisms. ...only adding on to this, IMHO, a hot mess. Thank you for your input! Commented Nov 4 at 13:16
  • software triggering a hardware feature? surprise ... but the point is, it also triggers screen lock...which is in the name of your command so... Commented Nov 4 at 23:42

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.