Public bug reported: Kernel 7.0.0-28-generic broke screen brightness control on my ASUS X580VD (Intel iGPU + NVIDIA Optimus, panel on i915/eDP). Confirmed via direct bisection: works on 7.0.0-27-generic, broken on 7.0.0-28-generic with everything else identical. Root cause: the "Patchset for TUXEDO devices" (LP: #2152570) backported into 7.0.0-28 includes commit 40d2f5820951 ("drm/i915/backlight: Remove try_vesa_interface"). This removes the gate on intel_dp_aux_supports_vesa_backlight() in drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c, so the driver now tries VESA/DPCD AUX backlight unconditionally whenever the panel's DPCD capability bits look plausible - even when the VBT correctly declares INTEL_BACKLIGHT_DISPLAY_DDI and the panel's real backlight control is native PWM. This exact regression was already found and fixed upstream: commit 2914709c9141 ("Revert \"drm/i915/backlight: Remove try_vesa_interface\""), merged 2026-05-17 by Suraj Kandpal (Intel), reviewed by Ankit Nautiyal, already cherry-picked into a stable tree as f30fddb44023. Its commit message describes this bug precisely: "Removing the try_vesa_interface gate caused a backlight regression on panels whose VBT correctly reports INTEL_BACKLIGHT_DISPLAY_DDI and whose PWM path is the actual backlight control, but whose DPCD optimistically advertises DP_EDP_BACKLIGHT_AUX_ENABLE_CAP / _BRIGHTNESS_AUX_SET_CAP. After the commit such panels silently bind to the VESA AUX backlight funcs; AUX writes complete but the panel ignores them, leaving brightness stuck (no-op backlight). Observed on at least KBL and TGL eDP setups." 7.0.0-28's TUXEDO backport included the regression-causing commit but not this later upstream revert. Requesting 2914709c9141 be cherry-picked into the next resolute kernel SRU. Confirmed locally: booting with i915.enable_dpcd_backlight=0 (forcing the same native-PWM path the revert restores) fully fixes brightness. dmesg with drm.debug=0x1e shows the driver binding to VESA AUX backlight by default and native PCH PWM ("Using native PCH PWM for backlight control") once forced off - AUX writes succeed but produce no physical change, matching the revert's description exactly. Panel DPCD (eDP): 02 b7 f6 00 00 (eDP 1.3, DP_EDP_BACKLIGHT_AUX_ENABLE_CAP and DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP both set despite AUX backlight not functioning on this hardware). ** 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/2162630 Title: 7.0.0-28 TUXEDO backlight backport missing upstream revert 2914709c9141 — breaks brightness on ASUS X580VD (and likely other DISPLAY_DDI panels) Status in linux package in Ubuntu: New Bug description: Kernel 7.0.0-28-generic broke screen brightness control on my ASUS X580VD (Intel iGPU + NVIDIA Optimus, panel on i915/eDP). Confirmed via direct bisection: works on 7.0.0-27-generic, broken on 7.0.0-28-generic with everything else identical. Root cause: the "Patchset for TUXEDO devices" (LP: #2152570) backported into 7.0.0-28 includes commit 40d2f5820951 ("drm/i915/backlight: Remove try_vesa_interface"). This removes the gate on intel_dp_aux_supports_vesa_backlight() in drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c, so the driver now tries VESA/DPCD AUX backlight unconditionally whenever the panel's DPCD capability bits look plausible - even when the VBT correctly declares INTEL_BACKLIGHT_DISPLAY_DDI and the panel's real backlight control is native PWM. This exact regression was already found and fixed upstream: commit 2914709c9141 ("Revert \"drm/i915/backlight: Remove try_vesa_interface\""), merged 2026-05-17 by Suraj Kandpal (Intel), reviewed by Ankit Nautiyal, already cherry-picked into a stable tree as f30fddb44023. Its commit message describes this bug precisely: "Removing the try_vesa_interface gate caused a backlight regression on panels whose VBT correctly reports INTEL_BACKLIGHT_DISPLAY_DDI and whose PWM path is the actual backlight control, but whose DPCD optimistically advertises DP_EDP_BACKLIGHT_AUX_ENABLE_CAP / _BRIGHTNESS_AUX_SET_CAP. After the commit such panels silently bind to the VESA AUX backlight funcs; AUX writes complete but the panel ignores them, leaving brightness stuck (no-op backlight). Observed on at least KBL and TGL eDP setups." 7.0.0-28's TUXEDO backport included the regression-causing commit but not this later upstream revert. Requesting 2914709c9141 be cherry-picked into the next resolute kernel SRU. Confirmed locally: booting with i915.enable_dpcd_backlight=0 (forcing the same native-PWM path the revert restores) fully fixes brightness. dmesg with drm.debug=0x1e shows the driver binding to VESA AUX backlight by default and native PCH PWM ("Using native PCH PWM for backlight control") once forced off - AUX writes succeed but produce no physical change, matching the revert's description exactly. Panel DPCD (eDP): 02 b7 f6 00 00 (eDP 1.3, DP_EDP_BACKLIGHT_AUX_ENABLE_CAP and DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP both set despite AUX backlight not functioning on this hardware). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2162630/+subscriptions
Комментариев нет:
Отправить комментарий