*** This bug is a duplicate of bug 2161309 ***
https://bugs.launchpad.net/bugs/2161309
---
Confirmed same regression on a **ThinkPad X1 Yoga 3rd gen** (Intel UHD
620 / Whiskey Lake, eDP panel **CMN N140HCE-GP2**), kernel
`7.0.0-28-generic`. Adding another confirmed hardware combination plus
one data point that seems important for the SRU: **the choice of
`enable_dpcd_backlight` value determines whether *live* writes work or
only boot-time initial brightness.**
- `intel_backlight` registered; sysfs writes stick (`brightness ==
actual_brightness`) but the panel does not respond — identical to the "silent
failure" described above.
- With `acpi_backlight=native i915.enable_dpcd_backlight=1`: boot-time initial
brightness was correct, but slider/keys/`echo > brightness` had no visual
effect (same as the earlier reporter's result with =1/=3).
I verified the panel itself is healthy and PWM-wired by sweeping the PCH PWM
duty-cycle register directly via MMIO (`resource0`, base `0x2ffa000000`, duty
reg at offset `0xc8254`, frequency counter = 1060) during a pristine-state boot
where the driver backlight path stays uninitialized (`acpi_backlight=video`, so
no DPCD/PWM latch has happened yet). Sweeping the duty cycle changed the panel
brightness **visibly** — so the panel TCON responds to the PWM pin fine.
Conclusion consistent with the bug title: on 7.0.0-28 the i915
backlight-selection heuristic puts the panel into VESA DPCD/AUX mode,
the TCON latches into that mode, and from then on the PWM pin (which
`intel_backlight` drives) is ignored. Sysfs keeps reporting success,
which matches everyone's "silent failure" observations.
```
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=native
i915.enable_dpcd_backlight=0"
```
After reboot with these parameters: `intel_backlight` registered
(max_brightness 1060), and **live** brightness updates work — keys,
GNOME slider, and sysfs writes all visibly change the screen. This
differs usefully from the earlier test with `enable_dpcd_backlight=1`:
blocking the DPCD selection entirely (=0) restores the full write path,
not just initial level. Worth keeping in mind for whoever tests SRU
kernels: `=0` and `=1` are not equivalent workarounds on affected
panels.
Happy to provide dmesg/journal excerpts if useful.
— yaleed
--
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
