! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xflock4 does not turn off screen due to lack of sleep


Description Chris Bainbridge 2015-01-31 14:03:53 CET
As noted at http://www.shallowsky.com/linux/x-screen-blanking.html calls to "xset dpms" need to be prefixed with "sleep 1":

    will blank the screen (or activate the screensaver program, if you're using
    one) after a delay of one second. You need the delay because X gets a little
    confused about the order of events; it will blank the screen but immediate
    un-blank it, thinking the activity of your typing the command happened
    recently enough to come out of screensaver mode.

    sleep 1; xset dpms force off

    will turn the screen OFF after a delay of one second. You can also use
    standby, suspend, or on instead of off.

Downstream bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776674
Comment 1 Chris Bainbridge 2015-02-08 13:50:49 CET
Created attachment 5915 
Comment 2 Steve Dodier-Lazaro editbugs 2015-02-08 18:07:02 CET
I can reproduce the issue, but the patch does not work for me (Xfce 4.11, ArchLinux 64 bits, xscreensaver 5.32).

@OP, what screensaver do you use, and does the patch work for you?

@Other triagers, could you please test the patch?
Comment 3 Chris Bainbridge 2015-02-08 21:27:28 CET
@Steve Yes the patch works for me using slock. 
What exactly fails for you?
Does "sleep 1; xset dpms force off" successfully turn off the monitors on your system?
Do you have one of {xscreensaver-command,light-locker-command,gnome-screensaver-command} installed? If so, the xset dpms line in xflock4 is never executed.

