I can also confirm this issue. Reverting to 6.17.0-40-generic fixed my issue as well. System: Kernel: 7.0.0-28-generic arch: x86_64 Desktop: Cinnamon v: 6.6.7 Distro: Linux Mint 22.3 Zena base: Ubuntu 24.04 noble -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb 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) Status in linux package in Ubuntu: New Bug description: 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161148/+subscriptions
Комментариев нет:
Отправить комментарий