Hi,

I'm running Debian testing, sporting KDE 4.12.4, on a Asus G55VW. At some point using KDE 4.11.x I had no trouble using my Fn+F3,F4 to change my keyboard's backlight brightness. An update (I wasn't keeping track so I can't say it was the 4.11 -> 4.12 migration or before that) eventually messed that up.

The hardware is working properly:

Code: Select all

# echo 1 > /sys/class/leds/asus::kbd_backlight/brightness


THe above does the trick and changes the keyboard backlight brightness to level 1 of 3.
Furthermore, xev reports the correct keycodes (as far as I can tell) for the the combinations Fn+F3 and Fn+F4.:

Code: Select all

KeyRelease event, serial 46, synthetic NO, window 0x7800001,
    root 0x289, subw 0x0, time 3638383, (105,55), root:(105,78),
    state 0x0, keycode 238 (keysym 0x1008ff05, XF86KbdBrightnessUp), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 46, synthetic NO, window 0x7800001,
    root 0x289, subw 0x0, time 3639413, (105,55), root:(105,78),
    state 0x0, keycode 237 (keysym 0x1008ff06, XF86KbdBrightnessDown), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False


Finally the correct configuration appears to be in place, in the System Settings > Shortcuts and Gestures > Global Keyboard Shortcuts > KDE Daemon for the fields of: Decrease/Increase keyboard brightness

But it still doesn't work! (except using echo as superuser). I've also noticed it works fine with an old script I used to use before KDE added this functionality in the 4.11 release. I suppose I could go back to the script, but I would prefer to fix what's broken with KDE.

Any help is appreciated!

Thanks

Andres

If you click on the battery applet, are you able to change the brightness using the controls offered there?

bcooksley wrote:If you click on the battery applet, are you able to change the brightness using the controls offered there?

Yes, but the controls I see are ONLY for screen brightness. I'm talking about the keyboard brightness (and I don't see any controls there)

Sorry - I got the screen/keyboard rightness confused.

Are you automatically logging in by any chance? If so, if you logout and then back in, does that have any impact on the visibility of keyboard brightness controls?

bcooksley wrote:Sorry - I got the screen/keyboard rightness confused.

Are you automatically logging in by any chance? If so, if you logout and then back in, does that have any impact on the visibility of keyboard brightness controls?

I am NOT logging in automatically. However, I did as you suggested, logged out and then back in and that did the trick!, it works flawlessly now.... I'm confused why on first login it doesn't work though.. any clues?

It is probably because necessary services haven't yet started or the driver hasn't yet loaded - which prevents the keyboard backlight from being detected. Unfortunately KDE's Power Management system doesn't watch for new devices after it's initial scan (or it isn't possible to do so) which is why it only shows up on the subsequent login.

If you wait 30 seconds or so after your system starts up and then login, does this also alleviate the issue?

bcooksley wrote:It is probably because necessary services haven't yet started or the driver hasn't yet loaded - which prevents the keyboard backlight from being detected. Unfortunately KDE's Power Management system doesn't watch for new devices after it's initial scan (or it isn't possible to do so) which is why it only shows up on the subsequent login.

I see. That is unfortunate. The curious thing is that it was working at some point, but suddenly this changed, I guess this is some sort of race condition.
The kernel module responsible for the driver is asus-nb-wmi. I wonder if there's a way to speedup its loading.

bcooksley wrote:If you wait 30 seconds or so after your system starts up and then login, does this also alleviate the issue?

I've accidentally tried this in the past and It does not help.

Before logging in to the KDE desktop, could you check to see if the asus-nb-wmi module is loaded?
I suspect that it may be the KDE startup process which triggers the loading of this module - which is too late for it to be of use.

bcooksley wrote:Before logging in to the KDE desktop, could you check to see if the asus-nb-wmi module is loaded?
I suspect that it may be the KDE startup process which triggers the loading of this module - which is too late for it to be of use.

I tested this and the answer is YES, the module is loaded before login. I don't understand what's wrong.
Let me know if you have you other suggestions

Andres

Unfortunately i'm out of ideas - you could try comparing the output of "upower -d" in a broken and working session though (at least on my system it doesn't cover brightness devices, so i'm not sure if it will be of relevance in this case).

bcooksley wrote:Unfortunately i'm out of ideas - you could try comparing the output of "upower -d" in a broken and working session though (at least on my system it doesn't cover brightness devices, so i'm not sure if it will be of relevance in this case).

Well, in a "broken system", using the CLI I can change the keyboard backlight brightness by using upower as follows:

Code: Select all

dbus-send --type=method_call --print-reply=literal --system       \
        --dest='org.freedesktop.UPower'                               \
        '/org/freedesktop/UPower/KbdBacklight'                        \
        'org.freedesktop.UPower.KbdBacklight.SetBrightness'           \
        "int32:${value}}"


where ${value}} can be 0,1,2 or 3.

So what I'm saying is that upower works like a charm. I used to have a script using this command for controlling the keyboard backlight brightness in previous KDE versions.

Just wondering, before logging into KDE could you login on a VT and check to see if UPower is running on the system bus?
(Don't try to directly call it as this will cause it to launch).

If it is not running, does calling UPower and making it start allow subsequent KDE sessions to work properly?

bcooksley wrote:Just wondering, before logging into KDE could you login on a VT and check to see if UPower is running on the system bus?
(Don't try to directly call it as this will cause it to launch).

I changed to a VT, logged in and tried this command:

Code: Select all

ps aux | grep upower

The result was that upower is NOT running on the system prior to login.

bcooksley wrote:If it is not running, does calling UPower and making it start allow subsequent KDE sessions to work properly?

Simply invoking upower didn't trigger it to run on my system. What I did, was to invoke the command to change keyboard brightness, as I posted earlier.
After this, the upower daemon appeared in the list of running processes.
I logged out of the VT, logged in KDM and success! KDE recognized the keyboard brightness capabilities of my laptop.

It seems this is expected from upowerd:

upowerd provides the org.freedesktop.UPower service on the system
message bus. Users or administrators should never need to start this
daemon as it will be automatically started by dbus-daemon(1) whenever
an application calls into the org.freedesktop.UPower service.

I will submit the information in a bug report with Debian. Do you know how to remedy the situation in the meantime? (i.e. make upowerd start before login).
Thanks!

Try creating a script in ~/.kde4/env/ which simply runs "qdbus --system org.freedesktop.UPower". This should be enough to trigger UPower to start up.
In this case I think the bug may actually be in KDE - as we should be detecting the presence of new brightness mechanisms or batteries as they become available (assuming UPower is informing us of them) although it is probably also a bug in UPower that this information only becomes available some point after it's initial start.

bcooksley wrote:Try creating a script in ~/.kde4/env/ which simply runs "qdbus --system org.freedesktop.UPower". This should be enough to trigger UPower to start up.

Thank you! this works!

bcooksley wrote:In this case I think the bug may actually be in KDE - as we should be detecting the presence of new brightness mechanisms or batteries as they become available (assuming UPower is informing us of them) although it is probably also a bug in UPower that this information only becomes available some point after it's initial start.

I see. Where should I submit this bug report?