Rename Overview.xml to Introduction.xml, reflecting the previous commit. Organize also Wayland.xml order of the includes.
Signed-off-by: Tiago Vignatti <[email protected]> --- doc/Wayland/Makefile.am | 8 +-- doc/Wayland/en_US/Introduction.xml | 116 ++++++++++++++++++++++++++++++++++++ doc/Wayland/en_US/Overview.xml | 116 ------------------------------------ doc/Wayland/en_US/Wayland.xml | 2 +- 4 files changed, 121 insertions(+), 121 deletions(-) create mode 100644 doc/Wayland/en_US/Introduction.xml delete mode 100644 doc/Wayland/en_US/Overview.xml diff --git a/doc/Wayland/Makefile.am b/doc/Wayland/Makefile.am index 65b5b65..f919a89 100644 --- a/doc/Wayland/Makefile.am +++ b/doc/Wayland/Makefile.am @@ -1,15 +1,15 @@ publican_sources = \ $(srcdir)/en_US/Wayland.ent \ - $(srcdir)/en_US/Architecture.xml \ - $(srcdir)/en_US/Author_Group.xml \ + $(srcdir)/en_US/Wayland.xml \ $(srcdir)/en_US/Book_Info.xml \ + $(srcdir)/en_US/Author_Group.xml \ $(srcdir)/en_US/Foreword.xml \ $(srcdir)/en_US/Preface.xml \ - $(srcdir)/en_US/Wayland.xml \ + $(srcdir)/en_US/Introduction.xml \ + $(srcdir)/en_US/Architecture.xml \ $(srcdir)/en_US/Protocol.xml \ $(srcdir)/en_US/Library.xml \ $(srcdir)/en_US/Compositors.xml \ - $(srcdir)/en_US/Overview.xml \ $(srcdir)/en_US/images/icon.svg \ $(srcdir)/en_US/images/wayland-architecture.png \ $(srcdir)/en_US/images/wayland.png \ diff --git a/doc/Wayland/en_US/Introduction.xml b/doc/Wayland/en_US/Introduction.xml new file mode 100644 index 0000000..51e451e --- /dev/null +++ b/doc/Wayland/en_US/Introduction.xml @@ -0,0 +1,116 @@ +<?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 of 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>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> diff --git a/doc/Wayland/en_US/Overview.xml b/doc/Wayland/en_US/Overview.xml deleted file mode 100644 index 51e451e..0000000 --- a/doc/Wayland/en_US/Overview.xml +++ /dev/null @@ -1,116 +0,0 @@ -<?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 of 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>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> diff --git a/doc/Wayland/en_US/Wayland.xml b/doc/Wayland/en_US/Wayland.xml index e72bb11..e240512 100644 --- a/doc/Wayland/en_US/Wayland.xml +++ b/doc/Wayland/en_US/Wayland.xml @@ -7,7 +7,7 @@ <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> <xi:include href="Foreword.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> <xi:include href="Preface.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> - <xi:include href="Overview.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> + <xi:include href="Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> <xi:include href="Architecture.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> <xi:include href="Protocol.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> <xi:include href="Library.xml" xmlns:xi="http://www.w3.org/2001/XInclude"; /> -- 1.7.9.5 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