(can't seem to change bug status back from needinfo..)
Comment 4 Steve Dodier-Lazaro editbugs 2015-02-08 21:36:33 CET
Hi Chris,

When I type xset dpms force off in a terminal, my screen is turned off. Xflock4, with or without delay, always fails to turn my screen off. I believe the screensaver is the culprit, it probably talks to the X11 server and causes it to wake up.
Comment 5 Steve Dodier-Lazaro editbugs 2015-02-08 21:38:11 CET
Errata; after uninstalling xscreensaver, the patch still does not work.
Comment 6 Chris Bainbridge 2015-02-08 22:15:53 CET
Can you try "slock & sleep 1; xset dpms force off"

Also try "sh -x /usr/bin/xflock4" and see if the xset line is actually being executed. It won't be if you have xscreensaver, light-locker or gnome-screensaver installed.
Comment 7 Steve Dodier-Lazaro editbugs 2015-02-12 03:20:22 CET
Ok, I've been a bit silly on that one. So, when having slock installed I reach this code path.

With the patch: 1 second delay, then a black screen
Without the patch: black screen immediately

Now, on desktops, when using a mouse, it's quite easy to trigger the mouse after the screen has been forced off. Still, a whole second is a bit excessive.

I'd like more developers to weight in before applying the patch.
Comment 8 Steve Dodier-Lazaro editbugs 2015-02-12 03:21:19 CET
Chris, thanks for writing the patch and bearing with me though. Of course if you can link to others complaining about the issue, and to more precise reasons why it is systematically happening for you, it'll increase the odds of people weighing in favour of your patch.
Comment 9 Chris Bainbridge 2015-02-12 11:47:11 CET
> With the patch: 1 second delay, then a black screen
> Without the patch: black screen immediately

slock will always show a black screen but is the monitor actually turned off with DPMS - my monitor shows "Entering power save mode" when this happens and turns off the back light.

Try this: in a terminal type "xset dpms force off" and press and hold the enter key for one second before releasing it. The key press event will cause the execution of the xset command, but then the release event will wake the monitor back up. The same happens with the ctrl-alt-delete shortcut.

> Of course if you can link to others complaining about the issue


The explanation:

"You're using it manually from command line or xset is binded to some keyboard shortcut? On my brother laptop this command was binded to some keys and after that monitor was turned off and on again, because when he was releasing key next event was emitted. Turning it off after quick sleep solved problem: perl -e 'select(undef,undef,undef,.1)' && xset dpms force off - this perl expression do sleep for 0.1 sec."

The timeout has to be longer than the delay between a person pressing the enter key and then releasing it.
Comment 10 Robert Moskowitz 2015-02-12 18:37:48 CET
Also see:


This is a real pain with my notebook screen not going off when locked.  In a hotel room at night, I have to put a towel over the screen to get to sleep myself!  When at my desk at home, the external monitor is brightly lit when locked, lighting up the whole room at night.

I am concerned about long-term effects on the backlight feature failing if not corrected.

Since I am running Fedora 21, please let me know what I have to do to test a patch.

thank you
Comment 11 Robert Moskowitz 2015-02-24 05:05:05 CET
Same problem with:


On my Cubietruck through its VGA adapter.  I probably will get around to testing with HDMI tomorrow as well as testing on my Cubieboard2.

The usual:  You set screensaver to use a blank screen, and lock the screen.

Screen blanks, but backlight stays on.
Comment 12 Chris Rainey 2018-11-07 21:12:31 CET
Still happening in Xubuntu 18.10. I vote for adding the patch!

$ hostnamectl 
   Static hostname: CKR-2
         Icon name: computer-laptop
           Chassis: laptop
        Machine ID: 5c61c71187fa4ba4aa26bdd89516ee5a
           Boot ID: 9a2e3fb61f6d461d9b423cdeebaa4c57
  Operating System: Ubuntu 18.10
            Kernel: Linux 4.18.0-10-generic
      Architecture: x86-64
Comment 13 Simon Steinbeiss editbugs 2019-04-28 00:52:39 CEST
@Chris: Does a sleep of <1sec also work?

I personally side with Steve regarding the excessive nature of adding a full second. Otherwise I'm ok with merging this patch.
Comment 14 Chris Rainey 2019-05-01 16:35:01 CEST
@Simon: apologies, if your previous comment is directed at me. I'm currently on Ubuntu 19.04(Gnome 3) without a proper XFCE4 installation to test this on.
Comment 15 Jarno Suni 2020-01-01 18:12:31 CET
Maybe some implementations of sleep do not allow non-integer number argument.
Comment 16 Jarno Suni 2020-01-02 00:04:34 CET
I do not see a problem in having even longer delay than a second. But, using "sleep 1; xset dpms force off" has still the problem that user may accidentally touch something so that display will become on again. Besides, it effectively disables Presentation mode user may have set using Power manager's panel item.

A better solution would be to change DPMS settings for the time such a screen locker is running to enable turning display off after reasonable time of inactivity from user, and restore previous settings, when user unlocks. This is possible by using a wrapper script.

I have actually introduced such a version of xflock4 in bug report https://bugzilla.xfce.org/show_bug.cgi?id=10217
in 2017. It uses 15 second delay, but an initial delay of 1 second could be added.

That script has other modifications such as added screensavers and lockers and optionally using display power management for the locker user may have set in Xfconf. The script can be simplified notably, if hacking the DPMS settings for general lock command set in Xfconf is left out.

I have never got any feedback about the script.

Note: proper screensavers (that have a daemon running when lock command is called) should handle DPMS by themselves.
Comment 17 Jarno Suni 2020-01-02 17:17:12 CET
Created attachment 9348 
improved xflock4

Note that even this improved xflock4 script never gets past xfce4-screensaver-command, because of bug 15945 which should be fixed ASAP. That is, if xfce4-screensaver is installed.
Comment 18 Git Bot editbugs 2020-05-26 00:47:01 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-session/-/issues/29.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #11491

Reported by:
Chris Bainbridge
Reported on: 2015-01-31
Last modified on: 2020-05-26


Simon Steinbeiss
CC List:
9 users




xflock4-sleep.patch (354 bytes, patch)
2015-02-08 13:50 CET , Chris Bainbridge
no flags
improved xflock4 (2.45 KB, text/plain)
2020-01-02 17:17 CET , Jarno Suni
no flags

Additional information