Is Wayland the New X?

Looking into the Future of Display Server Protocols

By

Bruce Byfield

Display server expert Daniel Stone explains what is really happening with the future of graphical display protocols on Linux.

So far as most Linux users are concerned, Wayland is the project that is eventually supposed to replace the X Window System (X). More recently, you might have heard how Canonical Software decided to start Mir rather than develop Wayland for Ubuntu. That is the extent of general knowledge, although that doesn’t stop people talking – which is why Daniel Stone, a long-time developer of display servers, delivered a talk at linux.conf.au in 2013 called, “The Real Story Behind Wayland and X (or ‘Why Everything You’ve Read in LWN and Phoronix Comments is Untrue’).”

Stone should know, if anyone does. He began his involvement with free software in 2001 as Debian package maintainer for KDE and Apache 2. A few years later, working at Trinity College at the Univeristy of Melbourne, he was asked to package a new version of XFree86, a version of X11 that is now largely supplanted by X.Org. That assignment led him to maintaining X for Ubuntu and later to troubleshooting display systems for mobile and embedded devices for Nokia and Collabora, as well as his involvement with X.Org, the current version of X used by most distributions.

Today, he is one of the major contributors to Wayland, a project of about 25 active contributors and supported largely by Intel and Stone’s employer, Collabora.

Over the last decade, he describes himself as having “slowly graduated from working on the packaging and the build system – including creating the first modular build of the X.Org server – to working on the core server.” The trajectory gives him a clear overview of exactly what has been happening with display servers in recent years.

Why Not Stay with X?

Stone traces the earliest origins of Wayland to a page on the X.Org wiki started by Adam Jackson called X12. “It wasn’t a serious attempt at a design,” Stone stresses, “but a list of things we would do differently if we had a chance to rework the core protocol.”

For many developers, this list helped codify the problems with X11. “Some of these issues were just out-and-out problems with the core protocol,” Stone says, “but a lot of them were to do with the fact that, in the 26 years since X11 was created, everything around it has changed, both hardware and applications.” Admittedly, X is extensible, but, with the average X server running an average of 23 out of 27 extensions, many X developers feel that “we’ve kicked that can as far down the road as we can.”

To make matters worse, because X.org policy is never to break backward compatibility, today, X includes four separate input models “reflecting the evolution from keyboard and three-button mouse to full multi-touch,” four display models, and two rendering models – not one of which has priority over the others, even though some are obsolete.

Consequently, the effort to keep X11 running is passing the point of diminishing returns. Although the last few years have seen numerous improvements, most of the easy improvements have already been implemented. Typically today, “Solving even the most tiny of issues, if [it was] actually solvable at all, would involve a massively disproportionate amount of effort – which would, in itself, create problems in the future,” says Stone.

Still, the efforts of the last few years gave X an extended life, while the work on X11 extensions became a general inspiration for Wayland. The specific inspiration came from founder Kristian H&oslash;gsberg’s work on the DRI2 direct rendering extension).

In short, “Wayland would not be possible without the last few years of X development,” Stone says. Cleaning up the extensions gave developers a clearer sense of how an ideal display server should work.

How Does Wayland Differ from X.Org?

Wayland’s main advantage over X is that it is starting from scratch. One of the main reasons for X’s complexity is that, over the years, its role has changed. As Stone says, “Originally, your X server would take a stream of rendering commands (rectangle here, image here, text there) and do all the rasterization. As our user interfaces (and, notably, fonts) got more complex, eventually window managers rendered everything themselves, and just posted huge window-sized buffers to the clients.”

As a result, today, X11 acts largely as “a really terrible” communications protocol between the client and the window manager. This changed role works, but can be awkward, and frequently results “in visual glitches, such as the old juddering [shaking] resizes or flashes of a gray-and-white window before it fills itself in.” Although these glitches can be patched, the patches further complicate the structure and the necessary maintenance.

Like the modern X11, Wayland is a display protocol, requiring a compositor from which to receive instructions (in Wayland’s case, the only compositor right now is Weston, although that will change with adoption). The difference is that Wayland is an attempt to re-create the modern purpose of X11 from scratch, reorganizing it and focusing on modern computers to reduce the needless complexity.

