<html> <head> <meta content="text/html; charset=utf-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 2/14/2019 1:27 PM, Sebastian Wick wrote: </div> <blockquote cite="mid:3c0dd6c154fa2db220830e1c8f936376@sebastianwick.net" type="cite">On 2019-02-14 08:13, Nautiyal, Ankit K via wayland-devel wrote: <blockquote type="cite">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] </blockquote> Thanks. That's useful. <blockquote type="cite"> 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? </blockquote> I absolutely think that this can be extended for handling HDR. <blockquote type="cite"> [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> [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> Also, there are a few queries to understand the flow, please find below inline: On 2/14/2019 8:16 AM, Sebastian Wick wrote: <blockquote type="cite">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 \ </blockquote> unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml <blockquote type="cite">\ 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> + </blockquote> 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. </blockquote> 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? </blockquote> 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? <blockquote cite="mid:3c0dd6c154fa2db220830e1c8f936376@sebastianwick.net" type="cite"> <blockquote type="cite"> 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. </blockquote> 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. <blockquote type="cite"> <blockquote type="cite">+ <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> + </blockquote> 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? <blockquote type="cite">+ <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> + </blockquote> 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? </blockquote> 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. </blockquote> 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 <blockquote cite="mid:3c0dd6c154fa2db220830e1c8f936376@sebastianwick.net" type="cite"> <blockquote type="cite"> Thanks & Regards, Ankit <blockquote type="cite">+ <event name="done"> + <description summary="done listing color space conversions"> + All color space conversion have been listed. + </description> + </event> + </interface> + +</protocol> </blockquote> _______________________________________________ wayland-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </blockquote> _______________________________________________ wayland-devel mailing list <a class="moz-txt-link-abbreviated" href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a class="moz-txt-link-freetext" href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </blockquote> </body> </html>