Probably everyone that is interested in the Linux desktop has heard about Wayland. It's the next big thing, the replacement for X.org, a solution to a lot of woes in terms of performance and graphics on Linux. And still, it has failed to materialize, over and over, and is still not the default on many big distributions, like Ubuntu, or Linux Mint. Let's see what Wayland is, and how ready it is, right after this!
Wayland is, in itself, just a protocol. It's not a program, or a replacement for the old X.org display server. This protocol has to be implemented by a compositor, which will display the application's content on the user's screen.
Currently, a lot of distributions use X.org, the very old display server that has served us pretty well for ages. The goal of wayland is to put this old beast to pasture, but for what benefits ?
First, let's take a look at how X.org works. This old thing, dating back to 1987, the blessed year of my birth, by the way, is a multi-layered process: First, you have your display server, or the X server. It's the central platform to communicate with the clients, like the applications you're using, and the compositor, which displays the windows for these apps themselves. This server is interacting with clients, which are basically your applications, but also with a compositor, which is your window manager, like Kwin on KDE, or Mutter on GNOME.
It's a sturdy process, but it introduces a lot of delay, with some back and forth betwen the server, the compositor, and the application itself.
Wayland has a simpler model, because in Wayland, the compositor IS the server as well. This means that, in our example, the application opens, tells the compositor that it wants a window, and the compositor gets all the details from the app in one go, decides what to do with the window, and tells the app to draw itself. Yep, on Wayland, the applications also have to do their own rendering on the screen: they manage their own titlebars, their own drop shadows, everything.
This is why you can't just switch GNOME or KDE from X.org to Wayland: the pieces that compose the desktop environment don't play the exact same role on both solutions. On Wayland, the compositor doesn't draw the windows, the app themselves do, so you have to update the window managers to become compositors that don't do any drawing, and you have to update the toolkits, GTK and Qt, to let them draw stuff themselves.
Then there's the issue of the graphics drivers: the Nvidia drivers, the open source AMD or Intel drivers, these were written to send information back and forth with X.org, not with a wayland compositor.
So they also have to be updated to work with that new model. This is already the case, as the open source Mesa drivers, which cover AMD and Intel, already support wayland using a solution called GBM. Nvidia, on the other hand, decided that they had a more efficient solution called EGL, which has to be supported separately by the wayland compositors.
Since Nvidia doesn't seem to be willing to update their driver to use GBM, for nvidia drivers to work with wayland, desktop environments have to also support EGL, which is an extra burden, and also explains why Nvidia drivers are hit or miss when using Wayland.
So, where is Wayland? Well, it's already very well supported: - GNOME supports Wayland, with Mutter, its window manager and compositor - KDE supports Wayland as well, with Kwin - Both GTK 3.20 and QT 5 support wayland out of the box
In terms of distros, Fedora already uses Wayland as the default, if the drivers permit it, and has been since 2016. Red Hat Enterprise Linux 8 also uses Wayland as the default, and Debian does so as well, for their GNOME sessions. Manjaro also defaults to wayland for the GNOME sessions, if the drivers allow it.
Some programs that were made specifically to work with X.org don't work on wayland-based systems, especially games.
For that use case, Wayland developers have a solution: as wine or proton expects to run in an X Server, Wayland provides the ability to run such a server inside of Wayland, as a client, this is called Xwayland.
The performance of Xwayland, however, seems on par with just running a game on X.org, as demonstrated by Phoronix early this year:
Hey guys, this is Nick and welcome to my Linux experiment.
Whether you're an old-timer or newcomer, you probably have heard about Wayland.
It's the next big thing, it's gonna put old X.org to rest,
it's gonna bring so many improvements to performance, everybody is working on it.
And still, since 2010, it has failed to materialize over and over again.
So I think it's time we take a look at what is Wayland and how ready it is as of today.
Let's take a look, but after this.
This video is sponsored by KernelCare Enterprise.
Keeping servers safe, compliant, and ensuring constant uptime
becomes a full-time job that has to be automated.
To do that, you need a live patching tool that integrates with automation tools
and vulnerability scanners, that is supported with the latest patches,
that lets you decide what patches are rolled out across your organization,
and that runs inside the firewall.
KernelCare Enterprise does all of this.
It provides you with more integration, more support, and more control.
It works in your local infrastructure via ePortal,
a dedicated patch server that runs internally, but outside your firewall.
This server acts as a bridge between internal patch servers
and the main KernelCare patch server.
This approach is ideal for staging and production environments
that need strict isolation from external networks
or require more stringent control over the patches to be applied.
Try KernelCare Enterprise for free by clicking the link in the description below.
Okay, so what is Wayland?
Well, Wayland in itself is just a protocol.
It's not an application that you can install.
You can't type sudo apt install wayland.
It doesn't work like that.
It is a specification that has to be implemented by a compositor or a window manager.
Now, most distributions have been using the agingx.org display server.
This thing has been created in 1984,
and the x11 version that we still use today dates back to 1987.
It didn't have a single major version update since then.
It is an old beast, and it has a lot of craft, a lot of code wrapped around it.
It's basically impossible to evolve for the modern world.
So Wayland is poised to put that old beast to pasture, but for what benefits?
Okay, so let's take a look at x.org first.
It's based on a server client model, which has been used because at the time,
they wanted one single rendering station to be able to display multiple screens
at the same time using the same hardware.
So they had an x server running on the main machine,
on the one that had the graphical power,
and the little terminal clients that they had just ran x clients that called to the x server itself.
So it's a server client model, which means that you have your x display server,
which communicates with the hardware through the Linux kernel,
so the mouse, the keyboard, the GPUs, the touch devices.
You have the compositor, which draws the windows and positions them on the screen,
and you have the x clients, which are basically the applications.
That's the model of the x server.
Now, imagine you wanted to make a window appear on the screen.
You're going to click with your mouse on the file manager icon, for example,
and this application will open.
It's then going to tell the x server that it wants a window.
Now, the x server will then talk to the compositor,
telling him, hey, I want a window.
What are the details of the window?
The compositor will then say, I don't know.
For what do you need a window?
And they're going to chat a long time over
to know if the window should be active or inactive,
where it should be positioned,
what are its dimensions,
what are its contents,
and is it resizable or not?
All of this information takes a little bit of time
between the x server and the compositor.
And once the compositor has all the information,
it gives the information to the x server.
The compositor draws the window itself.
The x server tells the application that the window is ready
and the application displays its own content inside of the window.
This is a sturdy process,
but it's also very long and introduces a lot of delay.
Now, Wayland has a simpler model,
because on Wayland, you don't have a server.
The compositor is the server itself.
So basically, when you open your file manager window,
the application will tell the compositor that it needs a window.
And the compositor will get all the details
from the application itself without any back and forth.
The compositor will then tell the application
to draw its own window and its own contents
with a few parameters that the compositor has calculated.
So yes, on Wayland,
the window manager or the compositor
doesn't draw the window himself.
It's the application that draws its own window.
It's what we call client-side rendering.
Now, this is why you can't just switch from x.org
to Wayland just like that,
because the roles that were fulfilled by the toolkits,
GDK or Qt,
by the window managers,
Kwin or Mutter for Gnome,
by the applications themselves,
these roles aren't the same on x.org and on Wayland,
which means that you have a lot of work
to port over the libraries, the window managers,
and even sometimes the applications themselves
to make use of Wayland
instead of calling to x.org protocols.
It's a long work,
and this explains also why Wayland hasn't materialized
on every single distribution yet.
That's a lot of effort.
But in the end,
what are the benefits of Wayland?
Well, as we saw,
you've got less input delay
between the moment you click something
and the moment it's displayed on the screen.
When you're going to resize a window,
move a window,
it's going to be more fluid, more smooth.
There's going to be less delay.
It's also going to have more performance
because there are less moving parts implicated
in the process of displaying windows on your screen.
And the code base is also going to be way leaner
because Wayland doesn't have 33 years of crust
to port over.
It's a newer code base,
a newer architecture,
which is more modern,
and which is going to be easier to evolve
as years go by.
But that's not all.
There's also the issue of the graphics drivers
because the graphics drivers that currently exist,
which are the proprietary NVIDIA driver,
the proprietary AMD driver,
and the open source Mesa drivers for Intel and AMD,
these things have been written for X.org,
not for Wayland,
which means that they have to be updated as well
to be able to communicate with the compositors
and display the things
in respecting the Wayland protocol.
Now, this has already been done.
The Mesa drivers use a standard called GBM
and they're already updated
and well and stable for Wayland.
The NVIDIA drivers though,
they took a different route.
They thought GBM wasn't efficient enough
and they created their own standard,
which is called EGL.
And since NVIDIA doesn't seem to be willing
to back down on this standard,
this means that every Wayland compositor,
if it wants to work on all machines and all devices,
this compositor will have to support
two competing standards,
GBM for the Mesa drivers
and EGL for the NVIDIA proprietary drivers.
This is an issue
and this is also why NVIDIA
hasn't been on point with Wayland recently
or at all,
because the community is focusing
on the open source solution on the standard,
which is GBM
and EGL is coming as a second thought.
Okay, so if the drivers are updated,
if the desktop environments are updated,
so why isn't Wayland here?
Well, it's already there
for a lot of distributions.
First, GNOME supports Wayland
through Mutter, its window manager and compositor.
KDE also supports Wayland
with KWin, its window manager and compositor.
And the toolkits GDK and Qt,
which are the main toolkits for KDE and GNOME,
also support Wayland as well.
Now, in terms of distribution,
Fedora ships with Wayland by default
if the drivers allow it since 2016.
Red Hat Enterprise Linux version 8
also uses Wayland as the default.
Debian also uses Wayland as the default
on their GNOME session,
as does Manjaro since November 2020
if you're using GNOME,
provided that the drivers allow for it.
So who's missing?
Well, basically the two big hitters
in the Linux desktop world,
which are Ubuntu and Linux Mint.
But why haven't they switched yet?
Well, I don't have the exact reasons
why these guys haven't tested the waters yet.
What's certain is that
all the programs written for x.org
are not working well on Wayland.
Some programs have been written specifically
for x.org, for example, f.lux,
which is a program that lets you change
the color temperature of your screen
as the hour advances during the day
to limit blue light emission.
This thing doesn't work on Wayland
because it uses x.org-specific protocols.
Then you also have gaming.
Wine and Proton expect an X server to work
and they haven't really been updated
to take advantage of Wayland,
which means that gaming on Wayland
is theoretically impossible.
Except the Wayland developers
have thought about this
and you can call as a Wayland client
an X server.
This is called X Wayland.
This means that your main device
will run Wayland as the display server,
as the compositor,
but one of the applications
that's gonna call to Wayland
is an X server,
which is going to be used to run the game.
It works in most cases,
but it also has issues
in terms of displaying
the actual game's contents
or rendering the mouse pointer.
Sometimes it gets dropped in the process.
It's not 100% stable yet,
but the performance is already there
as this test article from Foronyx shows,
the performance is virtually identical
when running X Wayland
or when running the same game
in the X server directly,
which is a very good thing.
No performance hit.
Wayland and Wayland-enabled compositors
are also not as stable
as the tried and tested X.org
and that's normal.
It's a younger protocol
and the major implementations
have only started like four years ago,
only on Fedora
and the rest have followed suit bit by bit.
So it doesn't have as much testing
and this means that Wayland
won't be as stable in all cases.
It's generally very good in day-to-day use
provided that you use the Mesa drivers
for AMD or Intel.
On Nvidia drivers,
your experience will be more hit or miss.
Now, since Wayland isn't a complete
drop-in replacement for X.org,
this means that the desktop environments
also had to re-implement some stuff
on their own
and this means that some basic features
that worked on X.org
now don't work really well on Wayland
and have to be re-implemented.
Take, for example,
this release from KDE 5.20.
You had a re-implementation on Wayland
of middle-clicked paste,
of supporting the clipboard manager,
of adjustable mouse scroll speeds
or of screen casting.
These are super basic features
but they just arrived in October
in KDE Plasma.
They weren't supported on Wayland before.
This is an issue
because this means that you can't just
switch to Wayland like that
because you're going to miss some features
that already work
and as long as you don't have feature parity,
I don't see the major distros
like Ubuntu or Linux Mint
moving to it.
And this is the holdup for moving to Wayland.
It doesn't have feature parity yet
in terms of desktop environments
and the support for NVIDIA proprietary drivers
is not there
which means that major Linux desktops
do not want to take the jump right now
because it would break the experience
for a lot of their users.
These two reasons are, in my mind,
enough to justify waiting for Wayland.
The improvements are mostly under the hood.
User-facing changes are virtually not there
or non-existent
so it's not worth it to take some slashes
in terms of features
and lose some of them
just to move to the newest things.
It's okay to wait.
But I'm honestly very excited
to see where Wayland is going to go
because we need a modern stable base
for our systems
if just because X.org is not suited to work
for example on Linux phones
or on Linux tablets.
This is where Wayland really shines
because it can do stuff that X.org can't
and it's a way leaner,
more stable,
and more performant code base.
So this is the future of the Linux desktop.
This is where we are going to go
but how long it's going to take
is not up to me.
And that's it for this video guys.
I hope you enjoyed.
If you did, don't hesitate to like
or dislike if you didn't.
If you're a specialist
in terms of Wayland or X.org
don't hesitate to correct me
if I got something wrong.
This is a pretty technical subject
and you can also subscribe
and turn on notifications,
all of you,
just if you want to support the channel.
And if you really want to help
the channel grow
you can also join my amazing
Patreon subscribers
and YouTube members
and get access to a weekly Patreon cast
and the right to vote
on the next topics I'll cover.
Thank you guys for watching
and I'll see you in the next one.
Bye!
