Hubbry Logo
Wayland (protocol)Wayland (protocol)Main
Open search
Wayland (protocol)
Community hub
Wayland (protocol)
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Wayland (protocol)
Wayland (protocol)
Wayland (protocol)
View on Wikipedia
from Wikipedia

Wayland
Original authorKristian Høgsberg
Developerfreedesktop.org et al.
Initial release30 September 2008; 17 years ago (2008-09-30)[1]
Stable release
Wayland: 1.24,[2] Weston: 14.0.2[3] / 7 July 2025; 3 months ago (2025-07-07)
Repository
Written inC
Operating systemOfficial: Linux
Unofficial: NetBSD, FreeBSD, OpenBSD, DragonFly BSD[4]
Compatibility layer: Haiku[5]
Type
LicenseMIT License[6][7][8]
Websitewayland.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.[9] 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[10][11][12][13] and simpler windowing system for Linux and other Unix-like operating systems.[9][14] The project's source code is published under the terms of the MIT License, a permissive free software license.[14][6] The Wayland project also develops an implementation of a Wayland compositor called Weston.[9]

Overview

[edit]
  1. The evdev module of the Linux kernel gets an event and sends it to the Wayland compositor.
  2. 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.
  3. 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.
  4. 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.[15]

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".[16]

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:[14]

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.[17] It was attempted as a Google Summer of Code project in 2011, but was not successful.[18] 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).[19] As of early 2013, Høgsberg was experimenting with network transparency using a proxy Wayland server which sends compressed images to the real compositor.[20][21] In August 2017, GNOME saw the first such pixel-scraping VNC server implementation under Wayland.[22] In modern Wayland compositors, network transparency is handled in an xdg-desktop-portal implementation that implements the RemoteDesktop portal.

Many Wayland compositors also include an xdg-desktop-portal implementation for common tasks such as a native file picker for native applications and sandboxes such as Flatpak (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

[edit]

Protocol architecture

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

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:[23]

  • A low-level layer or wire protocol that handles the inter-process communication between the two involved processes‍—‌client and compositor‍—‌and the marshalling of the data that they interchange. This layer is message-based and usually implemented using the kernel IPC services, specifically Unix domain sockets in the case of Linux and other Unix-like operating systems.[24]
  • 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".[25]

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.[26] 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.[27]

Protocol overview

[edit]

The Wayland protocol is described as an "asynchronous object-oriented protocol".[25] 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.[25]

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.[25] 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.[28]

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.[29] 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.[30]

Wayland core interfaces

[edit]

The interfaces of the current version of Wayland protocol are defined in the file protocol/wayland.xml of the Wayland source code.[26] 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:[29]

  • wl_display – the core global object, a special object to encapsulate the Wayland protocol itself
  • wl_registry – the global registry object, in which the compositor registers all the global objects that it wants to be available to all clients
  • wl_compositor – an object that represents the compositor, and is in charge of combining the different surfaces into one output
  • wl_surface – an object representing a rectangular area on the screen, defined by a location, size and pixel content
  • wl_buffer – an object that, when attached to a wl_surface object, provides its displayable content
  • wl_output – an object representing the displayable area of a screen
  • wl_pointer, wl_keyboard, wl_touch – objects representing different input devices like pointers or keyboards
  • wl_seat – an object representing a seat (a set of input/output devices) in multiseat configurations

A typical Wayland client session starts by opening a connection to the compositor using the wl_display object. This is a special local object that represents the connection and does not live within the server. By using its interface the client can request the wl_registry global object from the compositor, where all the global object names live, and bind those that the client is interested in. Usually the client binds at least a wl_compositor object from where it will request one or more wl_surface objects to show the application output on the display.[28]

Wayland extension interfaces

[edit]

A Wayland compositor can define and export its own additional interfaces.[29] 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[31]).

Extension protocols to the core protocol

[edit]

XDG-Shell protocol

[edit]

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

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.[32]

IVI-Shell protocol

[edit]

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

Rendering model

[edit]
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.[34][14][35][36]: 2  Instead, Wayland follows a direct rendering model, in which the client must render the window contents to a buffer shareable with the compositor.[37] 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[38] and wl_shm_pool[39] 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.[40] 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.[23] 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.[41]: 7  The procedure used for rendering, including the number of buffers involved and their management, is entirely under the client control.[41]: 7 

Comparison with other window systems

[edit]
See also: Mir software architecture

Differences between Wayland and X

[edit]

There are several differences between Wayland and X with regard to performance, code maintainability, and security:[42]

Architecture
The composition manager is a separate, additional feature in X, while Wayland merges display server and compositor as a single function.[43][35] Also, it incorporates some of the tasks of the window manager, which in X is a separate client-side process.[44]
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.[45]: 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.).[43][35] 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 xdg-decoration protocol, if the compositor chooses to implement such functionality.[46]
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,[11][12][13] although some extensions have been developed trying to mitigate it.[47][48][49]
Also, with the vast majority of the code running in the client, less code needs to run with root privileges, improving security,[11] although multiple popular Linux distributions now allow the X server to be run without root privileges.[50][51][52][53]
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;[14] 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.[21]

Compatibility with X

[edit]

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.[54][55] 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.[56]

Widget toolkits such as Qt 5 and GTK 3 can switch their graphical back-end at run time,[57] allowing users to choose at load time whether they want to run the application over X or over Wayland. Qt 5 provides the -platform command-line option[58] to that effect, whereas GTK 3 lets users select the desired GDK back-end by setting the GDK_BACKEND Unix environment variable.[57][59]

Wayland compositors

[edit]
Main article: List of Wayland compositors
Typical elements of a window. The Wayland protocol does not specify what software is responsible for rendering the window decoration.[46]
Plasma 5.24.0 (February 2022) on Wayland (kwin_wayland compositor) under Arch Linux

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.[60]

Some notable Wayland compositors are:

  • Weston – an implementation from the Wayland development team. For details about Weston see below.
  • Enlightenment had Wayland support since version 0.20[61]
  • KWin, the default wayland compositor of KDE Plasma[62]
  • Mutter, the default wayland compositor of GNOME[63]
  • Sway – a tiling Wayland compositor, based on wlroots; it is a drop-in replacement for the i3 X11 window manager.[64][65][66]
  • Hyprland – a tiling Wayland compositor written in C++. Noteworthy features of Hyprland include dynamic tiling, tabbed windows, and a custom renderer that provides window animations, rounded corners, and Dual-Kawase Blur on transparent windows.[67][68]
  • Woodland – wlroots-based window-stacking compositor for Wayland written in C, inspired by TinyWL and focused on simplicity and stability.
  • niri – a scrollable-tiling Wayland compositor written in Rust.[69]
  • labwc – a wlroots-based window-stacking compositor for Wayland, inspired by Openbox. It follows a similar approach and coding style to Sway.[70]

Weston

[edit]

Weston is a Wayland compositor previously developed as the reference implementation of the protocol by the Wayland project.[71][72] 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.[73]

The compositor supports High-bandwidth Digital Content Protection (HDCP)[74] 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.[21] Applications are responsible for rendering their own window decorations.

Weston supports rendering via OpenGL ES[75] or the pixman library for software rendering.[76] The full OpenGL stack is avoided to prevent pulling in GLX and other X Window System dependencies.[77]

A remote desktop interface for Weston was proposed in 2013 by a developer from RealVNC.[78]

Maynard

