[RFC wayland-protocols v3 1/1] unstable: add color management protocol

[Graeme Gill]

Sebastian Wick wrote:

> +<protocol name="color_management_unstable_v1">

> +  <interface name="zwp_color_manager_v1" version="1">

> +    <request name="get_color_management_surface">
> +      <description summary="create a color management surface from a wl_surface">
> +	This creates a new color zwp_color_management_surface object for the
> +	given wl_surface.
> +
> +	See the zwp_color_management_surface interface for more details.
> +      </description>
> +      <arg name="id" type="new_id" interface="zwp_color_management_surface_v1"/>
> +      <arg name="surface" type="object" interface="wl_surface"/>
> +    </request>

> +  <interface name="zwp_color_management_surface_v1" version="1">
> +    <description summary="set color management information of a surface">
> +	A zwp_color_management_surface allows the client to set the color space and
> +	HDR properties of a surface.
> +    </description>

> +    <request name="set_color_space">
> +      <description summary="set the color space">
> +	Set the color space of the underlying surface. The color space is double
> +	buffered, and will be applied at the time wl_surface.commit of the
> +	corresponding wl_surface is called.

Hi,
	source color space is not an attribute of a wl_surface though, it is an attribute
of a wl_buffer, the same as (implied) dpi and format. The compositor has to deal with a
mismatch in these attributes between a wl_buffer and an output frame buffert in the same
way: If the dpi's mismatch, the buffer has to be scaled. If the format's mismatch, the
pixel encoding has to be changed. If the colorspaces mismatch, the colorspace has to be
transformed.

Some formats (i.e. YCbCr) have different gamuts, and therefore might have different color
profiles that reflect differences in color handling due to the different gamuts sizes and
shapes. (A good compositor implementation would be forgiving in this regard though.)

Cheers,
	Graeme Gill.