[RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

Hi,

could you keep the CC list intact, please.

On Mon, 19 Dec 2016 12:37:14 +1100
Graeme Gill <graeme2 at argyllcms.com> wrote:

> Pekka Paalanen wrote:
> > On Wed, 14 Dec 2016 18:49:14 +1100
> > Graeme Gill <graeme2 at argyllcms.com> wrote:  
> 
> >> Please read my earlier posts. No (sane) compositor can implement CMM
> >> capabilities to a color critical applications requirements,
> >> so color management without any participation of a compositor
> >> is a core requirement.  
> 
> > that is a very strange requirement, and architecturally it is a big
> > step backwards.  
> 
> 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
> > may have been so with X11 where any client can change any display
> > setting any time it wants, but I cannot see that happening on Wayland.  
> 
> 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.

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

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.

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.

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.

> > If the pixels go through a display server, you have no choice but to
> > trust the display server to do the right thing. So the real question
> > is: "How do you let the compositor do the right thing?"
> > Not: "How do I bypass the compositor?"  
> 
> I didn't ask to bypass the compositor - you are the one assuming that.
> 
> I merely asked that core color management provide a means hat allows the
> application to provide display colorspace values, and that the compositor
> not mess with them.

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.

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.

> > - You do not know which parts of a window are shown on which outputs.  
> 
> Right. So that information needs to be communicated to the application,
> just like it currently is on systems like X11, OS X and MSWin.

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.

In this case, it is possible to achieve the goal without introducing
such glitches.

> > - Calibration (i.e. modifying compositor configuration)  
> 
> No, calibration in this context is setting the CRTC per channel
> lookup tables (RAMDAC contents).

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.

> >   must
> >   necessarily be a separate interface from the ones used by
> >   applications that only want to present color-managed content.  
> 
> Sure. Which is what I suggested.

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.

> >   Conflating it all into a single interface will cause problems with
> >   privilege separation and encourage usage patterns where different
> >   applications cannot work at the same time because they will be
> >   fighting over who gets to set the current configuration.  
> 
> Please suggest how to organize it then. I have looked through
> the Wayland documentation, and didn't spot any discussion on
> how privileged management operations are authorized or
> conveyed. Splitting these things up may make for a lot
> of extensions though. Seems simpler to privileged certain
> operations.

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.

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.

They should be very much orthogonal, not the least because you cannot
except any compositor to implement the configuration interface.
However, a common standard interface for describing color-managed
content and the compositor capabilities is important to have.

> > Applications have no right to be configuring *anything* in a desktop
> > compositor.  
> 
> So how is a Wayland desktop managed then ? By magic ?

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

> > It is usually reserved for the desktop
> > environment's configuration utilities that the user will be using
> > manually.  
> 
> So how does one write a Wayland based desktop configuration utility/application
> in a way that is not dependent on the particular operating system
> environment or compositor ?

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.

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.

The times when you could just bypass the DE when something didn't work
are behind us.

The key to success here is to completely decouple configuration from
application usage, and concentrate on the application usage which can
be standardised.


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