Wayland (display server protocol)

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Wayland Logo.svg
Wayland demo 2.png
Wayland demonstration
Original author(s) Kristian Høgsberg
Developer(s) freedesktop.org et al.
Initial release 0.85 / 9 February 2012; 2 years ago (2012-02-09)[1]
Stable release 1.5.0 / 20 May 2014; 2 months ago (2014-05-20)[2]
Development status Active
Written in C
Operating system Linux, FreeBSD[3]
License MIT License
Website wayland.freedesktop.org

Wayland is a protocol that specifies the communication between a display server (called Wayland compositor) and its clients, as well as a reference implementation of the protocol in C language.[4] It was initially authored by Kristian Høgsberg as a replacement for the X Window System.

The Wayland protocol is essentially only about input handling and buffer management. When running on Linux kernel, handling of the input hardware relies on evdev, while the handling of buffers relies on Generic Buffer Management (GBM); when running on other operating systems, Wayland compositors work with their respective components.

The initial implementation of the protocol, libwayland-server, libwayland-client and libwayland-EGL libraries, and the reference implementation of a Wayland compositor Weston are all written in C and published under the MIT License.

Unlike the X clients, Wayland clients will render directly into their own buffer located in the graphics memory, through the use of EGL with some additional Wayland-specific extensions to EGL.[citation needed] The display server is responsible for the compositing, hence it will incorporate a large part of the functionality of current compositing window managers. Several compositing window managers, such as Mutter, KWin and Enlightenment are in the process of being rewritten to become Wayland compositors.

Software architecture[edit]

① The evdev module of the Linux kernel gets an event and sends it to the Wayland compositor.
② The Wayland compositor looks through its scenegraph to determine which window should receive the event. The scenegraph corresponds to what's on screen and the Wayland compositor understands the transformations that it may have applied to the elements in the scenegraph. Thus, the Wayland compositor can pick the right window and transform the screen coordinates to window local coordinates, by applying the inverse transformations. The types of transformation that can be applied to a window is only restricted to what the compositor can do, as long as it can compute the inverse transformation for the input events.
③ As in the X case, when the client receives the event, it updates the UI in response. But in the Wayland case, the rendering happens by the client via EGL, and the client just sends a request to the compositor to indicate the region that was updated.
④ The Wayland compositor collects damage requests from its clients and then re-composites the screen. The compositor can then directly issue an ioctl to schedule a pageflip with KMS
Wayland compositor and its clients use EGL to draw directly into the framebuffer; X.Org Server with XWayland and Glamor.

In recent years, Linux desktop graphics has moved from having "a pile of rendering interfaces... all talking to the X server, which is at the center of the universe" towards putting the Linux kernel and its components (i.e. DRI, DRM) "in the middle", with "window systems like X and Wayland ... off in the corner". This will be "a much-simplified graphics system offering more flexibility and better performance".[5]

Høgsberg could have added an extension to X as many recent projects have done, but preferred to "[push] X out of the hotpath between clients and the hardware" for reasons explained in the project's FAQ:[6]

What’s different now is that 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. ... [An X server has] a tremendous amount of functionality that you must support to claim to speak the X protocol, yet nobody will ever use this. ... This includes code tables, glyph rasterization and caching, XLFDs (seriously, XLFDs!), and the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives. For many things we've been able to keep the X.org server modern by adding extension such as XRandR, XRender and COMPOSITE ... With Wayland we can move the X server and all its legacy technology to an optional code path. Getting to a point where the X server is a compatibility option instead of the core rendering system will take a while, but we'll never get there if [we] don’t plan for it.

Wayland consists of a protocol and a reference implementation named Weston. The project is also developing versions of GTK+ and Qt that render to Wayland instead of to X. Most applications are expected to gain support for Wayland through one of these libraries without modification to the application.

Wayland does not currently provide network transparency, but it may in the future.[7] It was attempted as a Google Summer of Code project in 2011, but was not successful.[8] Adam Jackson has envisioned providing remote access to a Wayland application by either 'pixel-scraping' (like VNC) or getting it to send a "rendering command stream" across the network (as in RDP, SPICE or X11).[9] As of early 2013, Høgsberg is experimenting with network transparency using a proxy Wayland server which sends compressed images to the real compositor.[10]

Differences between Wayland and X[edit]

