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: [PATCH wayland-protocols v3] Add alpha-compositing protocol
On 16/11/18 6:05 am, Derek Foreman wrote: This looks nice to me, and I have need of something like this. A couple of comments below. On 11/14/18 7:00 PM, Scott Anderson wrote: This protocol specifies a set of interfaces used to control the alpha compositing and blending of surface contents, based on the Chromium Wayland protocol of the same name [1]. Signed-off-by: Scott Anderson [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml --- Changes in v3: - Rename "blending" event to "blending_equation" - Add enum specifier to "blending_equation" event and "set_blending" request. - Fix typos Changes in v2: - Add additional "fromsource" blending equation used by [3] - Allow the server to advertise which blending equations it supports - Added a protocol error for using an unsupported equation - Added a protocol error for using an invalid alpha value - Added clarification about wl_surface.set_opaque_region - Added clarification about per-pixel alpha values Makefile.am | 1 + unstable/alpha-compositing/README | 5 + .../alpha-compositing-unstable-v1.xml | 175 ++ 3 files changed, 181 insertions(+) create mode 100644 unstable/alpha-compositing/README create mode 100644 unstable/alpha-compositing/alpha-compositing-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 6394e26..ac6c9f8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -21,6 +21,7 @@ unstable_protocols = \ unstable/xdg-output/xdg-output-unstable-v1.xml \ unstable/input-timestamps/input-timestamps-unstable-v1.xml \ unstable/xdg-decoration/xdg-decoration-unstable-v1.xml \ + unstable/alpha-compositing/alpha-compositing-unstable-v1.xml \ $(NULL) stable_protocols =\ diff --git a/unstable/alpha-compositing/README b/unstable/alpha-compositing/README new file mode 100644 index 000..5826967 --- /dev/null +++ b/unstable/alpha-compositing/README @@ -0,0 +1,5 @@ +Alpha compositing protocol + +Maintainers: +David Reveman +Alexandros Frantzis diff --git a/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml new file mode 100644 index 000..d3c41d5 --- /dev/null +++ b/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml @@ -0,0 +1,175 @@ + + + + +Copyright 2016 The Chromium Authors. +Copyright 2017-2018 Collabora Ltd +Copyright 2018 NXP + +Permission is hereby granted, free of charge, to any person obtaining a +copy of this software and associated documentation files (the "Software"), +to deal in the Software without restriction, including without limitation +the rights to use, copy, modify, merge, publish, distribute, sublicense, +and/or sell copies of the Software, and to permit persons to whom the +Software is furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice (including the next +paragraph) shall be included in all copies or substantial portions of the +Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +DEALINGS IN THE SOFTWARE. + + + +This protocol specifies a set of interfaces used to control the alpha +compositing and blending of surface contents. + +Warning! The protocol described in this file is experimental and backward +incompatible changes may be made. Backward compatible changes may be added +together with the corresponding interface version bump. Backward +incompatible changes are done by bumping the version number in the protocol +and interface names and resetting the interface version. Once the protocol +is to be declared stable, the 'z' prefix and the version number in the +protocol and interface names are removed and the interface version number is +reset. + + + + + The global interface exposing compositing and blending capabilities is + used to instantiate an interface extension for a wl_surface object. + This extended interface will then allow the client to specify the + blending equation and alpha value used for compositing the wl_surface. + + + + + + + + +Informs the server that the client will not be using this +protocol
Screen not displaying..
Hi, I have two UI applications App1 and App2. I created one more application called appMgr through which i am creating a layer. This AppMgr knows the surface ID of of app1 and App2. If I start App1 , App2 and AppMgr manually, AppMgr able to change the visibility of App1 and App2 and everything working as expected. If I start all as system service, AppMgr is able to switch visibility which we can see through "Layermanagercontrol get scene" command. But problem is that the screens of App2 is visible for 1 sec after that screens are not visible. That is showing blank screen only. ___ 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: [PATCH wayland-protocols v3] Add alpha-compositing protocol
> This protocol specifies a set of interfaces used to control the alpha > compositing and blending of surface contents, based on the Chromium > Wayland protocol of the same name [1]. > > Signed-off-by: Scott Anderson This version LGTM. Reviewed-by: Simon Ser Thanks! ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH wayland-protocols v3] Add alpha-compositing protocol
On Thursday, November 15, 2018 2:00 AM, Scott Anderson wrote: > > + > > + > > +This event advertises the blending equations that the server > > +supports. All the supported blending equations are advertised once > > +when the client binds to this interface. A roundtrip after binding > > +guarantees that the client has received all supported blending > > +equations. > > + > > +For the definition of the blending equations, see the > > +zwp_blending_v1.blending_equation enum. > > + > > +The server must always advertise the 'none' blending equation. > > Would it make sense to require the server to advertise 'none' last, so > clients can treat it as an end-of-list? I'm not a fan of this idea. If it is really needed, a "done" event would be better. However, the list is advertised once on bind and doesn't change, so I don't think this is necessary. Just making clients do a roundtrip should be enough (as it's done in other protocols like linux-dmabuf). ___ 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