-
Gareth Yu authored
Historically the expectation was to set brightness to max on enable, if it was zero. However, the policy should be to preserve brightness across disable/enable, for example the userspace might want to dim the brightness before disable (e.g. on suspend) and gradually bring it back up after enable (e.g. on resume). If the brightness gets bumped to max at enable, this causes flicker as the userspace expects the brightness to have been preserved across disable/enable. For example: (suspend) [53949.248875] i915 0000:00:02.0: [drm:intel_edp_backlight_off] [53949.452046] i915 0000:00:02.0: [drm:intel_backlight_set_pwm_level] set backlight PWM = 0 (wakeup) [53986.067356] i915 0000:00:02.0: [drm:intel_edp_backlight_on] [53986.067367] i915 0000:00:02.0: [drm:intel_backlight_enable] pipe A [53986.067476] i915 0000:00:02.0: [drm:intel_backlight_set_pwm_level] set backlight PWM = 96000 [53986.119766] backlight intel_backlight: PM: calling backlight_resume+0x0/0x7a @ 4916, parent: card0-eDP-1 [53986.119781] backlight intel_backlight: PM: backlight_resume+0x0/0x7a returned 0 after 0 usecs [53986.220068] [drm:intel_backlight_device_update_status] updating intel_backlight, brightness=26321/96000 [53986.220086] i915 0000:00:02.0: [drm:intel_panel_actually_set_backlight] set backlight level = 27961 Reduce the check to respecting the minimum brightness, and avoid bumping min brightness to max on enable. Note: It's possible there's still userspace out there that relies on the old behaviour. It would be unfortunate, but there's really only one way to find out. Cc: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Gareth Yu <gareth.yu@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [Jani: Rewrote the commit message.] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240321045311.2124111-1-gareth.yu@intel.com
92714006