> Subject: RE: [PATCH v3 1/8] drm/i915/backlight: Use default/max brightness for
> VESA AUX backlight init
>
> On Mon, 02 Mar 2026, "Kandpal, Suraj" <[email protected]> wrote:
> >> Subject: RE: [PATCH v3 1/8] drm/i915/backlight: Use default/max
> >> brightness for VESA AUX backlight init
> >>
> >> On Wed, 25 Feb 2026, "Kandpal, Suraj" <[email protected]> wrote:
> >> >> Subject: Re: [PATCH v3 1/8] drm/i915/backlight: Use default/max
> >> >> brightness for VESA AUX backlight init
> >> >>
> >> >> On Tue, 24 Feb 2026, Suraj Kandpal <[email protected]> wrote:
> >> >> > If the brightness fetched from VBT/previous state is 0 on
> >> >> > backlight initialization, then set the brightness to a default/max
> >> >> > value.
> >> >> > Whenever the minimum brightness is reported as 0 there are
> >> >> > chances we end up with blank screen. This confuses the user into
> >> >> > thinking the display is acting weird. This occurs in eDP 1.5
> >> >> > when we are using PANEL_LUMINANCE_OVERRIDE mode to mainpulate
> >> >> > brightness via luminance values.
> >> >> >
> >> >> > Closes:
> >> >> > https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15671
> >> >> > Signed-off-by: Suraj Kandpal <[email protected]>
> >> >> > Reviewed-by: Arun R Murthy <[email protected]>
> >> >> > ---
> >> >> > v1 -> v2:
> >> >> > - Let users set brightness to 0, make it so that it's just not
> >> >> > done by default (Arun)
> >> >> >
> >> >> > v2 -> v3:
> >> >> > -Update commit header and message (Arun)
> >> >> >
> >> >> > drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 4 ++++
> >> >> > 1 file changed, 4 insertions(+)
> >> >> >
> >> >> > diff --git
> >> >> > a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> >> > b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> >> > index eb05ef4bd9f6..c40ce310ad97 100644
> >> >> > --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> >> >> > @@ -564,6 +564,8 @@ static int
> >> >> > intel_dp_aux_vesa_setup_backlight(struct
> >> >> intel_connector *connector,
> >> >> > }
> >> >> > panel->backlight.level =
> >> >> intel_dp_aux_vesa_get_backlight(connector, 0);
> >> >> > panel->backlight.enabled = panel->backlight.level != 0;
> >> >> > + if (!panel->backlight.level)
> >> >> > + panel->backlight.level = panel->backlight.max;
> >> >>
> >> >> How does this help when .enabled is still based on level != 0 above?
> >> >>
> >> >
> >> > Well we keep the backlight.enabled as false if we read a 0 back
> >> > from the DPCD
> >> or the current level state is 0.
> >> > This is to maintain the policy that if during setup we get 0 as
> >> > backlight value eDP backlight is currently disabled (which means
> >> > __intel_backlight_enable needs be called). We then change the
> >> > current level to max so that when backlight enable is called after
> >> > setup from
> >> intel_backlight_update, we enable backlight with max level so that we
> >> do not end up with a blank screen. This is also where we set
> backlight.enabled = true.
> >> > This is to tackle different eDP behavior where, some preserve the
> >> > last brightness value programmed in them (in that case users want
> >> > the same brightness to continue) while others don't and just 0 it
> >> > out instead of
> >> having some default value (in that case we keep backlight.enabled =
> >> false later to be made true during the __intel_backlight_enable call).
> >> > We face these scenarios in some compositors during the pass key
> >> > phase where the compositor is still totally not doing everything
> >> > and does not send
> >> us any explicit brightness value to set thinking eDP would have some
> >> basic default value of it's own . We end up getting a 0 from DPCD and
> >> we enable and set the backlight enable with 0 value which anyways
> >> later causes us to call backlight disable.
> >> > In this case during authentication in some compositors like Fedora
> >> > there are cases where we do not get a explicitly backlight value
> >> > till the user
> >> has to blindly enter their Passkey, after which the compositor sends
> >> us some sane value which we then program.
> >>
> >> There's a long history of problems with the PWM backlight
> >> unexpectedly going from 0 to max.
> >
> > Right but at least with this now luminance values will continue if
> > DPCD maintains its state if we get a value back, otherwise we set a Default
> value.
>
> What's the brightness control mode *before* we enable luminance control?
>
> When taking over, we should try to read the current brightness setting with
> the
> current brightness control method. If we're switching to luminance control,
> the
> existing luminance value is meaningless.
>
> AFAICT drm_edp_backlight_probe_state() uses bl->luminance_set to determine
> the value to read, not the current mode. At a glance, seems wrong to me.
>
> Of course, regressions have priority, so a revert should also be a
> consideration
> before quickly going for adding level = max in there.
>
I did some more digging and for aux_set enabled we really do not need to do
get_backlight
And read register again that is filled in probe state and fills up the
current_level variable that can be use.
Check drm_edp_backlight_probe_state.
I also found this little comment there
/*
* If we're not in DPCD control mode yet, the programmed brightness
value is meaningless and
* the driver should assume max brightness
*/
return bl->max;
So this was a policy that was decided during VESA AUX Backlight implementation
time. Also that Mode will not be DPCD
Initially and will change later during backlight enable so we get to assume max
brightness . That should be okay to do with
Luminance_set case too then.
Regards,
Suraj Kandpal
> > Can we proceed with getting this merged ? Would really help the user.
>
> The real problem with quick fixes to help the user is that they have the
> potential to make it a lot harder for a lot more users and developers in the
> long
> run.
>
>
> BR,
> Jani.
>
> >
> > Regards,
> > Suraj Kandpal
> >
> >>
> >> BR,
> >> Jani.
> >>
> >> >
> >> > Regards,
> >> > Suraj Kandpal
> >> >
> >> >> > drm_dbg_kms(display->drm,
> >> >> > "[CONNECTOR:%d:%s] AUX VESA Nits
> backlight level
> >> >> is controlled through DPCD\n",
> >> >> > connector->base.base.id, connector-
> >base.name);
> >> >> @@ -573,6
> >> >> > +575,8 @@ static int intel_dp_aux_vesa_setup_backlight(struct
> >> >> intel_connector *connector,
> >> >> > if (current_mode ==
> >> >> DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD) {
> >> >> > panel->backlight.level = current_level;
> >> >> > panel->backlight.enabled = panel-
> >backlight.level != 0;
> >> >> > + if (!panel->backlight.level)
> >> >> > + panel->backlight.level = panel-
> >backlight.max;
> >> >>
> >> >> Ditto.
> >> >>
> >> >> > } else {
> >> >> > panel->backlight.level = panel->backlight.max;
> >> >> > panel->backlight.enabled = false;
> >> >>
> >> >> --
> >> >> Jani Nikula, Intel
> >>
> >> --
> >> Jani Nikula, Intel
>
> --
> Jani Nikula, Intel
