Official website for Linux User & Developer
FOLLOW US ON:
Aug
4

Replacing X – Wayland’s Rise

by Richard Hillesley

The graphics subsystem on Linux is undergoing change. The X Window System is 30 years old and showing its age. Richard Hillesley tells some of the story of X and its replacements…

The V microkernel was developed at Stanford University between 1981 and 1988 as a vehicle for operating system research. The windowing system for the V operating system was named W, and was ported to UNIX in 1983. A year later, Bob Scheifer, working at MIT’s Laboratory for Computer Science, announced the arrival of X. The original release of X was derived from W, and Scheifer admitted: “I stole a fair amount of code from W, surrounded it with an asynchronous rather than a synchronous interface, and called it X.”

According to Scheifer, the performance of X was “twice that of W” and although “the code seems fairly solid at this point”, he invited “anyone interested in hacking deficiencies” to “get in touch”.

Server and client

X was developed as part of Project Athena, co- sponsored by DEC and IBM. One of the objectives of Project Athena was to promote networking and interoperability between the many systems in use at MIT, to facilitate the sharing of information and research.

From the point of view of the UNIX companies, the virtue of X, which consisted of a server and a protocol, was that it made it possible to generate and display windows across a network – X offered ‘network transparency’ and the code was open source. A user with an X server on his or her computer or terminal could display and receive data from an X client on another computer. As a consequence, X became the standard server and protocol interface between graphical input and output devices for VAX and UNIX systems.

It should be noted that a confusing aspect of X as it relates to network transparency is that X inverts our usual understanding of the terminology of clients and servers. The UNIX Haters Handbook summarised this nicely. “In all other client/server relationships, the server is the remote machine that runs the application (ie the server provides services, such as a database service or computation service)… But X insists on calling the program running on the remote machine ‘the client’. This program displays its windows on the ‘window server’…

“When you see ‘client’ think ‘the remote machine where the application is running,’ and when you see ‘server’ think ‘the local machine that displays output and accepts user input’.”

Call it Motif

Network transparency was seen as essential because it allowed different versions of UNIX to talk to each other. 20 or 30 years ago, most computing on UNIX or VAX was done at remote terminals connected to a minicomputer. The user on the terminal with an X Server could run a program through the ‘client’ on the minicomputer.

The X Window System was a set of compromises which allowed the UNIX companies to differentiate themselves, and X gave “programmers a way to display windows and pixels.” X was the primary graphics server of its time. If it had a failing it was that it didn’t use a specific widget set, and left the choice to the developer. As a result “it didn’t speak to buttons, menus, scrollbars, or any of the other necessary elements of a graphical user interface. Programmers invented their own. Soon the UNIX community had six or so different interface standards. A bunch of people who hadn’t written ten lines of code in as many years… came up with a ‘solution’… Build something on top of three or four layers of X to look like Windows. Call it ‘Motif’.”

The lack of a toolkit specific to X meant that UNIX and the early versions of Linux used a variety of toolkits. In his initial announcement of KDE, Matthias Ettrich noted just how many different toolkits were in use. A typical desktop of the time might consist of the FVWM window manager, the RXVT terminal emulator, the Tgif 2D drawing program and the XV image viewer, each of which used its own distinct widget set to draw the elements of its windows. More ambitious applications such as Ghostview, Lyx, Xftp or Textedit used the Athena widget set, the XForms toolkit (unrelated to the later XML standard of the same name), Motif or the XView toolkit from Sun Microsystems, which claimed to be the “first open source professional-quality X Window System toolkit”.

The effect of this proliferation of widget sets was that no two applications could be relied on to look or behave like one another. The eventual solution on UNIX systems was to find some form of commonality around CDE, the Common Desktop Environment, and Motif. But neither CDE nor Motif was free software, and Motif was bulky, slow and inelegant to program.

Making a bookshelf

The Free Software Foundation’s replacement for Motif, Lesstif, didn’t reach maturity until 1997, by which time Qt and KDE had displaced its functionality. At the technical level, Ettrich’s response to Motif could be said to be typical of many Linux developers. Motif, he said, was “hard to use and requires a lot of source code for even simple tasks… you will have to learn at least three APIs and when to use them: Motif, Xt and Xlib. [And the resulting software was] sluggerish and slow.” And Jamie Zawinski was moved to say that “Using these toolkits is like trying to make a bookshelf out of mashed potatoes.”

Inevitably, Qt and GTK+ displaced Motif as the toolkits of choice, not only on Linux systems, but on UNIX ones, many of which long ago chose GNOME as a more flexible choice for graphical applications than CDE.

X has remained the standard method for driving the graphics subsystems, between the widget kits and the kernel, for most UNIX, Linux or BSD operating systems. But X was written for another time, when space and memory were limited, and graphics cards and screens were very different. X is 30 years old and is showing its age.

