https://bugs.kde.org/show_bug.cgi?id=469819
Bug ID: 469819
Summary: kbd_backlight restored to wrong value after lid
close-open
Classification: Plasma
Product: Powerdevil
Version: 5.27.4
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
Target Milestone: ---
SUMMARY
On a notebook on lid close and open again I observed that the keyboard
backlight was not restored to the previous value, but only flashing shortly and
then be turned off.
STEPS TO REPRODUCE
1. Close notebook with activated keyboard backlight, that is controllable via
the /sys/class/leds/*kbd_backlight* interface.
2. Open the notebook.
OBSERVED RESULT
Keyboard backlight flashes shortly, but then turns off.
EXPECTED RESULT
Keyboard backlight is restored to brightness vallue before lid close.
SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.105.0
Qt Version: 5.15.9
ADDITIONAL INFORMATION
I put a print statement in die backlight driver and observed:
On lid close-open:
Keyboard backlight is set to 0 (persumable on close)
Keyboard backlight is set to 255 (previous value, presumably on resume/lid
open)
Keyboard backlight is set to 0 (again an action taken on resume?)
Sending the notebook to sleep via menu:
Keyboard backlight is set to 255 (previous value, presumably on resume)
Deactivating standby on lid close:
Keyboard backlight is set to 0 (persumable on close)
Keyboard backlight is set to 255 (previous value, presumably on lid open)
Killing powerdevil:
Keyboard backlight is not changed from OS in all 3 scenarios above
My guess (without knowing the powerdevil codebase): there is a race condition
in powerdevil:
On lid close keyboard backlight is saved and set to 0
On standby keyboard backlight is saved
On lid open keyboard backlight is restored to the lid close value
On resume keyboard backlight is restored to the standby entry value
-> The lid-close-handler is executed before the suspend-entry-handler, so the
suspend-entry-handler saves brightness value 0. On lid open the correct value
is restored first because the lid-open-handler gets executed first. After that
the resume-handler restores the wrong value from the suspend-entry-handler
--
You are receiving this mail because:
You are watching all bug changes.
