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.
- 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)
-
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.
-
Compositor should convert prepared buffer and/or set some drm properties to match output capabilities
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 #4377
#9506
#9600
TODO
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.
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->parsedEDIDfor monitor capabilities andsurface->colorManagement->imageDescription()for a client (assume sRGB if missing)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.
Compositor should convert prepared buffer and/or set some drm properties to match output capabilities
output->state->setDeGammaLutoutput->state->setCTMoutput->state->setGammaLutoutput->state->setHDRMetadataCaveat: 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 #4377
#9506
#9600
TODO