[edit]
Maynard (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.[79]

Raspberry Pi Holdings in collaboration with Collabora released Maynard.[80][81]

libinput

[edit]
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.[82][83]

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[clarification needed] (via udev), device handling, input device event processing and abstraction.[84][85]

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.[86]

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

With version 1.16, the X.Org Server obtained support for the libinput library in form of a wrapper called xf86-input-libinput.[89][90]

Wayland Security Module

[edit]

Wayland Security Module is a proposition that resembles the Linux Security Module interface found in the Linux kernel.[91]

Some applications (especially the ones related to accessibility) require privileged capabilities that should work across different Wayland compositors. Currently,[when?] applications under Wayland are generally unable to perform any sensitive tasks such as taking screenshots or injecting input events without going through xdg-desktop-portal or obtaining privileged access to the system. The security model forced by Wayland also creates mouse position problems when attempting to type text in many games.[92]

Wayland Security Module is a way to delegate security decisions within the compositor to a centralized security decision engine.[91]

Adoption

[edit]

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. While many graphical toolkits already fully support Wayland, the developers of the graphical shells are cooperating with the Wayland developers to create the necessary additional interfaces.

Desktop Linux distributions

[edit]

Most major Linux distributions default to using Wayland. Some notable examples are:

  • Debian ships Wayland as the default session for GNOME since version 10 (Buster), released 6 July 2019.[93]
  • 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.[94] 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).[95]
  • Raspberry Pi OS, a port of Debian, has offered the option to use Wayland since version 11 (Bullseye), which was released on 3 December 2021. Wayland became the default in version 12 (Bookworm), released on 10 October 2023.
  • Red Hat Enterprise Linux ships Wayland as the default session in version 8, released 7 May 2019.[96]
  • Ubuntu shipped with Wayland by default in Ubuntu 17.10 (Artful Aardvark).[97] However, Ubuntu 18.04 LTS reverted to X.Org by default due to several issues.[98][99] Since Ubuntu 21.04, Wayland is the default again.[100]
  • Slackware Linux included Wayland on 20 February 2020[101] for the development version, -current, which became version 15.0 in 2022. However, Wayland is still not the default.[102]

Toolkit support

[edit]

Toolkits supporting Wayland include the following:

  • EFL has complete Wayland support, except for selection.[103]
  • GTK 3.20 has complete Wayland support.[104]
  • 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[105] and was enabled by default since version 2.0.4.[106]
  • GLFW 3.2 has Wayland support.[107]
  • FreeGLUT has initial Wayland support.[108]
  • FLTK supports Wayland since version 1.4.0 (Nov. 2024).[109]

Desktop environments

[edit]

Desktop environments that have been ported from X to Wayland include GNOME,[110] KDE Plasma[111] and Enlightenment.[112]

GNOME 3.20 was the first version to have a full Wayland session.[113] GNOME 3.22 included much improved Wayland support across GTK, Mutter, and GNOME Shell.[114] GNOME 3.24 shipped support for the proprietary Nvidia drivers under Wayland.[115]

KDE Plasma started supporting Wayland in version 5.[116] Version 5.4 of Plasma was the first with a full Wayland session.[117] In KDE Plasma 6, Wayland became the default.[118]

In November 2015, Enlightenment e20 was announced with full Wayland support.[119][61][120]

Other software

[edit]

Other software supporting Wayland includes the following:

  • Intelligent Input Bus is working on Wayland support, it could be ready for Fedora 22.[121]
  • RealVNC published a Wayland developer preview in July 2014.[78][122][123]
  • wayvnc is a VNC server for wlroots-based Wayland compositors.
  • Maliit is an input method framework that runs under Wayland.[124][125][126]
  • kmscon supports Wayland with wlterm.[127]
  • Mesa has Wayland support integrated.[128]
  • Eclipse was made to run on Wayland during a GSoC-Project in 2014.[129]
  • 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.[130]
  • Waydroid (formerly called Anbox-Halium), a container for Android applications to run on Linux distributions using Wayland.

Mobile and embedded hardware

[edit]
Weston running on postmarketOS

Mobile and embedded hardware supporting Wayland includes the following:

History

[edit]
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.[138][139][140][141] 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).[140][142]

In October 2010, Wayland became a freedesktop.org project.[143][144] 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,[145] while the reference compositor Weston and some example clients used the GNU General Public License version 2.[146] 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".[147] 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).[6]

Wayland works with all Mesa-compatible drivers with DRI2 support[128] as well as Android drivers via the Hybris project.[148][149][150]

Releases

[edit]
Major Wayland and Weston releases[151]
Version Date Main features
Wayland Weston Wayland Protocols
Unsupported: 0.85 9 February 2012[152] First release.
Unsupported: 0.95 24 July 2012[153] Began API stabilization.
Unsupported: 1.0 22 October 2012[154][155] Stable wayland-client API.
Unsupported: 1.1 15 April 2013[156][157] Software rendering.[76] FBDEV, RDP backends.
Unsupported: 1.2 12 July 2013[158][159] Stable wayland-server API. Color management. Subsurfaces. Raspberry Pi backend.
Unsupported: 1.3 11 October 2013[160] More pixel formats. Support for language bindings. Android driver support via libhybris.
Unsupported: 1.4 23 January 2014[31] New wl_subcompositor and wl_subsurface interfaces. Multiple framebuffer formats. logind support for rootless Weston.
Unsupported: 1.5 20 May 2014[82] libinput. Fullscreen shell.
Unsupported: 1.6 19 September 2014[161] libinput by default.
Unsupported: 1.7 14 February 2015[162][163] Support for the Wayland presentation extension and for surface roles. IVI shell protocol.
Unsupported: 1.8 2 June 2015[164][165] Separated headers for core and generated protocol. Repaint scheduling. Named outputs. Output transformations. Surface-shooting API.
Unsupported: 1.9 21 September 2015[166][167] Updated license. Updated license. New test framework. Triple-head DRM compositor. linux_dmabuf extension. 1.0 (2015-11-24)[168]
Unsupported: 1.10 17 February 2016[169][170] Drag-and-drop functionality, grouped pointer events.[171] Video 4 Linux 2, touch input, debugging improvements.[172] 1.1 (2016-02-16)[173]
1.4 (2016-05-23)[174]
Unsupported: 1.11 1 June 2016[175][176] New backup loading routine, new setup logic. Proxy wrappers, shared memory changes, Doxygen-generated HTML docs. 1.5 (2016-07-22)[177]
1.7 (2016-08-15)[178]
Unsupported: 1.12 21 September 2016[179][180] Debugging support improved. libweston and libweston-desktop. Pointer locking and confinement. Relative pointer support.
Unsupported: 1.13 24 February 2017[181] The ABI of Weston has been changed, thus the new version was named 2.0.0[182] rather than 1.13.0. 1.8 (2017-06-12)
1.10 (2017-07-31)[183]
Unsupported: 1.14 8 August 2017[184] Weston 3.0.0[185] was released at the same time. 1.11 (2017-10-11)[186]
1.13 (2018-02-14)[187]
Unsupported: 1.15 9 April 2018[188] Weston 4.0.0[189] was released at the same time. 1.14 (2018-05-07)[190]
1.16 (2018-07-30)[191]
Unsupported: 1.16 24 August 2018[192] Weston 5.0.0[193] was released at the same time. 1.17 (2018-11-12)[194]
Unsupported: 1.17 20 March 2019[195] Weston 6.0.0[196] was released at the same time. 1.18 (2019-07-25)[197]
Unsupported: 1.18 11 February 2020[198] Weston 7.0.0[199] was released on 2019-08-23.
Weston 8.0.0[200] was released on 2020-01-24.
Weston 9.0.0[201] was released on 2020-09-04. 		1.19 (2020-02-29)[202]
1.20 (2020-02-29)[203]
Unsupported: 1.19 27 January 2021[204] 1.21 (2021-04-30)[205]
1.24 (2021-11-23)[206]
Unsupported: 1.20 9 December 2021[207] Weston 10.0.0[208] was released on 2022-02-01.
Weston 10.0.5[209] was released on 2023-08-02. 		1.25 (2022-01-28)[210]
Unsupported: 1.21 30 June 2022[211] Weston 11.0.0[212] was released on 2022-09-22.
Weston 11.0.3[213] was released on 2023-08-02. 		1.26 (2022-07-07)[214]
1.31 (2022-11-29)[215]
Supported: 1.22 4 April 2023[216] Weston 12.0.0[217] was released on 2023-05-17.
Weston 12.0.5[218] was released on 2025-04-29.
Weston 13.0.0[219] was released on 2023-11-27.
Weston 13.0.4[220] was released on 2025-04-25. 		1.32 (2023-07-03)[221]
1.36 (2024-04-26)[222]
Supported: 1.23 30 May 2024[223] Weston 14.0.0[224] was released on 2024-09-04.
Weston 14.0.2[3] was released on 2025-04-25. 		1.37 (2024-08-31)[225]
1.45 (2025-06-13)[226]
Latest version: 1.24 7 July 2025[2]
Future version: 1.25
Legend:
Unsupported
Supported
Latest version
Future version

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Wayland (protocol)

