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

[Berniyh]

• I am a proud developer and don't want to throw away code I wrote and know well in favor of something unknown

Remember kdm?

So I don't think that's such a big issue with KDE. If there were a complete solution fulfilling their needs, they would drop kwin. But there isn't.

[Berniyh]

how does one even arrive to this conclusion? weston is the official compositor of AGL, well libweston. I would say that due to this alone, weston is probably the most used compositor of all of wayland compositors. let alone WSL2, I know it's used in industrial uses, set top boxes etc.

Yeah and that's what is mainly designed for, according to the devs.
If you look at Linux desktop, the outcome would probably be different.

[rabcor]

And this is relevant to who?

Isn't weston just waylands completely meaningless reference compositor that doesn't even work right, and has every feature poorly implemented as shit, so badly so that not a single other compositor has bothered to adopt a single line of code from it?

[oiaohm]

Yeah and that's what is mainly designed for, according to the devs.
If you look at Linux desktop, the outcome would probably be different.

Its party how weston been designed is a factor. Developers did not just design it for embedded.

Isn't weston just waylands completely meaningless reference compositor that doesn't even work right, and has every feature poorly implemented as shit, so badly so that not a single other compositor has bothered to adopt a single line of code from it?

https://github.com/varmd/wayward

rabcor on the right track wrong reason. Weston was not really designed at first to be used in parts in other compositors. Weston was design on the idea you would use a shell .so library to alter weston.

rabcor if weston did not work right it would not be able to be used in Automotive and other uses. Yes Automotive and other common uses of Weston make there own .so shell library to make Weston appear how they want it to. The reality I could put 300+ pictures of Weston interfaces that all look absolutely different because they are all running different custom .so shells majority of these are closed source by the way. Remember Weston is MIT license so closed source usage is perfectly above board..

Weston is not meaning less. Notice how a lot of people say having to write a complete wayland compositor from scratch would be hard. Weston is design that you don't have to do this. Instead write a plugin library and that replaces what was a X11 Windows manager. Embedded users take full advantage of this.

Weston is also designed to be able to stack on top of other wayland compositors. Lets say you have a wayland application not working right on gnome/kde you can fire up weston and run the application being trouble inside this and see if it core Wayland protocol or something gnome/kde... has done. Yes the recent feature of being able to resize the weston window when stacked relates to this feature.

We have not seen any major investment in making a serous port of a X11 desktop windows manager to weston shell .so. But there have been hundreds to possible thousands of X11 embedded windows mangers mangers(that have been closed source for decades) ported weston shell .so.

How important is weston depends are you embedded or are you desktop. Weston is very important to embedded.

[Berniyh]

Developers did not just design it for embedded.

No, but it's where the main users are and hence the focus is a bit more in that direction rather than the Linux desktop.

[Quackdoc]

And this is relevant to who?

Isn't weston just waylands completely meaningless reference compositor that doesn't even work right, and has every feature poorly implemented as shit, so badly so that not a single other compositor has bothered to adopt a single line of code from it?

not at all, weston/libweston is one of, if not the most used compositors, it's used in automotive, industry, tv set top boxes and tvs themsleves, and as for direct use of weston, there is some there too, with it being the most reccomended for nested wayland use case. however it is also one of the recommended methods for getting a direct "waydroid only" session (essentially mimics direct android). I personally use it for kiosk devices since it serves that roll excellently.

[ChrisLane]

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

[oiaohm]

No, but it's where the main users are and hence the focus is a bit more in that direction rather than the Linux desktop.

One of the reasons why X.org X11 server development is not as well staffed with programmers as it use to be is embedded stopping using it.

One of the realities here is embedded instances out number desktop instances by over 20 to 1. Yes desktop instances are all Linux, windows and mac os instances combined.

Hard one is for development ideal you want the embedded users involved due to the amount of resources they have to throw at problems. Big problem is always when you get the embedded involved that will always out number everyone else.

This is a problem lets say wlroots started being used lot in embedded would not need much of a percentage of embedded for the embedded users to come the dominate users.

This is just one of those tricky things how to get embedded developers and desktop developers to get along if they can the outcome long term will be better. The embedded have more resources for testing and code maintenance..

Seeing something built for embedded that is lean and mean normally gets desktop users to go this can never be suitable without in fact looking deeper. Lot of embedded use cases require very complex interfaces so a lean and mean embedded world is using is normally extendable to be insanely feature rich. Of course how it can be extended sometimes takes looking for it.

[andyprough]

how does one even arrive to this conclusion? weston is the official compositor of AGL, well libweston. I would say that due to this alone, weston is probably the most used compositor of all of wayland compositors. let alone WSL2, I know it's used in industrial uses, set top boxes etc.

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.

[guglovich]

- A backed-vnc backend has been added to provide remote desktop access, performing functions similar to backend-rpd. The VNC protocol is implemented with aml and neatvnc. It supports user authentication and communication channel encryption (TLS).

- Support has been added for writeback connectors, used to create screenshots.

- External library libdisplay-info is used for EDID metadata parsing.

- Preliminary support for multi-monitor systems (multi-head) was added in the backend-rdp remote access backend.

- The backend-headless backend, designed to run on systems without a display, has added support for the output decoration used to test the color-lcms plugin.

- Declared deprecated and disabled by default the launcher-logind component, instead of which it is recommended to use launcher-libseat, which also supports logind.

- In libweston/desktop (libweston-desktop), support for a wait state applied during the stage before the output buffer is attached to the client, which can be used to start the client from the beginning in full-screen mode, for example.

- The weston-output-capture protocol has been implemented, which is designed to take screenshots and is a more functional replacement for the old weston-screenshooter protocol.

- The libweston library implemented support for PAM user authentication and added support for version 4 of the wl_output programming interface.

- A simplified backend, shell and renderer selection mode has been added to the compositor process, allowing the syntax "--backend=headless", "--shell=foo" and "--renderer=gl|pixman" instead of "--backend=headless-backend.so", "--shell=foo-shell.so" and "--renderer=gl-renderer.so".

- The simple-egl client now has support for the fractional-scale protocol, which allows the use of non-integer scale values, and has implemented a vertical panel rendering mode.

- The ivi-shell, a shell for car infotainment systems, has implemented keyboard input focus activation for the xdg-shell surface, implemented similarly to desktop-shell and kiosk-shell input activation.

- The libweston-desktop shared library has been integrated with the libweston library, linking applications with libweston will allow access to all the features previously provided by libweston-desktop.