Use-case for CTRC background color?

[Pekka Paalanen]

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

> 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.

Hi,

the problem is that Weston will always have an opaque framebuffer on
the primary plane, and that primary plane will always cover the whole
CRTC area, which means that there is never a chance for a CRTC
background color to show through. You will have to change that by
allowing the primary plane to be smaller that the CRTC area or to be
omitted completely. I would ignore the case of the primary plane
framebuffer having a non-opaque alpha channel at start, because if the
hardware supports that it will be easy to make it work, unlike letting
the primary plane be smaller or omitted which is where the real
benefits are (memory bandwidth savings).

How to make use of and how to control the CRTC background color is a
good question. Just like any other detail of display, I think there
should not be an explicit protocol, even private one, to set the color.
A public protocol would be fought over by multiple clients, and a
private protocol would only be useful for the single helper client (e.g.
weston-desktop-shell) while leaving other use cases unaccounted for
(fullscreen video playback with black or other colored bars).

Therefore I think the right approach to control the CRTC background
color is to integrate it as part of the scenegraph, and recognize it
from the scenegraph to be used automatically, just like we use overlay
planes today.

The most optimal way for a video player to add black (or other colored)
bars around a fullscreen video is to make a single-color surface behind
the video surface. The player should use the sub-surface protocol to
layer the surfaces. The optimal way to create a single-color surface of
an arbitrary size is to use a 1x1 pixel wl_shm buffer scaled up to the
needed size with wl_viewport.

Weston internally has a concept of a solid-color surface, but those can
only be created internally, never by clients. It would be good to have
Weston recognize client surfaces with a 1x1 buffer and turn those
internally into solid-color surfaces. Then, the scenegraph analysis in
the DRM-backend can attempt to promote solid-color surfaces into a CRTC
background color setting. Once this works, it no longer matters how
many surfaces are on an output or which client created them; if the
scenegraph implies that CRTC background color can be used, then it will
be used and it will always be correct.

weston-desktop-shell helper client can be modified to use single-color
surfaces itself, which will make the compositor use the CRTC background
color automatically whenever the hardware supports it. That way
weston-desktop-shell does not need to worry about whether the hardware
or compositor supports it, and it can always use the same logic to set
up the desktop background. If the wallpaper is smaller than the output,
then this will result in memory savings regardless of whether the CRTC
background color is supported. This change could actually be made
already without any support for CRTC background color in the
compositor, and it would already be useful.

> 
> [1] https://patchwork.freedesktop.org/series/50834/


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20181116/807a4aa5/attachment.sig>