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.

With this commit, systemd at least handles all kbd_backlight's: https://github.com/systemd/systemd/pull/31042

Just to add some clarity: When you say lid open/closed, you have Sleep (suspend-to-RAM) configured as lid action in the Energy Saving settings page, yes?

PowerDevil's HandleButtonEvents action only restores keyboard brightness on lid-open if the stored brightness was greater than 0 to begin with. And there are two other places in PowerDevil that, confusingly, also mess with keyboard brightness: the DPMS action, which has the same guard and shouldn't be executed anyway in your (suspend) case; and the DimDisplay action, which doesn't trigger on lid state changes but only on user activity timeouts.

So I do wonder where your "Keyboard backlight is set to 0" at the end of the "lid close-open" list actually comes from.

Keeping keyboard backlights untouched by PowerDevil if systemd-backlight is running seems decent. I'd have to see how we can reliably check from PowerDevil that it's running.

Another idea would be to scrap the whole "restore previous value" concept and instead always use the value that the user last set via PowerDevil applet and/or KCM. Once we have that, we can take out all of the "save for later" code and unify all the "restore brightness" code into a single place. Which would hopefully be executed last in the wake-up process, and override whatever systemd may or may not have dealt with.

Cannot reproduce on my ThinkPad (X1 Carbon Gen 7) on latest Plasma 6.0 RC1 (plus a few days of extra code) btw.  That's with lid action set to "Sleep" and sleep mode as "Standby" in my current power state profile.

tbh I don't exactly know anymore what I meant by lide-close-open.

I currently have 2 notebook at hand: One where systemd-backlight + UPower/Powerdevil + Tuxedo-Control-Center causes the keyboard to bo of after suspend but just systemd-backlight + UPower/Powerdevil works fine and one where systemd-backlight + UPower/Powerdevil causes the keyboard to be of but with systemd-backlight + UPower/Powerdevil + Tuxedo-Control-Center it works fine. I have to do some more testing so untangle this suspected racecondition.

I will update you once I have a more clear picture/a hint when and when not it is reproduceable.

I reproduced the behaviour again on a TUXEDO IBP 14 Gen8 and seems to have nothing to do with systemd-backlight:

I masked and stoped systemd-backlight.
Tuxedo Control Center was not installed.
This device has brightness values 0-2.

With brightness 0, suspend via lid close, resume via lid open:
- On suspend 0 is written
- On resume 0 is written

With brightness 0, suspend via media key, resume via media key:
- On suspend nothing is written
- On resume 0 is written

With brightness 0, suspend via media key, resume via lid open:
- On suspend nothing is written
- On resume 0 is written

With brightness 2, suspend via lid close, resume via lid open:
- On suspend 0 is written
- On resume 2 followed by 0 is written <- this is the buggy case

With brightness 2, suspend via media key, resume via media key:
- On suspend nothing is written
- On resume 2 is written

With brightness 2, suspend via media key, resume via lid open:
- On suspend nothing is written
- On resume 2 is written