View on Grokipedia
from Grokipedia
Wayland is a display server protocol that specifies the communication between a graphical application and its display server for rendering content, handling input, and managing windows on operating systems. It serves as a modern replacement for the X11 window system, aiming to simplify the graphics stack by having clients perform their own rendering while the compositor handles composition, input events, and buffer management. Developed as an open-source project, Wayland emphasizes modularity, security through isolation of client rendering, and reduced latency compared to X11's client-server model. The project was initiated in 2008 by Kristian Høgsberg, a developer at , as a lightweight alternative to X11 to address its growing complexity and limitations in modern environments. Initially a , Wayland became an official project in 2010, with Høgsberg as its founder and maintainer. The first stable release, version 1.0, arrived in October 2012, marking the protocol's transition to a mature API for display servers and clients. Since then, it has been maintained by a of volunteers, with contributions from major distributions and desktop environments like , , and others. At its core, Wayland's architecture shifts responsibilities from a centralized server to a distributed model where the compositor acts as the display server, directly interfacing with kernel components like KMS (Kernel Mode Setting) for output and evdev for input devices. Unlike X11, which renders content on the server side and proxies input, Wayland clients render directly into buffers and notify the compositor of changes via damage events, allowing for efficient compositing using a scenegraph for transformations and layering. This design eliminates unnecessary context switches and round-trips, improving performance while enhancing security by preventing clients from accessing other applications' content or input directly. The protocol is implemented through the libwayland library, which provides C APIs for both clients and servers, translating the XML-defined protocol into efficient inter-process communication. Weston serves as the reference compositor implementation, demonstrating Wayland's capabilities in a standalone environment, though production use often integrates with desktop-specific compositors like Mutter (GNOME) or KWin (KDE). Extensions to the core protocol, defined in the wayland-protocols repository, add features such as shell integration, screen sharing, and input methods, ensuring extensibility without bloating the base specification. As of 2025, Wayland has seen widespread adoption in Linux distributions, becoming the default session in environments like Fedora and Ubuntu, though compatibility layers like XWayland bridge legacy X11 applications.

Overview

Definition and Purpose

Wayland is a that defines the (IPC) between client applications and a display server known as the compositor, serving as a modern replacement for the X11 protocol in managing input events, output rendering, and window management on and other operating systems. In this model, the compositor acts as the central server that receives rendered content from clients and composites it for display, while also routing user input directly to the appropriate applications. The primary purpose of Wayland is to establish a secure and efficient foundation for graphical user interfaces by emphasizing direct rendering, where clients generate their own graphics buffers locally using hardware acceleration and share only the necessary metadata or buffer handles with the compositor, thereby minimizing unnecessary data copying and reducing latency compared to traditional systems. This approach enhances performance and security by isolating clients from direct access to the display hardware or other applications' inputs, preventing issues like unauthorized screen captures or keystroke logging that were prevalent in older protocols. Wayland was initiated in 2008 by Kristian Høgsberg, a developer at Red Hat and contributor to X.Org, as a response to X11's accumulated bloat from decades of extensions and its inherent security vulnerabilities, such as unauthenticated access allowing any client to monitor or manipulate others. In the Wayland ecosystem, clients handle their own rendering and notify the compositor of changes to specific surface regions, enabling the compositor to efficiently blend multiple clients' outputs without redundant processing. The compositor, in turn, manages the final display composition across multiple clients to create a cohesive desktop environment.

Design Principles

Wayland's design is grounded in the principle of , manifested through a minimal core protocol that provides only the essential interfaces necessary for basic operations such as surface creation, buffer management, and input event handling. Unlike X11, which evolved into a burdened by decades of accumulated extensions and , Wayland deliberately limits its core to around 30 requests, promoting extensibility via separate protocols for advanced features. This streamlined approach reduces implementation complexity for both clients and compositors, fostering easier maintenance and innovation while avoiding the bloat that plagued its predecessor. Security is a foundational pillar of Wayland's architecture, achieved by denying clients direct access to global resources like keyboard or grabs and overlays. The compositor acts as a trusted intermediary, enforcing strict isolation between clients to prevent one application from intercepting or injecting input intended for another, thereby mitigating risks such as keylogging or unauthorized screen overlays that were exploitable in X11's more permissive model. This design ensures that input events are routed exclusively to the intended surface, enhancing overall system integrity without relying on client-side permissions. Efficiency is prioritized through a direct rendering paradigm, where clients leverage the GPU to render content straight into shared buffers using APIs like EGL, eliminating the need for server-mediated commands. The compositor intervenes solely for final composition—blending these buffers into the display output—which drastically cuts down on latency, bandwidth usage, and CPU involvement compared to X11's indirect rendering overhead. This model aligns with contemporary hardware capabilities, enabling smoother animations and reduced power consumption, particularly on resource-constrained devices. At its core, Wayland employs a compositor-centric model that delegates all aspects of window management, including decoration, stacking, and layout, to the compositor rather than distributing these responsibilities across clients. This centralization empowers compositors to optimize for specific hardware and user needs, such as seamless integration, while simplifying client logic to focus purely on content rendering. By contrast with X11's distributed client-server dynamics, this shift promotes cohesive desktop environments and facilitates consistent handling of modern features like multi-monitor support.

Technical Architecture

Core Protocol

