Every few months, I see posts or comments saying something to the effect of, "Wayland was forced on us," or "Wayland is not as good as X11" And every time it happens, I want to sit down and write a long post explaining why x11 had to go, and why wayland was the right choice to replace it. Today, I finally decided to do just that.

This post won't be like most posts; it's going to be nerdy and packed with information from several sources. To begin to explain why X11 has its flaws, we’ll need to start with Unix.

Before X: a Tale of Fragmentation

Almost everything related to X11's problems has to do with Unix. Unix was the wildest of operating systems: in theory, everything was “compatible”. In practice? Well, it was a mess of proprietary Unix spinoffs which were incompatible with everything from hardware support to display servers.

A Brief History of Unix

A group of researchers in MIT decided to adopt the technologies they created in their failed project "Multics" , an operating system for a dec mainframe. They used key concepts from it to create their new operating system: Unix. At the time, they were funded by Bell Labs, and due to a series of antitrust cases against the parent company, AT&T, Unix could not be a product. Instead, it was sold at the cost of the media.

In 1973 they released the first commercially-licensed version of Unix. However, these licenses only supplied the source code with no further support. Even then, AT&T continued to license the previous versions for universities. At the time, there wasn't an idea of "release," but rather continuous development with patches being distributed on tapes. Unix only ran on DEC hardware, but towards the 1980s AT&T and several universities ported it to other hardware like the intel 8086. In 1983 AT&T settled their second antitrust case and suddenly found themselves able to commercially sell Unix and support it. This prompted the introduction of System V Unix, which in turn eliminated fragmentation, as well as the ability to share Unix patches.. This eventually led to 3 bases for Unix forks, System V, BSD and Xenix (A discontinued Unix operating system developed by Microsoft).

The Unix Wars

The Unix Wars is a period of history in software development that can only be described as chaotic. You had non standard display servers, weird networking, and a whole lot more. Some of the tools that came out of it, such as Dtrace, are interesting. Customers demanded standardization, and AT&T responded by creating the System V Interface Definition for Unix spinoffs based on System V. And later, the IEE would publish the beloved POSIX standards.

At the time, MIT’s Project Athena was started to create a distributed computing environment on their campus. Out of Project Athena came the X Window System (at the time, version 10). In 1987, version 11, now known as X11, was released and that cemented it in Unix. And it's where we can start to see many of the architecture decisions that lead us to X11's fatal flaws and some of its unique properties.

The Unique

X11 has done an amazing job separating the hardware from the application. An X11 application basically never needs to worry about the hardware under it. X11 uses a client-server model, which means that the server provides display, graphics, and I/O to applications, and applications can use those resources by communicating with the server. This model allows for interesting solutions, like running applications on another computer over the network by communicating with an X11 server, which in turn allows rendering on another system.

The Flaws

X11 was built before a lot of modern features were necessary. Accessibility for example was an afterthought, with people struggling to implement simple features to provide accessibility. The same client-server architecture that is a unique selling point became a significant issue because it slowed down rendering. Modern X11 systems use Unix sockets and shared memory to speed this up, although shared memory is an opt-in feature that developers explicitly need to request from the server. Along with this, fallback is always present for legacy applications. Finally, X11 has a weird quirk: multiple monitors are actually treated as one large display. Now, you might be asking: why is that an issue? It’s because it's treated as one display, thus you can't have different refresh rates. Instead, you have to default to the lowest common settings, often meaning your fancy 4k 144hz display has to run at 60hz because your older monitor only goes up to 60hz.

MIT X Consortium

Adoption by several major companies meant that MIT no longer wanted to have stewardship of the project. However, at the insistence that a neutral party maintained the project, MIT formed the MIT X consortium. Following several years of significant revisions, the consortium prepared to leave, and formed the non-profit X Consortium, and released the final revision, X11R6.3. At the time, there were several competing X11 implementations, including XFree86. The stewardship of the protocol was handed to the open group in 1996.

