All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Kandpal, Suraj" <suraj.kandpal@intel.com>,
	"intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>
Cc: "Murthy, Arun R" <arun.r.murthy@intel.com>
Subject: RE: [PATCH v3 1/8] drm/i915/backlight: Use default/max brightness for VESA AUX backlight init
Date: Mon, 02 Mar 2026 11:42:07 +0200	[thread overview]
Message-ID: <9f9be7c4361428b7ccb77dcc04f93b0eda024c8b@intel.com> (raw)
In-Reply-To: <DM3PPF208195D8DACF643E4D0D138F0128CE375A@DM3PPF208195D8D.namprd11.prod.outlook.com>

On Wed, 25 Feb 2026, "Kandpal, Suraj" <suraj.kandpal@intel.com> 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 <suraj.kandpal@intel.com> 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 <suraj.kandpal@intel.com>
>> > Reviewed-by: Arun R Murthy <arun.r.murthy@intel.com>
>> > ---
>> > 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.

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

  reply	other threads:[~2026-03-02  9:42 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-24  3:45 [PATCH v3 0/8] Fixes and updates when using AUX backlight using Luminance Suraj Kandpal
2026-02-24  3:45 ` [PATCH v3 1/8] drm/i915/backlight: Use default/max brightness for VESA AUX backlight init Suraj Kandpal
2026-02-24 12:31   ` Jani Nikula
2026-02-25  4:43     ` Kandpal, Suraj
2026-03-02  9:42       ` Jani Nikula [this message]
2026-03-02 10:00         ` Kandpal, Suraj
2026-03-02 10:28           ` Jani Nikula
2026-03-02 11:04             ` Kandpal, Suraj
2026-03-02 11:25               ` Jani Nikula
2026-03-04  5:49             ` Kandpal, Suraj
2026-03-04 12:06               ` Jani Nikula
2026-02-24  3:45 ` [PATCH v3 2/8] drm/i915/backlight: Use intel_panel variable instead of intel_connector Suraj Kandpal
2026-02-24  3:45 ` [PATCH v3 3/8] drm/i915/backlight: Take luminance_set into account for VESA backlight Suraj Kandpal
2026-02-24  3:45 ` [PATCH v3 4/8] drm/i915/backlight: Check luminance_set when disabling PWM via AUX " Suraj Kandpal
2026-02-24  3:45 ` [PATCH v3 5/8] drm/i915/backlight: Short circuit intel_dp_aux_supports_hdr_backlight Suraj Kandpal
2026-02-24  3:45 ` [PATCH v3 6/8] drm/i915/backlight: Update debug log during backlight setup Suraj Kandpal
2026-02-24  3:45 ` [PATCH v3 7/8] drm/i915/backlight: Provide clear description on how backlight level is controlled Suraj Kandpal
2026-02-24  3:45 ` [PATCH v3 8/8] drm/i915/backlight: Use default/max brightness for INTEL AUX HDR backlight init Suraj Kandpal
2026-02-24 12:32   ` Jani Nikula
2026-02-24  3:54 ` ✓ CI.KUnit: success for Fixes and updates when using AUX backlight using Luminance (rev3) Patchwork
2026-02-24  4:56 ` ✓ i915.CI.BAT: " Patchwork
2026-02-24  8:04 ` ✗ i915.CI.Full: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9f9be7c4361428b7ccb77dcc04f93b0eda024c8b@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=arun.r.murthy@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=suraj.kandpal@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.