I would like to force my screen to blank, and leave it stay blank regardless of what I do with my keyboard and mouse until it receives a command to unblank (kind of like a lock).

The commands I know are:

xset dpms force off
sleep 2
xset dpms force on

I only want it to blank for two seconds then unblank, but I want it to absolutely stay blank for these two seconds no matter what. Can this be done?


You could just disable your keyboard and mouse for the duration. First, get your keyboard and mouse IDs:

$ xinput --list
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Logitech M325                             id=14   [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3    [master keyboard (2)]
    ↳ SIGMACHIP USB Keyboard                    id=11   [slave  keyboard (3)]

I have various things connected to my machine and am running a laptop so the output of xinput --list is very long. I have redacted it here for clarity. You need to figure out what the IDs of the devices you need to disable are. In my case, they were 14 and 11.

Now, switch off your screen, disable your keyboard and mouse, wait 2 seconds and switch everything back on again:

xinput set-prop 'Logitech M325' 'Device Enabled'  0 &&
xinput set-prop 'SIGMACHIP USB Keyboard' 'Device Enabled' 0 &&
xset dpms force off &&
sleep 2 &&
xinput set-prop 'Logitech M325' 'Device Enabled' 1 &&
xinput set-prop 'SIGMACHIP USB Keyboard' 'Device Enabled' 1 &&
xset dpms force on

On my system, SIGMACHIP USB matches more than one device. For some reason it is also identified as a mouse. To be 100% sure of getting the right devices, you can prepend their class to their name:

xinput set-prop 'pointer:Logitech M325' 'Device Enabled'  0 &&
xinput set-prop 'keyboard:SIGMACHIP USB Keyboard' 'Device Enabled' 0 &&
xset dpms force off &&
sleep 2 &&
xinput set-prop 'pointer:Logitech M325' 'Device Enabled' 1 &&
xinput set-prop 'keyboard:SIGMACHIP USB Keyboard' 'Device Enabled' 1 &&
xset dpms force on
  • Probably better to use absolute names rather than id's that could change between boots. Then again, doesn't seem to always work either. Not a very great program, but I guess it'll do.
    – Cestarian
    Feb 28 '16 at 13:19
  • I tried this though, and quite unfortunately it does not work. It does stop the mouse and keyboard from moving, sure, but for whatever reason if I disable my mouse and move it around while the screen is blank, even if no input should have been received, the screen won't blank. Might be related to the fact that I'm running synergy, (this machine is the host) might not. Does it work for you?
    – Cestarian
    Feb 28 '16 at 13:27
  • @Cestarian good point, I edited it to use the IDs. As for not working, really? That's odd, I tried it on my Arch and it worked as expected. Are you sure you disabled the right devices? Try disabling everything.
    – terdon
    Feb 28 '16 at 13:29
  • 1
    Nah I figured I made an error. I had to run the commands in a different order, or more specifically I had to disable the devices before the xset dpms force off command (might wanna edit that in). This works, thanks!
    – Cestarian
    Feb 28 '16 at 13:31

You can use xrandr. For example if your display is HDMI1 you can do

xrandr --output HDMI1 --off
sleep 2
xrandr --output HDMI1 --auto

You can find the name with

xrandr|grep ' connected'
  • Actually yes, this works very well, but I'm gonna stick with the other answer since xrandr ... --auto can mess up your screen configuration. But this is a good and much cleaner alternative if you have a simple setup, like me.
    – Cestarian
    Feb 28 '16 at 13:43
  • 1
    Actually nope, fucked up my desktop after doing it a few times, figures, but still good in cases it wouldn't do so.
    – Cestarian
    Feb 28 '16 at 13:51

I finally figured out an answer that at least works on my systems (a Lenovo ThinkPad X201 and a ThinkPad X201 Tablet, which both use LVDS panels). It actually disables the backlight, but unless you have a transflective or reflective LCD (which is pretty unusual), it should effectively be the same as having the LCD switched off.

First, I installed Intel GPU Tools (README here for more information). In debian, this was done with:

# apt-get install intel-gpu-tools

This package contains a program called intel_backlight, which directly interacts with Intel GPUs' registers and thus is not limited to the 'safe range' in modern Linux kernels' sysfs filesystem, where brightness level 0 is always supposed to be 'on at a low level of brightness.'

Unfortunately, this program needs to be run as root, and it doesn't really sanitize its inputs very well (it just blindly atoi()'s the first argument to the script and assumes it's actually a number). I'm still working on a proper solution to this, but for now your options are to either:

  1. Run this as root
  2. Write a script and acpid configuration to trigger it upon a specific ACPI event.

I chose the latter option. I picked a key combination which acpi_listen detected as firing an ACPI event, but which was not mapped to do anything already on my laptop. I chose fn+f1. Theoretically, one could also have it fire on the brightness-down key, check if the brightness was already at the minimum, and if so turn off the backlight.

I wrote the following files:


action=/etc/acpi/toggle-thinklight-or-tablet-lcd.sh "%e"


#! /bin/bash
# intel_backlight appears to require root privs.

# is the light on or off?
export INTEL_BACKLIGHT="/usr/bin/intel_backlight"
export light_state=$("$INTEL_BACKLIGHT" | sed 's/current backlight value: //g'|sed 's/%//g')
if [ "$light_state" -eq 0 ]; then # if the backlight is currently off
  # restore brightness level
  cat /root/brightness > /sys/class/backlight/acpi_video0/brightness
else # the backlight is currently on
  # back up current brightness level
  cat /sys/class/backlight/acpi_video0/brightness > /root/brightness
  # turn off backlight

Be sure the shell script is marked as executable.

Maybe not exactly what was wanted, and I know I'm late to the party, but it's working here.

Alternatively, on eDP panels, doing echo 0 > /sys/class/backlight/acpi_video0/bl_power might work. This absolutely will not work on LVDS panels, because apparently some kernel developers thought that was a good idea.

  • For me, intel_backlight throws a Floating point exception and exitcode 136. Jul 19 '19 at 13:08
  • You do have an intel graphics chipset, correct?
    – Wyatt Ward
    Jul 19 '19 at 18:14
  • Yes (Machine: GPD Pocket; I am confused about all those chip names and so dont know what the graphics chip is), and on my previous machine (Lenovo Thinkpad X200 tablet) I also had one and vbetool dpms off did work, now it does not (Real mode call failed) why I am searching for other solutions which are independent of X-Server or VT and work directly on the hardware. Jul 20 '19 at 17:24
  • Might want to run intel_backlight in gdb, then, because it sounds to me like your computer's haunted.
    – Wyatt Ward
    Jul 21 '19 at 7:11
  • Compiled with debugging options: Running in gdb: Program received signal SIGFPE, Arithmetic exception.0x00005555555551ca in main (argc=1, argv=0x7fffffffe1d8) at ../igt-gpu-tools-1.24/tools/intel_backlight.c:4848 printf ("current backlight value: %d%%\n", current * 100 / max); -- Looks like it searches for values somewhere where none are found. Chip: lspci -v: 00:02.0 VGA compatible controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series PCI Configuration Registers (rev 34) (prog-if 00 [VGA controller]), SoC is Intel Atom x7-Z8750 Jul 21 '19 at 8:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.