Skip to content

Colord architecture, or who controls monitor profiles in a Wayland system

This is continuing from wayland/wayland-protocols!14 (comment 1218426), but I think colord and other similar software deserves a big topic of their own. CC @pjanx.

Colord

Where does colord fit in?

I have only glimpsed at the colord doc above to get a faint idea so far.

Where should a Wayland compositor get its monitor profiles from in a system using colord?

I have been assuming that people use whatever tools they want to make colord deliver the monitor profiles they want. That's all good and fine for SDR and without any patching I suppose. A Wayland compositor can ask colord for the profiles (Weston has had a plugin for this for many years for the purpose of loading VCGT). Then:

  • Wayland clients get the monitor profiles via Wayland CM&HDR extension.
  • X11 clients do what they have always done, I suppose that is between colord and Xwayland, perhaps, or a thing called "a session client" might be responsible for setting up the X11 properties.

When you have a HDR monitor, things are different. The primary source of HDR monitor characterization is EDID/DisplayID, because

  • most people don't have monitor profiling instruments that could profile HDR monitors
  • consumer HDR monitors have too dynamic response to be profiled anyway
  • there are no ICC profiles available for these monitors (are there?)
  • and finally, even ICCv4 as it is today is probably incapable of sufficiently characterizing HDR monitors

A Wayland compositor will be reading EDID anyway, so naturally it would also parse the colorimetry and HDR information and use what is supposed to be reliable, and/or drive the monitor with a defined standard colorimetry (e.g. BT.2020/PQ). Therefore the compositor has the best knowledge of the characterization of a HDR monitor. The monitor behavior depends on how it is driven, which is a compositor (ultimately end user) decision.

If we want to have colord in the loop for HDR monitors, then colord needs to develop support for HDR in general, find a way to express HDR monitor characterization, and have an interface for the Wayland compositor to tell colord in what mode the monitor is being driven. Then, the compositor could get the HDR monitor characterization from colord and forward that to Wayland apps.

Is having colord in the loop like this reasonable, or should the architecture be different? (Colord cannot be a mandatory Wayland CM&HDR requirement in general, so the Wayland extension must be the way to deliver characterizations to apps.)

Or, should a Wayland compositor configure colord to deliver monitor profiles to legacy apps? But that might be awkward because end users may expect to be able to configure colord like they always have, and then a Wayland compositor might sometimes overwrite their settings. Therefore this option doesn't feel good to me.

Or, should a Wayland compositor be the only one "allowed" to configure monitor profiles in colord, even for SDR WCG? Wouldn't that be a disruptive change for end users?

A whole another question is, when you have a HDR monitor in one of the HDR modes, what do you tell to X11 clients? One could limit X11 clients to SDR + WCG, but then who will manufacture and set up the ICC profile corresponding to that display behavior? Is it the Wayland compositor or colord? If it is colord, how do you separate the HDR profile for Wayland apps from the SDR profile for X11 apps?

In this issue we should figure out how colord should integrate with Wayland CM&HDR.

Closing criterion: a proposal has been merged in the docs here.