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, whats 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 its 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
