[RFC wayland-protocols] Add the color-management protocol
Niels Ole Salscheider
niels_ole at salscheider-online.de
Mon Dec 19 09:07:31 UTC 2016
On Monday, 19 December 2016, 11:08:31 CET, Carsten Haitzler wrote:
> 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)?
I think this is useful information and some applications might want to know.
If the output color space changes the compositor will notify the applications
by the output_colorspace_changed event (if it knows about it).
I know that many professional screens have a hardware button to switch color
spaces. This is really useful right now because you can switch to sRGB for
normal desktop usage - otherwise the colors are much too saturated.
But I wish that you can just leave your screen in native/full all the time
with this protocol - the compositor will correct the colors for the normal
desktop applications but you still take advantage of the wide gamut when
viewing images or videos.
> > + <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...
I'm not sure what your point is. Don't you think that it can be useful to get
an sRGB colorspace object without creating one from an ICC profile?
> > + <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?
I'm not sure, I can see reasons for both. I thought about wl_buffer as the
storage while wl_surface contains transformations that have to be applied.
But the color profile is obviously tied to the pixel values.
> > + <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
>
> _______________________________________________
> 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