Color management support

Description

An app has some content in format A and says to compositor that it is in format B. The compositor stores it in format C and tells video drivers that it is in D. Monitor display it as E which leaves the user with what the F is going on? To reduce this frustration and get some better visuals a color management system is needed for proper content processing on the way to a display device.

1. Compositor needs to decide which format better suits current clients and outputs:

• Simple: single monitor - use the max supported format

• Advanced: take into account all the clients and use a lesser format if it is enough to reduce resource consumption

• Tricky: multi-monitor setup - needs some common format Caveat: monitors lie about their capabilities, clients lie about their content

  Some relevant info is in output->parsedEDID for monitor capabilities and surface->colorManagement->imageDescription() for a client (assume sRGB if missing)

1. Compositor should convert all clients' buffers to the selected format and prepare a buffer for displaying Needs some shaders. Direct buffer manipulation might be easier but highly ineffective. This step should be avoided if possible.

2. Compositor should convert prepared buffer and/or set some drm properties to match output capabilities

• https://drmdb.emersion.fr/properties/3435973836/DEGAMMA_LUT output->state->setDeGammaLut
• https://drmdb.emersion.fr/properties/3435973836/CTM output->state->setCTM
• https://drmdb.emersion.fr/properties/3435973836/GAMMA_LUT output->state->setGammaLut
• https://drmdb.emersion.fr/properties/3233857728/HDR_OUTPUT_METADATA output->state->setHDRMetadata Caveat: not all properties might be supported by the given video driver, some of this properties might accept different values on different drivers, properties listed in a "natural" color pipeline order but it is not guaranteed to be so

HDR10 for a fullscreen app is the easiest thing to do because it can got straight to step 3 with little to none modifications. Might still need some drm properties adjusting. Current implementation uses only HDR_OUTPUT_METADATA. On paper color management should be relatively simple and straightforward. In reality some bits should be ignored in favor of some sane defaults. Some double back and forth conversions might be needed just to slap a transformation in between. What those bits and defaults are might depend on hw setup.

Lots of docs about color and HDR https://gitlab.freedesktop.org/pq/color-and-hdr

Somewhat a duplicate of https://github.com/hyprwm/Hyprland/issues/4377

https://github.com/hyprwm/Hyprland/pull/9506 https://github.com/hyprwm/Hyprland/pull/9600 TODO

• Convert primaries
• Handle luminances
• Mark relevant proto features as supported
• Add a way to change output image description
• Add a setting for fullscreen passthrough
• Fix desktop effects with HDR
• CM for decorations
  • Border issues https://github.com/hyprwm/Hyprland/issues/9888 https://github.com/hyprwm/Hyprland/discussions/10422
• Wiki page
• CM for blur
  • tiled
  • floating
  • #9852
• CM for cursor
  • software
  • hardware #15905
  • hardware with cpu buffer copy
• Better monitor image description settings #9716 #10623
• Better fullscreen logic #9785
  • SDR passthrough #11503
  • HDR passthrough
• Direct scanout
  • SDR
    • primaries #11503
    • luminances
  • HDR
    • PQ10
    • scRGB (not possible?)
  • Handle SDR/HDR switch with DS or block DS when content and monitor settings do not match #12127
• Better internal format (FP16?) #10558 #11000
• Handle icc profiles #12711
• Optimize CM shader #9814
  • don't use math for global constants
  • use pre-calculated matrices for primaries conversion and luminances
  • #9795 #10888
• Utilize drm properties
  • GAMMA_LUT
  • CTM #11503
  • DRM Color Pipiline
• Handle YCC
• Decode to linear #11084
  • SRGB
  • GAMMA22
  • GAMMA28
  • ST2084_PQ
  • HLG
  • BT1886
  • ST240
  • LOG_100
  • LOG_316
  • XVYCC
  • ST428
• Encode from linear (check drm properties and monitor capabilities, everything supported by the hw might be covered already) #11084
  • SRGB
  • GAMMA22
  • GAMMA28
  • ST2084_PQ
  • HLG
  • BT1886
  • ST240
  • LOG_100
  • LOG_316
  • XVYCC
  • ST428
• Proper proto error handling #11916
• Better inverse tonemapping https://github.com/hyprwm/Hyprland/discussions/11341 #12204
  • Handle mastering primaries
• Correctly handle color values outside 0.0 - 1.0 range