[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:
> On Tue, 20 Dec 2016 15:17:31 +1100
> Graeme Gill <graeme2 at argyllcms.com> wrote:

> When I was talking about configuration, your reply talks about content
> delivery. We are continuously talking past each other. I talk about one
> thing, you deliberately interpret me talking about the other thing, so
> that you can make me look silly. I'm tired of correcting that in every
> turn.

You weren't talking about configuration, you were talking
about control. They are not the same thing. An application determines
(i.e. is in control of) the content it wants presented to the user.
That is its role. If it isn't in control of that, it can't do the job
the user expects of it.

[ And yes, I too am finding it rather tiring to be explaining
  color management fundamentals over and over again. ]

> Clients control what they send to the compositor: that is content
> delivery.

Exactly. Part of that content is color. To control that particular content,
the color values depend on the display they are being presented
on, i.e. which Output. So at some level the application needs to
know what outputs it's content will be delivered to, in order
to provide the correct content.

> Configuration controls compositor's global settings, like CRTC CLUT
> values.

Yes. But certain aspects of a display are both operational
elements _and_ configuration.

To a color calibration application, the VideoLUT is an operational
display element, just like the pixels values are to other
kinds of graphical applications. It's not configuration. Once
it's done, it becomes configuration for other applications
using the display.

So I'll agree that you can classify such an aspect as either
content (in the sense that it is a graphic output element
an application needs to manipulate to function), or configuration.
I'm sure you will say this is more configuration that content - fine.

But from the the calibration application writers point of view,
to write such an application it's very highly desirable
(i.e. may make the difference between such an application
existing or not) that there be a standard API to operate this
graphics system element, that is common and supported by the
graphics display system that it is intended to "configure".
What's the path for that, if it's not a Wayland protocol extension.
Is there a standard Wayland configuration protocol that can be extended ?

(And no, color calibration and profiling is not a "do it at the
 factory and pre-install it" type of thing. It's something
 some users want to do regularly.)

> Why would you not let compositors use the CMS libraries people have
> developed?

Nothing stopping them inventing their own color calibration and
profiling system. But can they afford the development effort ?
(My own color software has been developed over about 20 years).
There may be source code available to them under licensing
conditions that allow them to include it in the compositor,
but do they want to maintain such a port, and is
it really a good idea to want to include a full blown
application of considerable size and complexity, within a
compositor ? (All that color measurement instrument support!)
Do users want to be locked into a single
choice of such a built in application ?
Is it really expected that the compositor has to
be updated every time there is a bug or new feature in
the color management code ?
Maybe they can include a very stripped down
version of color management applications
(as Richard has done in Gnome), but that isn't
going to satisfy color critical users, and
seems rather contrary to open source philosophy to
deny users any way of using something else instead.

Answer - this seems rather unlikely to be a viable path. It's
not reasonable - color management applications need
to be independent applications to be practical, and the
alternative is fairly simply by comparison :-
provide the API's needed as standard.

> This is where we disagree, and that prevents us from making any
> progress.

It's up to you. I've laid out some sketches based on
existing working systems of how color management could
be supported in Wayland, but there are lots of variations
of how to do it, as long as they acknowledge the
logical realities of how color management works, and the
practical realities of how the associated applications work.
Suggest some approaches that take it forward.

Graeme Gill.