① The evdev module of the Linux kernel gets an event and sends it to the Wayland compositor.
② The Wayland compositor looks through its scenegraph to determine which window should receive the event. The scenegraph corresponds to what's on screen and the Wayland compositor understands the transformations that it may have applied to the elements in the scenegraph. Thus, the Wayland compositor can pick the right window and transform the screen coordinates to window local coordinates, by applying the inverse transformations. The types of transformation that can be applied to a window is only restricted to what the compositor can do, as long as it can compute the inverse transformation for the input events.
③ As in the X case, when the client receives the event, it updates the UI in response. But in the Wayland case, the rendering happens by the client via EGL, and the client just sends a request to the compositor to indicate the region that was updated.
④ The Wayland compositor collects damage requests from its clients and then re-composites the screen. The compositor can then directly issue an ioctl to schedule a pageflip with KMS.

In recent years, Linux desktop graphics has moved from having "a pile of rendering interfaces... all talking to the X server, which is at the center of the universe" towards putting the Linux kernel and its components (i.e. DRI, 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".[6]

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

“

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.

Wayland does not currently provide network transparency, but it may in the future.[8] It was attempted as a Google Summer of Code project in 2011, but was not successful.[9] 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).[10] As of early 2013, Høgsberg is experimenting with network transparency using a proxy Wayland server which sends compressed images to the real compositor.[11]

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

Wayland protocol follows a client-server model in which clients are the graphical applications requesting the display of pixel buffers on the screen, and the server (compositor) is the service provider controlling the display of these buffers.

The Wayland reference implementation has been designed as a two-layer protocol:[12]

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

While the low-level layer was written manually in C language, the high-level layer is automatically generated from a description of the elements of the protocol stored in XML format.[15] 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.[16]

The Wayland protocol is described as an "asynchronous object oriented protocol." Object oriented means that the services offered by the compositor are presented as a series of objects living on the same compositor. Each object implements an interface which has a name, a number of methods (called requests) as well as several associated events. Every request and event has zero or more arguments, each one with a name and a data type.[14] 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.[14]

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.[14] 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.[17]

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 can define and implement their own interfaces with their own requests and events, in order to extend its functionality beyond the core protocol.[18] To facilitate changes between versions of the protocol, interfaces contain a "version number" attribute in addition to its name; this attribute allows an interface to be treated differently from previous versions of itself with fewer or different requests and events. Each Wayland compositor exposes not only what interfaces are available but also their supported version, and objects implement a particular version of an interface.[19]

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

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

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

The Wayland protocol does not include a rendering API.[21][22][23][24] Instead, Wayland follows a direct rendering model, in which the client must render the window contents to a buffer shareable with the compositor.[22] 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.

There are several differences between Wayland and X in regards to performance, code maintainability and security:[25]

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

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

Rendering: the X server is able to render itself, although it can be instructed to display the rendered windows sent by clients. Wayland does not expose any API to render and delegates all the rendering responsibilities (including font rendering, widgets rendering, etc.) to the clients. Window decorations can be rendered on the client side, by the graphic toolkit, or on the server side, by the compositor.[28]

Security: Wayland isolates the input and output of every window, achieving confidentiality, integrity and availability in both cases; X lacks these important security features.[29] Also, with the vast majority of the code running in the client, less code needs to run with root privileges, improving security.[30]

Inter-process communication: the X server provides a basic communication method between X clients, later extended by ICCCM conventions. This X client-to-client communication is used by window managers and also to implement X sessions, selections and drag-and-drop, and other features. Wayland core protocol does not support communication between wayland clients at all, and the corresponding functionality (if needed) should be implemented by the desktop environments (like KDE or GNOME), or by a third party (for example, by using native IPC of the underlying operating system).

Networking: The X Window System is an architecture that was designed at its core to run over a network. Wayland does not offer network transparency by itself; however, a compositor can implement any remote desktop protocol to achieve remote displaying. In addition, there is research into Wayland image streaming and compression that would provide remote frame buffer access similar to that of VNC.[31]

Some of the differences can also be easily understood by comparing the architecture diagrams of both protocols.[32]

XWayland is an X Server running as a Wayland client, thus capable of displaying native X11 client applications in a Wayland compositor environment.[33] This is similar to the way XQuartz runs X applications in OS X’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[34]

Qt applications can switch between graphical back-ends like X and Wayland at load time with the -platform command-line option.[35] In January 2011, Wayland support was moved into the Lighthouse branch of the upstream Qt repository.[36] Qt Lighthouse is shipped in the Qt 4.8 release.[37]

In December 2010, GTK+ added preliminary support for switching back-ends at run time, saying "interesting combinations are X11+Wayland or Quartz+X11".[38][39] In January 2011, the GTK+ Wayland backend was updated to support the multiple-backends feature and moved to the gdk-wayland-backend branch of the upstream GTK+ Git repository.[40] In April 2011, the gdk-wayland-backend branch was merged in the GTK+ master branch.

