The KDE login screen offers three display options: Plasma, Plasma (Wayland), and Plasma (Full Wayland). What’s the difference between Wayland and Full Wayland? Wayland runs fine on my machine, but Full Wayland causes havoc with the display. Thanks for any insight that you can provide.
Was wondering about that, too.
I see a couple people online guess the same as me…
A full implementation of Wayland eliminates the X server component and implements through the use of sockets.
There is another implementation of Wayland that implements through its own X server, its primary purpose is to support apps that want to communicate with Desktop graphics and expect to access an X server… This is because the standard Xorg X server deploys this way.
An example of how this was important in the past is that LEAP 42.x required a Wayland X server to support VNC, but today TigerVNC deploys a number of different ways, and can be by sockets without an X server.
Maybe your current display is an installed proprietary driver that might require User mode management that requires the X server API?
So,
Maybe this implementation of Wayland through its own X server is “partial?”
Would be nice if the Wayland people published some kind of official explanation or definition, but so far it appears no search engine is picking that up if it exists.
TSU
Full Wayland causes problems.
You can look in “/usr/share/wayland-sessions” to see the difference. The line containing “Exec” is the important one. For Full Wayland, there are a couple of additional environment settings:
GDK_BACKEND=wayland QT_QPA_PLATFORM=wayland
I am still using X11. Wayland works, but Full Wayland causes some problems. It’s been a while since I last tried, so I don’t remember what those problems. I seem to recall that “firefox” misbehaved with Full Wayland, but perhaps that has been fixed by now.
Full Wayland uses native Wayland implementations of the GTK and QT. Where as non-full Wayland uses the X11 GTK and QT via XWayland which runs as a client of Wayland.
From https://wayland.freedesktop.org/docs/html/ch05.htmlXwayland is a complete X11 server, just like Xorg is, but instead of driving the displays and opening input devices, it acts as a Wayland client.
XWayland allows any X11 app to run without change on Wayland. So in non-full Wayland, Plasma is running on X11 only. Presumably there may be a price to pay for going through some extra layering.
Bugs in the native Wayland implementations of GTK and/or QT may mean that some applications don’t work quite right. For example, I was trying to use firefox in full wayland earlier this week, but I gave up and logged into non-full wayland (on an nvidia GPU).
Thank you for the enlightening replies. I am running the open source nouveau and mesa drivers. I appreciate the intermediate Wayland implementation as everything works fine in it. I don’t really notice any performance difference between Wayland and Full Wayland, but it’s hard to tell with the multitude of visual anomalies with Full. I’m running the intermediate approach, which is working great for me.
Thank you very much for that reference.
Unless I misread, I’m revising my conception of Wayland a bit…
I think that the reference says that XWayland doesn’t actually translate Xorg X server calls to a full Wayland backend, but passes to a Wayland compositor embedded within the Xorg X server… This would be an clear way for clients to communicate, since it’s with a “real” Xorg X server, but perhaps not obvious to the client is to a Wayland instead of some other compositor.
Although XWayland might be thought of as a client or intermediate translation device, it’s a client to a component embedded within itself… the Wayland compositor.
I had thought that there was a real and full Wayland backend to XWayland, which apparently is not the case.
Backing up a bit in the reference documentation, various objectives and architectural design are described, that recently a number of libraries that used to be included in the Xorg X server like fonts have now been moved into the kernel, plus some functionality so that a current main objective is to “distill”" the functionality of X rendering separate from what is provided elsewhere like in the kernel.
And, as I described “Full Wayland” does communicate with its clients by Unix streaming sockets without an X server. In this implementation, there is an expectation of performance and efficiency improvements but of course is radically different when the X server is removed. XWayland performance might be problematic since the architecture is same as any other Xorg Server running a different compositor, but perhaps there can be a benefit in the Wayland compositor itself.
TSU
On a careful read of the reference, it was incorrect of me to state that *Plasma is running on X11 only. *I think it would be more correct to state that that under non-full Wayland, the KDE applications are running on XWayland, but for both full/non-full scenarios the version of KWin (KDE window management and compositing) is one that has been written to run on Wayland directly.
KWin has to work directly with Wayland so it can manage all windows (native Wayland windows and X11/XWayland windows). I don’t think the Wayland version of KWin has to be concerned much whether a window is a Wayland or X11 Window, this KWin can just interact solely with Wayland. It’s Wayland that keeps track of which windows are actually Wayland or X11 windows. For X11 windows Wayland has a XWM component that passes the X11 management back up to XWayland.
The work involved in creating Wayland KWin is described here: KWin/Wayland - KDE Community Wiki.
In summary:
- Full Wayland: Wayland KWin, Wayland applications (via Wayland GTK and Wayland Qt).
- Non-Full Wayland: Wayland KWin, X11 applications (via X11 GTK and X11 Qt through XWayland and Wayland XWM)
- Non-Wayland: X11 KWin, X11 applications
Even under full Wayland, many old X11 apps such as xeyes and xterm would be running via XWayland.
Phew!
Yep, that’s how I understand it in a nutshell.
XWayland itself is just a client to the Wayland compositor. It is a minimal X11 server (created from via of a number of modifications over the X.Org server codebase) and running upon the Wayland protocol. It is similar in function to the Xorg server, but instead of driving displays and handling input devices, it acts as a Wayland client (as per any other Wayland-aware application). That way legacy X11 apps have support in a Wayland environment. Eventually, the need for such an intermediate layer will not be required.
I had a different take when I read the whole reference, starting from the first page.
I could be wrong, but am pretty sure of what I’ll describe next…
This is taking into account that I think the documentation might be a bit confusing by referring to “Wayland Compositor” the same when describing Full Wayland and XWayland. But, when I read the documentation carefully, I think I see differences which is in what I’ll describe.
I also am making a slight leap, although not explicitly described in the documentation that the deployment of an X server is more than simply inserting an X server object, I have to assume that an XWayland server has to not only be an object that communicates in a standard way with X11 clients, that also has to include performing as a translator of X11 request/response formatted messages to the Wayland protocol a Wayland compositor can understand.
This is my understanding…
Starting first with XWayland, it is a regular Xorg X server but configured to use a Wayland compositor to render graphic objects. In this configuration, nothing is actually passed to a “Full Wayland” but in a way the Wayland compositor can be considered a stub of Full Wayland. This Wayland compositor is also distributed as part of, or as a special version of an Xorg X server and not distributed as a completely separate standalone package or component. In other works, when you install XWaland, it’s installed completely all set to go, no dependencies required. And, since this is otherwise an ordinary Xorg X server, this is why it works with hardly any issues, when client apps like a Desktop framework or an application talks to XWayland, XWayland is no different than any other Xorg X server to the client. After processed by the compositor, the X server communicates with KMS.
Now,
Let’s talk about Full Wayland.
Full Wayland eliminates the X server completely and instead interacts with clients through Unix streaming sockets which is basically how the Linux OS has always communicated with itself internally(Linux mainly uses Unix sockets internally but also has Network sockets to communicate with “external” remote machines using networking). It’s fast, secure and built on a design and functionality which has always existed in Linux, there’s nothing that new here except for the idea of using it to support graphics rendering for a display.
But, for practically all of the Linux ecology, this is a radical shift. Decades of Desktops and applications have been built, designed, maintained and evolved based on the Xorg X server model and aren’t designed to use Unix sockets. Full Wayland replaces the X server, and like practically any other service, communicates with KMS using normal methods, like Unix sockets again.
Also,
Unix sockets is a good, sound architecture to move into the future, but the world won’t change overnight.
Unix sockets should be simpler, and a re-design from the ground up is expected to eliminate the bloat and spaghetti architecture that Xorg has become. Xorg is unnecessarily bloated and complex today because of decades of additions without regard to future changes, people have largely just added whatever was needed at that point in time.
This is my take,
TSU
No I don’t think the way you’ve described it is quite correct. Again looking athttps://wayland.freedesktop.org/docs/html/ch05.html
If you look at figure 5 and the surrounding description, XWayland is part of the Wayland compositor, not the other way around. The normal Wayland compositor contains an XWayland component and starts an instance of it to handle X11 clients (it’s true the to the X11 clients, XWayland just looks like the real deal). In this way normal Wayland compositor handles native Wayland-windows and X11-windows somewhat seamlessly for something like KWin.
This model allows Wayland-KWin running in Wayland to manage the entire session of both Wayland windows and X11 windows. That’s what makes non-full Wayland functional.
Now,
Let’s talk about Full Wayland.
Full Wayland eliminates the X server completely and instead interacts with clients through Unix streaming sockets which is basically how the Linux OS has always communicated with itself internally(Linux mainly uses Unix sockets internally but also has Network sockets to communicate with “external” remote machines using networking). It’s fast, secure and built on a design and functionality which has always existed in Linux, there’s nothing that new here except for the idea of using it to support graphics rendering for a display.
But, for practically all of the Linux ecology, this is a radical shift. Decades of Desktops and applications have been built, designed, maintained and evolved based on the Xorg X server model and aren’t designed to use Unix sockets. Full Wayland replaces the X server, and like practically any other service, communicates with KMS using normal methods, like Unix sockets again.
Also,
Unix sockets is a good, sound architecture to move into the future, but the world won’t change overnight.
Unix sockets should be simpler, and a re-design from the ground up is expected to eliminate the bloat and spaghetti architecture that Xorg has become. Xorg is unnecessarily bloated and complex today because of decades of additions without regard to future changes, people have largely just added whatever was needed at that point in time.
This is my take,
TSU
No, I think full wayland just means that as well as KWin using Wayland-Qt libs, the applications such as konsole and dolphin also use Wayland-Qt and Wayland-GTK libs (this could be switched by not much more than a change to LD_LIBRARY_PATH). Because the Wayland versions of these libraries are currently not good enough to handle all applications we need a non-full X11-lib supporting alternative. Plus XWayland is still started for full-wayland, otherwise xterm, xeyes, etc would fail.
At least that’s my interpretation.
BTW, as I understand X11, it uses local UNIX sockets unless a DISPLAY is set to a TCP name/address (so DISPLAY=:0 would result in UNIX sockets being used and DISPLAY=10.0.0.22:0 would force X11 to use TCP). It’s rare these days to use X11 over TCP-IP for more than admin xterms/emacs/yast/etc (issues with OpenGL and sound kind of diminished remote X11 via TCP for full desktop use).
I concur with this description.
IMO the diagram you’re referring to is accurate but you are interpreting incorrectly.
And, you’ll find the diagram 3.1 on the following page is more clear, supporting what I describe.
https://wayland.freedesktop.org/docs/html/ch03.html
As I said earlier, the referenced XWayland page is probably misleading read by itself. To properly understand the XWayland architecture you also have to read the preceding pages that describe Full Wayland and some other ways XWayland is described.
That said… who knows…
As I mentioned, by simply referring to the “Wayland compositor” in both Full Wayland and XWayland by the same name without differentiation, it’s easy to confuse or assume the two are same when I’m pretty sure the documentation says they’re not the same.
If someone can point out where in the documentation it says that the X server passes data to the compositor in a Full Wayland instead of a Wayland compositor in the X server, I’m easy to admit my mistake.
TSU
BTW -
For anyone following this discussion about what compositor is actually used or whether it’s one and the same for both Full Wayland and XWayland, it’s not just an academic exercise (lots of words with no significance).
It also means that although an X server Wayland compositor might be made as nearly the same as a Full Wayland compositor as possible, it’s not guaranteed to be so.
TSU
The diagrams in your reference illustrate the differences between traditional/old X11 and Wayland. They don’t illustrate the architecture of Wayland/XWayland.
XWayland definitely only runs as part of wayland. From the Wayland FAQ: Wayland
Is wayland replacing the X server?
Mostly, yes. User sessions are able to run under Wayland today, via a number of compositors: Weston itself as well as Enlightenment, GNOME Shell, KDE, and a number of others under development. With most toolkits having Wayland ports, as well as frameworks such as GStreamer and SDL, it’s perfectly possible to run a purely native Wayland session as your desktop.
That being said, there are some clients which rely on X11, and always will be. To that end, XWayland provides a plugin for Wayland compositors, running a real X server. This gives legacy clients a real and compliant X11 platform to run on, displayed side by side with native Wayland clients in your Wayland session.
It has to be this way so that Wayland can run old X11 applications, which is a major goal. The Wayland Wikipedia entry describes support for X11 and the full/non-full scenario pretty much as I have previously summarised them:
Compatibility with X
XWayland is an X Server running as a Wayland client, and thus is capable of displaying native X11 client applications in a Wayland compositor environment.[42]](Wayland (protocol) - Wikipedia) This is similar to the way XQuartz runs X applications in macOS’s native windowing system. The goal of XWayland is to facilitate the transition from X Window System to Wayland environments, providing a way to run unported applications in the meantime. XWayland was mainlined into X.Org Server version 1.16.[43]](Wayland (protocol) - Wikipedia)
Widget toolkits such as Qt5 and GTK3 can switch their graphical back-end at run time,[44]](Wayland (protocol) - Wikipedia) allowing users to choose at load time whether they want to run the application over X or over Wayland. Qt 5 provides the -platform command-line option[45]](Wayland (protocol) - Wikipedia) to that effect, whereas GTK 3 lets users select the desired GDK back-end by setting the GDK_BACKENDUnix environment variable.[44]](Wayland (protocol) - Wikipedia)[46]](Wayland (protocol) - Wikipedia)
So it even in openSUSE full-wayland is likely possible to still force a some troublesome applications to use the X11 (Qt5/GTK3) libraries. Similarly in non-full-wayland, it is likely possible to force selected applications to use Wayland (Qt5/GTK) libraries. But playing such games will may cause problems with cut/paste drag/drop between the X11/Wayland (unless KWin includes code to bridge the two).
I don’t understand what your confusion is about. From a Wayland perspective, XWayland is just another Wayland client. AFAIU, ‘Full Wayland’ refers to the desktop session (eg KDE Plasma) running as a Wayland compositor.
A Qt app can be made to run as a Wayland client using 'QT_QPA_PLATFORM=wayland <application>
More info:…
https://wayland.freedesktop.org/qt5.html
https://community.kde.org/KWin/Wayland
The following will start a Plasma session on Wayland…
dbus-run-session startplasma-wayland
You can actually play with a nested kwin_wayland running as wayland compositor inside a normal X11 session.
Here is what I think would equate to openSUSE full-wayland:
#!/bin/bash
#
export $(dbus-launch)
# Force all Qt and GTK applications to use Wayland
export QT_QPA_PLATFORM=wayland
export GDK_BACKEND=wayland
kwin_wayland --width=1280 --height=1024 --xwayland plasmashell
When this script is run, there will be a kwin_wayland process and under that an Xwayland sub-process. If you start a konsole inside the nested session, it will be running with wayland-Qt code paths.
In the konsole you can see DISPLAY is set and you can run up an xterm with no issues, DISPLAY connects it to XWayland.
If in a konsole you uset DISPLAY, you can no longer start an xterm from the konsole, but you can still start a konsole from the konsole. This is because konsole is using native wayland-Qt and doesn’t use/need X11 or the value of DISPLAY.
What about openSUSE non-full wayland? I think openSUSE non-full-wayland would equate to commenting out or removing the QT/GDK environment settings:
#!/bin/bash
#
export $(dbus-launch)
kwin_wayland --width=1280 --height=1024 --xwayland plasmashell
The KDE applications will use the Qt X11 code paths. Interestingly when I play the same tricks in a konsole by unsetting DISPLAY, starting a new konsole does result in a cannot find display message, but the konsole starts anyway, so is it falling back to Wayland?
Finally, a nested kwin_wayland can be started without an Xwayland client, just drop the --xwayland, in which case no X11 applications can run inside it and we definitely have to force all QT/GTK applications to use wayland (or the session won’t start at all).
#!/bin/bash
#
export $(dbus-launch)
# Force all Qt and GTK applications to use Wayland because there is no Xwayland
export QT_QPA_PLATFORM=wayland
export GDK_BACKEND=wayland
kwin_wayland --width=1280 --height=1024 plasmashell
Any xterm started in the above will start on the original outer desktop because DISPLAY=:0 was inherited and not overridden.
A little more background…
According to https://community.kde.org/KWin/Wayland kwin X11 is a X11 window manager and also an X11 compositor. Developer resources aren’t sufficient to create a stand alone Walland kde compositor, so the kwin codebase also serves to for kwin_wayland, which is a KDE window manager and Wayland compositor.
Under Wayland we have no wayland process, just a running compositer such as kwin_wayland. That differs from X11, where X11 runs in a process separate from kwin_X11 and they talk to each other. The difference can be clearly seen via ps/pstree when running the above scripts.
KWin_wayland is one of many compositors because Wayland is only protocol specification. There are dozens of Wayland compositors available, such as Weston (the reference implementation), Mutter, Enlightenment, etc. Presumably these compositors may share some code in the form of libraries, certainly many of them will use the XWalland client to support old X11 apps.
Fun stuff!
I think you guys are confused by the terminology used in the documentation,
In the Wikipedia reference, if you click on the footnote, inspect the announcement. It describes the Glamor rendering engine running in the X server. I wonder if that would be necessary if the X server merely translated and passed data to a Full Wayland backend where everything including Glamor exists.
XWayland was mainlined into X.Org Server version 1.16
When the XWayalnd Wayland compositor is deployed in the X server, the X server itself becomes the API interface to external clients and also itself becomes a client to the embedded Wayland compositor. Hence, no external Full Wayland is involved.
The stuff about XWayland supporting common DE and WM is probably merely interesting, it’s why XWayland is compatible with everything, because it’s not imposing a new architecture, objects and components but I don’t see it as a differentiator whether a full Wayland backend is used or not…
But,
We’re talking in circles when AFAIK none of us are Wayland Developers.
I recommend putting this topic on hold until I (or anyone else) can find someone who can authoritatively provide answers.
TSU
Agreed. With Glamor we are crossing into new territory that blurs the discussion, which is not helpful.
Glamor is something that is used to draw graphical output onto some graphical “buffer”. This is NOT something that Wayland does, from the FAQ:
Wayland doesn’t render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer. When the client is done, it informs the Wayland server of the new contents.
Wayland’s responsibility is to allocate and manage the buffers, keep track of which buffers belong to which on-screen windows, track which windows overlap each other, and efficiently created the composited final on-screen view. So a Wayland implementation is a window manager and compositor only.
Part of the picture is that other bits of X11 have also been supplanted by other libraries, such as drawing libraries including Glamor, OpenGL, Vulkan, etc.
So X11 applications running under XWayland still have to use something, such Qt/GTX, OpenGL/Glamor/Vulkan (or something older) to draw their output on the buffer allocated to them. The buffer will have come from Wayland (via XWalland), and that’s how the result is properly managed by Wayland.
At the same time pure Walland applications will also potentially using the same libraries to draw into there Wayland allocated buffers.
Now it may be that the Walland implementation is also using the same libraries, OpenGL, Vulkan, Glamor etc to do the final job of rendering the screen and doing compositing effects.
@tsu2:I’m really not certain about most of what your question to be frank. The reference links are at most overviews, and perhaps that leads to your confusion about some of the details.
When the XWayland Wayland compositor is deployed in the X server, the X server itself becomes the API interface to external clients and also itself becomes a client to the embedded Wayland compositor. Hence, no external Full Wayland is involved.
The stuff about XWayland supporting common DE and WM is probably merely interesting, it’s why XWayland is compatible with everything, because it’s not imposing a new architecture, objects and components but I don’t see it as a differentiator whether a full Wayland backend is used or not.
“Full Wayland” just means where back-ends for GTK or Qt are set to Wayland, and really only has meaning in the context of the desktop environment. As mchnz already mentioned, this means ‘QT_QPA_PLATFORM’ and ‘GDK_BACKEND’ variables are both set to ‘wayland’. Regular Plasma Wayland sessions will use X11 (XWayland) for applications (unless the application explicitly called with the pertinent environment variable set).
That’s a misconception on your part. There is no “translation” process. Wayland clients do their own rendering (to shared buffers), and notify the Wayland compositor when display updates are needed. As already mentioned, Wayland itself is a communication protocol used to communicate between Wayland clients and the display server (a Wayland compositor) for input and output (graphical update) events. The compositor
collects updates (damage requests) from clients and then re-composites the entire screen (via an ioctl pageflip with KMS).
The diagrams in your reference illustrate the differences between traditional/old X11 and Wayland. They don’t illustrate the architecture of Wayland/XWayland.
This image should help clarify how it fits together…
https://upload.wikimedia.org/wikipedia/commons/2/2d/The_Linux_Graphics_Stack_and_glamor.svg