Use-case for CTRC background color?

[Carsten Haitzler (The Rasterman)]

On Fri, 16 Nov 2018 09:19:17 +0530 Harish Krupo <harish.krupo.kps at intel.com>
said:

> Hi,
> 
> This patch [1] introduces the background crtc color property. This
> property is available on some display controlers and allows setting a
> non-black colors for pixels not covered by any plane (or pixels covered
> by the transparent regions of higher planes). I would like to implement
> a userspace consumer of this propery in weston.
> The primary use case for this property is for compositors to set the
> background color. I am planning on implementing it as follows:
> * The desktop client would bind to the weston-desktop-shell protocol.
> * The weston-desktop-shell would have a wrapper for the wl_output
> object.
> * The client would create a wrapper for wl_output (maybe called
> weston_desktop_shell_output).
> * This output interface will have an event to advertise its capability
> to set the background color directly.
> * Once the capability is found and if the client wishes to set the
> background color, it would use the set_background_color request in the
> weston_desktop_shell_ouput interface to set the color by providing the
> r,g,b primaries.
> 
> I have not completely thought this through, so I am sure this is
> incomplete and will require modification. I would like to know your
> comments and suggestions on the above method (or even if we could use
> this property differently) before I begin the implementation.

this smells of race conditions to me. compositor can bring up an output long
before the client has seen it yet and made a decision as to its color, so
welcome to "flicker of color" violating "every frame is perfect".

this also does not seem to synchronise with other content a compositor might put
there itself like a background image to a desktop like weston does by default
for example, or to whatever surface may be being used as a background (now
multiple clients can fight over this background color that may be different to
the background surface and its content and thus not visually match), also
violating "every frame must be perfect". background color that would fill in
areas not covered by this background image IMHO are integral to the  shell
"feel" like the and thus should be part and parcel of that and that
client/surface exclusively, or be compositor internal and no client can play
with it.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com