So, the Web is truly an amazing thing! After much research and diving into many forum links, I managed to better understand the problem, to find out what program was responsible for it and, finally, to disable this behavior for good. I thought I'd write down my steps, in case other people run into the same issue.
Step 1. Monitor the system to know if/when the keyboard backlight is being turned on
The first thing is to know that the current status of the keyboard backlight can be checked by reading the file /sys/devices/platform/dell-laptop/leds/dell\:\:kbd_backlight/brightness
. So, we would like to be notified of any changes to this file and, ideally, what process invoked the change.
This can be done using fanotify. I used the example program that is provided in the man page and added a few modifications* so that I could monitor changes to the brightness file. Turns out that the process responsible for the modification was /usr/lib/upower/upowerd
, which is a daemon process for UPower.
Step 2. Find out why UPower is turning the backlight on (fail)
This was the fuzziest part of the investigation, and I still can't tell why this happens. I found a person with a very similar problem but with no solution, so I started to see if I could just disable UPower completely (and what would the consequences be) when I found this link. Turns out UPower has a configuration file! That's better.
Step 3. Stop UPower from turning on the keyboard backlight
Finally, I edited the aforementioned config file, located at /etc/dbus-1/system.d/org.freedesktop.UPower.conf
, and changed <allow>
to <deny>
in the following line:
<allow send_destination="org.freedesktop.UPower"
send_interface="org.freedesktop.UPower.KbdBacklight"/>
I then restarted dbus with sudo service dbus restart
(use systemctl restart dbus.service
on Ubuntu 16.04 and later) and proceeded to lock my screen to test the result and... It worked!! Well, sorta. The login screen wouldn't show up, so I couldn't log back in and had to force a restart. But then everything worked great!
And that's it! I'm still curious what would be the right way to do this. If you know, leave a comment, please!
* For instance, the example program was only set up to monitor FAN_OPEN_PERM
and FAN_CLOSE_WRITE
events, but in this it was an FAN_MODIFY
event.
hardinfo
package and the keyboard is displayed as "AT Translated Set 2 keyboard" by vendor "1". Does that help at all?...