In 1998, the group released X11R6.4, which led to controversy as licensing changed to be more restrictive. Following XFree86 starting its own fork, they relicensed back to the liberal licensing change. In 1999, the open group formed X.org (but this isn't the X.org we know, that comes later).

X.org and XFree86

At this point, X.org released X11R6.5.1, after which development died out. Since the X Consortium dissolved, XFree86 took its place as the hub of development, and came from a single port of X to the 386 architecture, and quickly became the de facto server implementation. However, the XFree86 project had a very restrictive development environment, where patches could languish for years while waiting to be merged.

Keith Packard, who had joined the group after the original MIT X Consortium was dissolved, was ejected for proposing a fork. In response, in an ironic twist, the XFree86 project released 4.4 with a restrictive license, which led to massive outcry for a fork.

X.org Rising from the Wreckage

The freedeskop.org group, along with various members of X.org, formed the current X.org foundation we all know and love, and were given control of x.org. Since then, X11 has found major issues, such as a flawed font system, a 2D graphics system which was always intended to be replaced or augmented, and the aforementioned latency issues.

As you can see, although X11 has been around for years, it is fundamentally flawed. It came from when powerful computers meant mainframes, yet today we have desktops that could easily rival the power of those mainframes. With the exception of major CVEs, X.org developers have basically frozen most of the project, since for all intents and purposes the only thing that needs development is XWayland.

Why? Because X11 is old. It was written before we had many of the concepts of security we have now: for example, for the longest time you had to run X11 as root. If you exploited it, you had root access. Fuzzing wasn't a thing, and auditing code was rare. I suspect if people actively started fuzzing x11 components – especially ones like Xypher which aren't commonly used – we'd have a lot more CVE reports.

So How Do You Fix It?

Well, we could start by getting rid of the client-server model. While this model introduces some amazing capabilities, it introduces latency that just can't be solved. Instead, we can go with a model of client-compositor where a client talks to a compositor process via interprocess communication (IPC). We'll also make this asynchronous so we don't have to wait either as the server or the compositor.

At this point we can also look into modern security practices, for example we can adopt Android’s model of permissions. Any old application shouldn't be able to view the whole screen, as that is a security risk. And we should also make sure that old X11 applications are supported, so we should probably create a compatibility server, but – wait, that’s… everything Wayland already does.

Well, Now You’ve Just Revintented Wayland

Yep, you just did that. When Wayland was first developed in 2008, several X.org developers contributed to its design. When those developers tell you X11 is a dead end, they mean it, and that’s because they’re the people who maintained it and understood it. Around the same time, Fresco, Y windowing system, and Mir(now it's wayland compositor) were in development, but it was Wayland that survived and was adopted by the greater Linux community. (You could argue it was Redhat that pushed it down our throats.)

But here's the truth: it’s been in development since 2008, when I was 5 years old. It was never going to be as perfect as X11 on day one; X11 has had more than a decade of active use. If Wayland wasn't ready, KDE and Gnome wouldn’t have implemented it. They could have chosen anything else, but they didn't: They chose wayland.

Wayland is Still Rough Around the Edges

Portals: Not Bad

Wayland cant exist without portals. You can think of portals as a mixture of an IPC protocol and the Android permission model. Portals came from the Flatpak project, which allows sandboxed applications to request files and permissions from users.

A common use for portals outside sandboxed applications is screen sharing. You don't want an application to see your entire display without your permission, as that's how you get malware taking screenshots of your screen all the time and using AI to – oh wait, no, that’s Windows Recall. But you get the point: portals offer security benefits to the user

One complaint you'll often see is that it opened a dialog box which looked out of place on the desktop. Now, of course there are ways to fix this, such as setting GTK themes on KDE Plasma, and Qt themes on Gnome, but then you get the one application that chose not to use GTK or Qt, and instead use a different toolkit and produce a dialog that doesn't fit in. Portals solve this issue.

As a UI toolkit developer, instead of worrying about what file explorer is present on the system, you let the portal handle it. No more requiring Zenity or implementing your own file picker in your UI toolkit. Both Chrome and Firefox have started using this, to the delight of many Linux users.

The De Facto Server Implementation

Another criticism I often see people argue is that due to the fact that Wayland doesn’t have a de facto drop-in server similar to X11, it’s a failure. Here's the thing: XFree86 died. There was never a canonical X11 server. We just happen to have one most people use. There was Xynth, MicroXwin, Metisse and Kdrive/TinyX. These projects unfortunately did not make it; the de facto X11 server we use today is only de facto because all the other implementations never got enough traction.

Wayland does have a reference compositor: Weston. It’s not pretty, and is far from a daily driver, but it’s just a reference. It does offer a de facto library to implement compositors, however: wlroots. You don't need to use wlroots; KDE Plasma and Gnome didn’t. Arguing that there has to be one because X11 had one is an erroneous argument because X11 did not actually have one in the first place.

What About the Other Unix Variants?

Wayland doesn't officially support anything but Linux, and this mainly due to Wayland being a project started by a group of Linux developers. A big difference from X11 is wayland is a protocol, not a server implementation; there are ports of Kde plasma and Gnome to FreeBSD, NetBSD and DragonflyBSD. The major issue is that porting to one BSD doesn't result in a port to all. Unix's biggest selling point uniqueness is ultimately the issue here, fragmentation means sharing work is basically impossible. The most interesting work I've seen comes out of Haiku, who instead of porting a server, wrote a compatibility layer. The layer takes the Wayland protocol calls and translates them to the Haiku display server.

X11 Had Decades to Get It Right

If you speak to Linux/Unix users who used X11 in the old days, you're bound to hear stories of them having to manually tweak xorg.conf, praying it would work and not leave them unable to use their system. Even as recently as June of 2023, nyanpasu64 found bugs in X.org's cvt tool (cvt is a tool used to generate modelines for X.org). Wayland was never going to be perfect on day one. They needed adoption to see the rough edges, to see big desktops port over, to actually see where the rough edges are.

The funny thing about the PC ecosystem is that you'll never be able to test all the edge cases without having people test your code. Hardware is extremely weird: different firmware versions can behave differently. If you get past hardware issues, you run into application developers that want to do things which are not covered by your protocol. It's like the wild west, and can only be solved by people using the software.

X11 had decades. Give Wayland time as well.

Special Thanks

Thank you to FOSSUnleashed and LainVT for proofreading and their invaluable input on this post