(In reply to Jakob Petsovits from comment #3)
> Just to add some clarity: When you say lid open/closed, you have Sleep
> (suspend-to-RAM) configured as lid action in the Energy Saving settings
> page, yes?

Yes, left everything there at default.

(In reply to Werner Sembach [TUXEDO] from comment #7)
> (In reply to Jakob Petsovits from comment #3)
> > Just to add some clarity: When you say lid open/closed, you have Sleep
> > (suspend-to-RAM) configured as lid action in the Energy Saving settings
> > page, yes?
> 
> Yes, left everything there at default.

On this note: When I set lid close to "Do nothing":

With Brightness 2:
On lid close 0 is written
On lid open 2 is written

With Brightness 0:
On lid close 0 is written
On lid open nothing is written

systemd-backlight really only seem to do something on shutdown and boot and since on shutdown there is no write event there should not be any conflict potential. I blamed it wrongly.

After some printf debuggung i no longer think the 2nd write comes from pwoerdevil, nor does i come from systemd-backlight, nor does it come from the driver/firmware, nor does it come from tuxedo control center -> something else also tries to restore the brightness and i don't yet know what

(In reply to Werner Sembach [TUXEDO] from comment #10)
> After some printf debuggung i no longer think the 2nd write comes from
> pwoerdevil, nor does i come from systemd-backlight, nor does it come from
> the driver/firmware, nor does it come from tuxedo control center ->
> something else also tries to restore the brightness and i don't yet know what

Scrap that. It comes from powerdevil, I need to do more digging.

Found the culprit: https://invent.kde.org/plasma/powerdevil/-/merge_requests/311

commit aa2fa1067be58a9c68b54f3d80b239291e154911
Author: Werner Sembach
Date:   Tue Jan 30 14:26:53 2024 +0100

kbd backlight: Fix double brightness restore on LidOpen-resume

This fixes the issue that on LidOpen-resume the brightness might get restored
two times. Once to the correct vallue and once incorrectly to 0.

To archive this it uses the same simple "don't restore to 0"-policy as is used
in dimdisplay.cpp, dpms.cpp, and handlebuttonevent.cpp.

---

Also cherry-picked to Plasma/6.0 branch as commit 8dc9a5c0117d0be0e9a13489937d9d9a199ba6c1, and to Plasma/5.27 as commit b30c584d6a724d350b7b8f6a30cc4bbbf9dbac3d.

This bug (or at least it seems to be) returned to me after some update with Plasma 6.
How can I check if this is caused by Plasma?

Basically, when I close the lid (configured only to turn off the screen) and the open it, and the screen goes back, the keyboard lights stay turned off. I have to manually turn them on (FN+NUM+).

Is there a way to check if this is caused by Plasma or something else?

By default, keyboard lights goes off automatically when the laptop is not in use, but it turns on, when activity is resumed. The similar behavior is expected on opening the lid. It worked normally till recently.

I'm on Manjaro unstable, so on the level of Arch stable packages.

I'm trying to figure it out first, before submitting any new bug reports.
Thank you

Operating System: Manjaro Linux 
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.9-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
Memory: 30.6 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: TUXEDO
Product Name: TUXEDO Sirius 16 Gen1

I have this issue currently as well, on powerdevil version 6.0.2-3 - started with the update to KDE version 6.

It's definitely lid close: if I suspend and wake without lid close, it remembers keyboard brightness correctly. If I suspend, then close lid, then open to wake, it remembers correctly. But if I suspend via closing the lid, when I open it, the keyboard brightness is set to 0.

Reopening bug, since when I kill powerdevil (`killall org_kde_powerdevil`) and close then open lid, keyboard backlight remains unchanged.

Operating System: Arch Linux 
KDE Plasma Version: 6.0.2
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.8.1-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 12 × Intel® Core™ i7-10750H CPU @ 2.60GHz
Memory: 31.1 GiB of RAM
Graphics Processor: Mesa Intel® UHD Graphics
Manufacturer: Dell Inc.
Product Name: XPS 17 9700

(In reply to Toby Fox from comment #15)
> Reopening bug, since when I kill powerdevil (`killall org_kde_powerdevil`)
> and close then open lid, keyboard backlight remains unchanged.

I'm no powerdevil maintainer, but maybe try reverting this patch: https://invent.kde.org/plasma/powerdevil/-/commit/aa2fa1067be58a9c68b54f3d80b239291e154911

If that doesn't help a new bug report would maybe be better, because then it's a different bug just with the same symptoms.

Just stumbled upon this bug again, and realized that the fix from Bug 482306 probably also takes care of the remaining issue mentioned in Comment #15. Could you try retesting with Plasma 6.0.4 to see if it now works intended?

.

I just tested it on Plasma 6.0.4 and it's working, thanks all!

I can also confirm that the issue is gone, and after closing and opening the lid, keyboard lights are up, as they suppose to be.
Thank you!