HDR support in Wayland/Weston

[Graeme Gill]

Sharma, Shashank wrote:

Hi,

> Yes, this is very accurate. We are planning to add a protocol extension, which will allow
> a client to pass the buffers colorspace information to the compositor. And compositor
> already has HW's color capabilities (drm properties per plane and CRTC), and monitor color
> capabilities (EDID). So if compositor gets all of this, with some good policies, it might
> be able to take call on colorspace accurately.

my impression from past feedback is that EDID display characterization as a rule
is not to be relied on, at least not if any degree of accuracy is desired. Maybe
the manufacturers have got better.

But I can sympathize with the desire of not getting bogged down in
color management stuff if you are just trying to get something
vaguely reasonable displayed on HDR.

> Correct, in fact, we would be using these same CRTC channels to apply the EOTFs. If we go
> through the REC2020/2023 spec carefully, we realize that EOTF/OETF curves are nothing but
> gamma/degamma correction curves for HDR monitors while they are displaying a much wider
> gamut, like BT2020 or DCI-P3. I had written one drm-compositor based implementation of
> sample color management using these CRTC/Plane color properties being exposed by DRM, for
> accurate blending, but now I want to go through and understand Niels's color management
> solution first.

Sure. If you just take the HDR monitors as being nominally HDR10 or similar, then you can
do a by-the-spec conversion and get something working.

Cheers,
	Graeme Gill.