[RFC wayland-protocols v2 0/1] Color Management Protocol

[Sebastian Wick]

Sending in v2 with small fixes only. I'm using this in the hope to focus
the previous discussion in the direction of the actual protocol and
implementation.

It looks like we have come to at least some consensus on a few points.
If anyone disagrees here that would be great to know.

1. The color management protocol should contain support for HDR. I've
   previously argued against it but everyone else seems to agree and I
   don't have a strong opinion.

2. The whole pipeline should look something like

   [surface cs] -cs conversion-> [output cs] -tone mapping-> [output cs]
   -degamma-> [output linear cs] -blending-> [output linear cs] -gamma->
   [output cs].

   Where some parts can be skipped if e.g. surface cs == output cs or
   surface and output are SDR.

3. A CMS (like lcms2) can create a 3d lut which the pipeline can use to
   do the color space conversion from two 3 channel ICC profiles and a
   rendering intent.

4. A CMS can also create a 1d lut from the same data to linearize a
   surface from the output color space (degamma, gamma).

5. Device link profiles don't offer enough information to correctly do
   blending and convert to a random output color space.

6. The client should know which color spaces the surface is likely going
   to be converted to.

7. The CRTC gamma lut belongs to the compositor and no client should be
   able to directly change it.

Which brings me to open issues:

1. Does it make sense to support device link profiles? I'm against it
   but would love to hear if anyone has objections given that they are
   supported in the other proposal.

2. How exactly should the client be informed of the "prefered" color
   spaces?
   IMO there are a few requirements:
   * the client should know when the prefered color space changes
   * the client should know when multiple color spaces are involved
   * the priority of those color spaces
   The single "prefered" color space that can be requested doesn't meet
   those requirements, neither does the wl_output.enter/leave (missing
   priority) nor does my protocol (moving the surface to another output
   will not trigger any new events).
   Another point here is that wl_output actually doesn't map to a single
   but multiple color spaces (e.g. cloned display).
   Better ideas are very welcome!

3. Do the standard color spaces actually improve anything? When the
   compositor doesn't have to make them available to clients and they
   can't rely on them being available, what's the point? Especially when
   displays don't really support standard color spaces most of the time
   (according to the EDID).

4. How do universal planes handle gamma when blending? This hopefully
   has a sinmple answer and there probably is some documention which
   I just can't find.

There is some more open issues regarding HDR but I'll leave that to
Ankit.

Did I miss anything?

Sebastian Wick (1):
  unstable: add color management protocol

 Makefile.am                                   |   1 +
 unstable/color-management/README              |   4 +
 .../color-management-unstable-v1.xml          | 189 ++++++++++++++++++
 3 files changed, 194 insertions(+)
 create mode 100644 unstable/color-management/README
 create mode 100644 unstable/color-management/color-management-unstable-v1.xml

-- 
2.20.1