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

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.

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.

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.

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.


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!