So, You want to Write your own Linux Display Server?

UPDATE: It's been confirmed that Ubuntu will be switching to a new display server called Mir. Canonical have posted some FUD about Wayland on the documentation site, and it turns out the Mir devs didn't even understand Wayland enough to make a decision.

Yesterday, OMG! Ubuntu! published a news article stating that Canonical are working on their own display server. If you don't understand the technical details of a display server, what it's job is, and how applications talk to it, then you may think this is a good thing. You may think, “Linux is about choice” or “perhaps this will be better than the alternatives”. But you'd be wrong, horribly wrong.

I have so many problems with this announcement that I thought I'd actually stick my neck out here and put it down on paper. I've been largely driven to this because I have this unfortunate habit of reading comments, and some people tend to comment on topics that they have no knowledge about. This annoys me.

So, let's start from the beginning, what is a display server?

When you write an application, whatever it may be, you normally talk to some API that allows you to write the application without having to get down to the nitty gritty of actually rendering buttons or creating windows. Depending on personal choice, application type, and technical decisions you may choose to use something like Gtk+, or QT or for games SDL.

All of these toolkits talk to what is called a “display server” to do things like, draw the actual buttons, or receive input. Basically a display server is a middleware between your application, and the Linux kernel. But, each of these APIs needs to know how to talk to the display server, they need to be able to say “Hey! Display server! Can you draw me a button over there?” or “Hey! Do you know where the mouse cursor is?” (this explanation is obviously simplified).

For this reason, the display server will define a “protocol” or “language” for the middleware to talk to. All of these APIs talk this language, not only that but applications that need to talk directly to the display server (e.g. Wine) also talk this language.

Until recently, there has been one mainstream protocol called X11, and it's widely adopted. Every graphical Linux application eventually ends up talking X11 and to the display server that talks that language: the xserver.

X11 was invented a really long time ago, and it's served us well, but a lot of the protocol doesn't make sense anymore on modern computers. So, recently a bunch of the X.org developers got together and started defining a better, faster, slicker protocol than X11. This protocol is called Wayland. Wayland supersedes X11, and is designed for modern hardware, as opposed to the hardware of the 1970s. The Wayland protocol has been defined openly, over a couple of years. Everyone has been encouraged to contribute to its development because Wayland needs to cover all use cases.

In summary, there are now two protocols, there's X11 which is heading towards retirement, and Wayland which is destined to replace it. So, despite all the diversity in the Linux ecosystem, despite the different toolkits, and distributions and packaging systems and forks. There has only been one widely adopted display server protocol at a time, and this is a good thing! It means your toolkit or application just has to talk one language and bam, it works across all of the Linux distributions.

Now, Canonical wants to write a new display server, and that in itself is OK, write a new one that talks Wayland and everyone is laughing. Except, they've explicitly stated that Wayland doesn't suit their needs... Wut?

So the protocol that has been defined in the open for the last couple of years, that needed input from all areas so that it fitted all use cases, and actually has had at least one Canonical employee contributing to it doesn't fit their needs?!

This can only imply that they are writing their own protocol, which means that every application, or toolkit API will now need to speak another language. Aside from the legacy X11 and the widely supported Wayland, now everyone will need to code and maintain support for a new one. And this isn't trivial. I've worked with the Wine source code and there are 1000s of lines of code devoted to X11 and I don't think they have even begun to implement support for Wayland. I've also worked on the SDL source code, and again, there are 100s of lines of code in there for X11 and they've already implemented a Wayland backend.

What Canonical is actually doing is not saying “we're going to write a display server” they're saying “we're going to break compatibility with the rest of the Linux ecosystem”. There are two paths forward here, either Canonical themselves implement all the backends for all the toolkits to talk to their new display server, or, they'll use their majority market share to force toolkits themselves to maintain them. Niether of those is pretty, or a small amount of work. Neither benefits users or developers. To break compatibility in this way needs some pretty serious justification.

Going forward I hope that when they said “Wayland doesn't fit our needs” I'm hoping they meant “Weston doesn't fit our needs” (Weston is the reference implementation of the Wayland protocol).

They can by all means implement their own display server, I just really hope that it talks the same language!