[RFC wayland-protocols] Add the color-management protocol

[Kai-Uwe]

Am 20.12.2016 um 15:25 schrieb Daniel Stone:
> On 19 November 2016 at 16:29, Niels Ole Salscheider
> <niels_ole at salscheider-online.de> wrote:
>> +    <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>
> 
> This should probably take length + offset, and note explicitly whether
> it requires NULL termination or not, and how that relates to the size.
> Our experience with xkbcommon was that _not_ NULL-terminating was
> ideal.

Color spaces are binaries. So NULL-termination might not apply?

>> +    <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>
> 
> This might be a stupid question, but is the blending colourspace
> constant, or could it feasibly be changed if you had, e.g., outputs
> with different characteristics? I understand that blending in linear
> space is a must, but are there other considerations in play which
> could suggest multiple 'blending spaces' for a single compositor? (I
> would expect that if the blending space was to be constant across
> outputs, then it should also be statically derivable by clients,
> making this event redundant.)

PDF, SVG2 require handling of different blending color spaces. So the
interface appears to be useful.

>> +    <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>
> 
> If a client doesn't want its surfaces to be colour-corrected ... won't
> the compositor still convert into blending space and back (not
> necessarily a lossless operation), if blending is required?

Likely.

My concern is that input == output color space => NULL conversion is
flacky. A explicite opt out of color correction would be much appreciated.

Kai-Uwe