<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - 24bpp (True Color) limited RGB fix for Intel Graphics over DisplayPort"
href="https://bugs.freedesktop.org/show_bug.cgi?id=107476">107476</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>24bpp (True Color) limited RGB fix for Intel Graphics over DisplayPort
</td>
</tr>
<tr>
<th>Product</th>
<td>DRI
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>critical
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>DRM/Intel
</td>
</tr>
<tr>
<th>Assignee</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>nicholas.stommel@gmail.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>CC</th>
<td>intel-gfx-bugs@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=140958" name="attach_140958" title="proposed fix for auto full-range RGB color over 24bpp DisplayPort monitors">attachment 140958</a> <a href="attachment.cgi?id=140958&action=edit" title="proposed fix for auto full-range RGB color over 24bpp DisplayPort monitors">[details]</a></span> <a href='page.cgi?id=splinter.html&bug=107476&attachment=140958'>[review]</a>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>