[RFC wayland-protocols] Color management protocol

[Graeme Gill]

Jason Gerecke wrote:
> On Mon, Dec 19, 2016 at 7:04 AM, James Feeney <james at nurealm.net> wrote:

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

Input events are nowhere as closely related to the rendering
systems as color management is though. Color management is
to do with the actual pixel values, the way that pixels
get rendered by (say) a GPU (if there is a compositor
implementation of a CMM), the way the pixels get routed
to displays, the setup of the pipeline from frame buffer
to display, and the communication to and from the display
itself. Nor is this compositor specific - many applications
have color management goals, and all applications and the
desktop benefit from a mechanism to manage display
characteristics when faced with the wide gamut problem,
and it is desirable that all Wayland compositors support
some level of color management.

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

That's all fine if it is something that is 1) clearly separate
from rendering and the display and 2) that there is a mechanism
(say a standard server boilerplate) to setup specific standardized
extra services related to the desktop, rather than merely shifting
pain points from one area to another.

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

Might be waiting a while at the current rate. Don't delete your
X11 server just yet.

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

Or be prepared to re-visit Wayland's fundamental design decisions
if they turn out to be based on a false premise.

Graeme Gill.