117 lines
5.5 KiB
XML
117 lines
5.5 KiB
XML
<?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>
|