There are several differences between Wayland and X in regards to performance, code maintainability and security:[11]

  • Architecture: the composition manager is a separate, additional feature in X, while Wayland merges display server and compositor as a single function. Also, it incorporates some of the tasks of the window manager, which in X is a separate client-side process.[12]
  • Composition: compositing is optional in X, but mandatory in Wayland. Compositing in X is "active", that is, the compositor must fetch all pixel data, which introduces latency. In Wayland compositing is "passive", which means the compositor receives pixel data directly from clients.[13]
  • Rendering: the X server is able to render itself, although it can be instructed to display the rendered windows sent by clients. Wayland does not expose any API to render and delegates all the rendering responsibilities (including font rendering, widgets rendering, etc.) to the clients. Even the window decoration should be rendered in client side (by the graphic toolkits), although some compositors can offer server-side decorations.[14]
  • Security: Wayland isolates the input and output of every window, achieving confidentiality, integrity and availability in both cases; X lacks these important security features.[15] Also, with the vast majority of the code running in the client, less code needs to run with root privileges, improving security.[16]
  • Inter-process communication: the X server provides a basic communication method between X clients, later extended by ICCCM conventions. This X client-to-client communication is used by window managers and also to implement X sessions, selections and drag-and-drop, and other features. Wayland core protocol does not support communication between wayland clients at all, and the corresponding functionality (if needed) should be implemented by the desktop environments (like KDE or GNOME), or by a third party (for example, by using native IPC of the underlying operating system).
  • Networking: The X Window System is an architecture that was designed at its core to run over a network. Wayland does not offer network transparency by itself; however, a compositor can implement any remote desktop protocol to achieve remote displaying. In addition, there is research into Wayland image streaming and compression that would provide remote frame buffer access similar to that of VNC.[17]

Some of the differences can also be easily understood by comparing the architecture diagrams of both protocols.[18]

Compatibility with X[edit]

A screenshot showing xwayland

XWayland is a X Server running as a Wayland client, thus capable of displaying native X11 client applications in a Wayland compositor environment.[19] This is similar to the way XQuartz runs X applications in OS X’s native windowing system. The goal of XWayland is to facilitate the transition from X Window System to Wayland environments, providing a way to run unported applications in the meantime. XWayland was mainlined into X.Org Server version 1.16[20]

Qt applications can switch between graphical back-ends like X and Wayland at load time with the -platform command-line option.[21] In January 2011, Wayland support was moved into the Lighthouse branch of the upstream Qt repository.[22] Qt Lighthouse is shipped in the Qt 4.8 release.[23]

In December 2010, GTK+ added preliminary support for switching back-ends at run time, saying "interesting combinations are X11+Wayland or Quartz+X11".[24][25] In January 2011, the GTK+ Wayland backend was updated to support the multiple-backends feature and moved to the gdk-wayland-backend branch of the upstream GTK+ Git repository.[26] In April 2011, the gdk-wayland-backend branch was merged in the GTK+ master branch.


Planned adoption[edit]

  • Fedora: Fedora ships Wayland since release 17.[49] Fedora developer Matthias Clasen released a tentative roadmap in March 2013, targeting to use Wayland as default by Fedora 21.[50] Fedora 20 ships with a technology preview of a Wayland-enabled Gnome 3.10 session.[51][52]
  • GNOME: In March 2013 GNOME developers announced plans for a complete Wayland port within a year.[53] GNOME 3.10 includes initial support that "will enable the project to fully adopt the next generation display and input technology in the future".[54][55] The current roadmap targets GNOME 3.12 as the first version to be fully ported to Wayland.[56]
  • KWin, the KDE's window manager, added support for OpenGL ES output[57] in version 4.7.[58] In January 2013 KWin’s main developer Martin Grässlin started working for Blue Systems with one of the goals being a complete Wayland port.[59] Experimental Wayland support is now working in current KWin 4.11.[60]
  • KDE’s Calligra Suite already has an unofficial but working port to Wayland.[61]
  • Mate desktop: Wayland support is on Mate’s roadmap.[62] The targeted Mate version is 1.10.[63]
  • Intelligent Input Bus is working on Wayland support, it could be ready for Fedora 22[64]
  • RealVNC published a Wayland developer preview in July 2014[65][66][67]


