<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><font size="-1">Hi Sebastian, <br>
        <br>
        I am trying to extend Ole's color management protocol [1] to
        enable a client to pass HDR meta data.<br>
        Added the modified protocol as weston protocol for the time
        being. [2]<br>
        <br>
        You have mention that the proposed protocol, ignores the HDR
        calibration/profiling,  so do you suggest there should<br>
        be another protocol for that altogether or is there a
        possibility to extend this for handling HDR metadata?<br>
        <br>
        [1]
<a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/archives/wayland-devel/2017-January/032770.html">https://lists.freedesktop.org/archives/wayland-devel/2017-January/032770.html</a><br>
        [2]
<a class="moz-txt-link-freetext" href="https://gitlab.freedesktop.org/aknautiyal/weston/commit/9d08cc22d6ba2b0c48ac255abc86ba5e217a507c">https://gitlab.freedesktop.org/aknautiyal/weston/commit/9d08cc22d6ba2b0c48ac255abc86ba5e217a507c</a></font><br>
      <br>
      <font size="-1">Also, there are a few queries to understand the
        flow, please find below inline:</font></p>
    <br>
    <div class="moz-cite-prefix">On 2/14/2019 8:16 AM, Sebastian Wick
      wrote:<br>
    </div>
    <blockquote
      cite="mid:20190214024621.6892-2-sebastian@sebastianwick.net"
      type="cite">
      <pre wrap="">This protocol allows clients to attach a color space and rendering
intent to a wl_surface. It further allows the client to be informed
which color spaces a wl_surface was converted to on the last presented.

Signed-off-by: Sebastian Wick <a class="moz-txt-link-rfc2396E" href="mailto:sebastian@sebastianwick.net"><sebastian@sebastianwick.net></a>
---
 Makefile.am                                   |   1 +
 unstable/color-management/README              |   4 +
 .../color-management-unstable-v1.xml          | 183 ++++++++++++++++++
 3 files changed, 188 insertions(+)
 create mode 100644 unstable/color-management/README
 create mode 100644 unstable/color-management/color-management-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 345ae6a..80abc1d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -23,6 +23,7 @@ unstable_protocols =                                                          \
        unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
        unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml \
        unstable/primary-selection/primary-selection-unstable-v1.xml            \
+       unstable/color-management/color-management-unstable-v1.xml              \
        $(NULL)
 
 stable_protocols =                                                             \
diff --git a/unstable/color-management/README b/unstable/color-management/README
new file mode 100644
index 0000000..140f1e9
--- /dev/null
+++ b/unstable/color-management/README
@@ -0,0 +1,4 @@
+Color management protocol
+
+Maintainers:
+Sebastian Wick <a class="moz-txt-link-rfc2396E" href="mailto:sebastian@sebastianwick.net"><sebastian@sebastianwick.net></a>
diff --git a/unstable/color-management/color-management-unstable-v1.xml b/unstable/color-management/color-management-unstable-v1.xml
new file mode 100644
index 0000000..1615fe6
--- /dev/null
+++ b/unstable/color-management/color-management-unstable-v1.xml
@@ -0,0 +1,183 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<protocol name="color_management_unstable_v1">
+
+  <copyright>
+    Copyright © 2019 Sebastian Wick
+    Copyright © 2019 Erwin Burema
+
+    Permission is hereby granted, free of charge, to any person obtaining a
+    copy of this software and associated documentation files (the "Software"),
+    to deal in the Software without restriction, including without limitation
+    the rights to use, copy, modify, merge, publish, distribute, sublicense,
+    and/or sell copies of the Software, and to permit persons to whom the
+    Software is furnished to do so, subject to the following conditions:
+
+    The above copyright notice and this permission notice (including the next
+    paragraph) shall be included in all copies or substantial portions of the
+    Software.
+
+    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+    IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+    FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+    THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+    LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+    FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+    DEALINGS IN THE SOFTWARE.
+  </copyright>
+
+  <description summary="color management protocol">
+    This protocol provides the ability to specify the color space
+    of a wl_surface. If further enumerates the color spaces currently
+    in the system and allows to query feedback about which color spaces
+    a wl_surface was converted to on the last present.
+    The idea behind the feedback system is to allow the client to do color
+    conversion to a color space which will likely be used to show the surface
+    which allows the compositor to skip the color conversion step.
+  </description>
+
+  <interface name="zwp_color_manager_v1" version="1">
+    <description summary="color manager">
+      The color manager is a singleton global object that provides access
+      to outputs' color spaces, let's you create new color spaces and attach
+      a color space to surfaces.
+    </description>
+
+    <enum name="render_intent">
+      <description summary="render intent">
+        render intents
+      </description>
+      <entry name="absolute" value="1"/>
+      <entry name="relative" value="2"/>
+      <entry name="perceptual" value="3"/>
+      <entry name="saturation" value="4" />
+    </enum>
+
+    <enum name="well_known_color_space">
+      <description summary="well-known color spaces">
+        Well-known color spaces
+      </description>
+      <entry name="none" value="0" summary="no known color space" />
+      <entry name="sRGB" value="1" summary="sRGB color space" />
+      <entry name="adobeRGB" value="2" summary="Adobe RGB" />
+      <entry name="DCI-3P" value="3" summary="DCI-3P" />
+      <entry name="rec2020" value="4" summary="rec2020" />
+      <entry name="rec2020-pq" value="5" summary="rec2020 with pq curve (HDR)" />
+      <entry name="rec2020-hlg" value="6" summary="rec2020 with HLG curve (HDR)" />
+    </enum>
+
+    <enum name="error">
+      <description summary="fatal color manager errors">
+        These fatal protocol errors may be emitted in response to
+        illegal color management requests.
+      </description>
+      <entry name="invalid_icc_profile" value="0" summary="invalid ICC profile"/>
+    </enum>
+
+    <request name="set_color_space">
+      <description summary="set the color space of a surface">
+        Set the color space of a surface. The color space is double buffered,
+        and will be applied at the time wl_surface.commit of the corresponding
+        wl_surface is called.
+
+        The render intent gives the compositor a hint what to optimize for
+        in color space conversions.
+
+        If a surface has no color space set, sRGB and an arbitrary render
+        intent will be assumed.
+      </description>
+      <arg name="surface" type="object" interface="wl_surface"/>
+      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
+      <arg name="render_intent" type="uint" enum="render_intent"/>
+    </request>
+
+    <request name="color_space_feedback">
+      <description summary="color space feedback">
+        Request color space feedback for the current content submission
+        on the given surface. This creates a new color_space_feedback
+        object, which will deliver the feedback information once. If
+        multiple color_space_feedback objects are created for the same
+        submission, they will all deliver the same information.
+
+        For details on what information is returned, see the
+        color_space_feedback interface.
+      </description>
+      <arg name="surface" type="object" interface="wl_surface"/>
+      <arg name="feedback" type="new_id" interface="zwp_color_space_feedback_v1"/>
+    </request>
+
+    <request name="color_space_from_icc">
+      <description summary="create a color space from an ICC profile">
+        Create a color space from an ICC profile. Only three channel
+        profiles are allowed.
+      </description>
+      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>
+      <arg name="icc" type="fd"/>
+    </request>
+</pre>
    </blockquote>
    <br>
    <font size="-1">If I understand it correctly,<br>
      the client first sends a request for getting color-space for an
      icc file, receives the color_space interface.<br>
      If we can add the surface in this requests, it can be tied to the
      color-space interface, and later set color_space,<br>
      without the surface.<br>
      <br>
      You have declared some of the color-space as well known, do you
      think it will be useful to also let the<br>
      client get the color_space interface, based on the well-known
      color-space.?<br>
      Server on the other hand can have already built objects from the
      standard icc files, the interfaces of<br>
      which can be passed to the client.<br>
      <br>
    </font>
    <blockquote
      cite="mid:20190214024621.6892-2-sebastian@sebastianwick.net"
      type="cite">
      <pre wrap="">+    <event name="color_space_added">
