Use-case for CTRC background color?

Fri Nov 16 13:16:01 UTC 2018

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

> Hi Pekka,
> 
> Thanks for the in-depth and descriptive reply. I will begin
> understanding the code and start making changes. I will revert back to
> this mail if I have doubts. :)

Hi,

I just realized I forgot one major detail: the composited framebuffer.
Ideally the composited framebuffer, if the hardware allows the primary
plane to be smaller than the CRTC area, would have its size optimized
to what actually needs compositing. That is, the framebuffer should
avoid covering areas where the CRTC background color is exclusive.
Otherwise the CRTC background color is only optimal if compositing can
be completely bypassed.

I think it is ok ignore this for now, and concentrate on cases where
compositing is totally skipped and all visible views are assigned to
planes. For testing, you will need a fullscreen client that allows
compositing to be skipped. A fullscreen video player could be one, but
you could also modify weston-simple-egl to have a fullscreen
single-color background surface while the OpenGL scene is shown smaller.

weston-desktop-shell will not allow you to hit the composite bypass,
because it uses wl_shm buffers exclusively, and those cannot be
promoted to planes to avoid compositing. You either need an app that is
fullscreen and completely hides the weston-desktop-shell elements, or
the single-color background must be the only surface
weston-desktop-shell is showing (you can disable the panel in
weston.ini, maybe that's enough).

You can use the weston-debug tool to inspect the scenegraph and the
analysis at runtime. See weston --debug command line option.

Thanks,
pq

> Pekka Paalanen <ppaalanen at gmail.com> writes:
> 
> > 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/bad80980/attachment.sig>