This is on top of !30 (merged). Only the last commit is interesting.
This comes from thinking that end users might want to keep things like NightLight automatically enabled on timer while still doing color sensitive work during the day, and that they would want to be warned if color reproduction on screen becomes compromised due to e.g. NightLight or some other effects.
Another reason why color presentation would be compromised is that maybe the monitor was never profiled. Maybe the profile was automatically created from EDID data, or maybe it's just a stock profile. Until an end user installs a profile and tells the compositor that it is a verified profile, color presentation would always be compromised.
Or, maybe the monitor profile was verified and no longer is due to e.g. changes in how KMS is being driven by the compositor. Or due to anything else listed in wayland/weston#467 section "Color calibration auditing system".
This RFC adds an event so that a color sensitive application can warn the user. Only applications that care would show the warning in their own way.
I can also see another kind of design where no event is needed and the compositor itself will show the warning. The compositor is trusted to detect compromised color presentation in both designs. In the second design, a compositor would show the warning if a client is using either of the two colorimetric rendering intents.