On 2019-02-14 08:13, Nautiyal, Ankit K via wayland-devel wrote:
Hi Sebastian,
I am trying to extend Ole's color management protocol [1] to enable a
client to pass HDR meta data.
Added the modified protocol as weston protocol for the time being. [2]
Thanks. That's useful.
You have mention that the proposed protocol, ignores the HDR
calibration/profiling, so do you suggest there should
be another protocol for that altogether or is there a possibility to
extend this for handling HDR metadata?
I absolutely think that this can be extended for handling HDR.
[1]
https://lists.freedesktop.org/archives/wayland-devel/2017-January/032770.html
[2]
https://gitlab.freedesktop.org/aknautiyal/weston/commit/9d08cc22d6ba2b0c48ac255abc86ba5e217a507c
Also, there are a few queries to understand the flow, please find
below inline:
On 2/14/2019 8:16 AM, Sebastian Wick wrote:
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 <sebast...@sebastianwick.net>
---
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 <sebast...@sebastianwick.net>
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>
+
If I understand it correctly,
the client first sends a request for getting color-space for an icc
file, receives the color_space interface.
If we can add the surface in this requests, it can be tied to the
color-space interface, and later set color_space,
without the surface.
There is two ways to get a color_space object. The first one is to
listen for
color_space_added events and the other, like you noted, is to call
color_space_from_icc.
However, I don't see why a color space should should be tied to a
wl_surface
from the beginning. Binding the color space to a surface with
set_color_space
allows us to use the color spaces coming from the compositor via the
color_space_added event.
Can you explain why you want to do this differently?
You have declared some of the color-space as well known, do you think
it will be useful to also let the
client get the color_space interface, based on the well-known
color-space.?
Server on the other hand can have already built objects from the
standard icc files, the interfaces of
which can be passed to the client.
When the compositor loaded an icc profile for e.g. a display it should
emit a
color_space_added event which then, if the color space is "well-known"
(other
names were suggested) the zwp_color_space_v1.information event should
say
that.
So I think what you suggest is already possible with this protocol.
+ <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>
+
When will this event be generated, should there be a request from a
client via the color_space interface
for the information? Will events be sent for each output, the surface
is displayed on?
+ <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>
+
So a client with a surface, will receive a series of these events for
its surface, whenever the
color space conversion takes place for that surface?
Why do we need this interface, can the color_manager be used to send
these events?
The client will receive the events on the next present when it created
the
zwp_color_space_feedback_v1 object via
zwp_color_manager_v1.color_space_feedback.
This is strictly not needed but allows the client to choose a color
space
to render to which will likely be used to display the surface on the
next
present which in turn means that the compositor can skip color
conversion.
I hope this answers all your questions. Feel free to keep questioning
me.
I'll try to come up with a modification of this protocol that can handle
HDR
based on your changes.
Thanks & Regards,
Ankit
+ <event name="done">
+ <description summary="done listing color space conversions">
+ All color space conversion have been listed.
+ </description>
+ </event>
+ </interface>
+
+</protocol>
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
