linux-kernel - Re: [PATCH v3 5/5] drm/i915: Clarify probing order in intel_dp_aux_init_backlight

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 19 Oct 2021 21:15:02 +0300
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Lyude Paul <lyude@...hat.com>
Cc:     intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
        nouveau@...ts.freedesktop.org,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Joonas Lahtinen <joonas.lahtinen@...ux.intel.com>,
        Rodrigo Vivi <rodrigo.vivi@...el.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Sean Paul <seanpaul@...omium.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 5/5] drm/i915: Clarify probing order in
 intel_dp_aux_init_backlight_funcs()

On Tue, Oct 05, 2021 at 10:40:18PM -0400, Lyude Paul wrote:
> Hooray! We've managed to hit enough bugs upstream that I've been able to
> come up with a pretty solid explanation for how backlight controls are
> actually supposed to be detected and used these days. As well, having the
> rest of the PWM bits in VESA's backlight interface implemented seems to
> have fixed all of the problematic brightness controls laptop panels that
> we've hit so far.
> 
> So, let's actually document this instead of just calling the laptop panels
> liars. As well, I would like to formally apologize to all of the laptop
> panels I called liars. I'm sorry laptop panels, hopefully you can all
> forgive me and we can move past this~
> 
> Signed-off-by: Lyude Paul <lyude@...hat.com>
> ---
>  .../drm/i915/display/intel_dp_aux_backlight.c    | 16 +++++++++++-----
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> 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 91daf9ab50e8..04a52d6a74ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -455,11 +455,17 @@ int intel_dp_aux_init_backlight_funcs(struct intel_connector *connector)
>  	}
>  
>  	/*
> -	 * A lot of eDP panels in the wild will report supporting both the
> -	 * Intel proprietary backlight control interface, and the VESA
> -	 * backlight control interface. Many of these panels are liars though,
> -	 * and will only work with the Intel interface. So, always probe for
> -	 * that first.
> +	 * Since Intel has their own backlight control interface, the majority of machines out there
> +	 * using DPCD backlight controls with Intel GPUs will be using this interface as opposed to
> +	 * the VESA interface. However, other GPUs (such as Nvidia's) will always use the VESA
> +	 * interface. This means that there's quite a number of panels out there that will advertise
> +	 * support for both interfaces, primarily systems with Intel/Nvidia hybrid GPU setups.
> +	 *
> +	 * There's a catch to this though: on many panels that advertise support for both
> +	 * interfaces, the VESA backlight interface will stop working once we've programmed the
> +	 * panel with Intel's OUI - which is also required for us to be able to detect Intel's
> +	 * backlight interface at all. This means that the only sensible way for us to detect both
> +	 * interfaces is to probe for Intel's first, and VESA's second.
>  	 */

You know a lot more about this than I do.

Acked-by: Ville Syrjälä <ville.syrjala@...ux.intel.com>

>  	if (try_intel_interface && intel_dp_aux_supports_hdr_backlight(connector)) {
>  		drm_dbg_kms(dev, "Using Intel proprietary eDP backlight controls\n");
> -- 
> 2.31.1

-- 
Ville Syrjälä
Intel