[RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

I feel like the discussion drifts off a bit. You (Graeme) obviously know much 
more about color management than I do. But as Pekka already pointed out there 
are a few constraints that originate in the design decisions of wayland and 
are quite different to these of X11. We can't change these constraints but 
have to find a solution that works well with them:

- A normal application CANNOT control the hardware directly (it can't program 
LUTs, for example).

- A normal application CANNOT alter global settings of the compositor (like 
setting color profiles for the outputs). This can only be done by the 
compositor or a few trusted applications. The user will just have to use the 
settings dialog provided with the compositor. Because of that it does not 
matter if this is implementation dependent.

- You DO NOT know which parts of a surface are shown on which screen.

- We aim to be pixel-perfect.

I think these constraints mean that we must let the compositor take part in 
the color correction, at least if more than one screen is involved. If we do 
so, we should also be able to expect that the compositor can handle a bit more 
complicated cases (e. g. an arbitrary number of different surfaces with 
different color profiles).

When I proposed this protocol my focus was on applications that may not be 
color managed currently. I thought for example about web browsers or simple 
image viewers where I would view (but not edit) photos.
Your focus is obviously on professional applications. I think both use cases 
are equally important and we should not treat one as an afterthought of the 
other.

I would be glad if we could come up with a solution that works for both under 
these constraints.