Use-case for CTRC background color?

Discussion:

Harish Krupo

2018-11-16 03:49:17 UTC

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/

Ucan, Emre (ADITG/ESB)

2018-11-16 08:29:43 UTC

Permalink

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-----
Behalf Of Harish Krupo
Sent: Freitag, 16. November 2018 04:57
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
* 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
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Harish Krupo

2018-11-16 08:31:06 UTC

Permalink

Hi Emre,

Thanks for replying.

Post by Ucan, Emre (ADITG/ESB)
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

Post by Ucan, Emre (ADITG/ESB)

Ucan, Emre (ADITG/ESB)

2018-11-16 08:54:26 UTC

Permalink

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.

Best regards

Emre Ucan
Engineering Software Base (ADITG/ESB)

Tel. +49 5121 49 6937

-----Original Message-----
Sent: Freitag, 16. November 2018 09:39
Subject: Re: Use-case for CTRC background color?
Hi Emre,
Thanks for replying.

Post by Ucan, Emre (ADITG/ESB)
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

Post by Ucan, Emre (ADITG/ESB)

-----Original Message-----

Post by Ucan, Emre (ADITG/ESB)

Behalf Of Harish Krupo
Sent: Freitag, 16. November 2018 04:57
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
* 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
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Harish Krupo

2018-11-16 09:30:09 UTC

Permalink

Post by Ucan, Emre (ADITG/ESB)
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 0x00000000 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

Carsten Haitzler (The Rasterman)

2018-11-16 09:09:53 UTC

Permalink

Post by Harish Krupo
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
* 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 - ***@rasterman.com

Pekka Paalanen

2018-11-16 11:51:47 UTC

Permalink

On Fri, 16 Nov 2018 09:19:17 +0530

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.

Post by Harish Krupo
[1] https://patchwork.freedesktop.org/series/50834/

Thanks,
pq

Harish Krupo

2018-11-16 12:33:18 UTC

Permalink

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

Post by Pekka Paalanen
On Fri, 16 Nov 2018 09:19:17 +0530

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.

Post by Harish Krupo
[1] https://patchwork.freedesktop.org/series/50834/

Thanks,
pq

Pekka Paalanen

2018-11-16 13:16:01 UTC

Permalink

On Fri, 16 Nov 2018 18:03:18 +0530

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

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

Post by Harish Krupo

Post by Pekka Paalanen
On Fri, 16 Nov 2018 09:19:17 +0530

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.

Post by Harish Krupo
[1] https://patchwork.freedesktop.org/series/50834/

Thanks,
pq