HDR Colors De-saturated with DisplayPort (Alienware AW3423DWF)

While researching this further, I found the amdgpu_current_colorspace debugfs:

HDMI:

# cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_bpc
Current: 8
# cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_colorspace
BT2020_YCC

DP:

# cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_bpc       
Current: 10
# cat /sys/kernel/debug/dri/1/crtc-0/amdgpu_current_colorspace
BT2020_RGB

So the color space seems to be correct here but the output looks like it handles it as rec709 (really desaturated colors). I got full colors with RGB format over DP on Windows, so the monitor isn't entirely incapable of handling this combination.

I can reproduce this with a rx 6800 XT and with a Ryzen 7840U on my Samsung C49RG9, with kernel 6.6.8. I thought the colors being desatured unless colors are stretched up to rec.2020 was just the screen having bad HDR support, but it doesn't happen with HDMI for me either.

I also tested it with a portable OLED display, same issue there. It happens if I connect the display over a USB C dock -> HDMI too, only direct HDMI with no DisplayPort in between works correctly.

This is because the sending of the colorimetry info in the VSC was gated around panel self-refresh being enabled.

I've sent a patch to upstream to fix this:

https://lists.freedesktop.org/archives/amd-gfx/2024-January/102725.html

Thank you for for fixing this!

I built a custom kernel with this patch on the fedora rawhide kernel (6.7.0-0.rc8.61.fc40.x86_64) and now the colors look correct. SDR content is now displayed as sRGB and HDR/WCG content can use the full capabilities of the display.

I currently don't have a desktop mail client installed to comment on the mailing list directly, so I'll post it here (not sure if it counts or matters )

Tested-by: Simon Berz <simon@berz.me>

I forwarded your comment, thanks for testing.

Is this in 6.7 or will it only be included in 6.8?

Self reply: it was merged just in time for 6.7

Now, to finally force someone to disable freesync_video

added 7000 dGPU series DC labels

closed

This is an issue again as it was reverted because it broke on some broken eDP displays.

As the new patches only reenable sending this packet for DP ≥1.4, what can users of older screens do to not have the washed colors? If I disable check for DP≥1.4 the new patches work beautifully and the colors are rich again.

Any way to fix this issue for older DP 1.2 monitors like my HP Pavilion Gaming 32 HDR?

Same issue here with 7900 XTX-kernel 6.8.1- Asus VG32VQR monitor.

yes, I can confirm this is an issue again.

@agd5f guys, could you stop breaking amdgpu for just one minute?

And please, reopen the issue

guys, could you stop breaking amdgpu for just one minute?

They're not breaking it on purpose, so your rudeness is uncalled for.

reopened

