Wayland (display server protocol)

Template:Format references Template:Use dmy dates {{#invoke:Infobox|infobox}}

Wayland is a communication protocol that specifies the communication between a display server and its clients, as well as a C library implementation of that protocol.Template:R A display server using the Wayland protocol is called a Wayland compositor, because it additionally performs the task of a compositing window manager.

Wayland is developed by a group of volunteers initially led by Kristian Høgsberg as a free and open-source community-driven project with the aim of replacing the X Window System with a modern, secure^[1]Template:R Template:R Template:R simpler windowing system in Linux and other Unix-like operating systems.Template:R The project's source code is published under the terms of the MIT License, a permissive free software licence.Template:R Template:R

As part of its efforts, the Wayland project also develops a reference implementation of a Wayland compositor called Weston.Template:R

Overview

File:Wayland display server protocol.svg

Template:Ordered list

Starting around 2010, 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. Direct Rendering Infrastructure (DRI), Direct Rendering Manager (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".Template:R

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:Template:R

Template:Quote

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.

Initial versions of Wayland have not provided network transparency, though Høgsberg noted in 2010 that network transparency is possible.Template:R It was attempted as a Google Summer of Code project in 2011, but was not successful.Template:R 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).Template:R As of early 2013, Høgsberg is experimenting with network transparency using a proxy Wayland server which sends compressed images to the real compositor.Template:R Template:R In August 2017, GNOME saw the first such pixel-scraping VNC server implementation under Wayland.Template:R

Software architecture

Protocol architecture

File:Wayland protocol architecture.svg

In the Wayland protocol architecture, a client and a compositor communicate through the Wayland protocol using the reference implementation libraries.

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:Template:R

A low-level layer or wire protocol that handles the inter-process communication between the two involved processes Template:Mdashbclient and compositorTemplate:Mdashband 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.Template:R
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".Template:R

While the low-level layer was written manually in C, the high-level layer is automatically generated from a description of the elements of the protocol stored in XML format.Template:R 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 libwayland-server.Template:R

Protocol overview

The Wayland protocol is described as an "asynchronous object-oriented protocol".Template:R 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.Template:R

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.Template:R 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.Template:R

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.Template:R 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.Template:R

Wayland core interfaces

The interfaces of the current version of Wayland protocol are defined in the file Template:Mono of the Wayland source code.Template:R 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:Template:R

wl_displayTemplate:Snd the core global object, a special object to encapsulate the Wayland protocol itself
wl_registryTemplate:Snd the global registry object, in which the compositor registers all the global objects that it wants to be available to all clients
wl_compositorTemplate:Snd an object that represents the compositor, and is in charge of combining the different surfaces into one output
wl_surfaceTemplate:Snd an object representing a rectangular area on the screen, defined by a location, size and pixel content
wl_bufferTemplate:Snd an object that, when attached to a wl_surface object, provides its displayable content
wl_outputTemplate:Snd an object representing the displayable area of a screen
wl_pointer, wl_keyboard, wl_touchTemplate:Snd objects representing different input devices like pointers or keyboards
wl_seatTemplate:Snd 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.Template:R

Wayland extension interfaces

A Wayland compositor can define and export its own additional interfaces.Template:R 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.4Template:R).

Extension protocols to the core protocol

XDG-Shell 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 Template:Mono. An implementation of the xdg-shell protocol, on the contrary, is supposed to be provided by the Wayland compositor. So you will find the Template:Mono header in the Weston source tree. Each Wayland compositor is supposed to provide its own implementation.

Template:As of, 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.Template:R

IVI-Shell protocol

IVI-Shell is an extension to the Wayland core protocol, targeting in-vehicle infotainment (IVI) devices.^[2]

Rendering model

File:The Linux Graphics Stack and glamor.svg

Wayland compositor and its clients use EGL to draw directly into the framebuffer; X.Org Server with XWayland and Glamor.

The Wayland protocol does not include a rendering API.Template:R Template:R Template:R Template:R Instead, Wayland follows a direct rendering model, in which the client must render the window contents to a buffer shareable with the compositor.Template:R 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 dependent. 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 natively provides this kind of shared memory buffer through the wl_shm and wl_shm_pool interfaces.Template:R 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, OpenGL ES or Vulkan. Client and compositor can share this GPU-space buffer using a special handler to reference it.Template:R This method allows the compositor to avoid the extra data copy through itself of the main memory buffer client-to-compositor-to-GPU method, resulting in faster graphics performance, and is therefore the preferred one. The compositor can further optimize the composition of the final scene to be shown on the display by using the same hardware acceleration API as an API client.

When rendering is completed in a shared buffer, 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.Template:R 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, bind this new buffer to the surface and commit its contents.Template:R The procedure used for rendering, including the number of buffers involved and their management, is entirely under the client control.Template:R

Comparison with other window systems

Template:See also

Differences between Wayland and X

There are several differences between Wayland and X in regards to performance, code maintainability, and security:Template:R

Architecture: The composition manager is a separate, additional feature in X, while Wayland merges display server and compositor as a single function.Template:R Template:R Also, it incorporates some of the tasks of the window manager, which in X is a separate client-side process.Template:R

Compositing: 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.Template:R

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, but delegates to clients such tasks (including the rendering of fonts, widgets, etc.).Template:R Template:R Window decorations can be rendered on the client side (e.g., by a graphics toolkit) or on the server side (by the compositor).Template:R

Security: Wayland isolates the input and output of every window, achieving confidentiality, integrity and availability in both cases; the original X design lacks these important security features,Template:R Template:R Template:R although some extensions have been developed trying to mitigate it.Template:R Template:R Template:R Also, with the vast majority of the code running in the client, less code needs to run with root privileges, improving security,Template:R although multiple popular Linux distributions now allow X to be run without root privileges.^[3]^[4]^[5]^[6]

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. The 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;Template:R however, a compositor can implement any remote desktop protocol to achieve remote display. In addition, there is research into Wayland image streaming and compression that would provide remote frame buffer access similar to that of VNC.Template:R

Compatibility with X

File:XWayland.png

A screenshot showing xwayland

XWayland is an X Server running as a Wayland client, and thus is capable of displaying native X11 client applications in a Wayland compositor environment.Template:R This is similar to the way XQuartz runs X applications in macOS’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.Template:R

Widget toolkits such as Qt5 and GTK3 can switch their graphical back-end at run time,Template:R allowing users to choose at load time whether they want to run the application over X or over Wayland. Qt 5 provides the Template:Code command-line optionTemplate:R to that effect, whereas GTK 3 lets users select the desired GDK back-end by setting the Template:Code Unix environment variable.Template:R Template:R

Wayland compositors

File:Window (windowing system).svg

Typical elements of a window. Neither Wayland nor X11 specifies what software is responsible for rendering the window decoration. Weston requires that they are drawn by the client, but KWin will implement server-side decoration.Template:R

Template:Main

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 Template:Snd the reference implementation of a Wayland compositor; Weston implements client side decorations
LipstickTemplate:Snd mobile graphical shell framework which implements Wayland compositor; it is used in Sailfish OS, Nemo Mobile and AsteroidOS Template:R
Enlightenment claimed full Wayland support since version 0.20Template:R but work is currently underway to land a complete Wayland compositor ^[7]
KWin has nearly complete Wayland support as of 2018Template:Citation needed
Mutter maintains a separate branch for the integration of Wayland for GNOME 3.9 (in September 2013)Template:R
Clayland – a simple example Wayland compositor using Clutter
Westeros – a Wayland compositor library that allows applications to create their own Wayland displays, which allows nesting and embedding of third party applications^[8]
wlroots – a modular Wayland implementation that functions as a base for other compositors, most notably Sway^[9]^[10]
Sway – a tiling Wayland compositor and a drop-in replacement for the i3 window manager for X11^[11]

Template:AnchorWeston

File:PostmarketOS and Weston compositor running on Motorola Moto G.jpg

Weston running on postmarketOS

Weston is the reference implementation of a Wayland compositor^[12] also developed by the Wayland project. It is written in C and published under the MIT License. Weston has official support for only the Linux operating system due to Weston's dependence on certain features of the Linux kernel, such as kernel mode-setting, Graphics Execution Manager (GEM), and udev, which have not been implemented in other Unix-like operating systems.Template:R When running on Linux, handling of the input hardware relies on evdev, while the handling of buffers relies on Generic Buffer Management (GBM). However, in 2013 a prototype port of Weston to FreeBSD was announced.Template:R

Weston supports High-bandwidth Digital Content Protection (HDCP).^[13]

Weston relies on GEM to share application buffers between the compositor and applications. It contains a plug-in system of "shells" for common desktop features like docks and panels.Template:R Clients are responsible for the drawing of their window borders and their decorations. For rendering, Weston can use OpenGL ES Template:R or the pixman library to do software rendering.Template:R 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.Template:R

A remote access interface for Weston was proposed in October 2013 by a RealVNC employee.Template:R

Maynard

File:Maynard desktop.png

Maynard desktop in January 2017

Maynard is a graphical shell and has been written as a plug-in for Weston, just as the GNOME Shell has been written as a plug-in to Mutter.Template:R

libinput

File:Libinput for Wayland compositors.svg

libinput was created to consolidate the input stack across multiple Wayland compositors.

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.Template:R Template:R

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 detectionTemplate:Clarify (via udev), device handling, input device event processing and abstraction.Template:R Template:R

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.Template:R

As GNOME/GTK and KDE Frameworks 5 Template:R have mainlined the required changes, Fedora 22 will replace X.Org's evdev and Synaptics drivers with libinput.Template:R

With version 1.16, the X.Org Server obtained support for the libinput library in form of a wrapper called Template:Mono.Template:R Template:R

Wayland Security Module

Wayland Security Module is a proposition that resembles the Linux Security Module interface found in the Linux kernel.Template:R

Some applications (especially the ones related to accessibility) require privileged capabilities that should work across different Wayland compositors. Currently,Template: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.Template:R

Adoption

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 were 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.

Desktop Linux distributions

As of 2020 most Linux distributions support Wayland out of the box, some notable examples are:

Fedora starting with version 25 uses Wayland for the default GNOME 3.22 desktop session, with X.Org as a fallback if the graphics driver cannot support Wayland.^[14]
Ubuntu ships Wayland as default in Ubuntu 17.10 (Artful Aardvark).^[15] Ubuntu reverted to X.Org for Ubuntu 18.04 LTS, as Wayland still has issues with screen sharing and remote desktop applications, and does not recover as well from window manager crashes.^[16]^[17] In the 20.04 LTS release of Ubuntu, Xorg was still the default.^[18]
Red Hat Enterprise Linux ships Wayland as the default session in version 8.^[19]
Debian ships Wayland as the default session for GNOME since version 10.^[20]
Slackware Linux included Wayland on Feb 20th, 2020^[21] for the development version, -current, which will eventually become version 15.0.
PureOS included Wayland on Feb 20th, 2020 for the development version, -current, which will eventually become version 15.0.^[22]

Notable early adopter:

RebeccaBlackOS is a live USB Debian-based^[23] Linux distribution that allows a convenient way to try out a real Wayland desktop without having to make any modifications to the main operating system of the computer.^[24] It has been used since as early as 2012 to showcase Wayland.^[25]^[26]

Toolkit support

Toolkits supporting Wayland include the following:

Clutter has complete Wayland support.Template:R Template:R Template:R
EFL has complete Wayland support, except for selection.Template:R
GTK 3.20 has complete Wayland support.Template:R
Qt 5 has complete Wayland support, and can be used to write both Wayland compositors and Wayland clients.
SDL support for Wayland debuted with the 2.0.2 releaseTemplate:R and was enabled by default since version 2.0.4.Template:R
GLFW 3.2 has Wayland support.Template:R
FreeGLUT has initial Wayland support.Template:R

Desktop environments

Desktop environments in process of being ported from X to Wayland include GNOME,Template:R KDE Plasma 5 Template:R and Enlightenment.Template:R

In November 2015, Enlightenment e20 was announced with full Wayland support.Template:R Template:R Template:R GNOME 3.20 was the first version to have a full Wayland session.Template:R GNOME 3.22 included much improved Wayland support across GTK, Mutter, and GNOME Shell.^[27] GNOME 3.24 shipped support for the proprietary NVidia drivers under Wayland.^[28]

Wayland support for KDE Plasma was delayed until the release of Plasma 5,Template:R though previously KWin 4.11 got an experimental Wayland support.Template:R The version 5.4 of Plasma was the first with a Wayland session.Template:R During 2020 Klipper was ported to Wayland and the next 5.20 release in October 2020 has the goal to improve screen casting and recording.^[29] At least one core part of KDE: sddm is yet to be ported to Wayland as of September 2020.^[30]

Other software

Other software supporting Wayland includes the following:

Intelligent Input Bus is working on Wayland support, it could be ready for Fedora 22.Template:R
RealVNC published a Wayland developer preview in July 2014.Template:R Template:R Template:R
Maliit is an input method framework that runs under Wayland.Template:R Template:R Template:R
kmscon supports Wayland with wlterm.Template:R
Mesa has Wayland support integrated.Template:R
Eclipse was made to run on Wayland during a GSoC-Project in 2014.Template:R
The Vulkan WSI (Window System Interface) is a set of API calls serve a similar purpose as EGL does for OpenGL ES or GLX for OpenGL. Vulkan WSI includes support for Wayland from day one: VK_USE_PLATFORM_WAYLAND_KHR. Vulkan clients can run on unmodified Wayland servers, including Weston, GENIVI LayerManager, Mutter / GNOME Shell, Enlightenment, and more. The WSI allows applications to discover the different GPUs on the system, and display the results of GPU rendering to a window system.Template:R
SPURV, a compatibility layer for Android applications to run on GNU/Linux distributions using Wayland

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.Template:R
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.Template:R Template:R
Jolla: Smartphones from Jolla use Wayland. 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.Template:R Template:R Template:R
Tizen: Tizen up to 2.x supports Wayland in in-vehicle infotainment (IVI) setupsTemplate:R and from 3.0 onward defaults to Wayland.Template:R^[31]

History

File:Linux graphics drivers DRI Wayland.svg

Wayland uses direct rendering over EGL.

Kristian Høgsberg, a Linux graphics and X.Org developer who previously worked on AIGLX and DRI2, started Wayland as a spare-time project in 2008 while working for Red Hat.Template:R Template:R Template:R Template:R 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." Høgsberg was driving through the town of Wayland, Massachusetts when the underlying concepts "crystallized", hence the name.Template:R Template:R

In October 2010, Wayland became a freedesktop.org project.Template:R Template:R As part of the migration the prior Google Group was replaced by the wayland-devel mailing list as the project's central point of discussion and development.

The Wayland client and server libraries were initially released under the MIT License,Template:R while the reference compositor Weston and some example clients used the GNU General Public License version 2.Template:R Later all the GPL code was relicensed under the MIT license "to make it easier to move code between the reference implementation and the actual libraries".Template:R In 2015 it was discovered that the license text used by Wayland was a slightly different and older version of the MIT license, and the license text was updated to the current version used by the X.Org project (known as MIT Expat License).Template:R

Wayland works with all Mesa-compatible drivers with DRI2 supportTemplate:R as well as Android drivers via the Hybris project.Template:R Template:R Template:R

The developers of Wayland are largely current X.Org Server developers.Template:R

Releases

Major Wayland and Weston releasesTemplate:R
Version	Date	Main features
Version	Date	Wayland	Weston
Template:Version	Template:Dts Template:R	First release.
Template:Version	Template:Dts Template:R	Began API stabilization.
Template:Version	Template:Dts Template:R Template:R	Stable wayland-client API.
Template:Version	Template:Dts Template:R Template:R		Software rendering.Template:R FBDEV, RDP backends.
Template:Version	Template:Dts Template:R Template:R	Stable wayland-server API.	Color management. Subsurfaces. Raspberry Pi backend.
Template:Version	Template:Dts Template:R	More pixel formats. Support for language bindings.	Android driver support via libhybris.
Template:Version	Template:Dts Template:R	New wl_subcompositor and wl_subsurface interfaces.	Multiple framebuffer formats. logind support for rootless Weston.
Template:Version	Template:Dts Template:R		libinput. Fullscreen shell.
Template:Version	Template:Dts Template:R		libinput by default.
Template:Version	Template:Dts Template:R Template:R		Support for the Wayland presentation extension and for surface roles. IVI shell protocol.
Template:Version	Template:Dts Template:R Template:R	Separated headers for core and generated protocol.	Repaint scheduling. Named outputs. Output transformations. Surface-shooting API.
Template:Version	Template:Dts Template:R Template:R	Updated license.	Updated license. New test framework. Triple-head DRM compositor. linux_dmabuf extension.
Template:Version	Template:Dts Template:R Template:R	Drag-and-drop functionality, grouped pointer events.Template:R	Video 4 Linux 2, touch input, debugging improvements.Template:R
Template:Version	Template:Dts Template:R Template:R	New backup loading routine, new setup logic.	Proxy wrappers, shared memory changes, Doxygen-generated HTML docs.
Template:Version	Template:Dts Template:R Template:R	Debugging support improved.	libweston and libweston-desktop. Pointer locking and confinement. Relative pointer support.
Template:Version	Template:Dts Template:R Template:R		The ABI of Weston has been changed, thus the new version was named 2.0.0 rather than 1.13.0.
Template:Version	Template:Dts Template:R Template:R		Weston 3.0.0 was released at the same time.
Template:Version	Template:Dts Template:R Template:R		Weston 4.0.0 was released at the same time.
Template:Version	Template:Dts Template:R Template:R		Weston 5.0.0 was released at the same time.
Template:Version	Template:Dts Template:R Template:R		Weston 6.0.0 was released at the same time.
Template:Version	Template:Dts Template:R Template:R		Weston 7.0.0 was released one month later.
Weston 8^[32]	Template:Dts
Weston 9^[33]	Template:Dts
Template:Version

References

1 }}

     | references-column-width 
     | references-column-count references-column-count-{{#if:1|{{{1}}}}} }}
   | {{#if: 
     | references-column-width }} }}" style="{{#if: 
   | {{#iferror: {{#ifexpr: 1 > 1 }}
     | Template:Column-width
     | Template:Column-count }}
   | {{#if: 
     | Template:Column-width }} }} list-style-type: {{#switch: 
   | upper-alpha
   | upper-roman
   | lower-alpha
   | lower-greek
   | lower-roman = {{{group}}}
   | #default = decimal}};">

Cite error: <ref> tag with name "wllicense" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Wayland homepage" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Wayland FAQ" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Wayland architecture" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "xwayland" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland README" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland releases" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wlprotoxml" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Wayland doc" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Bradford 2011" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Corbet 2010" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Edge 2012" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Edge 2013 jolla" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Graesslin 2013 decorations" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Graesslin 2015" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Graesslin 2015 security" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Griffith 2013" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Hillesley 2012" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Hillesley 2012 p3" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Høgsberg 2008" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Høgsberg 2011 GTK" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Hutterer 2014" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Jenkins 2011" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Kerrisk 2012" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel 2010 freedesktop" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel 2011 remote" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel 2013 pixman" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel 2013 freebsd" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel 2013 Jolla" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel wayland 1.1" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel 2013 kwin" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel wayland 1.2" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel 2015 license" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel 2015 e20" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel 2016 SDL2" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Larabel wayland 1.10" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Paalanen 2012 EGL" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Paalanen 2012" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Paalanen 2014" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Peres 2014" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Schaller 2014" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Scherschel wayland 1.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Vervloesem 2012" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Willis 2013" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "LPC2009" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "FOSDEM2012 interview" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "XDC2014 libinput" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "XDC2014 wayland security" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "FOSDEM2016 wl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "hellowl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "QtWayland" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "GTK Wayland support" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "mutter wayland" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "maynard" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "libinput" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "autoref0004" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "auto" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "auto1" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "auto2" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "efl wayland" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "gtk+ wayland" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "sdl2 wayland" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "glfw wayland" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "GNOME wl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "KDE wl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "enlightenment wl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "e20 wl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "GNOME release plan" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "vizzzion" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "autoref0005" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "autoref0007" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "autoref0008" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Maliit" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "kmscon wl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "eclipse wl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Collabora vulkan" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "genivi" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Collabora RPi" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "RPi wayland" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "tizen 2.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland part1" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland part2" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "autoref0010" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "X.Org Security" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "X11 Security extension" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "XACE" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "GNOME Remote Desktop" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Barnes slides" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Wayland Compositor" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "libinputfosdem15" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Stone 2013 LCA" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "License" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Høgsberg remotewl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Jackson remotewl" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "xorg 1.16" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "Høgsberg wayland GL" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "RealVNC remote" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "libinput stable API" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "libinput fedora 22" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "libinput announce" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "clutter 1.6" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "clutter 1.16" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "autoref0006" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "tizen 3.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland freedesktop" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "original license" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "license clarification" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "license change GPL" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 0.85" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 0.95" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.1" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.2" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.3" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.4" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.5" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.6" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.7" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 1.7" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.8" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 1.8" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.9" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 1.9" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.10" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 1.10" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.11" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 1.11" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.12" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 1.12" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.13" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 2.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.14" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 3.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.15" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 4.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.16" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 5.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.17" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 6.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "wayland 1.18" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 7.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "weston 8.0" defined in <references> is not used in prior text.
Cite error: <ref> tag with name "xdg-shell" defined in <references> is not used in prior text.

Cite error: <ref> tag with name "freeglut wayland" defined in <references> is not used in prior text.

External links

Template:Official website

Template:Freedesktop.org Template:Desktop environments and window managers for X11 and Wayland

[1] Template:Cite web

[2] Template:Cite web

[3] Template:Cite web

[4] Template:Cite web

[5] Template:Cite web

[6] Template:Cite web

[7] Template:Cite web

[8] Template:Cite web

[9] Template:Cite web

[10] Template:Cite web

[11] Template:Cite web

[12] Template:Cite web

[13] Template:Cite web

[14] Template:Cite web

[15] Template:Cite web

[16] Template:Cite web

[17] Template:Cite web

[18] Template:Cite web

[19] Template:Cite web

[20] Template:Cite web

[21] Template:Cite web

[22] Template:Cite web

[23] Template:Cite web

[24] Template:Cite web

[25] Template:Cite web

[26] Template:Cite web

[27] Template:Cite web

[28] Template:Cite web

[29] Template:Cite web

[30] Template:Cite web

[31] Template:Cite web

[32] ttps://lists.freedesktop.org/archives/wayland-devel/2020-January/041147.html

[33] ttps://lists.freedesktop.org/archives/wayland-devel/2020-September/041595.html

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]