The Wayland core protocol establishes the foundational communication mechanism between clients and the compositor in a display server environment, emphasizing simplicity and efficiency over legacy features. Defined entirely within the wayland.xml schema file, the protocol specifies a set of interfaces, requests, and events that enable basic surface management, buffer handling, input routing, and display configuration. This XML is processed by the wayland-scanner tool to generate C language bindings for both client and server sides, ensuring type-safe implementations. Messages are serialized and exchanged asynchronously over Unix domain sockets, using a wire format that includes a 32-bit object ID, followed by a 16-bit message size and 16-bit , and variable-length arguments such as integers, strings, or file descriptors. Central to the protocol is the wl_display interface, a singleton object that serves as the for client connections. It manages dispatching, synchronization via roundtrip requests (e.g., sync and done events for confirming delivery), and reporting. Clients initiate interaction by connecting to the compositor's socket and receiving an initial wl_display object with ID 1; from there, they can issue a get_registry request to obtain a wl_registry proxy for discovering compositor-provided globals. The wl_registry interface enumerates available global objects through its global event, which includes the interface name, version, and name; clients then to these globals using the bind request, creating new proxy objects with client-assigned IDs. This object-oriented model ensures that all interactions occur via method-like requests on specific objects, with the compositor responding through events. Surface creation and management rely on the wl_compositor and wl_surface interfaces. The wl_compositor global allows clients to create wl_surface objects via its create_surface request, where each wl_surface represents a basic, opaque drawing area without inherent window management semantics. Clients attach content to a surface by creating a wl_buffer—typically via wl_shm.create_pool and pool.create_buffer for shared memory-backed buffers—and issuing an attach request to associate it with the surface, specifying offset and dimensions. The wl_shm interface facilitates efficient buffer sharing using POSIX shared memory (shm_open and mmap), supporting formats like XRGB8888 for direct rendering without unnecessary copies. Clients can use the wl_surface.damage request to indicate changed regions on a surface, allowing the compositor to optimize repaints. However, optimization remains the application's responsibility. Updates to a surface's state, including attachments and transformations, are applied atomically through the commit request, ensuring the compositor sees a consistent state without partial renders—pending changes are queued until commit, at which point frame events signal rendering completion for vertical blank synchronization. Display and input aspects are handled by the wl_output and wl_seat globals, respectively. The wl_output interface, bound from the registry, provides mode events detailing resolutions, refresh rates, and physical properties like subpixel layout, along with geometry events for positioning relative to other outputs; it enables clients to adapt content to setups. For input, the wl_seat interface advertises device capabilities (pointer, keyboard, touch) via its capabilities event and offers factory requests to obtain device-specific proxies, such as wl_pointer for motion and button events or wl_keyboard for key presses—events include timestamps and serials for ordering. These interfaces ensure direct, low-latency forwarding of input from the compositor to the relevant surface under the pointer. Error handling is standardized to maintain robustness, with the compositor issuing wl_display.error events for violations such as invalid object IDs, out-of-bounds arguments, or unsupported requests; each error includes a 32-bit from a predefined enum (e.g., WL_DISPLAY_ERROR_INVALID_OBJECT or WL_DISPLAY_ERROR_INVALID_METHOD) and a descriptive string. Clients must validate responses and handle dispatch s gracefully, as the protocol assumes no automatic recovery mechanisms. This core set of interfaces forms the minimal foundation, upon which extensions can build without altering the base .

Extension Protocols

Wayland's extensibility is achieved through extension protocols, which define additional interfaces beyond the core protocol. These extensions are specified in separate XML files, parsed by the Wayland scanner to generate C headers and code for clients and compositors. New interfaces are advertised by the compositor as global objects via the wl_registry, allowing clients to bind to them using the wl_registry.bind request, specifying the interface name and desired version. This modular approach enables additions without modifying the core protocol, supporting diverse use cases such as desktop environments and embedded systems. The xdg_shell protocol, maintained by , provides a standard for desktop-style shell surfaces. It introduces xdg_wm_base as a global interface, from which clients create xdg_surface objects attached to wl_surface instances to define roles like xdg_toplevel for top-level windows or xdg_popup for transient dialogs. Key features include support for window states such as maximized, fullscreen, and minimized, along with resize and move operations, enabling consistent window management across compositors. Other prominent extensions address specific functionality. The presentation-time protocol delivers precise feedback on surface presentation timing, including timestamps synchronized to display refresh cycles, to facilitate smooth video playback and audio-video synchronization. The pointer-constraints protocol allows clients to confine or lock the pointer to a surface, enhancing input focus for applications like games. Complementing this, the relative-pointer protocol provides relative motion events, independent of screen boundaries, for smooth cursor handling in scenarios requiring unconstrained movement. Additionally, the text-input protocol supports input method editors (IMEs) by enabling text input coordination, including preedit and commit events for multilingual typing. The color-management protocol (stable since wayland-protocols 1.41, February 2025) enables clients to specify color characteristics for content, supporting (HDR) displays. Furthermore, ext-data-control (stable in wayland-protocols 1.39, December 2024) allows privileged clients to manage between applications, while ext-workspace provides APIs for management. For automotive applications, the IVI-Shell protocol (ivi-application) targets in-vehicle systems. It allows clients to assign unique IDs to surfaces for grouping and layering, with the compositor managing visibility and z-order based on priorities, facilitating multi-zone UI layouts in . This extension supports server-side control over surface properties without client-side shell dependencies. Protocol negotiation occurs during client initialization: the compositor broadcasts available globals via wl_registry.global events, listing interface names and versions. Clients then selectively to supported extensions using wl_registry., ensuring compatibility without assuming universal support. This query-bind process, rooted in the core wl_registry interface, promotes robustness in heterogeneous environments.

Rendering and Compositing Model

In Wayland, client applications perform all rendering on their own side, utilizing graphical toolkits such as or Qt to draw content into offscreen buffers. These buffers are typically created and managed using hardware-accelerated APIs like EGL with , or for modern rendering pipelines. Once the content is rendered, the client attaches a wl_buffer object to a wl_surface via the wl_surface.attach request, signaling the compositor that new content is available for display. The compositor plays a central role in the display pipeline by receiving these client buffers and performing all necessary operations without engaging in server-side rendering of application content. It applies transformations such as scaling or to the buffers—using like buffer scale for high-DPI adjustments or buffer transform for orientation changes—and layers multiple surfaces into a composite scene. This composition occurs on the GPU, leveraging the (DRM) and Kernel Mode Setting (KMS) for efficient hardware access and output to physical displays. The resulting frame is then scanned out directly via KMS, ensuring tear-free presentation. Buffer management in Wayland relies on a double-buffered state model for surface properties, including attached buffers and regions, to enable atomic updates. Clients prepare changes in pending state and apply them via wl_surface.commit, which swaps the pending and current states, prompting the compositor to re-read the buffer. For smooth animations, many implementations employ triple buffering, where clients maintain three buffers to allow continuous rendering without stalling on compositor feedback, reducing latency in dynamic scenes. regions, specified through wl_surface.damage, optionally indicate only modified areas to optimize compositor redraws. Wayland supports multi-monitor configurations through the wl_output interface, where the compositor advertises available outputs via global objects and sends events detailing modes (resolution and ) and (position and physical dimensions). Clients receive these wl_output events to adjust their rendering accordingly, such as scaling content per output. The compositor independently manages per-output composition, applying transformations and layering buffers tailored to each display's characteristics for consistent presentation across multiple screens.

Client-Server Interaction

