Bug 100023

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.

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.

Any update?

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

(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.

Hello everyone, any update so far? Thanks.

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.

(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.

(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.

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.

Any update on this one?

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.

Closing, please re-open is issue still exists.

Re-opening.

Jani, Ville, any help here?

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.

(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?

(In reply to N. W. from comment #17)
> What part of dmesg do you need?

Start to finish.

(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?

Hello,

This issue is affecting me as well. My setup is:
 - ThinkPad T430

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.

When will this finally be fixed?

(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?

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

(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?

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.

Please try https://bugs.freedesktop.org/show_bug.cgi?id=107476#c17

(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.

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

Decreasing priority to high/major.

Reporter, can you apply below patch on drm-tip to ensure that issue is resolved?
https://patchwork.freedesktop.org/series/36068/

(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.

Decreasing priority back to high/major.

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).

Re-opening, since the issue still is not solved, still not working with kernel 5.1.

By the way, the  MegaChips MCDP2800 LSPCON has been updated to latest firmware version 1.66, but that does not help with the issue described here.

Please attach dmesg from boot to reproducing the problem with drm.debug=14 set on v5.1.

(In reply to N. W. from comment #36)
> By the way, the  MegaChips MCDP2800 LSPCON has been updated to latest
> firmware version 1.66, but that does not help with the issue described here.

MCA LSPCON FW version 1.66 is pretty old, you need at-least 1.72 (ideally 1.75) to be claiming 'new'

(In reply to shashank.sharma@intel.com from comment #38)
> (In reply to N. W. from comment #36)
> > By the way, the  MegaChips MCDP2800 LSPCON has been updated to latest
> > firmware version 1.66, but that does not help with the issue described here.
> 
> MCA LSPCON FW version 1.66 is pretty old, you need at-least 1.72 (ideally
> 1.75) to be claiming 'new'

Do you have any changelog or recollection on what firmware version is required to support the AVI infoframe code you added for MCA LSPCON?

(In reply to Jani Nikula from comment #39)
> (In reply to shashank.sharma@intel.com from comment #38)
> > (In reply to N. W. from comment #36)
> > > By the way, the  MegaChips MCDP2800 LSPCON has been updated to latest
> > > firmware version 1.66, but that does not help with the issue described here.
> > 
> > MCA LSPCON FW version 1.66 is pretty old, you need at-least 1.72 (ideally
> > 1.75) to be claiming 'new'
> 
> Do you have any changelog or recollection on what firmware version is
> required to support the AVI infoframe code you added for MCA LSPCON?

On paper it should have been supported from the beginning, but we tested only from 1.70 >= version.

(In reply to shashank.sharma@intel.com from comment #38)
> (In reply to N. W. from comment #36)
> > By the way, the  MegaChips MCDP2800 LSPCON has been updated to latest
> > firmware version 1.66, but that does not help with the issue described here.
> 
> MCA LSPCON FW version 1.66 is pretty old, you need at-least 1.72 (ideally
> 1.75) to be claiming 'new'

Where do you get v1.75 from?

v1.66 is the latest version that ASRock provides on it's website for this mainboard: https://www.asrock.com/mb/Intel/Fatal1ty%20Z170%20Gaming-ITXac/#Download

Also, according to https://nucblog.net/2017/03/intel-releases-the-final-hdmi-firmware-for-apollo-and-kaby-lake/ , v1.66 is the last release.

That being said, when following the link to the Intel Download Center in that blog, it actually links to v1.72 now: https://downloadcenter.intel.com/download/26609/NUCs-HDMI-2-0-Firmware-Update-Tool-for-Intel-NUC-Kit-NUC6CAY-and-NUC7i3BN?product=95069

When searching for "HDMI Firmware Update" on Intel Download Center, that v1.72 version also is the latest version that appears in the search results.

So, where does one get v1.75 from?

Anyone?

Hello NW, 
Intel download center for NUC devices has FW V 1.72 available, along with the flashing utility. 
https://downloadcenter.intel.com/download/26609/NUCs-HDMI-2-0-Firmware-Update-Tool-for-Intel-NUC-Kit-NUC6CAY-and-NUC7i3BN?product=95069

Swati, any news from 1.75?

Intel download center for NUC devices has FW V 1.77 available, along with the flashing utility.
-FW for Coffee Lake based NUC: https://downloadcenter.intel.com/download/29092/HDMI-Firmware-Update-Tool-for-NUC8i3BE-NUC8i5BE-NUC8i7BE
-FW for our Kaby Lake NUC: https://downloadcenter.intel.com/download/29162/HDMI-Firmware-Update-Tool-for-NUC7i3BN-NUC7i5BN-NUC7i7BN?product=95067

@N.W. ping.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/32.