I have a thinkpad T430 which recently gained a better keyboard backlight driver. It works in a VT both with the keyboard shortcut (FN+Space) or via dbus, however, it breaks when inside a Plasma 5 session, as there is an endless loop of the backlight cycling between the 3 states. qdbus --system org.freedesktop.UPower /org/freedesktop/UPower/KbdBacklight org.freedesktop.UPower.KbdBacklight.GetBrightness 0 qdbus --system org.freedesktop.UPower /org/freedesktop/UPower/KbdBacklight org.freedesktop.UPower.KbdBacklight.GetMaxBrightness 2 Reproducible: Always Steps to Reproduce: 0. Have a Thinkpad T430 (other models might be affected too, I don't have any) 1. Be in a Plasma 5 session 2. Change the Keyboard backlight, either via keyboard, via dbus or via the battery plasmoid Actual Results: Brightness endlessly cycles through possible states Expected Results: Brightness is set correctly, as it is when switching to a VT Plasma is 5.6 Beta, Qt is 5.5.1, Kernel is 4.5 Any information on how I could debug and solve this is appreciated.
Looking at the code so far, my best guess would be that it tries to round (with the very limited amount of steps, 0,1,2) and horribly fails, which never lets it rest at a certain value. If that is the case, I hope the logic can be adapted to cope with that. Otherwise someone needs to dig a bit further.
Ignore the last comment, actual issue is the following: per default the key triggers keycode 236 (keysym 0x1008ff04, XF86KbdLightOnOff), which by default in KDE Plasma is configured to toggle the keyboard light. However, at the same time the keyboard light is changed by the BIOS. This seems to get plasma / powerdevil in a confused state so it doesn't stop cycling through them. If somehow possible, I highly recommend disabling that default keybinding on affected thinkpads. If not possible some logic will be needed to avoid that, because otherwise owners of affected hardware will run into this issue with recent kernels and KDE plasma, changing their keyboard brightness leading to an endless cycle (which, as a side effect, triggers the lovely pop up which won't disappear either. In short: the session is rendered quite unusable) If I can somehow help resolving this issue (xev or dbus monitor logs or whatnot): let me know. Workaround for me: disable that keybinding in systemsettings.
As discussed on IRC: I also checked why using the slider or dbus would trigger the buggy behaviour. As expected, the driver is silly enough to emit keycode 236 (keysym 0x1008ff04, XF86KbdLightOnOff) even if you didn't touch the keyboard, it just does this on all keyboard brightness changes. Huzzah.
Thanks a lot for your investigation! While this is definitely a driver but and it's utterly stupid to emit key events on non key presses, ie. you tell PowerDevil to change brightness, it emits a keyboard event which tells PowerDevil to do something yet again. But you convinced me that it's serious enough to disable the default key binding for this keyboard shortcut as I have yet to see a laptop that actually has this key... Marking as confirmed and major so I don't forget.
(In reply to Kai Uwe Broulik from comment #4) > I have yet to see a laptop that actually has this key... What do other laptops emit when pressing the key combination to change keyboard backlight brightness?
Keyboard brightness up / down
Oh okay, they do that directly? Fine, then.
As a sidenote there is a BIOS setting on how the brightness key should behave, I can't remember whether that is only related to the thinklight (which gets turned on after 3 presses) or also the keyboard levels. I'll update the bug report if there are any changes. As discussed on IRC, just to have this documented here as well: the keyboard event emitted unfortunately also has other side effects, e.g. when using the slider of the battery plasmoid it closes it. So it would be great to have that fixed upstream in kernel. Also the OSD is obviously not shown when the key binding is disabled, this should be workaroundable with a little script and dbus, I'll also update the bug report when I manage something. Won't have time today / in the next two days though. Thanks so far for everybody involved.
To get the OSD back, I created the following script (Adapt paths where needed, should work in POSIX compliant shells) and bound it to XF86KbdLightOnOff. Therefore now using the keyboard or the battery plasmoid slider (aside from closing itself) works including displaying the OSD. #!/bin/sh # Get the maximum value MAX=`/usr/bin/qdbus --system org.freedesktop.UPower /org/freedesktop/UPower/KbdBacklight org.freedesktop.UPower.KbdBacklight.GetMaxBrightness` # Get the current value. Dbus currently (kernel 4.5) gives wrong values for GetBrightness, so we fetch it via the proc interface CUR=`grep status /proc/acpi/ibm/kbdlight | awk '{print $2}'` # Calculate percentage PER=$(($CUR * 100 / 2)) # Invoke OSD /usr/bin/qdbus org.kde.plasmashell /org/kde/osdService org.kde.osdService.keyboardBrightnessChanged $PER exit 0
Augh, obviously replace 2 above with $MAX, my bad. (And in this case maybe check for non-null, even though this should™ not be possible)
Is this still a problem in Plasma 5.27? Or, even better, in Plasma 6?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!