mirror of
https://gitlab.freedesktop.org/wayland/wayland.git
synced 2026-02-16 22:05:55 -05:00
74 lines
4.1 KiB
Markdown
74 lines
4.1 KiB
Markdown
|
# Introduction
|
|||
|
|
|
|||
|
|
## Motivation
|
|||
|
|
|
|||
|
|
Most Linux and Unix-based systems rely on the X Window System (or simply _X_) as
|
|||
|
|
the low-level protocol for building bitmap graphics interfaces. On these
|
|||
|
|
systems, the X stack has grown to encompass functionality arguably belonging in
|
|||
|
|
client libraries, helper libraries, or the host operating system kernel. Support
|
|||
|
|
for things like PCI resource management, display configuration management,
|
|||
|
|
direct rendering, and memory management has been integrated into the X stack,
|
|||
|
|
imposing limitations like limited support for standalone applications,
|
|||
|
|
duplication in other projects (e.g. the Linux fb layer or the DirectFB project),
|
|||
|
|
and high levels of complexity for systems combining multiple elements (for
|
|||
|
|
example radeon memory map handling between the fb driver and X driver, or VT
|
|||
|
|
switching).
|
|||
|
|
|
|||
|
|
Moreover, X has grown to incorporate modern features like offscreen rendering
|
|||
|
|
and scene composition, but subject to the limitations of the X architecture. For
|
|||
|
|
example, the X implementation of composition adds additional context switches
|
|||
|
|
and makes things like input redirection difficult.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
The diagram above illustrates the central role of the X server and compositor in
|
|||
|
|
operations, and the steps required to get contents on to the screen.
|
|||
|
|
|
|||
|
|
Over time, X developers came to understand the shortcomings of this approach and
|
|||
|
|
worked to split things up. Over the past several years, a lot of functionality
|
|||
|
|
has moved out of the X server and into client-side libraries or kernel drivers.
|
|||
|
|
One of the first components to move out was font rendering, with freetype and
|
|||
|
|
fontconfig providing an alternative to the core X fonts. Direct rendering OpenGL
|
|||
|
|
as a graphics driver in a client side library went through some iterations,
|
|||
|
|
ending up as DRI2, which abstracted most of the direct rendering buffer
|
|||
|
|
management from client code. Then cairo came along and provided a modern 2D
|
|||
|
|
rendering library independent of X, and compositing managers took over control
|
|||
|
|
of the rendering of the desktop as toolkits like GTK+ and Qt moved away from
|
|||
|
|
using X APIs for rendering. Recently, memory and display management have moved
|
|||
|
|
to the Linux kernel, further reducing the scope of X and its driver stack. The
|
|||
|
|
end result is a highly modular graphics stack.
|
|||
|
|
|
|||
|
|
## The compositing manager as the display server
|
|||
|
|
|
|||
|
|
Wayland is a new display server and compositing protocol, and Weston is the
|
|||
|
|
implementation of this protocol which builds on top of all the components above.
|
|||
|
|
We are trying to distill out the functionality in the X server that is still
|
|||
|
|
used by the modern Linux desktop. This turns out to be not a whole lot.
|
|||
|
|
Applications can allocate their own off-screen buffers and render their window
|
|||
|
|
contents directly, using hardware accelerated libraries like libGL, or high
|
|||
|
|
quality software implementations like those found in Cairo. In the end, what’s
|
|||
|
|
needed is a way to present the resulting window surface for display, and a way
|
|||
|
|
to receive and arbitrate input among multiple clients. This is what Wayland
|
|||
|
|
provides, by piecing together the components already in the eco-system in a
|
|||
|
|
slightly different way.
|
|||
|
|
|
|||
|
|
X will always be relevant, in the same way Fortran compilers and VRML browsers
|
|||
|
|
are, but it’s time that we think about moving it out of the critical path and
|
|||
|
|
provide it as an optional component for legacy applications.
|
|||
|
|
|
|||
|
|
Overall, the philosophy of Wayland is to provide clients with a way to manage
|
|||
|
|
windows and how their contents are displayed. Rendering is left to clients, and
|
|||
|
|
system wide memory management interfaces are used to pass buffer handles between
|
|||
|
|
clients and the compositing manager.
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
The figure above illustrates how Wayland clients interact with a Wayland server.
|
|||
|
|
Note that window management and composition are handled entirely in the server,
|
|||
|
|
significantly reducing complexity while marginally improving performance through
|
|||
|
|
reduced context switching. The resulting system is easier to build and extend
|
|||
|
|
than a similar X system, because often changes need only be made in one place.
|
|||
|
|
Or in the case of protocol extensions, two (rather than 3 or 4 in the X case
|
|||
|
|
where window management and/or composition handling may also need to be
|
|||
|
|
updated).
|