[RFC wayland-protocols] Color management protocol

[Daniel Stone]

Hi,
I'm going to be very blunt here, because the attitude, arrogance, lack
of respect and civility, and general unwillingness to see a point
demonstrated by multiple people in this thread is perhaps the worst
I've ever seen on this list.

I recommend you re-read Pekka's emails a couple of times until they
sink in. It is clear that you are extremely experienced in colour
management; more so than most in this discussion. It is equally clear
that you do not understand Wayland as a system, its fundamental design
principles, nor the things modern desktops do to invalidate pretty
much every single assumption that your arguments are resting on. Pekka
was kind enough to point them out, but they don't seem to have sunk
in. If you reduce Wayland's capabilities to that of X11, then some of
your suggestions may be less wildly unsuitable, but on the other hand,
we might as well be using X11 if that were the case.

On 20 December 2016 at 04:17, Graeme Gill <graeme2 at argyllcms.com> wrote:
> Pekka Paalanen wrote:
>>> 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.

Let's say that the target here is a user for whom absolute colour
correctness is so critical, that they have deeply specialised
applications and hardware, monitors most people have never heard of,
secondary measurement and calibration hardware, and have sunk a great
deal of time into specifically configuring this.

For such a user to pick a compositor which was actively bad at colour
management would be rank stupidity.

If you don't trust the compositor you're using to do the thing which
is above all else most important to you, maybe pick something else?

I also invite you to read up on 'the platform problem', which might as
well specifically be describing this thread:
https://lwn.net/Articles/443531/

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

Why are you here then?

I appreciate parts of this thread have been frustrating, but the fact
you're participating in these discussions whilst slating Wayland as
poorly-designed crap that will never take off, suggests that a) you
don't actually understand it (objectively true, by this thread), or b)
deliberately saying these kinds of things to get a rise out of people.
Neither are a good look, so please grow up.

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

This is risible hyperbole, and total rubbish.

You're painting a false dichotomy where either people use external
tools to allow colour-critical users to compensate for the damage
their known-bad compositors do, or there is no chance of ever having
colour management ever. If only there was a third option.

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

This thread perhaps demonstrates why many projects which would
otherwise care about colour management have such difficulty supporting
colour management correctly.

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

The problem here starts with 'it's not even a complete solution',
continues on via 'colour control within display hardware is now more
complex than you realise', and ends with 'this is limiting enough to
be the worst of all possible worlds'.

You keep repeating this solution as axiomatic; if it really is the
only possible option for you to work with Wayland, then I thank you
for your interest in discussion and wish you the best in your future
endeavours.

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

Oh good, again we're into the land of presenting subjective judgement
as if it were absolute truth. Always productive.

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

Reading you reiterate this yet again, I'm stunned that you want to
explicitly design for a system where a core and indispensible
component of the rendering pipeline, is incapable of correct
rendering. I understand how and why that came to be, but this is not
the system we are designing here.

The entire reason it's taken this long for this discussion is because
it was kicked into the long grass a couple of years ago. It was
delayed specifically to allow the entire ecosystem (Wayland itself,
the compositors and toolkits, applications, plus rendering and display
control APIs) to mature enough to let us design a credible solution.
'Everything is going to be bad so let's let apps bypass and drive it'
is not that solution.

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

Privilege being pretty important, when you care about security.

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

Much as the compositor's rendering and display pipeline is part of an
overall system, yes.

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

Yes, everyone on this thread agrees. But the detail of the specific
implementation of configuration you have in mind, is not the same as
the concept of configuration.

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

Therein lies a problem ... if you have decided that the only solution
is external tools. Given that you're an external tool vendor, it's an
understandable point of view, but it's not mine, or that of many
others.

> [further astounding leaps of logic and unilateral judgement elided]

Niels, I think conceptually you have the foundations of a good system
in this proposal. I need to do some more looking into colour
management (bit of light reading for Christmas), so hopefully I can
have some more pertinent questions and suggestions after that.

This thread has been enough of a catastrophe so far that it's taken me
around half a day to actually properly read through it, and even then
I skimmed some of the more egregiously pointless parts. Hopefully we
can all engage in the Christmas spirit a little bit, and continue this
attempting to productively discuss technical solutions, rather than
shouting subjective judgements taken as axiom at each other, assuming
that the other person is an idiot.

Graeme, you obviously have a vast depth of colour management
expertise, and I hope this is something we can make use of, but your
attitude is shocking and your net contribution to this thread has to
be negative. Carsten, please try to constrain yourself to a core point
and try not to talk past others; maybe re-read your mails before
sending them? Graeme did have some reasonable points (beyond the
nitpicking at nomenclature) which you definitely didn't absorb from
his replies. Unfortunately I have no desire to dig those sub-threads
up.

Grumpily yours,
Daniel