The description for mate-wayland-session seems to suggest that the Wayland implementation for the MATE Desktop is X11-based.
Is this correct?
Why did I think it would be GTK-based as for the rest of MATE?
[edit]
Or am I completely unaware of the parallel co-existence and interdependency of GTK and X11 for the current MATE Desktop build?
I thought it was just a side-by-side installation of the 2 APIs to accomodate various applications built on top of one or the other API.
They were built with GTK3 and with an X11 server (backend) in mind. What has changed is that they now accomodate wayland backends, too.
As far as I understood from the link, X11 (Xwayland) here is a compatibility layer between X11-based applications and the wayland backend (Wayfire).
The whole (or most?) of MATE desktop, and wayland apps, will run directly on the wayland-backend
Anybody know if there is anything like the following "map" that offers a similar "comprehensive" view of the "wrappers" that provide all the remaining Linux functionality that surrounds the Kernel?
Also, is there a diagram similar to Figure 1 or Figure 4 which is provided by the FLUSP (University of SĂŁo Paulo Free/Libre/Open Source Software) ?
What confuses me about Wayland are the many published references (such as this one from AMD) which show Wayland as interacting directly with the kernel, rather than acting as a layer before/after the screen display "engine".
But then I came across this diagram on Wikipedia's page for Wayland, and also this one, which seem to clarify a some, but still seem to leave me a bit unsettled.
I guess I am struggling with the idea that, as Wayland is attempting to implement, everything is going thru the Kernel, instead of being layers disconnected from the Kernel, as was the case with X11. And if such is the case, why is there any effort being applied to things like "XWayland" ?
I am just a bit confused, or as I already said, just "ignorant" of the inner workings which, to be honest, maybe I shouldn't try to understand! (That's the senior in me talking now. 
)
All I know is that XWayland is an implementation of an X server so that applications that specifically require one can still be displayed. To me that means it sits 'on top' of a Wayland (compositor) and translates any call made to an X server into something that Wayland can handle.
I think you are looking for linux architecture diagram. E.g. something like this:
or like that:
You can see that any program/application may, can and actually must use kernel aka system calls. System calls are often disguised by a wrapper, say, standard C library. There is nothing wrong in the (inevitable) fact that an application use kernel one way or another. The only thing with Wayland & X11 is that they are competing to provide a kind of service for applications intended to provide GUI.
Here is layered structure of software services:
user -> my_gui_app -> GTK library -> X11 display server -> kernel.
Hopefully these notes may help to fight a confusion.
Just in order to give Wayland extra X11-like interface so that programs written for X11 environment could be executed in Wayland.
Something like this ? > https://www.linuxpro.com.br/images/wayland-arch.png
Or the one below ?: Wayland (protocol) - Wikipedia
Thank you, Thom.
I guess the first of those two diagrams is the cleanest representation of the Wayland-based future showing where and how the "X server" (I thought that was the "X Client" in X-Window terminology ) will exist and interact within that new environment.
But to get back to my original question, the answers offered by the Community aren't really touching on what maybe a slight re-phrasing of the question would focus on:
Did Wayland evolve from, or adopt as part of its own core code, elements of X11 code libraries,
or
did it evolve from a blank slate into a new framework, owing none of its capabilities to the pre-existing X11 code?
It did evolve from a blank slate.
The how and why is explained in this video lecture by Daniel Stone ( Xorg & Wayland dev ) :
There seems to be a fundamental confusion here, and I’m replying because the “solution” didn’t clarify it for you. X11 is a protocol and display server. It talks to your monitor and draws primitives that widget toolkits use. GTK is a toolkit for writing applications; it draws all the components inside a window, like lists, frames, text boxes, choosers, etc. GTK also needs some kind of display server to display on… it used to be X11, now it is wayland. X11 and GTK are two different things, that work together to show you graphical interfaces.
Wayland is analogous to X11 (even if what they do under the hood is fundamentally different)
GTK is analogous to QT (what KDE and many other apps use)… GTK and QT apps can display on X11 or wayland.
Apps have to be written for either X11 or wayland. For decades, the traditional display server has been X11, so Linux desktops have historically been written for it. In the last few years, both GNOME and KDE have been re-jiggered to work on wayland (or X11, though I think they’re fixing to rip out the X11 code, or they want to anyway.)
XWayland is a program that allows X11 applications (whether QT, GTK, or any other toolkit) that have not been designed for wayland, to run on a wayland sesstion.
I’m almost certain that Linux Mint (whose desktop, MATE, uses GTK, by the way) does not use wayland by default. Someone is working on a wayland compositor for MATE (wayfire.) The link you gave, mate-wayland-session, gives people who want to, to run a session of MATE with a wayland backend (wayfire.) It probably is not stable or as featureful as MATE on X11.
Hi, @mercster and welcome to the Ubuntu MATE Community!
A similar situation is PipeWire and how audio has been evolving on Linux. Regarding the layers of how audio hardware is linked up to an application:
PulseAudio has its limitations and lots of people were looking to update it - but, just like X11 - it was deemed easier to start fresh with significant changes to the model. Enter PipeWire.
By the way, PulseAudio wasn't the only game in town. JACK existed as well for users who were doing studio music or otherwise needed lower-latency audio pipeline. But it too had limits.
Now we have PipeWire which provides a whole new API that applications could use to send or receive audio ... but existing applications cant use it directly. Whay to do?
Well, PipeWire comes with an implementation of a PulseAudio server "on top". This is analogous to XWayland, which is a X11 server that runs on top of a Wayland compositor. In the audio realm; this means that applications that expect to use a PulseAudio server can still use it - even if its not the usual PulseAudio server that we all know.
Applications (and libraries) are now slowly picking up using PipeWire audio directly. This is roughly what we're seeing with Wayland, too. Many applications that have used X11 directly are still able to run with a Wayland compositor (thanks to XWayland) but over time they're being migrated to use Wayland itself (or equivalent mechanisms).
There are complicated examples where its not so simple as "I can just run an X11 application on XWayland" because some features are limited even under XWayland. OBS Studio is an example because it used X11 for application capture and on Wayland this prevented capturing anything that wasn't also launched with XWayland (i.e. Wayland native apps). OBS now uses PipeWire to do its application capture on Wayland and all is well.
Anyway - thats how I understand the story, and learning about the story of audio on Linux has helped me understand a little what is going on with compositors.
There are a lot of parallels regarding who has been driving both PipeWire and Wayland, and the community and user reaction. PipeWire was met with a lot of skepticism (and feral forum abuse) but it now has broad acceptance amongst both users and developers on Linux.
I certainly enjoy having fewer xruns in my audio (pops or stutters) alongside better latency. From what little I understand - I'm expecting some similar benefits with Wayland regarding frame delivery.
