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

[Graeme Gill]

Pekka Paalanen wrote:

Hi,

> they are analogues. They are not transforms, instead they describe
> properties of the image. Buffer scale is not a command for the
> compositor scale the image, instead it describes the scale of the image
> so that a compositor can present it in a suitable way anywhere. One
> could say buffer scale is only half of a transform, just like a color
> profile; source state.

OK.

> The combining cannot be fixed at commit. It happens on composition.

So I guess I'm wrong in understanding that commit triggers composition ?

<https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Surface>:

"Once the client has finished writing pixels, it 'commits' the buffer; this permits the
compositor to access the buffer and read the pixels. When the compositor is finished, it
releases the buffer back to the client."

So how does this actually work ? (Is there documentation somewhere ?)

> Let's consider a case where a client has committed an image (wl_buffer +
> color properties etc.). That image is now in the wl_surface. The
> wl_surface gets shown on output 1, for that the compositor creates the
> necessary device link transformation and uses it. Then, the wl_surface
> gets moved by the compositor and shown on output 2. The compositor
> needs to create a new different device link transformation to do the
> color mapping. Therefore the device link transformation cannot be fixed
> at commit time - not even if you generated one for each output, because
> a new output could be hotplugged later.

And I wasn't assuming so, but I was assuming commit = compose, and that
the color transform would be determined at composition time. What
concerns me is that a surface doesn't represent the pixel value state
without explicit coordination from the client. This seems like
a poor model of how things actually are, and I'd really like
to get this right.

> Right now there is no Wayland protocol object that would directly
> represent "a frame of content" with all the properties it may have. It
> could have been useful, but maybe not avoid the need for
> wl_surface.commit because the set of needed state varies and new
> extensions will need a point to hook their state updates to.

Sure. But a color profile is not a property that is divorced
from the pixel values - it is intimately tied to them in a similar
way to pixel encoding, width & height or stride. Yet these are not
sent to the surface as separate values, which would be the case if
a wl_buffer was just a pointer to a chunk of shared memory.

[ If color profile is a property of the wl_surface, how does the
  screencopy protocol communicate the colorspace of the wl_buffer
  it returns ? It couldn't really return a wl_surface could it ? ]

> A
> wl_buffer is only a part of content - more of an artifact of memory
> management, and wl_surface is more than just the content... or is it?

I think I understand, but it seems that a wl_buffer is not quite
a chunk of memory, since it has graphic attributes as part of it,
and not quite a complete description of what the pixels mean.

> Not having a Wayland object for something does not prevent a compositor
> from using an internal object for it. E.g. weston has struct
> weston_surface_state.

Right. But it's a problem if one needs to reference that object
in the protocol so that the color profile can be set or retrieved.

> The EGL problem is in the client side: a client cannot attach anything
> to a wl_buffer if it uses EGL Wayland platform, because it cannot get
> to the wl_buffer at all.

Right, but the server would attach the color profile to the wl_buffer
on the clients behalf.

So:

1) Is it reasonable to tag a wl_buffer with the color profile to make it
   a more complete description of the pixel values, and implement a more
   natural model of how things are ?

2) How would this be implemented, since (AFAIK) the server wl_buffer structure
   is assumed to be private to the back end implementation ?
   (That's something I have a couple more more ideas about though.)

Thanks,
	Graeme Gill.