The ThinkPad E14 has a light up power button. It’s very futuristic looking: its a thin ring around the circular power button. But, it is a bit of a bother when I’m watching movies. I hunted around the internet looking for a way to turn it off. This is Linux. The LED on the power button is a device.
/sys/class/leds/tpacpi::power/brightness
So you can do things like
# Get LED setting
cat '/sys/class/leds/tpacpi::power/brightness'
# Turn it off!! From the command line!!
echo 0 | sudo tee /sys/class/leds/tpacpi::power/brightnessOf course, once I found that out, there was no stopping. I quickly made this a script
# In ~/bin/led-off.sh
#!/bin/bash
echo 0 | tee /sys/class/leds/tpacpi::power/brightnesswhich I would invoke using
sudo led-off.shI didn’t want to have to type in my password each time, so I added the script to my sudoers file.
#in /etc/sudoers.d/kghose
kghose ALL=(ALL) NOPASSWD: /home/kghose/bin/led-off.shAwesome!
But the problem was that every time the computer woke from sleep the system would turn the LED on. Invoking sudo /home/kghose/bin/led-off.sh each time I opened the lid grew tedious.
After further searching on the internet I figured out how to run the script automatically each time the computer woke from sleep:
# In /lib/systemd/system-sleep/led-off
#!/bin/sh
case "$1" in
post)
echo 0 | sudo tee /sys/class/leds/tpacpi::power/brightness
;;
esac
Perfect! At least until I remembered that the ThinkPad’s power button was also a finger print reader. I didn’t really need a fingerprint reader: I was quite happy logging in with my password, but hey, anything to save a few keystrokes amirite?
I searched on the Lenovo website and found that they had a Linux driver for my finger print reader. I installed it and WooHoo! the finger print reader started working. It was also the first time I’d seen the power LED go a shade of blood red. It was quite cool: the computer would come out of sleep or lock screen and the power button would start flashing red. I would tap my finger on it and I’d log in.
Problem was that the fingerprint driver, or whatever it was flashing the LED, overwrote the LED state and didn’t restore it. So I was back to having the LED being on when the laptop came out of sleep. Bother!
After more searching on the internet, it turns out that there is a way to detect when the computer unlocks the screen, using something called dbus-monitor (which is quite cool, and it’s fascinating to see the programs broadcast messages on the dbus).
# In ~/bin/dbus-led-off.sh
#!/bin/bash
while read x
do
case "$x" in
*"boolean false"*) sudo /home/kghose/bin/led-off.sh;;
esac
done < <(dbus-monitor --session "type='signal', interface='org.gnome.ScreenSaver'")
And this script I run on desktop start up, by adding
# In ~/.config/autostart/led-off.desktop
[Desktop Entry]
Type=Application
Exec=dbus-led-off.sh
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name[en_US]=Battery Rate
Name=Battery Rate
Comment[en_US]=Taskbar notification for power draw
Comment=Taskbar Notification for power draw
Ahhhh! I can watch movies in peace again! Not that I got a lot of movie watching done, with all the internet searches, and reading up about dbus and so on and so forth. But it’s the principle that counts …
Pages from the fire 
One wonders if you could use systemd instead (since you mention being on Ubuntu — and most Linux distros use systemd anyway). It’s not that I’m a huge fan of systemd, but it has caught on, and it’s also here to stay for at least a decade or so (then something else will suddenly become fashionable instead… wash, rinse, repeat 😛 ).
Despite its name, systemd also works on a user basis, i.e. it launches things on request when someone logs in or off, and such things are under the full control of the user — no need to tamper with system configuration whatsoever. And I always like the ability of doing a systemctl –failed (or systemctl –user –failed for user-specific things).
Oh, and you’ll also be pleased to know that systemd also uses the D-Bus. Lately, on the trivial daemons I write on Go, which usually rely on systemd to launch on start etc., I have been fond of writing to the D-Bus — it’s a way to let systemd know when you’re finished with the setup, when you’re ready to accept requests, etc., even to change the status, and so forth. Quite useful for something that is supposed to “play nicely” with the rest of the uncountable system-specific daemons that are already being managed by systemd…
Granted, since you’re using GNOME, I guess there is limited use (for you, that is) to deal with systemctl directly; GNOME, after all, will happily run anything from the autostart directory.
I just happen to use a Mac as my workstation (which uses launchd, Apple’s own management tool that inspired the development of systemd) and so log in remotely to plethora of Linux servers (at home and remotely!), so user-based systemd makes much more sense in such an environment.