+      <description summary="color space added">
+        Send after binding or when a new color space is added to the system.
+      </description>
+      <arg name="color_space" type="new_id" interface="zwp_color_space_v1"/>
+    </event>
+  </interface>
+
+  <interface name="zwp_color_space_v1" version="1">
+    <description summary="a color space">
+      A color space can be attached to a wl_surface and sends
+      information like the ICC profile to let the client perform color
+      correction.
+    </description>
+
+    <event name="information">
+      <description summary="color space information">
+        Information describing the color space.
+
+        The icc argument contains a fd to the corresponding ICC profile.
+        well-known can be used to easily identify a color-space.
+
+        A color space can be associated with a wl_output.
+      </description>
+      <arg name="icc" type="fd"/>
+      <arg name="well-known" type="uint" enum="well_known_color_space"/>
+      <arg name="output" type="object" interface="wl_output" allow-null="true"/>
+    </event>
+</pre>
    </blockquote>
    <br>
    <font size="-1">When will this event be generated, should there be a
      request from a client via the color_space interface<br>
      for the information? Will events be sent for each output, the
      surface is displayed on?</font><br>
    <br>
    <blockquote
      cite="mid:20190214024621.6892-2-sebastian@sebastianwick.net"
      type="cite">
      <pre wrap="">
+    <event name="removed">
+      <description summary="color space removed">
+        This event is sent when the color space is removed from the system.
+        When this event is received, the client must destroy the object.
+      </description>
+    </event>
+
+    <request name="destroy" type="destructor">
+      <description summary="destroy the color space object">
+             Destroy the color_space object.
+      </description>
+    </request>
+  </interface>
+
+  <interface name="zwp_color_space_feedback_v1" version="1">
+    <description summary="color space feedback">
+      The surface content was converted to a number of color spaces
+      on the last content update. They get listed in decreasing order
+      of importance by the converted event.
+      Once a color_space_feedback object has delivered a done
+      event it is automatically destroyed.
+    </description>
+
+    <event name="converted">
+      <description summary="color space conversion">
+        The surface was converted to a color space.
+      </description>
+      <arg name="color_space" type="object" interface="zwp_color_space_v1"/>
+    </event>
+</pre>
    </blockquote>
    <font size="-1"><br>
      So a client with a surface, will receive a series of these events
      for its surface, whenever the<br>
      color space conversion takes place for that surface?<br>
      Why do we need this interface, can the color_manager be used to
      send these events?<br>
      <br>
      Thanks & Regards,<br>
      Ankit</font><br>
    <blockquote
      cite="mid:20190214024621.6892-2-sebastian@sebastianwick.net"
      type="cite">
      <pre wrap="">
+    <event name="done">
+      <description summary="done listing color space conversions">
+        All color space conversion have been listed.
+      </description>
+    </event>
+  </interface>
+
+</protocol>
</pre>
    </blockquote>
    <br>
  </body>
</html>