1<?xml version='1.0' encoding='utf-8' ?>
2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
3<!ENTITY % BOOK_ENTITIES SYSTEM "Wayland.ent">
4%BOOK_ENTITIES;
5]>
6<chapter id="chap-Introduction">
7  <title>Introduction</title>
8  <section id="sect-Motivation">
9    <title>Motivation</title>
10    <para>
11      Most Linux and Unix-based systems rely on the X Window System (or
12      simply <emphasis>X</emphasis>) as the low-level protocol for building
13      bitmap graphics interfaces. On these systems, the X stack has grown to
14      encompass functionality arguably belonging in client libraries,
15      helper libraries, or the host operating system kernel.  Support for
16      things like PCI resource management, display configuration management,
17      direct rendering, and memory management has been integrated into the X
18      stack, imposing limitations like limited support for standalone
19      applications, duplication in other projects (e.g. the Linux fb layer
20      or the DirectFB project), and high levels of complexity for systems
21      combining multiple elements (for example radeon memory map handling
22      between the fb driver and X driver, or VT switching).
23    </para>
24    <para>
25      Moreover, X has grown to incorporate modern features like offscreen
26      rendering and scene composition, but subject to the limitations of the
27      X architecture.  For example, the X implementation of composition adds
28      additional context switches and makes things like input redirection
29      difficult.
30    </para>
31    <mediaobject>
32      <imageobject>
33	<imagedata fileref="images/x-architecture.png" format="PNG" />
34      </imageobject>
35      <textobject>
36        <phrase>
37          X architecture diagram
38        </phrase>
39      </textobject>
40    </mediaobject>
41    <para>
42      The diagram above illustrates the central role of the X server and
43      compositor in operations, and the steps required to get contents on to
44      the screen.
45    </para>
46    <para>
47      Over time, X developers came to understand the shortcomings of this
48      approach and worked to split things up.  Over the past several years,
49      a lot of functionality has moved out of the X server and into
50      client-side libraries or kernel drivers. One of the first components
51      to move out was font rendering, with freetype and fontconfig providing
52      an alternative to the core X fonts.  Direct rendering OpenGL as a
53      graphics driver in a client side library went through some iterations,
54      ending up as DRI2, which abstracted most of the direct rendering
55      buffer management from client code. Then cairo came along and provided
56      a modern 2D rendering library independent of X, and compositing
57      managers took over control of the rendering of the desktop as toolkits
58      like GTK+ and Qt moved away from using X APIs for rendering. Recently,
59      memory and display management have moved to the Linux kernel, further
60      reducing the scope of X and its driver stack.  The end result is a
61      highly modular graphics stack.
62    </para>
63
64  </section>
65
66  <section id="sect-Compositing-manager-display-server">
67    <title>The compositing manager as the display server</title>
68    <para>
69      Wayland is a new display server and compositing protocol, and Weston
70      is the implementation of this protocol which builds on top of all the
71      components above. We are trying to distill out the functionality in
72      the X server that is still used by the modern Linux desktop. This
73      turns out to be not a whole lot. Applications can allocate their own
74      off-screen buffers and render their window contents directly, using
75      hardware accelerated libraries like libGL, or high quality software
76      implementations like those found in Cairo. In the end, what’s needed
77      is a way to present the resulting window surface for display, and a
78      way to receive and arbitrate input among multiple clients. This is
79      what Wayland provides, by piecing together the components already in
80      the eco-system in a slightly different way.
81    </para>
82    <para>
83      X will always be relevant, in the same way Fortran compilers and VRML
84      browsers are, but it’s time that we think about moving it out of the
85      critical path and provide it as an optional component for legacy
86      applications.
87    </para>
88    <para>
89      Overall, the philosophy of Wayland is to provide clients with a way to
90      manage windows and how their contents is displayed.  Rendering is left
91      to clients, and system wide memory management interfaces are used to
92      pass buffer handles between clients and the compositing manager.
93    </para>
94    <mediaobject>
95      <imageobject>
96	<imagedata fileref="images/wayland-architecture.png" format="PNG" />
97      </imageobject>
98      <textobject>
99        <phrase>
100          Wayland architecture diagram
101        </phrase>
102      </textobject>
103    </mediaobject>
104    <para>
105      The figure above illustrates how Wayland clients interact with a
106      Wayland server.  Note that window management and composition are
107      handled entirely in the server, significantly reducing complexity
108      while marginally improving performance through reduced context
109      switching.  The resulting system is easier to build and extend than a
110      similar X system, because often changes need only be made in one
111      place.  Or in the case of protocol extensions, two (rather than 3 or 4
112      in the X case where window management and/or composition handling may
113      also need to be updated).
114    </para>
115  </section>
116</chapter>
117