Re: Use-case for CTRC background color?
On Fri, 16 Nov 2018 18:03:18 +0530 Harish Krupo 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 writes: > > > On Fri, 16 Nov 2018 09:19:17 +0530 > > Harish Krupo 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
Re: Use-case for CTRC background color?
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 writes: > On Fri, 16 Nov 2018 09:19:17 +0530 > Harish Krupo 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 wayland-devel@lists.freedesktop.org
Re: Use-case for CTRC background color?
On Fri, 16 Nov 2018 09:19:17 +0530 Harish Krupo 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
Re: Use-case for CTRC background color?
Ucan, Emre (ADITG/ESB) writes: > Hi Harish, > > Then, this would only work for desktop-shell. Furthermore, I cannot set > different background colors to different outputs. > > Also my suggestion is simpler to implement. > Yes, that indeed is easier to implement. Unfortunately, the desktop shell would fall back to setting 0x even if we were to comment out background-image and background-color in the config. This would obscure our color because the background-color set by the desktop shell would fill the complete display resolution on a plane. I see 2 options: * We can make desktop-shell.c skip the setting of the background color if a color is provided for an output. Unfortunately, the desktop shell sets the color for background and not per output. * The other option would be that we ignore desktop shell's background when the color is provided in the output. But here we cannot identify if the client set a wallpaper or a plain color. With the above issues, I don't think we can go for this implementation. Please correct me if I have got something wrong. Thank you Regards Harish Krupo ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Use-case for CTRC background color?
On Fri, 16 Nov 2018 09:19:17 +0530 Harish Krupo said: > 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. this smells of race conditions to me. compositor can bring up an output long before the client has seen it yet and made a decision as to its color, so welcome to "flicker of color" violating "every frame is perfect". this also does not seem to synchronise with other content a compositor might put there itself like a background image to a desktop like weston does by default for example, or to whatever surface may be being used as a background (now multiple clients can fight over this background color that may be different to the background surface and its content and thus not visually match), also violating "every frame must be perfect". background color that would fill in areas not covered by this background image IMHO are integral to the shell "feel" like the and thus should be part and parcel of that and that client/surface exclusively, or be compositor internal and no client can play with it. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Use-case for CTRC background color?
Hi Emre, Thanks for replying. Ucan, Emre (ADITG/ESB) writes: > Hi, > > Clients should not control a property of a wl_output directly. > > You can add a new property to the weston-config for output section, so that > weston can enable a specific color for an output at startup. Sorry, I should have been specific. The user would set the color here [1]. The desktop client would then check if the output (output wrapper) has advertised the background color capability. If so, it would then set the color using a different request as compared the the set_background request which already exists in weston-desktop-shell. This interface would take R, G, B colors instead of a buffer. Thank you Regards Harish Krupo [1] https://gitlab.freedesktop.org/wayland/weston/blob/master/weston.ini.in#L10 >> -Original Message- >> From: wayland-devel On >> Behalf Of Harish Krupo >> Sent: Freitag, 16. November 2018 04:57 >> To: wayland-devel@lists.freedesktop.org >> Cc: pekka.paala...@collabora.co.uk; dani...@collabora.com >> Subject: Use-case for CTRC background color? >> >> 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. >> >> Thank you >> Regards >> Harish Krupo >> >> [1] https://patchwork.freedesktop.org/series/50834/ >> ___ >> wayland-devel mailing list >> wayland-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
RE: Use-case for CTRC background color?
Hi, Clients should not control a property of a wl_output directly. You can add a new property to the weston-config for output section, so that weston can enable a specific color for an output at startup. Best regards Emre Ucan Engineering Software Base (ADITG/ESB) Tel. +49 5121 49 6937 > -Original Message- > From: wayland-devel On > Behalf Of Harish Krupo > Sent: Freitag, 16. November 2018 04:57 > To: wayland-devel@lists.freedesktop.org > Cc: pekka.paala...@collabora.co.uk; dani...@collabora.com > Subject: Use-case for CTRC background color? > > 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. > > Thank you > Regards > Harish Krupo > > [1] https://patchwork.freedesktop.org/series/50834/ > ___ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Use-case for CTRC background color?
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. Thank you Regards Harish Krupo [1] https://patchwork.freedesktop.org/series/50834/ ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
