[Bug 107476] New: 24bpp (True Color) limited RGB fix for Intel Graphics over DisplayPort

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107476

            Bug ID: 107476
           Summary: 24bpp (True Color) limited RGB fix for Intel Graphics
                    over DisplayPort
           Product: DRI
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: critical
          Priority: medium
         Component: DRM/Intel
          Assignee: intel-gfx-bugs at lists.freedesktop.org
          Reporter: nicholas.stommel at gmail.com
        QA Contact: intel-gfx-bugs at lists.freedesktop.org
                CC: intel-gfx-bugs at lists.freedesktop.org

Created attachment 140958
  --> https://bugs.freedesktop.org/attachment.cgi?id=140958&action=edit
proposed fix for auto full-range RGB color over 24bpp DisplayPort monitors

Expected behavior: connect computer with Intel integrated graphics (in my case
the HD 630 iGPU on an HP Elitedesk 800 G3 DM with an i7-7700 Intel processor)
to a 24-bit color monitor over native DisplayPort and receive full-range 0:255
RGB color. 

Actual behavior: when computer is connected via native native DisplayPort to a
DisplayPort monitor that supports 24-bit color depth (which is most monitors on
the market today, and all the monitors with native DP-in that I tried), it
*always* defaults to outputting limited-range, borderline unusable, washed-out
16:235 RGB. 

I originally filed this bug in the incorrect place on the kernel bugzilla and
had some difficulty with the code logic so I would prefer the issue to be
addressed better here, as it is very much a problem with the Intel DisplayPort
video driver in the Linux kernel. 

The problem here is quite clear: only 18bpp color DP displays are actually
receiving correct full-range color by default. This means *any* 18bpp DP
display  will yield in an immediate short-circuit boolean 'false' value,
setting pipe_config->limited_color_range = false, thereby delivering full-range
RGB appropriately. My small patch simply extends that behavior to 24bpp DP
displays. See the unpatched condition below that only accounts for 18bpp
displays: 

pipe_config->limited_color_range =
  bpp != 18 &&
  drm_default_rgb_quant_range(adjusted_mode) ==
  HDMI_QUANTIZATION_RANGE_LIMITED;

On further inspection, (and what I failed to originally see in the prior bug
report) Intel currently isn't even testing whether displays with 18bpp adhere
to the CEA/VESA spec, as the function drm_default_rgb_quant_range(...) is never
actually executed. Which just makes me confused. Why should those of us with
24bpp True Color displays *not* be getting full-range color over DP, especially
when the color depth is actually greater than 18bpp? It doesn't make sense. 

No 24-bit 16.7 million color display that takes DisplayPort-in even *expects*
something besides full-range RGB. Without this fix, using a native DP
connection through integrated Intel graphics on Linux is no joke unusable
without manually setting correct color depth, which isn't even currently
possible in Wayland, and doesn't fix KMS plymouth boot-screen or text-mode
things before the display server is initialized. 

The second condition involving a function call that checks display modes to
determine color range is unreliable and fails (returns value representing
limited-range instead of full-range RGB) on every VESA certified DP display I
have tried, which I suppose is the other primary part of this bug. Furthermore,
that "automagic" drm_default_rgb_quant_range(...) function is not even
currently called for 18bpp displays. 24bpp DP displays should receive equal
treatment here, and also short-circuit in the logic statement above to
limited_color_range = false, just the same as 18bpp DP displays currently do. I
implore someone at Intel to address this issue. I simply cannot use native DP
on Linux without literally recompiling the kernel every single point release.

My attached patch for the latest mainline 4.17.11 kernel enforces skipping the
unreliable CEA/VESA compliance checks just as the "bpp != 18" clause already
does, unless perhaps the bpp alone determines the appropriate color range
(which isn't that far fetched really, and it's what is currently happening for
18bpp DP displays). This DP color range bug requires a fix, even if it's not in
the manner I originally approached it. Thank you for bearing with me here, and
I hope that this issue can be resolved soon.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20180803/12e59663/attachment.html>