As of October 2013:

  • Clutter has complete Wayland support.[68]
  • EFL has complete Wayland support, except for selection.[69]
  • GTK+ 3.10 (released 23 September 2013) has complete Wayland 1.2 support, including the client-side decorations, which is required by Weston.[70][71]
  • Qt 5 has complete Wayland support, including the client-side decorations, which is required by Weston but not KWin.
  • SDL support for Wayland debuts with the 2.0.2 release, but as experimental and disabled by default.[72]

Wayland compositors[edit]

Typical elements of a window. Neither Wayland nor X11 specify which software has to do the drawing of the window decoration. Weston requires that they be drawn by the client, but KWin will implement server-side decoration.[14]

Display servers that implement the Wayland display server protocol are also called Wayland compositors because they additionally perform the task of a compositing window manager.


Weston is the reference implementation of a Wayland compositor. It is written in C and was initially published under GPLv2, but is currently published under the MIT license. Weston is written for the Linux kernel API, i.e. it is only officially supported to work with the Linux kernel due to dependence on certain features, such as KMS driver, Graphics Execution Manager (GEM), and udev, which have not been implemented yet in other Unix-like operating systems.[77]

Weston is written for the Linux kernel; as of February 2013, an initial port to FreeBSD is in progress.[3]

Weston relies on GEM to share application buffers between the compositor and applications. It contains a plugin system, external "shells" for WM/dock/etc, and Weston supports X clients. Clients are responsible for the drawing of their window borders and their decorations. For rendering, Weston can use OpenGL ES or software (pixman[78]).[79] The full OpenGL implementation is not used, because on most current systems, installing the full OpenGL libraries would also install GLX and other X Window System support libraries as dependencies.[80]

Maynard is a graphical shell and has been written as a plugin for Weston, similar as the GNOME Shell has been written as a plugin to Mutter.[81]

A remote access interface for Weston was proposed in October 2013 by a RealVNC employee.[67]


The Weston code to handle input devices (keyboards, pointers, touch screens, etc.) was split in its own separated library, called libinput.[82][83] The goal was to provide any Wayland compositor with a common way to handle input events while minimizing the amount of custom input code compositors need to include. libinput provides device detection, device handling, input device event processing and abstraction,[84] and it could also provide a generic X.Org input driver in the future. libinput support was first merged in Weston 1.5.[85]

XDG-Shell protocol[edit]

XDG-Shell protocol (see freedesktop.org for XDG) is an extended way to manage surfaces under Wayland compositors (not only Weston). The traditional way to manipulate (maximize, minimize, fullscreen, etc.) surfaces is to use the wl_shell_*() functions, which are part of the core Wayland protocol and live in libwayland-client. An implementation of the xdg-shell protocol, on the contrary, is supposed to be provided by the Wayland compositor. So you will find the xdg-shell-client-protocol.h header in the Weston source tree. Each Wayland compositor is supposed to provide its own implementation.

As of June 2014, XDG-Shell protocol was not versioned and still prone to changes.

xdg_shell is a protocol aimed to substitute wl_shell in the long term, but will not be part of the Wayland core protocol. It starts as a non-stable API, aimed to be used as a development place at first, and once features are defined as required by several desktop shells, it can be finally made stable. It provides mainly two new interfaces: xdg_surface and xdg_popup. The xdg_surface interface implements a desktop-style window, that can be moved, resized, maximized, etc.; it provides a request for creating child/parent relationship. The xdg_popup interface implements a desktop-style popup/menu; an xdg_popup is always transient for another surface, and also has implicit grab.[86]


Major Wayland/Weston releases[87]
Version Date Wayland main features Weston main features
Old version, no longer supported: 0.85 9 Feb 2012[1] First release
Old version, no longer supported: 0.95 24 Jul 2012[88] Began API stabilization
Old version, no longer supported: 1.0 22 Oct 2012[89][90] Stable wayland-client API
Old version, no longer supported: 1.1 15 Apr 2013[91][92] Software rendering.[93] FBDEV, RDP backends
Old version, no longer supported: 1.2 12 Jul 2013[94][95] Stable wayland-server API Color management. Subsurfaces. Raspberry Pi backend
Old version, no longer supported: 1.3 11 Oct 2013[96] More pixel formats. Support for language bindings Android driver support via libhybris
Older version, yet still supported: 1.4 23 Jan 2014[97] New wl_subcompositor and wl_subsurface interfaces Multiple framebuffer formats. logind support for rootless Weston
Current stable version: 1.5 20 May 2014[85] libinput. Fullscreen shell.
Future release: 1.6 Sep 2014[85] xdg-shell interface
Old version
Older version, still supported
Latest version
Latest preview version
Future release


