Dell keyboard backlight behavior recently broke

I have a Dell Studio 1558 with keyboard backlighting. My problem has to do with the backlight no longer turning back on once it has turned off.

Historically, I have had to edit /etc/dbus-1/system.d/org.freedesktop.UPower.conf and comment out the following two lines for keyboard backlighting to work:

<allow send_destination=“org.freedesktop.UPower”

Recently I discovered that this file had been moved to /usr/share/dbus-1/system.d/org.freedesktop.UPower.conf, where I repeated my edit, but have still been having problems that once my keyboard backlight turns off, it won’t turn back on by keyboard or touchpad activity.

Further investigation showed that the contents of the file start_triggers in /sys/class/leds/dell::kbd_backlight (also found in /sys/devices/platform/dell-laptop/leds/dell::kbd_backlight) are set to “-keyboard -touchpad”.

When I edit the file to contain “+keyboard +touchpad” things work for a while. When the keyboard backlight turns off, keyboard or touchpad activity turns it back on.

My problem is that something keeps changing the file contents back to “-keyboard -touchpad”, which leaves me having to turn the keyboard backlight back on using the function key - something hard to do in the dark!

When I do turn on the keyboard backlight with the Fn-F6 function key (which is only supposed to be used to changing brightness), the start_triggers file is again modified by the system to “+keyboard +touchpad”, but this goes away after a while with the contents reverting to “-keyboard -touchpad”.

I’ve not determined the exact parameters of when the keyboard backlight is disabled, whether it’s just a matter of time, or letting the laptop sleep or something else. And I have no idea what process is playing with start_triggers.

Any help if getting this back under control will be greatly appreciated.

Does this happen when connected to AC power and when running from battery? A search on the subject seems to bring up numerous threads concerning upower, but not sure they are completely relevant to this situation. A bug report may be required to help resolve this perhaps.

Just to check that

sudo systemctl show upower.service | grep ProtectKernelTunables



as expected.

I’ve moved to Leap 15.2 and am having this problem there too.

This is on AC power and I do get:

Adding to the fun, /etc/dbus-1/system.d/org.freedesktop.UPower.conf is gone, so I don’t even have what to comment out to try and fix. (The fix of commenting out mentioned in my original post did work in Leap 15.1.)

I had gone from Tumbleweed down to Leap 15.1 because of this bug. Now that this bug is in Leap 15.2, I have nowhere to go in order to keep my keyboard backlight working. :frowning:

Thank you again for any help you can give.

OK, I’ve found a workaround, but still would like to get to the underlying problem.

In summary, as shipped, Leap 15.2 (and Tumbleweed, last time I checked) will change /sys/class/leds/dell::kbd_backlight/start_triggers from “+keyboard +touchpad” to “-keyboard -touchpad” a few minutes after the keyboard backlight has timed out and gone off. As a result, the keyboard backlight doesn’t turn back on thereafter unless I hit Fn+F6, which normally controls the backlight brightness.

Similar to what I did in Leap 15.1, I found the file /usr/share/dbus-1/system.d/org.freedesktop.UPower.conf. In it, I commented out:

<!--    <allow send_destination="org.freedesktop.UPower.KbdBacklight"
<!--    <allow send_destination="org.freedesktop.UPower"

which seems to have fixed the symptom (and hence the annoyance), if not the underlying problem.

Any idea what the actual underlying problem is?


Ok, that checks out as expected.

Adding to the fun, /etc/dbus-1/system.d/org.freedesktop.UPower.conf is gone, so I don’t even have what to comment out to try and fix. (The fix of commenting out mentioned in my original post did work in Leap 15.1.)

The upower package provides /usr/share/dbus-1/system.d/org.freedesktop.UPower.conf, but you should be able to override this by copying to /etc/dbus-1/system.d/ and editing the configuration as you require.

If you can’t resolve this your self, I would recommend submitting a bug report.

I have no idea what the underlying problem is, but I do recommend that you copy the working configuration to /etc/dbus-1/system.d/ instead, as that is the place to undertake system admin configuration. A upower package update may replace your custom configuration as it is.