Ironically, the functionality that distinguished X from other window systems, network transparency, or the ability to run graphics applications on remote terminals, is seldom used on most Linux devices. When X appeared, computing was still being performed on minicomputers and servers, and graphic terminals were only tasked with displaying graphics. Now, in a computing environment that is radically different from that of twenty years ago, where CPU power is usually on the desktop in the same device as the graphics display, that networking capability is more than redundant; it can actually get in the way of efficient performance. Networking applications can be replaced with remoting tools such as RDP or VNC or are better performed in a browser.
Linux is famously scalable between devices but as Keith Packard points out: "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", and often do. So the Android developers, for instance, replaced X with an Android specific compositing environment.
This is where Wayland comes in. Wayland isn't designed to be portable, the perceived benefit of X, but increases the performance and portability of Linux and the graphical applications that run on Linux. This may be why Intel has an interest in Wayland, and why Tizen may be the first platform to deploy the new display server. There is no immediate intention to implement network transparency in Wayland, although it could be done in the future. In the meantime an X Server can be run as a client of Wayland with relatively little overhead, and can run current applications across the network. But this may fail as new applications are written which aren't aware of X.
Høgsberg's response to this problem has said that although Wayland isn't a remote rendering API, it already works by being informed of changes to client buffers through events and that the compositor could then send the new pixels in that region out over the network. He adds that "the Wayland protocol is already violently asynchronous, so it should be able to handle a bit of network lag gracefully", which suggests that while network transparency isn't high on the priority list, it could be implemented on Wayland without a fuss.
A period of transition
Inevitably, restructuring the entire Linux graphics stack is a slow and laborious process, and there are hurdles to overcome. Wayland uses OpenGL ES, and not OpenGL, because "libGL pulls in GLX and all the X dependencies". Libraries have to be stripped out and functionality replaced. Graphics cards have to be supported, and support for X has to remain seamless during the period of transition.
Wayland supports open source drivers for Intel, AMD and NVIDIA graphics cards. Weston, the reference compositor, does not have chipset specific code, and supports the Mesa infrastructure and "all drivers in Mesa that support DRI2 under X... The support for Wayland is in the shared Mesa infrastructure, so when driver writers enable a new chipset in Mesa, it will automatically support Wayland". The future ubiquity of Wayland on Linux seems likely given the preponderance of smaller devices in the market for Linux, and the drive towards a faster and more flexible graphics stack. The cause is helped by the patronage of Canonical and Red Hat through Ubuntu and Fedora.
Wayland is only as useful as the applications and toolkits it supports. Applications built for Xfce, GNOME and LXDE use the GTK+ toolkit. Porting the toolkit to Wayland makes the use of Wayland transparent to the application. From an application's point of view, it is still using the common UI elements, buttons, scrollbars, text areas, sliders and checkboxes, that it has always used; but further down the graphics stack, in the backend, these are now translated so they are rendered with an appropriate graphics library into Wayland buffers.
Høgsberg says "the two most interesting challenges in porting toolkits to Wayland are probably popup windows and client side decorations. Popup windows are interesting since the popup behavior relies on grabbing the keyboard and pointer, and being able to position the popup window at a given position on screen. Wayland doesn't allow either, but we solve it by having the server know a little more about how the popup should work and implement part of the behavior. The other challenge is client side window decorations, which means that the clients draw their own window title bars and frames. This typically means that the toolkit has to draw a few more widgets as part of the top level window, but it makes the whole stack simpler."
Høgsberg himself has worked on the backend for the GTK toolkit, used by Xfce, GNOME and LXDE, and Canonical is financing a port of Compiz to OpenGL ES, to enable its use on Wayland. The translation of the Qt toolkit, which will make Wayland visible to KDE applications, is being maintained by Nokia, and work is under way by KDE developers on Kwin. Other toolkits currently being ported include the EFL toolkit used by Enlightenment, SDL (Simple DirectMedia Layer), which has been used to port games software to Linux (including Civilization: Call to Power), and the cross-platform multimedia library, Clutter, which was developed by Openedhand Ltd., now owned by Intel.
At this month's FOSDEM, Høgsberg announced the prospective release of Wayland 1.0 at the end of this year. Inevitably, there will be a lag as the bleeding edge distros test the water, but with any luck, within a year or two the payoff should be a smaller footprint, faster graphics and an easier life for Linux graphics developers.
For other feature articles by Richard Hillesley, please see the archive.