A solution for gamma-adjustment support in Wayland

[Daniel Stone]

Hi Mattias,

On 21 December 2016 at 11:31, Mattias Andrée <maandree at kth.se> wrote:
> On Wed, 21 Dec 2016 10:40:44 +0000 Daniel Stone <daniel at fooishbar.org> wrote:
>> The point is that I'm extremely wary of copying X11 by
>> way of encoding this into an API; it's a truly dizzying
>> space to even enumerate, let alone abstract.
>
> I think at the very least want I have suggested should
> be implemented. However, adding the functionality to
> transform the values via matrix multiplication as well
> is probably a good idea. If matrices and ramps are
> combined into the same chain, what more could possibly
> be added. Abstraction is easier than enumeration in this
> case, if the transformation can be handles by the
> graphics card, let it do it, otherwise, do it before.
>
> If there is no API for these thinks, functionality
> such as inverting the colours, lowering the temperature,
> and (requires matrices) simulating defective colour
> vision must be done in the compositor. This is not
> a sustainable solution, an API is necessary. It's bad
> enough that colour management is done by the compositor.

I fundamentally disagree on the difficulty of designing API,
especially when the API is already inadequate from the start.
Enumeration in particular is required to get the best results: a
client may sometimes wish to render in a wider but linear format in
order to avoid the loss of precision on LUT indexing when using
split-gamma modes.

I also cannot disagree more with your assertion that 'it's bad enough
that colour management is done by the compositor'. The compositor is
the very thing between clients producing pixels, and the final output.
If a compositor is unaware of how those pixels should be interpreted,
then it is going to be destructive and do the wrong thing. If you want
colour-accurate display, there is no good solution based on the
premise that your display controller should have no idea about
colours.

Cheers,
Daniel