Public bug reported:
After the kernel update to 7.0.0-28-generic (HWE, arrived alongside a
KDE Plasma update), the internal laptop screen brightness became stuck
at maximum. The /sys/class/backlight/intel_backlight/brightness sysfs
value still changes correctly (both via the KDE Plasma slider and via
manual echo > brightness), and org.kde.powerdevil.backlighthelper is
invoked successfully each time, but the physical panel brightness no
longer follows the value at runtime.
Booting the previous kernel (6.17.0-40-generic) with the exact same GRUB
configuration (no special kernel parameters) restores correct behaviour
immediately: both the slider and manual sysfs writes change the physical
screen brightness as expected.
This points to a regression in the i915 driver's eDP AUX/DPCD backlight
write path in 7.0.0-28-generic, not an issue with KDE Plasma/powerdevil
(which was ruled out — see tests below).
System information
Laptop: Dell Vostro 15 3510
GPU: Intel UHD Graphics G4 (Tiger Lake-LP GT2, 48EU) — i915 0000:00:02.0,
device ID 9a78, "tigerlake/uy"
OS: Ubuntu Noble 24.04 (KDE neon on top)
Desktop: KDE Plasma (recently updated)
Broken kernel: linux-image-7.0.0-28-generic (7.0.0-28.28~24.04.1, via
linux-generic-hwe-24.04)
Working kernel: linux-image-6.17.0-40-generic (6.17.0-40.40~24.04.1)
GRUB config: default, no special parameters (GRUB_CMDLINE_LINUX_DEFAULT="quiet
splash")
Steps to reproduce (on 7.0.0-28-generic)
Boot into 7.0.0-28-generic with a clean/default GRUB command line.
Check the sysfs interface:
ls /sys/class/backlight/
→ intel_backlight
cat /sys/class/backlight/intel_backlight/brightness
cat /sys/class/backlight/intel_backlight/max_brightness
→ e.g. 410 / 1023
Change brightness via the KDE Plasma slider, or manually:
echo 200 | sudo tee /sys/class/backlight/intel_backlight/brightness
Observe: the sysfs value updates correctly (confirmed by reading it back), and
org.kde.powerdevil.backlighthelper is activated successfully in the journal,
but the physical screen brightness does not change — it stays at the level set
at boot time by systemd-backlight.
Steps to reproduce the working case (6.17.0-40-generic)
Boot into 6.17.0-40-generic with the same, unmodified GRUB command line.
Note the sysfs interface uses a different (raw PWM-like) brightness scale on
this kernel, e.g. max_brightness in the tens of thousands rather than 1023.
Repeat the same slider / manual echo test.
Observe: the physical screen brightness follows the value correctly, both from
the KDE Plasma slider and from manual sysfs writes.
What we ruled out
KDE Plasma / powerdevil is not at fault. org.kde.powerdevil.backlighthelper is
called successfully via D-Bus/KAuth every time the slider is moved, on both
kernels, and the sysfs value is written correctly in both cases. The failure is
purely between "sysfs value" and "physical panel output", which is below the
desktop environment / kernel userspace boundary.
Not a permissions issue. /sys/class/backlight/intel_backlight/brightness write
succeeds (verified via direct sudo tee), the value persists when re-read.
Tried acpi_backlight=native and acpi_backlight=vendor kernel parameters on
7.0.0-28-generic:
acpi_backlight=vendor → intel_backlight sysfs interface disappears entirely
(i915: [drm] Skipping intel_backlight registration in dmesg), no backlight
class device is exposed at all on this hardware.
acpi_backlight=native → interface present, sysfs value changes, but no physical
brightness change (same broken behaviour as default).
Tried i915.enable_dpcd_backlight=1 and =3 (note: per modinfo i915, this
parameter is actually boolean, so both likely evaluated to the same
"enabled" state) combined with acpi_backlight=native:
Fixed the boot-time initial brightness (screen now dims to the value
saved/restored by systemd-backlight at boot, instead of being stuck at 100%).
Did not fix live/runtime updates — slider and manual sysfs writes still don't
change the physical brightness after boot.
dmesg during a live brightness write shows no relevant
AUX/DPCD/backlight error messages on 7.0.0-28-generic (driver does not
log at that verbosity by default) — happy to gather more verbose i915
debug logs if useful (e.g. via drm.debug).
Expected behaviour
Writing to /sys/class/backlight/intel_backlight/brightness (whether via
the desktop environment or directly) should change the physical panel
brightness at runtime, as it does on 6.17.0-40-generic with identical
hardware and GRUB configuration.
Actual behaviour
On 7.0.0-28-generic, only the kernel's own boot-time backlight
restoration (systemd-backlight@backlight:intel_backlight.service)
succeeds in setting a correct initial physical brightness (and only when
acpi_backlight=native i915.enable_dpcd_backlight=1 is set); all
subsequent runtime writes to the sysfs brightness file are silently
ignored by the hardware, even though the sysfs value itself updates.
Current workaround
Pinning/holding the working kernel as default via GRUB
(GRUB_DEFAULT=saved + grub-set-default) and holding the linux-
image-7.0.0-28-generic / linux-generic-hwe-24.04 packages to prevent apt
from reactivating the broken kernel on the next update.
Additional info available on request
Full journalctl -b output around powerdevil/backlight activity on both kernels
dmesg output on both kernels
Willing to test additional kernel parameters or debug builds if it helps narrow
down the regression
** Affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2161148
Title:
[SRU] intel_backlight (i915/eDP AUX-DPCD) stops responding to live
brightness writes in 7.0.0-28-generic (works in 6.17.0-40-generic)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161148/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
