On Fri, 16 Nov 2018 09:19:17 +0530 Harish Krupo <harish.krupo....@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
pgp34oEnExroi.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel