https://bugs.kde.org/show_bug.cgi?id=469819
--- Comment #1 from Werner Sembach [TUXEDO] <w...@tuxedocomputers.com> --- So afaik there are potentialy 4 locations where kbd_backlight is stored/restored on power events like, lid close, boot or suspend resume: 1. The firmware and/or kernel driver itself 2. systemd-backlight@, a systemd service that attached to the first (and only exactly 1) kbd_backlight it finds and does not use upower 3. powerdevil (and probably the gnome equivalent on that side too) 4. Tuxedo-Control-Center in my specific case Well, imho that's 3 locations to much xD. Ofc I could easily remove 4, but I explicitly built it in, because without it it was kinda buggy -> see this issue. But tbh I did not yet recheck the current situation. Probably the best case scenario would be to implement this completly in driver/firmware, because this is the only place where there is enough information about the hardware to guarantie a flicker free restore, if possible. For TUXEDO devices I could implement this, but it's not feasible to make sure that all legacy drivers behave correctly here. I suspect that's why systemd-backlight exists and now that I think of it, kernel space can not easily restore the value across reboots. One idea: If systemd-backlight@ is running powerdevil does not try to restore kbd backlight. Also fix systemd-backlight@ to use upower to automatically handle multiple kbd_backlights once this gets merged: https://gitlab.freedesktop.org/upower/upower/-/merge_requests/203 and to ensure that upower is always up to date to the values in sysfs. Alternatively let powerdevil somehow make sure that it is not "sabotaged" by systemd-backlight. -- You are receiving this mail because: You are watching all bug changes.
