Notice: Undefined index: order_next_posts in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 194

Notice: Undefined index: post_link_target in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 195

Notice: Undefined index: posts_featured_size in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 196

Replacing X – Wayland’s Rise

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 ( 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!