From weston.ini to HDR metadata
Apparently an important part in programming a HDR video mode is to get the HDR Static Metadata Type 1 in SMPTE ST 2084 mode in. For my HDR monitor, it does not need to be right, but it needs to be there and not wildly wrong for the monitor show a plausible HDR picture.
Where do we get that? HDR ST 2084 video should come with it. However, a compositor is a video producer itself, not a simple pass-through relay, and it can adapt to the HDR sink at hand. So, ideally we'd use parameters that allow us to make the most of the monitor, and adapt the image to the monitor. Those parameters come from EDID. Ha ha. EDID. Yeah.
Since libdisplay-info is still very much brewing, and overriding or editing EDID is a pain anyway, let's start with weston.ini.
This MR adds weston.ini syntax to encode practically everything one needs to know about a monitor, that would be available in EDID. Those parameters go to the color manager, which is supposed to take them into account when creating color transformations (not implemented yet) and produce HDR Static Metadata Type 1 (defined in CTA-861-G) parameters (tentatively implemented) to be sent to the sink (monitor). DRM-backend takes that information and puts it up in a KMS blob property from where the DRM driver pushes it out to the cable. Once it's on the cable, it's out of our hands and all bets are off.
The main goal of this MR is that I can stop hardcoding my monitor parameters in a DRM-backend patch, and instead hardcode them in my weston.ini. That also makes it easier for anyone else to try HDR video mode on their monitor, which is likely different from mine.
This also sets up the API for color manager to access the those basic monitor characteristics, meaning that working on SDR→HDR color conversions should be more... approachable.