[9][14] The project's source code is published under the terms of the MIT License, a permissive free software licence.

[9] The Wayland Display Server project was started by Red Hat developer Kristian Høgsberg in 2008.

[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 the entire core rendering API that lets you draw stippled lines, polygons, wide arcs and many more state-of-the-1980s style graphics primitives.

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.

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

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.

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 compositor in turn sends information back to the client by causing the object to emit events (probably with arguments too).

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.

[26] This is an XML file that lists the existing interfaces in the current version, along with their requests, events and other attributes.

XDG-Shell protocol (see freedesktop.org for XDG) is an extended way to manage surfaces under Wayland compositors (not only Weston).

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.

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

The client can also optionally use other specialized libraries to perform specific tasks, such as Freetype for font rendering.

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.

[41]: 7  The procedure used for rendering, including the number of buffers involved and their management, is entirely under the client control.

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.

Qt 5 provides the -platform command-line option[57] to that effect, whereas GTK 3 lets users select the desired GDK back-end by setting the GDK_BACKEND Unix environment variable.

Weston has official support for only the Linux operating system due to Weston's dependence on certain features of the Linux kernel, such as kernel mode-setting, Graphics Execution Manager (GEM), and udev, which have not been implemented in other Unix-like operating systems.

[78] The Raspberry Pi Foundation in collaboration with Collabora released Maynard and work on improving performance and memory consumption.

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

[90] Some applications (especially the ones related to accessibility) require privileged capabilities that should work across different Wayland compositors.

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.

[123] During 2020 Klipper was ported to Wayland and Plasma 5.20, released in October 2020, improved screen casting and recording.

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

[150][151] 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.