Another major difference is that, whereas X11 blindly carries out commands from the client, Wayland attempts to improve performance by encoding appropriate reactions to more common rendering situations.

“Probably the best example is a pop-up window,” Stone says. “In X11, this is implemented by telling the server to place a window in a very specific location, and to give your client all the keyboard and mouse input from the whole display so it can close the window when you click outside of it. And since we have no way to break these input grabs, your media keys don’t work, and the screen saver can’t start.”

By contrast, Wayland includes specific instructions about what to do with a pop-up window class, “and the compositior is expected to close the pop-up window when you click outside of it. If the compositor wants to trigger the screen saver, it’ll do that and close the pop-up window. Having that context is hugely, hugely valuable.”

Of course, such instructions cannot anticipate the correct behavior for every situation. For instance, on touch screens, multiple areas of the screen can be touched at once, and which area – if any – should be given priority is impossible to anticipate. Temporarily, at least, Stone says, “we’ve just done our best to design these issues out of the protocol, and we’ll see what falls out of various implementations trying to make the best of it.”

The bottom line? Being built from scratch, Wayland is less of a patchwork and therefore less likely to suffer from unforeseen interactions. Additionally, in basic contexts, Wayland offers specific instructions that make it react more intelligently in many routine situations.

Was Canonical’s Decision to Abandon Wayland Based on Technical Limitations?

Judging from Stone’s comments, Canonical’s decision has less of an effect on Wayland than outsiders might imagine. Although Mark Shuttleworth, Canonical and Ubuntu’s founder and leader, pledged support for Wayland in 2010, according to Stone, “they weren’t ever really involved. The sum total of their involvement is Chris Roger’s prototype work on system compositors, which we’d used to implement things like fast user switching.” As a result, Canonical’s decision “doesn’t really make any difference.”

However, one point that Stone does emphasize is that the reasons given have nothing to do with Wayland’s limitations. The intial reasons given for the decison were wrong and were corrected later. The remaining reasons come down to the fact that Wayland isn’t developed using test-driven development, and that “they want to be able to swap out our UNIX socket-based IPC with something else” – both of which are easily corrected, Stone says.

Additionally, Canonical also has suggested it wants to develop proprietary drivers for Android and perhaps for Valve. Yet Stone claims that “Wayland is explicitly designed to be easier to implement in proprietary drivers (and we’ve done it several times). We had a Wayland stack running on Android as part of Collabora’s work last year. Also, thus far, neither Valve nor any proprietary driver has come out and said that they’ll port to Mir.”

Stone is careful not to say anything more, but the inference is that, whatever the reasons for Canonical’s decision, they weren’t technical, so as far as he is concerned, Wayland is perfectly capable of doing what Canonical complained it didn’t or couldn’t do.

When Will Wayland Be Ready for Use?

Although most people have settled into thinking of Wayland as a work in progress, the project has already shipped on a number of embedded products, phones, and tablets. “For these products, where you control the entire stack top-to-bottom, it’s very easy to use the Wayland core protocol, and build your own specific UI on top with custom extensions.”

However, “for more generic desktop usage, there are still a fair few gaps which will only really be solved when we get viable ports of the major desktop environments.” According to Stone, “A number of GNOME developers are working really hard to get a full port of GNOME to Wayland this year,” and KDE and Enlightenment are also working on supporting Wayland. “I’m not going to put a date in writing,” he says, “[but] I think it’ll be a pretty big year for Wayland.”

Regardless of how Wayland is received in the near future, Stone notes that in recent years, “kernel mode-setting drivers are delivering us huge benefits and great stability; we’re now seeing a lot more support from a much wider vendor base, and Mesa is not only extremely stable but beginning to compete on features. We wouldn’t have dreamed of having a base like this to work on previously.” As far as Stone is concerned, the work on X11 that inspired Wayland and Wayland itself has already helped improve graphical displays, even if more work remains to be done.