[RFC wayland-protocols 1/1] unstable: add color management protocol
Nautiyal, Ankit K
ankit.k.nautiyal at intel.com
Thu Feb 14 07:13:09 UTC 2019
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]
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?
[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 <sebastian at 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 <sebastian at 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.
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.
> + <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?
Thanks & Regards,
Ankit
> + <event name="done">
> + <description summary="done listing color space conversions">
> + All color space conversion have been listed.
> + </description>
> + </event>
> + </interface>
> +
> +</protocol>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190214/673f75b0/attachment-0001.html>
More information about the wayland-devel
mailing list