[RFC wayland-protocols] Color management protocol

[Pekka Paalanen]

On Wed, 14 Dec 2016 18:49:14 +1100
Graeme Gill <graeme2 at argyllcms.com> wrote:

> Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 12 Dec 2016 17:57:08 +1100 Graeme Gill <graeme2 at argyllcms.com> said:  
> 
> >> Right. So a protocol for querying the profile of each output for its surface
> >> is a base requirement.  
> > 
> > i totally disagree. the compositor should simply provide available colorspaces
> > (and generally only provide those that hardware can do). what screen they apply
> > to is unimportant.  
> 
> 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.

Hi,

that is a very strange requirement, and architecturally it is a big
step backwards.

Applications are never in direct control of the display hardware. If
they need to be, they need to be written directly on DRM/KMS, not
Wayland. That way you truly get what you want: no compositor to mess
with your colors, and no fighting between different apps demanding
different display confgurations. If you really have applications this
color critical, then you'd better do exactly this or provide/audit the
compositor yourself.

In every other case, there is a display server *with a compositor*
between the application and the display. The compositor will
necessarily copy and translate pixel values from one format to another,
if not from color space to another.

The compositor is also in control of the display hardware: color lookup
tables, color transformation matrices, hardware overlays and direct
scanout of client buffers at opportunity. Scanout hardware can often do
color transformations on its own, with a method that might be unknown
to anyone but the vendor. All of these depend on the hardware whether
and which of them are available. What you are proposing necessarily
leads to moving the control of all of these into Wayland clients. 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.

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

You cannot take the compositor out of the equation unless you don't
have a compositor at all.


Here are some other points:

- Blending will only be an issue if a color-managed window has
  non-opaque pixels. If the application cares about the end result, it
  should not have non-opaque pixels, because not only it cannot know
  *how* they will be blended, it also cannot know *what* they will be
  blended with.

- You do not know which parts of a window are shown on which outputs.
  Some parts may be shown on multiple outputs at the same time. There
  is no provision for clients to provide a buffer separately for each
  output (you could add that as an extension). Therefore the same
  buffer content must be applicable to any and all outputs in the
  system. Unless all outputs have identical color profiles, this
  necessarily means the compositor must convert while compositing.

- Different compositors will always have different levels of color
  management support. You might want the color management protocol
  extension(s) to implicitly or explicitly indicate the level, perhaps
  even validation/auditing certificates. (Think about, say,
  professionally calibrated workstations where all the hardware, the
  drivers, the compositor and settings have been verified and locked
  down.)

- Calibration (i.e. modifying compositor configuration) must
  necessarily be a separate interface from the ones used by
  applications that only want to present color-managed content.
  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.


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/20161215/38d65ebb/attachment-0001.sig>