Wayland (display server protocol)
Screenshot of a Wayland demonstration
|Original author(s)||Kristian Høgsberg|
|Developer(s)||freedesktop.org et al.|
|Initial release||0.85 / 9 February 2012|
|Stable release||1.9.0 / 21 September 2015|
|Preview release||1.9.92 / 2 February 2016|
|Size||c. 100 KB|
|License||MIT Expat License|
Wayland is a computer 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 the C programming language.
Wayland is developed by a group of volunteers led by Kristian Høgsberg as a free and open-source software community-driven project with the aim of replacing the X Window System with a modern, simpler windowing system in Linux and Unix-like operating systems. The project's source code is published under the terms of the MIT Expat permissive free software licence.
As part of its efforts, the Wayland project also develops a reference implementation of a Wayland compositor called Weston.
- 1 Overview
- 2 Software architecture
- 3 Comparison with other window systems
- 4 Wayland compositors
- 5 Adoption
- 6 History
- 7 See also
- 8 References
- 9 External links
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".
Kristian 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:
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. It was attempted as a Google Summer of Code project in 2011, but was not successful. 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). As of early 2013, Høgsberg is experimenting with network transparency using a proxy Wayland server which sends compressed images to the real compositor.
Wayland protocol follows a client-server model in which clients are the graphical applications requesting the display of pixel buffers on the screen, and the server (compositor) is the service provider controlling the display of these buffers.
The Wayland reference implementation has been designed as a two-layer protocol:
- A low-level layer or wire protocol that handles the inter-process communication between the two involved processes—
client and compositor— and the marshalling of the data that they interchange. This layer is message-based and usually implemented using the kernel IPC services, specifically Unix domain sockets in the case of Linux and Unix-like operating systems.
- A high-level layer built upon it, that handles the information that client and compositor need to exchange to implement the basic features of a window system. This layer is implemented as "an asynchronous object-oriented protocol".
While the low-level layer was written manually in C language, the high-level layer is automatically generated from a description of the elements of the protocol stored in XML format. Every time the protocol description of this XML file changes, the C source code that implements such protocol can be regenerated to include the new changes, allowing a very flexible, extensible and error-proof protocol.
The reference implementation of Wayland protocol is split in two libraries: a library to be used by Wayland clients called
libwayland-client and a library to be used by Wayland compositors called
The Wayland protocol is described as an "asynchronous object-oriented protocol." Object-oriented means that the services offered by the compositor are presented as a series of objects living on the same compositor. Each object implements an interface which has a name, a number of methods (called requests) as well as several associated events. Every request and event has zero or more arguments, each one with a name and a data type. The protocol is asynchronous in the sense that requests do not have to wait for synchronized replies or ACKs, avoiding round-trip delay time and achieving improved performance.
The Wayland clients can make a request (a method invocation) on some object if the object's interface supports that request. The client must also supply the required data for the arguments of such request. This is the way the clients request services from the compositor. The compositor in turn sends information back to the client by causing the object to emit events (probably with arguments too). These events can be emitted by the compositor as a response to a certain request, or asynchronously, subject to the occurrence of internal events (such as one from an input device) or state changes. The error conditions are also signaled as events by the compositor.
For a client to be able to make a request to an object, it first needs to tell the server the ID number it will use to identify that object. There are two types of objects in the compositor: global objects and non-global objects. Global objects are advertised by the compositor to the clients when they are created (and also when they are destroyed), while non-global objects are usually created by other objects that already exist as part of their functionality.
The interfaces and their requests and events are the core elements that define the Wayland protocol. Each version of the protocol includes a set of interfaces, along with their requests and events, which are expected to be in any Wayland compositor. Optionally, a Wayland compositor may define and implement its own interfaces that support new requests and events, thereby extending functionality beyond the core protocol. To facilitate changes to the protocol, each interface contains a "version number" attribute in addition to its name; this attribute allows for distinguishing variants of the same interface. Each Wayland compositor exposes not only what interfaces are available, but also the supported versions of those interfaces.
Wayland core interfaces
The interfaces of the current version of Wayland protocol are defined in the file protocol/wayland.xml of the Wayland source code. This is an XML file that lists the existing interfaces in the current version, along with their requests, events and other attributes. This set of interfaces is the minimum required to be implemented by any Wayland compositor.
Some of the most basic interfaces of the Wayland protocol are:
- wl_display – the core global object, a special object to encapsulate the Wayland protocol itself
- wl_registry – the global registry object, in which the compositor registers all the global objects that it wants to be available to all clients
- wl_compositor – an object that represents the compositor, and is in charge of combining the different surfaces into one output
- wl_surface – an object representing a rectangular area on the screen, defined by a location, size and pixel content
- wl_buffer – an object that, when attached to a wl_surface object, provides its displayable content
- wl_output – an object representing the displayable area of a screen
- wl_pointer, wl_keyboard, wl_touch – objects representing different input devices like pointers or keyboards
- wl_seat – an object representing a seat (a set of input/output devices) in multiseat configurations
A typical Wayland client session starts by opening a connection to the compositor using the wl_display object. This is a special local object that represents the connection and does not live within the server. By using its interface the client can request the wl_registry global object from the compositor, where all the global object names live, and bind those that the client is interested in. Usually the client binds at least a wl_compositor object from where it will request one or more wl_surface objects to show the application output on the display.
Wayland extension interfaces
A Wayland compositor can define and export its own additional interfaces. This feature is used to extend the protocol beyond the basic functionality provided by the core interfaces, and has become the standard way to implement Wayland protocol extensions. Certain compositors can choose to add custom interfaces to provide specialized or unique features. The Wayland reference compositor, Weston, used them to implement new experimental interfaces as a testbed for new concepts and ideas, some of which later became part of the core protocol (such as wl_subsurface interface added in Wayland 1.4).
Extension protocols to the core protocol
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[update], 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.
IVI-Shell protocol is an extension protocol to the Wayland core protocol by the IVI-people.
WRandR is an extension to Wayland intended to facilitate the ability to resize, rotate and reflect the root window of a screen.
The Wayland protocol does not include a rendering API. Instead, Wayland follows a direct rendering model, in which the client must render the window contents to a buffer shareable with the compositor. For that purpose, the client can choose to do all the rendering by itself, use a rendering library like Cairo or OpenGL, or rely on the rendering engine of high-level widget libraries with Wayland support, such as Qt or GTK+. The client can also optionally use other specialized libraries to perform specific tasks, such as Freetype for font rendering.
The resulting buffer with the rendered window contents are stored in a wl_buffer object. The internal type of this object is implementation dependant. The only requirement is that the content data must be shareable between the client and the compositor. If the client uses a software (CPU) renderer and the result is stored in the system memory, then client and compositor can use shared memory to implement the buffer communication without extra copies. The Wayland protocol already provides natively this kind of shared memory buffers through wl_shm and wl_shm_pool interfaces . The drawback of this method is that the compositor may need to do additional work (usually to copy the shared data to the GPU) to display it, which leads to slower graphics performance.
The most typical case is for the client to render directly into a video memory buffer using a hardware (GPU) accelerated API such as OpenGL or OpenGL ES. Client and compositor can share this GPU-space buffer using a special handler to reference it. This method allows the compositor to avoid additional copies of data to the GPU, resulting in faster graphics performance than using shm buffers, and therefore the preferred one. The compositor can further optimize the composition of the final scene to show on the display by using the same hardware acceleration API that the client.
When the rendering is done and the buffer shared, the Wayland client should instruct the compositor to present the rendered contents of the buffer on the display. For this purpose, the client binds the buffer object that stores the rendered contents to the surface object, and sends a "commit" request to the surface, transferring the effective control of the buffer to the compositor. Then, the client waits for the compositor to release the buffer (signaled by an event) if it wants to reuse the buffer to render another frame, or it can use another buffer to render the new frame and, when the rendering is finished, to bind this new buffer to the surface and commit its contents. The procedure used for rendering, including the number of buffers involved and their management, is entirely under the client control.
Comparison with other window systems
Differences between Wayland and X
There are several differences between Wayland and X in regards to performance, code maintainability, and security:
- 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.
- 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.
- Rendering: the X server itself is able to perform rendering, although it can also be instructed to display a rendered window sent by a client. In contrast, Wayland does not expose any API for rendering, instead delegating to a client all such responsibilities (including the rendering of fonts, widgets, etc.). Window decorations can be rendered on the client side (e.g., by a graphics toolkit) or on the server side (by the compositor).
- Security: Wayland isolates the input and output of every window, achieving confidentiality, integrity and availability in both cases; X lacks these important security features. Also, with the vast majority of the code running in the client, less code needs to run with root privileges, improving security.
- 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.
Some of the differences can also be easily understood by comparing the architecture diagrams of both protocols.
Compatibility with X
XWayland is an X Server running as a Wayland client, thus capable of displaying native X11 client applications in a Wayland compositor environment. 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
Qt applications can switch between graphical back-ends like X and Wayland at load time with the
-platform command-line option. In January 2011, Wayland support was moved into the Lighthouse branch of the upstream Qt repository. Qt Lighthouse is shipped in the Qt 4.8 release.
In December 2010, GTK+ added preliminary support for switching back-ends at run time, saying "interesting combinations are X11+Wayland or Quartz+X11". 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. In April 2011, the gdk-wayland-backend branch was merged in the GTK+ master branch.
- Weston – the reference implementation of a Wayland compositor; Weston implements client-side decoration
- Lipstick – mobile graphical shell framework which implements Wayland compositor. It is used in Sailfish OS and Nemo Mobile.
- Enlightenment 0.20 (E20) will have full Wayland support.
- KWin had incomplete Wayland support in April 2013.
- Mutter maintains a separate branch for the integration of Wayland for GNOME 3.9 (in September 2013).
- Clayland is a simple example Wayland compositor using Clutter.
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 Historical Permission Notice and Disclaimer license. Weston is written for the Linux kernel API; that is, Weston only has official support for the Linux kernel due to dependence on certain features, such as Linux's kernel mode-setting, Graphics Execution Manager (GEM), and udev, which have not yet been implemented in other Unix-like operating systems. When running on the Linux kernel, handling of the input hardware relies on evdev, while the handling of buffers relies on Generic Buffer Management (GBM).
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). 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.
Libinput handles input devices for multiple Wayland compositors and also provides a generic X.Org Server input driver. It aims to provide one implementation for multiple Wayland compositors with a common way to handle input events while minimizing the amount of custom input code compositors need to include. libinput provides device detection (via udev), device handling, input device event processing and abstraction.
Version 1.0 of libinput followed version 0.21, and included support for tablets, button sets and touchpad gestures. This version will maintain stable API/ABI.
The Weston code for handling input devices (keyboards, pointers, touch screens, etc.) was split into its own separate library, called libinput, for which support was first merged in Weston 1.5.
Wayland Security Module
Some applications (especially the ones related to accessibility) require privileged capabilities that should work across different Wayland compositors. Currently,[when?] applications under Wayland are generally unable to perform any sensitive tasks such as taking screenshots or injecting input events. Wayland developers are actively looking for feasible ways to handle privileged clients securely and then designing privileged interfaces for them.
Wayland Security Module is a way to delegate security decisions within the compositor to a centralized security decision engine.
A debugger called wldbg was announced July 2015.
As explained in the "Software architecture" section above, the Wayland protocol is designed to be simple so that additional protocols and interfaces need to be defined and implemented to achieve a holistic windowing system. As of July 2014, these additional interfaces are actively being worked on. So, while the toolkits already fully support Wayland, the developers of the graphical shells are cooperating with the Wayland developers creating the necessary additional interfaces.
In general, out of the box support for a full desktop running Wayland in major Linux distributions is still in early stages. However, many distributions are highly interested in eventually switching from X.org to Wayland.
- Fedora is planning for version 24 to change the login manager (GNOME Desktop Manager) to use Wayland by default when the graphics driver supports it. The desktop will still use X.org.
- Sailfish OS by Jolla use Wayland as standard, hence in several devices using it from Jolla. It is also used as standard when licensed Linux Sailfish OS is used with hardware from other vendors or when it is installed into Android devices by users themselves.
Toolkits supporting Wayland include the following:
- Clutter has complete Wayland support.
- EFL has complete Wayland support, except for selection.
- GTK+ 3.10 has complete Wayland 1.2 support.
- Qt 5 has complete Wayland support.
- SDL support for Wayland debuts with the 2.0.2 release, but as experimental and disabled by default.
- GLFW 3.1 will have experimental unadvertised Wayland support.
- FreeGLUT has initial Wayland support
|This section is outdated. (October 2014)|
Desktop environments supporting Wayland include the following:
- KDE support:
- KWin: is in the process of becoming a Wayland compositor, but support is incomplete; support for OpenGL ES output was added in 2010, in version 4.7. 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. Experimental Wayland support is now working in current KWin 4.11.
- KDE Frameworks 5: it is possible to run most applications built on top of Frameworks 5 under a Wayland compositor, without X11, as X11-dependent codepaths have become optional.
- KDE Plasma 5: is based on Frameworks 5, but as e.g. interfaces between the workspace shell, the compositor (KWin) and the display server are not yet well-defined or implemented up-stream, support is incomplete.
- Calligra Suite already has an unofficial but working port to Wayland.
- Glx-Dock has been ported to Wayland.
- The Hawaii desktop environment exclusively supports Wayland.
- GNOME: In March 2013 GNOME developers announced plans for a complete Wayland port within a year. GNOME 3.10 includes initial support that "will enable the project to fully adopt the next generation display and input technology in the future". The current roadmap targets GNOME 3.20 as the first version to be fully ported to Wayland.
- MATE: Wayland support is on MATE’s roadmap for “when MATE will become GTK+3 only”.
Other software supporting Wayland includes the following:
- Intelligent Input Bus is working on Wayland support, it could be ready for Fedora 22
- RealVNC published a Wayland developer preview in July 2014
- Maliit: Maliit, an input method framework, runs under Wayland.
- kmscon supports Wayland with wlterm
- Mesa: Mesa, to which AMD and Intel directly contribute to support their graphics processors, has Wayland support integrated. Within the Mesa projects, drivers for Qualcomm Snapdragon (freedreno) and Nvidia GPUs (nouveau) are being developed by Red Hat and community contributors.
- Eclipse was made to run on Wayland during a GSoC-Project in 2014.
Mobile and embedded hardware
Mobile and embedded hardware supporting Wayland includes the following:
- GENIVI Alliance: The GENIVI automotive industry consortium for in-vehicle infotainment (IVI) supports Wayland.
- Raspberry Pi: The Raspberry Pi Foundation in collaboration with Collabora released Maynard and work on improving performance and memory consumption, but do not expect to be able to replace X11 as the default display server until later in 2013
- Sailfish OS: Smartphones from Jolla use Wayland as standard. It is also used as standard when Linux Sailfish OS is used with hardware from other vendors or when it is installed into Android devices by users.
- Tizen: Tizen up to 2.x supports Wayland in in-vehicle infotainment (IVI) setups and from 3.0 onward defaults to Wayland.
Kristian Høgsberg, a software engineer who works on the Linux graphics stack, started Wayland as a spare-time project in 2008 while working for Red Hat (he is now at Intel). His earlier work on X included AIGLX, which enabled hardware acceleration of compositing window managers, and DRI2. 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."
With the demo compositor and clients originally under the GPLv2 license and a LGPLv2 planned, the Wayland libraries (libwayland-server and libwayland-client) were released under the MIT License. Wayland works with all Mesa-compatible drivers with DRI2 support as well as Android drivers via the Hybris project.
On 4 October 2013 Nvidia released a beta version of their 331.13 driver which supports the EGL API. 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. In March 2014, Nvidia announced a change in Wayland was "[throwing] a wrench into things" in their planned support for Wayland.
|Version||Date||Wayland main features||Weston main features|
|Old version, no longer supported: 0.85||9 February 2012||First release|
|Old version, no longer supported: 0.95||24 July 2012||Began API stabilization|
|Old version, no longer supported: 1.0||22 October 2012||Stable wayland-client API|
|Old version, no longer supported: 1.1||15 April 2013||Software rendering. FBDEV, RDP backends|
|Old version, no longer supported: 1.2||12 July 2013||Stable wayland-server API||Color management. Subsurfaces. Raspberry Pi backend|
|Old version, no longer supported: 1.3||11 October 2013||More pixel formats. Support for language bindings||Android driver support via libhybris|
|Old version, no longer supported: 1.4||23 January 2014||New wl_subcompositor and wl_subsurface interfaces||Multiple framebuffer formats. logind support for rootless Weston|
|Old version, no longer supported: 1.5||20 May 2014||libinput. Fullscreen shell.|
|Old version, no longer supported: 1.6||19 September 2014||libinput by default|
|Old version, no longer supported: 1.7||14 February 2015||Support for the Wayland presentation extension and for surface roles. IVI shell protocol.|
|Older version, yet still supported: 1.8||2 June 2015||Separated headers for core and generated protocol||Repaint scheduling. Named outputs. Output transformations. Surface-shooting API.|
|Current stable version: 1.9||21 September 2015||Updated license.||Updated license. New test framework. Triple-head DRM compositor. linux_dmabuf extension.|
|Future release: 1.10||16 February 2016 scheduled|
- Høgsberg, Kristian (9 February 2012). "[ANNOUNCE] Wayland and Weston 0.85.0 released". wayland-devel mailing list.
- Harrington, Bryce (21 September 2015). "[ANNOUNCE] wayland 1.9.0". wayland-devel (Mailing list).
- Harrington, Bryce (3 February 2016). "[ANNOUNCE] wayland 1.9.92". wayland-devel (Mailing list).
- Harrington, Bryce (15 September 2015). "[ANNOUNCE] wayland 1.8.93". freedesktop.org (Mailing list).
- "wayland/wayland: root/COPYING". freedesktop.org. Retrieved 14 June 2015.
- "Wayland's MIT License To Be Updated/Corrected - Phoronix". phoronix.com.
Wayland is a protocol for a compositor to talk to its clients as well as a C library implementation of that protocol.
Wayland is intended as a simpler replacement for X, easier to develop and maintain.
- Jonathan Corbet (5 November 2010). "Linux Plumbers Conference: Life after X (reporting a talk by Keith Packard)". LWN.net.
- "Wayland FAQ". Retrieved 17 February 2011.
- 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."
- Michael Larabel (18 August 2011). "Remote Wayland Server Project: Does It Work Yet?".
- Adam Jackson (ajax) (9 November 2010). "[Re:] Ubuntu moving towards Wayland".
- 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."
- "The Hello Wayland Tutorial". Retrieved 25 July 2014.
- Høgsberg, Kristian. "Wayland Documentation 1.3 - Wire Format". FreeDesktop.org. Retrieved 25 July 2014.
- Høgsberg, Kristian. "Wayland Documentation 1.3 - Basic Principles". FreeDesktop.org. Retrieved 25 July 2014.
- Høgsberg, Kristian. "protocol/wayland.xml". FreeDesktop.org. Retrieved 25 July 2014.
- Høgsberg, Kristian. "Wayland Documentation 1.3 - Wayland Library". FreeDesktop.org. Retrieved 26 July 2014.
- Paalanen, Pekka. "Wayland protocol design: object lifespan". Retrieved 4 September 2014.
- Høgsberg, Kristian. "Wayland Documentation 1.3 - Interfaces". FreeDesktop.org. Retrieved 31 July 2014.
- Høgsberg, Kristian. "Wayland Documentation 1.3 - Versioning". FreeDesktop.org. Retrieved 31 July 2014.
- Høgsberg, Kristian (24 January 2014). "Wayland and Weston 1.4 is out". wayland-devel mailing list.
- "xdg_shell: Adding a new shell protocol". freedesktop.org. 3 December 2013. Retrieved 14 June 2014.
- Høgsberg, Kristian. "Wayland" (PDF). Retrieved 5 September 2014.
No rendering API, all direct rendering
- Høgsberg, Kristian. "Wayland Documentation 1.3 - Wayland Rendering". FreeDesktop.org. Wayland project. Retrieved 4 September 2014.
- "Wayland FAQ". Wayland project. Wayland project. Retrieved 4 September 2014.
Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer.
- Barnes, Jesse. "Introduction to Wayland" (PDF). Intel Open Source Technology Center.
Does not include a rendering API – Clients use what they want and send buffer handles to the server
- Paalanen, Pekka (21 November 2012). "On supporting Wayland GL clients and proprietary embedded platforms". Retrieved 15 December 2015.
Buffer sharing works by creating a handle for a buffer, and passing that handle to another process which then uses the handle to make the GPU access again the same buffer.
- "The Wayland Situation: Facts About X vs. Wayland". Phoronix.com. 7 June 2013. p. 2. Retrieved 18 July 2013.
- "LFCS 2012: X and Wayland". LWN.net. 11 April 2012. Retrieved 19 March 2014.
- "Wayland/X Compositor Architecture By Example: Enlightenment DR19" (PDF). Retrieved 4 July 2014.
- Gräßlin, Martin (7 February 2013). "Client Side Window Decorations and Wayland". Retrieved 26 February 2014.
- Peres, Martin. "Wayland Compositors - Why and How to Handle Privileged Clients!". Retrieved 26 February 2014.
- "XDC2012: Graphics stack security". LWN.net. Retrieved 18 July 2013.
- Stone, Daniel (28 January 2013). "The real story behind Wayland and X linux.conf.au".
- "Wayland architecture". freedesktop.org. Retrieved 18 July 2013.
- "X Clients under Wayland (XWayland)". Wayland project. Retrieved 18 July 2014.
- "ANNOUNCE: xorg-server 1.16.0". freedesktop.org. 17 July 2014.
- "Getting started with Lighthouse". Retrieved 17 December 2010.
- Kristian Høgsberg (25 January 2011). "Add wayland lighthouse plugin".
- Nokia (15 December 2011). "Qt Lighthouse git-repository".
- Michael Larabel (22 December 2010). "GTK+3 Now Uses X Input 2 By Default, New Back-End Caps".
- Matthias Clasen (21 December 2010). "GTK+ 2.91.7 released".
- Kristian Høgsberg (3 January 2011). "Multiple backends for GTK+".
- "Jolla: Sailfish OS, Qt, and open source". LWN. 31 July 2013.
- Grässlin, Martin. "The History on Wayland Support inside KWin". Martin’s Blog. Retrieved 15 July 2013.
- "Mutter-wayland tarballs".
- "README file from the Wayland source code repository". freedesktop.org.
- Larabel, Michael (16 February 2013). "Wayland Begins Porting Process To FreeBSD". Phoronix. Retrieved 14 July 2013.
- "Pixman". pixman.org. Retrieved 16 April 2015.
- Stone, Daniel (1 February 2013). 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."
- Kristian Høgsberg (9 December 2010). "Blender3D & cursor clamping.".
- "Maynard announcement". 16 April 2014. Retrieved 16 April 2014.
- "[RFC weston] remote access interface module". freedesktop.org. 18 October 2013.
- "libinput". Freedesktop.org. Retrieved 21 May 2014.
- "XDC2014 libinput". 2014-10-08.
- "libinput: the road to 1.0".
- "Libinput support added to Touchpad KCM".
- "Libinput now enabled as default xorg driver for F-22 workstation installs".
- Høgsberg, Kristian (20 May 2014). "Wayland and Weston 1.5.0 is released". wayland-devel mailing list.
- Ådahl, Jonas (12 November 2013). "[RFC] Common input device library". Wayland mailing list.
- "libinput - a common input stack for Wayland compositors and X.Org drivers".
- "Replacing xorg-server input- drivers with libinput" (PDF). 2015-02-01. line feed character in
|title=at position 29 (help)
- "Security in Wayland-based desktop environments: Privileged clients, authorization, authentication and sandboxing!". X.Org Foundation. 8 October 2014.
- "announcing wldbg". 2015-07-22.
- Fedora Wiki: Changes/WaylandByDefault
- "The First Jolla Smartphone Runs With Wayland". LinuxG.net. 14 July 2013. Retrieved 8 October 2013.
- "sailfishos main components diagram".
- "our first Jolla will ship with wayland, yes".
- "Clutter on Wayland". Retrieved 28 March 2012.
- "Wayland – Enlightenment". Retrieved 6 March 2013.
- "GTK+ 3.10 release mail". 23 September 2013. Retrieved 24 September 2013.
- Lantinga, Sam (8 March 2014). "SDL 2.0.2 RELEASED!". SDL Project. Retrieved 18 March 2014.
- Berglund, Camilla (8 April 2014). "Implementation for Wayland · Issue #106 · glfw/glfw · GitHub". Retrieved 14 August 2014.
- "FreeGLUT Wayland support merged".
- "Plasma’s Road to Wayland". 25 July 2014.
- 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
- Grässlin, Martin (19 January 2011). "On the Road to Modern OpenGL (ES)". Retrieved 31 July 2013.
- Grässlin, Martin. "KWin Hacking++". Retrieved 8 April 2013.
- Larabel, Michael (14 June 2013). "KDE 4.11 Beta Released, Works On Wayland". Phoronix. Retrieved 16 June 2013.
- "ANNOUNCE: New Wayland live CD". Lists.freedesktop.org. 21 March 2014. Retrieved 8 July 2014.
- "Glx-Dock/Cairo-Dock Has Been Ported To Wayland". 21 June 2014.
- Larabel, Michael (13 March 2013). "GNOME Will Move Full-Speed With Wayland Support". Phoronix. Retrieved 8 April 2013.
- "GNOME 3.10 Has Been Officially Released". Phoronix. 25 September 2013. Retrieved 8 October 2013.
- "3.10 Released!". GNOME. 25 September 2013. Retrieved 8 October 2013.
- "Projects/GTK+/Roadmap". GNOME Project. Retrieved 31 May 2015.
- "ReleasePlanning/FeaturesPlans". GNOME Project. Retrieved 31 May 2015.
- "MATE: Roadmap". wiki.mate-desktop.org. Retrieved 11 November 2015.
- "Wayland in Fedora Update | Christian Schaller". Blogs.gnome.org. 3 July 2014. Retrieved 8 July 2014.
- "VNC® Wayland Developer Preview". 8 July 2014.
- "RealVNC Wayland developer preview email". freedesktop.org. 9 July 2014.
- "Maliit Status Update". Posterous. 2 April 2013. Archived from the original on 17 May 2013. Retrieved 14 October 2013.
- "More Maliit Keyboard Improvements: QtQuick2". Murray's Blog. 2 April 2013. Retrieved 14 October 2013.
- "Maliit under Wayland". Retrieved 14 September 2013.
- "wlterm". Freedesktop.org. Retrieved 8 July 2014.
- Richard Hillesley (13 February 2012). "Wayland – Beyond X". The H Open. Heise Media UK. p. 3.
- "Mesa/Gallium3D Gets Its First ARM SoC GPU Driver". Phoronix. 12 March 2013. Retrieved 30 July 2013.
- Rob Clark (30 July 2013). "freedreno update: drm/kms and ifc6410". Blogspot. Retrieved 30 July 2013.
- "Nouveau Merged". Phoronix. 20 December 2006. Retrieved 30 July 2013.
- Michael Larabel (8 November 2010). "NVIDIA Says It Has No Plans To Support Wayland". Phoronix.
- "Red Hat Picks Up Another Graphics Driver Developer". Phoronix. 15 February 2013. Retrieved 30 July 2013.
- "Red Hat Talks About Nouveau, Open-Source Drivers". Phoronix. 11 May 2010. Retrieved 30 July 2013.
- "Eclipse now runs on Wayland". 18 August 2014.
- "Wayland Backend DRM | IVI Layer Management". GENIVI Alliance. Retrieved 15 July 2013.
- "Raspberry Pi Case Study". Collabora. Retrieved 9 August 2013.
- "Wayland preview". Raspberry Pi. Retrieved 9 August 2013.
- "The First Jolla Smartphone Runs With Wayland". LinuxG.net. 14 July 2013. Retrieved 8 October 2013.
- "sailfishos main components diagram".
- "our first Jolla will ship with wayland, yes".
- "IVI/IVI Setup". Tizen Wiki. Retrieved 8 April 2013.
- "[IVI] Tizen IVI 3.0-M1 released". Tizen.org. Retrieved 15 July 2013.
- Høgsberg, Kristian. "Wayland – A New Display Server for Linux". Linux Plumbers Conference, 2009. (Video available here )
- Høgsberg, Kristian. "EGL and GLES1/2 on Linux". Linux Plumbers Conference, 2010.
- "Interview: Kristian Høgsberg". FOSDEM 2007. 6 February 2007.
- Høgsberg, Kristian (8 September 2008). "DRI2 Protocol Spec Draft".
- Høgsberg, Kristian (31 March 2008). "DRI2 Direct Rendering".
- "An Experimental GNOME Shell Running On Wayland". Retrieved 6 April 2012.
Founder Kristian Høgsberg responsible for key X improvement of the past few years: DRI2....
- Evan Jenkins (March 2011). "The Linux graphics stack from X to Wayland". Ars Technica.
- "Wayland Becomes A FreeDesktop.org Project". Phoronix. 29 October 2010. Retrieved 31 July 2013.
- Kristian Høgsberg (29 October 2010). "Moving to freedesktop.org". Retrieved 31 July 2013.
- Larabel, Michael (22 November 2010). "Wayland License Changing To LGPLv2". Phoronix. Retrieved 21 September 2011.
- Larabel, Michael (20 September 2011). "Wayland Reference Code Being Re-Licensed". Phoronix. Retrieved 21 September 2011.
- Carsten Munk (11 April 2013). "Wayland utilizing Android GPU drivers on glibc based systems, Part 1". Mer Project. Retrieved 3 July 2013.
- Munk, Carsten (8 June 2013). "Wayland utilizing Android GPU drivers on glibc based systems, Part 2". Mer Project. Retrieved 3 July 2013.
- "Jolla Brings Wayland Atop Android GPU Drivers". Phoronix. 11 April 2013. Retrieved 3 July 2013.
- "Nvidia drivers 331.13 beta". 4 October 2013. Retrieved 5 October 2013.
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.
- "NVIDIA Releases Major Linux Driver With New Features, EGL". Phoronix. Retrieved 5 October 2013.
- "Unterstützt Nvidia Wayland und Mir?". Golem.de (in German) (Klass & Ihlenfeld Verlag GmbH). Retrieved 5 October 2013.
- James Jones (28 March 2014). "[PATCH 6/6] Xwayland DDX".
we are actively working on support [for Wayland] and this certainly throws a wrench into things
- Daniel Stone (March 2013). "The real story behind Wayland and X linux.conf.au". Ars Technica.
- "Wayland". Wayland.freedesktop.org. Retrieved 15 July 2013.
- Høgsberg, Kristian (24 July 2012). "Wayland and Weston 0.95.0 released". wayland-devel mailing list.
- Høgsberg, Kristian (22 October 2012). "Wayland and Weston 1.0". wayland-devel mailing list.
- Scherschel, Fabian (23 October 2012). "Wayland's 1.0 milestone fixes graphics protocol". The H - Open. Heinz Heise. Retrieved 14 July 2013.
- Larabel, Michael (16 April 2013). "Wayland 1.1 Officially Released With Weston 1.1". Phoronix. Retrieved 14 July 2013.
- Høgsberg, Kristian (15 April 2013). "1.1 Released". wayland-devel mailing list.
- Larabel, Michael (6 January 2013). "A Software-Based Pixman Renderer For Wayland's Weston". Phoronix. Retrieved 14 July 2013.
- Larabel, Michael (13 July 2013). "Wayland 1.2.0 Released, Joined By Weston Compositor". Phoronix. Retrieved 14 July 2013.
- Høgsberg, Kristian (12 July 2013). "Wayland and Weston 1.2.0 released". wayland-devel mailing list.
- Høgsberg, Kristian (11 October 2013). "Wayland and Weston 1.3 releases are out". wayland-devel mailing list.
- Paalanen, Pekka (19 September 2014). "Wayland and Weston 1.6.0 released". wayland-devel mailing list.
- Harrington, Bryce (14 February 2015). "[ANNOUNCE] wayland 1.7.0". wayland-devel mailing list.
- Harrington, Bryce (14 February 2015). "[ANNOUNCE] weston 1.7.0". wayland-devel mailing list.
- Harrington, Bryce (2 June 2015). "[ANNOUNCE] wayland 1.8.0". wayland-devel mailing list.
- Harrington, Bryce (2 June 2015). "[ANNOUNCE] weston 1.8.0". wayland-devel mailing list.
- Harrington, Bryce (21 September 2015). "[ANNOUNCE] weston 1.9.0". wayland-devel (Mailing list).
- Official website
- Wayland at Open Hub
- Wayland at FOSDEM 2012 by Kristian Høgsberg
- The way to Wayland: Preparing for life After X by Joe 'Zonker' Brockmeier, LWN, 17 November 2010
- Wayland – Beyond X by Richard Hillesley, The H, 13 February 2012
- The Wayland Situation: Facts About X vs. Wayland by Eric Griffith, Phoronix, 7 June 2013