Wayland uses direct rendering over EGL.

Kristian Høgsberg (krh), a software engineer who works on the Linux graphics stack, started Wayland as a spare-time project in 2008, while working for Red Hat;[98] he is now at Intel.[99] His earlier work on X included AIGLX,[100] which enabled hardware acceleration of compositing window managers, and DRI2.[101][102][103]

His stated goal was a system in which "every frame is perfect, by which I mean that applications will be able to control the rendering enough that we'll never see tearing, lag, redrawing or flicker."

In October 2010 Wayland became a freedesktop.org project.[104][105]

Wayland is free software, and the libraries (libwayland-server and libwayland-client) were released under the MIT License, with the demo compositor and clients originally under the GPLv2 license. Moving the whole project to LGPLv2 was planned[106] but did not occur and the project is now switching fully to the MIT License.[107] Wayland works with all Mesa-compatible drivers with DRI2 support[32] as well as Android drivers via the Hybris project.[108][109][110] As of November 2010, Nvidia has no plans to support it in their proprietary drivers.[36][111][needs update] On 4 October 2013 Nvidia released a beta version of their 331.13 driver which supports the EGL API.[112] Although limited to X11, IT publications such as Phoronix and Golem.de noted that EGL support in the Nvidia driver could pave the way for future Wayland support.[113][114]

The developers of Wayland are largely present X.Org Server developers.[115]

The name "Wayland" comes from the town of Wayland, Massachusetts. Høgsberg was driving through that town when the concepts behind Wayland "crystallized".[116]

