[RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Mon, 19 Dec 2016 08:04:48 -0700
James Feeney <james at nurealm.net> wrote:

> On 12/19/2016 03:04 AM, Pekka Paalanen wrote:
> > We very deliberately avoid defining any "standard" Wayland interfaces
> > for configuring a compositor, because every compositor is different.
> > With X11, you had the one single X server implementation and no other.
> > On Wayland, every compositor is an individual, just like every X11
> > window manager is.
> > 
> > I do not want to waste time in designing a "standard configuration
> > interface" when the realistic expectation is that none of the major
> > DEs' compositor will be implementing it. They already have their own
> > tailor-made ways. As a case study one could look at the feature set of
> > xrandr tool.  
> 
> At first glance, that comes across as off-point and shirking responsibility,
> where Weston boastfully promotes itself as "*the* reference implementation of a
> Wayland compositor, and a useful compositor in its own right".
> 
> Where is *Weston's* "pixel perfect" Color Management System?
> 
> Unless the argument is convincingly made that *nothing* will ever be required
> from the Wayland protocol in order for any compositor to implement a "pixel
> perfect" CMS, on its own, then 'deliberately avoid[ing] defining any "standard"
> Wayland interfaces for configuring a compositor' is just "throwing a monkey
> wrench" into the conversation.
> 
> To convincingly make that argument, create the Weston "pixel perfect" CMS, and
> demonstrate that nothing CMS related was required from the Wayland protocol.
> 
> What is the design outline of that Wayland-protocol-free CMS?

Hi,

it sounds like you too are conflating configuration with the public
interface to deliver color-managed content.

Wayland protocol must grow extensions to let applications tell the
compositor what kind of content they provide for color management
purposes, and probably also let the applications know which color
management features the compositor supports. A very related and useful
part of this is letting the applications know what kind of outputs the
compositor is using and what their calibration/color profile currently
is, but even more importantly, what kind or which color
profile/space/... definitions it can handle.

That is exactly where Niels started, and he started in the right end
of things. The questions to discuss are how do you represent a color
profile/whatever and how do you attach one with a wl_surface or a
wl_buffer, and how should a compositor process that; what guarantees
must a compositor make if it advertises some features; what information
does the compositor need to expose; etc. The important bit is that the
compositor's global state is read-only in this interface.

What I do not want to see as an integral part of this effort is a
compositor configuration interface, where a client can *change* how the
compositor operates globally, what the color data associated with an
output is, or how the hardware is configured. Why? Because it will take
literally many years to design and agree on. I don't want to block the
design and implementation of the application interface on that.

I hope I finally made that crystal clear.

Yes, you also need tools and interfaces for calibration and
configuration.

At this time, calibration needs to be considered on the level of how to
present a calibration image, so that you know what a measurement device
is measuring. Whether that should be integrated into the normal Wayland
interface applications usually use is an open question, but at first
hand I would advice against it: it may require resetting the hardware
state, which is a global operation, and hence needs to be privileged.
It is reasonable to design it as a Wayland interface rather than any
other, because it relies on presenting an image through Wayland.

Applying compositor configuration OTOH has no reason to be a Wayland
interface. You are not presenting anything through it, you are making
settings that are at most per-output, and there you do not gain
anything from using Wayland as the transport. I bet there will be
compositors which are configured by editing a settings file, for
instance. I would not want to deny them from implementing any kind of
color management support.

Every compositor is an individual. If you cannot design the public
interface for applications without also designing the configuration
interface and requiring everyone to implement both, it will take a very
long time to be adopted, if ever. The different DE and compositor
projects are not unanimous on how you map a normal window which is a
fundamental basic operation of all window systems, how could they ever
agree on a configuration interface?

Since the people demanding that everything must be
application-controlled from the start and that the compositor must do
nothing and know nothing are seasoned CMS developers (I presume), I
suspect they are trying to force the X11 model of doing CMS upon
Wayland. Is it really impossible to separate configuration from content
delivery?

Niels had an extremely good point that compositors *can* do all the
hard stuff too, by using the libraries the CMS experts have written.
This is not the X11 where you cannot add these features and
dependencies to the X server.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161220/c3d152bd/attachment-0001.sig>