|
|
<?xml version='1.0' encoding='utf-8' ?>
|
|
|
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
|
|
<!ENTITY % BOOK_ENTITIES SYSTEM "Wayland.ent">
|
|
|
%BOOK_ENTITIES;
|
|
|
]>
|
|
|
<chapter id="chap-Introduction">
|
|
|
<title>Introduction</title>
|
|
|
<section id="sect-Motivation">
|
|
|
<title>Motivation</title>
|
|
|
<para>
|
|
|
Most Linux and Unix-based systems rely on the X Window System (or
|
|
|
simply <emphasis>X</emphasis>) 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).
|
|
|
</para>
|
|
|
<para>
|
|
|
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.
|
|
|
</para>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="images/x-architecture.png" format="PNG" />
|
|
|
</imageobject>
|
|
|
<textobject>
|
|
|
<phrase>
|
|
|
X architecture diagram
|
|
|
</phrase>
|
|
|
</textobject>
|
|
|
</mediaobject>
|
|
|
<para>
|
|
|
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.
|
|
|
</para>
|
|
|
<para>
|
|
|
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.
|
|
|
</para>
|
|
|
|
|
|
</section>
|
|
|
|
|
|
<section id="sect-Compositing-manager-display-server">
|
|
|
<title>The compositing manager as the display server</title>
|
|
|
<para>
|
|
|
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.
|
|
|
</para>
|
|
|
<para>
|
|
|
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.
|
|
|
</para>
|
|
|
<para>
|
|
|
Overall, the philosophy of Wayland is to provide clients with a way to
|
|
|
manage windows and how their contents is displayed. Rendering is left
|
|
|
to clients, and system wide memory management interfaces are used to
|
|
|
pass buffer handles between clients and the compositing manager.
|
|
|
</para>
|
|
|
<mediaobject>
|
|
|
<imageobject>
|
|
|
<imagedata fileref="images/wayland-architecture.png" format="PNG" />
|
|
|
</imageobject>
|
|
|
<textobject>
|
|
|
<phrase>
|
|
|
Wayland architecture diagram
|
|
|
</phrase>
|
|
|
</textobject>
|
|
|
</mediaobject>
|
|
|
<para>
|
|
|
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).
|
|
|
</para>
|
|
|
</section>
|
|
|
</chapter>
|
