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 <[email protected]> writes: > On Fri, 16 Nov 2018 09:19:17 +0530 > Harish Krupo <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
