Expose EDID to allow sdr-native to work for correct DCI P3 Color (stops oversaturated displays)

[taprobane99]

On Gnome 50 inserting sdr-native on the line underneath in monitors.xml in .config folder allows the desktop to be displayed correctly in the P3 color space. This works on Intel Macbooks.

On Asahi Linux it does nothing. Presumably the EDID is not exposed correctly?

[chadmed]

DCP automatically does colourspace conversion. The embedded displays have no EDIDs, so we force DCP to map the incoming framebuffers as sRGB on these displays, which should automatically DTRT. Are you noticing oversaturated colours on one of the laptops? We have tested this approach with a colourimeter and did not notice anything wrong with it.

[taprobane99]

Do you mean that you already do something equivalent to this on Gnome:

https://gitlab.gnome.org/GNOME/gnome-control-center/-/work_items/3742

So adding sdr-native into monitors.xml is unnecessary?

I think I notice oversaturation, but not completely sure.

[chadmed]

Correct, you should not need to force any colourspace conversion or ICC profile use in userspace for sRGB framebuffers as DCP will do this for you in hardware automatically.

[taprobane99]

ok. i will close this then.

[taprobane99]

hi. according to a mutter dev "Since mutter produces sRGB output by default, the best [DCP colourspace conversion] could achieve is correct sRGB output, not correct display of colours outside of sRGB."

can you comment?

[chadmed]

That is mostly correct. The DCP API allows us to tell it what colourspace the framebuffer to be displayed is in, which it will then map to the connected display's colourspace. Since the laptop screens do not have EDIDs, compositors (including mutter) will default to sRGB framebuffers. We tell DCP this, which makes it display the sRGB colourspace correctly on the DisplayP3 laptop screens.

[chadmed]

I've closed this for now but we do plan on "faking" the EDIDs for the builtin panels eventually, as this will be required for some other features,