See also[edit]


  1. ^ a b Høgsberg, Kristian (9 February 2012). "[ANNOUNCE] Wayland and Weston 0.85.0 released". Wayland mailing list. Retrieved 8 June 2013. 
  2. ^ "Wayland and Weston 1.5.0 is released". Retrieved 2014-05-20. 
  3. ^ a b Larabel, Michael (16 February 2013). "Wayland Begins Porting Process To FreeBSD". Phoronix. Retrieved 14 July 2013. 
  4. ^ "Wayland". "Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol." 
  5. ^ Jonathan Corbet (5 November 2010). "Linux Plumbers Conference: Life after X (reporting a talk by Keith Packard)". LWN.net. 
  6. ^ "Wayland FAQ". Retrieved 17 February 2011. 
  7. ^ Kristian Høgsberg (9 November 2010). "Network transparency argument". 
    "Wayland isn't a remote rendering API like X, but that doesn't exclude network transparency. Clients render into a shared buffer and then have to tell the compositor (...) what they changed. The compositor can then send the new pixels in that region out over the network. The Wayland protocol is already violently asynchronous, so it should be able to handle a bit of network lag gracefully. Remote fullscreen video viewing or gaming isn't going to work well, [but] I don't know any other display system that handles that well and transparently."
  8. ^ Michael Larabel (18 August 2011). "Remote Wayland Server Project: Does It Work Yet?". 
  9. ^ Adam Jackson (ajax) (9 November 2010). "[Re:] Ubuntu moving towards Wayland". 
  10. ^ Stone, Daniel (1 February 2013). The real story behind Wayland and X. 42:00 minutes in.  Presentation at linux.conf.au 2013.
    "[W]e think it's going to better at remoting than X."
  11. ^ "The Wayland Situation: Facts About X vs. Wayland". Phoronix.com. 7 June 2013. p. 2. Retrieved 2013-07-18. 
  12. ^ "LFCS 2012: X and Wayland". LWN.net. 11 April 2012. Retrieved 19 March 2014. 
  13. ^ "Wayland/X Compositor Architecture By Example: Enlightenment DR19". Retrieved 4 July 2014. 
  14. ^ a b Gräßlin, Martin (7 February 2013). "Client Side Window Decorations and Wayland". Retrieved 26 February 2014. 
  15. ^ Peres, Martin. "Wayland Compositors - Why and How to Handle Privileged Clients!". Retrieved 26 February 2014. 
  16. ^ "XDC2012: Graphics stack security". LWN.net. Retrieved 2013-07-18. 
  17. ^ Stone, Daniel (28 January 2013). "The real story behind Wayland and X linux.conf.au". 
  18. ^ "Wayland architecture". freedesktop.org. Retrieved 2013-07-18. 
  19. ^ "X Clients under Wayland (XWayland)". Wayland project. Retrieved 18 July 2014. 
  20. ^ "ANNOUNCE: xorg-server 1.16.0". freedesktop.org. 2014-07-17. 
  21. ^ "Getting started with Lighthouse". Retrieved 17 December 2010. 
  22. ^ Kristian Høgsberg (25 January 2011). "Add wayland lighthouse plugin". 
  23. ^ Nokia (15 December 2011). "Qt Lighthouse git-repository". 
  24. ^ Michael Larabel (22 December 2010). "GTK+3 Now Uses X Input 2 By Default, New Back-End Caps". 
  25. ^ Matthias Clasen (21 December 2010). "GTK+ 2.91.7 released". 
  26. ^ Kristian Høgsberg (3 January 2011). "Multiple backends for GTK+". 
  27. ^ "Wayland Backend DRM | IVI Layer Management". GENIVI Alliance. Retrieved 2013-07-15. 
  28. ^ "Maliit Status Update". Posterous. 2 April 2013. Archived from the original on 2013-05-17. Retrieved 2013-10-14. 
  29. ^ "More Maliit Keyboard Improvements: QtQuick2". Murray's Blog. 2 April 2013. Retrieved 2013-10-14. 
  30. ^ "Maliit under Wayland". Retrieved 2013-09-14. 
  31. ^ "wlterm". Freedesktop.org. Retrieved 2014-07-08. 
  32. ^ a b Richard Hillesley (13 February 2012). "Wayland – Beyond X". The H Open. Heise Media UK. p. 3. 
  33. ^ "Mesa/Gallium3D Gets Its First ARM SoC GPU Driver". Phoronix. 12 March 2013. Retrieved 30 July 2013. 
  34. ^ Rob Clark (30 July 2013). "freedreno update: drm/kms and ifc6410". Blogspot. Retrieved 30 July 2013. 
  35. ^ "Nouveau Merged". Phoronix. 20 December 2006. Retrieved 2013-07-30. 
  36. ^ a b Michael Larabel (8 November 2010). "NVIDIA Says It Has No Plans To Support Wayland". Phoronix. 
  37. ^ "Red Hat Picks Up Another Graphics Driver Developer". Phoronix. 15 February 2013. Retrieved 2013-07-30. 
  38. ^ "Red Hat Talks About Nouveau, Open-Source Drivers". Phoronix. 11 May 2010. Retrieved 2013-07-30. 
  39. ^ "The First Jolla Smartphone Runs With Wayland". LinuxG.net. 14 July 2013. Retrieved 2013-10-08. 
  40. ^ "sailfishos main components diagram". 
  41. ^ "our first Jolla will ship with wayland, yes". 
  42. ^ "IVI/IVI Setup". Tizen Wiki. Retrieved 2013-04-08. 
  43. ^ "[IVI] Tizen IVI 3.0-M1 released". Tizen.org. Retrieved 2013-07-15. 
  44. ^ "Glx-Dock/Cairo-Dock Has Been Ported To Wayland". 2014-06-21. 
  45. ^ "Raspberry Pi Case Study". Collabora. Retrieved 2013-08-09. 
  46. ^ "Wayland preview". Raspberry Pi. Retrieved 2013-08-09. 
  47. ^ "Enlightenment and EFL backing Wayland". Enlightenment.org. 14 March 2013. Retrieved 2013-07-15. 
  48. ^ "Enlightenment as Standalone Wayland Compositor". 1 February 2014. Retrieved 2014-02-16. 
  49. ^ "Package wayland". Fedora Project. Retrieved 2013-07-15. 
  50. ^ "Wayland and Fedora". Lists.fedoraproject.org. Retrieved 2013-07-15. 
  51. ^ "You Can Now Run GNOME Shell Wayland On Fedora 20". Phoronix. 3 October 2013. Retrieved 2013-10-08. 
  52. ^ "GNOME / Wayland in Fedora". 3 October 2013. Retrieved 2013-10-08. 
  53. ^ Larabel, Michael (13 March 2013). "GNOME Will Move Full-Speed With Wayland Support". Phoronix. Retrieved 8 Apr 2013. 
  54. ^ "GNOME 3.10 Has Been Officially Released". Phoronix. 25 September 2013. Retrieved 2013-10-08. 
  55. ^ "3.10 Released!". GNOME. 25 September 2013. Retrieved 2013-10-08. 
  56. ^ "GNOME Wayland Initiative". GNOME Project. Retrieved 18 March 2014. 
  57. ^ Grässlin, Martin (28 November 2010). "KWin runs on OpenGL ES". "It does not only help, it is a must have to start working for Wayland. So to say it’s the first part of the KWin port to Wayland" 
  58. ^ Grässlin, Martin (19 January 2011). "On the Road to Modern OpenGL (ES)". Retrieved 2013-07-31. 
  59. ^ Grässlin, Martin. "KWin Hacking++". Retrieved 2013-04-08. 
  60. ^ Larabel, Michael (14 June 2013). "KDE 4.11 Beta Released, Works On Wayland". Phoronix. Retrieved 16 June 2013. 
  61. ^ "ANNOUNCE: New Wayland live CD". Lists.freedesktop.org. 2014-03-21. Retrieved 2014-07-08. 
  62. ^ "MATE Mythbusting | LINUX Unplugged 26". Jupiter Broadcasting. Retrieved 2014-07-08. 
  63. ^ "Split MATE 1.8 roadmap". Ml.mate-desktop.org. Retrieved 2014-07-08. 
  64. ^ "Wayland in Fedora Update | Christian Schaller". Blogs.gnome.org. 2014-07-03. Retrieved 2014-07-08. 
  65. ^ "VNC® Wayland Developer Preview". 2014-07-08. 
  66. ^ "RealVNC Wayland developer preview email". freedesktop.org. 2014-07-09. 
  67. ^ a b "[RFC weston] remote access interface module". freedesktop.org. 2013-10-18. 
  68. ^ "Clutter on Wayland". Retrieved 28 March 2012. 
  69. ^ "Wayland – Enlightenment". Retrieved 6 March 2013. 
  70. ^ "GTK+ 3.10 release mail". 23 September 2013. Retrieved 2013-09-24. 
  71. ^ "Documentation of the Wayland support in GTK+". 3 September 2013. 
  72. ^ Lantinga, Sam (8 March 2014). "SDL 2.0.2 RELEASED!". SDL Project. Retrieved 18 March 2014. 
  73. ^ "Jolla: Sailfish OS, Qt, and open source". LWN. 31 July 2013. 
  74. ^ e-releasemanager (18 August 2013). "A Double Dose Of The W |". E19releasemanager.wordpress.com. Retrieved 2013-08-23. 
  75. ^ Grässlin, Martin. "The History on Wayland Support inside KWin". Martin’s Blog. Retrieved 2013-07-15. 
  76. ^ "Mutter-wayland tarballs". 
  77. ^ "README file from the Wayland source code repository". freedesktop.org. 
  78. ^ http://www.pixman.org/
  79. ^ Stone, Daniel (2013-02-01). The real story behind Wayland and X. 38:46 minutes in.  Presentation at linux.conf.au 2013.
    "It doesn't require OpenGL. Nothing in Wayland requires OpenGL."
  80. ^ Kristian Høgsberg (9 December 2010). "Blender3D & cursor clamping.". 
  81. ^ "Maynard announcement". 2014-04-16. Retrieved 2014-04-16. 
  82. ^ Ådahl, Jonas (12 Nov 2013). "[RFC] Common input device library". Wayland mailing list. 
  83. ^ "[ANNOUNCE] libinput 0.4.0". freedesktop.org. 2014-06-24. 
  84. ^ "libinput". Freedesktop.org. Retrieved 21 May 2014. 
  85. ^ a b c Høgsberg, Kristian (20 May 2014). "Wayland and Weston 1.5.0 is released". Wayland mailing list. 
  86. ^ "xdg_shell: Adding a new shell protocol". freedesktop.org. 2013-12-03. Retrieved 2014-06-14. 
  87. ^ "Wayland". Wayland.freedesktop.org. Retrieved 2013-07-15. 
  88. ^ Høgsberg, Kristian (24 July 2012). "Wayland and Weston 0.95.0 released". Wayland mailing list. Retrieved 14 July 2013. 
  89. ^ Høgsberg, Kristian (22 October 2012). "Wayland and Weston 1.0". Wayland mailing list. Retrieved 14 July 2013. 
  90. ^ Scherschel, Fabian (23 October 2012). "Wayland's 1.0 milestone fixes graphics protocol". The H - Open. Heinz Heise. Retrieved 14 July 2013. 
  91. ^ Larabel, Michael (16 April 2013). "Wayland 1.1 Officially Released With Weston 1.1". Phoronix. Retrieved 14 July 2013. 
  92. ^ Høgsberg, Kristian (15 April 2013). "1.1 Released". Wayland mailing list. Retrieved 18 July 2013. 
  93. ^ Larabel, Michael (6 January 2013). "A Software-Based Pixman Renderer For Wayland's Weston". Phoronix. Retrieved 14 July 2013. 
  94. ^ Larabel, Michael (13 July 2013). "Wayland 1.2.0 Released, Joined By Weston Compositor". Phoronix. Retrieved 14 July 2013. 
  95. ^ Høgsberg, Kristian (12 July 2013). "Wayland and Weston 1.2.0 released". Wayland mailing list. Retrieved 18 July 2013. 
  96. ^ Høgsberg, Kristian (11 October 2013). "Wayland and Weston 1.3 release notes". Wayland mailing list. 
  97. ^ Høgsberg, Kristian (24 January 2014). "Wayland and Weston 1.4 is out". Wayland mailing list. 
  98. ^ Høgsberg, Kristian. "Wayland – A New Display Server for Linux". Linux Plumbers Conference, 2009.  (Video available here [1])
  99. ^ Høgsberg, Kristian. "EGL and GLES1/2 on Linux". Linux Plumbers Conference, 2010. 
  100. ^ "Interview: Kristian Høgsberg". FOSDEM 2007. 6 February 2007. 
  101. ^ Høgsberg, Kristian (8 September 2008). "DRI2 Protocol Spec Draft". 
  102. ^ Høgsberg, Kristian (31 March 2008). "DRI2 Direct Rendering". 
  103. ^ "An Experimental GNOME Shell Running On Wayland". Retrieved 6 Apr 2012. "Founder Kristian Høgsberg responsible for key X improvement of the past few years: DRI2...." 
  104. ^ "Wayland Becomes A FreeDesktop.org Project". Phoronix. 29 October 2010. Retrieved 2013-07-31. 
  105. ^ Kristian Høgsberg (29 October 2010). "Moving to freedesktop.org". Retrieved 2013-07-31. 
  106. ^ Larabel, Michael (22 November 2010). "Wayland License Changing To LGPLv2". Phoronix. Retrieved 21 September 2011. 
  107. ^ Larabel, Michael (20 September 2011). "Wayland Reference Code Being Re-Licensed". Phoronix. Retrieved 21 September 2011. 
  108. ^ Carsten Munk (11 April 2013). "Wayland utilizing Android GPU drivers on glibc based systems, Part 1". Mer Project. Retrieved 2013-07-03. 
  109. ^ Munk, Carsten (8 June 2013). "Wayland utilizing Android GPU drivers on glibc based systems, Part 2". Mer Project. Retrieved 2013-07-03. 
  110. ^ "Jolla Brings Wayland Atop Android GPU Drivers". Phoronix. 11 April 2013. Retrieved 2013-07-03. 
  111. ^ Aaron Plattner, nvidia's primary Linux developer (7 November 2010). "nvidia and the wayland display server". "We have no plans to support Wayland." 
  112. ^ "Nvidia drivers 331.13 beta". 4 October 2013. Retrieved 2013-10-05. "Added support for the EGL API on 32-bit platforms. Currently, the supported client APIs are OpenGL ES 1.1, 2.0 and 3.0, and the only supported window system backend is X11." 
  113. ^ "NVIDIA Releases Major Linux Driver With New Features, EGL". Phoronix. Retrieved 5 October 2013. 
  114. ^ "Unterstützt Nvidia Wayland und Mir?". Golem.de (in German) (Klass & Ihlenfeld Verlag GmbH). Retrieved 5 October 2013. 
  115. ^ Daniel Stone (March 2013). "The real story behind Wayland and X linux.conf.au". Ars Technica. 
  116. ^ Evan Jenkins (March 2011). "The Linux graphics stack from X to Wayland". Ars Technica. 

External links[edit]