linux-kernel - Re: [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <87bmvlhpb0.fsf@intel.com>
Date:   Thu, 05 Jan 2017 10:41:07 +0200
From:   Jani Nikula <jani.nikula@...el.com>
To:     Lyude <lyude@...hat.com>, intel-gfx@...ts.freedesktop.org
Cc:     Lyude <lyude@...hat.com>, Chris Wilson <chris@...is-wilson.co.uk>,
        Daniel Vetter <daniel@...ll.ch>,
        Ville Syrjälä <ville.syrjala@...ux.intel.com>,
        Daniel Vetter <daniel.vetter@...el.com>,
        David Airlie <airlied@...ux.ie>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/i915/dp: Stop enabling limited color ranges for everything

On Thu, 05 Jan 2017, Lyude <lyude@...hat.com> wrote:
> Until now, it seems we've been erroneously enabling limited color ranges
> for the vast majority of DisplayPort monitors. I noticed this after
> writing a frame dump comparison test for the Chamelium and noticing that
> every i915 device I had was failing, while amdgpu machines were fine:
>
> https://people.freedesktop.org/~lyudess/archive/01-03-2017/
>
> It looks like this is because the DisplayPort spec tells us to use
> limited color ranges whenever we detect a CEA mode in use. However, from
> the looks of it there's another rather confusing part of the spec that
> got missed: source devices are allowed to use the full range of values
> for pixels -even- if the sink device declares that it's using a CEA
> mode. It's up to the sink device to limit the pixel range to the CEA
> ranges if it needs.

DP 1.2a 5.1.1.1 Video Colorimetry

* When a Source device is transmitting an RGB stream with a video timing
  format called out in CEA-861C Section 5 (except 640 x 480p) as using
  CEA range RGB, it should use CEA range RGB.

* When a Source device is transmitting a RGB stream with a video timing
  format called out in CEA-861C Section 5 as using CEA range RGB, it
  must use the CEA range RGB.

* However, a Source device may transmit all code values from zero to the
  maximum even when it declares the CEA range in the Main Stream
  Attributes. It is the responsibility of the Sink device to limit the
  pixel value range as needed.

The spec has a conflict about SHOULD and MUST. Nevertheless, using CEA
range is at least recommended. When using CEA range, the CEA range MUST
be declared in Main Stream Attributes for CEA modes, but full range of
values MAY be transmitted.

DP 1.4 5.1.1.1 Video Colorimetry

* When a Source device is transmitting an RGB stream with a video timing
  format called out in CEA-861-F, Section 5 (except 640x480p) as using
  CEA range RGB, it should use CEA range RGB.

* When a Source device is transmitting an RGB stream with a video timing
  format called out in CEA-861-F, the device may provide RGB in the VESA
  range.

* The Sink device shall have the responsibility of limiting the pixel
  value range, as needed.

The conflict has been resolved, using CEA range is now
recommended. However, the source MAY also use VESA range. I take it that
means the source could also declare VESA range in Main Stream
Attributes.

---

I am not sure if we'd be able to declare CEA range in Main Stream
Attributes but transmit VESA range anyway. Feels kind of silly anyway,
and IIUC would only be according to DP 1.2a. It boils down to CEA range
vs. VESA range.

> I'm really surprised that this bug would have been around as long as it looks
> like it has been without anyone noticing it, so I figured I'd just send a patch
> to the mailing list so you guys can point out whether or not this is really the
> correct thing to do.

We've had the same discussion several times over with HDMI for sure, but
I think also with DP. The conclusion has always been that no matter
which range we choose as the default, it's going to be wrong for some
displays. And when it turns into a contest of who complains the loudest,
it's a no brainer to go by spec. It's never been less than recommended
to go with CEA range for CEA modes, regardless of the conflict in DP
1.2a.

No matter what we do here, the question remains what to do with
Chamelium. Changing the color range is really a workaround for
Chamelium, not a fix. Using CEA range is perfectly fine per DP spec.

BR,
Jani.

>
>  drivers/gpu/drm/i915/intel_dp.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index d9bc19b..6642abd 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -1649,12 +1649,15 @@ intel_dp_compute_config(struct intel_encoder *encoder,
>  found:
>  	if (intel_dp->color_range_auto) {
>  		/*
> +		 * We are required to use the limited CEA RGB range when a CEA
> +		 * mode is declared in the EDID. However, limiting the pixel
> +		 * value range is up to the sink, not the source. So, just
> +		 * don't enable limited color ranges.
>  		 * See:
>  		 * CEA-861-E - 5.1 Default Encoding Parameters
>  		 * VESA DisplayPort Ver.1.2a - 5.1.1.1 Video Colorimetry
>  		 */
> -		pipe_config->limited_color_range =
> -			bpp != 18 && drm_match_cea_mode(adjusted_mode) > 1;
> +		pipe_config->limited_color_range = false;
>  	} else {
>  		pipe_config->limited_color_range =
>  			intel_dp->limited_color_range;

-- 
Jani Nikula, Intel Open Source Technology Center