On Linux, much of the functionality of X has been bypassed or is irrelevant to modern devices and applications. Long-time X developer and current Wayland protagonist Keith Packard asks: “How many of these applications care about network transparency, which was one of the original headline features of X? How many of them care about ICCCM compliance? How many of them care about X at all?

“The answer to all of those questions, of course, is ‘very few’. Instead, developers designing these systems are more likely to resent X for its complexity, for its memory and CPU footprint, and for its contribution to lengthy boot times. They would happily get rid of it.”

Wayland is the answer

The performance of the Linux graphics subsystems have been impeded by X because “the window system has been split apart into multiple pieces – the X server, the window manager, the compositing manager etc. All of these pieces are linked by complex, asynchronous protocols. Performance suffers as a result; for example, every keystroke must pass through at least three processes: the application, the X server and the compositing manager.” To ensure that GNU/Linux systems remain compatible with modern graphics systems, “a lot of infrastructure has moved from the X server into the kernel (memory management, command scheduling, mode setting) or libraries (cairo, pixman, FreeType, Fontconfig, Pango etc) and there is very little left that has to happen in a central server process.”

The mainstream replacement for X is Wayland, which has been under development for five years. Wayland is a protocol that replaces the X protocol. Weston is the compositor, or display server, for Wayland. Weston will support the primary Linux toolkits, GTK, Qt and E17. The pay-off for the user will be a much smaller footprint and faster graphics. The pay-off for graphics developers will be a much simpler and more productive life.

Most of the Wayland developers have a long history as X developers, having kept X and the graphics subsystem going against the odds during a time when there have been tectonic shifts in graphics technologies and paradigms.

The core developers work for a variety of companies, primarily Intel, Samsung and Red Hat – although like many other free software projects it began as a one-man project, initiated by Kristian Høgsberg in 2008, when he realised that, over time, the functionality of X had been “split up and refactored into shared libraries, kernel drivers and other components,” because the X protocol is no longer sufficient to handle modern graphics systems. As a result, the X server “is now just a middleman that introduces an extra
step between applications and the compositor and an extra step between the compositor and the hardware.”

Wayland radically reduces the complexities of the graphics subsystem, and replaces all the workarounds and kluges that compensated for the historic deficiencies of X, but is not the only prospective replacement for X. Android already uses a display server of its own, SurfaceFlinger, adapted for the specialist environment of mobile devices, and Canonical is writing yet another, Mir.

The first display server in space

Mir is named after the space station that Mark Shuttleworth visited when he travelled into space. Mir is controversial and it is unclear why Canonical felt the need to usurp Wayland as the replacement for X on Ubuntu. Ultimately, the logic seems to be that Mir will be something like Wayland or Google’s SurfaceFlinger, but Canonical will bypass all functionality that does not relate directly to Unity and Ubuntu. Mir will allow Unity to take short cuts and prioritise performance.

There are some very real objections to Mir, and Canonical’s cathedral approach to development. Wayland developer Daniel Stone’s instant response was that “this means more work for us, more work for upstream developers, more work for toolkits, more work for hardware vendors, and years of explaining that most of the page explaining that Mir had to be created because Wayland was a) hugely deficient, and b) unfixable, was total bull****.” The explanatory page was later amended, but the damage was done.

It is apparent that development on Mir has been under way for some time, and the main objection of developers has been the failure to talk issues through with the community. The crisp response of David Edmundsun, the developer of LightDM (www.sharpley.org.uk/ blog/lightdm-mir-wayland) was that “If you know for six months that you’re not going to do something you said you would, it’s rude not to tell people.”

If Ubuntu Touch takes off, if Ubuntu finds commercial traction, Mir will be a central plank of Canonical’s strategy and important to the success of Linux and other free software projects; but, as previously noted, “Mir code will be licensed under Canonical’s CLA, which assigns rights of ownership to Canonical. Mir isn’t an application, but aims to be the essential underpinning of the graphics stack on the most popular Linux distribution and, as such, may not only take resources away from Wayland but create future incompatibilities in the graphics stack. Removing the ambivalences, incongruities and incompatibilities in the code is one of the reasons why so much effort has been poured into Wayland. One doesn’t have to doubt the intentions or motives of Canonical and Ubuntu to know that Mir offers the prospect of more unintended consequences for the Linux graphics stack, and the graphics stack should not be in the ownership of one company.”

Wayland and Weston will be the chosen path for the great majority of Linux distributions, including Tizen, the mobile operating system sponsored by Intel and Samsung as an alternative to Android and Ubuntu Touch.

