[RFC wayland-protocols] Add the color-management protocol
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Mon Dec 19 02:08:31 UTC 2016
On Sat, 19 Nov 2016 17:29:20 +0100 Niels Ole Salscheider
<niels_ole at salscheider-online.de> said:
> Signed-off-by: Niels Ole Salscheider <niels_ole at salscheider-online.de>
> ---
> Makefile.am | 1 +
> unstable/color-management/README | 4 +
> .../color-management-unstable-v1.xml | 136 ++++++++++++++++++++
> + 3 files changed, 141 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 e693afa..ff435d5 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -12,6 +12,7 @@ unstable_protocols
> = \
> unstable/tablet/tablet-unstable-v2.xml
> \ unstable/xdg-foreign/xdg-foreign-unstable-v1.xml \
> unstable/idle-inhibit/idle-inhibit-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..3bd3e6c
> --- /dev/null
> +++ b/unstable/color-management/README
> @@ -0,0 +1,4 @@
> +Color management protocol
> +
> +Maintainers:
> +Niels Ole Salscheider <niels_ole at salscheider-online.de>
> 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..f2bb3f6
> --- /dev/null
> +++ b/unstable/color-management/color-management-unstable-v1.xml
> @@ -0,0 +1,136 @@
> +<?xml version="1.0" encoding="UTF-8"?>
> +<protocol name="color_management_unstable_v1">
> +
> + <copyright>
> + Copyright © 2014-2016 Niels Ole Salscheider
> +
> + Permission to use, copy, modify, distribute, and sell this
> + software and its documentation for any purpose is hereby granted
> + without fee, provided that the above copyright notice appear in
> + all copies and that both that copyright notice and this permission
> + notice appear in supporting documentation, and that the name of
> + the copyright holders not be used in advertising or publicity
> + pertaining to distribution of the software without specific,
> + written prior permission. The copyright holders make no
> + representations about the suitability of this software for any
> + purpose. It is provided "as is" without express or implied
> + warranty.
> +
> + THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
> + SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
> + FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
> + SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
> + AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
> + ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
> + THIS SOFTWARE.
> + </copyright>
> +
> + <interface name="zwp_color_management_v1" version="1">
> + <description summary="allows attaching a color space to a wl_surface">
> + This interface allows attaching a color space to a wl_surface. The
> + compositor uses this information to display the colors correctly.
> + For this, the compositor converts any attached surfaces to the blending
> + color space before performing the blending operations. After blending,
> + the output surface is converted to the color space of the output
> device.
> + This interface also provides requests for the sRGB and the blending
> color
> + space. It further allows creation of a color space from an ICC profile.
> + The client is informed by an event if the color space of one of the
> + outputs changes.
> + </description>
> +
> + <request name="set_colorspace">
> + <description summary="set the color space of a wl_surface">
> + With this request, the color space of a wl_surface can be set.
> + The sRGB colorspace is attached to a surface before set_colorspace is
> + called for the first time.
> + </description>
> + <arg name="surface" type="object" interface="wl_surface" />
> + <arg name="colorspace" type="object" interface="zwp_colorspace_v1" />
> + </request>
> +
> + <request name="colorspace_from_fd">
> + <description summary="creates a color space from an ICC profile">
> + This request allows to create a zwp_colorspace_v1 object from an ICC
> + profile. The fd argument is the file descriptor to the ICC profile
> (ICC
> + V2 or V4).
> + </description>
> + <arg name="fd" type="fd" />
> + <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
> + </request>
> +
> + <request name="output_colorspace">
> + <description summary="returns the color space for the requested
> output">
> + This request returns a zwp_colorspace_v1 object for the requested
> + output. A client can use this when it does not want its surfaces to
> be
> + color-corrected. In this case it can attach the color space of its
> main
> + output to its surfaces.
> + </description>
> + <arg name="output" type="object" interface="wl_output" />
> + <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
> + </request>
this above i wonder if this shoiuld be done this way. does it not expose too
much about an output? what happens when the output changes its colorspace?
imagine it has software controls where it can chnage its mapping or hardware
buttons etc.? shouldnt we just have a list of colorspaces available (that may
change at any time so some kind of event indicating a change would be needed)?
> + <request name="srgb_colorspace">
> + <description summary="tell the client what blending space is used">
> + This request returns a zwp_colorspace_1 object for the sRGB color
> + space. The sRGB color space is initially attached to all surfaces.
> + </description>
> + <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
> + </request>
ok - so srgb is default as it implicitly is now. but is this necessary? if no
actual blending takes place isn't this moot? any surface with a buffer with
alpha i don't think is going to get this fussy...
> + <request name="blending_colorspace">
> + <description summary="tell the client what blending space is used">
> + This request returns a zwp_colorspace_v1 object for the blending
> color
> + space of the compositor. All surfaces are converted by the compositor
> + to the blending color space before the blending operations. Once the
> + blending is performed, a further color conversion to the output color
> + spaces is carried out by the compositor.
> + A client should render in the blending color space returned by this
> + request if it does any color conversion on its own. This allows the
> + compositor to skip the color conversion to the blending color space.
> + </description>
> + <arg name="id" type="new_id" interface="zwp_colorspace_v1" />
> + </request>
> +
> + <event name="output_colorspace_changed">
> + <description summary="tell the client what color space an output has">
> + This event will be sent when the color space of an output is changed.
> + </description>
> + <arg name="output" type="object" interface="wl_output" />
> + </event>
as above. should this be tied to an output at all? ok. so an event. great.
> + <enum name="error">
> + <entry name="invalid_profile" value="0"
> + summary="the passed icc data is invalid" />
> + </enum>
> + </interface>
> +
> + <interface name="zwp_colorspace_v1" version="1">
> + <description summary="represents a color space">
> + This interface represents a color space that can be attached to
> surfaces.
> + It is used by the zwp_color_management_v1 interface.
> + </description>
so... here is my question - shouldn't the colorspace be tired to a buffer? not
a surface? yes. i know. the surface "displays" the buffer... but the colorspace
is intrinsic to the buffer content... right?
> + <request name="destroy" type="destructor">
> + <description summary="destroys the zwp_colorspace_v1 object">
> + Informs the server that the client will not be using this protocol
> + object anymore.
> + </description>
> + </request>
> +
> + <request name="get_profile_fd">
> + <description summary="get a file descriptor to the profile data">
> + This request will cause a profile_fd event that returns a file
> + descriptor to the ICC profile data of this colorspace.
> + </description>
> + </request>
> +
> + <event name="profile_data">
> + <description summary="file descriptor to the profile data">
> + This event occurs after a get_profile_fd request and returns the file
> + descriptor to the ICC profile data of this colorspace.
> + </description>
> + <arg name="fd" type="fd" />
> + </event>
> + </interface>
> +</protocol>
> --
> 2.10.2
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the wayland-devel
mailing list