Typical elements of a window. Neither Wayland nor X11 specify which software has to do the drawing of the window decoration. Weston requires that they be drawn by the client, but KWin will implement server-side decoration.[28]

Weston is written for the Linux kernel; as of February 2013[update], a prototype port of Wayland to FreeBSD was announced.[46]

Weston relies on GEM to share application buffers between the compositor and applications. It contains a plugin system, external "shells" for WM/dock/etc, and Weston supports X clients. Clients are responsible for the drawing of their window borders and their decorations. For rendering, Weston can use OpenGL ES or software (pixman[47]).[48] The full OpenGL implementation is not used, because on most current systems, installing the full OpenGL libraries would also install GLX and other X Window System support libraries as dependencies.[49]

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. Each Wayland compositor is supposed to provide its own implementation.

As of June 2014[update], XDG-Shell protocol was not versioned and still prone to changes.

xdg_shell is a protocol aimed to substitute wl_shell in the long term, but will not be part of the Wayland core protocol. It starts as a non-stable API, aimed to be used as a development place at first, and once features are defined as required by several desktop shells, it can be finally made stable. It provides mainly two new interfaces: xdg_surface and xdg_popup. The xdg_surface interface implements a desktop-style window that can be moved, resized, maximized, etc.; it provides a request for creating child/parent relationship. The xdg_popup interface implements a desktop-style popup/menu; an xdg_popup is always transient for another surface, and also has implicit grab.[59]

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. Wayland developers are actively looking for feasible ways to handle privileged clients securely and then designing privileged interfaces for them.

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

As explained in the "Software architecture" section above, the Wayland protocol is designed to be simple so that additional protocols and interfaces need to be defined and implemented to achieve a holistic windowing system. As of July 2014, these additional interfaces are actively being worked on. So, while the toolkits already fully support Wayland, the developers of the graphical shells are cooperating with the Wayland developers creating the necessary additional interfaces:

This section is outdated. Please update this article to reflect recent events or newly available information.Last update: Updates are required regarding the current roadmap and GNOME 3.12 as the first version to be fully ported to Wayland(October 2014)

KWin: is in the process of becoming a Wayland compositor, but support is incomplete;[66] support for OpenGL ES output was added in 2010,[67] in version 4.7.[68] In January 2013 KWin’s main developer Martin Grässlin started working for Blue Systems with one of the goals being a complete Wayland port.[69] Experimental Wayland support is now working in current KWin 4.11.[70]

KDE Frameworks 5: it is possible to run most applications built on top of Frameworks 5 under a Wayland compositor, without X11 as X11-dependent codepaths have become optional.[66]

KDE Plasma 5: is based on Frameworks 5, but as e.g. interfaces between the workspace shell, the compositor (KWin) and the display server are not yet well-defined or implemented up-stream, support is incomplete.[66]

GNOME: In March 2013 GNOME developers announced plans for a complete Wayland port within a year.[75] GNOME 3.10 includes initial support that "will enable the project to fully adopt the next generation display and input technology in the future".[76][77] The current roadmap targets GNOME 3.16 as the first version to be fully ported to Wayland.[78]

MATE: Wayland support is on MATE’s roadmap, with 1.12 as the targeted MATE version.[79]

Sailfish OS: The Jolla's company smartphones use Wayland as standard. It is also used as standard when Linux Sailfish OS is used with hardware from other vendors or when it is installed into Android devices by users.[100][101][102]

Kristian Høgsberg, a software engineer who works on the Linux graphics stack, started Wayland as a spare-time project in 2008, while working for Red Hat;[103] he is now at Intel.[104] His earlier work on X included AIGLX,[105] which enabled hardware acceleration of compositing window managers, and DRI2.[106][107][108] 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."

The name "Wayland" comes from the town of Wayland, Massachusetts. Høgsberg was driving through that town when the concepts behind Wayland "crystallized".[109]

On 4 October 2013 Nvidia released a beta version of their 331.13 driver which supports the EGL API.[117] Although limited to X11, IT publications such as Phoronix and Golem.de noted that EGL support in the Nvidia driver could pave the way for future Wayland support.[118][119] In March 2014, Nvidia announced a change in Wayland was "[throwing] a wrench into things" in their planned support for Wayland.[120]

^Kristian Høgsberg (9 November 2010). "Network transparency argument".
"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."

^"Wayland FAQ". Wayland project. Wayland project. Retrieved 4 September 2014. "Wayland doesn't render on behalf of the clients, it expects the clients to use whatever means they prefer to render into a shareable buffer."

^Barnes, Jesse. "Introduction to Wayland". Intel Open Source Technology Center. "Does not include a rendering API – Clients use what they want and send buffer handles to the server"

^"Nvidia drivers 331.13 beta". 4 October 2013. Retrieved 5 October 2013. Added support for the EGL API on 32-bit platforms. Currently, the supported client APIs are OpenGL ES 1.1, 2.0 and 3.0, and the only supported window system backend is X11.