[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:
> On Wed, 14 Dec 2016 18:49:14 +1100
> Graeme Gill <graeme2 at argyllcms.com> wrote:

>> Please read my earlier posts. No (sane) compositor can implement CMM
>> capabilities to a color critical applications requirements,
>> so color management without any participation of a compositor
>> is a core requirement.

> that is a very strange requirement, and architecturally it is a big
> step backwards.

Since Wayland doesn't currently implement any color management support,
I'm not following how it can be a step backwards.

> Applications are never in direct control of the display hardware.

But applications have to be in control over the display content.
Content includes color.

> If
> they need to be, they need to be written directly on DRM/KMS, not
> Wayland.

I'm not sure why you think that, unless you are telling me
that applications can't send rasters to the display via Wayland.

> That way you truly get what you want: no compositor to mess
> with your colors, and no fighting between different apps demanding
> different display confgurations.

Messing with colors is not a requirement of the compositor. It can
leave them alone, just like it currently does. And I've
not mentioned display configurations.

> If you really have applications this
> color critical, then you'd better do exactly this or provide/audit the
> compositor yourself.

That's an extreme position to take - no other graphics system
(i.e. X11, OS X, MSWindows) has such a requirement for supporting
color managed applications.

> In every other case, there is a display server *with a compositor*
> between the application and the display. The compositor will
> necessarily copy and translate pixel values from one format to another,
> if not from color space to another.

And I'm pointing out that you cannot assume that a compositor will be capable
of translating from one colorspace to another in a way that the application
requires, so a means of allowing the application to provide color
values in display colorspace is a requirement. It's not that difficult,
the compositor just has to avoid messing with them, as well as
working as a communication point for display profile information.

> The compositor is also in control of the display hardware: color lookup
> tables, color transformation matrices, hardware overlays and direct
> scanout of client buffers at opportunity. Scanout hardware can often do
> color transformations on its own, with a method that might be unknown
> to anyone but the vendor. All of these depend on the hardware whether
> and which of them are available.

Which is why protocols for controlling the hardware should
ideally go via Wayland, so that applications who's job
is to setup that hardware can work.

> What you are proposing necessarily
> leads to moving the control of all of these into Wayland clients.

Yes - that's their job. Wayland or operating system management tools
don't have the expertise to manage such things - they don't know how
to create calibration curves or profiles etc.

> It
> may have been so with X11 where any client can change any display
> setting any time it wants, but I cannot see that happening on Wayland.

Wayland is useless unless there is a way to manage it. Which means
that it should have channels for administrative tools to configure it.

> If the pixels go through a display server, you have no choice but to
> trust the display server to do the right thing. So the real question
> is: "How do you let the compositor do the right thing?"
> Not: "How do I bypass the compositor?"

I didn't ask to bypass the compositor - you are the one assuming that.

I merely asked that core color management provide a means hat allows the
application to provide display colorspace values, and that the compositor
not mess with them.

> Here are some other points:
> 
> - Blending will only be an issue if a color-managed window has
>   non-opaque pixels. If the application cares about the end result, it
>   should not have non-opaque pixels, because not only it cannot know
>   *how* they will be blended, it also cannot know *what* they will be
>   blended with.

Yes, agreed. I pointed this out in a previous email.

> - You do not know which parts of a window are shown on which outputs.

Right. So that information needs to be communicated to the application,
just like it currently is on systems like X11, OS X and MSWin.

>   Some parts may be shown on multiple outputs at the same time.

Right, so since there is no hardware path for providing different
color managed value to each display, the best that can be done
in such hardware mirroring situations is to prioritize the color
management to the user designated display of highest priority.

>   There
>   is no provision for clients to provide a buffer separately for each
>   output (you could add that as an extension).

None is needed.

>   Therefore the same
>   buffer content must be applicable to any and all outputs in the
>   system.

This doesn't follow. Different parts of a buffer may go to different
Outputs. The application just needs to know the appropriate regions.

>   Unless all outputs have identical color profiles, this
>   necessarily means the compositor must convert while compositing.

Demonstrable not true, because current display systems work
without a compositor doing such things.

> - Different compositors will always have different levels of color
>   management support. You might want the color management protocol
>   extension(s) to implicitly or explicitly indicate the level, perhaps
>   even validation/auditing certificates. (Think about, say,
>   professionally calibrated workstations where all the hardware, the
>   drivers, the compositor and settings have been verified and locked
>   down.)

Which is why they shouldn't be relied upon for critical color
management.

> - Calibration (i.e. modifying compositor configuration)

No, calibration in this context is setting the CRTC per channel
lookup tables (RAMDAC contents).

>   must
>   necessarily be a separate interface from the ones used by
>   applications that only want to present color-managed content.

Sure. Which is what I suggested.

>   Conflating it all into a single interface will cause problems with
>   privilege separation and encourage usage patterns where different
>   applications cannot work at the same time because they will be
>   fighting over who gets to set the current configuration.

Please suggest how to organize it then. I have looked through
the Wayland documentation, and didn't spot any discussion on
how privileged management operations are authorized or
conveyed. Splitting these things up may make for a lot
of extensions though. Seems simpler to privileged certain
operations.

> Applications have no right to be configuring *anything* in a desktop
> compositor.

So how is a Wayland desktop managed then ? By magic ?

> Configuring the compositor is an action with global effects, and
> therefore must be privileged.

Of course - that is assumed.

> It is usually reserved for the desktop
> environment's configuration utilities that the user will be using
> manually.

So how does one write a Wayland based desktop configuration utility/application
in a way that is not dependent on the particular operating system
environment or compositor ?

As I've pointed out, expecting every such application writer
to write N versions of it for every possible such operating
system environment is a non starter, and the cracks will soon start
to show with remote versions of Wayland. The whole point of creating a
protocol such as Wayland is to provide a common API that can be used
by all applications that are intended to run on Wayland.

Graeme Gill.