This bug should get the highest priority, as we are reliant on DP adapters because HDMI 2.1 does not work with amdgpu (#1417).

Should be fixed with these patches:

https://patchwork.freedesktop.org/patch/587044/

https://patchwork.freedesktop.org/patch/587055/

Tested on plasma 6, works fine, thx a lot!

Can this still make it into kernel 6.9?

Yes:

https://github.com/torvalds/linux/commit/9e61ef8d219877202d4ee51d0d2ad9072c99a262 https://github.com/torvalds/linux/commit/c3e2a5f2da904a18661335e8be2b961738574998

It'll likely be in the 6.8.7 kernel as well given the timing of it landing in Linus' tree and the stable kernel mailing list being CCed.

Both patches are currently in 6.8.7-rc1 so they should be in 6.8.7 assuming they don't cause a regression and need to be dropped.

closed

This is still not fixed for monitors with DP < 1.4 like my HP Pavilion Gaming 32 HDR. HDR worked fine on before the old patches got reverted, and also works fine with the new patches if I disable the check for DP ≥ 1.4. Any way those HDR monitors could be supported as well, as clearly some monitors can work just fine on linux?

@hwentland is DP 1.4 a requirement for HDR? I.e., do we need quirks for monitors that are pre-DP 1.4?

@agd5f apparently not since Jacek has fully functioning HDR if the check for DP version is removed from the code.

I looked into it. It appears that DP 1.4 and HDR support started appearing in monitors at roughly the same time, and most monitors that received HDR support also got DP 1.4. It doesn't appear that the list of HDR supporting monitors that shipped with DP 1.2 is very long, it could very well be a quirk.

Fwiw i was a bit surprised when my monitor with DP 1.2 also picked up HDR signal and set itself to HDR mode too.

Every source online says DP HDR support starts at 1.4 but if that was the case, why did monitor picked up that correctly and set itself to HDR mode?

Monitor is Asus VG32VQR; problem at hand is it does have HDMI 2.0 and DP 1.2, DP 1.2 supports 165 hz while HDMI 2.0 maxes out at 144. So if not a hassle, not removing DP 1.2 HDR support ( if technically possible) would be nice.

I meant from the perspective of the DP spec. I.e., to technically be compliant, the monitor should report DP 1.4 if it supports HDR. Of course in the wild, there could be monitors that support it but report the wrong DP version. If that is the case, it would probably make sense to add quirks for non-compliant monitors.

I agree quirks are probably best here. We've seen pre-DP1.4 displays that advertise support for HDR but then go all silly when we send the infopacket. See #3151 (closed).

To add quirks we'd need your edid. You can extract it with cat /sys/class/drm/card1-DP-1/edid (replace the card1 and DP-1 as needed).

Is it cat /sys/class/card1-DP-1/edid or cat /sys/class/drm/card1-DP-1/edid because only latter returns something for me.

cat /sys/class/drm/card1-DP-1/edid :

vg32vqr-edid.txt

cat /sys/class/drm/card1-DP-1/edid|parse-edid:

parse-edid.txt

cat /sys/class/drm/card1-DP-1/edid|di-edid-decode :

di-edid-decode.txt

All with 6.8.5-arch1-1 x86_64 kernel.

Thank you! Here is my EDID: HPPavilionGaming32HdrEdid.txt

And here it is decoded with di-edid-decode: HPPavilionGaming32HdrEdidDecoded.txt

@Leopard1907 The latter one is correct

/sys/class/drm of course. Thanks for the correction and edids. I updated my comment.

I have another monitor that has HDR support and uses DP 1.2. HDR workes on linux 6.8.2, and stops working after updating further. Here's my edid stuff. The full monitor model name is Samsung LC27G55TQBUXEN.

Also attaching output of the auxrw command written in the comments two posts down to ensure that the monitor signals DPCD 1.2

parse-edid.txt di-edid-decode.txt edid.bin auxrw.txt

Tested using an LG Oled CX48 with a DP to HDMI 2.1 adapter (VMM-7100 chip) & kernel 6.9RC4.

It is random on every boot if i get the washed out colors. Same as without the fix. It did however fix my native DP monitor (Viewsonic Elite XG270).

edid.bin parse-edid.txt di-edid-decode.txt

I got the same result with the 6.8.7 kernel. Using the same VMM-7100 adapter with an LG OLED C2.

Are we sure this is related to the same issue? Where does the randomness come from? If you switch between tty to GUI it sometimes comes up with HDR, other times washed out.

Btw since this whole DP 1.4/1.2 situation was a bit muddy for me, i looked further a bit and found this.

"Color depth of 10 bpc (30 bit/px or 1.07 billion colors) is assumed for all formats in these tables. This color depth is a requirement for various common HDR standards, such as HDR10. It requires 25% more bandwidth than standard 8 bpc video.

HDR extensions were defined in version 1.4 of the DisplayPort standard. Some displays support these HDR extensions, but may only implement HBR2 transmission mode if the extra bandwidth of HBR3 is unnecessary (for example, on 4K 60 Hz HDR displays). Since there is no definition of what constitutes a "DisplayPort 1.4" device, some manufacturers may choose to label these as "DP 1.2" devices despite their support for DP 1.4 HDR extensions.[52] As a result, DisplayPort "version numbers" should not be used as an indicator of HDR support."

Now my question is ( ofc not expecting an answer if there is no good answer to this ) , what are those HDR extensions, do they show up in edid data, also is it possible for end user to parse DP port version of the monitor because in those parsed edid datas we all posted above i've seem to miss where it was noted or is it actually not noted in such data?

di-edid-decode shows the colorimetry data block of the display and additional transfer functions. For example, here's a part from my monitor's edid decode.

  Colorimetry Data Block:
    BT2020YCC
    BT2020RGB
  HDR Static Metadata Data Block:
    Electro optical transfer functions:
      Traditional gamma - SDR luminance range
      SMPTE ST2084
    Supported static metadata descriptors:
      Static metadata type 1

I know that part, i also posted my edid above couple days ago which contains this.

Colorimetry Data Block:
    BT2020YCC
    BT2020RGB
    ST2113RGB
  HDR Static Metadata Data Block:
    Electro optical transfer functions:
      Traditional gamma - SDR luminance range
      Traditional gamma - HDR luminance range
      SMPTE ST2084
    Supported static metadata descriptors:
      Static metadata type 1
    Desired content max luminance: 97 (408.759 cd/m^2)
    Desired content max frame-average luminance: 86 (322.098 cd/m^2)
    Desired content min luminance: 28 (0.049 cd/m^2)

What i don't get is how one determines DP version from that edid data, as i can"t.

Only part where DP itself was even mentioned is this.

Basic Display Parameters & Features:
    Digital display
    Bits per primary color channel: 10
    DisplayPort interface
    Maximum image size: 70 cm x 39 cm
    Gamma: 2.20
    DPMS levels: Off
    Supported color formats: RGB 4:4:4, YCrCb 4:4:4, YCrCb 4:2:2

So what i'm asking is does those edid data contain DP version info at all, if it doesn't then where one can get that info, other than manufacturers often undetailed specs page which mine says 1.2 there.

The DP version is determined by talking to the monitor over the aux bus. It doesn't come from the EDID.

Thanks for the answer, is there a command that reveals that data in human readable form from the aux bus?

Not that I know of off hand. Might be a debugfs interface to query that. @hwentland?

No debugfs that I know of but you can use auxrw.

sudo ./``auxrw.py r /dev/drm_dp_aux0 0x0

This is the output I get on my (HDR) display:

[hwentlan@hwentlanryzen auxrw]$ sudo ./auxrw.py r /dev/drm_dp_aux0 0x0 16
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00000: 12 14 c4 01 01 00 01 c0 02 00 06 00 00 00 80 00 ..Ä....À........

Byte 0 is 12, meaning DPCD version 1.2. It should be 14 for version 1.4.

So obviously I need to have a closer look at the DP spec and check if my previous fix is correct since my DP 1.2 monitor can do HDR. The question is whether we should be sending the infopacket as well in that case.

One of my monitors (Viewsonic XG270) is only DP1.2 and works without the washed out colors. It is also weird that HDR is not mentioned at all in its documentation but is present in the OSD. Also the output for it:

        0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  0123456789abcdef
00000: 12 14 c4 01 01 00 01 c0 02 00 06 00 00 00 80 00  ..Ä....À........

The port for my LG Oled which uses a DP to HDMI 2.1 adapter reports DP 1.2 (Manufacturer advertises 1.4) as well even though 4K@120 4:4:4 should not even be possible with 1.2:

        0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f  0123456789abcdef
00000: 12 14 c4 81 01 1d 01 c1 2a 3f 04 00 00 00 84 00  ..Ä....Á*?......

mentioned in issue #3151 (closed)

mentioned in issue #3334 (closed)

added HDR label

HDR Colors De-saturated with DisplayPort (Alienware AW3423DWF)

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

Attached files:

Log files

Designs

Child items ...

Activity

Admin message

Admin message

HDR Colors De-saturated with DisplayPort (Alienware AW3423DWF)

Brief summary of the problem:

Hardware description:

System information:

How to reproduce the issue:

Attached files:

Log files

Activity