Introduce EOTF mode and program that through KMS HDR_OUTPUT_METADATA property
This MR is the first step towards programming a HDR video mode through DRM KMS. More steps will be needed to complete the HDR video mode programming, and even further steps to correctly produce HDR pixels.
Still, I'm fairly confident that this part is in its final form, so I'm proposing to land it upstream to reduce the set of patches I carry. This might also help others hack on HDR stuff.
The concept of "EOTF mode" is introduced. The values in the EOTF mode enumeration come straight from CTA-861-G standard, designating the HDR system:
- traditional gamma SDR (i.e. not HDR)
- traditional gamma HDR
- SMPTE ST 2084 (Perceptual Quantizer, PQ)
- Hybrid Log-Gamma (HLG)
Libweston gains API for EOTF mode, both to return what a head supports, and how to set it on an output. Weston gains a weston.ini key for setting it. Headless backend does not do anything with it, but claims to support them all for future testing purposes. DRM-backend checks for KMS support, but does not parse EDID to see what the monitor supports yet. Other backends do not support HDR modes for now.
The color-lcms module is required for using a HDR mode, even though color-lcms does not yet handle the EOTF mode in order to produce proper pixels.
DRM-backend will attempt to program the chosen EOTF mode via HDMI/DisplayPort infoframes as implemented by DRM drivers, but so far only the EOTF itself is set in HDR_OUTPUT_METADATA KMS property. Everything else is left undefined. This may or may not be enough to make a monitor switch into a HDR mode. When HDR is enabled, DRM-backend will default to 10 bpc pixel format instead of 8 bpc.
DRM-backend will also program max bpc KMS property whenever it exists, for all modes, SDR and HDR. SDR aims for 8 bpc, HDR aims for 16 bpc, both depend on what KMS actually supports. Previously Weston did not program max bpc at all.
Likewise, HDR_OUTPUT_METADATA KMS property will always be programmed now when it exists. When HDR is not used, the property is forced to unset (blob id 0).
For now, if you manage to set a HDR mode and your monitor agrees it's a HDR mode, you will see an image (bright, dark, weird, ...) that is not proper HDR. This is because this MR does nothing to the actual pixels sent to the monitor, they are still the plain old sRGB SDR values which the monitor (falsely) assumes are PQ or HLG HDR encoded. Furthermore, since programming HDR_OUTPUT_METADATA KMS property is very rare (pick any display server and it probably won't touch it), exiting Weston will leave the monitor in this broken HDR mode. So you can see wild things like fbcon in HDR. However, that's how DRM KMS is meant to work: it is always up to the next KMS client (fbcon included) to ensure all KMS properties are sane when it takes over.