In Wayland, a client initiates communication with the compositor by establishing a connection through a , typically located at $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY (defaulting to wayland-0 if unset). The primary function for this is wl_display_connect(NULL), which returns a wl_display object representing the client's connection to the compositor; if a custom socket is needed, wl_display_connect_to_fd() can be used with an existing . Once connected, the client retrieves a wl_registry object via wl_display_get_registry(display) to discover and bind to global objects provided by the compositor, such as wl_compositor for surface creation. Binding occurs through wl_registry_bind(registry, name, interface, version), which returns a proxy for the bound object; for example, binding to wl_compositor enables the client to create wl_surface objects and allocate buffers using functions like wl_compositor_create_surface() and wl_shm_pool_create_buffer(). Client-server interaction in Wayland operates asynchronously for events from the compositor to the client, while requests from client to compositor are synchronous method invocations marshaled over the socket. Events, such as input notifications from wl_seat (e.g., pointer motion via wl_pointer_motion or key presses via wl_keyboard_key) and rendering feedback from wl_surface (e.g., frame completion signals), are delivered to the client and processed in its main event loop by dispatching them to registered listener callbacks associated with each proxy object. The client calls wl_display_dispatch(display) or wl_display_prepare_read() followed by wl_display_read_events() to read incoming events from the socket and invoke the appropriate dispatchers, ensuring non-blocking handling integrated with the application's event loop (e.g., using poll() or epoll() on the display's file descriptor obtained via wl_display_get_fd()). In contrast, client requests like attaching a buffer to a surface or committing changes are encoded and sent immediately via proxy methods, with the compositor processing them in order without blocking the client. Synchronization between client and compositor is achieved through specific protocol mechanisms to coordinate initial setup and ongoing rendering. For initial connection stabilization, clients invoke wl_display_roundtrip(display), which flushes all pending requests to the server and blocks until all corresponding events are received, ensuring globals are bound and resources are ready before proceeding. For rendering, clients request frame callbacks via wl_surface_frame(surface), receiving a wl_callback object; the compositor emits a done event on this callback with a when the next frame can be presented, aligning client rendering with the display's vertical sync (vsync) interval to avoid tearing and optimize resource use. This callback-driven approach allows clients to render only on compositor notification, typically at rates like 60 Hz, and can be chained for continuous animation loops. Wayland resources, represented on the client side as wl_proxy objects, follow an explicit lifecycle managed by the client to prevent leaks and ensure proper cleanup. Clients destroy a proxy by calling wl_proxy_destroy(proxy), which sends a destroy request to the compositor (if the interface defines one) and frees the local proxy structure, atomically handling the marshal to avoid races. All proxies, including core objects like wl_display and wl_event_queue, must be manually destroyed before disconnecting via wl_display_disconnect() to release associated resources. For unreferenced items, the Wayland library and compositor implement ; if a client fails to destroy proxies explicitly (e.g., upon abrupt disconnection), the server destroys all associated resources, effectively providing garbage collection for dangling objects to maintain protocol integrity.

Comparisons and Compatibility

Key Differences from X11

Wayland fundamentally diverges from X11 in its approach to . X11 was designed with built-in support for remote access over TCP/IP, enabling clients to connect to a display server across a network for scenarios. In contrast, Wayland operates exclusively over local Unix domain sockets, intentionally omitting to prioritize low-latency performance and simplify the protocol for modern, localized use cases. This design choice reflects Wayland's focus on desktop and embedded environments where remote access is rarely needed, avoiding the overhead and complexities associated with X11's networking features. A core philosophical difference lies in the authority model for and . Under X11, clients retain significant control over system resources, such as direct access to via extensions like MIT-SHM, which allows applications to bypass the server for efficient rendering but introduces vulnerabilities like unauthorized data interception. Wayland, however, centralizes all authority in the compositor, which exclusively handles , and buffer management; clients submit rendered surfaces but cannot manipulate hardware or other clients' resources directly. This delegation enhances by isolating clients and preventing issues like keylogging or screen scraping that plague X11. Event handling in Wayland contrasts sharply with X11's flexible but insecure model. X11 generates synthetic events and supports global grabs, allowing any client to intercept input events system-wide, which facilitates features like screen recording but enables malicious applications to capture keystrokes or mouse actions indiscriminately. Wayland routes input —such as pointer, keyboard, and touch—directly from the compositor to the focused surface only, eliminating grabs and ensuring events are delivered solely to the without client interference. This direct routing reduces latency and bolsters privacy, though it requires specialized extensions for legacy grab-dependent functionality. The protocols themselves differ in verbosity and extensibility. X11's core protocol encompasses 128 requests covering a broad array of operations, from window creation to font handling, resulting in a complex, layered specification that has accumulated extensions over decades. Wayland's core protocol is deliberately minimal, featuring around 23 interfaces with fewer than 50 requests in total, which streamlines communication and lowers overhead by offloading advanced features to optional extension protocols. This lean design promotes efficiency and easier maintenance but shifts the burden of feature implementation to compositors and toolkits.

X11 Compatibility Mechanisms

To enable legacy X11 applications to run on Wayland sessions, the primary mechanism is XWayland, an integrated X server that operates as a Wayland client. XWayland functions as a proxy, accepting connections from X11 clients and translating their protocol requests into equivalent Wayland surface operations, which are then rendered by the Wayland compositor. This nested approach allows most X11 applications to function with minimal modifications, though some features, such as global hotkeys and certain input event handling, may be lost due to the protocol differences. As of 2025, XWayland has seen improvements in support for GPUs and better emulation of X11 extensions, enhancing compatibility on diverse hardware. XWayland supports two operational modes: rootful and rootless. In rootless mode, which is the default and most commonly used, X11 windows are embedded directly into the Wayland without a separate , enabling seamless integration managed by the Wayland compositor acting as the X11 . Rootful mode, by contrast, creates a dedicated X11 within a Wayland surface, allowing the use of a traditional X11 inside it, though this can lead to less fluid compositing. Despite its effectiveness, XWayland has notable limitations. It does not support network-transparent X11 clients, as it lacks a TCP listener for remote connections, prioritizing local session security over X11's traditional remote access model. Additionally, some applications may experience reduced tear-free rendering or visual artifacts, particularly those relying on direct X11 extensions for graphics acceleration. For remote access needs, alternatives like Xpra provide a workaround by forwarding X11 sessions over Wayland, encapsulating application windows for transport without full X11 network transparency. Beyond XWayland, compatibility can be enhanced through translation layers in application toolkits, such as proxying XCB (X protocol C-language Binding) calls to Wayland equivalents in libraries like GTK or Qt. However, these layers offer partial support and often require application-level porting for complete feature parity and optimal performance.

Advantages and Limitations

Wayland offers several advantages over its predecessor, X11, primarily through its streamlined design that enables direct rendering from clients to the display hardware. This eliminates the multiple round-trips inherent in X11's client-server model, aiming to achieve lower input latency. Additionally, Wayland's architecture supports native hardware integration for modern displays, including HiDPI support and fractional scaling, allowing for smoother handling of high-resolution screens without the pixelation issues common in X11. A key strength of Wayland is its enhanced model, where the compositor acts as the gatekeeper for all input and output, preventing unauthorized access that plagues X11. Unlike X11, which runs with elevated privileges and exposes vulnerabilities enabling root exploits or keyloggers, Wayland enforces isolation between clients, reducing the significantly. Despite these benefits, Wayland has notable limitations stemming from its protocol's minimalism, which delegates many features to individual compositors rather than standardizing them centrally. This leads to inconsistent support across implementations, such as varying handling of setups or input devices, requiring developers and users to adapt to compositor-specific behaviors. The protocol also presents a steeper for developers transitioning from X11, as it demands a deeper understanding of compositor interactions and lacks the extensive legacy documentation and tools available for X11. Remote desktop functionality remains incomplete in Wayland's core protocol, which does not include ; solutions like RDP require compositor extensions such as KRDP in Plasma or GNOME's remote desktop server, often with limitations in multi-session support or . In terms of , Wayland's efficient direct buffer sharing via DMA-BUF can lead to lower CPU usage for in some scenarios compared to X11, though legacy applications running through XWayland introduce measurable overhead, potentially increasing latency by 1-2 frames in graphics-intensive tasks. The ecosystem is evolving, and as of 2025, integrations like have enabled improved screen sharing via , addressing earlier gaps in portal-based capture.

Implementations

Reference Implementation: Weston

Weston serves as the official of a Wayland compositor, providing a complete and minimal environment that demonstrates the protocol's capabilities while functioning as a standalone display server for various use cases, including desktop, embedded, and systems. Initially developed by Kristian Høgsberg while at starting in 2008, Weston was designed to embody the principles of correctness, reliability, predictability, and efficient performance in handling tasks. Its architecture centers on libweston, a modular library that abstracts backend-specific details, allowing developers to focus on protocol implementation without deep hardware dependencies. A core strength of Weston lies in its flexible backend support, enabling it to operate in diverse scenarios: the DRM backend leverages Kernel Mode Setting (KMS) for direct access to graphics hardware on systems, the Wayland backend facilitates nested within another Wayland instance for development and testing, and the headless backend supports scenarios without display output, such as server-side rendering or CI environments. This modularity ensures Weston can run on everything from high-end desktops to resource-constrained devices, while abstracting complexities like buffer management and input handling through the core Wayland protocol interfaces. Weston includes built-in shell plugins to manage surface behaviors, notably the desktop-shell plugin that implements the xdg_shell protocol for handling toplevel surfaces, popups, and layers in a desktop-like environment. It also supports multiple outputs natively, allowing seamless handling of setups with per-output configuration for scaling, , and positioning. To aid in protocol verification and development, Weston bundles a suite of demo clients, such as weston-simple-egl for rendering, weston-flower for frame protocol testing, and weston-smoke for buffer validation, which collectively exercise key aspects of client-compositor interactions. In its role as a development tool, Weston acts as a primary testbed for emerging Wayland protocols and extensions, where developers prototype features like input handling or security mechanisms before integrating them into production compositors, thanks to its clean separation of concerns and extensible plugin system.

Input and Security Components

libinput serves as the primary library for handling input devices in Wayland compositors, offering a unified API that abstracts kernel-provided events for devices such as keyboards, mice, and touchpads. It processes raw input data, applying device-specific configurations like pointer acceleration and touch coordinate scaling to ensure consistent event delivery across diverse hardware. This library integrates directly with the Wayland core protocol's wl_seat interface, which represents groups of input devices and facilitates the routing of events like key presses, pointer motion, and touch interactions to the appropriate client surfaces. The Wayland input model emphasizes direct event routing to the focused surface under the pointer or touch, avoiding the global grabs common in legacy systems like X11, which could allow unauthorized interception of input across all applications. This design enhances security by limiting clients to receiving only events intended for their own surfaces, with the compositor maintaining implicit grabs solely for matching button presses and releases to prevent event loss. For advanced multi-touch interactions, the pointer-gestures extension provides a standardized protocol supporting swipe, pinch, and hold gestures through a three-stage lifecycle (begin, update, end) for swipes and pinches, and a two-stage cycle for holds, enabling semantic gesture recognition without overlapping gestures per . libinput complements this by managing gesture detection, calibration, and filtering, such as smoothing touchpad movements and resolving multi-finger ambiguities before forwarding events via wl_seat. Wayland's security model relies on client isolation, where applications cannot access other clients' content or input directly, combined with features like namespaces for sandboxing. Namespaces isolate processes in separate mount, network, and user contexts, restricting access to the Wayland socket (WAYLAND_DISPLAY or WAYLAND_SOCKET). This allows compositors to launch clients with diminished privileges, preventing broader system interference. For privileged operations such as screenshots, screen sharing, or camera access, the xdg-desktop-portal framework provides a secure interface that requires explicit user consent, ensuring only authorized applications can access sensitive resources through mechanisms like DMA-buf file descriptors. As of 2025, this portal system is integral to sandboxed environments in major desktop environments like and .

Other Compositors and Tools

KWin serves as the primary Wayland compositor for the Plasma desktop environment, offering a flexible architecture that supports advanced window management features including multiple virtual desktops for organizing workflows. It integrates visual effects through a scripting system that allows users to extend functionality with KWin scripts written in or , enabling custom animations and transitions without recompiling the core software. Additionally, KWin provides seamless XWayland integration to run legacy X11 applications alongside native Wayland clients, ensuring compatibility while maintaining Wayland's security model. Mutter functions as the Wayland compositor underlying Shell, leveraging the to manage its scene graph for efficient rendering of windows, animations, and overlays. It includes built-in support for gestures, such as swipe actions for switching workspaces or overview navigation, enhancing user interaction on touch-enabled devices. Mutter also implements fractional scaling to handle high-DPI displays by allowing non-integer scale factors, which improves text and UI clarity on mixed-resolution setups without relying solely on integer scaling modes. Sway is a tiling Wayland compositor designed as a drop-in replacement for the i3 window manager, automatically arranging windows in a non-overlapping grid to optimize screen space. It maintains full compatibility with i3 configurations, permitting users to leverage existing keybindings and setup files for seamless migration to Wayland. Sway emphasizes keyboard-driven workflows, supporting rapid window manipulation through shortcuts for splitting layouts, resizing, and navigation, which suits productivity-focused users preferring minimal mouse interaction. Several tools complement Wayland compositors by aiding development, testing, and inspection. The wayland-info utility inspects the protocols advertised by a running Wayland compositor, listing supported interfaces and versions to verify compatibility for clients. Weston-simple-egl is a simple demo client that demonstrates EGL-based rendering on Wayland, creating an alpha-transparent surface to showcase hardware-accelerated graphics integration. Cage provides a minimal, KMS-based Wayland compositor tailored for mode, running a single maximized application fullscreen while restricting user access to other system elements.

Adoption and Ecosystem

Linux Distributions and Desktop Environments

Wayland has been the default display server protocol for the desktop environment in since version 25, released in November 2016. This shift positioned as an early leader in Wayland adoption among major distributions, with the protocol integrated via the Mutter compositor in sessions. introduced an optional Wayland session for starting with version 21.04 in April 2021, allowing users to select it at while defaulting to X11 for broader compatibility; by 25.10 in 2025, support for on Xorg was removed, making Wayland the exclusive option. provides experimental Wayland support across several s, with partial integration in since version 6.0 and ongoing development for others like and , though it remains opt-in and not default in stable releases. Among desktop environments, GNOME has offered a dedicated Wayland session since version 3.22 in 2016, enabling a native Wayland experience without X11 dependencies for core functionality. In 2025, GNOME's Mutter compositor dropped X11 support entirely, further solidifying Wayland as the sole option in GNOME 49 and later. KDE Plasma introduced a Wayland session with version 5.20 in October 2020, providing an alternative to its traditional X11 setup, though session stability has varied due to ongoing refinements in areas like input handling and multi-monitor support. Both environments rely on login managers such as GDM for GNOME and SDDM for KDE to present Wayland as an opt-in choice during user authentication. The transition to Wayland in these distributions and environments has faced challenges, particularly with proprietary NVIDIA drivers prior to version 470, which lacked sufficient Wayland support and often forced fallbacks to X11 sessions to avoid crashes or rendering issues. Users typically select Wayland sessions via gear icons in login managers, but compatibility layers like XWayland ensure legacy X11 applications run, albeit with potential performance overhead. As of November 2025, adoption continues to grow, driven by exclusive Wayland use in GNOME sessions of recent releases like Fedora 43, which removed the GNOME X11 session. Usage is growing in rolling-release distributions such as , where Wayland sessions are increasingly default or recommended for modern hardware, and in , where it serves as an option in Tumbleweed and experimental preview in Leap 16.0 for environments like .

Toolkit and Application Support

The GTK toolkit has provided a full Wayland backend since version 3.22, released in September 2016, enabling native support for rendering surfaces and handling input events through the GDK_WAYLAND implementation. This backend integrates with Wayland protocols for window management and compositing, allowing GTK applications to run without X11 dependencies while supporting features like tablet input and high-DPI scaling. Additionally, GTK leverages xdg-desktop-portal for secure inter-application interactions, such as file selection dialogs and color picker access, ensuring sandboxed compatibility in Wayland environments. Qt introduced its Wayland platform plugin in version 5.11, released in 2018, which serves as the primary interface for Qt applications to connect to Wayland compositors for display and event handling. The plugin supports native rendering via EGL and integrates with Wayland's output protocols for efficient buffer management. For developers building custom compositors, Qt offers the QWaylandCompositor module, providing C++ and QML APIs to implement shell surfaces and input handling. Qt's Wayland support also natively accommodates HiDPI displays by respecting per-output scaling factors reported by the compositor, reducing the need for manual adjustments. Other toolkits have similarly adapted to Wayland. SDL2 includes a dedicated Wayland video driver, selectable via the SDL_VIDEODRIVER=wayland environment variable, which handles window creation, input events, and rendering through Wayland protocols like xdg-shell. For web-based applications, Electron and Chromium utilize the Ozone-Wayland connector, an experimental backend that enables native Wayland operation when launched with flags like --ozone-platform=wayland, facilitating hardware-accelerated rendering and input for browser-embedded UIs. Notable applications demonstrate these toolkit integrations. Mozilla Firefox has supported native Wayland rendering since version 75, released in April 2020, allowing direct protocol communication for smoother performance and reduced latency compared to X11 fallbacks. The GIMP image editor, built on GTK, achieves native Wayland compatibility in version 3.0, released in March 2025, benefiting from the toolkit's backend for canvas rendering and tool interactions without requiring XWayland. However, some applications, particularly older Windows software emulated via Wine, continue to rely on XWayland for compatibility, as Wine's native Wayland driver remains in development and defaults to the X11 translation layer for broader application support. Cross-application features, such as screenshots and file access, are facilitated by xdg-desktop-portal, a D-Bus service that provides standardized, secure APIs for Wayland clients to request desktop resources without direct protocol extensions.

Embedded and Mobile Platforms

Wayland has found significant adoption in resource-constrained environments such as embedded systems and mobile devices, where its protocol and direct rendering model enable efficient graphics handling without the overhead of X11's features. In these platforms, Wayland compositors like Weston provide the foundation for user interfaces tailored to low-power hardware, supporting applications in automotive , mobile operating systems, and (IoT) devices. This adoption leverages Wayland's security model and reduced latency, which are particularly beneficial for battery-powered or real-time systems. In the automotive sector, Wayland is prominently used through the IVI-Shell extension, which defines protocols for in-vehicle (IVI) systems. The Weston IVI-Shell plugin implements the GENIVI (now ) API, allowing clients to manage surfaces for dashboards and interfaces via the ivi-application and ivi-hmi-controller protocols. This shell is integrated into Automotive Grade (AGL), where it is included by default in the agl-demo-platform image, enabling layered compositing for safety-critical displays. AGL's agl-compositor, built on libweston, further extends this support with private Wayland extensions for surface roles like panels and pop-ups, facilitating multi-application environments in vehicles. Compositors such as Qt Wayland are employed for rendering dashboards, using Qt's platform abstraction to interact with these extensions and ensure smooth integration of Qt-based applications. For mobile platforms, Wayland serves as the display server in several Linux-based operating systems targeting smartphones. supports multiple Wayland compositors, including Weston as a for (DRM) hardware, alongside interfaces like and Sxmo for touch-based navigation on devices such as the . , maintained by the UBports community, utilizes Lomiri—a Qt-based, Wayland-powered environment derived from Unity 8—to provide a convergent interface that adapts across phone, tablet, and desktop form factors. This shift to Wayland in OTA-12 introduced support for Mir's Wayland backend, enhancing compatibility with modern graphics stacks. also employs Wayland as its core protocol, leveraging and for gesture-driven interfaces on mobile hardware, with its built-in compositor handling window management and output. In embedded systems, particularly for IoT applications, the facilitates Wayland integration by providing recipes to build Wayland and Weston for targets supporting Mesa's (DRI). This enables lightweight compositing on single-board computers like the and BeagleBone, where Weston can be configured for hardware-accelerated rendering via GPU drivers. For instance, Yocto images for include Weston with enabled graphics acceleration, suitable for IoT dashboards or control panels, while BeagleBone's BSP layers allow similar customization for industrial embedded use. Wayland's viability on these platforms relies on open-source drivers in the Mesa graphics library, particularly for ARM-based GPUs common in low-power devices. Panfrost provides conformant OpenGL ES 3.1 and 1.2 support for Mali Midgard and Bifrost architectures, enabling efficient rendering in Wayland compositors without proprietary blobs. Similarly, Mesa's Freedreno driver handles GPUs, supporting and for mobile and embedded ARM hardware. These drivers facilitate low-latency on resource-limited systems, though challenges persist with legacy closed-source drivers that lack full Wayland compatibility, often requiring fallback to software rendering or XWayland bridges.

History and Development

Origins and Early Development

The Wayland protocol originated in 2008 when Kristian Høgsberg, a graphics developer at , began working on it as a response to longstanding frustrations with the X11 display server's architecture. Høgsberg, who had contributed to X.Org and the (EFL) during his time at , sought to address X11's inefficiencies in compositing, input handling, and direct GPU access, which complicated modern desktop development. The project's initial repository was established on September 30, 2008, under Høgsberg's authorship, laying the groundwork for a new between display servers and clients. Early development drew inspiration from for simplified access and the (DRI) for hardware-accelerated rendering, aiming to integrate these with kernel modesetting (KMS) for more efficient graphics pipelines. By 2011, the first commits to the Weston reference compositor appeared, focusing on a minimal implementation to test core concepts like buffer management and event handling. Høgsberg joined in 2009, bringing the project with him and fostering collaboration on key components, including the Generic Buffer Management (GBM) , which provided a vendor-neutral interface for allocating and sharing buffers between the compositor and GPU drivers. Early key contributors included Daniel Stone, who worked on protocol stability and integration with existing stacks, and Jonas Ådahl, who contributed to input and features; together, they formalized the Wayland project under the umbrella to enable broader open-source participation. Leading up to version 1.0, development emphasized defining a core protocol for surface management, input events, and output configuration, while avoiding feature bloat to ensure simplicity and security. The release of Weston 1.0 in 2012 served as the proof-of-concept, demonstrating a functional compositor that validated Wayland's design principles without relying on X11 for rendering or input.

Major Releases and Milestones

The Wayland protocol reached its initial milestone with version 1.0 on 22, 2012, accompanied by the release of Weston 1.0 as the reference compositor. This version solidified the core protocol specifications, emphasizing fundamental elements such as surface creation, buffer management, and input event handling, while committing to a for clients and servers. The release marked a shift from experimental development to a production-ready foundation, enabling early compositors to implement basic compositing without relying on X11 for rendering. Subsequent releases built incrementally on this base, with version 1.12 arriving on September 21, 2016. Key enhancements included refined protocol documentation and adjustments to support improved multi-monitor configurations, aligning with contemporaneous efforts like 's initial Wayland session experiments in 3.22. These changes facilitated more robust handling of display outputs and client positioning across multiple screens, reducing common edge cases in early deployments. Entering the 2020s, Wayland evolved through versions like 1.20, released December 9, 2021, which introduced official compatibility and further protocol refinements for broader platform support. Extensions in the accompanying wayland-protocols package advanced graphics integration, including wl_drm for direct rendering access and protocols for precise gamut handling in modern displays. Version 1.22, released April 4, 2023, added the preferred buffer scale interface to optimize high-DPI rendering, while compositor integrations with stabilized remote audio and video pipelines for seamless screen sharing and calls. Significant milestones included the establishment of formal governance for wayland-protocols under the freedesktop.org umbrella in 2019, standardizing extension reviews and maintenance processes. In 2024, development prioritized explicit synchronization, with the linux-drm-syncobj-v1 protocol merging into wayland-protocols 1.36 (released April 26, 2024) to resolve tearing artifacts, particularly benefiting GPU users by enabling precise buffer synchronization without legacy implicit methods. Subsequent releases included Wayland 1.23 on May 28, 2024, and 1.24 on July 7, 2025, with ongoing refinements to protocol stability and platform support; wayland-protocols reached version 1.45 on June 13, 2025. The community has sustained momentum through annual sessions at the X.Org Developer's since 2018, alongside continuous refinements to the defining protocol interfaces.

References

  1. https://wayland.freedesktop.org/
  2. https://wayland.freedesktop.org/docs/html/ch01.html
  3. https://wayland.freedesktop.org/docs/html/ch03.html
  4. https://www.phoronix.com/review/xorg_wayland
  5. https://www.phoronix.com/news/ODczNQ
  6. https://www.phoronix.com/news/MTA1MTQ
  7. https://wayland.freedesktop.org/releases.html
  8. https://cgit.freedesktop.org/wayland/wayland-protocols
  9. https://wayland.freedesktop.org/faq.html
  10. https://www.phoronix.com/news/MTIxMjM
  11. https://arstechnica.com/information-technology/2011/03/the-linux-graphics-stack-from-x-to-wayland/
  12. https://wayland.freedesktop.org/docs/html/ch04.html
  13. https://lwn.net/Articles/481490/
  14. https://cgit.freedesktop.org/wayland/wayland-protocols/tree/stable/presentation-time/presentation-time.xml
  15. https://lists.freedesktop.org/archives/wayland-devel/2025-February/043980.html
  16. https://lists.freedesktop.org/archives/wayland-devel/2024-December/043920.html
  17. https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_registry
  18. https://doc.qt.io/qt-6/wayland-and-qt.html
  19. https://wayland.freedesktop.org/docs/html/apa.html
  20. https://wiki.archlinux.org/title/Wayland
  21. https://pointieststick.com/2024/05/25/this-week-in-kde-triple-buffering-and-other-sources-of-amazingness/
  22. https://wayland-book.com/wayland-display/creation.html
  23. https://manpages.ubuntu.com/manpages/bionic/man3/wl_display_connect.3.html
  24. https://man.archlinux.org/man/extra/wayland-docs/wl_display.3.en
  25. https://gaultier.github.io/blog/wayland_from_scratch.html
  26. https://glfmn.io/posts/hardmode-triangle-1/
  27. https://wayland-book.com/seat/example.html
  28. https://wayland.freedesktop.org/docs/html/apb.html
  29. https://python-wayland.org/wayland/wl_display/
  30. https://wayland-book.com/surfaces-in-depth/frame-callbacks.html
  31. https://emersion.fr/blog/2018/wayland-rendering-loop/
  32. https://www.systutorials.com/docs/linux/man/3-wl_proxy_destroy/
  33. https://man.archlinux.org/man/extra/wayland-docs/wl_proxy.3.en
  34. https://ppaalanen.blogspot.com/2014/07/wayland-protocol-design-object-lifespan.html
  35. https://www.x.org/releases/current/doc/xproto/x11protocol.html
  36. https://wayland.freedesktop.org/architecture.html
  37. https://wayland.freedesktop.org/docs/html/ch05.html
  38. https://man.archlinux.org/man/Xwayland.1.en
  39. https://www.phoronix.com/news/Wayland-1.23-Released
  40. https://docs.fedoraproject.org/en-US/quick-docs/troubleshooting-wayland-problems/
  41. https://xpra.org/index.html
  42. https://www.phoronix.com/review/x_wayland_situation
  43. https://security.stackexchange.com/questions/3589/passive-and-active-attacks-via-x11-is-wayland-any-better
  44. https://planet.kde.org/matthias-klumpp-2024-01-11-wayland-really-breaks-things-just-for-now/
  45. https://discuss.kde.org/t/remote-desktop-using-the-rdp-protocol-for-plasma-wayland/3616
  46. https://www.phoronix.com/review/fedora_21_xwayland
  47. https://wiki.hypr.land/Useful-Utilities/Screen-Sharing/
  48. https://wayland.pages.freedesktop.org/weston/
  49. https://man.archlinux.org/man/weston.1.en
  50. https://wayland.freedesktop.org/libinput/doc/latest/
  51. https://wayland.app/protocols/pointer-gestures-unstable-v1
  52. https://lwn.net/Articles/589147/
  53. https://flatpak.github.io/xdg-desktop-portal/
  54. https://community.kde.org/KWin/Wayland
  55. https://mutter.gnome.org/
  56. https://blogs.gnome.org/shell-dev/author/feaneron/
  57. https://discourse.gnome.org/t/full-explanation-of-current-hidpi-fractional-and-integer-scaling-support-in-wayland/14225
  58. https://swaywm.org/
  59. https://man.archlinux.org/man/wayland-info.1.en
  60. https://gitlab.freedesktop.org/wayland/weston/blob/master/clients/simple-egl.c
  61. https://github.com/cage-kiosk/cage
  62. https://fedoraproject.org/wiki/Wayland_features
  63. https://www.phoronix.com/news/Ubuntu-21.04-Wayland-Default
  64. https://discourse.ubuntu.com/t/ubuntu-25-10-drops-support-for-gnome-on-xorg/62538
  65. https://wiki.debian.org/Wayland
  66. https://blogs.gnome.org/alatiera/2025/06/23/x11-session-removal-faq/
  67. https://www.phoronix.com/news/GNOME-Mutter-Drop-X11
  68. https://community.kde.org/Plasma/Wayland_Known_Significant_Issues
  69. https://www.phoronix.com/news/KDE-Plasma-5.20-More-Wayland
  70. https://www.ghacks.net/2025/09/17/fedora-linux-43-beta-released-drops-x11-support-to-go-wayland-only/
  71. https://news.opensuse.org/2025/08/04/leap-16-rc/
  72. https://mail.gnome.org/archives/gtk-devel-list/2016-September/msg00012.html
  73. https://developer.gnome.org/gtk3/stable/
  74. https://gnome.pages.gitlab.gnome.org/gtk/gtk4/wayland.html
  75. https://wiki.qt.io/QtWayland
  76. https://doc.qt.io/qt-6/qtwaylandcompositor-index.html
  77. https://wiki.libsdl.org/SDL2/FAQUsingSDL
  78. https://bugzilla.mozilla.org/show_bug.cgi?id=635134
  79. https://www.gimp.org/release-notes/gimp-3.0.html
  80. https://www.theregister.com/2025/03/20/gimp_3_and_photogimp/
  81. https://forum.winehq.org/viewtopic.php?t=38372
  82. https://www.collabora.com/news-and-blog/news-and-events/a-libweston-based-compositor-for-automotive-grade-linux.html
  83. https://wiki.automotivelinux.org/subsystem/graphics/weston-ivi-shell
  84. https://wiki.postmarketos.org/wiki/Category:Interface
  85. https://9to5linux.com/postmarketos-21-12-brings-support-for-more-devices-gnome-41-apps-and-sxmo-on-wayland
  86. https://ubports.com/lomiri
  87. https://www.phoronix.com/news/Ubuntu-Touch-OTA-12
  88. https://wiki.qt.io/SailfishOS
  89. https://docs.yoctoproject.org/dev/dev-manual/wayland.html
  90. https://anavi.org/article/189/
  91. https://docs.yoctoproject.org/kirkstone/bsp-guide/bsp.html
  92. https://docs.mesa3d.org/drivers/panfrost.html
  93. https://www.collabora.com/news-and-blog/news-and-events/improvements-to-mesa-video-decoding-for-panfrost.html
  94. https://people.freedesktop.org/~krh/General%20Wayland%20%283%29.pdf
  95. https://archive.fosdem.org/2012/interview/kristian-hogsberg.html
  96. https://cgit.freedesktop.org/wayland/wayland/commit/?id=97f1ebe8d5c2e166fabf757182c289fed266a45a
  97. https://lwn.net/Articles/520832/
  98. https://lists.freedesktop.org/archives/wayland-devel/2012-October/005967.html
  99. https://lists.freedesktop.org/archives/wayland-devel/2016-September/031121.html
  100. https://www.phoronix.com/news/Wayland-1.20-Released
  101. https://www.phoronix.com/news/Wayland-1.22-Released
  102. https://lists.freedesktop.org/archives/wayland-devel/2019-November/021878.html
  103. https://lists.freedesktop.org/archives/wayland-devel/2024-April/043581.html
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.