Skip to content

Make it possible to drive outputs in HDR mode

Xaver Hugl requested to merge work/zamundaaa/color into master

This MR implements the ability to change the color space a display expects to BT.2020, to send the HDR metadata required to allow the use of the PQ encoding, and to do the required conversion steps from sRGB content from client buffers to the required color space and encoding for the display, while ensuring we also do blending correctly.

For non-HDR displays, nothing changes. For HDR displays that support BT.2020 and PQ though, the following color pipeline is used:

sRGB content from clients 
    -> linear brightness with BT.709 primaries 
    -> XYZ
    -> linear brightness with BT.2020 primaries 
    -> blending into a shadow buffer 
    -> PQ encoding with BT.2020 primaries -> display

Note that amdgpu currently doesn't support the Colorspace drm property, so for full testing you need to either use an Intel GPU or a patched kernel like https://gitlab.freedesktop.org/swick/linux/-/tree/test/amd-colorimetry. Even without that though, displays should turn into HDR mode - just using BT.709 primaries instead of BT.2020

This is still WIP because:

  • we need libdisplay-info in CI
  • night color is sort of broken in HDR mode. Doing the color temperature adjustment in PQ is wrong
  • this is still applying the VCGT (also in PQ), which should be removed until that can be handled better
  • we need settings for:
    • whether to enable HDR in the first place
    • the brightness for SDR content. The hardcoded 400 nits is needed for my monitor to not be super dark, but it's probably a bit too bright with other displays
    • which transfer function and/or color space to use? Colors look pretty bad on my monitor with BT.2020, but they're great with BT.709. Needs more experimenting

Handling non-sRGB inputs for this pipeline is a lot more involved and will be implemented in a future MR.

depends on libraries/plasma-wayland-protocols!56 (merged)

Edited by Vlad Zahorodnii

Merge request reports