Wayland (protocol)
{{Short description|Display system intended to replace X11}}
{{Use dmy dates|date=November 2014}}
{{Infobox software
| name = Wayland
| logo = Wayland Logo.svg
| logo size = 100px
| screenshot = Weston 10.0 screenshot.png
| caption = Weston, the reference implementation of a Wayland server
| author = Kristian Høgsberg
| developer = freedesktop.org et al.
| released = {{Start date and age|2008|09|30|df=yes}}{{cite web
| url = https://gitlab.freedesktop.org/wayland/wayland/-/commit/97f1ebe8d5c2e166fabf757182c289fed266a45a
| title = Initial commit
| first = Kristian
| last = Høgsberg
| date = 30 September 2008
| access-date = 4 August 2024
}}
| latest release version = Wayland: 1.23,{{r|wayland 1.23}} Weston: 14.0.2{{r|weston 14.0.2}}
| latest release date = {{Start date and age|2025|04|25|df=yes}}
| programming language = C
| operating system = Official: Linux
Unofficial: NetBSD, FreeBSD, OpenBSD, DragonFly BSD{{Cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=Wayland-DragonFlyBSD-Port|title=Wayland & Weston Compositor Ported To DragonFlyBSD - Phoronix|website=www.phoronix.com|access-date=20 July 2016|archive-date=16 August 2016|archive-url=https://web.archive.org/web/20160816072551/https://www.phoronix.com/scan.php?page=news_item&px=Wayland-DragonFlyBSD-Port|url-status=live}}
Compatibility layer: Haiku{{cite web | url=https://discuss.haiku-os.org/t/my-progress-in-wayland-compatibility-layer/12373 | title=My progress in Wayland compatibility layer | date=24 July 2022 }}
| platform =
| genre = {{unbulleted list|Windowing system|Display server}}
| license = MIT License{{r|License}}{{r|wllicense}}{{r|Larabel 2015 license}}
| website = {{URL|https://wayland.freedesktop.org/}}
}}
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.{{r|Wayland homepage}} 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 secure{{cite web |last1=Sengar |first1=Shivam Singh |title=Wayland v/s Xorg : How Are They Similar & How Are They Different |url=https://www.secjuice.com/wayland-vs-xorg/ |website=secjuice |date=16 June 2018 |access-date=10 September 2020 |archive-date=23 September 2020 |archive-url=https://web.archive.org/web/20200923224243/https://www.secjuice.com/wayland-vs-xorg/ |url-status=live}}{{r|Kerrisk 2012}}{{r|Peres 2014}}{{r|Graesslin 2015 security}} and simpler windowing system for Linux and other Unix-like operating systems.{{r|Wayland homepage|Wayland FAQ}} The project's source code is published under the terms of the MIT License, a permissive free software licence.{{r|Wayland FAQ}}{{r|License}}
As part of its efforts, the Wayland project also develops a implementation of a Wayland compositor called Weston.{{r|Wayland homepage}}
Overview
[[File:Wayland display server protocol.svg|thumb|right|upright=1.6|{{ordered list
| The evdev module of the Linux kernel gets an event and sends it to the Wayland compositor.
| The Wayland compositor looks through its scenegraph to determine which window should receive the event. The scenegraph corresponds to what is on screen and the Wayland compositor understands the transformations that it may have applied to the elements in the scenegraph. Thus, the Wayland compositor can pick the right window and transform the screen coordinates to window local coordinates, by applying the inverse transformations. The types of transformation that can be applied to a window is only restricted to what the compositor can do, as long as it can compute the inverse transformation for the input events.
| As in the X case, when the client receives the event, it updates the UI in response. But in the Wayland case, the rendering happens by the client via EGL, and the client just sends a request to the compositor to indicate the region that was updated.
| The Wayland compositor collects damage requests from its clients and then re-composites the screen. The compositor can then directly issue an ioctl to schedule a pageflip with KMS.}}]]
The Wayland Display Server project was started by Red Hat developer Kristian Høgsberg in 2008.{{cite web|url=https://www.phoronix.com/scan.php?page=article&item=wayland_q209&num=1|title=The State Of The Wayland Display Server|author=Michael Larabel|date=20 May 2009|work=Phoronix|access-date=17 October 2021|archive-date=17 October 2021|archive-url=https://web.archive.org/web/20211017212244/https://www.phoronix.com/scan.php?page=article&item=wayland_q209&num=1|url-status=live}}
Beginning around 2010, Linux desktop graphics have 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".{{r|Corbet 2010}}
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:{{r|Wayland FAQ}}
{{blockquote|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.
Initial versions of Wayland have not provided network transparency, though Høgsberg noted in 2010 that network transparency is possible.{{r|Høgsberg remotewl}}
It was attempted as a Google Summer of Code project in 2011, but was not successful.{{r|Larabel 2011 remote}}
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).{{r|Jackson remotewl}} As of early 2013, Høgsberg was experimenting with network transparency using a proxy Wayland server which sends compressed images to the real compositor.{{r|Stone 2013 LCA}}{{r|Willis 2013}} In August 2017, GNOME saw the first such pixel-scraping VNC server implementation under Wayland.{{r|GNOME Remote Desktop}} In modern Wayland compositors, network transparency is handled in an [https://github.com/flatpak/xdg-desktop-portal xdg-desktop-portal implementation] that implements the RemoteDesktop portal.
Many Wayland compositors also include an [https://github.com/flatpak/xdg-desktop-portal xdg-desktop-portal implementation] for common tasks such as a native file picker for native applications and sandboxes such as Flatpak ([https://github.com/flatpak/xdg-desktop-portal-gtk xdg-desktop-portal-gtk] is commonly used as a fallback filepicker), screen recording, network transparency, screenshots, color picking, and other tasks that could be seen as needing user intervention and being security risks otherwise. Note that xdg-desktop-portal is not Flatpak or Wayland-specific, and can be used with alternative packaging systems and windowing systems.
Software architecture
=Protocol architecture=
File:Wayland protocol architecture.svg
The 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:{{r|hellowl}}
- A low-level layer or wire protocol that handles the inter-process communication between the two involved processes{{mdashb}}client and compositor{{mdashb}}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 other Unix-like operating systems.{{cite web |url=https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Wire-Format |title=Chapter 4. Wayland Protocol and Model of Operation |at=Wire Format |work=The Wayland Protocol |last=Høgsberg |first=Kristian}}
- 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".{{cite web |url=https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles |title=Chapter 4. Wayland Protocol and Model of Operation |at=Basic Principles |work=The Wayland Protocol |last=Høgsberg |first=Kristian}}
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.{{r|wlprotoxml}} 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
.{{cite web |url=https://wayland.freedesktop.org/docs/html/apb.html#id-1.10.2 |title=Appendix B. Client API |at=Introduction |work=The Wayland Protocol |last=Høgsberg |first=Kristian}}
=Protocol overview=
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.{{r|Paalanen 2014}}
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.{{cite web |url=https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Interfaces |title=Chapter 4. Wayland Protocol and Model of Operation |at=Interfaces |work=The Wayland Protocol |last=Høgsberg |first=Kristian}} 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.{{cite web |url=https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Versioning |title=Chapter 4. Wayland Protocol and Model of Operation |at=Versioning |work=The Wayland Protocol |last=Høgsberg |first=Kristian}}
==Wayland core interfaces==
The interfaces of the current version of Wayland protocol are defined in the file {{mono|protocol/wayland.xml}} of the Wayland source code.{{r|wlprotoxml}} 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{{snd}} the core global object, a special object to encapsulate the Wayland protocol itself
- wl_registry{{snd}} the global registry object, in which the compositor registers all the global objects that it wants to be available to all clients
- wl_compositor{{snd}} an object that represents the compositor, and is in charge of combining the different surfaces into one output
- wl_surface{{snd}} an object representing a rectangular area on the screen, defined by a location, size and pixel content
- wl_buffer{{snd}} an object that, when attached to a wl_surface object, provides its displayable content
- wl_output{{snd}} an object representing the displayable area of a screen
- wl_pointer, wl_keyboard, wl_touch{{snd}} objects representing different input devices like pointers or keyboards
- wl_seat{{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.{{r|Paalanen 2014}}
==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{{r|wayland 1.4}}).
=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 {{mono|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 {{mono|xdg-shell-client-protocol.h}} header in the Weston source tree.
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.{{r|xdg-shell}}
==IVI-Shell protocol==
IVI-Shell is an extension to the Wayland core protocol, targeting in-vehicle infotainment (IVI) devices.{{cite web|url=https://github.com/GENIVI/wayland-ivi-extension|title=GENIVI/wayland-ivi-extension|website=GitHub|date=17 November 2021|access-date=17 August 2016|archive-date=24 March 2017|archive-url=https://web.archive.org/web/20170324145817/https://github.com/GENIVI/wayland-ivi-extension|url-status=live}}
=Rendering model=
File:The Linux Graphics Stack and glamor.svg 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.{{cite web |url=https://wayland.freedesktop.org/docs/html/ch03.html#sect-Wayland-Architecture-wayland_architecture |title=Chapter 3. Wayland Architecture |at=X vs. Wayland Architecture |work=The Wayland Protocol |last=Høgsberg |first=Kristian}}{{r|Wayland FAQ}}{{r|Vervloesem 2012}}{{r|Barnes slides|p=2}} Instead, Wayland follows a direct rendering model, in which the client must render the window contents to a buffer shareable with the compositor.{{cite web |url=https://wayland.freedesktop.org/docs/html/ch03.html#sect-Wayland-Architecture-wayland_rendering |title=Chapter 3. Wayland Architecture |at=Wayland Rendering |work=The Wayland Protocol |last=Høgsberg |first=Kristian}} 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{{cite web |url=https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shm |title=Appendix A. Wayland Protocol Specification |at=wl_shm - shared memory support |work=The Wayland Protocol |last=Høgsberg |first=Kristian}} and wl_shm_pool{{cite web |url=https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_shm_pool |title=Appendix A. Wayland Protocol Specification |at=wl_shm_pool - a shared memory pool |work=The Wayland Protocol |last=Høgsberg |first=Kristian}} 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, OpenGL ES or Vulkan. Client and compositor can share this GPU-space buffer using a special handler to reference it.{{r|Paalanen 2012}} 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.{{r|hellowl}} 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.{{r|Wayland doc|page=7}} The procedure used for rendering, including the number of buffers involved and their management, is entirely under the client control.{{r|Wayland doc|page=7}}
Comparison with other window systems
{{See also|Mir (software)#Software architecture|label 1=Mir software architecture}}
=Differences between Wayland and X=
There are several differences between Wayland and X with regard to performance, code maintainability, and security:{{r|Griffith 2013}}
; Architecture : The composition manager is a separate, additional feature in X, while Wayland merges display server and compositor as a single function.{{r|Wayland architecture}}{{r|Vervloesem 2012}} Also, it incorporates some of the tasks of the window manager, which in X is a separate client-side process.{{r|Edge 2012}}
; 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.{{r|Wayland Compositor|pages=8-11}}
; 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.).{{r|Wayland architecture}}{{r|Vervloesem 2012}} Window decorations are to be rendered on the client side (e.g., by a graphics toolkit), or on the server side (by the compositor) with the opt-in [https://wayland.app/protocols/xdg-decoration-unstable-v1 xdg-decoration] protocol, if the compositor chooses to implement such functionality.{{r|Graesslin 2013 decorations}}
; Security : Wayland isolates the input and output of every window, achieving confidentiality, integrity and availability for both. The original X design lacked these important security features,{{r|Kerrisk 2012}}{{r|Peres 2014}}{{r|Graesslin 2015 security}} although some extensions have been developed trying to mitigate it.{{r|X.Org Security}}{{r|X11 Security extension}}{{r|XACE}}
: Also, with the vast majority of the code running in the client, less code needs to run with root privileges, improving security,{{r|Kerrisk 2012}} although multiple popular Linux distributions now allow the X server to be run without root privileges.{{cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=Debian-Non-Root-X|title=Debian Moves To Non-Root X.Org Server By Default - Phoronix|website=www.phoronix.com|access-date=2 April 2018|archive-date=2 April 2018|archive-url=https://web.archive.org/web/20180402225807/https://www.phoronix.com/scan.php?page=news_item&px=Debian-Non-Root-X|url-status=live}}{{cite web|url=https://wiki.gentoo.org/wiki/Non_root_Xorg|title=Non root Xorg - Gentoo Wiki|website=wiki.gentoo.org|access-date=2 April 2018|archive-date=2 April 2018|archive-url=https://web.archive.org/web/20180402163248/https://wiki.gentoo.org/wiki/Non_root_Xorg|url-status=live}}{{cite web|url=https://wiki.ubuntu.com/X/Rootless|title=X/Rootless - Ubuntu Wiki|website=wiki.ubuntu.com|access-date=2 April 2018|archive-date=2 April 2018|archive-url=https://web.archive.org/web/20180402225623/https://wiki.ubuntu.com/X/Rootless|url-status=live}}{{cite web|url=https://bugzilla.redhat.com/show_bug.cgi?id=1078902|title=1078902 – Xorg without root rights|website=bugzilla.redhat.com|access-date=2 April 2018|archive-date=2 April 2018|archive-url=https://web.archive.org/web/20180402225512/https://bugzilla.redhat.com/show_bug.cgi?id=1078902|url-status=live}}
; 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;{{r|Wayland FAQ}} 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.{{r|Willis 2013}}
=Compatibility with X=
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.{{r|xwayland}} 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.{{r|xorg 1.16}}
Widget toolkits such as Qt5 and GTK3 can switch their graphical back-end at run time,{{r|Høgsberg 2011 GTK}} allowing users to choose at load time whether they want to run the application over X or over Wayland. Qt 5 provides the {{code|-platform}} command-line option{{r|QtWayland}} to that effect, whereas GTK 3 lets users select the desired GDK back-end by setting the {{code|GDK_BACKEND}} Unix environment variable.{{r|Høgsberg 2011 GTK}}{{r|GTK Wayland support}}
Wayland compositors
{{Main|List of display servers#Wayland|l1=List of Wayland compositors}}
File:Window (windowing system).svg. The Wayland protocol does not specify what software is responsible for rendering the window decoration.{{r|Graesslin 2013 decorations}}]]
File:KDE Plasma 5.24 on Arch Linux screenshot.png|thumb]]
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.
A library called wlroots is a modular Wayland implementation that functions as a base for several compositors{{cite web|url=https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/README.md|title=README.md|work=wlroots project on GitLab|date=2 February 2023 }}
Some notable Wayland compositors are:
- Weston{{snd}}an implementation from the Wayland development team. Weston implements client side decorations.
- Enlightenment claimed full Wayland support since version 0.20{{r|Larabel 2015 e20}} but work is currently underway to land a complete Wayland compositor{{Cite web|url=https://www.enlightenment.org/about-wayland|title=Wayland|website=www.enlightenment.org|access-date=8 March 2016|archive-date=9 March 2016|archive-url=https://web.archive.org/web/20160309102604/https://www.enlightenment.org/about-wayland|url-status=live}}
- KWin has nearly complete Wayland support as of 2021{{Cite web|date=2021-02-16|title=Plasma 5.21|url=https://kde.org/announcements/plasma/5/5.21.0/|access-date=2021-03-09|website=KDE Community|language=en|archive-date=8 March 2021|archive-url=https://web.archive.org/web/20210308140934/https://kde.org/announcements/plasma/5/5.21.0/|url-status=live}}
- Mutter maintained a separate branch for the integration of Wayland for GNOME 3.9 (in September 2013);{{r|mutter wayland}} in the 3.13.1 release in 2014, the Wayland branch was merged into the main repository.{{cite web |url=https://gitlab.gnome.org/GNOME/mutter/-/commit/a7665a3e05bdbfa5540dc1ea92bac10517909d15 |title=Bump version to 3.13.1|date=30 April 2014}}
- Clayland – a simple example Wayland compositor using Clutter
- Sway – a tiling Wayland compositor, based on wlroots; it is a drop-in replacement for the i3 X11 window manager.{{cite web|url=https://swaywm.org/|title=Sway|website=swaywm.org|access-date=2018-12-20|archive-date=20 December 2018|archive-url=https://web.archive.org/web/20181220230525/https://swaywm.org/|url-status=live}}{{cite web |title=swaywm/wlroots |url=https://github.com/swaywm/wlroots |access-date=2018-10-28 |website=GitHub |language=en |archive-date=19 December 2018 |archive-url=https://web.archive.org/web/20181219001720/https://github.com/swaywm/wlroots |url-status=live}}{{cite web |title=swaywm/sway |url=https://github.com/swaywm/sway |access-date=2018-10-28 |website=GitHub |language=en |archive-date=28 August 2019 |archive-url=https://web.archive.org/web/20190828153524/https://github.com/swaywm/sway |url-status=live}}
- Hyprland{{snd}}an independent tiling Wayland compositor written in C++. Noteworthy features of Hyprland include dynamic tiling, tabbed windows, a clean and readable C++ code-base, and a custom renderer that provides window animations, rounded corners, and Dual-Kawase Blur on transparent windows.{{Cite web |title=Hyprland - ArchWiki |url=https://wiki.archlinux.org/title/Hyprland |access-date=2024-01-28 |website=wiki.archlinux.org}}{{Cite web |title=Hyprland: Dynamic tiling window compositor with the looks |url=https://hyprland.org/ |access-date=2024-01-28 |website=hyprland.org |language=en}}
- Woodland{{snd}}wlroots-based window-stacking compositor for Wayland written in C, inspired by TinyWL and focused on simplicity and stability.
- labwc{{snd}}a wlroots-based window-stacking compositor for Wayland, inspired by Openbox. It follows a similar approach and coding style to Sway.{{Cite web |title=labwc |url=https://labwc.github.io/ |access-date=2025-05-28 |website=labwc.github.io |language=en}}
=<span class="anchor" id="WESTON"></span>Weston=
Weston is a Wayland compositor previously developed as the reference implementation of the protocol by the Wayland project.{{cite web |last1=Ser |first1=Simon |title=Remove "the reference Wayland compositor" |url=https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1014 |website=FreeDesktop GitLab |access-date=14 May 2025}}{{cite web |url=https://gitlab.freedesktop.org/wayland/weston/-/raw/main/README.md |title=README |website=gitlab.freedesktop.org |access-date=4 August 2024}} It is written in C and released under the MIT License.
Weston officially supports only Linux due to dependencies on kernel-specific features such as kernel mode-setting (KMS), the Graphics Execution Manager (GEM), and udev. On Linux, it handles input via evdev and buffer management via Generic Buffer Management (GBM). A prototype port for FreeBSD was announced in 2013.{{r|Larabel 2013 freebsd}}
The compositor supports High-bandwidth Digital Content Protection (HDCP){{cite web|url=https://gitlab.freedesktop.org/wayland/weston/merge_requests/48/diffs?commit_id=05dc6b86431fe040f91ca7b4cf122fa9dc4dd8dd|title=Adding Content protection support in drm-backend (!48) · Merge Requests · wayland / weston|website=GitLab|date=6 November 2018 |language=en|access-date=2019-10-27|archive-date=27 August 2022|archive-url=https://web.archive.org/web/20220827010905/https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/48/diffs?commit_id=05dc6b86431fe040f91ca7b4cf122fa9dc4dd8dd|url-status=live}} and uses GEM to share buffers between applications and the compositor. It features a plug-in architecture with "shells" that provide elements like docks and panels.{{r|Willis 2013}} Applications are responsible for rendering their own window decorations.
Weston supports rendering via OpenGL ES{{r|Paalanen 2012 EGL}} or the pixman library for software rendering.{{r|Larabel 2013 pixman}} The full OpenGL stack is avoided to prevent pulling in GLX and other X Window System dependencies.{{r|Høgsberg wayland GL}}
A remote desktop interface for Weston was proposed in 2013 by a developer from RealVNC.{{r|RealVNC remote}}
==<span class="anchor" id="MAYNARD"></span>Maynard==
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.{{r|maynard}}
The Raspberry Pi in collaboration with Collabora released Maynard.{{r|Collabora RPi}}{{r|RPi wayland}}
{{Clear}}
=libinput=
File:Libinput for Wayland compositors.svg
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.{{r|wayland 1.5}}{{r|libinput announce}}
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{{clarify|reason=both input and output devices?|date=December 2016}} (via udev), device handling, input device event processing and abstraction.{{r|libinput}}{{r|XDC2014 libinput}}
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.{{r|libinput stable API}}
As GNOME/GTK and KDE Frameworks 5{{r|autoref0004}} have mainlined the required changes, Fedora 22 will replace X.Org's evdev and Synaptics drivers with libinput.{{r|libinput fedora 22}}
With version 1.16, the X.Org Server obtained support for the libinput library in form of a wrapper called {{mono|xf86-input-libinput}}.{{r|Hutterer 2014}}{{r|libinputfosdem15}}
{{Clear}}
=Wayland Security Module=
Wayland Security Module is a proposition that resembles the Linux Security Module interface found in the Linux kernel.{{r|XDC2014 wayland security}}
Some applications (especially the ones related to accessibility) require privileged capabilities that should work across different Wayland compositors. Currently,{{When|date=October 2014}} applications under Wayland are generally unable to perform any sensitive tasks such as taking screenshots or injecting input events without going through [https://github.com/flatpak/xdg-desktop-portal xdg-desktop-portal] or obtaining privileged access to the system.
Wayland Security Module is a way to delegate security decisions within the compositor to a centralized security decision engine.{{r|XDC2014 wayland security}}
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:
- Debian ships Wayland as the default session for GNOME since version 10 (Buster), released 6 July 2019.{{cite web|url=https://wiki.debian.org/NewInBuster|title=NewInBuster - Debian Wiki|website=wiki.debian.org|access-date=2019-07-15|archive-date=25 September 2019|archive-url=https://web.archive.org/web/20190925065917/https://wiki.debian.org/NewInBuster|url-status=live}}
- Fedora starting with version 25 (released 22 November 2016) uses Wayland for the default GNOME 3.22 desktop session, with X.Org as a fallback if the graphics driver cannot support Wayland.{{Cite web |title=Changes/WaylandByDefault - Fedora Project Wiki |url=https://fedoraproject.org/wiki/Changes/WaylandByDefault |access-date=2020-11-09 |website=fedoraproject.org |archive-date=27 December 2015 |archive-url=https://web.archive.org/web/20151227103524/https://fedoraproject.org/wiki/Changes/WaylandByDefault |url-status=live}} Fedora uses Wayland as the default for KDE desktop session starting with version 34 (released 27 April 2021)
- Manjaro ships Wayland as default in the Gnome edition of Manjaro 20.2 (Nibia) (released 22 November 2020).{{cite web |title=Manjaro 20.2 Nibia got released |date=3 December 2020 |url=https://forum.manjaro.org/t/manjaro-20-2-nibia-got-released/41034 |access-date=3 December 2020 |archive-date=4 December 2020 |archive-url=https://web.archive.org/web/20201204122710/https://forum.manjaro.org/t/manjaro-20-2-nibia-got-released/41034 |url-status=live}}
- Raspberry Pi OS, a port of Debian, has offered the option to use Wayland since version 11 (Bullseye) was released on 3 December 2021 and it became the default in version 12 (Bookworm) released on 10 October 2023.
- RebeccaBlackOS is a live USB Debian-based{{cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=RBOS-2016-02-08|title=Wayland Live OS Is Now Based On Debian Testing, Working KDE Wayland Support|publisher=Phoronix|access-date=14 January 2020|archive-date=11 August 2019|archive-url=https://web.archive.org/web/20190811055252/https://www.phoronix.com/scan.php?page=news_item&px=RBOS-2016-02-08|url-status=live}} 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.{{cite web|url=https://sourceforge.net/projects/rebeccablackos/|title=RebeccaBlackOS|publisher=Sourceforge|access-date=11 October 2016|archive-date=25 November 2016|archive-url=https://web.archive.org/web/20161125215104/https://sourceforge.net/projects/rebeccablackos/|url-status=live}} It has been used since as early as 2012 to showcase Wayland.{{cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=MTA3Njk|title=Trying Out Wayland With Rebecca Black|publisher=Phoronix|access-date=14 January 2020|archive-date=18 May 2020|archive-url=https://web.archive.org/web/20200518210256/https://www.phoronix.com/scan.php?page=news_item&px=MTA3Njk|url-status=live}}{{cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=MTUzNTU|title=New Wayland Live CD Has A Lot Of Features|publisher=Phoronix|access-date=14 January 2020|archive-date=18 May 2020|archive-url=https://web.archive.org/web/20200518212840/https://www.phoronix.com/scan.php?page=news_item&px=MTUzNTU|url-status=live}}
- Red Hat Enterprise Linux ships Wayland as the default session in version 8, released 7 May 2019.{{cite web|url=https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.0_release_notes/rhel-8_0_0_release#desktop|title=Release notes for Red Hat Enterprise Linux 8.0|website=Red Hat Customer Portal|language=en|access-date=2020-12-25|archive-date=25 November 2020|archive-url=https://web.archive.org/web/20201125003517/https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/8.0_release_notes/rhel-8_0_0_release#desktop|url-status=live}}
- Ubuntu shipped with Wayland by default in Ubuntu 17.10 (Artful Aardvark).{{cite web|url=https://wiki.ubuntu.com/ArtfulAardvark/ReleaseNotes#Ubuntu_Desktop|title=ReleaseNotes for Ubuntu 17.10|publisher=Canonical|access-date=10 November 2017|archive-date=24 November 2017|archive-url=https://web.archive.org/web/20171124175600/https://wiki.ubuntu.com/ArtfulAardvark/ReleaseNotes#Ubuntu_Desktop|url-status=live}} However, Ubuntu 18.04 LTS reverted to X.Org by default due to several issues.{{cite web|url=https://www.neowin.net/news/ubuntu-1804-will-revert-to-long-in-the-tooth-xorg/|title=Ubuntu 18.04 will revert to long-in-the-tooth Xorg|access-date=16 December 2023}}{{cite web|url=https://insights.ubuntu.com/2018/01/26/bionic-beaver-18-04-lts-to-use-xorg-by-default/|title=Bionic Beaver 18.04 LTS to use Xorg by default|publisher=Canonical|access-date=18 February 2018|archive-date=18 February 2018|archive-url=https://web.archive.org/web/20180218211218/https://insights.ubuntu.com/2018/01/26/bionic-beaver-18-04-lts-to-use-xorg-by-default/|url-status=live}} Since Ubuntu 21.04, Wayland is the default again.{{cite web|title=Ubuntu 21.04 is here|url=https://ubuntu.com/blog/ubuntu-21-04-is-here|url-status=live|archive-url=https://web.archive.org/web/20210422140245/https://ubuntu.com//blog/ubuntu-21-04-is-here|archive-date=22 April 2021|access-date=14 June 2021|website=Canonical Ubuntu Blog}}
- Slackware Linux included Wayland on 20 February 2020{{cite web|url=http://www.slackware.com/changelog/current.php?cpu=x86_64|title=Slackware ChangeLogs|publisher=Slackware Linux|access-date=2020-02-26|archive-date=30 January 2020|archive-url=https://web.archive.org/web/20200130153903/http://www.slackware.com/changelog/current.php?cpu=x86_64|url-status=live}} for the development version, -current, which became version 15.0.
=Toolkit support=
Toolkits supporting Wayland include the following:
- Clutter has complete Wayland support.{{r|clutter 1.6}}{{r|Bradford 2011}}{{r|clutter 1.16}}
- EFL has complete Wayland support, except for selection.{{r|efl wayland}}
- GTK 3.20 has complete Wayland support.{{r|gtk+ wayland}}
- 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 release{{r|sdl2 wayland}} and was enabled by default since version 2.0.4.{{r|Larabel 2016 SDL2}}
- GLFW 3.2 has Wayland support.{{r|glfw wayland}}
- FreeGLUT has initial Wayland support.{{r|freeglut wayland}}
- FLTK supports Wayland since version 1.4.0 (Nov. 2024).{{cite web |last1=S |first1=A |title=FLTK 1.4.0-1 released on Nov. 18, 2024 |url=https://www.fltk.org/articles.php?L1955 |website=FLTK |publisher=AlbrechtS}}
=Desktop environments=
Desktop environments in the process of being ported from X to Wayland include GNOME,{{r|GNOME wl}} KDE Plasma 6{{r|KDE wl}} and Enlightenment.{{r|enlightenment wl}}
In November 2015, Enlightenment e20 was announced with full Wayland support.{{r|e20 wl}}{{r|Larabel 2015 e20}}{{r|FOSDEM2016 wl}} GNOME 3.20 was the first version to have a full Wayland session.{{r|GNOME release plan}} GNOME 3.22 included much improved Wayland support across GTK, Mutter, and GNOME Shell.{{cite web|url=https://www.phoronix.com/scan.php?page=article&item=gnome-322-features&num=1|title=A Look At The Exciting Features/Improvements Of GNOME 3.22|publisher=Phoronix|access-date=14 January 2020|archive-date=12 August 2020|archive-url=https://web.archive.org/web/20200812095126/https://www.phoronix.com/scan.php?page=article&item=gnome-322-features&num=1|url-status=live}} GNOME 3.24 shipped support for the proprietary Nvidia drivers under Wayland.{{cite web|url=https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Mutter-Mainline-EGLStream|title=GNOME Lands Mainline NVIDIA Wayland Support Using EGLStreams|publisher=Phoronix|access-date=14 January 2020|archive-date=8 August 2019|archive-url=https://web.archive.org/web/20190808131309/https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Mutter-Mainline-EGLStream|url-status=live}}
Wayland support for KDE Plasma was delayed until the release of Plasma 5,{{r|vizzzion}} though previously KWin 4.11 got an experimental Wayland support.{{r|Larabel 2013 kwin}} The version 5.4 of Plasma was the first with a Wayland session.{{r|Graesslin 2015}} During 2020 Klipper was ported to Wayland and Plasma 5.20, released in October 2020, improved screen casting and recording.{{Cite web |last=Sneddon |first=Joey |date=2020-09-17 |title=KDE Plasma 5.20 Looks Like an Awesome Update |url=https://www.omgubuntu.co.uk/2020/09/kde-plasma-5-20-release-features |access-date=2024-06-14 |website=OMG! Ubuntu |language=en-GB}}{{Cite web |last=Nestor |first=Marius |date=2020-10-13 |title=KDE Plasma 5.20 Desktop Environment Officially Released, Here's What's New |url=https://9to5linux.com/kde-plasma-5-20-desktop-environment-officially-released-heres-whats-new |access-date=2024-06-14 |website=9to5Linux |language=en-US}} In Plasma 6, the default graphical session that uses Wayland was set as the default, making the X11 session secondary.{{Cite web |last=Wallen |first=Jack |date=2024-02-14 |title=The first Linux distribution to deliver a pure KDE Plasma 6 environment is here |url=https://www.zdnet.com/article/the-first-linux-distribution-to-deliver-a-pure-kde-plasma-6-environment-is-here/ |access-date=2024-03-24 |website=ZDNET |language=en}}
=Other software=
Other software supporting Wayland includes the following:
- Intelligent Input Bus is working on Wayland support, it could be ready for Fedora 22.{{r|Schaller 2014}}
- RealVNC published a Wayland developer preview in July 2014.{{r|RealVNC remote}}{{r|autoref0005}}{{r|autoref0006}}
- [https://github.com/any1/wayvnc wayvnc] is a VNC server for wlroots-based Wayland compositors.
- Maliit is an input method framework that runs under Wayland.{{r|autoref0007}}{{r|autoref0008}}{{r|Maliit}}
- kmscon supports Wayland with wlterm.{{r|kmscon wl}}
- Mesa has Wayland support integrated.{{r|Hillesley 2012 p3}}
- Eclipse was made to run on Wayland during a GSoC-Project in 2014.{{r|eclipse wl}}
- The Vulkan WSI (Window System Interface) is a set of API calls that serve a similar purpose as EGL does for OpenGL & OpenGL ES or GLX for OpenGL on X11. 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.{{r|Collabora vulkan}}
- Waydroid (formerly called Anbox-Halium), a container for Android applications to run on Linux distributions using Wayland.
=Mobile and embedded hardware=
File:PostmarketOS and Weston compositor running on Motorola Moto G.jpg]]
Mobile and embedded hardware supporting Wayland includes the following:
- postmarketOS
- GENIVI Alliance: The GENIVI Aliance, now COVESA, for in-vehicle infotainment (IVI) supports Wayland.{{r|genivi}}
- 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.{{r|auto}}{{r|auto1}}{{r|auto2}}
- Tizen: Tizen up to 2.x supports Wayland in in-vehicle infotainment (IVI) setups{{r|tizen 2.0}} and from 3.0 onward defaults to Wayland.{{r|tizen 3.0}}{{cite web
|url = https://arstechnica.com/gadgets/2017/05/the-samsung-z4-is-tizens-new-flagship-smartphone/
|title = The Samsung Z4 is Tizen's new flagship smartphone
|last = Amadeo
|first = Ron
|work = Ars Technica
|date = 12 May 2017
|access-date = 13 May 2017
|archive-date = 13 May 2017
|archive-url = https://web.archive.org/web/20170513000659/https://arstechnica.com/gadgets/2017/05/the-samsung-z4-is-tizens-new-flagship-smartphone/
|url-status = live
}}
{{Clear}}
History
File:Linux graphics drivers DRI Wayland.svg 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.{{r|Høgsberg 2008}}{{r|FOSDEM2012 interview}}{{r|Hillesley 2012}}{{r|LPC2009}} 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 (Weston and Maynard are also nearby towns in the same area, continuing the reference).{{r|Hillesley 2012}}{{r|Jenkins 2011}}
In October 2010, Wayland became a freedesktop.org project.{{r|Larabel 2010 freedesktop}}{{r|wayland freedesktop}} 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,{{r|original license}} while the reference compositor Weston and some example clients used the GNU General Public License version 2.{{r|license clarification}} 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".{{r|license change GPL}} 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).{{r|License}}
Wayland works with all Mesa-compatible drivers with DRI2 support{{r|Hillesley 2012 p3}} as well as Android drivers via the Hybris project.{{r|wayland part1}}{{r|wayland part2}}{{r|Larabel 2013 Jolla}}
=Releases=
class="wikitable sortable collapsible text-align:center"
|+ Major Wayland and Weston releases{{r|wayland releases}} |
rowspan="2" | Version
! rowspan="2" | Date ! colspan="3" | Main features |
---|
Wayland
! Weston ! Wayland Protocols |
{{Version|o|0.85|sortKey=0.85}}
| {{dts|format=dmy|2012|02|09}}{{r|wayland 0.85}} | colspan="2" style="text-align: center;" | First release. | |
{{Version|o|0.95|sortKey=0.95}}
| {{dts|format=dmy|2012|07|24}}{{r|wayland 0.95}} | Began API stabilization. | | |
{{Version|o|1.0|sortKey=1.0}}
| {{dts|format=dmy|2012|10|22}}{{r|wayland 1.0}}{{r|Scherschel wayland 1.0}} | Stable wayland-client API. | | |
{{Version|o|1.1|sortKey=1.1}}
| {{dts|format=dmy|2013|04|15}}{{r|Larabel wayland 1.1}}{{r|wayland 1.1}} | | Software rendering.{{r|Larabel 2013 pixman}} FBDEV, RDP backends. | |
{{Version|o|1.2|sortKey=1.2}}
| {{dts|format=dmy|2013|07|12}}{{r|Larabel wayland 1.2}}{{r|wayland 1.2}} | Stable wayland-server API. | Color management. Subsurfaces. Raspberry Pi backend. | |
{{Version|o|1.3|sortKey=1.3}}
| {{dts|format=dmy|2013|10|11}}{{r|wayland 1.3}} | More pixel formats. Support for language bindings. | Android driver support via libhybris. | |
{{Version|o|1.4|sortKey=1.4}}
| {{dts|format=dmy|2014|01|23}}{{r|wayland 1.4}} | New wl_subcompositor and wl_subsurface interfaces. | Multiple framebuffer formats. logind support for rootless Weston. | |
{{Version|o|1.5|sortKey=1.5}}
| {{dts|format=dmy|2014|05|20}}{{r|wayland 1.5}} | | libinput. Fullscreen shell. | |
{{Version|o|1.6|sortKey=1.6}}
| {{dts|format=dmy|2014|09|19}}{{r|wayland 1.6}} | | libinput by default. | |
{{Version|o|1.7|sortKey=1.7}}
| {{dts|format=dmy|2015|02|14}}{{r|wayland 1.7}}{{r|weston 1.7}} | | Support for the Wayland presentation extension and for surface roles. IVI shell protocol. | |
{{Version|o|1.8|sortKey=1.8}}
| {{dts|format=dmy|2015|06|02}}{{r|wayland 1.8}}{{r|weston 1.8}} | Separated headers for core and generated protocol. | Repaint scheduling. Named outputs. Output transformations. Surface-shooting API. | |
{{Version|o|1.9|sortKey=1.9}}
| {{dts|format=dmy|2015|09|21}}{{r|wayland 1.9}}{{r|weston 1.9}} | Updated license. | Updated license. New test framework. Triple-head DRM compositor. linux_dmabuf extension. |
{{Version|o|1.10|sortKey=1.10}}
| {{dts|format=dmy|2016|02|17}}{{r|wayland 1.10}}{{r|weston 1.10}} | Drag-and-drop functionality, grouped pointer events.{{r|autoref0010}} | Video 4 Linux 2, touch input, debugging improvements.{{r|Larabel wayland 1.10}} | 1.1 (2016-02-16){{cite mailing list | url=https://lists.freedesktop.org/archives/wayland-devel/2016-February/027029.html | title=[ANNOUNCE] wayland-protocols 1.1 | mailing-list=wayland-devel | first=Jonas | last=Ådahl | date=16 February 2016}} |
{{Version|o|1.11|sortKey=1.11}}
| {{dts|format=dmy|2016|06|01}}{{r|wayland 1.11}}{{r|weston 1.11}} | New backup loading routine, new setup logic. | Proxy wrappers, shared memory changes, Doxygen-generated HTML docs. | 1.5 (2016-07-22){{cite mailing list | url=https://lists.freedesktop.org/archives/wayland-devel/2016-July/030211.html | title=[ANNOUNCE] wayland-protocols 1.5 | mailing-list=wayland-devel | first=Jonas | last=Ådahl | date=22 July 2016}} |
{{Version|o|1.12|sortKey=1.12}}
| {{dts|format=dmy|2016|09|21}}{{r|wayland 1.12}}{{r|weston 1.12}} | Debugging support improved. | libweston and libweston-desktop. Pointer locking and confinement. Relative pointer support. | |
{{Version|o|1.13|sortKey=1.13}}
| {{dts|format=dmy|2017|02|24}}{{r|wayland 1.13}} | | The ABI of Weston has been changed, thus the new version was named 2.0.0{{r|weston 2.0}} rather than 1.13.0. | 1.8 (2017-06-12) |
{{Version|o|1.14|sortKey=1.14}}
| {{dts|format=dmy|2017|08|08}}{{r|wayland 1.14}} | | Weston 3.0.0{{r|weston 3.0}} was released at the same time. | 1.11 (2017-10-11){{cite mailing list | url=https://lists.freedesktop.org/archives/wayland-devel/2017-October/035397.html | title=[ANNOUNCE] wayland-protocols 1.11 | mailing-list=wayland-devel | first=Jonas | last=Ådahl | date=11 October 2017}} |
{{Version|o|1.15|sortKey=1.15}}
| {{dts|format=dmy|2018|04|09}}{{r|wayland 1.15}} | | Weston 4.0.0{{r|weston 4.0}} was released at the same time. | 1.14 (2018-05-07){{cite mailing list | url=https://lists.freedesktop.org/archives/wayland-devel/2018-May/038103.html | title=[ANNOUNCE] wayland-protocols 1.14 | mailing-list=wayland-devel | first=Jonas | last=Ådahl | date=7 May 2018}} |
{{Version|o|1.16|sortKey=1.16}}
| {{dts|format=dmy|2018|08|24}}{{r|wayland 1.16}} | | Weston 5.0.0{{r|weston 5.0}} was released at the same time. |
{{Version|o|1.17|sortKey=1.17}}
| {{dts|format=dmy|2019|03|20}}{{r|wayland 1.17}} | | Weston 6.0.0{{r|weston 6.0}} was released at the same time. |
{{Version|o|1.18|sortKey=1.18}}
| {{dts|format=dmy|2020|02|11}}{{r|wayland 1.18}} | | Weston 7.0.0{{r|weston 7.0}} was released on 2019-08-23. | 1.19 (2020-02-29){{cite mailing list | url=https://lists.freedesktop.org/archives/wayland-devel/2020-February/041267.html | title=[ANNOUNCE] wayland-protocols 1.19 | mailing-list=wayland-devel | first=Jonas | last=Ådahl | date=29 February 2020}} |
{{Version|o|1.19|sortKey=1.19}}
| {{dts|format=dmy|2021|01|27}}{{r|wayland 1.19}} | | | 1.21 (2021-04-30){{cite mailing list | url=https://lists.freedesktop.org/archives/wayland-devel/2021-April/041815.html | title=[ANNOUNCE] wayland-protocols 1.21 | mailing-list=wayland-devel | first=Jonas | last=Ådahl | date=30 April 2021}} |
{{Version|o|1.20|sortKey=1.20}}
| {{dts|format=dmy|2021|12|09}}{{r|wayland 1.20}} | | Weston 10.0.0{{r|weston 10.0.0}} was released on 2022-02-01. |
{{Version|o|1.21|sortKey=1.21}}
| {{dts|format=dmy|2022|06|30}}{{r|wayland 1.21}} | | Weston 11.0.0{{r|weston 11.0.0}} was released on 2022-09-22. | 1.26 (2022-07-07){{cite mailing list | url=https://lists.freedesktop.org/archives/wayland-devel/2022-July/042270.html | title=[ANNOUNCE] wayland-protocols 1.26 | mailing-list=wayland-devel | first=Jonas | last=Ådahl | date=7 July 2022}} |
{{Version|co|1.22|sortKey=1.22}}
| {{dts|format=dmy|2023|04|04}}{{r|wayland 1.22}} | | Weston 12.0.0{{r|weston 12.0.0}} was released on 2023-05-17. | 1.32 (2023-07-03){{cite mailing list | url=https://lists.freedesktop.org/archives/wayland-devel/2023-July/042836.html | title=[ANNOUNCE] wayland-protocols 1.32 | mailing-list=wayland-devel | first=Jonas | last=Ådahl | date=3 July 2023}} |
{{Version|c|1.23|sortKey=1.23}}
| {{dts|format=dmy|2024|05|30}}{{r|wayland 1.23}} | | Weston 14.0.0{{r|weston 14.0.0}} was released on 2024-09-04. | 1.37 (2024-08-31){{cite mailing list | url=https://lists.freedesktop.org/archives/wayland-devel/2024-August/043774.html | title=[ANNOUNCE] wayland-protocols 1.37 | mailing-list=wayland-devel | first=Jonas | last=Ådahl | date=31 August 2024}} |
{{Version|p|1.24|sortKey=1.24}}
| | | | |
colspan=5 | {{Version|l|show=11101}} |
See also
{{Portal|Free and open-source software}}
References
{{reflist|refs=
{{cite web|last=Berglund|first=Camilla|title=Implementation for Wayland · Issue #106 · glfw/glfw · GitHub|website=GitHub|url=https://github.com/glfw/glfw/issues/106#issuecomment-39872275|date=8 April 2014|access-date=14 August 2014|archive-date=27 August 2022|archive-url=https://web.archive.org/web/20220827010908/https://github.com/glfw/glfw/issues/106#issuecomment-39872275|url-status=live}}
{{cite web|url=https://news.softpedia.com/news/wayland-1-10-display-server-officially-released-wayland-1-11-arrives-in-may-2016-500558.shtml|title=Wayland 1.10 Display Server Officially Released, Wayland 1.11 Arrives in May 2016|last=Nestor|first=Marius|date=18 February 2016|work=Softpedia|access-date=14 January 2020|archive-date=14 January 2020|archive-url=https://web.archive.org/web/20200114134844/https://news.softpedia.com/news/wayland-1-10-display-server-officially-released-wayland-1-11-arrives-in-may-2016-500558.shtml|url-status=live}}
{{cite mailing list|url=https://lists.freedesktop.org/archives/wayland-devel/2015-September/024226.html|title=[ANNOUNCE] wayland 1.8.93|first=Bryce|last=Harrington|date=15 September 2015|mailing-list=freedesktop.org|access-date=14 January 2020|archive-date=25 October 2020|archive-url=https://web.archive.org/web/20201025230202/https://lists.freedesktop.org/archives/wayland-devel/2015-September/024226.html|url-status=live}}
{{cite web|url=https://lists.x.org/archives/xorg-announce/2014-July/002457.html|title=ANNOUNCE: xorg-server 1.16.0|publisher=freedesktop.org|date=17 July 2014|access-date=14 January 2020|archive-date=8 March 2021|archive-url=https://web.archive.org/web/20210308121411/https://lists.x.org/archives/xorg-announce/2014-July/002457.html|url-status=live}}
{{cite web|url=https://lists.freedesktop.org/archives/wayland-devel/2013-October/011536.html|title=[RFC weston] remote access interface module|publisher=freedesktop.org|date=18 October 2013|access-date=14 January 2020|archive-date=25 October 2020|archive-url=https://web.archive.org/web/20201025220521/https://lists.freedesktop.org/archives/wayland-devel/2013-October/011536.html|url-status=live}}
{{cite web|url=https://lists.freedesktop.org/archives/wayland-devel/2014-July/015949.html|title=RealVNC Wayland developer preview email|publisher=freedesktop.org|date=9 July 2014|access-date=14 January 2020|archive-date=25 October 2020|archive-url=https://web.archive.org/web/20201025220610/https://lists.freedesktop.org/archives/wayland-devel/2014-July/015949.html|url-status=live}}
https://lists.freedesktop.org/archives/wayland-devel/2025-April/044163.html
https://lists.freedesktop.org/archives/wayland-devel/2025-April/044159.html
https://lists.freedesktop.org/archives/wayland-devel/2025-April/044158.html
{{cite web|url=https://gitlab.freedesktop.org/wayland/weston/-/commit/3c4dc74cebe1de6f71ec9eeb9794eaaff4327e95|title=xdg_shell: Adding a new shell protocol|work=freedesktop.org|date=3 December 2013|access-date=4 August 2024}}
}}
External links
{{Wikibooks|Linux Guide/Applications supported via Wayland|Linux Guide/Applications supported via Wayland}}
- {{Official website|https://wayland.freedesktop.org/}}
{{Freedesktop.org}}
{{Desktop environments and window managers for X11 and Wayland}}