WIN the latest tech with Linux User!
A Google Nexus 10 tablet and Google Nexus 4 smartphone must be won!

  • Tell a Friend
  • Follow our Twitter to find out about all the latest Linux news, reviews, previews, interviews, features and a whole more.
    • Tarek Said

      I don’t know a lot about display servers, and I may be saying something stupid, but one way they could fix these incompatibilities issues would be to get together and decide on a common API.

      That way, Wayland, Mir and any other display server could do their own thing and the programs would not need to know the specifics, the communication between them and the display server would work the same way.

    • colin mcdermott

      So who here is thinking of Security?

      Does Wayland, Mir or any of these interfaces offer a level of GUI environment security and isolation. Linux is relatively secure, but as this blog points out http://theinvisiblethings.blogspot.com.au/2011/04/linux-security-circus-on-gui-isolation.html The GUI could easily be compromised.

    • Henrik Danielsson

      Wayland was supposed to be that common protocol/API. As far as I can tell, one problem is that Mir is intentionally incompatible with Wayland.

    • Henrik Danielsson

      Good article, one nitpick though. E17 isn’t a toolkit but the WM on top of the Enlightenment Foundation Libraries.

    • Bob_Robert

      I use the network display functionality of X on a regular basis.

      The switch to Wayland is fine by me (I’m a user, not a programmer) so long as I can still “ssh -Y” and launch GUI applications that display on my local machine.

      That X did network transparency “mainline” and Wayland would do it with a “plug-in” is actually unimportant to me. What matters is that it DOES it. It is functionality I use, and want.

    • bwat47

      Afaik, Wayland is basically just an IPC protocol and API, I wouldn’t even really call it a “display server”. It is an efficient protocol that allows others to implement their own “display server” or more accurately “wayland compositor” using a common protocol. There really wasn’t many valid reasons for canonical to create their own server and protocol, when they could have certainly accomplished anything they needed to do with the wayland protocol, and that way they would not have broken compatibility with upstream.

      That said, I don’t think the situation is quite as bad as it seems. Both Mir and Wayland have several major similarities in their architecture, such as using EGL. For drivers, theoretically it should not be difficult to support both as long as they provide EGL support. For applications things shouldn’t be that bad either, because mir/wayland support is at the toolkit level. The biggest burden will probably be on the toolkits though; having to have and support two backends in addition to X (because X will not be totally going away anytime soon)

    • Wayne Winget

      Just another way some egotistical linux programmers are standing in the of universal acceptance of linux over windows and apple stuff. It’s my way or the highway. If LINUX had a superchief such as Gates or Wozniak/Jobs, we wouldn’t be in this mess.

      Still my operating system is linux, and I’m not going back. I wish I had more programming skills, but at 80 YO, I don’t have the time left to contribute.

    • Henrik Danielsson

      Please do not blame programmers for what is likely a business decision. Btw, contributing does not have to take a lot of time or require programming. Many projects are looking for all kinds of help with anything from spreading the word/marketing to translation corrections or simply cash contributions to keep services running.

    • Gene Mosher

      > Keith Packard asks: “How many of these applications care about network transparency, which was one of the original headline features of X? How many of them care about ICCCM compliance? How many of them care about X at all? “The answer to all of those questions, of course, is ‘very few’.

      And if we all are among the ‘very few’, then what does the future hold for us, Keith?

    • elder_geek

      I am glad Canonical has made something very different. I am tired of the old Microsoft route of corrupting a protocol. Active Directory is Kerberos + LDAP with just enough changes to both to make them incompatable with open implementations.

      I would prefer MIR = very different from Wayland over MIR = 90% Wayland and 10% other stuff.

    • Henrik Danielsson

      With Mir being very different from Wayland, it’ll only mean applications will have to support two different ways of communicating their interface to the user. Sure, libraries will help abstract that, but it also means the apps using those libs are much less likely to be optimized for either case because they don’t have direct access to the display server in time critical operations without a lot of extra code.

      If Canonical would have gone with Wayland like they said they would, instead of going into silent mode, they could have helped improve Wayland and avoid this mess. They are instead, IMHO, now bound to set back the unification of the Linux desktop(s) by years – despite the ironic naming of their software products. Sometimes I do wonder if they pick them out of sarcasm…

    • elder_geek

      Henrick, do NOT get me started on that one. I am in 100% agreement there. Canonical was 100% on the Wayland bandwagon. Then they realized that they needed something done fast and in my words “did not have time to get consensus on how to do it.” They decided to go their own route and forget to mention it to anyone for 6 months.

      They pull their Wayland developer(s), put them to work on MIR and anything that Canonical had promised to work on or communicate about for Wayland sat in limbo for six months till they announced they just started working on MIR … six months ago.

      MIR is correct, something that was developed with cold war secrecy.

    • Pingback: What Distro Am I Using As I Start This Blog? | Lintea

    • Pingback: How Does My Desktop look? | Lintea

    • ben deb

      Hello Using Qt on wayland does wayland window manager can control QT window ?