Wayland's Weston 12.0 Released With Multi-GPU Support, PipeWire Backend, Tearing Control

[MorrisS.]

Would be useful to understand what be the best compositor which allows Wayland to be better integrated and implemented. What about Android compositor for Wayland?
About the last question I got this article: https://www.gfxstrand.net/faith/proj...yland-android/

[Quackdoc]

Would be useful to understand what be the best compositor which allows Wayland to be better integrated and implemented. What about Android compositor for Wayland?
About the last question I got this article: https://www.gfxstrand.net/faith/proj...yland-android/

someone was working on getting smithay working for android but that project seems stalled, it was called waylovely or something like that

[Etherman]

What does a PipeWire back-end do in the context of a Wayland compositor?

It's for screen capture in a secure way. As opposed to X11 where every app has unrestricted access to all of screen.

[oiaohm]

Would be useful to understand what be the best compositor which allows Wayland to be better integrated and implemented. What about Android compositor for Wayland?
About the last question I got this article:

https://github.com/termux/termux-x11

https://waydro.id/

termux-x11 uses cutdown wayland compositor on top of android compositor to run Xwayland on android.
waydroid uses SurfaceFlinger android compositor to run on top of Wayland something google has for chromebooks so not using out of tree code.

SurfaceFlinger the android compositor has it own protocol yes the SurfaceFlinger protocol. Could support be added to Surfaceflinger for wayland protocol there is no particular reason why not other than SurfaceFlinger protocol being a even more limited protocol than Wayland protocol that does make it tricky to implement full wayland protocol on top of Android.

Newer android devices kernels for graphics use normal KMS/DRM .

https://www.collabora.com/news-and-blog/blog/2018/12/17/a-dream-come-true-android-finally-using-drm/kms/

That started 2018 this newer that using KMS/DRM you don't need the libhybris. Libhybris is need if you are using hardware that using android platform unique drivers. Even google is pushing vendors away from using android platform unique graphics instead wanting the drivers mainlined into the Linux kernels too many crashes and security problems caused by those android platform unique graphics drivers due to not validated code. I remember impressive one by samsung where /dev/mem was removed so they just made their own android platform unique driver that put that back totally security flawed so their android userspace graphics driver would keep on working..
https://lwn.net/Articles/529392/ Yes I know that was 2012 but it was one the things that got google asking the serous question is android unique graphics drivers even a good idea. Google final answer is android unique graphics drivers that don't have to be peer reviewed was a bad idea resulting in the pressure to move to KMS/DRM and mainlining the graphics drivers.

Basically the reason for libhybris is not going to be their on newer android hardware.

[curfew]

Has anyone rounded up any stats on the usage of Gnome's mutter and KDE's Kwin implementations of the wayland spec? If what you are saying is true, that WSL2 makes Weston the most used wayland compositor, then the usage of mutter and Kwin-wayland must be infinitesimally small.

Well what do you expect? Linux on the desktop is close to non-existent. Linux is probably much more popular in embedded systems. Not all non-desktop use cases are just about servers and CLI apps...

[MorrisS.]

Would be possible to replace Kwin with Weston compositor on its own desktop environment, or is it too hard to apply Weston without compromise the whole system?

[oiaohm]

Would be possible to replace Kwin with Weston compositor on its own desktop environment, or is it too hard to apply Weston without compromise the whole system?

In theory it possible. https://github.com/varmd/wayward is working on using Weston desktop shell feature.

Weston at this stage does not support KDE restart feature.

https://invent.kde.org/plasma/kwin/-/wikis/Restarting

Yes the means to leave the wayland socket open after compositor stops and then pick it up again so Wayland application don't terminate when you change wayland compositors.

The issue is really someone putting in the developer time to make the process work. Yes done right in theory you could change between kwin/plasma and something weston + desktop shell + desktop environment at will with all running applications remaining. Yes in theory be able to switch between both at will.

The question is it possible to find a developer willing to do the work.

[MorrisS.]

In theory it possible. https://github.com/varmd/wayward is working on using Weston desktop shell feature.

Weston at this stage does not support KDE restart feature.

https://invent.kde.org/plasma/kwin/-/wikis/Restarting

Yes the means to leave the wayland socket open after compositor stops and then pick it up again so Wayland application don't terminate when you change wayland compositors.

The issue is really someone putting in the developer time to make the process work. Yes done right in theory you could change between kwin/plasma and something weston + desktop shell + desktop environment at will with all running applications remaining. Yes in theory be able to switch between both at will.

The question is it possible to find a developer willing to do the work.

Many thanks for your reply. What is the process to follow in order to replace Weston compositor to Kwin compositor?

[oiaohm]

Many thanks for your reply. What is the process to follow in order to replace Weston compositor to Kwin compositor?

There are two things that cause it not to be able to be done at the moment..

Weston not support wayland socket stay alive. This means the only way to change to weston to kwin or back is logout and login again. Yes this socket stay alive feature is how wayland kwin can crash and be restarted by systemd and the user might see some screen flicker and that it. Since there is not another wayland compositor with this feature at this stage switching between them has not been tested. Developer behind kwin wayland means to restart long term plan include means to switch with other compositors when they support the feature. This also means on the fly compositors having different wayland feature support and running wayland applications tolerating the change is not that tested. Yes there has a been a little kwin to kwin testing where new kwin has new wayland feature or switching back to old kwin with feature missing.

Lack of a KDE plasma compatible desktop shell .so for Weston to allow plasma to talk to Weston like it talks to kwin. Without this changing to weston you would have to accept taking down KDE plamsa and kwin at the same time. wayward has done there own alternative to item like plamsa. Yes changing to a complete different desktop environment live is kind of jarring..

As I said in theory it possible. But for it to be possible developer time is need on the weston side.

Weston was designed that it could be everyone Wayland compositor with its plugin system but that only works if plugin exists. KDE developer doing the restart work only has so many hours to put into it. Yes lots of work thinking its dealing with every project using unique toolkit individually to make it work with KDE kwin restart.

This is case of not enough developers working on this problem.

kwin wayland means to restart and so replacing it self with it self and have all applications remain is still a unique feature of kwin at this stage. Yes it on gnome mutter roadmap but they have not implement yet and its not in weston either.. So even without the means to switch the compositor to make Wayland environment resilient to Wayland compositor crashes you want this feature.