The Wayland compositor looks through itsscenegraph 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 viaEGL, 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 anioctl to schedule a pageflip withKMS.
The Wayland Display Server project was started byRed Hat developer Kristian Høgsberg in 2008.[15]
Beginning around 2010, Linux desktop graphics have moved from having "a pile ofrendering interfaces... all talking to theX 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 anextension 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 theX 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 asXRandR,XRender andCOMPOSITE ... 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 namedWeston. The project is also developing versions ofGTK andQt 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 providednetwork transparency, though Høgsberg noted in 2010 that network transparency is possible.[17]It was attempted as aGoogle 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" (likeVNC) or getting it to send a "rendering command stream" across the network (as inRDP,SPICE orX11).[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 anxdg-desktop-portal implementation that implements the RemoteDesktop portal.
Many Wayland compositors also include anxdg-desktop-portal implementation for common tasks such as a native file picker for native applications and sandboxes such asFlatpak (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.
In the Wayland protocol architecture, a client and a compositor communicate through the Wayland protocol using the reference implementation libraries.
The Wayland protocol follows aclient–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 orwire protocol that handles theinter-process communication between the two involvedprocesses—client and compositor—and themarshalling of the data that they interchange. This layer is message-based and usually implemented using the kernel IPC services, specificallyUnix domain sockets in the case ofLinux and otherUnix-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 awindow system. This layer is implemented as "an asynchronous object-oriented protocol".[25]
While the low-level layer was written manually inC, the high-level layer is automatically generated from a description of the elements of the protocol stored inXML 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 twolibraries: a library to be used by Wayland clients calledlibwayland-client and a library to be used by Wayland compositors calledlibwayland-server.[27]
The Wayland protocol is described as an "asynchronousobject-oriented protocol".[25]Object-oriented means that the services offered by the compositor are presented as a series ofobjects living on the same compositor. Each object implements aninterface which has a name, a number of methods (calledrequests) as well as several associatedevents. Every request and event has zero or more arguments, each one with a name and adata type. The protocol isasynchronous in the sense that requests do not have to wait for synchronized replies orACKs, avoidinground-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]
The interfaces of the current version of Wayland protocol are defined in the fileprotocol/wayland.xml of the Wayland source code.[26] This is anXML 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 awl_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 likepointers orkeyboards
wl_seat – an object representing a seat (a set of input/output devices) inmultiseat configurations
A typical Wayland client session starts by opening a connection to the compositor using thewl_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 thewl_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 awl_compositor object from where it will request one or morewl_surface objects to show the application output on the display.[28]
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 aswl_subsurface interface added in Wayland 1.4[31]).
XDG-Shell protocol (seefreedesktop.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 inlibwayland-client. An implementation of the xdg-shell protocol, on the contrary, is supposed to be provided by the Wayland compositor. So you will find thexdg-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]
The Wayland protocol does not include a rendering API.[34][14][35][36]: 2 Instead, Wayland follows adirect 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 likeCairo orOpenGL, or rely on the rendering engine of high-level widget libraries with Wayland support, such asQt orGTK. The client can also optionally use other specialized libraries to perform specific tasks, such asFreetype forfont rendering.
The resulting buffer with the rendered window contents are stored in awl_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 thesystem memory, then client and compositor can useshared memory to implement the buffer communication without extra copies. The Wayland protocol already natively provides this kind of shared memory buffer through thewl_shm[38] andwl_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 avideo memory buffer using a hardware (GPU) accelerated API such asOpenGL,OpenGL ES orVulkan. 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
There are several differences between Wayland and X with regard to performance, code maintainability, and security:[42]
Architecture
Thecomposition 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 thewindow 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-inxdg-decoration protocol, if the compositor chooses to implement such functionality.[46]
Security
Wayland isolates the input and output of every window, achievingconfidentiality, 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 withroot privileges, improving security,[11] although multiple popular Linux distributions now allow the X server to be run without root privileges.[50][51][52][53]
Inter-process communication
The X server provides a basic communication method between X clients, later extended byICCCM conventions. This X client-to-client communication is used by window managers and also to implementX sessions,selections and drag-and-drop, and other features. The Wayland core protocol does not support communication between Wayland clients at all as the corresponding functionality (if needed) is regarded by the Wayland community as something which should be implemented by thedesktop environments (like KDE or GNOME), or by a third party (for example, by using nativeIPC of the underlying operating system).
Networking
The X Window System is anarchitecture 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 anyremote 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 ofVNC.[21]
XWayland is anX Server running as a Wayland client, and thus is capable of displaying native X11 client applications in a Wayland compositor environment.[54] This is similar to the wayXQuartz runs X applications inmacOS'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 intoX.Org Server version 1.16.[55]
Widget toolkits such asQt5 andGTK3 can switch their graphical back-end at run time,[56] allowing users to choose atload time whether they want to run the application over X or over Wayland. Qt 5 provides the-platform command-line option[57] to that effect, whereas GTK 3 lets users select the desiredGDK back-end by setting theGDK_BACKENDUnix environment variable.[56][58]
Typical elements of awindow. The Wayland protocol does not specify what software is responsible for rendering thewindow decoration.[46]Plasma 5.24.0 (February 2022) on Wayland (kwin_wayland compositor) underArch Linux
Display servers that implement the Wayland display server protocol are also calledWayland compositors because they additionally perform the task of acompositing window manager.
A library calledwlroots is a modular Wayland implementation that functions as a base for several compositors[59]
Enlightenment claimed full Wayland support since version 0.20[60] but work is currently underway to land a complete Wayland compositor[61]
KWin has nearly complete Wayland support as of 2021[62]
Mutter maintained a separate branch for the integration of Wayland for GNOME 3.9 (in September 2013);[63] in the 3.13.1 release in 2014, the Wayland branch was merged into the main repository.[64]
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.[65][66][67]
Hyprland – 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.[68][69]
Woodland – a wlroots-based stacking Wayland compositor written in C, inspired by TinyWL and focused on simplicity and stability.
Weston is the reference implementation of a Wayland compositor[70] also developed by the Wayland project. It is written inC and published under theMIT License. Weston has official support for only theLinux operating system due to Weston's dependence on certain features of theLinux kernel, such askernel mode-setting,Graphics Execution Manager (GEM), andudev, which have not been implemented in other Unix-like operating systems.[71] When running on Linux, handling of the input hardware relies onevdev, while the handling of buffers relies onGeneric Buffer Management (GBM). However, in 2013 a prototype port of Weston toFreeBSD was announced.[72]
Weston relies on GEM to share application buffers between the compositor and applications. It contains a plug-in system of "shells" for common desktop features like docks and panels.[21] Clients are responsible for the drawing of their window borders and their decorations. For rendering, Weston can useOpenGL ES[74] or the pixman library to dosoftware rendering.[75] The full OpenGL implementation is not used, because on most current systems, installing the full OpenGL libraries would also installGLX and otherX Window System support libraries as dependencies.[76]
A remote access interface for Weston was proposed in October 2013 by aRealVNC employee.[77]
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, calledlibinput, for which support was first merged in Weston 1.5.[81][82]
Libinput handles input devices for multiple Wayland compositors and also provides a genericX.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] (viaudev), device handling, input device event processing and abstraction.[83][84]
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.[85]
As GNOME/GTK andKDE Frameworks 5[86] have mainlined the required changes, Fedora 22 will replace X.Org's evdev and Synaptics drivers with libinput.[87]
With version 1.16, theX.Org Server obtained support for the libinput library in form of a wrapper calledxf86-input-libinput.[88][89]
Some applications (especially the ones related toaccessibility) 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 throughxdg-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.[90]
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[update] these additional interfaces were being worked on. So, while the toolkits already fully support Wayland, the developers of thegraphical shells are cooperating with the Wayland developers creating the necessary additional interfaces.
As of 2020[update] most Linux distributions support Wayland out of the box. Some notable examples are:
Fedora starting with version 25 (released 22 November 2016) uses Wayland for the default GNOME 3.22 desktop session, withX.Org as a fallback if the graphics driver cannot support Wayland.[91] Fedora uses Wayland as the default for KDE desktop session starting with version 34 (released 27 April 2021)
Ubuntu shipped with Wayland by default in Ubuntu 17.10 (Artful Aardvark).[92] However, Ubuntu 18.04 LTS reverted to X.Org by default due to several issues.[93][94] Since Ubuntu 21.04, Wayland is the default again.[95]
Debian ships Wayland as the default session for GNOME since version 10, released 6 July 2019.[97]
Slackware Linux included Wayland on 20 February 2020[98] for the development version, -current, which became version 15.0.
Manjaro ships Wayland as default in the Gnome edition of Manjaro 20.2 (Nibia) (released 22 November 2020).[99]
Notable early adopter:
RebeccaBlackOS is alive USB Debian-based[100] 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.[101] It has been used since as early as 2012 to showcase Wayland.[102][103]
In November 2015, Enlightenment e20 was announced with full Wayland support.[116][60][117] GNOME 3.20 was the first version to have a full Wayland session.[118] GNOME 3.22 included much improved Wayland support across GTK, Mutter, and GNOME Shell.[119] GNOME 3.24 shipped support for the proprietary Nvidia drivers under Wayland.[120]
Wayland support for KDE Plasma was delayed until the release of Plasma 5,[121] though previouslyKWin 4.11 got an experimental Wayland support.[122] The version 5.4 of Plasma was the first with a Wayland session.[123] During 2020 Klipper was ported to Wayland and Plasma 5.20, released in October 2020, improved screen casting and recording.[124][125] In Plasma 6, the default graphical session that uses Wayland was set as the default, making the X11 session secondary.[126]
Eclipse was made to run on Wayland during aGSoC-Project in 2014.[135]
TheVulkan 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.[136]
Waydroid (formerly calledAnbox-Halium), a container for Android applications to run on Linux distributions using Wayland.
Jolla: Smartphones from Jolla use Wayland. It is also used as standard when LinuxSailfish OS is used with hardware from other vendors or when it is installed into Android devices by users.[139][140][141]
Kristian Høgsberg, aLinux graphics andX.Orgdeveloper who previously worked onAIGLX andDRI2, started Wayland as a spare-time project in 2008 while working forRed Hat.[145][146][147][148] 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 ofWayland, Massachusetts when the underlying concepts "crystallized", hence the name (Weston andMaynard are also nearby towns in the same area, continuing the reference).[147][149]
In October 2010, Wayland became afreedesktop.org project.[150][151] As part of the migration the priorGoogle Group was replaced by thewayland-devel mailing list as the project's central point of discussion and development.
The Wayland client and server libraries were initially released under theMIT License,[152] while the reference compositor Weston and some example clients used theGNU General Public License version 2.[153] Later all the GPL codewas relicensed under the MIT license "to make it easier to move code between the reference implementation and the actual libraries".[154] 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 theX.Org project (known asMIT Expat License).[6]
Weston 12.0.0[224] was released on 2023-05-17. Weston 12.0.4[225] was released on 2024-04-23. Weston 13.0.0[226] was released on 2023-11-27. Weston 13.0.3[227] was released on 2024-06-05.
^Corbet, Jonathan (5 November 2010)."LPC: Life after X".LWN.net.Archived from the original on 28 April 2016. Retrieved17 April 2016.
^Høgsberg, Kristian (9 November 2010)."Network transparency argument".Archived from the original on 15 August 2020. Retrieved14 January 2020.Wayland isn't a remote rendering API like X, but that doesn't exclude network transparency. Clients render into a shared buffer and then have to tell the compositor (...) what they changed. The compositor can then send the new pixels in that region out over the network. The Wayland protocol is already violently asynchronous, so it should be able to handle a bit of network lag gracefully. Remote fullscreen video viewing or gaming isn't going to work well, [but] I don't know any other display system that handles that well and transparently.
^Stone, Daniel (28 January 2013).The real story behind Wayland and X (Speech). linux.conf.au 2013. Canberra.Archived from the original on 10 August 2017. Retrieved13 April 2016.
^abHøgsberg, Kristian (24 January 2014)."Wayland and Weston 1.4 is out".wayland-devel (Mailing list).Archived from the original on 5 April 2020. Retrieved14 January 2020.
^Barnes, Jesse."Introduction to Wayland"(PDF). Intel Open Source Technology Center.Archived(PDF) from the original on 6 April 2016. Retrieved18 April 2016.Does not include a rendering API – Clients use what they want and send buffer handles to the server
^Paalanen, Pekka (21 November 2012)."On supporting Wayland GL clients and proprietary embedded platforms".Archived from the original on 6 April 2016. Retrieved6 April 2016.Buffer sharing works by creating a handle for a buffer, and passing that handle to another process which then uses the handle to make the GPU access again the same buffer.
^"X.Org Security".X.Org Foundation.Archived from the original on 22 December 2017. Retrieved2 July 2017.The X server has long included an extension, SECURITY, which provides support for a simple trusted/untrusted connection model.
^Bradford, Rob (16 December 2011)."Clutter & Cogl Wayland update". Archived fromthe original on 10 March 2016. Retrieved9 March 2016.The Clutter client side support is basically complete
^abHillesley, Richard (13 February 2012)."Wayland - Beyond X".The H Open. Heise Media UK. Archived fromthe original on 6 December 2013. Retrieved8 March 2016.
^Høgsberg, Kristian (3 December 2008)."Wayland is now under MIT license".wayland-display-server (Mailing list).Archived from the original on 9 November 2012. Retrieved8 March 2016.
^Høgsberg, Kristian (22 November 2010)."Wayland license clarification".wayland-devel (Mailing list).Archived from the original on 9 March 2016. Retrieved8 March 2016.
^Høgsberg, Kristian (19 September 2011)."License update".wayland-devel (Mailing list).Archived from the original on 29 April 2016. Retrieved8 March 2016.
^Høgsberg, Kristian (22 October 2012)."Wayland and Weston 1.0".wayland-devel (Mailing list).Archived from the original on 23 August 2019. Retrieved14 January 2020.
^Harrington, Bryce (14 February 2015)."[ANNOUNCE] wayland 1.7.0".wayland-devel (Mailing list).Archived from the original on 5 April 2020. Retrieved14 January 2020.
^Harrington, Bryce (14 February 2015)."[ANNOUNCE] weston 1.7.0".wayland-devel (Mailing list).Archived from the original on 5 April 2020. Retrieved14 January 2020.
^Harrington, Bryce (2 June 2015)."[ANNOUNCE] wayland 1.8.0".wayland-devel (Mailing list).Archived from the original on 15 August 2020. Retrieved14 January 2020.
^Harrington, Bryce (2 June 2015)."[ANNOUNCE] weston 1.8.0".wayland-devel (Mailing list).Archived from the original on 15 August 2020. Retrieved14 January 2020.
^Harrington, Bryce (21 September 2015)."[ANNOUNCE] wayland 1.9.0".wayland-devel (Mailing list).Archived from the original on 25 October 2020. Retrieved14 January 2020.
^Harrington, Bryce (21 September 2015)."[ANNOUNCE] weston 1.9.0".wayland-devel (Mailing list).Archived from the original on 21 September 2020. Retrieved14 January 2020.
^Harrington, Bryce (17 February 2016)."[ANNOUNCE] wayland 1.10.0".wayland-devel (Mailing list).Archived from the original on 17 February 2016. Retrieved17 February 2016.
^Harrington, Bryce (17 February 2016)."[ANNOUNCE] weston 1.10.0".wayland-devel (Mailing list).Archived from the original on 24 February 2016. Retrieved17 February 2016.
^Harrington, Bryce (1 June 2016)."[ANNOUNCE] wayland 1.11.0".wayland-devel (Mailing list).Archived from the original on 1 June 2016. Retrieved1 June 2016.
^Harrington, Bryce (1 June 2016)."[ANNOUNCE] weston 1.11.0".wayland-devel (Mailing list).Archived from the original on 8 October 2016. Retrieved1 June 2016.
^Harrington, Bryce (21 September 2016)."[ANNOUNCE] wayland 1.12.0".wayland-devel (Mailing list).Archived from the original on 2 April 2017. Retrieved21 September 2016.
^Harrington, Bryce (21 September 2016)."[ANNOUNCE] weston 1.12.0".wayland-devel (Mailing list).Archived from the original on 8 October 2016. Retrieved21 September 2016.
^Harrington, Bryce (21 February 2017)."[ANNOUNCE] wayland 1.13.0".wayland-devel (Mailing list).Archived from the original on 24 February 2017. Retrieved30 April 2017.
^Harrington, Bryce (25 February 2017)."[ANNOUNCE] weston 2.0.0".wayland-devel (Mailing list).Archived from the original on 2 March 2017. Retrieved30 April 2017.
^Harrington, Bryce (8 August 2017)."[ANNOUNCE] wayland 1.14.0".wayland-devel (Mailing list).Archived from the original on 20 October 2018. Retrieved25 March 2018.
^Harrington, Bryce (8 August 2017)."[ANNOUNCE] weston 3.0.0".wayland-devel (Mailing list).Archived from the original on 20 October 2018. Retrieved25 March 2018.
^Foreman, Derek (9 April 2018)."[ANNOUNCE] wayland 1.15.0".wayland-devel (Mailing list).Archived from the original on 10 April 2018. Retrieved15 April 2018.
^Foreman, Derek (9 April 2018)."[ANNOUNCE] weston 4.0.0".wayland-devel (Mailing list).Archived from the original on 10 April 2018. Retrieved15 April 2018.
^Foreman, Derek (24 August 2018)."[ANNOUNCE] wayland 1.16.0".wayland-devel (Mailing list).Archived from the original on 28 August 2018. Retrieved30 November 2018.
^Foreman, Derek (24 August 2018)."[ANNOUNCE] weston 5.0.0".wayland-devel (Mailing list).Archived from the original on 25 August 2018. Retrieved30 November 2018.
^Ser, Simon (27 January 2021)."[ANNOUNCE] wayland 1.19.0".wayland-devel (Mailing list).Archived from the original on 1 February 2021. Retrieved27 January 2021.
^Ser, Simon (27 January 2021)."[ANNOUNCE] wayland 1.20.0".wayland-devel (Mailing list).Archived from the original on 11 December 2021. Retrieved27 January 2021.
^Ser, Simon (1 February 2022)."[ANNOUNCE] weston 10.0.0" (Mailing list).Archived from the original on 4 February 2022. Retrieved12 February 2022.
.svg)
