How do I set zero brightness on laptops that have a nonzero minimum brightness on the brightness control?
The solution should work regardless of X. I.e. it should also work in the virtual terminals.
How do I set zero brightness on laptops that have a nonzero minimum brightness on the brightness control?
The solution should work regardless of X. I.e. it should also work in the virtual terminals.
In the realm of laptops with Intel chipsets, there seems to be a division between the LVDS- and eDP-connected panels:
echo 4 > /sys/class/backlight/intel_backlight/bl_power …should turn off the backlight.
echo 0 > /sys/class/backlight/intel_backlight/bl_power I have discovered that it is not possible to turn off the backlight on my Thinkpad X201 and X201 tablets via sysfs (bl_power does nothing; apparently, it is eDP-specific).
This page has a very lengthy description of the convoluted history of the backlight control in the linux kernel. TL;DR:
i915 has supported bl_power for eDP panels (but not LVDS) starting from v3.18.
HOWEVER, I have been able to make the backlight turn off by using a tool called intel_backlight from intel-gpu-tools. This requires root, since it apparently writes to a raw register.
intel_backlight 0 ...turned the backlight off for me. Bumping it up with brightness adjustment controls re-enabled it here.
I also wrote a script that I hooked up to fire on a keyboard-generated ACPI event (in my case, fn+space, or button/zoom. If your system doesn't use that ACPI event, you need to use acpi_listen to find one that your system does have.
To trigger it, I made a file called fnspace-backlight in /etc/acpi/events:
# Wyatt Ward # hook for magnify acpi event (fn+space) # toggle LCD backlight on/off event=button/zoom action=/etc/acpi/actions/toggle-lcd-light.sh I also made a file called /etc/acpi/actions/toggle-lcd-light.sh, marked as executable. This lets me toggle the backlight without changing the previously set brightness level, storing the temporary value in /brightness. Since ACPI events run actions as root, be careful.
#! /bin/bash BRIGHTSAVEFILE="/brightness" BRIGHTSYSFS="/sys/class/backlight/acpi_video0/brightness" # is the light on or off? INTEL_BACKLIGHT="/usr/bin/intel_backlight" light_state=$("$INTEL_BACKLIGHT" | sed 's/current backlight value: //g'|sed 's/%//g') echo "light: ""$light_state" if [ "$light_state" -eq 0 ]; then cat "$BRIGHTSAVEFILE" > "$BRIGHTSYSFS" else # back up current brightness level cat "$BRIGHTSYSFS" > "$BRIGHTSAVEFILE" # turn off backlight "$INTEL_BACKLIGHT" 0 fi Ad an additional fun note, you can control backlight with an incredible amount of granularity by modifying intel_backlight slightly. Changing it to read arguments as floating point numbers rather than integers, and to do floating point arithmetic, only requires tweaking a few lines of code and lets you make ridiculously precise brightness changes, including ones lower than the minimum you can get via sysfs.
From X Windows you can use the application xbacklight to get and set the percent brightness for your screen.
current level
$ xbacklight -get 100.000000 set to 75%
$ xbacklight -set 75 $ xbacklight -get 73.333333 set back to 100%
$ xbacklight -set 100 $ xbacklight -get 100.000000 To achieve something similar for a virtual terminal you'll likely need to interact with the ACPI settings via the /sys filesystem.
dims it
$ echo "10" | sudo tee /sys/class/backlight/acpi_video0/brightness 10 full brightness
$ echo "15" | sudo tee /sys/class/backlight/acpi_video0/brightness 15 You'll have to play with this one, the range of brightnesses can be from 0-9 or 0-15, I believe it ultimately depends on your laptop.
If neither of these 2 options suites your needs take a look at the ArchLinux Wiki's topic titled: Backlight. That article contains every method I've ever seen employed to achieve this!
vbetool dpms off also turns off the LCD. However, this happens a fraction of a second after the backlight and vbetool dpms on turns the LCD on a fraction of a second before the backlight, so maybe there's still a way to do this generically. Or maybe that delay is also a result of BIOS firmware code.