All autopkgtests for the newly accepted systemd (257.4-1ubuntu3.2) for plucky have finished running. The following regressions have been reported in tests triggered by the package:
apport/2.32.0-0ubuntu5.3 (amd64, arm64, ppc64el) avahi/0.8-16ubuntu2 (s390x) cups/2.4.12-0ubuntu1 (s390x) dbus-broker/36-1ubuntu0.25.04.1 (s390x) dracut/106-2ubuntu5 (amd64) gnome-remote-desktop/48.0-1 (s390x) incus/6.0.3-4 (armhf) initramfs-tools/0.147ubuntu1.1 (s390x) libsoup3/3.6.5-1ubuntu0.2 (ppc64el) linux-realtime/6.14.0-1010.10 (amd64) netplan.io/1.1.2-2ubuntu1.1 (arm64, s390x) samba/2:4.21.4+dfsg-1ubuntu3.4 (ppc64el) sks/1.1.6+git20210302.c3ba6d5a-4.1 (amd64, arm64, armhf, ppc64el, s390x) systemd/257.4-1ubuntu3.2 (amd64, ppc64el) util-linux/2.40.2-14ubuntu1.1 (amd64) Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1]. https://people.canonical.com/~ubuntu-archive/proposed- migration/plucky/update_excuses.html#systemd [1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions Thank you! -- You received this bug notification because you are a member of Ubuntu Touch seeded 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: Triaged Status in systemd source package in Plucky: Fix Committed 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 due to two features: * Panel power savsings * Custom Brightness curves Panel power savings has been introduced in kernel 6.8 and is activated by power profiles daemon dynamically. Custom brightness curves are brightness values programmed by an OEM in the firmware to make the panel behave optimally. Support for this is introduced in kernel 6.15. The 'actual_brightness' of some 'brightness' values will be lower in both cases. 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. 1. Use a laptop with an eDP panel, AMD laptop. Verify the presence of panel power savings feature by looking at /sys/class/drm/card0-eDP/amdgpu/panel_power_savings. 2. Manually set power savings to maximum: # echo 4 | sudo tee /sys/class/drm/card0-eDP/amdgpu/panel_power_savings 3. Look at value of brightness for device in /sys/class/backlight/. Note it down. $ grep . /sys/class/backlight/*/* 2>/dev/null 4. Reboot look at value again, ensure the brightness value is the same as 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] 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. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2110585/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
