[RFC wayland-protocols] Add the color-management protocol

[Daniel Stone]

Hi,

On 20 December 2016 at 14:25, Daniel Stone <daniel at fooishbar.org> wrote:
> Hm. When does this apply: is it at the next wl_surface::commit, or
> immediately? FWIW, the correct answer for this is the former. ;)
> Putting explicit language in to this effect would be good; it may also
> be nice to have this new_id a separate per-surface object, so the
> application can then destroy the object to opt out, e.g. if it starts
> embedding content of an unknown colourspace, so the best option is to
> have the compositor convert from sRGB.
>
> Another good reason to have a per-surface object is so you have
> explicit control: only one per-surface object can be active at any
> time, and that surface is free to call set_colorspace as many times as
> it wants. Without per-surface objects, you can't enforce the same
> 'only one at a time' model.

A thought which just coalesced in my mind as I was making coffee, is
that this would also allow the compositor to suggest the best
colourspace for the surface's content to be rendered in. Though the
output device's characteristics are (semi-)constant, the rendering
pipeline is not. For instance, if you're switching between blending
and not, but even things like content from other clients can affect
it. Some KMS devices can perform per-plane colour management
(typically a variable-depth degamma LUT, 3x3 CTS matrix and re-gamma
LUT), such that a non-fullscreen client can have correct colour
conversion, independent of any compositor rendering. However, another
client could then come along and force your client off the plane, such
that you land in the compositor's GPU pipeline before display: this
rendering may be done in a 'lowest common denominator' colourspace,
such that the most optimal / least lossy output from your colour-aware
client would then _not_ correspond to your display device's native
characteristics.

Cheers,
Daniel