Skip to content

KMS Colorspace=bt2020 on HDMI causes misinterpreted colors

Problem

With wayland/weston!1505 (merged), when I set KMS Colorspace property of a HDMI connector to BT2020_RGB or BT2020_YCC, the display colors go mostly wrong. Black becomes green, light grey becomes pink, etc. My wild guess is that the gfx card sends limited range RGB, and the monitor expects full range YCbCr. This is 100% deterministic and stable, no glitches.

This is the color-broken image with `Colorspace=BT2020`: bt2020_screen

BT2020 KMS state according to drm_info: test.txt

This is similar framebuffer content with `Colorspace=Default` default_screen

Default KMS state: default.txt

The difference between the KMS states is only

-│   │       ├───"Colorspace": enum {Default, BT709_YCC, opRGB, BT2020_RGB, BT2020_YCC} = Default
+│   │       ├───"Colorspace": enum {Default, BT709_YCC, opRGB, BT2020_RGB, BT2020_YCC} = BT2020_RGB

I would expect the actual image with Colorspace=BT2020 to be much like the Default one except more saturated. I would not expect black to become green.

I would like to know if the monitor and/or amdgpu are buggy, and if someone can explain what I see.

I tried the same display on Intel driver using DisplayPort, and there setting Colorspace property has no visible effect at all. I'm not sure, but it is possible the monitor requires ST2084 EOTF to turn into wide color gamut mode which also turns on HDR if HDR static metadata has max luminance > 100 cd/m², and partially ignores the colorspace infoframe setting.

Hardware description:

  • CPU: Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz
  • GPU: Advanced Micro Devices, Inc. [AMD/ATI] Baffin [Radeon RX 550 640SP / RX 560/560X] [1002:67ff] (rev ff)
  • System Memory: 24 GB
  • Display(s): HP Pavilion 27 Quantum Dot (decoded EDID)
  • Type of Display Connection: HDMI

System information:

  • Distro name and Version: Debian Bookworm
  • Kernel version: Linux eldfell 6.6.13+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.13-1~bpo12+1 (2024-02-15) x86_64 GNU/Linux
  • GL version: OpenGL ES 3.2 Mesa 23.1.3 (git-b2d41b3fcc)
  • GL renderer: AMD Radeon RX 550 Series (polaris11, LLVM 15.0.6, DRM 3.54, 6.6.13+bpo-amd64)

How to reproduce the issue:

Build and install Weston from git main with -Dcolor-management-lcms=true. Make sure it runs ok first from a text login on a VT. Then configure in weston.ini:

[core]
color-management=true

[output]
name=HDMI-A-4
colorimetry-mode=bt2020rgb

Replace HDMI-A-4 with whatever Weston says your monitor is connected to. Then Weston should program Colorspace=BT2020_RGB, causing the issue if your monitor at hand happens to be prone to it.