Why I don't use Wayland (and how it can be improved)

Why I don't use Wayland (and how it can be improved)


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.


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 whereever 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?

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.


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!