Bug 200711

Essentially your patch means to avoid using limited range as default for "all DP in reality", which is one of the approaches I proposed, so good luck having Intel accpeting it. (No offense but the extra check makes less sense than just equate auto to full.)

To be honest I don't expect Intel to fix it (by avoiding limited as default) anyway. The DP spec is just some braindead cheap copycat work from some idiot (VESA) that tried to dominate the world but failed (after all those years HDMI just exists and evolve parallelly on the AV world, with DP do only on the computer word), so there's not a real point in arguing whether Intel is doing the right thing or wrong thing.

I think we deserves something like per-port sysfs for the attribute though. I hope someday someone would do it. Couldn't care less though, as I did enough for this as a human being (while some people can earn money by keep producing garbage driver).

pipe_config->limited_color_range = false

No, the patch does NOT mean avoiding limited range as default for "all DP in reality", as the drm CEA mode check line is still very much in place and working correctly. And frankly, I rather like DisplayPort as a video standard, Tom. It is under no circumstances "some braindead cheap copycat work". For some uses, dual DP++ is far superior to HDMI. This fix does NOT default set the RGB range to full over any DP connection like setting 

pipe_config->limited_color_range = false. 

Accounting for 24bpp displays (just as 18bpp displays are accounted for) in the conditional statement under regarding automatic color range selection INTEL_BROADCAST_RGB_AUTO) and setting limited_color_range to false entirely adheres to the Intel spec. Furthermore, the color range WILL be correctly be set to limited on DP connections that do not adhere to the VESA spec in

drm_default_rgb_quant_range(adjusted_mode) == 
HDMI_QUANTIZATION_RANGE_LIMITED;

This is a constructive and important matter for many 24bpp True Color displays that is itself an entirely different bug than #94921. Furthermore, the small patch keeps all of Intel's automatic mode selection work entirely in place. I would appreciate some input from Intel here, as this is evidently something that can and should be changed.

Constructive input from Intel here would be nice. I would appreciate if we could keep the conversation limited to 24bpp True Color being correctly handled over DP, regardless of Tom's feelings towards/remarks concerning Intel. This is very much a relevant and fixable issue that doesn't demand any kind of radical changes on the Intel driver side. CEA/VESA mode detection clearly works as intended, with the exception of the case of DisplayPort 24bpp displays (as evident in the minor edit of the conditional statement in the patch).

To be clear: this is not a feature request. It is most certainly a bug, perhaps one that only became evident when 24bpp True Color monitors became widespread. As it stands before the patch, DP sinks on 24bpp True Color displays erroneously fail the part of the color range conditional check, always setting the output RGB range to washed-out limited 16:235. The expected and correct behavior in full adherence to the VESA/CEA spec is outputting the full 0:255 RGB color range over DisplayPort on 24bpp True Color displays. Intel, I respectfully ask of you to fix this issue, with something like the minor patch I attached.

 (In reply to Tom Yan from comment #1)
> Essentially your patch means to avoid using limited range as default for
> "all DP in reality", which is one of the approaches I proposed, so good luck
> having Intel accpeting it. (No offense but the extra check makes less sense
> than just equate auto to full.)

Oh...wait. My logic was incorrect indeed. Tom is basically right here, as what is CURRENTLY happening in the conditional statement means ANY DP 18bpp display (and with my small patch ANY DP 24bpp display) will result in an immediate short-circuit boolean 'false' value, setting pipe_config->limited_color_range = false. See the unpatched condition below: 

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

On further inspection, 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 or 30+bpp HDR displays *not* be getting full-range color? It doesn't even make sense. So now I suppose we are right back where we started at bug #94921. 

I do believe this particular harcoded hack "bpp != 18" is, however, a bug. 24bpp displays should receive equal treatment in that 24bpp DP displays should 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.

Realizing the truth of the matter here by examining the logic with a more...rational eye, if 18bpp displays unconditionally receive full-range 0:255 RGB color, then 24bpp True Color displays should as well. No 24-bit 16.7 million color display that takes DisplayPort-in even expects something besides full range RGB. The second condition involving a function call that checks display modes is, as Tom correctly pointed out and I originally failed to see, not even evaluated for 18bpp displays and the current code simply does not make logical sense. I just want my computer to properly display color, instead of washed-out soupy gray-black. As an Intel customer with no other options available, I am stuck in this situation just as, I expect, many other users have been for several years. Please at the very least look into this issue. If I had known how bad the situation was, I never would have purchased this computer months ago, but I couldn't have known that and certainly won't be able to produce the funds for another computer in quite some time. This matter is one of great disappointment and dissatisfaction, but I fear there is nothing that will be done :(

I may have made myself look like something of a fool here, but the very nature of that one inverted boolean statement in comment #6 found in intel_dp.c is misleading. The logic is fundamentally flawed and self-deceiving on Intel's part because 18bpp displays are *not even checked* for VESA/CEA mode compliance as the statement short-circuits to false after evaluating bpp != 18, ignoring the "automagical" function call entirely. This seems for all intents and purposes a hardcoded hack implemented five years ago that doesn't consider the possibility of 24 or 30+ bit color depth over DP connections. 

As it stands, the code does not account for True Color or Deep Color/HDR displays whatsoever. My patch simply enforces skipping VESA compliance checks just as the "bpp != 18" clause already does, unless perhaps the bpp alone can determine the appropriate color range (which isn't so far fetched in the 2013 white paper). This upsetting color range bug does need a fix, even if it's not in the manner I originally approached it. I apologize if I have been overzealous in my demands (I'm pleading somewhat desperately here), but honestly fixing this single problem would be immensely helpful for many Linux users who rely on integrated Intel graphics.

Due to the confusion surrounding some of my original posts which I am unable to edit, and the fact this bug was filed in the wrong place to begin with, I have moved it to appropriately to https://bugs.freedesktop.org/show_bug.cgi?id=107476