Bug 100023 - [SKL] LSPCon and DisplayPort always output limited range RGB, even when it should output full range RGB
Summary: [SKL] LSPCon and DisplayPort always output limited range RGB, even when it sh...
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: high major
Assignee: Swati Sharma
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-01 16:45 UTC by N. W.
Modified: 2018-10-15 13:14 UTC (History)
11 users (show)

See Also:
i915 platform: IVB, SKL
i915 features: display/DP, display/LSPCON


Attachments
attachment-28938-0.html (2.88 KB, text/html)
2017-06-29 22:43 UTC, shashank.sharma@intel.com
no flags Details
attachment-16180-0.html (2.88 KB, text/html)
2018-07-23 13:26 UTC, shashank.sharma@intel.com
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description N. W. 2017-03-01 16:45:37 UTC
What the title says.

Follow-up to: https://bugs.freedesktop.org/show_bug.cgi?id=94248
Comment 1 N. W. 2017-03-01 16:48:28 UTC
Relevant quote from https://bugs.freedesktop.org/show_bug.cgi?id=94248#c94 :

(In reply to Ville Syrjala from comment #94)
> 
> [   12.431104] [drm:intel_atomic_check [i915]] [CONNECTOR:56:HDMI-A-2]
> checking for sink bpp constrains
> [   12.431151] [drm:intel_atomic_check [i915]] clamping display bpp (was 36)
> to default limit of 24
> [   12.431201] [drm:intel_hdmi_compute_config [i915]] picking bpc to 8 for
> HDMI output
> [   12.431246] [drm:intel_hdmi_compute_config [i915]] forcing pipe bpc to 24
> for HDMI
> [   12.431293] [drm:intel_atomic_check [i915]] hw max bpp: 36, pipe bpp: 24,
> dithering: 0
> [   12.431359] [drm:intel_dump_pipe_config [i915]] [CRTC:31:pipe A][modeset]
> [   12.431403] [drm:intel_dump_pipe_config [i915]] cpu_transcoder: A, pipe
> bpp: 24, dithering: 0
> [   12.431446] [drm:intel_dump_pipe_config [i915]] audio: 0, infoframes: 0
> 
> That "infoframes: 0" part is telling me that your display likely doesn't
> identify itself as supporting HDMI, so we treat it as DVI and decide to send
> it full range data instead of limited range data. But for DP (which is what
> LSPCON is for us) we don't make that distinction. Unfortunately the DP spec
> doesn't make any useful provisions for these kinds of combinations. so we're
> basically left to guess what we should be doing.
> 
> I think what we might want to do is send full range data regardless of the
> timings when dealing with a DVI/HDMI downstream port and the monitor doesn't
> identify itself as HDMI compatible (essentially using the same logic as we
> use for native HDMI). DP++ downstream port might more difficult since I
> don't recall if we can somehow tell if the plugged in monitor is actually
> DVI/HDMI or DP (I'll need to look into this a bit more). For
> VGA/NO_EDID/whatnot downstream ports sending full range all the time might
> be the right choice.
Comment 2 N. W. 2017-03-01 18:10:28 UTC
I don't think it was correct to set this to "i915 features: display/LSPCON", since Ville Syrjala said this is about DisplayPort. He said LSPCon is being treated as DisplayPort, which is why the issue is also affecting LSPCon.

But essentially it's DisplayPort as far as I understood him.
Comment 3 N. W. 2017-03-18 20:58:29 UTC
Any update?
Comment 4 shashank.sharma@intel.com 2017-06-29 22:43:29 UTC
Created attachment 132363 [details]
attachment-28938-0.html

Hello,
I am on vacation between 06 Dec - 16 Dec  with limited Phone and no mail access.
Please expect delay in response.

If this is something urgent, please contact my manager : Indranil, Mukherjee

Regards
Shashank
Comment 5 Elizabeth 2017-06-29 22:53:21 UTC
(In reply to N. W. from comment #3)
> Any update?

(In reply to N. W. from comment #3)
> Any update?

Hello N.W.,
Sorry for the long delay. Recently some features and fixes for DP had been included on kernel 4.12.-rc7. Could you try to replicate with this kernel? Also in order to speed up this case, could you add in this bug the HW and SW configuration, as same as the steps to reproduce and a dmesg log with parameter drm.debug=0xe on grub and a clean kern.log, both from boot till the error is present. Thank you.
Comment 6 Elizabeth 2017-08-31 21:11:57 UTC
Hello everyone, any update so far? Thanks.
Comment 7 Elizabeth 2017-10-06 17:41:59 UTC
Hello N.W., Shashank,
No news on this case have been reported for a while, is this case still valid? Lots of changes for DP and LSPCON have been done since 4.10 to current drm-tip 4.15, so probably this could be already fixed. N.W. Could you check? Thank you.
Comment 8 N. W. 2017-11-04 22:42:59 UTC
(In reply to Elizabeth from comment #5)
> Sorry for the long delay. Recently some features and fixes for DP had been
> included on kernel 4.12.-rc7. Could you try to replicate with this kernel?

I've just tested it with kernel 4.13 and the issue unfortunately is still there.

(In reply to Elizabeth from comment #5)
> Also in order to speed up this case, could you add in this bug the HW and SW
> configuration, as same as the steps to reproduce and a dmesg log with
> parameter drm.debug=0xe on grub and a clean kern.log, both from boot till
> the error is present. Thank you.

I had already provided all of this info and Ville Syrjala already commented on it, please check comment 1. Is there anything else you need to know to from me to fix this issue?

That being said: Please just fix https://bugzilla.kernel.org/show_bug.cgi?id=94921 instead of closing it without listening to your customers and the other issue will solve itself.
Comment 9 N. W. 2017-11-05 00:22:18 UTC
(In reply to Elizabeth from comment #7)
> Lots of changes for DP and LSPCON have been done since 4.10 to
> current drm-tip 4.15, so probably this could be already fixed. N.W. Could
> you check? Thank you.

In addition to kernel 4.13 (see previous post), I've also checked it with kernel 4.14-rc7 now. Issue is still there.

So, as already mentioned in the previous post, please fix https://bugzilla.kernel.org/show_bug.cgi?id=94921 so that this issue here will be fixed as well.
Comment 10 N. W. 2017-12-25 23:58:26 UTC
It's still _not_ fixed with kernel 4.15rc4.

When will you ever going to do something about this?

Please revert https://bugzilla.kernel.org/show_bug.cgi?id=94921 ASAP for kernel 4.15.

Ubuntu 18.04 will be an LTS release and will probably ship with kernel 4.14 (in which case it will already be too late) or, if we are lucky, with kernel 4.15, in which case we still would be able to revert https://lists.freedesktop.org/archives/dri-devel/2013-January/033576.html .

So, please revert it ASAP. Or please fix the issue ASAP.
Comment 11 N. W. 2018-01-16 22:02:34 UTC
Any update on this one?
Comment 12 Jani Saarinen 2018-03-29 07:10:59 UTC
First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.
Comment 13 Jani Saarinen 2018-04-25 06:40:43 UTC
Closing, please re-open is issue still exists.
Comment 14 N. W. 2018-05-01 13:29:12 UTC
Re-opening.
Comment 15 Jani Saarinen 2018-05-02 06:58:27 UTC
Jani, Ville, any help here?
Comment 16 Jani Nikula 2018-05-03 08:15:59 UTC
Please install some recent kernel, add drm.debug=14 module parameter, reproduce the problem, and attach dmesg to the bug.

Please ensure you have CONFIG_DRM_DP_AUX_CHARDEV=y, and do:

# dd if=/dev/drm_dp_aux0 > dpcd

Attach the result to the bug. If dd fails, please try ddrescue instead.
Comment 17 N. W. 2018-05-10 23:31:16 UTC
(In reply to Jani Nikula from comment #16)
> Please install some recent kernel

The issue is still there with kernel 4.16.7 and latest MegaChips MCDP2800 LSPCON firmware, nothing has changed, it still defaults to 16-235 even though it's connected to a DVI-D 0-255 input.

(In reply to Jani Nikula from comment #16)
> add drm.debug=14 module parameter,
> reproduce the problem, and attach dmesg to the bug.

What part of dmesg do you need?
 
(In reply to Jani Nikula from comment #16)
> Please ensure you have CONFIG_DRM_DP_AUX_CHARDEV=y, and do:
> 
> # dd if=/dev/drm_dp_aux0 > dpcd
> 
> Attach the result to the bug. If dd fails, please try ddrescue instead.

$ sudo dd if=/dev/drm_dp_aux0 > dpcd
dd: error reading '/dev/drm_dp_aux0': Connection timed out
0+0 records in
0+0 records out
0 bytes copied, 0,267088 s, 0,0 kB/s

$ sudo ddrescue /dev/drm_dp_aux0 /home/user/Documents/outputfile
GNU ddrescue 1.23
Press Ctrl-C to interrupt
     ipos:    74240 B, non-trimmed:        0 B,  current rate:       0 B/s
     opos:    74240 B, non-scraped:   973824 B,  average rate:       0 B/s
non-tried:        0 B,  bad-sector:    74752 B,    error rate:     512 B/s
  rescued:        0 B,   bad areas:        2,        run time:         43s
pct rescued:    0.00%, read errors:      162,  remaining time:         n/a
                              time since last successful read:         n/a
Scraping failed blocks... (forwards)

How long is that supposed to run? It seems to run for a long time without anything happening (outputfile stays empty). Are the commands correct?
Comment 18 Jani Nikula 2018-05-11 08:38:30 UTC
(In reply to N. W. from comment #17)
> What part of dmesg do you need?

Start to finish.
Comment 19 Jani Nikula 2018-05-11 08:40:10 UTC
(In reply to N. W. from comment #17)
> How long is that supposed to run? It seems to run for a long time without
> anything happening (outputfile stays empty). Are the commands correct?

Display enabled?

Is that the chardev that corresponds to the port in question?
Comment 20 Michał Kopeć 2018-07-05 14:57:51 UTC
Hello,

This issue is affecting me as well. My setup is:
 - ThinkPad T430
Comment 21 Michał Kopeć 2018-07-05 15:03:45 UTC
Apologies, previous comment was submitted accidentally before I finished it. Feel free to remove it.

This issue is affecting me as well. My setup is:
 - Lenovo ThinkPad T430 with HD 4000
 - HP LA2306x connected via DisplayPort on the laptop docking station
 - Arch Linux with kernel 4.17.3

DisplayPort output defaults to 16-235 color range, while any other outputs on the laptop will correctly output 0-255 full RGB. There is currently no way to set the driver to default to Full RGB regardless of what the display EDID is.
Comment 22 N. W. 2018-07-21 23:56:44 UTC
When will this finally be fixed?
Comment 23 Martin Peres 2018-07-23 13:25:38 UTC
(In reply to N. W. from comment #22)
> When will this finally be fixed?

Without the EDID, it is not possible for us to investigate where the issue lies :s. Could you answer Jani's question?
Comment 24 shashank.sharma@intel.com 2018-07-23 13:26:04 UTC
Created attachment 140781 [details]
attachment-16180-0.html

Hello,
I am on vacation between 06 Dec - 16 Dec  with limited Phone and no mail access.
Please expect delay in response.

If this is something urgent, please contact my manager : Indranil, Mukherjee

Regards
Shashank
Comment 25 Martin Peres 2018-07-23 13:26:54 UTC
(In reply to Michał Kopeć from comment #21)
> Apologies, previous comment was submitted accidentally before I finished it.
> Feel free to remove it.
> 
> This issue is affecting me as well. My setup is:
>  - Lenovo ThinkPad T430 with HD 4000
>  - HP LA2306x connected via DisplayPort on the laptop docking station
>  - Arch Linux with kernel 4.17.3
> 
> DisplayPort output defaults to 16-235 color range, while any other outputs
> on the laptop will correctly output 0-255 full RGB. There is currently no
> way to set the driver to default to Full RGB regardless of what the display
> EDID is.

Thanks for telling us! Could you follow the instructions of Jani in comment https://bugs.freedesktop.org/show_bug.cgi?id=100023#c16?
Comment 26 Nicholas Stommel 2018-08-07 23:55:03 UTC
I am having this same issue, I believe the report I filed for DP on True Color displays in bug #107476 is very similar to this bug report I found afterwards. 

(In reply to Michał Kopeć from comment #21)
> DisplayPort output defaults to 16-235 color range, while any other outputs
> on the laptop will correctly output 0-255 full RGB. There is currently no
> way to set the driver to default to Full RGB regardless of what the display
> EDID is.

Michal's comment sums up exactly what is currently happening. 

(In reply to N. W. from comment #8)
> That being said: Please just fix
> https://bugzilla.kernel.org/show_bug.cgi?id=94921 instead of closing it
> without listening to your customers and the other issue will solve itself.

I wholeheartedly agree with N.W. that something more needs to be done about https://bugzilla.kernel.org/show_bug.cgi?id=94921

However, my experience with Intel has been similar to Tom Yan's on https://bugzilla.kernel.org/show_bug.cgi?id=94921 and to N.W.'s on this bug thread. I don't think our concerns are really being taken into account here, and personally I feel like my failed attempts to figure out what precisely is going wrong were unkindly and summarily dismissed. I would greatly appreciate if Intel could take this issue more seriously and propose some kind of fix instead of threatening to close the issue entirely again. 

This is not a personal matter or an attack on Intel graphics developers, nor should it be treated as such. There is objectively something wrong when every DisplayPort output connector powered by Intel integrated graphics defaults to washed-out, limited 16-235 color on modern full range color displays. This issue is mainly about general usability of Intel graphics over DisplayPort on Linux, which likely affects far more users than the few of us who dug deep enough to find this bug report here.
Comment 27 Jani Nikula 2018-08-13 10:07:24 UTC
Please try https://bugs.freedesktop.org/show_bug.cgi?id=107476#c17
Comment 28 Nicholas Stommel 2018-08-14 03:40:00 UTC
(In reply to Jani Nikula from comment #27)
> Please try https://bugs.freedesktop.org/show_bug.cgi?id=107476#c17

Jani Nikula's patch works fantastically to fix color-range detection over native DisplayPort connections. I fully encourage anyone here to read Jani's patch notes, the fix is quite interesting. I am, however, unable to get full-range color over DP-LSPCON->HDMI, and currently cannot accurately test LSPCON due to the following bug: https://bugs.freedesktop.org/show_bug.cgi?id=107503 I will move the LSPCON discussion back to this thread, as my original bug report concerned only native DisplayPort color-range handling.
Comment 29 Jani Nikula 2018-08-14 08:21:55 UTC
Thanks for testing. Let's keep all LSPCON related limited range discussion here, and direct all native DP discussion to bug 107476.

Shashank's patch series [1] on top of drm-tip might fix the color range issue on LSPCON. As I wrote in the commit message of the patch [2] that fixes bug 107476, I'm guessing the LSPCON fails to turn the CEA range MSA into proper AVI infoframes. Turns out there's a way to manually override the infoframes the LSPCON produces, and this is what Shashank's patches do, although originally aimed at adding YCbCr support. Please test.

[1] https://patchwork.freedesktop.org/series/36068/
[2] http://patchwork.freedesktop.org/patch/msgid/20180814060001.18224-1-jani.nikula@intel.com
Comment 30 Jani Nikula 2018-08-14 09:37:58 UTC
Decreasing priority to high/major.
Comment 31 Lakshmi 2018-08-26 05:07:32 UTC
Reporter, can you apply below patch on drm-tip to ensure that issue is resolved?
https://patchwork.freedesktop.org/series/36068/
Comment 32 N. W. 2018-08-29 16:17:50 UTC
(In reply to Jani Nikula from comment #29)
> Shashank's patch series [1] on top of drm-tip might fix the color range
> issue on LSPCON. As I wrote in the commit message of the patch [2] that
> fixes bug 107476, I'm guessing the LSPCON fails to turn the CEA range MSA
> into proper AVI infoframes. Turns out there's a way to manually override the
> infoframes the LSPCON produces, and this is what Shashank's patches do,
> although originally aimed at adding YCbCr support. Please test.

No offense, but why are you guessing on your patches and asking customers to test instead of testing yourself?


(In reply to Lakshmi from comment #31)
> Reporter, can you apply below patch on drm-tip to ensure that issue is
> resolved?
> https://patchwork.freedesktop.org/series/36068/

Developer, unless it is merged into the mainline kernel it will be difficult to test. Not all users compile kernels themselves.

No offense, but judging from your email address, you seem to be working for Intel and working on graphics products. Don't you have a PC with LSPCon output and monitor with DVI-D input in your office/lab to test it yourself? Just saying.
Comment 33 Jani Nikula 2018-08-30 06:43:21 UTC
Decreasing priority back to high/major.
Comment 34 Jani Nikula 2018-10-15 13:14:40 UTC
Presumed fixed by

commit 7cbf19fd54ffef01a8a7af554b8447bef7c17ce7
Author: Shashank Sharma <shashank.sharma@intel.com>
Date:   Fri Oct 12 11:53:12 2018 +0530

    drm/i915: Write AVI infoframes for MCA LSPCON

commit 799a964ffe0b536e4c9f36991a6002c05c3140ae
Author: Shashank Sharma <shashank.sharma@intel.com>
Date:   Fri Oct 12 11:53:13 2018 +0530

    drm/i915: Write AVI infoframes for Parade LSPCON

in drm-intel-next-queued.

Thanks for your patience, please reopen if the problem persists with the above commits (and their dependencies).


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.