HDR support in Wayland/Weston

[Adam Jackson]

On Tue, 2019-01-15 at 11:30 +0200, Pekka Paalanen wrote:
> On Tue, 15 Jan 2019 13:47:07 +1100
> Graeme Gill <graeme2 at argyllcms.com> wrote:
> 
> > If done in the composer, it would need to render the graphic elements to
> > the output DPI / convert the source colorspace to the output colorspace.
> > But the composer would need the code to do rendering / convert colorspaces
> > (as well as being told what the graphic elements / source colorspace is),
> > and this is not the role Wayland has - that's the responsibility of the
> > client, so instead Wayland makes it possible for the client to know what DPI
> > it is rendering to. The analogous facility for CM is for the client to know
> > what output colorspace it is rendering for.
> 
> Yes and no. Yes, we do and should let clients know what kind of outputs
> their contents will be shown on. However, we will in any case need the
> compositor to be able to do the full and correct conversion from what
> ever the client has submitted to what is correct for a specific output,
> because nothing guarantees that those two would always match.

This isn't necessarily true. The server is free to just draw a black
rectangle (or nothing) instead if the image doesn't match the target
colorspace. If you want to handle the case of cloned outputs or
crossing output borders, let the client attach one image per output
colorspace if it wants, and let the server send the client events to
indicate when it should start or stop drawing to a particular
colorspace. You need that complexity in the client's renderer anyway,
why add it to the server's?

> One wl_surface on multiple outputs is an obvious case where one buffer
> rendered by a client cannot match all the outputs it is shown on. The
> other case is transitions between outputs, where we cannot have the
> compositor wait for the client to re-draw with new color parameters.

Honestly I think of this as an implementation issue? If we take the
above multiple-images approach, then if it's my compositor I just omit
drawing actors onto any output where there isn't an image for that
colorspace, because I am comfortable saying any further latency is the
client's renderer's problem. Someone else's compositor might try to
bend the existing image to the output colorspace until the client has
caught up, believing close-but-wrong color is better than visible
absence of color. I could see an argument for either implementation
depending on the environment, and I don't really see why the protocol
spec should require one or the other.

- ajax