[RFC wayland-protocols] Color management protocol

[Jason Gerecke]

On Mon, Dec 19, 2016 at 7:04 AM, 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?

I can certainly see where you're coming from, as I too had similar
thoughts when getting my feet wet with with protocol design for tablet
input events. What it basically comes down to is that standardized
Wayland protocols are intended for providing features to "general
purpose" applications. Standardized protocols are not generally used
for configuring compositors for multiple reasons, e.g. recognizing
that not every compositor will want to offer the same configuration
options in the same way (read: feature-creep of configuration
interfaces with ever-more-niche options that only matter to single
compositors), and concerns about random applications changing settings
(read: sensitive/priviliged operations and applications "fighting"
each other to apply conflicting configs).

There is no "standard configuration interface" for something even so
basic as configuring input devices. It sure feels like shirking
responsibility, but its a conscious design decision to try and avoid
some of the pain points that we lived with in X.

Its possible to separate concerns of usage from configuration without
"throwing a monkey wrench" into the conversation. Its just necessary
to be mindful that defining (standard) Wayland interfaces is not
necessarily always the appropriate design decision. I'm just a
hobbyist photographer whose done casual reading about color management
and use a second-hand colorimeter and can't wait to see some color
management come to Wayland. But it will be necessary to figure out
exactly how to deal with its complexities in a way that is compatible
with Wayland's fundamental design decisions.

Jason
---
Now instead of four in the eights place /
you’ve got three, ‘Cause you added one  /
(That is to say, eight) to the two,     /
But you can’t take seven from three,    /
So you look at the sixty-fours....