[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Pekka Paalanen wrote:

> could you keep the CC list intact, please.

Sorry - no. I don't like getting spammed with multiple copies
of the same email, so I don't do it to other people.

>> Since Wayland doesn't currently implement any color management support,
>> I'm not following how it can be a step backwards.
> 
> It is step towards "clients are in control and the compositor does not
> know what is happening". That is, a step towards X11 design and away
> from Wayland design principles.

It depends on what you mean by "control". Wayland can't operate
without applications providing the content, and color is part of
content.

>> Wayland is useless unless there is a way to manage it. Which means
>> that it should have channels for administrative tools to configure it.
> 
> Indeed: Administrative tools. These are part of the compositor or the
> desktop environment distribution. They have the privileges to configure
> the compositor.

And how are management functions that can't reasonably be contained
in the compositor handled then ?
A compositor is _not_ going to come with display color calibration
and profiling functionality - it's too complex and specialized.
The user will insist on being able to choosing such tools anyway.

> However, in this thread we are talking about arbitrary applications,
> not administrative tools.

There is no difference, apart from any privilege needed.

> Administrative tools must always be written to interface with the
> compositor, they cannot go changing things behind the compositor,
> because then the compositor will lose track of the setting and
> malfunction will happen.

Sorry - I'm not following. You mean that the compositor doesn't
pay any attention to the Wayland protocol ?

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

What is the point of Wayland then ? If it doesn't standardize
a protocol so that applications can be written once to
that protocol and will run on all systems that conform
to that protocol, why bother with it at all ?

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

Please point out the "tailor-made ways" they all have of
supporting color management then!

And you are mistaken if you think that color management tool
or application authors like myself are about to create N different
versions of our applications for each of the different
compositors different "tailor-made ways"! Life is simply
too short.

So the future is pretty clear - if Wayland doesn't accommodate
color management, then no applications or users of color
applications are ever going to use Wayland. No
Scribus, Krita, GIMP, Inkscape or Darktable for Wayland.
No Photographers, Videographers or Desktop publishers using
Wayland.

> If you want a standard interface, you have to get the buy-in from the
> major DE projects first. One can write a protocol spec and throw it
> into wayland-protocols, but whether anyone will implement it is another
> matter.

Go right ahead and build the barriers to supporting Wayland higher then.

> That is one of the things you said you want. You also said that:
> "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."
> 
> Those are two very very different things.

Yes, but they are related by both being about supporting
color management, and the fact the color profile for
a display depends on its calibration state.

> The first one I agree. The second one I strongly object unless it
> originates from more than one DE project and is kept non-essential for
> correct operation. Please, do not conflate them.

Setting VideoLUTs has been standard in display systems almost
forever. Find a way of implementing support in Wayland, so
that color management can happen in Wayland.

> No, it will not. The application cannot keep up with window moves
> re-rendering the regions and the compositor cannot wait for the
> application to catch up. Adding features that cannot be implemented
> without introducing glitches was fine with X11, but it is not ok in
> Wayland.

If the founding principles of Wayland turn out to be based on faulty
assumptions, then you need to either revisit those principles
or abandon Wayland.

> That *is* compositor configuration. There is no other entity to
> maintain it. See the reference to libinput configuration below as an
> example of another similar case.

It's display configuration, which is (presumably) the compositors
job to help the user manage.

> You have mentioned configuration being separate maybe once or twice,
> yet in every turn you have been promoting configuration as a necessary
> part in conjuction with the public color-managed content interfaces,
> conflating the two into one, hence my objection.

Because what I have suggested is not separate except perhaps
in privilege.

> Extensions are extremely cheap. It is much harder to have a privileged
> operation inside an otherwise public interface, than making a whole new
> different interface for the privileged actions.

OK - so separating privileged and non-functions within an extension
is the way to go ?

> The first step would be to start talking about them as completely
> separate and independent things. You do not need to design the
> configuration interfaces at the same time with the interface that
> applications use to provide color-managed content.

Yes I do, since they are part of an overall system.

> They should be very much orthogonal, not the least because you cannot
> except any compositor to implement the configuration interface.

Without the ability to configure, the other public interface is
useless.

> By the afore-mentioned administrative tools, that most often do not use
> Wayland to talk to the compositor, because they already have other
> means (that are not X11 either).

And therein lies a problem.

> That's a part of the general question: How do you write a desktop
> environment configuration utility that works in KDE, GNOME and
> Enlightement?
> 
> I believe the answer which has been proven over the many years is:
> either you write one for each, or you don't.

OK - so I don't. So Wayland has no way of color calibration
or profiling, so Wayland can't be used for color critical
applications or users.

> A related example for a different sub-system:
> http://who-t.blogspot.fi/2016/03/why-libinput-does-not-have.html
> 
> Whenever libinput gets a new feature or setting, all compositors need
> to add code to support it. Why you cannot have a configuration
> interface directly into libinput to avoid waiting for compositors to
> implement the support is explained in that blog. The same reasons apply
> here.
> 
>> 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.
> 
> Indeed, that is the job of the desktop environment developers, not the
> application writers.

OK, so I guess Wayland will have to wait around for the
desktop environment developers to come to some consensus
about a protocol and implementation to support Wayland
application color management. Could take a while I guess,
since they might imagine that Wayland color management support
is a Wayland problem to solve.

Graeme Gill.