144 lines
8 KiB
Markdown
144 lines
8 KiB
Markdown
# Why I don't use Wayland (and how it can be improved)
|
|
|
|
2023-04-28
|
|
|
|
Today I want to talk about Wayland, and why I don't use it. In case you're a
|
|
normie and don't know what Wayland is, Wayland is this new display protocol
|
|
created by the people over at Freedesktop. They want it to be better than the
|
|
display protocol most GNU/Linux users are already using called X11. While I'm
|
|
not against the idea of a new display protocol, in my opinion Wayland is a
|
|
failure, and it fails at doing everything X11 did right, and that's what I want
|
|
to talk about here. Note that most of this will be from a developer's
|
|
perspective; if you're using GNOME, KDE or maybe even one of the many wlroots
|
|
based compositors, your experience on Wayland is probably going to be pretty good.
|
|
|
|
## Terminology
|
|
|
|
First, let's talk terminology. On X11 we have something called a 'Window manager',
|
|
and as the name implies it manages your window. The window manager is the root
|
|
window, meaning it's the first window. Other than that, it's just like any other
|
|
window you may have. This is quite powerful, because it means in theory anything
|
|
can be a window manager. You can try this for yourself on Xorg and xinit by
|
|
running `startx /usr/bin/firefox`. What you should have is an X11 session with
|
|
only firefox open and nothing else. This is why we have window managers, they
|
|
allow us to spawn more windows and place those windows wherever we want. Even
|
|
desktop environment users have a window manager, because your desktop
|
|
environment comes bundled with one.
|
|
|
|
On Wayland and X11, we have something called a compositor. Let's ignore
|
|
Wayland's definition completely for now. On a basic level, the compositor provides
|
|
fancy effects such as transparency, rounded corners with anti-aliasing, shadows,
|
|
animations and other things you may or may not want. One of the most popular
|
|
compositors today is called Picom, and most standalone window manager users use
|
|
it, if they use a compositor at all. This works by creating buffer where these
|
|
effects are added, and then displaying the buffer to the user. This is why
|
|
older machines may feel slow when a compositor is running, it's just not
|
|
displaying that buffer quickly enough.
|
|
|
|
In X11, a client is pretty much the same thing as a window. I am going to be
|
|
using the term 'window' throughout this blog post, but client is what I
|
|
usually use when referring to an X11 window.
|
|
|
|
'Xorg' is an *implementation* of the X11 protocol, and it's the implementation
|
|
most users are using. There are other ones like XFree86, but most users use Xorg.
|
|
|
|
## The compositor problem
|
|
|
|
This is where Wayland's problem for me comes in. On X11 these two components are
|
|
separate, so I can pick and choose each component and just combine what I like.
|
|
With Wayland, they have decided to combine the compositor and window manager
|
|
into one program, which to make it even more confusing is also called a
|
|
compositor. Now, why is this so bad?
|
|
|
|
- Less modular
|
|
|
|
By combining the compositor and window manager, you're slowly making the display
|
|
stack less and less modular. The days of choosing your compositor and choosing
|
|
your window manager are now gone. It's all one big program, meaning even if you
|
|
avoid desktop environments you're still going to have one big program that does
|
|
everything. This is just not the way forward if you ask me. I believe the main
|
|
reason for this is "making the desktop easier for new users", but at this point
|
|
the GNU/Linux community should give up on new users who aren't willing to
|
|
learn our technology.
|
|
|
|
- Window managers are so complex
|
|
|
|
It is incredibly easy to make an X11 window manager, because again it's a window
|
|
like any other. You really just need to create a window, read atoms and finally
|
|
move/resize windows around. On Wayland you now also need to implement a compositor,
|
|
which adds a lot of complexity and room for failure. Even one of the more minimal
|
|
Wayland compsitors dwl, a dwm rewrite for Wayland has many more lines of code
|
|
than the original dwm, because now you also need to do the compositing yourself.
|
|
Not to mention, if you're using a minimal compositor like dwl, you can't have
|
|
fancy effects and a minimal window manager, that's just not possible anymore,
|
|
at least as of now.
|
|
|
|
This added complexity led to libraries like wlroots being created, and its slogan
|
|
really says it all; "about 60,000 lines of code you were going to write anyway".
|
|
However even with wlroots you still need to implement compositing, there's no
|
|
way to have a separate compositor with your window manager.
|
|
|
|
- No, a Wayland compositor is not a window like any other.
|
|
|
|
As I said earlier, a window manager on X11 is a window like any other. The only
|
|
difference is it's the first window spawned (root window), and it is responsible
|
|
for creating, resizing and displaying all other windows, although this is technically
|
|
not a requirement. This is good because you can for example `startx /usr/bin/firefox`
|
|
and have an X11 session that runs Firefox. Nothing else, just Firefox. This goes
|
|
for any graphical program such as your terminal emulator, text editor, Emacs, etc.
|
|
On Wayland, this is not possible, because windows do not implement compositing
|
|
whatsoever. They are only responsible for creating themselves.
|
|
|
|
- How about no compositor
|
|
|
|
I think this is worth mentioning as well. A lot of X11 users simply don't use a
|
|
compositor at all. They deem it unnecessary, and it makes sense. If you don't need
|
|
transparency, fancy effects, Vsync and other nice features like that, why should
|
|
you waste your system resources on a compositor? Good luck omitting the compositor
|
|
when you're using Wayland. You can't.
|
|
|
|
Those are the problems that come as a result of combining the compositor and
|
|
window manager. While I'm sure there could be benefits to combining the
|
|
compositor and window manager as well, I just cannot think of a single reason.
|
|
|
|
## What change do I want to see?
|
|
|
|
I want a more minimal display protocol. Wayland is more minimal so I think it
|
|
passes here. What I also want is a more *modular* display protocol, and this
|
|
is where Wayland seems to fail. X11 did this right, but I want it even more
|
|
modular than X11. Everything should be separate, as long as it doesn't harm the
|
|
user experience. Not to mention, more modular software is usually more secure,
|
|
because each module is much smaller and easier to maintain.
|
|
|
|
I also want a library which allows creating BOTH X11 and Wayland clients without
|
|
writing any extra code for it. This would be ideal, although I'm sure there
|
|
are potential challenges from doing it this way. You might say, "Just use GTK
|
|
or QT" but they also require writing extra code for Wayland or X11 support.
|
|
This leads to developers not supporting one or the other.
|
|
|
|
For example, I want to add Wayland support into spmenu. I'd be happy to do so,
|
|
but the problem is it would require rewriting the code for creating the
|
|
window, handling events, keybinds, clicks, drawing, mapping, and more.
|
|
It's just not something I want to deal with, which is why I've
|
|
chosen to not write any of my software to use Wayland native libraries.
|
|
There is XWayland, but to my knowledge there's no such thing in reverse.
|
|
|
|
## Conclusion
|
|
|
|
I want to mention that I'm very much open-minded towards a new display protocol.
|
|
I'm all for a new, more minimal, more stable display protocol. It's just that
|
|
Wayland makes it a pain to write compositors, and in many ways it's a downgrade
|
|
from X11, which is *really* old I might add. That's not to say Wayland has no
|
|
improvements and X11 is perfect. The most popular X11 implementation, Xorg
|
|
is extremely bloated and has a lot of legacy code that really doesn't matter
|
|
today and the protocol itself is probably not much better.
|
|
|
|
It also has absolutely horrible security. But all things considered, I think X11
|
|
just has much better ideas on what the desktop should be than Wayland does. If
|
|
Wayland improves the things I don't particularly like, I may end up switching
|
|
to it. But as of now, X11 works fine for me and the benefits of Wayland just aren't
|
|
worth it, so I am going to be sticking with X11. If you know of any solution
|
|
to this problem, I'd love to hear it, and I'd love to give Wayland a proper chance.
|
|
|
|
Thank you for reading, have a good day!
|