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

[Sebastian Wick]

New version with smaller changes and clarifications and a new feature:

* Introduce enum color_space_name to optionally name a color space
  object when the color space is well-known. Even if the color space
  object is describing one of the well-known color spaces it may not be
  tagged with the name and is purely an augmentation. The reasoning here
  is that figuring out if a profile describes a well-known color space
  is not trivial. This might be useful for HDR displays.
* tighten the requirements on the accepted ICC profiles
* disallow creating multiple zwp_color_management_output/surface objects
  from the same wl_output/wl_surface
* zwp_color_management_output/surface become inert when their associated
  wl_output/wl_surface is destroyed
* rename zwp_* to zwp_*_v1
* reorder rendering intents
* add relative+bpc intent
* allow to reset the color space attached to a surface by passing NULL
  in set_color_space and comming the state
* clearify that the color space attached to a surface is reset when the
  associated zwp_color_management_surface is destroyed
* getting the color space information event now requires sending the
  get_information request
* restrict the client usage of the ICC fd to mmaping with MAP_PRIVATE
* clearify that the ICC fd send in color_space.information may not be
  the same as the one used to create the object

There is two FIXMEs left for which I would also appreciate feedback

* How exactly should the restriction on the ICC fd look like that gets
  send from the client to the compositor? In my Weston POC I use read
  and make sure the fd is O_NONBLOCK and construct a new independent fd
  representing the color space so the client fd can be released by the
  compositor. Mmaping would require handling SIGBUS again. Not sure
  what's better.
* Should we actually mandate un-premultiplied data? I have to look at
  KMS plane blending, the graphics ROPs and custom blend shaders to
  figure out what they all do.

The focus for the next version is probably going to be HDR. So I'd also
appreciate if we can come to a concensus on the overall design of HDR
support.

I'm also still looking for people who want to become co-maintainers of
the protocol.

Previous version:
https://lists.freedesktop.org/archives/wayland-devel/2019-March/040319.html

Weston POC implementation:
https://gitlab.freedesktop.org/swick/weston/commits/color-management-backend


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

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

-- 
2.23.0