[RFC wayland-protocols] Color management protocol

[Niels Ole Salscheider]

Am Donnerstag, 8. Dezember 2016, 15:51:12 CET schrieb 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 is (currently) up to the compositor to decide how to implement this. The 
compositor could come with its own settings for the output color profiles or 
query some other program. This might be colord, but it could also be 
kolormanager, or something else.

> 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.

Yes, with the protocol I proposed there is a (small) time window after 
changing the output color space where the application might still display 
surfaces with the old color space...

> 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.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel