doc: Refactor the build system for complete build dir docs

By structuring things differently, it becomes possible to have a
complete build of the docs in the build dir, without having to install
anything.

Signed-off-by: Sebastian Wick <sebastian.wick@redhat.com>

24 files changed, 0 insertions, 3844 deletions

diff --git a/doc/publican/sources/Architecture.xml b/doc/publican/sources/Architecture.xml
deleted file mode 100644
index b8a104c..0000000
--- a/doc/publican/sources/Architecture.xml
+++ /dev/null
@@ -1,344 +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-Wayland-Architecture">
-  <title>Wayland Architecture</title>
-  <section id="sect-Wayland-Architecture-wayland_architecture">
-    <title>X vs. Wayland Architecture</title>
-    <para>
-      A good way to understand the Wayland architecture
-      and how it is different from X is to follow an event
-      from the input device to the point where the change
-      it affects appears on screen.
-    </para>
-    <para>
-      This is where we are now with X:
-    </para>
-    <figure>
-      <title>X architecture diagram</title>
-      <mediaobjectco>
-	<imageobjectco>
-	  <areaspec id="map1" units="other" otherunits="imagemap">
-	    <area id="area1_1" linkends="x_flow_1" x_steal="#step_1"/>
-	    <area id="area1_2" linkends="x_flow_2" x_steal="#step_2"/>
-	    <area id="area1_3" linkends="x_flow_3" x_steal="#step_3"/>
-	    <area id="area1_4" linkends="x_flow_4" x_steal="#step_4"/>
-	    <area id="area1_5" linkends="x_flow_5" x_steal="#step_5"/>
-	    <area id="area1_6" linkends="x_flow_6" x_steal="#step_6"/>
-	  </areaspec>
-	  <imageobject>
-	    <imagedata fileref="images/x-architecture.png" format="PNG" />
-	  </imageobject>
-	</imageobjectco>
-      </mediaobjectco>
-    </figure>
-    <para>
-      <orderedlist>
-	<listitem id="x_flow_1">
-	  <para>
-	    The kernel gets an event from an input
-	    device and sends it to X through the evdev
-	    input driver. The kernel does all the hard
-	    work here by driving the device and
-	    translating the different device specific
-	    event protocols to the linux evdev input
-	    event standard.
-	  </para>
-	</listitem>
-	<listitem id="x_flow_2">
-	  <para>
-	    The X server determines which window the
-	    event affects and sends it to the clients
-	    that have selected for the event in question
-	    on that window. The X server doesn't
-	    actually know how to do this right, since
-	    the window location on screen is controlled
-	    by the compositor and may be transformed in
-	    a number of ways that the X server doesn't
-	    understand (scaled down, rotated, wobbling,
-	    etc).
-	  </para>
-	</listitem>
-	<listitem id="x_flow_3">
-	  <para>
-	    The client looks at the event and decides
-	    what to do. Often the UI will have to change
-	    in response to the event - perhaps a check
-	    box was clicked or the pointer entered a
-	    button that must be highlighted. Thus the
-	    client sends a rendering request back to the
-	    X server.
-	  </para>
-	</listitem>
-	<listitem id="x_flow_4">
-	  <para>
-	    When the X server receives the rendering
-	    request, it sends it to the driver to let it
-	    program the hardware to do the rendering.
-	    The X server also calculates the bounding
-	    region of the rendering, and sends that to
-	    the compositor as a damage event.
-	  </para>
-	</listitem>
-	<listitem id="x_flow_5">
-	  <para>
-	    The damage event tells the compositor that
-	    something changed in the window and that it
-	    has to recomposite the part of the screen
-	    where that window is visible. The compositor
-	    is responsible for rendering the entire
-	    screen contents based on its scenegraph and
-	    the contents of the X windows. Yet, it has
-	    to go through the X server to render this.
-	  </para>
-	</listitem>
-	<listitem id="x_flow_6">
-	  <para>
-	    The X server receives the rendering requests
-	    from the compositor and either copies the
-	    compositor back buffer to the front buffer
-	    or does a pageflip. In the general case, the
-	    X server has to do this step so it can
-	    account for overlapping windows, which may
-	    require clipping and determine whether or
-	    not it can page flip. However, for a
-	    compositor, which is always fullscreen, this
-	    is another unnecessary context switch.
-	  </para>
-	</listitem>
-      </orderedlist>
-    </para>
-    <para>
-      As suggested above, there are a few problems with this
-      approach. The X server doesn't have the information to
-      decide which window should receive the event, nor can it
-      transform the screen coordinates to window-local
-      coordinates. And even though X has handed responsibility for
-      the final painting of the screen to the compositing manager,
-      X still controls the front buffer and modesetting. Most of
-      the complexity that the X server used to handle is now
-      available in the kernel or self contained libraries (KMS,
-      evdev, mesa, fontconfig, freetype, cairo, Qt etc). In
-      general, the X server is now just a middle man that
-      introduces an extra step between applications and the
-      compositor and an extra step between the compositor and the
-      hardware.
-    </para>
-    <para>
-      In Wayland the compositor is the display server. We transfer
-      the control of KMS and evdev to the compositor. The Wayland
-      protocol lets the compositor send the input events directly
-      to the clients and lets the client send the damage event
-      directly to the compositor:
-    </para>
-    <figure>
-      <title>Wayland architecture diagram</title>
-      <mediaobjectco>
-	<imageobjectco>
-	  <areaspec id="mapB" units="other" otherunits="imagemap">
-	    <area id="areaB_1" linkends="wayland_flow_1" x_steal="#step_1"/>
-	    <area id="areaB_2" linkends="wayland_flow_2" x_steal="#step_2"/>
-	    <area id="areaB_3" linkends="wayland_flow_3" x_steal="#step_3"/>
-	    <area id="areaB_4" linkends="wayland_flow_4" x_steal="#step_4"/>
-	  </areaspec>
-	  <imageobject>
-	    <imagedata fileref="images/wayland-architecture.png" format="PNG" />
-	  </imageobject>
-	</imageobjectco>
-      </mediaobjectco>
-    </figure>
-    <para>
-      <orderedlist>
-	<listitem id="wayland_flow_1">
-	  <para>
-	    The kernel gets an event and sends
-	    it to the compositor. This
-	    is similar to the X case, which is
-	    great, since we get to reuse all the
-	    input drivers in the kernel.
-	  </para>
-	</listitem>
-	<listitem id="wayland_flow_2">
-	  <para>
-	    The compositor looks through its
-	    scenegraph to determine which window
-	    should receive the event. The
-	    scenegraph corresponds to what's on
-	    screen and the compositor
-	    understands the transformations that
-	    it may have applied to the elements
-	    in the scenegraph. Thus, the
-	    compositor can pick the right window
-	    and transform the screen coordinates
-	    to window-local coordinates, by
-	    applying the inverse
-	    transformations. The types of
-	    transformation that can be applied
-	    to a window is only restricted to
-	    what the compositor can do, as long
-	    as it can compute the inverse
-	    transformation for the input events.
-	  </para>
-	</listitem>
-	<listitem id="wayland_flow_3">
-	  <para>
-	    As in the X case, when the client
-	    receives the event, it updates the
-	    UI in response. But in the Wayland
-	    case, the rendering happens in the
-	    client, and the client just sends a
-	    request to the compositor to
-	    indicate the region that was
-	    updated.
-	  </para>
-	</listitem>
-	<listitem id="wayland_flow_4">
-	  <para>
-	    The compositor collects damage
-	    requests from its clients and then
-	    recomposites the screen. The
-	    compositor can then directly issue
-	    an ioctl to schedule a pageflip with
-	    KMS.
-	  </para>
-	</listitem>
-
-
-      </orderedlist>
-    </para>
-  </section>
-  <section id="sect-Wayland-Architecture-wayland_rendering">
-    <title>Wayland Rendering</title>
-    <para>
-      One of the details I left out in the above overview
-      is how clients actually render under Wayland. By
-      removing the X server from the picture we also
-      removed the mechanism by which X clients typically
-      render. But there's another mechanism that we're
-      already using with DRI2 under X: direct rendering.
-      With direct rendering, the client and the server
-      share a video memory buffer. The client links to a
-      rendering library such as OpenGL that knows how to
-      program the hardware and renders directly into the
-      buffer. The compositor in turn can take the buffer
-      and use it as a texture when it composites the
-      desktop. After the initial setup, the client only
-      needs to tell the compositor which buffer to use and
-      when and where it has rendered new content into it.
-    </para>
-
-    <para>
-      This leaves an application with two ways to update its window contents:
-    </para>
-    <para>
-      <orderedlist>
-	<listitem>
-	  <para>
-	    Render the new content into a new buffer and tell the compositor
-	    to use that instead of the old buffer. The application can
-	    allocate a new buffer every time it needs to update the window
-	    contents or it can keep two (or more) buffers around and cycle
-	    between them. The buffer management is entirely under
-	    application control.
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    Render the new content into the buffer that it previously
-	    told the compositor to to use. While it's possible to just
-	    render directly into the buffer shared with the compositor,
-	    this might race with the compositor. What can happen is that
-	    repainting the window contents could be interrupted by the
-	    compositor repainting the desktop. If the application gets
-	    interrupted just after clearing the window but before
-	    rendering the contents, the compositor will texture from a
-	    blank buffer. The result is that the application window will
-	    flicker between a blank window or half-rendered content. The
-	    traditional way to avoid this is to render the new content
-	    into a back buffer and then copy from there into the
-	    compositor surface. The back buffer can be allocated on the
-	    fly and just big enough to hold the new content, or the
-	    application can keep a buffer around. Again, this is under
-	    application control.
-	  </para>
-	</listitem>
-      </orderedlist>
-    </para>
-    <para>
-      In either case, the application must tell the compositor
-      which area of the surface holds new contents. When the
-      application renders directly to the shared buffer, the
-      compositor needs to be noticed that there is new content.
-      But also when exchanging buffers, the compositor doesn't
-      assume anything changed, and needs a request from the
-      application before it will repaint the desktop. The idea
-      that even if an application passes a new buffer to the
-      compositor, only a small part of the buffer may be
-      different, like a blinking cursor or a spinner.
-    </para>
-  </section>
-  <section id="sect-Wayland-Architecture-wayland_hw_enabling">
-    <title>Hardware Enabling for Wayland</title>
-    <para>
-      Typically, hardware enabling includes modesetting/display
-      and EGL/GLES2. On top of that Wayland needs a way to share
-      buffers efficiently between processes. There are two sides
-      to that, the client side and the server side.
-    </para>
-    <para>
-      On the client side we've defined a Wayland EGL platform. In
-      the EGL model, that consists of the native types
-      (EGLNativeDisplayType, EGLNativeWindowType and
-      EGLNativePixmapType) and a way to create those types. In
-      other words, it's the glue code that binds the EGL stack and
-      its buffer sharing mechanism to the generic Wayland API. The
-      EGL stack is expected to provide an implementation of the
-      Wayland EGL platform. The full API is in the wayland-egl.h
-      header. The open source implementation in the mesa EGL stack
-      is in wayland-egl.c and platform_wayland.c.
-    </para>
-    <para>
-      Under the hood, the EGL stack is expected to define a
-      vendor-specific protocol extension that lets the client side
-      EGL stack communicate buffer details with the compositor in
-      order to share buffers. The point of the wayland-egl.h API
-      is to abstract that away and just let the client create an
-      EGLSurface for a Wayland surface and start rendering. The
-      open source stack uses the drm Wayland extension, which lets
-      the client discover the drm device to use and authenticate
-      and then share drm (GEM) buffers with the compositor.
-    </para>
-    <para>
-      The server side of Wayland is the compositor and core UX for
-      the vertical, typically integrating task switcher, app
-      launcher, lock screen in one monolithic application. The
-      server runs on top of a modesetting API (kernel modesetting,
-      OpenWF Display or similar) and composites the final UI using
-      a mix of EGL/GLES2 compositor and hardware overlays if
-      available. Enabling modesetting, EGL/GLES2 and overlays is
-      something that should be part of standard hardware bringup.
-      The extra requirement for Wayland enabling is the
-      EGL_WL_bind_wayland_display extension that lets the
-      compositor create an EGLImage from a generic Wayland shared
-      buffer. It's similar to the EGL_KHR_image_pixmap extension
-      to create an EGLImage from an X pixmap.
-    </para>
-    <para>
-      The extension has a setup step where you have to bind the
-      EGL display to a Wayland display. Then as the compositor
-      receives generic Wayland buffers from the clients (typically
-      when the client calls eglSwapBuffers), it will be able to
-      pass the struct wl_buffer pointer to eglCreateImageKHR as
-      the EGLClientBuffer argument and with EGL_WAYLAND_BUFFER_WL
-      as the target. This will create an EGLImage, which can then
-      be used by the compositor as a texture or passed to the
-      modesetting code to use as an overlay plane. Again, this is
-      implemented by the vendor specific protocol extension, which
-      on the server side will receive the driver specific details
-      about the shared buffer and turn that into an EGL image when
-      the user calls eglCreateImageKHR.
-    </para>
-  </section>
-</chapter>
diff --git a/doc/publican/sources/Author_Group.xml b/doc/publican/sources/Author_Group.xml
deleted file mode 100644
index 2bdde62..0000000
--- a/doc/publican/sources/Author_Group.xml
+++ /dev/null
@@ -1,16 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE authorgroup 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;
-]>
-<authorgroup>
-  <author>
-    <firstname>Kristian</firstname>
-    <surname>Høgsberg</surname>
-    <affiliation>
-      <orgname>Intel Corporation</orgname>
-    </affiliation>
-    <email>krh@bitplanet.net</email>
-  </author>
-</authorgroup>
-
diff --git a/doc/publican/sources/Book_Info.xml b/doc/publican/sources/Book_Info.xml
deleted file mode 100644
index 897673a..0000000
--- a/doc/publican/sources/Book_Info.xml
+++ /dev/null
@@ -1,71 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE bookinfo 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;
-]>
-<bookinfo id="book-Wayland-Wayland">
-  <title>Wayland</title>
-  <subtitle>The Wayland Protocol</subtitle>
-  <productname>Documentation</productname>
-  <productnumber>0.1</productnumber>
-  <edition>1</edition>
-  <pubsnumber>0</pubsnumber>
-  <abstract>
-    <para>
-      Wayland is a protocol for a compositor to talk to
-      its clients as well as a C library implementation of
-      that protocol. The compositor can be a standalone
-      display server running on Linux kernel modesetting
-      and evdev input devices, an X application, or a
-      Wayland client itself. The clients can be
-      traditional applications, X servers (rootless or
-      fullscreen) or other display servers.
-    </para>
-  </abstract>
-  <corpauthor>
-    <inlinemediaobject>
-      <imageobject>
-	<imagedata fileref="images/wayland.png" format="PNG" />
-      </imageobject>
-      <textobject>
-	<phrase>
-	  Wayland logo
-	</phrase>
-      </textobject>
-    </inlinemediaobject>
-  </corpauthor>
-
-  <legalnotice lang="en-US">
-    <para>
-      Copyright <trademark class="copyright"></trademark> &YEAR; &HOLDER;
-    </para>
-
-	<para>
-	  Permission is hereby granted, free of charge, to any person obtaining a
-	  copy of this software and associated documentation files (the "Software"),
-	  to deal in the Software without restriction, including without limitation
-	  the rights to use, copy, modify, merge, publish, distribute, sublicense,
-	  and/or sell copies of the Software, and to permit persons to whom the
-	  Software is furnished to do so, subject to the following conditions:
-	</para>
-
-	<para>
-	  The above copyright notice and this permission notice (including the next
-	  paragraph) shall be included in all copies or substantial portions of the
-	  Software.
-	</para>
-
-	<para>
-	  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-	  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-	  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
-	  THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-	  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
-	  FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
-	  DEALINGS IN THE SOFTWARE.
-	</para>
-  </legalnotice>
-
-
-  <xi:include href="Author_Group.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-</bookinfo>
diff --git a/doc/publican/sources/Client.xml b/doc/publican/sources/Client.xml
deleted file mode 100644
index 19bf3e9..0000000
--- a/doc/publican/sources/Client.xml
+++ /dev/null
@@ -1,92 +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">
-  <!ENTITY doxygen SYSTEM "ClientAPI.xml">
-%BOOK_ENTITIES;
-]>
-<appendix id="sect-Library-Client">
-  <title>Client API</title>
-  <section><title>Introduction</title>
-  <para>
-    The open-source reference implementation of Wayland protocol is
-    split in two C libraries, libwayland-client and <link
-    linkend="sect-Library-Server">libwayland-server</link>. Their main
-    responsibility is to handle the Inter-process communication
-    (<emphasis>IPC</emphasis>) with each other, therefore guaranteeing
-    the protocol objects marshaling and messages synchronization.
-  </para>
-  <para>
-    A client uses libwayland-client to communicate with one or more
-    wayland servers. A <link
-    linkend="Client-classwl__display">wl_display</link> object is
-    created and manages each open connection to a server. At least one
-    <link linkend="Client-classwl__event__queue">wl_event_queue</link>
-    object is created for each wl_display, this holds events as they
-    are received from the server until they can be
-    processed. Multi-threading is supported by creating an additional
-    wl_event_queue for each additional thread, each object can have
-    it's events placed in a particular queue, so potentially a
-    different thread could be made to handle the events for each
-    object created.
-  </para>
-  <para>
-    Though some convenience functions are provided, libwayland-client
-    is designed to allow the calling code to wait for events, so that
-    different polling mechanisms can be used. A file descriptor is
-    provided, when it becomes ready for reading the calling code can
-    ask libwayland-client to read the available events from it into
-    the wl_event_queue objects.
-  </para>
-  <para>
-    The library only provides low-level access to the wayland objects.
-    Each object created by the client is represented by a <link
-    linkend="Client-classwl__proxy">wl_proxy</link> object that this
-    library creates. This includes the id that is actually
-    communicated over the socket to the server, a void* data pointer
-    that is intended to point at a client's representation of the
-    object, and a pointer to a static <link
-    linkend="Client-structwl__interface">wl_interface</link> object,
-    which is generated from the xml and identifies the object's class
-    and can be used for introspection into the messages and events.
-  </para>
-  <para>
-    Messages are sent by calling wl_proxy_marshal. This will write a
-    message to the socket, by using the message id and the
-    wl_interface to identify the types of each argument and convert
-    them into stream format.  Most software will call type-safe
-    wrappers generated from the xml description of the <link
-    linkend="appe-Wayland-Protocol">Wayland protocols</link>. For
-    instance the C header file generated from the xml defines the
-    following inline function to transmit the <link
-    linkend="protocol-spec-wl_surface-request-attach">wl_surface::attach</link>
-    message:
-  </para>
-  <programlisting>static inline void
-wl_surface_attach(struct wl_surface *wl_surface, struct wl_buffer *buffer, int32_t x, int32_t y)
-{
-  wl_proxy_marshal((struct wl_proxy *) wl_surface, WL_SURFACE_ATTACH, buffer, x, y);
-}</programlisting>
-  <para>
-    Events (messages from the server) are handled by calling a
-    "dispatcher" callback the client stores in the wl_proxy for each
-    event. A language binding for a string-based interpreter, such as
-    CPython, might have a dispatcher that uses the event name from the
-    wl_interface to identify the function to call. The default
-    dispatcher uses the message id number to index an array of
-    functions pointers, called a wl_listener, and the wl_interface to
-    convert data from the stream into arguments to the function. The
-    C header file generated from the xml defines a per-class structure
-    that forces the function pointers to be of the correct type, for
-    instance the <link
-    linkend="protocol-spec-wl_surface-event-enter">wl_surface::enter</link>
-    event defines this pointer in the wl_surface_listener object:
-  </para>
-  <programlisting>struct wl_surface_listener {
-  void (*enter)(void *data, struct wl_surface *, struct wl_output *);
-  ...
-}</programlisting>
-  <para>
-  </para>
-  </section>
-  &doxygen;
-</appendix>
diff --git a/doc/publican/sources/Color.xml b/doc/publican/sources/Color.xml
deleted file mode 100644
index ceee779..0000000
--- a/doc/publican/sources/Color.xml
+++ /dev/null
@@ -1,139 +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-Color-Management">
-  <title>Color management</title>
-
-  <section id="sect-Color-Management-preface">
-    <title>Overview</title>
-
-    <para>
-      Color management in Wayland considers only displays. All pictures in
-      Wayland are always display-referred, meaning that the pixel values are
-      intended as-is for some specific display where they would produce the
-      light emissions (<ulink
-      url="https://cie.co.at/eilvterm/17-23-002">stimuli</ulink>) the picture's
-      author desired. Wayland does not support displaying "raw" camera or
-      scanner images as they are not display-referred, nor are they even
-      pictures without complex and subjective processing.
-    </para>
-    <para>
-      Stimuli — the picture itself — are only half of the picture reproduction.
-      The other half is the environment where a display is viewed. A striking
-      example is comparing a brightly lit office to a dark movie theater, the
-      stimuli required to produce a good reading of the picture is greatly
-      different. Therefore display-referred does not include only the display
-      but the viewing environment as well.
-    </para>
-    <para>
-      Window systems have been very well capable of operating without any
-      explicit consideration to color management. This is because there used to
-      be the implicit assumption of the standard display, the sRGB display,
-      which all computer monitors implemented, more or less. The viewing
-      environment was and still is accounted by adjusting the display and/or the
-      room to produce a workable experience. Pictures are authored on a computer
-      system by drawing, painting and adjusting the picture until it looks right
-      on the author's monitor. This implicitly builds the standard display and
-      environment assumption into the picture data. Deviations from the sRGB
-      specification were minor enough that they often did not matter if not in a
-      professional context like the printing industry. Displaying video material
-      required some more attention to the details, because video and television
-      standards differ enough from the sRGB display. What really made explicit
-      color management a hard requirement for entertainment is the coming of
-      wide color gamut (WCG) and high dynamic range (HDR) materials and
-      displays.
-    </para>
-    <para>
-      The color management design in Wayland follows the general Wayland design
-      principles: compositors tell clients what would be the optimal thing to
-      do, clients tell the compositors what kind of pictures they are actually
-      producing, and then compositors display those pictures the best they can.
-    </para>
-  </section>
-
-  <section id="sect-Color-Management-Protocol">
-    <title>Protocol Interfaces</title>
-
-    <para>
-      Color management interfaces in Wayland and divided into two protocols:
-      <ulink url="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/color-management?ref_type=heads">color-management</ulink>
-      and
-      <ulink url="https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/color-representation?ref_type=heads">color-representation</ulink>.
-      They are designed to work together, but they can also be used
-      independently when the other one is not needed.
-    </para>
-
-    <section id="sect-Color-Management-Protocol-color-management">
-      <title>Color-management</title>
-
-      <para>
-	Color management protocol has two main purposes. First, it puts the
-	responsibility of color management on the compositor. This means that
-	clients do not necessarily need to care about color management at all,
-	and can display just fine by using the traditional standard display
-	assumption even when the actual display is wildly different. Clients
-	can also choose to target some other assumed display and let the
-	compositor handle it, or they can explicitly render for the actual
-	display at hand. Second, when the window system has multiple different
-	monitors, and a wl_surface happens to span more than one monitor, the
-	compositor can display the surface content correctly on all spanned
-	monitors simultaneously, as much as physically possible.
-      </para>
-      <para>
-	Color-management protocol concentrates on colorimetry: when you have a
-	pixel with RGB values, what stimulus do those values represent. The
-	stimulus definition follows the CIE 1931 two-degree observer model. Some
-	core concepts here are color primaries, white point, transfer function,
-	and dynamic range. The viewing environment is represented in an
-	extremely simplified way as the reference white luminance. The
-	connection between pixel RGB values and stimulus plus viewing
-	environment is recorded in an <emphasis>image description</emphasis>
-	object. Clients can create image description objects and tag
-	<code>wl_surface</code>s with them, to indicate what kind of surface
-	content there will be. Clients can also ask what image description the
-	compositor would prefer to have on the <code>wl_surface</code>, and that
-	preference can change over time, e.g. when the <code>wl_surface</code>
-	is moved from one
-	<code>wl_output</code> to another. Following the compositor's preference
-	may provide advantages in image quality and power consumption.
-      </para>
-      <para>
-	Image description objects can come in two flavors: parametric and
-	ICC-based. The above was written with parametric image descriptions in
-	mind, and they have first-class support for HDR. ICC-based image
-	descriptions are wrapping an ICC profile and have no other data. ICC
-	profiles are the standard tool for standard dynamic range (SDR) display
-	color management. This means the capabilities between the two flavors
-	differ, and one cannot always be replaced by the other. Compositor
-	support for each flavor is optional.
-      </para>
-    </section>
-
-    <section id="sect-Color-Management-Protocol-color-representation">
-      <title>Color-representation</title>
-
-      <para>
-	Color-representation protocol deals with (potentially sub-sampled)
-	YCbCr-RGB conversion, quantization range, and the inclusion of alpha in
-	the RGB color channels, a.k.a. pre-multiplication. There are several
-	different specifications on how an YCbCr-like (including ICtCp) signal,
-	with chroma sub-sampling or not, is created from a full-resolution RGB
-	image. Again, a client can tag a <code>wl_surface</code> with
-	color-representation metadata to tell the compositor what kind of pixel
-	data will be displayed through the wl_surface.
-      </para>
-      <para>
-	The main purpose of color-representation is to correctly off-load the
-	YCbCr-RGB conversion to the compositor, which can then opportunistically
-	off-load it further to very power-efficient fixed-function circuitry in
-	a display controller. This can significantly reduce power consumption
-	when watching videos compared to using a GPU for the same, and on some
-	embedded hardware platforms it is a hard requirement for processing high
-	resolution video.
-      </para>
-    </section>
-  </section>
-</chapter>
diff --git a/doc/publican/sources/Compositors.xml b/doc/publican/sources/Compositors.xml
deleted file mode 100644
index 7a7bdaa..0000000
--- a/doc/publican/sources/Compositors.xml
+++ /dev/null
@@ -1,128 +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-Compositors">
-  <title>Types of Compositors</title>
-
-  <para>
-    Compositors come in different types, depending on which
-    role they play in the overall architecture of the OS.
-    For instance, a
-    <link linkend="sect-Compositors-System-Compositor">system compositor</link>
-    can be used for booting the system, handling multiple user switching, a
-    possible console terminal emulator and so forth. A different compositor, a
-    <link linkend="sect-Compositors-Session-Compositor">session compositor</link>
-    would provide the actual desktop environment. There are many ways for
-    different types of compositors to co-exist.
-  </para>
-  <para>
-    In this section, we introduce three types of Wayland compositors relying
-    on <link linkend="sect-Library-Server">libwayland-server</link>.
-  </para>
-
-  <section id="sect-Compositors-System-Compositor">
-    <title>System Compositor</title>
-    <para>
-      A system compositor can run from early boot until shutdown.
-      It effectively replaces the kernel vt system, and can tie in
-      with the systems graphical boot setup and multiseat support.
-    </para>
-    <para>
-      A system compositor can host different types of session
-      compositors, and let us switch between multiple sessions
-      (fast user switching, or secure/personal desktop switching).
-    </para>
-    <para>
-      A linux implementation of a system compositor will typically
-      use libudev, egl, kms, evdev and cairo.
-    </para>
-    <para>
-      For fullscreen clients, the system compositor can reprogram the
-      video scanout address to read directly from the client provided
-      buffer.
-    </para>
-  </section>
-  <section id="sect-Compositors-Session-Compositor">
-    <title>Session Compositor</title>
-    <para>
-      A session compositor is responsible for a single user session.
-      If a system compositor is present, the session compositor will
-      run nested under the system compositor. Nesting is feasible because
-      the protocol is asynchronous; roundtrips would be too expensive
-      when nesting is involved. If no system compositor is present, a
-      session compositor can run directly on the hardware.
-     </para>
-     <para>
-      X applications can continue working under a session compositor
-      by means of a root-less X server that is activated on demand.
-     </para>
-    <para>
-       Possible examples for session compositors include
-      <itemizedlist>
-	<listitem>
-	  <para>
-	    gnome-shell
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    moblin
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    kwin
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    kmscon
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    rdp session
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    Weston with X11 or Wayland backend is a session compositor nested
-	    in another session compositor.
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    fullscreen X session under Wayland
-	  </para>
-	</listitem>
-      </itemizedlist>
-    </para>
-  </section>
-  <section id="sect-Compositors-Embedding-Compositor">
-    <title>Embedding Compositor</title>
-    <para>
-      X11 lets clients embed windows from other clients, or lets clients
-      copy pixmap contents rendered by another client into their window.
-      This is often used for applets in a panel, browser plugins and similar.
-      Wayland doesn't directly allow this, but clients can communicate GEM
-      buffer names out-of-band, for example, using D-Bus, or command line
-      arguments when the panel launches the applet.  Another option is to
-      use a nested Wayland instance.  For this, the Wayland server will have
-      to be a library that the host application links to.  The host
-      application will then pass the Wayland server socket name to the
-      embedded application, and will need to implement the Wayland
-      compositor interface.  The host application composites the client
-      surfaces as part of it's window, that is, in the web page or in the
-      panel.  The benefit of nesting the Wayland server is that it provides
-      the requests the embedded client needs to inform the host about buffer
-      updates and a mechanism for forwarding input events from the host
-      application.
-    </para>
-    <para>
-      An example for this kind of setup is firefox embedding the flash
-      player as a kind of special-purpose compositor.
-    </para>
-  </section>
-</chapter>
diff --git a/doc/publican/sources/Foreword.xml b/doc/publican/sources/Foreword.xml
deleted file mode 100644
index 46fda2b..0000000
--- a/doc/publican/sources/Foreword.xml
+++ /dev/null
@@ -1,28 +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;
-]>
-
-<preface>
-  <title>Preface</title>
-
-  <para>
-  This document describes the (i) Wayland architecture, (ii) Wayland model of
-  operation and (iii) its library API. Also, the Wayland protocol specification is shown
-  in the Appendix. This document is aimed primarily at Wayland developers and
-  those looking to program with it; it does not cover application development.
-  </para>
-  <para>
-  There have been many contributors to this document and since this is only the
-  first edition many errors are expected to be found. We appreciate
-  corrections.
-  </para>
-  <literallayout>
-Yours,
-
-	the Wayland open-source community
-	November 2012
-  </literallayout>
-</preface>
diff --git a/doc/publican/sources/Introduction.xml b/doc/publican/sources/Introduction.xml
deleted file mode 100644
index f2a8274..0000000
--- a/doc/publican/sources/Introduction.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 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 are 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/publican/sources/Preface.xml b/doc/publican/sources/Preface.xml
deleted file mode 100644
index 17c6ebf..0000000
--- a/doc/publican/sources/Preface.xml
+++ /dev/null
@@ -1,20 +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;
-]>
-
-<preface>
-  <title>Acknowledgments</title>
-
-  <para>
-  TODO: Kristian has to fill up this with one or two paragraphs and a small
-  "thank you": http://en.wikipedia.org/wiki/Preface
-  </para>
-  <literallayout>
-Best,
-
-	Kristian Høgsberg
-  </literallayout>
-</preface>
diff --git a/doc/publican/sources/Protocol.xml b/doc/publican/sources/Protocol.xml
deleted file mode 100644
index e4087e9..0000000
--- a/doc/publican/sources/Protocol.xml
+++ /dev/null
@@ -1,592 +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-Protocol">
-  <title>Wayland Protocol and Model of Operation</title>
-  <section id="sect-Protocol-Basic-Principles">
-    <title>Basic Principles</title>
-    <para>
-      The Wayland protocol is an asynchronous object oriented protocol.  All
-      requests are method invocations on some object.  The requests include
-      an object ID that uniquely identifies an object on the server.  Each
-      object implements an interface and the requests include an opcode that
-      identifies which method in the interface to invoke.
-    </para>
-    <para>
-      The protocol is message-based.  A message sent by a client to the server
-      is called request.  A message from the server to a client is called event.
-      A message has a number of arguments, each of which has a certain type (see
-      <xref linkend="sect-Protocol-Wire-Format"/> for a list of argument types).
-    </para>
-    <para>
-      Additionally, the protocol can specify <type>enum</type>s which associate
-      names to specific numeric enumeration values.  These are primarily just
-      descriptive in nature: at the wire format level enums are just integers.
-      But they also serve a secondary purpose to enhance type safety or
-      otherwise add context for use in language bindings or other such code.
-      This latter usage is only supported so long as code written before these
-      attributes were introduced still works after; in other words, adding an
-      enum should not break API, otherwise it puts backwards compatibility at
-      risk.
-    </para>
-    <para>
-      <type>enum</type>s can be defined as just a set of integers, or as
-      bitfields.  This is specified via the <type>bitfield</type> boolean
-      attribute in the <type>enum</type> definition.  If this attribute is true,
-      the enum is intended to be accessed primarily using bitwise operations,
-      for example when arbitrarily many choices of the enum can be ORed
-      together; if it is false, or the attribute is omitted, then the enum
-      arguments are a just a sequence of numerical values.
-    </para>
-    <para>
-      The <type>enum</type> attribute can be used on either <type>uint</type>
-      or <type>int</type> arguments, however if the <type>enum</type> is
-      defined as a <type>bitfield</type>, it can only be used on
-      <type>uint</type> args.
-    </para>
-    <para>
-      The server sends back events to the client, each event is emitted from
-      an object.  Events can be error conditions.  The event includes the
-      object ID and the event opcode, from which the client can determine
-      the type of event.  Events are generated both in response to requests
-      (in which case the request and the event constitutes a round trip) or
-      spontaneously when the server state changes.
-    </para>
-    <para>
-      <itemizedlist>
-	<listitem>
-	  <para>
-	    State is broadcast on connect, events are sent
-	    out when state changes. Clients must listen for
-	    these changes and cache the state.
-	    There is no need (or mechanism) to query server state.
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    The server will broadcast the presence of a number of global objects,
-	    which in turn will broadcast their current state.
-	  </para>
-	</listitem>
-      </itemizedlist>
-    </para>
-  </section>
-  <section id="sect-Protocol-Code-Generation">
-    <title>Code Generation</title>
-    <para>
-      The interfaces, requests and events are defined in
-      <filename>protocol/wayland.xml</filename>.
-      This xml is used to generate the function prototypes that can be used by
-      clients and compositors.
-    </para>
-    <para>
-      The protocol entry points are generated as inline functions which just
-      wrap the <function>wl_proxy_*</function> functions.  The inline functions aren't
-      part of the library ABI and language bindings should generate their
-      own stubs for the protocol entry points from the xml.
-    </para>
-  </section>
-  <section id="sect-Protocol-Wire-Format">
-    <title>Wire Format</title>
-    <para>
-      The protocol is sent over a UNIX domain stream socket, where the endpoint
-      usually is named <systemitem class="service">wayland-0</systemitem>
-      (although it can be changed via <emphasis>WAYLAND_DISPLAY</emphasis>
-      in the environment). Beginning in Wayland 1.15, implementations can
-      optionally support server socket endpoints located at arbitrary
-      locations in the filesystem by setting <emphasis>WAYLAND_DISPLAY</emphasis>
-      to the absolute path at which the server endpoint listens. The socket may
-      also be provided through file descriptor inheritance, in which case
-      <emphasis>WAYLAND_SOCKET</emphasis> is set.
-    </para>
-    <para>
-      Every message is structured as 32-bit words; values are represented in the
-      host's byte-order.  The message header has 2 words in it:
-      <itemizedlist>
-	<listitem>
-	  <para>
-	    The first word is the sender's object ID (32-bit).
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    The second has 2 parts of 16-bit.  The upper 16-bits are the message
-	    size in bytes, starting at the header (i.e. it has a minimum value of 8).The lower is the request/event opcode.
-	  </para>
-	</listitem>
-      </itemizedlist>
-      The payload describes the request/event arguments.  Every argument is always
-      aligned to 32-bits. Where padding is required, the value of padding bytes is
-      undefined. There is no prefix that describes the type, but it is
-      inferred implicitly from the xml specification.
-    </para>
-    <para>
-
-      The representation of argument types are as follows:
-      <variablelist>
-	<varlistentry>
-	  <term>int</term>
-	  <term>uint</term>
-	  <listitem>
-	    <para>
-	      The value is the 32-bit value of the signed/unsigned
-	      int.
-	    </para>
-	  </listitem>
-	</varlistentry>
-	<varlistentry>
-	  <term>fixed</term>
-	  <listitem>
-	    <para>
-	      Signed 24.8 decimal numbers. It is a signed decimal type which
-	      offers a sign bit, 23 bits of integer precision and 8 bits of
-	      decimal precision. This is exposed as an opaque struct with
-	      conversion helpers to and from double and int on the C API side.
-	    </para>
-	  </listitem>
-	</varlistentry>
-	<varlistentry>
-	  <term>string</term>
-	  <listitem>
-	    <para>
-	      Starts with an unsigned 32-bit length (including null terminator),
-	      followed by the UTF-8 encoded string contents, including
-	      terminating null byte, then padding to a 32-bit boundary. A null
-	      value is represented with a length of 0. Interior null bytes are
-	      not permitted.
-	    </para>
-	  </listitem>
-	</varlistentry>
-	<varlistentry>
-	  <term>object</term>
-	  <listitem>
-	    <para>
-	      32-bit object ID. A null value is represented with an ID of 0.
-	    </para>
-	  </listitem>
-	</varlistentry>
-	<varlistentry>
-	  <term>new_id</term>
-	  <listitem>
-	    <para>
-	      The 32-bit object ID.  Generally, the interface used for the new
-	      object is inferred from the xml, but in the case where it's not
-	      specified, a new_id is preceded by a <code>string</code> specifying
-	      the interface name, and a <code>uint</code> specifying the version.
-	    </para>
-	  </listitem>
-	</varlistentry>
-	<varlistentry>
-	  <term>array</term>
-	  <listitem>
-	    <para>
-	      Starts with 32-bit array size in bytes, followed by the array
-	      contents verbatim, and finally padding to a 32-bit boundary.
-	    </para>
-	  </listitem>
-	</varlistentry>
-	<varlistentry>
-	  <term>fd</term>
-	  <listitem>
-	    <para>
-	      The file descriptor is not stored in the message buffer, but in
-	      the ancillary data of the UNIX domain socket message (msg_control).
-	    </para>
-	  </listitem>
-	</varlistentry>
-      </variablelist>
-    </para>
-    <para>
-      The protocol does not specify the exact position of the ancillary data
-      in the stream, except that the order of file descriptors is the same as
-      the order of messages and <code>fd</code> arguments within messages on
-      the wire.
-    </para>
-    <para>
-      In particular, it means that any byte of the stream, even the message
-      header, may carry the ancillary data with file descriptors.
-    </para>
-    <para>
-      Clients and compositors should queue incoming data until they have
-      whole messages to process, as file descriptors may arrive earlier
-      or later than the corresponding data bytes.
-    </para>
-  </section>
-  <xi:include href="ProtocolInterfaces.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
-  <section id="sect-Protocol-Versioning">
-    <title>Versioning</title>
-    <para>
-      Every interface is versioned and every protocol object implements a
-      particular version of its interface.  For global objects, the maximum
-      version supported by the server is advertised with the global and the
-      actual version of the created protocol object is determined by the
-      version argument passed to wl_registry.bind().  For objects that are
-      not globals, their version is inferred from the object that created
-      them.
-    </para>
-    <para>
-      In order to keep things sane, this has a few implications for
-      interface versions:
-      <itemizedlist>
-	<listitem>
-	  <para>
-	    The object creation hierarchy must be a tree.  Otherwise,
-	    inferring object versions from the parent object becomes a much
-	    more difficult to properly track.
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    When the version of an interface increases, so does the version
-	    of its parent (recursively until you get to a global interface)
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    A global interface's version number acts like a counter for all
-	    of its child interfaces.  Whenever a child interface gets
-	    modified, the global parent's interface version number also
-	    increases (see above).  The child interface then takes on the
-	    same version number as the new version of its parent global
-	    interface.
-	  </para>
-	</listitem>
-      </itemizedlist>
-    </para>
-    <para>
-      To illustrate the above, consider the wl_compositor interface.  It
-      has two children, wl_surface and wl_region.  As of wayland version
-      1.2, wl_surface and wl_compositor are both at version 3.  If
-      something is added to the wl_region interface, both wl_region and
-      wl_compositor will get bumpped to version 4.  If, afterwards,
-      wl_surface is changed, both wl_compositor and wl_surface will be at
-      version 5.  In this way the global interface version is used as a
-      sort of "counter" for all of its child interfaces.  This makes it
-      very simple to know the version of the child given the version of its
-      parent.  The child is at the highest possible interface version that
-      is less than or equal to its parent's version.
-    </para>
-    <para>
-      It is worth noting a particular exception to the above versioning
-      scheme.  The wl_display (and, by extension, wl_registry) interface
-      cannot change because it is the core protocol object and its version
-      is never advertised nor is there a mechanism to request a different
-      version.
-    </para>
-  </section>
-  <section id="sect-Protocol-Connect-Time">
-    <title>Connect Time</title>
-    <para>
-      There is no fixed connection setup information, the server emits
-      multiple events at connect time, to indicate the presence and
-      properties of global objects: outputs, compositor, input devices.
-    </para>
-  </section>
-  <section id="sect-Protocol-Security-and-Authentication">
-    <title>Security and Authentication</title>
-    <para>
-      <itemizedlist>
-	<listitem>
-	  <para>
-	    mostly about access to underlying buffers, need new drm auth
-	    mechanism (the grant-to ioctl idea), need to check the cmd stream?
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    getting the server socket depends on the compositor type, could
-	    be a system wide name, through fd passing on the session dbus.
-	    or the client is forked by the compositor and the fd is
-	    already opened.
-	  </para>
-	</listitem>
-      </itemizedlist>
-    </para>
-  </section>
-  <section id="sect-Protocol-Creating-Objects">
-    <title>Creating Objects</title>
-    <para>
-      Each object has a unique ID.  The IDs are allocated by the entity
-      creating the object (either client or server).  IDs allocated by the
-      client are in the range [1, 0xfeffffff] while IDs allocated by the
-      server are in the range [0xff000000, 0xffffffff].  The 0 ID is
-      reserved to represent a null or non-existent object.
-
-      For efficiency purposes, the IDs are densely packed in the sense that
-      the ID N will not be used until N-1 has been used. This ordering is
-      not merely a guideline, but a strict requirement, and there are
-      implementations of the protocol that rigorously enforce this rule,
-      including the ubiquitous libwayland.
-    </para>
-  </section>
-  <section id="sect-Protocol-Compositor">
-    <title>Compositor</title>
-    <para>
-      The compositor is a global object, advertised at connect time.
-    </para>
-    <para>
-      See <xref linkend="protocol-spec-wl_compositor"/> for the
-      protocol description.
-    </para>
-  </section>
-  <section id="sect-Protocol-Surface">
-    <title>Surfaces</title>
-    <para>
-      A surface manages a rectangular grid of pixels that clients create
-      for displaying their content to the screen.  Clients don't know
-      the global position of their surfaces, and cannot access other
-      clients' surfaces.
-    </para>
-    <para>
-      Once the client has finished writing pixels, it 'commits' the
-      buffer; this permits the compositor to access the buffer and read
-      the pixels.  When the compositor is finished, it releases the
-      buffer back to the client.
-    </para>
-    <para>
-      See <xref linkend="protocol-spec-wl_surface"/> for the protocol
-      description.
-    </para>
-  </section>
-  <section id="sect-Protocol-Input">
-    <title>Input</title>
-    <para>
-      A seat represents a group of input devices including mice,
-      keyboards and touchscreens. It has a keyboard and pointer
-      focus. Seats are global objects. Pointer events are delivered
-      in surface-local coordinates.
-    </para>
-    <para>
-      The compositor maintains an implicit grab when a button is
-      pressed, to ensure that the corresponding button release
-      event gets delivered to the same surface. But there is no way
-      for clients to take an explicit grab. Instead, surfaces can
-      be mapped as 'popup', which combines transient window semantics
-      with a pointer grab.
-    </para>
-    <para>
-      To avoid race conditions, input events that are likely to
-      trigger further requests (such as button presses, key events,
-      pointer motions) carry serial numbers, and requests such as
-      wl_surface.set_popup require that the serial number of the
-      triggering event is specified. The server maintains a
-      monotonically increasing counter for these serial numbers.
-    </para>
-    <para>
-      Input events also carry timestamps with millisecond granularity.
-      Their base is undefined, so they can't be compared against
-      system time (as obtained with clock_gettime or gettimeofday).
-      They can be compared with each other though, and for instance
-      be used to identify sequences of button presses as double
-      or triple clicks.
-    </para>
-    <para>
-      See <xref linkend="protocol-spec-wl_seat"/> for the
-      protocol description.
-    </para>
-    <para>
-      Talk about:
-
-      <itemizedlist>
-	<listitem>
-	  <para>
-	    keyboard map, change events
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    xkb on Wayland
-	  </para>
-	</listitem>
-	<listitem>
-	  <para>
-	    multi pointer Wayland
-	  </para>
-	</listitem>
-      </itemizedlist>
-    </para>
-    <para>
-      A surface can change the pointer image when the surface is the pointer
-      focus of the input device.  Wayland doesn't automatically change the
-      pointer image when a pointer enters a surface, but expects the
-      application to set the cursor it wants in response to the pointer
-      focus and motion events.  The rationale is that a client has to manage
-      changing pointer images for UI elements within the surface in response
-      to motion events anyway, so we'll make that the only mechanism for
-      setting or changing the pointer image.  If the server receives a request
-      to set the pointer image after the surface loses pointer focus, the
-      request is ignored.  To the client this will look like it successfully
-      set the pointer image.
-    </para>
-    <para>
-      Setting the pointer image to NULL causes the cursor to be hidden.
-    </para>
-    <para>
-      The compositor will revert the pointer image back to a default image
-      when no surface has the pointer focus for that device.
-    </para>
-    <para>
-      What if the pointer moves from one window which has set a special
-      pointer image to a surface that doesn't set an image in response to
-      the motion event?  The new surface will be stuck with the special
-      pointer image.  We can't just revert the pointer image on leaving a
-      surface, since if we immediately enter a surface that sets a different
-      image, the image will flicker.  If a client does not set a pointer image
-      when the pointer enters a surface, the pointer stays with the image set
-      by the last surface that changed it, possibly even hidden.  Such a client
-      is likely just broken.
-    </para>
-  </section>
-  <section id="sect-Protocol-Output">
-    <title>Output</title>
-    <para>
-      An output is a global object, advertised at connect time or as it
-      comes and goes.
-    </para>
-    <para>
-      See <xref linkend="protocol-spec-wl_output"/> for the protocol
-      description.
-    </para>
-    <para>
-    </para>
-    <itemizedlist>
-      <listitem>
-	<para>
-	  laid out in a big (compositor) coordinate system
-	</para>
-      </listitem>
-      <listitem>
-	<para>
-	  basically xrandr over Wayland
-	</para>
-      </listitem>
-      <listitem>
-	<para>
-	  geometry needs position in compositor coordinate system
-	</para>
-      </listitem>
-      <listitem>
-	<para>
-	  events to advertise available modes, requests to move and change
-	  modes
-	</para>
-      </listitem>
-    </itemizedlist>
-  </section>
-  <section id="sect-Protocol-data-sharing">
-    <title>Data sharing between clients</title>
-    <para>
-      The Wayland protocol provides clients a mechanism for sharing
-      data that allows the implementation of copy-paste and
-      drag-and-drop. The client providing the data creates a
-      <function>wl_data_source</function> object and the clients
-      obtaining the data will see it as <function>wl_data_offer</function>
-      object. This interface allows the clients to agree on a mutually
-      supported mime type and transfer the data via a file descriptor
-      that is passed through the protocol.
-    </para>
-    <para>
-      The next section explains the negotiation between data source and
-      data offer objects. <xref linkend="sect-Protocol-data-sharing-devices"/>
-      explains how these objects are created and passed to different
-      clients using the <function>wl_data_device</function> interface
-      that implements copy-paste and drag-and-drop support.
-    </para>
-    <para>
-      See <xref linkend="protocol-spec-wl_data_offer"/>,
-      <xref linkend="protocol-spec-wl_data_source"/>,
-      <xref linkend="protocol-spec-wl_data_device"/> and
-      <xref linkend="protocol-spec-wl_data_device_manager"/> for
-      protocol descriptions.
-    </para>
-    <para>
-      MIME is defined in RFC's 2045-2049. A
-      <ulink url="https://www.iana.org/assignments/media-types/media-types.xhtml">
-      registry of MIME types</ulink> is maintained by the Internet Assigned
-      Numbers Authority (IANA).
-    </para>
-    <section>
-      <title>Data negotiation</title>
-      <para>
-	A client providing data to other clients will create a <function>wl_data_source</function>
-	object and advertise the mime types for the formats it supports for
-	that data through the <function>wl_data_source.offer</function>
-	request. On the receiving end, the data offer object will generate one
-	<function>wl_data_offer.offer</function> event for each supported mime
-	type.
-      </para>
-      <para>
-	The actual data transfer happens when the receiving client sends a
-	<function>wl_data_offer.receive</function> request. This request takes
-	a mime type and a file descriptor as arguments. This request will generate a
-	<function>wl_data_source.send</function> event on the sending client
-	with the same arguments, and the latter client is expected to write its
-	data to the given file descriptor using the chosen mime type.
-      </para>
-    </section>
-    <section id="sect-Protocol-data-sharing-devices">
-      <title>Data devices</title>
-      <para>
-	Data devices glue data sources and offers together. A data device is
-	associated with a <function>wl_seat</function> and is obtained by the clients using the
-	<function>wl_data_device_manager</function> factory object, which is also responsible for
-	creating data sources.
-      </para>
-      <para>
-	Clients are informed of new data offers through the
-	<function>wl_data_device.data_offer</function> event. After this
-	event is generated the data offer will advertise the available mime
-	types. New data offers are introduced prior to their use for
-	copy-paste or drag-and-drop.
-      </para>
-      <section>
-	<title>Selection</title>
-	<para>
-	  Each data device has a selection data source. Clients create a data
-	  source object using the device manager and may set it as the
-	  current selection for a given data device. Whenever the current
-	  selection changes, the client with keyboard focus receives a
-	  <function>wl_data_device.selection</function> event. This event is
-	  also generated on a client immediately before it receives keyboard
-	  focus.
-	</para>
-	<para>
-	  The data offer is introduced with
-	  <function>wl_data_device.data_offer</function> event before the
-	  selection event.
-	</para>
-      </section>
-      <section>
-	<title>Drag and Drop</title>
-	<para>
-	  A drag-and-drop operation is started using the
-	  <function>wl_data_device.start_drag</function> request. This
-	  requests causes a pointer grab that will generate enter, motion and
-	  leave events on the data device. A data source is supplied as
-	  argument to start_drag, and data offers associated with it are
-	  supplied to clients surfaces under the pointer in the
-	  <function>wl_data_device.enter</function> event. The data offer
-	  is introduced to the client prior to the enter event with the
-	  <function>wl_data_device.data_offer</function> event.
-	</para>
-	<para>
-	  Clients are expected to provide feedback to the data sending client
-	  by calling the <function>wl_data_offer.accept</function> request with
-	  a mime type it accepts. If none of the advertised mime types is
-	  supported by the receiving client, it should supply NULL to the
-	  accept request. The accept request causes the sending client to
-	  receive a <function>wl_data_source.target</function> event with the
-	  chosen mime type.
-	</para>
-	<para>
-	  When the drag ends, the receiving client receives a
-	  <function>wl_data_device.drop</function> event at which it is expected
-	  to transfer the data using the
-	  <function>wl_data_offer.receive</function> request.
-	</para>
-      </section>
-    </section>
-  </section>
-</chapter>
diff --git a/doc/publican/sources/Revision_History.xml b/doc/publican/sources/Revision_History.xml
deleted file mode 100644
index 2c540fe..0000000
--- a/doc/publican/sources/Revision_History.xml
+++ /dev/null
@@ -1,7 +0,0 @@
-<revhistory>
-  <revision>
-    <revnumber>1-0</revnumber>
-    <authorinitials>krh</authorinitials>
-    <revremark>Initial version</revremark>
-  </revision>
-</revhistory>
diff --git a/doc/publican/sources/Server.xml b/doc/publican/sources/Server.xml
deleted file mode 100644
index 2333b1a..0000000
--- a/doc/publican/sources/Server.xml
+++ /dev/null
@@ -1,49 +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">
-  <!ENTITY doxygen SYSTEM "ServerAPI.xml">
-%BOOK_ENTITIES;
-]>
-<appendix id="sect-Library-Server">
-  <title>Server API</title>
-  <section><title>Introduction</title>
-  <para>
-    The open-source reference implementation of Wayland protocol is
-    split in two C libraries, <link
-    linkend="sect-Library-Client">libwayland-client</link> and
-    libwayland-server. Their main responsibility is to handle the
-    Inter-process communication (<emphasis>IPC</emphasis>) with each
-    other, therefore guaranteeing the protocol objects marshaling and
-    messages synchronization.
-  </para>
-  <para>
-    The server library is designed to work much like libwayland-client,
-    although it is considerably complicated due to the server needing
-    to support multiple versions of the protocol. It is best to learn
-    libwayland-client first.
-  </para>
-  <para>
-    Each open socket to a client is represented by a <link
-    linkend="Server-structwl__client">wl_client</link>.  The equivalent
-    of the <link linkend="Client-classwl__proxy">wl_proxy</link> that
-    libwayland-client uses to represent an object is <link
-    linkend="Server-structwl__resource">wl_resource</link> for
-    client-created objects, and <link
-    linkend="Server-structwl__global">wl_global</link> for objects
-    created by the server.
-  </para>
-  <para>
-    Often a server is also a client for another Wayland server, and
-    thus must link with both libwayland-client and libwayland-server.
-    This produces some type name conflicts (such as the <link
-    linkend="Client-classwl__display">client wl_display</link> and
-    <link linkend="Server-structwl__display">server wl_display</link>,
-    but the duplicate-but-not-the-same types are opaque, and accessed
-    only inside the correct library where it came from. Naturally that
-    means that the program writer needs to always know if a pointer to
-    a wl_display is for the server or client side and use the
-    corresponding functions.
-  </para>
-  </section>
-  &doxygen;
-</appendix>
diff --git a/doc/publican/sources/Wayland.ent b/doc/publican/sources/Wayland.ent
deleted file mode 100644
index da18a95..0000000
--- a/doc/publican/sources/Wayland.ent
+++ /dev/null
@@ -1,4 +0,0 @@
-<!ENTITY PRODUCT "Documentation">
-<!ENTITY BOOKID "Wayland">
-<!ENTITY YEAR "2012">
-<!ENTITY HOLDER "Kristian Høgsberg, Intel Corporation">
diff --git a/doc/publican/sources/Wayland.xml b/doc/publican/sources/Wayland.xml
deleted file mode 100644
index 7593097..0000000
--- a/doc/publican/sources/Wayland.xml
+++ /dev/null
@@ -1,19 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE book 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;
-]>
-<book>
-  <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="Introduction.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-  <xi:include href="Compositors.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="Xwayland.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-  <xi:include href="Color.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-  <xi:include href="ProtocolSpec.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
-  <xi:include href="Client.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
-  <xi:include href="Server.xml" xmlns:xi="http://www.w3.org/2001/XInclude"/>
-</book>
diff --git a/doc/publican/sources/Xwayland.xml b/doc/publican/sources/Xwayland.xml
deleted file mode 100644
index 7915559..0000000
--- a/doc/publican/sources/Xwayland.xml
+++ /dev/null
@@ -1,170 +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-X11-Application-Support">
-  <title>X11 Application Support</title>
-  <section id="sect-X11-Application-Support-introduction">
-    <title>Introduction</title>
-    <para>
-      Being able to run existing X11 applications is crucial for the adoption
-      of Wayland, especially on desktops, as there will always be X11
-      applications that have not been or cannot be converted into Wayland
-      applications, and throwing them all away would be prohibitive.
-      Therefore a Wayland compositor often needs to support running X11
-      applications.
-    </para>
-    <para>
-      X11 and Wayland are different enough that there is no "simple" way to
-      translate between them. Most of X11 is uninteresting to a Wayland
-      compositor. That, combined with the gigantic implementation effort needed
-      to support X11, makes it intractable to just write X11 support directly in
-      a Wayland compositor. The implementation would be nothing short of a
-      real X11 server.
-    </para>
-    <para>
-      Therefore, Wayland compositors should use Xwayland, the X11 server that
-      lives in the Xorg server source code repository and shares most of the
-      implementation with the Xorg server. Xwayland is a complete X11 server,
-      just like Xorg is, but instead of driving the displays and opening input
-      devices, it acts as a Wayland client. The rest of this chapter talks
-      about how Xwayland works.
-    </para>
-    <para>
-      For integration and architecture reasons, while Xwayland is a Wayland
-      client of the Wayland compositor, the Wayland compositor is an X11 client
-      of Xwayland. This circular dependency requires special care from the
-      Wayland compositor.
-    </para>
-  </section>
-  <section id="sect-X11-Application-Support-two-modes">
-    <title>Two Modes for Foreign Windows</title>
-    <para>
-      In general, windows from a foreign window system can be presented in one
-      of two ways: rootless and rootful (not rootless).
-    </para>
-    <para>
-      In rootful mode, the foreign window system as a whole is represented as a
-      window (or more) of its own. You have a native window, inside which all
-      the foreign windows are. The advantage of this approach in Xwayland's
-      case is that you can run your favourite X11 window manager to manage your
-      X11 applications. The disadvantage is that the foreign windows do not
-      integrate with the native desktop. Therefore this mode is not usually
-      used.
-    </para>
-    <para>
-      In rootless mode, each foreign window is a first-class resident among the
-      native windows. Foreign windows are not confined inside a native window
-      but act as if they were native windows. The advantage is that one can
-      freely stack and mix native and foreign windows, which is not possible in
-      rootful mode. The disadvantage is that this mode is harder to implement
-      and fundamental differences in window systems may prevent some things
-      from working. With rootless Xwayland, the Wayland compositor must take
-      the role as the X11 window manager, and one cannot use any other X11
-      window manager in its place.
-    </para>
-    <para>
-      This chapter concentrates on the rootless mode, and ignores the rootful
-      mode.
-    </para>
-  </section>
-  <section id="sect-X11-Application-Support-architecture">
-    <title>Architecture</title>
-    <para>
-      A Wayland compositor usually takes care of launching Xwayland.
-      Xwayland works in cooperation with a Wayland compositor as follows:
-    </para>
-    <figure>
-      <title>Xwayland architecture diagram</title>
-      <mediaobjectco>
-	<imageobjectco>
-	  <imageobject>
-	    <imagedata fileref="images/xwayland-architecture.png" format="PNG" />
-	  </imageobject>
-	</imageobjectco>
-      </mediaobjectco>
-    </figure>
-    <para>
-      An X11 application connects to Xwayland just like it would connect to any
-      X server. Xwayland processes all the X11 requests. On the other end,
-      Xwayland is a Wayland client that connects to the Wayland compositor.
-    </para>
-    <para>
-      The X11 window manager (XWM) is an integral part of the Wayland
-      compositor. XWM uses the usual X11 window management protocol to manage
-      all X11 windows in Xwayland. Most importantly, XWM acts as a bridge
-      between Xwayland window state and the Wayland compositor's window manager
-      (WWM). This way WWM can manage all windows, both native Wayland and X11
-      (Xwayland) windows. This is very important for a coherent user
-      experience.
-    </para>
-    <para>
-      Since Xwayland uses Wayland for input and output, it does not have any
-      use for the device drivers that Xorg uses. None of the xf86-video-* or
-      xf86-input-* modules are used. There also is no configuration file for
-      the Xwayland server. For optional hardware accelerated rendering,
-      Xwayland uses GLAMOR.
-    </para>
-    <para>
-      A Wayland compositor usually spawns only one Xwayland instance. This is
-      because many X11 applications assume they can communicate with other X11
-      applications through the X server, and this requires a shared X server
-      instance. This also means that Xwayland does not protect nor isolate X11
-      clients from each other, unless the Wayland compositor specifically
-      chooses to break the X11 client intercommunications by spawning
-      application specific Xwayland instances. X11 clients are naturally
-      isolated from Wayland clients.
-    </para>
-    <para>
-      Xwayland compatibility compared to a native X server will probably never
-      reach 100%. Desktop environment (DE) components, specifically X11 window
-      managers, are practically never supported. An X11 window manager would
-      not know about native Wayland windows, so it could manage only X11
-      windows. On the other hand, there must be an XWM that reserves the
-      exclusive window manager role so that the Wayland compositor could show
-      the X11 windows appropriately. For other DE components, like pagers and
-      panels, adding the necessary interfaces to support them in WWM through XWM
-      is often considered not worthwhile.
-    </para>
-  </section>
-  <section id="sect-X11-Application-Support-xwm">
-    <title>X Window Manager (XWM)</title>
-    <para>
-      From the X11 point of view, the X window manager (XWM) living inside a
-      Wayland compositor is just like any other window manager. The difference
-      is mostly in which process it resides in, and the few extra conventions
-      in the X11 protocol to support Wayland window management (WWM)
-      specifically.
-    </para>
-    <para>
-      There are two separate asynchronous communication channels between
-      Xwayland and a Wayland compositor: one uses the Wayland protocol, and the
-      other one, solely for XWM, uses X11 protocol. This setting demands great
-      care from the XWM implementation to avoid (random) deadlocks with
-      Xwayland. It is often nearly impossible to prove that synchronous or
-      blocking X11 calls from XWM cannot cause a deadlock, and therefore it is
-      strongly recommended to make all X11 communications asynchronous. All
-      Wayland communications are already asynchronous by design.
-    </para>
-    <section id="sect-X11-Application-Support-xwm-window-identification">
-      <title>Window identification</title>
-      <para>
-	In Xwayland, an X11 window may have a corresponding wl_surface object
-	in Wayland. The wl_surface object is used for input and output: it is
-	referenced by input events and used to provide the X11 window content
-	to the Wayland compositor. The X11 window and the wl_surface live in
-	different protocol streams, and they need to be matched for XWM to do
-	its job.
-      </para>
-      <para>
-	When Xwayland creates a wl_surface on Wayland, it will also send an X11
-	ClientMessage of type atom "WL_SURFACE_ID" to the X11 window carrying
-	the wl_surface Wayland object ID as the first 32-bit data element. This
-	is how XWM can associate a wl_surface with an X11 window. Note that
-	the request to create a wl_surface and the ID message may arrive in any
-	order in the Wayland compositor.
-      </para>
-    </section>
-  </section>
-</chapter>
diff --git a/doc/publican/sources/css/brand.css b/doc/publican/sources/css/brand.css
deleted file mode 100644
index d86cba9..0000000
--- a/doc/publican/sources/css/brand.css
+++ /dev/null
@@ -1,14 +0,0 @@
-/*headings*/
-h1, h2, h3, h4, h5, h6,
-div.producttitle,
-div.subtitle,
-div.author div.author,
-div.translator div.translator,
-div.othercredit div.othercredit,
-div.editor div.editor,
-div.contrib div.contrib,
-.title,
-.titlepage .edition,
-.titlepage .releaseinfo {
-	color: #336699;
-}
diff --git a/doc/publican/sources/css/common.css b/doc/publican/sources/css/common.css
deleted file mode 100644
index a05648e..0000000
--- a/doc/publican/sources/css/common.css
+++ /dev/null
@@ -1,1769 +0,0 @@
-* {
-	widows: 4 !important;
-	orphans: 4 !important;
-}
-
-body, h1, h2, h3, h4, h5, h6, pre, li, div {
-	line-height: 1.29em;
-}
-
-body {
-	background-color: white;
-	margin:0 auto;
-	font-family: "liberation sans", "Myriad ", "Bitstream Vera Sans", "Lucida Grande", "Luxi Sans", "Trebuchet MS", helvetica, verdana, arial, sans-serif;
-	font-size: 14px;
-	max-width: 770px;
-	color: black;
-}
-
-body.toc_embeded {
-	/*for web hosting system only*/
-	margin-left: 300px;
-}
-
-object.toc, iframe.toc {
-	/*for web hosting system only*/
-	border-style: none;
-	position: fixed;
-	width: 290px;
-	height: 99.99%;
-	top: 0;
-	left: 0;
-	z-index: 100;
-	border-style: none;
-	border-right:1px solid #999;
-}
-
-/* Hide web menu */
-
-body.notoc {
-	margin-left: 3em;
-}
-
-iframe.notoc {
-	border-style:none;
-	border: none;
-	padding: 0px;
-	position:fixed;
-	width: 21px;
-	height: 29px;
-	top: 0px;
-	left:0;
-	overflow: hidden;
-	margin: 0px;
-	margin-left: -3px;
-}
-/* End hide web menu */
-
-/* desktop styles */
-body.desktop {
-	margin-left: 26em;
-}
-
-body.desktop .book > .toc {
-	display:block;
-	width:24em;
-	height:99.99%;
-	position:fixed;
-	overflow:auto;
-	top:0px;
-	left:0px;
-/*	padding-left:1em; */
-	background-color:#EEEEEE;
-	font-size: 12px;
-}
-
-body.pdf {
-	max-width: 100%;
-}
-
-.toc {
-	line-height:1.35em;
-}
-
-.toc .glossary,
-.toc .chapter, .toc .appendix {
-	margin-top:1em;
-}
-
-.toc .part {
-	margin-top:1em;
-	display:block;
-}
-
-span.glossary,
-span.appendix {
-	display:block;
-	margin-top:0.5em;
-}
-
-div {
-	padding-top:0px;
-}
-
-div.section {
-	page-break-inside: avoid;
-}
-
-p, div.para {
-	padding-top: 0px;
-	margin-top: 1em;
-	padding-bottom: 0px;
-	margin-bottom: 1em;
-}
-
-div.formalpara {
-	padding-top: 0px;
-	margin-top: 1em;
-	padding-bottom: 0px;
-	margin-bottom: 1em;
-}
-
-.varlistentry div.para {
-	page-break-before: avoid;
-
-}
-
-/*Links*/
-a {
-	outline: none;
-}
-
-a:link {
-	text-decoration: none;
-	border-bottom: 1px dotted ;
-	color:#3366cc;
-}
-
-body.pdf a:link {
-	word-wrap: break-word;
-}
-
-a:visited {
-	text-decoration:none;
-	border-bottom: 1px dotted ;
-	color:#003366;
-}
-
-div.longdesc-link {
-	float:right;
-	color:#999;
-}
-
-.toc a, .qandaset a {
-	font-weight:normal;
-	border:none;
-}
-
-.toc a:hover, .qandaset a:hover
-{
-	border-bottom: 1px dotted;
-}
-
-/*headings*/
-h1, h2, h3, h4, h5, h6 {
-	color: #336699;
-	margin-top: 0px;
-	margin-bottom: 0px;
-	background-color: transparent;
-	margin-bottom: 0px;
-	margin-top: 20px;
-	page-break-inside: avoid;
-	page-break-after: avoid;
-	word-wrap: break-word;
-}
-
-h1 {
-	font-size: 22px;
-}
-
-.titlepage h1.title {
-	text-align:left;
-}
-
-.book > .titlepage h1.title {
-	text-align: center;
-}
-
-.article > .titlepage h1.title,
-.article > .titlepage h2.title {
-	text-align: center;
-}
-
-.set .titlepage > div > div > h1.title {
-	text-align: center;
-}
-
-.part > .titlepage h1.title {
-	text-align: center;
-	font-size: 24px;
-}
-
-div.producttitle {
-	margin-top: 0px;
-	margin-bottom: 20px;
-	font-size: 48px;
-	font-weight: bold;
-/* 	background: #003d6e url(../images/h1-bg.png) top left repeat-x; */
-	color:  #336699;
-	text-align: center;
-	padding-top: 12px;
-}
-
-.titlepage .corpauthor {
-	margin-top: 1em;
-	text-align: center;
-}
-
-.section h1.title {
-	font-size: 18px;
-	padding: 0px;
-	color: #336699;
-	text-align: left;
-	background: white;
-}
-
-h2 {
-	font-size: 20px;
-	margin-top: 30px;
-}
-
-
-.book div.subtitle, .book h2.subtitle, .book h3.subtitle {
-	margin-top: 1em;
-	margin-bottom: 1em;
-	font-size: 18px;
-	text-align: center;
-}
-
-div.subtitle {
-	color:  #336699;
-	font-weight: bold;
-}
-
-h1.legalnotice {
-	font-size: 24px;
-}
-
-.preface > div > div > div > h2.title,
-.preface > div > div > div > h1.title {
-	margin-top: 1em;
-	font-size: 24px;
-}
-
-.appendix h2 {
-	font-size: 24px;
-}
-
-
-
-h3 {
-	font-size: 14px;
-	padding-top:0px;
-	padding-bottom: 0px;
-	margin-bottom: 0px;
-}
-h4 {
-	font-size: 14px;
-	padding-top:0px;
-	padding-bottom:0px;
-}
-
-h5 {
-	font-size: 14px;
-}
-
-h6 {
-	font-size: 14px;
-	margin-bottom: 0px;
-}
-
-.abstract h6 {
-	margin-top:1em;
-	margin-bottom:.5em;
-	font-size: 24px;
-}
-
-.index > div > div > div > h2.title {
-	font-size: 24px;
-}
-
-.chapter > div > div > div > h2.title {
-	font-size: 24px;
-}
-
-.section > div > div > div > h2.title {
-	font-size: 21px;
-	page-break-inside: avoid;
-	page-break-before: avoid;
-	page-break-after: avoid;
-}
-
-.section > div > div > div > h3.title {
-	font-size: 17px;
-}
-
-/*element rules*/
-hr {
-	border-collapse: collapse;
-	border-style:none;
-	border-top: 1px dotted #ccc;
-	width:100%;
-}
-
-/* web site rules */
-ul.languages, .languages li {
-	display:inline;
-	padding:0px;
-}
-
-.languages li a {
-	padding:0px .5em;
-	text-decoration: none;
-}
-
-.languages li p, .languages li div.para {
-	display:inline;
-}
-
-.languages li a:link, .languages li a:visited {
-	color:#444;
-}
-
-.languages li a:hover, .languages li a:focus, .languages li a:active {
-	color:black;
-}
-
-ul.languages {
-	display:block;
-	background-color:#eee;
-	padding:.5em;
-}
-
-/*supporting stylesheets*/
-
-/*unique to the webpage only*/
-.books {
-	position:relative;
-}
-
-.versions li {
-	width:100%;
-	clear:both;
-	display:block;
-}
-
-a.version {
-	font-size: 20px;
-	text-decoration:none;
-	width:100%;
-	display:block;
-	padding:1em 0px .2em 0px;
-	clear:both;
-}
-
-a.version:before {
-	content:"Version";
-	font-size: smaller;
-}
-
-a.version:visited, a.version:link {
-	color:#666;
-}
-
-a.version:focus, a.version:hover {
-	color:black;
-}
-
-.books {
-	display:block;
-	position:relative;
-	clear:both;
-	width:100%;
-}
-
-.books li {
-	display:block;
-	width:200px;
-	float:left;
-	position:relative;
-	clear: none ;
-}
-
-.books .html {
-	width:170px;
-	display:block;
-}
-
-.books .pdf {
-	position:absolute;
-	left:170px;
-	top:0px;
-	font-size: smaller;
-}
-
-.books .pdf:link, .books .pdf:visited {
-	color:#555;
-}
-
-.books .pdf:hover, .books .pdf:focus {
-	color:#000;
-}
-
-.books li a {
-	text-decoration:none;
-}
-
-.books li a:hover {
-	color:black;
-}
-
-/*products*/
-.products li {
-	display: block;
-	width:300px;
-	float:left;
-}
-
-.products li a {
-	width:300px;
-	padding:.5em 0px;
-}
-
-.products ul {
-	clear:both;
-}
-
-/*revision history*/
-.revhistory {
-	display:block;
-}
-
-.revhistory table {
-	background-color:transparent;
-	border-color:#fff;
-	padding:0px;
-	margin: 0;
-	border-collapse:collapse;
-	border-style:none;
-}
-
-.revhistory td {
-	text-align :left;
-	padding:0px;
-	border: none;
-	border-top: 1px solid #fff;
-	font-weight: bold;
-}
-
-.revhistory .simplelist td {
-	font-weight: normal;
-}
-
-.revhistory .simplelist {
-	margin-bottom: 1.5em;
-	margin-left: 1em;
-}
-
-.revhistory table th {
-	display: none;
-}
-
-
-/*credits*/
-.authorgroup div {
-	clear:both;
-	text-align: center;
-}
-
-div.author div.author,
-div.translator div.translator,
-div.othercredit div.othercredit,
-div.editor div.editor,
-div.contrib div.contrib {
-	margin: 0px;
-	padding: 0px;
-	margin-top: 12px;
-	font-size: 14px;
-	font-weight: bold;
-	color: #336699;
-}
-
-div.editedby {
-	margin-top: 15px;
-	margin-bottom: -0.8em;
-}
-
-div.authorgroup .author,
-div.authorgroup.editor,
-div.authorgroup.translator,
-div.authorgroup.othercredit,
-div.authorgroup.contrib {
-	display: block;
-	font-size: 14px;
-	page-break-inside: avoid;
-}
-
-.revhistory .author {
-	display: inline;
-}
-
-.othercredit h3 {
-	padding-top: 1em;
-}
-
-
-.othercredit {
-	margin:0px;
-	padding:0px;
-}
-
-.releaseinfo {
-	clear: both;
-}
-
-.copyright {
-	margin-top: 1em;
-}
-
-/* qanda sets */
-.answer {
-	margin-bottom:1em;
-	border-bottom:1px dotted #ccc;
-}
-
-.qandaset .toc {
-	border-bottom:1px dotted #ccc;
-}
-
-.question {
-	font-weight:bold;
-}
-
-.answer .data, .question .data {
-	padding-left: 2.6em;
-}
-
-.answer .label, .question .label {
-	float:left;
-	font-weight:bold;
-}
-
-/* inline syntax highlighting */
-.perl_Alert {
-	color: #0000ff;
-}
-
-.perl_BaseN {
-	color: #007f00;
-}
-
-.perl_BString {
-	color: #5C3566;
-}
-
-.perl_Char {
-	color: #ff00ff;
-}
-
-.perl_Comment {
-	color: #888888;
-}
-
-
-.perl_DataType {
-	color: #0000ff;
-}
-
-
-.perl_DecVal {
-	color: #00007f;
-}
-
-
-.perl_Error {
-	color: #ff0000;
-}
-
-
-.perl_Float {
-	color: #00007f;
-}
-
-
-.perl_Function {
-	color: #007f00;
-}
-
-
-.perl_IString {
-	color: #5C3566;
-}
-
-
-.perl_Keyword {
-	color: #002F5D;
-}
-
-
-.perl_Operator {
-	color: #ffa500;
-}
-
-
-.perl_Others {
-	color: #b03060;
-}
-
-
-.perl_RegionMarker {
-	color: #96b9ff;
-}
-
-
-.perl_Reserved {
-	color: #9b30ff;
-}
-
-
-.perl_String {
-	color: #5C3566;
-}
-
-
-.perl_Variable {
-	color: #0000ff;
-}
-
-
-.perl_Warning {
-	color: #0000ff;
-}
-
-/*Lists*/
-ul {
-    list-style-image: url("../images/dot.png");
-    list-style-type: circle;
-    padding-left: 1.6em;
-}
-
-ul ul {
-    list-style-image: url("../images/dot2.png");
-    list-style-type: circle;
-}
-
-ol.1 {
-	list-style-type: decimal;
-}
-
-ol.a,
-ol ol {
-	list-style-type: lower-alpha;
-}
-
-ol.i {
-	list-style-type: lower-roman;
-}
-ol.A {
-	list-style-type: upper-alpha;
-}
-
-ol.I {
-	list-style-type: upper-roman;
-}
-
-dt {
-	font-weight:bold;
-	margin-bottom:0px;
-	padding-bottom:0px;
-}
-
-dd {
-	margin:0px;
-	margin-left:2em;
-	padding-top:0px;
-}
-
-li {
-	padding-top: 0px;
-	margin-top: 0px;
-	padding-bottom: 0px;
-/*	margin-bottom: 16px; */
-}
-
-/*images*/
-img {
-	display:block;
-	margin: 2em 0;
-	max-width: 100%;
-}
-
-.inlinemediaobject,
-.inlinemediaobject img,
-.inlinemediaobject object {
-	display:inline;
-	margin:0px;
-	overflow: hidden;
-}
-
-.figure {
-    margin-top: 1em;
-    width: 100%;
-}
-
-.figure img,
-.mediaobject img {
-	display:block;
-	margin: 0em;
-	page-break-inside: avoid;
-}
-
-.figure .title {
-	margin-bottom:2em;
-	padding:0px;
-}
-
-/*document modes*/
-.confidential {
-	background-color:#900;
-	color:White;
-	padding:.5em .5em;
-	text-transform:uppercase;
-	text-align:center;
-}
-
-.longdesc-link {
-	display:none;
-}
-
-.longdesc {
-	display:none;
-}
-
-.prompt {
-	padding:0px .3em;
-}
-
-/*user interface styles*/
-.screen .replaceable {
-}
-
-.guibutton, .guilabel {
-	font-family: "liberation mono", "bitstream vera mono", "dejavu mono", monospace;
-	font-weight: bold;
-}
-
-.example {
-	background-color: #ffffff;
-	border-left: 3px solid #aaaaaa;
-	padding-top: 1px;
-	padding-bottom: 0.1em;
-	padding-left: 1em;
-}
-
-.equation {
-	border-left: 3px solid #aaaaaa;
-	background-color: #ffffff;
-	padding-top: 1px;
-	padding-bottom: 0.1em;
-	padding-left: 1em;
-}
-
-.equation-contents {
-	margin-left: 4em;
-}
-
-div.title {
-	margin-bottom: 1em;
-	font-weight: 14px;
-	font-weight: bold;
-	color: #336699;
-	page-break-inside: avoid;
-	page-break-after: avoid;
-	word-wrap: break-word;
-}
-
-.example-contents {
-	background-color: #ffffff;
-}
-
-.example-contents .para {
-/*	 padding: 10px;*/
-}
-
-/*terminal/console text*/
-.computeroutput,
-.option {
-	font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
-	font-weight:bold;
-}
-
-.replaceable {
-	font-style: italic;
-}
-
-.command, .filename, .keycap, .classname, .literal {
-	font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
-	font-weight:bold;
-}
-
-/* no bold in toc */
-.toc * {
-	font-weight: inherit;
-}
-
-.toc H1 {
-	font-weight: bold;
-}
-
-
-div.programlisting {
-	white-space: pre-wrap; /* css-3 */
-	white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
-	white-space: -pre-wrap; /* Opera 4-6 */
-	white-space: -o-pre-wrap; /* Opera 7 */
-	word-wrap: break-word; /* Internet Explorer 5.5+ */
-}
-
-pre {
-	font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
-	display:block;
-	background-color: #f5f5f5;
-	color: #000000;
-/*	border: 1px solid #aaaaaa; */
-	margin-bottom: 1em;
-	padding:.5em 1em;
-	white-space: pre-wrap; /* css-3 */
-	white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
-	white-space: -pre-wrap; /* Opera 4-6 */
-	white-space: -o-pre-wrap; /* Opera 7 */
-	word-wrap: break-word; /* Internet Explorer 5.5+ */
-	font-size: 0.9em;
-	border-style:none;
-	box-shadow: 0 2px 5px #AAAAAA inset;
-	-moz-box-shadow:  0 2px 5px #AAAAAA inset;
-	-webkit-box-shadow: 0 2px 5px #AAAAAA inset;
-	-o-box-shadow: 0 2px 5px #AAAAAA inset;
-}
-
-body.pdf pre {
-	border: 1px solid #AAAAAA;
-	box-shadow: none;
-	-moz-box-shadow: none;
-	-webkit-box-shadow: none;
-	-o-box-shadow: none;
-}
-
-
-pre .replaceable,
-pre .keycap {
-}
-
-code {
-	font-family:"liberation mono", "bitstream vera mono", "dejavu mono", monospace;
-	white-space: pre-wrap;
-	word-wrap: break-word;
-	font-weight:bold;
-}
-
-.parameter code {
-	display: inline;
-	white-space: pre-wrap; /* css-3 */
-	white-space: -moz-pre-wrap !important; /* Mozilla, since 1999 */
-	white-space: -pre-wrap; /* Opera 4-6 */
-	white-space: -o-pre-wrap; /* Opera 7 */
-	word-wrap: break-word; /* Internet Explorer 5.5+ */
-}
-
-code.email {
-	font-weight: normal;
-	font-family: "liberation sans", "Myriad ", "Bitstream Vera Sans", "Lucida Grande", "Luxi Sans", "Trebuchet MS", helvetica, verdana, arial, sans-serif;
-
-}
-
-/*Notifications*/
-div.warning:before {
-	content:url(../images/warning.png);
-	padding-left: 5px;
-}
-
-div.note:before {
-	content:url(../images/note.png);
-	padding-left: 5px;
-}
-
-div.important:before {
-	content:url(../images/important.png);
-	padding-left: 5px;
-}
-
-div.warning, div.note, div.important {
-	color: black;
-	margin: 0px;
-	padding: 0px;
-	background: none;
-	background-color: white;
-	margin-bottom: 1em;
-	border-bottom: 1px solid #aaaaaa;
-	page-break-inside: avoid;
-}
-
-div.admonition_header p {
-	margin: 0px;
-	padding: 0px;
-	color: #eeeeec;
-	padding-top: 0px;
-	padding-bottom: 0px;
-	height: 1.4em;
-	line-height: 1.4em;
-	font-size: 17px;
-	display:inline;
-}
-
-div.admonition_header {
-	background-origin:content-box;
-	clear: both;
-	margin: 0px;
-	padding: 0px;
-	margin-top: -40px;
-	padding-left: 58px;
-	line-height: 1.0px;
-	font-size: 1.0px;
-}
-
-div.warning div.admonition_header {
-	background: url(../images/red.png) top left repeat-x;
-	background-color: #590000;
-	background: -webkit-linear-gradient(#a40000,#590000);
-	background: linear-gradient(#a40000,#590000);
-}
-
-div.note div.admonition_header {
-	background: url(../images/green.png) top right repeat-x;
-	background-color: #597800;
-	background: -webkit-linear-gradient(#769f00,#597800);
-	background: linear-gradient(#769f00,#597800);
-}
-
-div.important div.admonition_header {
-	background: url(../images/yellow.png) top right repeat-x;
-	background-color: #a6710f;
-	background: -webkit-linear-gradient(#d08e13,#a6710f);
-	background: linear-gradient(#d08e13,#a6710f);
-}
-
-div.warning p:first-child,
-div.warning div.para:first-child,
-div.note p:first-child,
-div.note div.para:first-child,
-div.important p:first-child,
-div.important div.para:first-child {
-	padding: 0px;
-	margin: 0px;
-}
-
-div.admonition {
-	border: none;
-	border-left: 1px solid #aaaaaa;
-	border-right: 1px solid #aaaaaa;
-	padding:0px;
-	margin:0px;
-	padding-top: 1.5em;
-	padding-bottom: 1em;
-	padding-left: 2em;
-	padding-right: 1em;
-	background-color: #eeeeec;
-	-moz-border-radius: 0px;
-	-webkit-border-radius: 0px;
-	border-radius: 0px;
-}
-
-/*Page Title*/
-#title  {
-	display:block;
-	height:45px;
-	padding-bottom:1em;
-	margin:0px;
-}
-
-#title a.left{
-	display:inline;
-	border:none;
-}
-
-#title a.left img{
-	border:none;
-	float:left;
-	margin:0px;
-	margin-top:.7em;
-}
-
-#title a.right {
-	padding-bottom:1em;
-}
-
-#title a.right img {
-	border:none;
-	float:right;
-	margin:0px;
-	margin-top:.7em;
-}
-
-/*Table*/
-div.table {
-/*	page-break-inside: avoid; */
-}
-
-table {
-	border: 1px solid #444;
-	width:100%;
-	border-collapse:collapse;
-	table-layout: fixed;
-	word-wrap: break-word;
-}
-
-table.blockquote,
-table.simplelist,
-.calloutlist table {
-	border-style: none;
-}
-
-table th {
-	text-align:left;
-	background-color:#6699cc;
-	padding:.3em .5em;
-	color:white;
-}
-
-table td {
-	padding:.15em .5em;
-}
-
-table tr.even td {
-	background-color:#f5f5f5;
-}
-
-tr:nth-child(even) {
-	background-color: #eeeeee;
-
-}
-
-
-table th p:first-child, table td p:first-child, table  li p:first-child,
-table th div.para:first-child, table td div.para:first-child, table  li div.para:first-child {
-	margin-top:0px;
-	padding-top:0px;
-	display:inline;
-}
-
-th, td {
-	border-style:none;
-	vertical-align: top;
-/* 	border: 1px solid #000; */
-}
-
-.blockquote td,
-.simplelist th,
-.simplelist td {
-	border: none;
-}
-
-table table td {
-	border-bottom:1px dotted #aaa;
-	background-color:white;
-	padding:.6em 0px;
-}
-
-table table {
-	border:1px solid white;
-}
-
-td.remarkval {
-	color:#444;
-}
-
-td.fieldval {
-	font-weight:bold;
-}
-
-.lbname, .lbtype, .lbdescr, .lbdriver, .lbhost {
-	color:white;
-	font-weight:bold;
-	background-color:#999;
-	width:120px;
-}
-
-td.remarkval {
-	width:230px;
-}
-
-td.tname {
-	font-weight:bold;
-}
-
-th.dbfield {
-	width:120px;
-}
-
-th.dbtype {
-	width:70px;
-}
-
-th.dbdefault {
-	width:70px;
-}
-
-th.dbnul {
-	width:70px;
-}
-
-th.dbkey {
-	width:70px;
-}
-
-span.book {
-	margin-top:4em;
-	display:block;
-	font-size: 11pt;
-}
-
-span.book a{
-	font-weight:bold;
-}
-span.chapter {
-	display:block;
-}
-
-table.simplelist td, .calloutlist table td {
-	border-style: none;
-}
-
-
-table.lt-4-cols.lt-7-rows td {
-	border: none;
-}
-/*to simplify layout*/
-
-
-table.lt-4-cols.gt-14-rows tr:nth-child(odd) {
-	background-color: #fafafa;
-}
-/* to keep simple but stripe rows */
-
-
-.gt-8-cols td {
-	border-left: 1px solid #ccc;
-}
-
-.gt-8-cols td:first-child {
-	border-left: 0;
-}
-/* to apply vertical lines to differentiate columns*/
-
-/*Breadcrumbs*/
-#breadcrumbs ul li.first:before {
-	content:" ";
-}
-
-#breadcrumbs {
-	color:#900;
-	padding:3px;
-	margin-bottom:25px;
-}
-
-#breadcrumbs ul {
-	margin-left:0;
-	padding-left:0;
-	display:inline;
-	border:none;
-}
-
-#breadcrumbs ul li {
-	margin-left:0;
-	padding-left:2px;
-	border:none;
-	list-style:none;
-	display:inline;
-}
-
-#breadcrumbs ul li:before {
-	content:"\0020 \0020 \0020 \00BB \0020";
-	color:#333;
-}
-
-dl {
-	margin-top: 0px;
-	margin-left: 28px;
-}
-
-.toc dl {
-	margin-left: 10px;
-}
-
-/*index*/
-.glossary h3,
-.index h3 {
-	font-size: 20px;
-	color:#aaa;
-	margin:0px;
-}
-
-.indexdiv {
-	margin-bottom:1em;
-}
-
-.glossary dt,
-.index dt {
-	color:#444;
-	padding-top:.5em;
-}
-
-.glossary dl dl dt,
-.index dl dl dt {
-	color:#777;
-	font-weight:normal;
-	padding-top:0px;
-}
-
-.index dl dl dt:before {
-	content:"- ";
-	color:#ccc;
-}
-
-/*changes*/
-.footnote {
-	font-size: 10px;
-	margin: 0px;
-	color: #222;
-}
-
-.footnotes {
-	margin-bottom: 60px;
-}
-
-table .footnote {
-}
-
-sup {
-	margin:0px;
-	padding:0px;
-	font-size: 10px;
-	padding-left:0px;
-}
-
-.footnote {
-	position:relative;
-}
-
-.footnote sup  {
-	color: black;
-	left: .4em;
-}
-
-.footnote a:link,
-.footnote a:visited {
-	text-decoration:none;
-	border: none;
-}
-
-.footnote .para sup  {
-/*	position:absolute; */
-	vertical-align:text-bottom;
-}
-
-a.footnote {
-	padding-right: 0.5em;
-	text-decoration:none;
-	border: none;
-}
-
-.footnote sup a:link,
-.footnote sup a:visited {
-	color:#92917d;
-	text-decoration:none;
-}
-
-.footnote:hover sup a {
-	text-decoration:none;
-}
-
-.footnote p,.footnote div.para {
-	padding-left:1em;
-}
-
-.footnote a:link,
-.footnote a:visited before{
-	color:#00537c;
-}
-
-.footnote a:hover {
-}
-
-/**/
-.pdf-break {
-	page-break-before: always;
-}
-
-div.legalnotice {
-	page-break-before: always;
-}
-
-div.abstract {
-	page-break-before: always;
-/*	page-break-after: always;*/
-}
-
-div.chapter {
-	page-break-before: always;
-}
-
-
-div.titlepage, div.titlepage > div, div.titlepage > div > div {
-	page-break-inside: avoid;
-	page-break-after: avoid;
-}
-
-div.preface, div.part {
-	page-break-before: always;
-}
-
-div.appendix {
-	page-break-before: always;
-}
-
-div.section {
-	page-break-inside: auto;
-	page-break-before: auto;
-	page-break-after: auto;
-}
-
-
-dt.varlistentry {
-	page-break-inside: avoid;
-	page-break-after: avoid;
-}
-
-dd {
-	page-break-before: avoid;
-}
-
-div.note .replaceable,
-div.important .replaceable,
-div.warning .replaceable,
-div.note .keycap,
-div.important .keycap,
-div.warning .keycap
-{
-}
-
-ul li p:last-child, ul li para:last-child {
-	margin-bottom:0px;
-	padding-bottom:0px;
-}
-
-/*document navigation*/
-.docnav a, .docnav strong {
-	border:none;
-	text-decoration:none;
-	font-weight:normal;
-}
-
-.docnav {
-	list-style:none;
-	margin:0px;
-	padding:0px;
-	position:relative;
-	width:100%;
-	padding-bottom:2em;
-	padding-top:1em;
-        height:2.5em;
-        line-height:2.5em;
-/*
-	border-top:1px dotted #ccc;
-        background-color: rgba(240, 240, 240, 0.9);
--webkitbox-shadow: 0px .15em .5em rgba(0,0,0,0.2);
-  -moz-box-shadow: 0px .15em .5em rgba(0,0,0,0.2);
-       box-shadow: 0px .15em .5em rgba(0,0,0,0.2);
-*/
-}
-
-.docnav li {
-	list-style:none;
-	margin:0px;
-	padding:0px;
-	display:inline;
-	font-size: 14px;
-}
-
-.docnav li:before {
-	content:" ";
-}
-
-.docnav li.previous, .docnav li.next {
-	position:absolute;
-	top:1.5em;
-}
-
-.docnav li.up, .docnav li.home {
-	margin:0px 1.5em;
-}
-
-.docnav.top li.home {
-	color: #336699;
-	font-size: 22pt;
-	font-weight: bold;
-}
-
-
-.docnav li.previous {
-	left:0px;
-	text-align:left;
-}
-
-.docnav li.next {
-	right:0px;
-	text-align:right;
-}
-
-.docnav li.previous strong, .docnav li.next strong {
-	height: 17px;
-	display: block;
-}
-
-.docnav {
-	margin:0 auto;
-	text-align:center;
-}
-
-.docnav li.next a strong {
-	background:  url(../images/stock-go-forward.png) right 120% no-repeat;
-	padding-top:3px;
-	padding-bottom:4px;
-	padding-right:28px;
-}
-
-.docnav li.previous a strong {
-	background: url(../images/stock-go-back.png) left 120% no-repeat;
-	padding-top:3px;
-	padding-bottom:4px;
-	padding-left:28px;
-	padding-right:0.5em;
-}
-
-.docnav li.home a strong {
-	background: url(../images/stock-home.png) top left no-repeat;
-	padding:5px;
-	padding-left:28px;
-}
-
-.docnav li.up a strong {
-	background: url(../images/stock-go-up.png) top left no-repeat;
-	padding:5px;
-	padding-left:28px;
-}
-
-.docnav a:link, .docnav a:visited {
-	color:#666;
-}
-
-.docnav a:hover, .docnav a:focus, .docnav a:active {
-	color:black;
-}
-
-.docnav a {
-	max-width: 10px;
-	overflow:hidden;
-}
-
-.docnav a:link strong {
-	text-decoration:none;
-}
-
-.docnav {
-	margin:0 auto;
-	text-align:center;
-}
-
-ul.docnav {
-	margin-bottom: 1em;
-}
-/* Reports */
-.reports ul {
-	list-style:none;
-	margin:0px;
-	padding:0px;
-}
-
-.reports li{
-	margin:0px;
-	padding:0px;
-}
-
-.reports li.odd {
-	background-color: #eeeeee;
-	margin:0px;
-	padding:0px;
-}
-
-.reports dl {
-	display:inline;
-	margin:0px;
-	padding:0px;
-	float:right;
-	margin-right: 17em;
-	margin-top:-1.3em;
-}
-
-.reports dt {
-	display:inline;
-	margin:0px;
-	padding:0px;
-}
-
-.reports dd {
-	display:inline;
-	margin:0px;
-	padding:0px;
-	padding-right:.5em;
-}
-
-.reports h2, .reports h3{
-	display:inline;
-	padding-right:.5em;
-	font-size: 14px;
-	font-weight:normal;
-}
-
-.reports div.progress {
-	display:inline;
-	float:right;
-	width:16em;
-	background:#c00 url(../images/shine.png) top left repeat-x;
-	margin:0px;
-	margin-top:-1.3em;
-	padding:0px;
-	border:none;
-}
-
-/*uniform*/
-body.results, body.reports {
-	max-width:57em ;
-	padding:0px;
-}
-
-/*Progress Bar*/
-div.progress {
-	display:block;
-	float:left;
-	width:16em;
-	background:#c00 url(../images/shine.png) top left repeat-x;
-	height:1em;
-}
-
-div.progress span {
-	height:1em;
-	float:left;
-}
-
-div.progress span.translated {
-	background:#6c3 url(../images/shine.png) top left repeat-x;
-}
-
-div.progress span.fuzzy {
-	background:#ff9f00 url(../images/shine.png) top left repeat-x;
-}
-
-
-/*Results*/
-
-.results ul {
-	list-style:none;
-	margin:0px;
-	padding:0px;
-}
-
-.results li{
-	margin:0px;
-	padding:0px;
-}
-
-.results li.odd {
-	background-color: #eeeeee;
-	margin:0px;
-	padding:0px;
-}
-
-.results dl {
-	display:inline;
-	margin:0px;
-	padding:0px;
-	float:right;
-	margin-right: 17em;
-	margin-top:-1.3em;
-}
-
-.results dt {
-	display:inline;
-	margin:0px;
-	padding:0px;
-}
-
-.results dd {
-	display:inline;
-	margin:0px;
-	padding:0px;
-	padding-right:.5em;
-}
-
-.results h2, .results h3 {
-	display:inline;
-	padding-right:.5em;
-	font-size: 14px;
-	font-weight:normal;
-}
-
-.results div.progress {
-	display:inline;
-	float:right;
-	width:16em;
-	background:#c00 url(../images/shine.png) top left repeat-x;
-	margin:0px;
-	margin-top:-1.3em;
-	padding:0px;
-	border:none;
-}
-
-/* Dirty EVIL Mozilla hack for round corners */
-pre {
-	-moz-border-radius:11px;
-	-webkit-border-radius:11px;
-	border-radius: 11px;
-/*	page-break-inside: avoid; */
-}
-
-.example {
-	-moz-border-radius:0px;
-	-webkit-border-radius:0px;
-	border-radius: 0px;
-	page-break-inside: avoid;
-}
-
-/* move these invisible fields out of the flow */
-.example > a:first-child,
-.table > a:first-child {
-    float: left;
-}
-
-.package, .citetitle {
-	font-style: italic;
-}
-
-.titlepage .edition,
-.titlepage .releaseinfo {
-	color: #336699;
-	background-color: transparent;
-	margin-top: 1em;
-	margin-bottom: 1em;
-	font-size: 20px;
-	font-weight: bold;
-	text-align: center;
-}
-
-span.remark {
-	background-color: #ff00ff;
-}
-
-.draft {
-	background-image: url(../images/watermark-draft.png);
-	background-repeat: repeat-y;
-        background-position: center;
-}
-
-.foreignphrase {
-	font-style: inherit;
-}
-
-dt {
-	clear:both;
-	page-break-inside: avoid;
-	page-break-after: avoid;
-}
-
-dt img {
-	border-style: none;
-	max-width: 112px;
-}
-
-dt object {
-	max-width: 112px;
-}
-
-dt .inlinemediaobject, dt object {
-	display: inline;
-	float: left;
-	margin-bottom: 1em;
-	padding-right: 1em;
-	width: 112px;
-}
-
-dl:after {
-	display: block;
-	clear: both;
-	content: "";
-}
-
-.toc dd {
-	padding-bottom: 0px;
-	margin-bottom: 1em;
-	padding-left: 1.3em;
-	margin-left: 0px;
-}
-
-div.toc > dl > dt {
-	padding-bottom: 0px;
-	margin-bottom: 0px;
-	margin-top: 1em;
-}
-
-
-.strikethrough {
-	text-decoration: line-through;
-}
-
-.underline {
-	text-decoration: underline;
-}
-
-.calloutlist img, .callout {
-	padding: 0px;
-	margin: 0px;
-	width: 12pt;
-	display: inline;
-	vertical-align: middle;
-}
-
-li.step > a:first-child {
-	display: block;
-}
-
-.stepalternatives {
-	list-style-image: none;
-	list-style-type: upper-alpha;
-}
-.task {
-/*	page-break-inside: avoid; */
-}
-
-
-.added {
-	background-color: #99ff99;
-}
-
-.changed {
-	background-color: #ffff77;
-}
-
-.deleted {
-	background-color: #ff4455;
-	text-decoration: line-through;
-}
diff --git a/doc/publican/sources/css/default.css b/doc/publican/sources/css/default.css
deleted file mode 100644
index bf38ebb..0000000
--- a/doc/publican/sources/css/default.css
+++ /dev/null
@@ -1,3 +0,0 @@
-@import url("common.css");
-@import url("overrides.css");
-@import url("lang.css");
diff --git a/doc/publican/sources/css/epub.css b/doc/publican/sources/css/epub.css
deleted file mode 100644
index b0ffd43..0000000
--- a/doc/publican/sources/css/epub.css
+++ /dev/null
@@ -1,115 +0,0 @@
-/*headings*/
-h1, h2, h3, h4, h5, h6,
-div.producttitle,
-div.subtitle,
-div.author div.author,
-div.translator div.translator,
-div.othercredit div.othercredit,
-div.editor div.editor,
-div.contrib div.contrib,
-.title,
-.titlepage .edition {
-}
-
-div.para {
-	margin-top: 1em;
-}
-/* inline syntax highlighting */
-.perl_Alert {
-	color: #0000ff;
-}
-
-.perl_BaseN {
-	color: #007f00;
-}
-
-.perl_BString {
-	color: #5C3566;
-}
-
-.perl_Char {
-	color: #ff00ff;
-}
-
-.perl_Comment {
-	color: #888888;
-}
-
-
-.perl_DataType {
-	color: #0000ff;
-}
-
-
-.perl_DecVal {
-	color: #00007f;
-}
-
-
-.perl_Error {
-	color: #ff0000;
-}
-
-
-.perl_Float {
-	color: #00007f;
-}
-
-
-.perl_Function {
-	color: #007f00;
-}
-
-
-.perl_IString {
-	color: #5C3566;
-}
-
-
-.perl_Keyword {
-	color: #002F5D;
-}
-
-
-.perl_Operator {
-	color: #ffa500;
-}
-
-
-.perl_Others {
-	color: #b03060;
-}
-
-
-.perl_RegionMarker {
-	color: #96b9ff;
-}
-
-
-.perl_Reserved {
-	color: #9b30ff;
-}
-
-
-.perl_String {
-	color: #5C3566;
-}
-
-
-.perl_Variable {
-	color: #0000ff;
-}
-
-
-.perl_Warning {
-	color: #0000ff;
-}
-
-b, strong {
-	font-weight: bolder;
-}
-
-code.command {
-	font-family: monospace;
-	font-weight: bolder;
-}
diff --git a/doc/publican/sources/css/print.css b/doc/publican/sources/css/print.css
deleted file mode 100644
index 54088f4..0000000
--- a/doc/publican/sources/css/print.css
+++ /dev/null
@@ -1,15 +0,0 @@
-@import url("common.css");
-@import url("overrides.css");
-@import url("lang.css");
-
-#tocframe {
-	display: none;
-}
-
-body.toc_embeded {
-	margin-left: 30px;
-}
-
-.producttitle {
-	color: #336699;
-}
diff --git a/doc/publican/sources/images/icon.svg b/doc/publican/sources/images/icon.svg
deleted file mode 100644
index b2f16d0..0000000
--- a/doc/publican/sources/images/icon.svg
+++ /dev/null
@@ -1,19 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<svg xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.0" width="32" height="32" id="svg3017">
-  <defs id="defs3019">
-    <linearGradient id="linearGradient2381">
-      <stop id="stop2383" style="stop-color:#ffffff;stop-opacity:1" offset="0"/>
-      <stop id="stop2385" style="stop-color:#ffffff;stop-opacity:0" offset="1"/>
-    </linearGradient>
-    <linearGradient x1="296.4996" y1="188.81061" x2="317.32471" y2="209.69398" id="linearGradient2371" xlink:href="#linearGradient2381" gradientUnits="userSpaceOnUse" gradientTransform="matrix(0.90776,0,0,0.90776,24.35648,49.24131)"/>
-  </defs>
-  <g transform="matrix(0.437808,-0.437808,0.437808,0.437808,-220.8237,43.55311)" id="g5089">
-    <path d="m 8.4382985,-6.28125 c -0.6073916,0 -4.3132985,5.94886271 -4.3132985,8.25 l 0,26.71875 c 0,0.846384 0.5818159,1.125 1.15625,1.125 l 25.5625,0 c 0.632342,0 1.125001,-0.492658 1.125,-1.125 l 0,-5.21875 0.28125,0 c 0.49684,0 0.906249,-0.409411 0.90625,-0.90625 l 0,-27.9375 c 0,-0.4968398 -0.40941,-0.90625 -0.90625,-0.90625 l -23.8117015,0 z" transform="translate(282.8327,227.1903)" id="path5091" style="fill:#5c5c4f;stroke:#000000;stroke-width:3.23021388;stroke-miterlimit:4;stroke-dasharray:none"/>
-    <rect width="27.85074" height="29.369793" rx="1.1414107" ry="1.1414107" x="286.96509" y="227.63805" id="rect5093" style="fill:#032c87"/>
-    <path d="m 288.43262,225.43675 25.2418,0 0,29.3698 -26.37615,0.0241 1.13435,-29.39394 z" id="rect5095" style="fill:#ffffff"/>
-    <path d="m 302.44536,251.73726 c 1.38691,7.85917 -0.69311,11.28365 -0.69311,11.28365 2.24384,-1.60762 3.96426,-3.47694 4.90522,-5.736 0.96708,2.19264 1.83294,4.42866 4.27443,5.98941 0,0 -1.59504,-7.2004 -1.71143,-11.53706 l -6.77511,0 z" id="path5097" style="fill:#a70000;fill-opacity:1;stroke-width:2"/>
-    <rect width="25.241802" height="29.736675" rx="0.89682275" ry="0.89682275" x="290.73544" y="220.92249" id="rect5099" style="fill:#809cc9"/>
-    <path d="m 576.47347,725.93939 6.37084,0.41502 0.4069,29.51809 c -1.89202,-1.31785 -6.85427,-3.7608 -8.26232,-1.68101 l 0,-26.76752 c 0,-0.82246 0.66212,-1.48458 1.48458,-1.48458 z" transform="matrix(0.499065,-0.866565,0,1,0,0)" id="rect5101" style="fill:#4573b3;fill-opacity:1"/>
-    <path d="m 293.2599,221.89363 20.73918,0 c 0.45101,0 0.8141,0.3631 0.8141,0.81411 0.21547,6.32836 -19.36824,21.7635 -22.36739,17.59717 l 0,-17.59717 c 0,-0.45101 0.3631,-0.81411 0.81411,-0.81411 z" id="path5103" style="opacity:0.65536726;fill:url(#linearGradient2371);fill-opacity:1"/>
-  </g>
-</svg>
diff --git a/doc/publican/sources/images/wayland.png b/doc/publican/sources/images/wayland.png
deleted file mode 100644
index c993792..0000000
--- a/doc/publican/sources/images/wayland.png
+++ /dev/null
diff --git a/doc/publican/sources/images/xwayland-architecture.png b/doc/publican/sources/images/xwayland-architecture.png
deleted file mode 100644
index f24dc18..0000000
--- a/doc/publican/sources/images/xwayland-architecture.png
+++ /dev/null
diff --git a/doc/publican/sources/meson.build b/doc/publican/sources/meson.build
deleted file mode 100644
index a53b389..0000000
--- a/doc/publican/sources/meson.build
+++ /dev/null
@@ -1,114 +0,0 @@
-ProtocolSpec_xml = custom_target(
-	'ProtocolSpec.xml',
-	command: [ xsltproc, '-o', '@OUTPUT@', files('../protocol-to-docbook.xsl'), '@INPUT@' ],
-	input: wayland_protocol_xml,
-	output: 'ProtocolSpec.xml'
-)
-
-ProtocolInterfaces_xml = custom_target(
-	'ProtocolInterfaces.xml',
-	command: [ xsltproc, '-o', '@OUTPUT@', files('../protocol-interfaces-to-docbook.xsl'), '@INPUT@' ],
-	input: wayland_protocol_xml,
-	output: 'ProtocolInterfaces.xml'
-)
-
-ClientAPI_combined = custom_target(
-	'ClientAPI-combined',
-	command: [ xsltproc, '-o', '@OUTPUT@', '@INPUT@' ],
-	input: [ doxygen_Client_combine_xslt, doxygen_Client_index_xml ],
-	output: 'ClientAPI-combined.xml'
-)
-
-to_publican_xsl = files('../doxygen-to-publican.xsl')
-
-ClientAPI_xml = custom_target(
-	'ClientAPI.xml',
-	command: [ xsltproc, '-o', '@OUTPUT@', '--stringparam', 'which', 'Client', to_publican_xsl, '@INPUT@' ],
-	input: ClientAPI_combined,
-	output: 'ClientAPI.xml'
-)
-
-ServerAPI_combined = custom_target(
-	'ServerAPI-combined',
-	command: [ xsltproc, '-o', '@OUTPUT@', '@INPUT@' ],
-	input: [ doxygen_Server_combine_xslt, doxygen_Server_index_xml ],
-	output: 'ServerAPI-combined.xml'
-)
-
-ServerAPI_xml = custom_target(
-	'ServerAPI.xml',
-	command: [ xsltproc, '-o', '@OUTPUT@', '--stringparam', 'which', 'Server', to_publican_xsl, '@INPUT@' ],
-	input: ServerAPI_combined,
-	output: 'ServerAPI.xml'
-)
-
-
-publican_sources = [
-	'Wayland.ent',
-	# 'Wayland.xml', # handled specially
-	'Book_Info.xml',
-	'Author_Group.xml',
-	'Foreword.xml',
-	'Preface.xml',
-	'Revision_History.xml',
-	'Protocol.xml',
-	'Xwayland.xml',
-	'Compositors.xml',
-	'Color.xml',
-	'Client.xml',
-	'Server.xml'
-]
-
-publican_processed_main = configure_file(
-	input: 'Wayland.xml',
-	output: 'Wayland.xml',
-	copy: true
-)
-
-publican_copied_sources = []
-foreach src: publican_sources
-	publican_copied_sources += configure_file(
-		input: src,
-		output: src,
-		copy: true
-	)
-endforeach
-
-publican_processed_sources = [
-	'Architecture.xml',
-	'Introduction.xml'
-]
-
-publican_processed_targets = []
-foreach src: publican_processed_sources
-	publican_processed_targets += custom_target(
-		src,
-		command: [ xsltproc, '-o', '@OUTPUT@', '--stringparam', 'basedir', '.', merge_mapcoords_xsl, '@INPUT@' ],
-		input: src,
-		output: src
-	)
-endforeach
-
-publican_css_sources = files([
-	'css/brand.css',
-	'css/common.css',
-	'css/default.css',
-	'css/epub.css',
-	'css/print.css'
-])
-
-install_data(
-	publican_css_sources,
-	install_dir: join_paths(publican_install_prefix, publican_html_dir, 'css')
-)
-
-publican_img_sources = files([
-	'images/icon.svg',
-	'images/wayland.png',
-	'images/xwayland-architecture.png'
-])
-
-install_data(
-	publican_img_sources,
-	install_dir: join_paths(publican_install_prefix, publican_html_dir, 'images')
-)