[RFC wayland-protocols] Color management protocol

[Kai-Uwe]

Am 20.12.2016 um 03:38 schrieb Graeme Gill:
> Niels Ole Salscheider wrote:
>> What MIGHT be possible is that an application provides the complete surface in 
>> all color spaces of all outputs so that the compositor can use the parts it 
>> needs.
> 
> Yes, that's an interesting thought.

It appears to be expensive to me. [But there might be tricks like area
events to signal repaint demand.]

> Another thought that avoids
> the application having to know the exact surface to output mapping
> would be for the application to provide a device link for
> each output (I'm currently thinking through the implications
> of such an approach.)

Device Link ICC profile solve the desire to completely describe a
conversion inside the display encoding (3*precision_of_choice).

A device link could be used to
* provide a relatively simple means for injecting values to the GPU
shaders. ( That needs to carefully define a compatibility subset. Device
links can have lots of features like all other ICC profile classes,
which are hard to reimplement. Close to what we see in compositors are
3D LUT support. Extending that by curves makes a lot of sense to support
the desired gamma 1.0 blending spaces: e.g. matrix/shaper curves[ICC
v2], parametric curves[ICC v4] + 3D LUTs[mtf2 ICC v2] || [mAB ICC v4]. )
* compositors can read plain values from the device link profile without
any conversion by a ICC CMM
* applications gain a lot of flexibility, like support for effects etc.
* a agent could take over the device link creation for all applications,
which do not know about howto

on the downside:
* clients need to see output changes to supply a matching ICC device
link for the new/changed device
* device links work not for n > number of display channels (cmyk is
impossible that way). The n-channels (n >= 4) clients need still
information about outputs + window regions.

> Both ideas have similar issues -
> you really want the per output pixels or device links to
> be provided by the application on demand - i.e. when a surface
> first overlaps an output, so that it doesn't have to pre-compute
> pixels or device links for all possible outputs, even if they
> never get used. This has interactivity implications. I think

Pressing the monitor simulates a new space or adding a new hot monitor
triggers a similar update demand.

Maybe the device link is kind of a extension for later implementation.

Kai-Uwe