[RFC wayland-protocols 1/1] unstable: add color management protocol
Nautiyal, Ankit K
ankit.k.nautiyal at intel.com
Thu Feb 14 09:23:47 UTC 2019
On 2/14/2019 1:27 PM, Sebastian Wick wrote:
> 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?
Sorry, I missed the color_space_added event.
I got it now. So as soon as the client starts, and binding of the client
object to the
server, it receives a series of events, notifying it with the well-known
colorspaces.
Clients stores each of the color_space interfaces and choose it deems best.
Thanks for clarifying, this answers my other question as well, regarding
well-known color-spaces.
I still wonder about the 'information' event sent by the
color_space_interface.
When will this event be sent. I think this should be in response to a
client request for the
color-space information via the color_space_interface.
Also, such an event will be sent for which all outputs?
>>
>> 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, that will be great.
Should you have anything to discuss in this regard, please let me know
through mail, or IRC: aknautiy
Regards,
Ankit
>
>>
>> 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
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190214/0c2072ff/attachment-0001.html>
More information about the wayland-devel
mailing list