Use-case for CTRC background color?

[Harish Krupo]

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

Thank you
Regards
Harish Krupo


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