[PATCH 05/18] doc: Rename Overview.xml to Introduction.xml

Peter Hutterer peter.hutterer at who-t.net
Mon Apr 1 17:08:59 PDT 2013


From: Tiago Vignatti <tiago.vignatti at intel.com>

Rename Overview.xml to Introduction.xml, reflecting the previous commit.
Organize also Wayland.xml order of the includes.

Signed-off-by: Tiago Vignatti <tiago.vignatti at intel.com>
Reviewed-by: Peter Hutterer <peter.hutterer at who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
---
 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 03723e1..6bafce0 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.8.1.4



More information about the wayland-devel mailing list