Comment 50 for bug 1510344

I am working in Dell. I have some digging on this issue. There are two symptoms reported in the thread – the keyboard backlight unexpectedly turns ON on boot and after the resume from a screen lock. These are due to two different causes.

- the backlight unexpectedly turns ON on boot, regardless of the previous state of brightness. This is an intentional behavior of “unity-settings-daemon”. This daemon reads the brightness value of kbd_backlight (via “upowerd”) when system starts up, and turn it on (via upowerd) if the read value is 0 (which indicates the backlight is off). Even worse, the daemon does not make this behavior configurable.

- The backlight unexpectedly turns ON after the resume from a screen lock, regardless of the previous state of brightness. The “unity-settings-daemon” also deals with power management things. It turns the backlight off when the system is about to dim screen for power saving reason. Also, the daemon thought itself as the only S/W piece that can set the brightness of backlight and no other ones will change it, so it does not query for the current state of backlight before dimming it. But the fact is, Dell’s BIOS already dimmed the backlight due to a timeout of idle. When screen resumes, the daemon resumes the backlight to ON as it assumed the backlight was ON before dim.

The issue should start happening since the introduce of commit 6cff8d60aa0aba5583ecda09984dbcb2f24cc28d (pointed out in #5), because it implements a new “kbd_backlight” driver in dell-laptop kernel module. It it gives the chance to “upowerd” for having the control over the keyboard backlight hardware on Dell laptops.

The workaround provided in #47 does work because it denies “unity-settings-daemon” from sending DBUS commands that regarding kbd_backlight set/get to upowerd.