[RFC wayland-protocols 1/1] unstable: add color management protocol
Sebastian Wick
sebastian at sebastianwick.net
Thu Feb 14 07:57:13 UTC 2019
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 <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.
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 at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
More information about the wayland-devel
mailing list