Public bug reported: # [i915] eDP backlight max_brightness drops from 7500 to 1023 between kernel 6.8 and 7.0, screen stays dark even at maximum brightness (Dell Latitude 7490) ## Summary On a Dell Latitude 7490 (Skylake-generation VBT), the internal eDP panel becomes very dark when running kernel 7.0.0-14-generic (Xubuntu 26.04), even at the maximum backlight value. The same hardware, same BIOS version, and byte-identical VBT works correctly under kernel 6.8.0 and 5.15.0. The root cause appears to be a regression in how `intel_backlight`'s `max_brightness` is computed: it drops from 7500 (correct, working) to 1023 (broken) between these kernel versions, meaning the "maximum" brightness value under the broken kernel corresponds to only a small fraction of the panel's actual full-scale PWM duty cycle. ## Environment - **Model:** Dell Latitude 7490 - **BIOS version:** 1.41.0 (identical on both working and broken test units) - **VBT:** `$VBT SKYLAKE`, BDB version 212, build 1000, dated 01/21/2015 — confirmed **byte-identical** between a working unit (kernel 5.15) and the broken unit (kernel 7.0), extracted via `/sys/kernel/debug/dri/*/i915_vbt` - **LFP Backlight block (VBT block 43), decoded fields:** - `type = 2` (Display DDI / native PWM, not DPCD/AUX) - `active_low_pwm = 0` - `pwm_freq_hz = 200` - `min_brightness = 0` - **Broken:** Xubuntu 26.04, kernel `7.0.0-14-generic` - **Working (same hardware/BIOS):** kernel `6.8.0-060800-generic` (Ubuntu mainline build) and, on a second identical Latitude 7490 unit, Xubuntu 22.04 with kernel `5.15.0-186-generic` ## Steps to Reproduce 1. Boot Dell Latitude 7490 with Xubuntu 26.04, kernel 7.0.0-14-generic. 2. Observe the internal display is very dark immediately from boot (i.e., before any user session/compositor starts). 3. Check backlight state: ``` cat /sys/class/backlight/intel_backlight/max_brightness cat /sys/class/backlight/intel_backlight/brightness ``` 4. Boot the same machine with kernel 6.8.0-060800-generic (installed in parallel via Ubuntu mainline builds) and repeat step 3. ## Expected Result `max_brightness` should reflect the panel's real full-scale PWM range, and setting `brightness` to `max_brightness` should produce full/normal screen brightness — as seen on kernel 6.8.0 and 5.15.0. ## Actual Result | Kernel | max_brightness | brightness at max | Screen appearance | |---|---|---|---| | 5.15.0-186-generic | 7500 | 7500 | Normal / bright | | 6.8.0-060800-generic | 7500 | 7500 | Normal / bright | | 7.0.0-14-generic | 1023 | 1023 | Very dark, even at max value | Writing arbitrary values to `/sys/class/backlight/intel_backlight/brightness` under the broken kernel does change the screen's brightness (e.g., writing 300 makes it visibly darker than writing 1023), confirming the sysfs interface is functionally connected to the hardware — it is simply capped at a much lower duty-cycle ceiling than the panel actually supports. ## Additional Diagnostics (broken kernel, 7.0.0-14-generic) - `cat /sys/class/backlight/intel_backlight/type` → `raw` - `acpi_backlight=video` boot parameter: `acpi_video0` backlight device appears (`max_brightness=66`), but writing to it also produces no visible brightness change. - `i915.enable_dpcd_backlight=1` and `=3` boot parameters: no change. - `i915.enable_psr=0 i915.enable_dc=0` boot parameters (to rule out PSR/DC-state PWM miscalculation): no change. - `nomodeset` boot parameter: screen boots at full/normal brightness and stays there (firmware/UEFI-set backlight level, untouched because i915 never takes over the panel) — this was the first strong indicator that i915's own panel/backlight initialization on this kernel is the culprit, not a downstream consumer (Xfce power manager, compositor, etc.). - Also observed in `kern.log` on the 7.0 kernel (possibly related, possibly a separate regression from the same ACPI-handling change): ``` ACPI Warning: SystemMemory range 0x00000000FE028000-0x00000000FE0281FF conflicts with OpRegion 0x00000000FE028000-0x00000000FE028207 (\_SB.PCI0.GEXP.BAR0) (20251212/utaddress-204) ACPI: OSL: Resource conflict; ACPI support missing from driver? intel-lpss INT3446:00: probe with driver intel-lpss failed with error -16 ``` ## Notes - Ruled out: BIOS/firmware VBT differences (confirmed byte-identical between working and broken systems), xfce4-power-manager or other userspace brightness helpers (issue reproduces on a bare TTY with no X11/compositor running), gamma/compositor dimming (`xrandr --verbose` shows `Gamma: 1.0:1.0:1.0`), DPCD/AUX vs native PWM backlight type mismatch (VBT explicitly specifies type 2 / native DDI PWM, and forcing DPCD via `enable_dpcd_backlight` made no difference). - This strongly points to a regression in the i915 PWM/backlight range calculation code introduced somewhere between kernel 6.8 and 7.0 (exact commit not yet bisected). ## Suggested Next Steps for Investigation - Bisect between v6.8 and v7.0 mainline kernels to identify the offending commit in `drivers/gpu/drm/i915/display/intel_backlight.c` (or related PWM period/precision calculation code). - Compare computed PWM period/precision-bit values between the two kernel versions for this specific panel (Skylake-era native PWM, VBT type 2, 200 Hz). ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2161713 Title: [i915] eDP backlight max_brightness drops from 7500 to 1023 between kernel 6.8 and 7.0, screen stays dark even at maximum brightness (Dell Latitude 7490) Status in linux package in Ubuntu: New Bug description: # [i915] eDP backlight max_brightness drops from 7500 to 1023 between kernel 6.8 and 7.0, screen stays dark even at maximum brightness (Dell Latitude 7490) ## Summary On a Dell Latitude 7490 (Skylake-generation VBT), the internal eDP panel becomes very dark when running kernel 7.0.0-14-generic (Xubuntu 26.04), even at the maximum backlight value. The same hardware, same BIOS version, and byte-identical VBT works correctly under kernel 6.8.0 and 5.15.0. The root cause appears to be a regression in how `intel_backlight`'s `max_brightness` is computed: it drops from 7500 (correct, working) to 1023 (broken) between these kernel versions, meaning the "maximum" brightness value under the broken kernel corresponds to only a small fraction of the panel's actual full-scale PWM duty cycle. ## Environment - **Model:** Dell Latitude 7490 - **BIOS version:** 1.41.0 (identical on both working and broken test units) - **VBT:** `$VBT SKYLAKE`, BDB version 212, build 1000, dated 01/21/2015 — confirmed **byte-identical** between a working unit (kernel 5.15) and the broken unit (kernel 7.0), extracted via `/sys/kernel/debug/dri/*/i915_vbt` - **LFP Backlight block (VBT block 43), decoded fields:** - `type = 2` (Display DDI / native PWM, not DPCD/AUX) - `active_low_pwm = 0` - `pwm_freq_hz = 200` - `min_brightness = 0` - **Broken:** Xubuntu 26.04, kernel `7.0.0-14-generic` - **Working (same hardware/BIOS):** kernel `6.8.0-060800-generic` (Ubuntu mainline build) and, on a second identical Latitude 7490 unit, Xubuntu 22.04 with kernel `5.15.0-186-generic` ## Steps to Reproduce 1. Boot Dell Latitude 7490 with Xubuntu 26.04, kernel 7.0.0-14-generic. 2. Observe the internal display is very dark immediately from boot (i.e., before any user session/compositor starts). 3. Check backlight state: ``` cat /sys/class/backlight/intel_backlight/max_brightness cat /sys/class/backlight/intel_backlight/brightness ``` 4. Boot the same machine with kernel 6.8.0-060800-generic (installed in parallel via Ubuntu mainline builds) and repeat step 3. ## Expected Result `max_brightness` should reflect the panel's real full-scale PWM range, and setting `brightness` to `max_brightness` should produce full/normal screen brightness — as seen on kernel 6.8.0 and 5.15.0. ## Actual Result | Kernel | max_brightness | brightness at max | Screen appearance | |---|---|---|---| | 5.15.0-186-generic | 7500 | 7500 | Normal / bright | | 6.8.0-060800-generic | 7500 | 7500 | Normal / bright | | 7.0.0-14-generic | 1023 | 1023 | Very dark, even at max value | Writing arbitrary values to `/sys/class/backlight/intel_backlight/brightness` under the broken kernel does change the screen's brightness (e.g., writing 300 makes it visibly darker than writing 1023), confirming the sysfs interface is functionally connected to the hardware — it is simply capped at a much lower duty-cycle ceiling than the panel actually supports. ## Additional Diagnostics (broken kernel, 7.0.0-14-generic) - `cat /sys/class/backlight/intel_backlight/type` → `raw` - `acpi_backlight=video` boot parameter: `acpi_video0` backlight device appears (`max_brightness=66`), but writing to it also produces no visible brightness change. - `i915.enable_dpcd_backlight=1` and `=3` boot parameters: no change. - `i915.enable_psr=0 i915.enable_dc=0` boot parameters (to rule out PSR/DC-state PWM miscalculation): no change. - `nomodeset` boot parameter: screen boots at full/normal brightness and stays there (firmware/UEFI-set backlight level, untouched because i915 never takes over the panel) — this was the first strong indicator that i915's own panel/backlight initialization on this kernel is the culprit, not a downstream consumer (Xfce power manager, compositor, etc.). - Also observed in `kern.log` on the 7.0 kernel (possibly related, possibly a separate regression from the same ACPI-handling change): ``` ACPI Warning: SystemMemory range 0x00000000FE028000-0x00000000FE0281FF conflicts with OpRegion 0x00000000FE028000-0x00000000FE028207 (\_SB.PCI0.GEXP.BAR0) (20251212/utaddress-204) ACPI: OSL: Resource conflict; ACPI support missing from driver? intel-lpss INT3446:00: probe with driver intel-lpss failed with error -16 ``` ## Notes - Ruled out: BIOS/firmware VBT differences (confirmed byte-identical between working and broken systems), xfce4-power-manager or other userspace brightness helpers (issue reproduces on a bare TTY with no X11/compositor running), gamma/compositor dimming (`xrandr --verbose` shows `Gamma: 1.0:1.0:1.0`), DPCD/AUX vs native PWM backlight type mismatch (VBT explicitly specifies type 2 / native DDI PWM, and forcing DPCD via `enable_dpcd_backlight` made no difference). - This strongly points to a regression in the i915 PWM/backlight range calculation code introduced somewhere between kernel 6.8 and 7.0 (exact commit not yet bisected). ## Suggested Next Steps for Investigation - Bisect between v6.8 and v7.0 mainline kernels to identify the offending commit in `drivers/gpu/drm/i915/display/intel_backlight.c` (or related PWM period/precision calculation code). - Compare computed PWM period/precision-bit values between the two kernel versions for this specific panel (Skylake-era native PWM, VBT type 2, 200 Hz). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2161713/+subscriptions
Комментариев нет:
Отправить комментарий