[RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Tue, 20 Dec 2016 13:05:10 +0100
Kai-Uwe <ku.b-list at gmx.de> wrote:

> Am 20.12.2016 um 10:08 schrieb Pekka Paalanen:
> > 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.  
> 
> That's not correct. Keith Packard and other people rejected the idea of
> adding a new XCMS layer in the X server. He said color conversion
> belongs into the window manager. So we are using today the X property
> system to communicate between applications, compositors and
> configuration libraries/systemsettings dialogs (beside the
> Xinerama/XRandR gamma table APIs).

Oh nice. So indeed, CMS belongs in the compositor too (not only
clients), because it is the window manager in the Wayland architecture.

But yes, I did mean to include also political decisions on what belongs
where.

> IMO the main difference to wayland is that: we do not know a similar
> inherent transport mechanism for meta data like Xatom is for X11. (I
> share Graemes position, that the meta data communication path should
> match that of wayland in order to remain compatible. I do not like the
> idea to randomly add different mechanism as wayland extents
> capabilities. Most relevant image file formats had adopted some way to
> attach meta data. Otherwise workflows are not flexible enough.) That
> meta data communication path has __not__ necessarily the need to
> configure wayland.

Meta-data is fine. Totally fine. That's what we do need in Wayland, and
that is what Niels has been working on.

Global configuration (e.g. programming display CLUTs) is a completely
different thing. That is my clash with Graeme.

After thinking about my last reply to Graeme, I have become more
convinced that compositors must be full-fledged CMS users, not only
applications. Now the question becomes: what do you need from Wayland,
so that the application side instance of CMS can relay the necessary
information to the compositor-side CMS, so that the compositor can do
the right thing? And vice versa.

When one integrates a CMS in a compositor, you no longer need to
expose configuration (hardware configuration, like CLUT programming)
via any protocol. The compositor talks directly with the CMS and if the
compositor can set e.g. CLUTs, CMS can tell it what to set.

I am assuming that the compositor can interface with a CMS by calling
into a library offered by the CMS. If that interfacing was previously
done over X11, then you have to write that library. It will be more
efficient too, since you don't have to serialize and deserialize, and
asynchronicity (problems) appear only when you want to.

I'm slowly starting to suspect that CMS designers need a slight paradigm
shift: the compositor is meant to integrate with the CMS, instead of
the CMS given low-level access to the hardware bypassing the window
manager. CMS is no longer something that can be bolted on externally,
like it is in X11. Embrace the idea of integration, and I belive and
hope that it will pay off as a much more reliable architecture and
polished user interfaces. Some of what used to go over X11 would
probably be much better as a library ABI, but in X11 times it was not
possible because X11 implied separate processes.

Btw. in X11, how do CMS integrate/interface with compositing managers?
Who does the colorspace etc. conversions? How do you control blending
spaces? How have you implemented GPU-accelerated color mapping?

The compositor internal interfaces can and should be used for what
Xinerama, RandR and whatever you have been using to configure an X
server through X11. This time, the compositor needs to load and
interface with the CMS.


As to what you really need from Wayland, there are two ways that are
perhaps even complementary:

1. The one Niels started with: a standard protocol extension that is
   used manually.

2. The approach what e.g. libEGL uses: if you have a particular CMS
   implementation, and the compositor initializes the CMS, the CMS can
   hook up it's very own Wayland protocol extensions. When a client
   initializes the same CMS, the CMS looks up the
   CMS-implementation-specific extension from the Wayland display, and
   uses it. This way everything about the Wayland protocol extension is
   actually private to the CMS implementation. The cost is that you
   need a library ABI in the CMS, one for compositors and one for
   clients.

A "benefit" of option 2 is that you don't have to go through the
Wayland upstream review process but only your own.


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/f11d4728/attachment.sig>