[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Niels Ole Salscheider wrote:

> Therefore I think that the situation has changed and I'd like to propose this
> protocol for inclusion in wayland-protocols again.
> What do you think?

Hi,
	I'm prompted to look into the current state of color management
in Wayland, by Richard Hughes comment on the ArgyllCMS mailing list
recently that:

> About this; in the near future systems will be migrating from X11 to
> Wayland (Fedora 25 already defaults to Wayland, other distros will
> follow) and so setting X atoms is no longer going to work. Even with
> XWayland (the compatibility "wrapper" that provides an isolated
> xserver for the app) you can't use the root window as it's isolated
> from the other windows. I think most applications that want to know
> what profile to use are now using either libcolord, or more commonly,
> the colord DBus API.

What I take from this is that XWayland is lacking in its emulation
of existing X11 color management protocols (primarily due to lack
of underlying support in Wayland), and that currently the only
option for pure Wayland applications is to depend on system
specific work-arounds such as using Weston with colord. I can
therefore see that users that depend on color managed X11 applications
(such as photographers, desktop publishers, video editors etc.)
aren't going to be switching to Wayland based systems any
time soon.

Looking through the current Wayland color-management protocol
proposal, I think it is missing a really fundamental thing -
managing the output device color calibration state and color
profile. I guess the assumption is that this is being done
by colord, but my understanding is that colord is specific
to Gnome based systems, and certainly depends on DBus, which
Wayland does not. [ Please correct me if I've got any of this wrong. ]

It also seems fundamentally poor design to be using a parallel
protocol to manage the color of the graphics system, rather
than it being kept in sync with the elements being managed,
such as outputs and pixel rasters, etc. Certainly in X11 it is
all kept within the X11 protocol or its extensions.
If Wayland gets extended to be a remote protocol, then
the existence of in band protocols for color management
become even more important.

So as a broad outline, what I would regard as features of
a reasonable color management facility for a graphics
system such as Wayland are:

* That color management protocol's have two uses :- 1) configuring
  color management and 2) allowing applications to use color management.
  These two uses may need different security profiles.
  The assumption should be that color management applications
  used to create calibrations, profiles and configure the
  state of color management, are of equal importance to color
  managed applications that depend on a properly profiled and
  configured color management system, since you can't have latter
  with out the former.

* Color management of a graphics rendering system such as Wayland
  should be split into two levels (possibly two extensions) :-

  1) Core == output device management, which involves identifying output devices,
  controlling their calibration state (Video LUT), installing a color profile
  resources associated with that output device, and identifying which rendered
  pixels go to which output device(s). This is the most basic requirement, since
  this is the bare minimum for applications to be properly color managed. It
  is also a necessary resource for the second level to be able to operate.

  2) Enhanced == input space management, which assumes a graphics
  server rendering system capable of color management. This involves labeling
  an input raster with a color profile, and controlling the manner of
  rendering (i.e. rendering intent, maybe blending space ? etc.) This is useful
  for implementing default color management (e.g. as a means of coping
  with wide gamut displays when many applications are not color aware),
  or as a low developer overhead means of implementing basic color
  management in non color critical applications.

Translating these aims into a more concrete set of capabilities might
look like this:

Core:
	Get corresponding CRTC regions for a given Surface.
	Get corresponding Output(s) for a CRTC.
	Get unique Monitor identifier for an Output (i.e. EDID)
	Get/Set CRTC per channel lookup tables.
	Clear/Set/Get ICC profile associated with an Output.

	Event notifications:
	- CRTC to surface mapping change
	- Output to CRTC mapping change
	- Monitor to Output connection change
	- ICC profile associated with Output change

Enhanced:
	Clear/Set/Get default color management source RGB ICC profile for a display.
	Disable/Enable/UseDefault color management flag for a Surface.
	Clear/Set/Get source RGB ICC profile for a Surface.
	Set/Get source and destination rendering intents for a Surface.

Given that Wayland doesn't seem to have current support for configuring
CRTC's, Outputs etc., there still seem to be some big gaps to fill to add
even core color management support as part of the Wayland protocol.

Graeme Gill.