[RFC wayland-protocols] Add the color-management protocol
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Tue Dec 20 01:45:30 UTC 2016
On Mon, 19 Dec 2016 10:07:31 +0100 Niels Ole Salscheider
<niels_ole at salscheider-online.de> said:
> 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).
what if the display can do different color profiles for different regions? my
example is yuv colorspace. 601 vs 709 etc. actually can be assigned per hw
plane... they are different colorspaces ... :)
> 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.
ultimately this is the right thing. a compositor would color correct all
content eg srgb by default as with most content then high gammut content can
be "let loose".
but hear me out. i have been thinking. shouldnt the compositor send a list of
colorspaces per SURFACE? if the surface moves from screen to screen it may
adjust that list of colorspaces? if a surface spans multiple screens it may
list all colorspaces that the surface spans?
> > > + <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.
well this is up for debate... to my mind it belongs to the buffer imho...
but...?
> > > + <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
>
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the wayland-devel
mailing list