debcrafters-packages team mailing list archive

Thread
Date

[Bug 2110585] Re: [SRU] Stop using 'actual_brightness' in systemd

To: debcrafters-packages@xxxxxxxxxxxxxxxxxxx
From: Bin Li <2110585@xxxxxxxxxxxxxxxxxx>
Date: Sat, 19 Jul 2025 03:33:40 -0000
Reply-to: Bug 2110585 <2110585@xxxxxxxxxxxxxxxxxx>
Sender: noreply@xxxxxxxxxxxxx

Hi Nick, I've updated the test plan part. In Beijing Lab, we have
several platforms could reproduce this issue.

Hi Mario,

How could we confirm AMD laptop supports custom brightness curve (look
in kernel log)? From the 'backlight' keyword, I only got these logs
below.

$ sudo dmesg | grep backlight
[ 1.600606] thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
[ 1.665703] systemd[1]: Created slice system-systemd\x2dbacklight.slice - Slice /system/systemd-backlight.
[ 1.667804] systemd[1]: Starting systemd-backlight@leds:tpacpi::kbd_backlight.service - Load/Save Screen Backlight Brightness of leds:tpacpi::kbd_backlight...
[ 1.674453] systemd[1]: Finished systemd-backlight@leds:tpacpi::kbd_backlight.service - Load/Save Screen Backlight Brightness of leds:tpacpi::kbd_backlight.

** Description changed:

[Impact]

At shutdown time systemd will record the most recently used brightness
value and then attempt to restore it the next boot.

In order to do this; it currently will read the 'actual_brightness'
value and use that to save.

This normally works fine; but GPU drivers don't always show the same
value in 'brightness' and 'actual_brightness' meaning that the wrong
value may be restored the next boot.

This problem is very prominently found on AMD APUs starting with kernel
6.15 due to a new feature called "custom brightness curves". Custom
brightness curves are brightness values programmed by an OEM in the
firmware to make the panel behave optimally. The 'actual_brightness' of
some 'brightness' values will be lower.

The same issue can occur on systems using "panel power savings" which
behaves similarly.

For example if the brightness a user requested was 150, the
actual_brightness might be 130. So the next boot the brightness will be
"set" to 130, but the actual brightness might be 115. If the user
reboots again it will be set to 115 for the next boot but the actual
brightness might be 100. That is this gets worse and worse each reboot
cycle until the system eventually boots up at minimum brightness.

[Test Plan]

Verify brightness save/restore works properly on Intel UMA, AMD UMA, and
either I+N or A+N systems.

+ 0. Use a laptop with an eDP panel, AMD laptop that supports custom
+ brightness curve (look in kernel log)
+
+ 1. Look at value of brightness for device in /sys/class/backlight/. Note it down.
+ $ grep . /sys/class/backlight/*/* 2>/dev/null
+
+ 2. Unplug the power supply, look at the value of brightness again. The
+ actual_brightness will be decreased on AMD laptops that supportes custom
+ brightnes curve.
+
+ 3. Reboot without power supply, look at value again, ensure the
+ actual_brightnesss and brightness are the same.
+
+
[Where problems could occur]

If a driver relies upon actual_brightness rather than brightness (which
is against kernel API [1] then the brightness might no longer be saved
and restored properly.

[1] https://origin.kernel.org/doc/html/next/admin-guide/abi-
stable.html#abi-sys-class-backlight-backlight-actual-brightness

[Other Info]

This has been fixed in upstream systemd in this commit:
https://github.com/systemd/systemd/commit/9a224c307b36610e3675390eb2620e74d0f4efb0
It's been brought into stable systemd releases carried by other distros as well.
No regressions have been reported upstream that I'm aware of.

** Description changed:

[Impact]

At shutdown time systemd will record the most recently used brightness
value and then attempt to restore it the next boot.

In order to do this; it currently will read the 'actual_brightness'
value and use that to save.

This normally works fine; but GPU drivers don't always show the same
value in 'brightness' and 'actual_brightness' meaning that the wrong
value may be restored the next boot.

The same issue can occur on systems using "panel power savings" which
behaves similarly.

[Test Plan]

Verify brightness save/restore works properly on Intel UMA, AMD UMA, and
either I+N or A+N systems.

0. Use a laptop with an eDP panel, AMD laptop that supports custom
brightness curve (look in kernel log)

1. Look at value of brightness for device in /sys/class/backlight/. Note it down.
$ grep . /sys/class/backlight/*/* 2>/dev/null

2. Unplug the power supply, look at the value of brightness again. The
actual_brightness will be decreased on AMD laptops that supportes custom
brightnes curve.

3. Reboot without power supply, look at value again, ensure the
- actual_brightnesss and brightness are the same.
-
+ actual_brightnesss and brightness are the same with the ones before
+ reboot.

[Where problems could occur]

If a driver relies upon actual_brightness rather than brightness (which
is against kernel API [1] then the brightness might no longer be saved
and restored properly.

[1] https://origin.kernel.org/doc/html/next/admin-guide/abi-
stable.html#abi-sys-class-backlight-backlight-actual-brightness

[Other Info]

--
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2110585

Title:
[SRU] Stop using 'actual_brightness' in systemd

Status in OEM Priority Project:
Triaged
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Noble:
Incomplete
Status in systemd source package in Plucky:
Incomplete
Status in systemd source package in Questing:
Fix Released

Bug description:
[Impact]

At shutdown time systemd will record the most recently used brightness
value and then attempt to restore it the next boot.

In order to do this; it currently will read the 'actual_brightness'
value and use that to save.

This normally works fine; but GPU drivers don't always show the same
value in 'brightness' and 'actual_brightness' meaning that the wrong
value may be restored the next boot.

This problem is very prominently found on AMD APUs starting with
kernel 6.15 due to a new feature called "custom brightness curves".
Custom brightness curves are brightness values programmed by an OEM in
the firmware to make the panel behave optimally. The
'actual_brightness' of some 'brightness' values will be lower.

The same issue can occur on systems using "panel power savings" which
behaves similarly.

For example if the brightness a user requested was 150, the
actual_brightness might be 130. So the next boot the brightness will
be "set" to 130, but the actual brightness might be 115. If the user
reboots again it will be set to 115 for the next boot but the actual
brightness might be 100. That is this gets worse and worse each reboot
cycle until the system eventually boots up at minimum brightness.

[Test Plan]

Verify brightness save/restore works properly on Intel UMA, AMD UMA,
and either I+N or A+N systems.

0. Use a laptop with an eDP panel, AMD laptop that supports custom
brightness curve (look in kernel log)

1. Look at value of brightness for device in /sys/class/backlight/. Note it down.
$ grep . /sys/class/backlight/*/* 2>/dev/null

2. Unplug the power supply, look at the value of brightness again. The
actual_brightness will be decreased on AMD laptops that supportes
custom brightnes curve.

3. Reboot without power supply, look at value again, ensure the
actual_brightnesss and brightness are the same with the ones before
reboot.

[Where problems could occur]

If a driver relies upon actual_brightness rather than brightness
(which is against kernel API [1] then the brightness might no longer
be saved and restored properly.

[1] https://origin.kernel.org/doc/html/next/admin-guide/abi-
stable.html#abi-sys-class-backlight-backlight-actual-brightness

[Other Info]

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/2110585/+subscriptions

References

[Bug 2110585] [NEW] Stop using 'actual_brightness' in systemd
From: Mario Limonciello, 2025-05-13