[PATCH wayland-web 2/2] gitlab-ci: Automate wayland's docs publishing

Matheus Santana embs at cin.ufpe.br
Mon Jul 16 17:08:35 UTC 2018


These changes

1. remove the `docs/` dir, which won't be necessary anymore as we'll
   build them from wayland's repo
2. build wayland in CI pipeline, providing docs as an artifact which is
   later published to GitLab pages

Also see https://gitlab.freedesktop.org/wayland/wayland/issues/48

Signed-off-by: Matheus Santana <embs at cin.ufpe.br>
---
 .gitlab-ci.yml                             |   31 +
 docs/html/Wayland.proc                     |    0
 docs/html/apa.html                         | 2051 ----------------------------
 docs/html/apb.html                         |  624 ---------
 docs/html/apc.html                         |  674 ---------
 docs/html/ch01.html                        |   73 -
 docs/html/ch02.html                        |   77 --
 docs/html/ch03.html                        |  237 ----
 docs/html/ch04.html                        |  381 ------
 docs/html/ch05.html                        |  120 --
 docs/html/css/brand.css                    |   14 -
 docs/html/css/common.css                   | 1769 ------------------------
 docs/html/css/default.css                  |    3 -
 docs/html/css/epub.css                     |  115 --
 docs/html/css/print.css                    |   15 -
 docs/html/images/icon.svg                  |   19 -
 docs/html/images/wayland-architecture.png  |  Bin 28435 -> 0 bytes
 docs/html/images/wayland.png               |  Bin 5649 -> 0 bytes
 docs/html/images/x-architecture.png        |  Bin 32329 -> 0 bytes
 docs/html/images/xwayland-architecture.png |  Bin 7611 -> 0 bytes
 docs/html/index.html                       |   89 --
 docs/html/pr01.html                        |   15 -
 docs/html/pr02.html                        |    8 -
 23 files changed, 31 insertions(+), 6284 deletions(-)
 delete mode 100644 docs/html/Wayland.proc
 delete mode 100644 docs/html/apa.html
 delete mode 100644 docs/html/apb.html
 delete mode 100644 docs/html/apc.html
 delete mode 100644 docs/html/ch01.html
 delete mode 100644 docs/html/ch02.html
 delete mode 100644 docs/html/ch03.html
 delete mode 100644 docs/html/ch04.html
 delete mode 100644 docs/html/ch05.html
 delete mode 100644 docs/html/css/brand.css
 delete mode 100644 docs/html/css/common.css
 delete mode 100644 docs/html/css/default.css
 delete mode 100644 docs/html/css/epub.css
 delete mode 100644 docs/html/css/print.css
 delete mode 100644 docs/html/images/icon.svg
 delete mode 100644 docs/html/images/wayland-architecture.png
 delete mode 100644 docs/html/images/wayland.png
 delete mode 100644 docs/html/images/x-architecture.png
 delete mode 100644 docs/html/images/xwayland-architecture.png
 delete mode 100644 docs/html/index.html
 delete mode 100644 docs/html/pr01.html
 delete mode 100644 docs/html/pr02.html

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 0e69f62..3d33881 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -24,6 +24,37 @@ libinput:
     # libinput's .gitlab-ci.yml has the list of ARCH_PKGS, copied from there
     ARCH_PKGS:   'git gcc         pkgconfig          meson check       libsystemd    libevdev       doxygen graphviz valgrind binutils libwacom                     gtk3                        mtdev      '
 
+wayland:
+  image: debian:stretch
+  stage: build
+  before_script:
+  - echo 'path-exclude=/usr/share/doc/*' > /etc/dpkg/dpkg.cfg.d/99-exclude-cruft
+  - echo 'path-exclude=/usr/share/man/*' >> /etc/dpkg/dpkg.cfg.d/99-exclude-cruft
+  - echo '#!/bin/sh' > /usr/sbin/policy-rc.d
+  - echo 'exit 101' >> /usr/sbin/policy-rc.d
+  - chmod +x /usr/sbin/policy-rc.d
+  - apt-get update
+  - apt-get -y --no-install-recommends install build-essential automake autoconf libtool pkg-config libexpat1-dev libffi-dev libxml2-dev doxygen graphviz xmlto xsltproc docbook-xsl git ca-certificates
+  script:
+  - git clone https://gitlab.freedesktop.org/embs/wayland.git wayland.git
+  - pushd wayland.git
+  - export BUILD_ID="wayland-$CI_JOB_NAME_$CI_COMMIT_SHA-$CI_JOB_ID"
+  - export PREFIX="$(pwd)/prefix-$BUILD_ID"
+  - export BUILDDIR="$(pwd)/build-$BUILD_ID"
+  - export MAKEFLAGS="-j4"
+  - mkdir "$BUILDDIR" "$PREFIX"
+  - cd "$BUILDDIR"
+  - ../autogen.sh --prefix="$PREFIX" --with-icondir=/usr/share/X11/icons
+  - make all
+  - make check
+  - make install
+  - make distcheck
+  - popd
+  - mv $PREFIX/share/doc/wayland/Wayland/en-US/html docs/
+  artifacts:
+    paths:
+    - docs/html
+
 pages:
   stage: deploy
   script:
diff --git a/docs/html/Wayland.proc b/docs/html/Wayland.proc
deleted file mode 100644
index e69de29..0000000
diff --git a/docs/html/apa.html b/docs/html/apa.html
deleted file mode 100644
index efe03c9..0000000
--- a/docs/html/apa.html
+++ /dev/null
@@ -1,2051 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Appendix A. Wayland Protocol Specification</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="ch05.html" title="Chapter 5. X11 Application Support"><link rel="next" href="apb.html" title="Appendix B. Client API"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix A. Wayland Protocol Specification</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch05.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="apb.html">Next</a></td></tr></table><hr></div><div class="appendix"><div class="titlepage"><div><div><h1 class="title"><a name="appe-Wayland-Protocol"></a>Appendix A. Wayland Protocol Specification</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="apa.html#protocol-spec-wl_display">wl_display
-	- core global object</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_registry">wl_registry
-	- global registry object</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_callback">wl_callback
-	- callback object</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_compositor">wl_compositor
-	- the compositor singleton</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_shm_pool">wl_shm_pool
-	- a shared memory pool</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_shm">wl_shm
-	- shared memory support</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_buffer">wl_buffer
-	- content for a wl_surface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_data_offer">wl_data_offer
-	- offer to transfer data</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_data_source">wl_data_source
-	- offer to transfer data</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_data_device">wl_data_device
-	- data transfer device</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_data_device_manager">wl_data_device_manager
-	- data transfer interface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_shell">wl_shell
-	- create desktop-style surfaces</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_shell_surface">wl_shell_surface
-	- desktop-style metadata interface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_surface">wl_surface
-	- an onscreen surface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_seat">wl_seat
-	- group of input devices</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_pointer">wl_pointer
-	- pointer input device</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_keyboard">wl_keyboard
-	- keyboard input device</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_touch">wl_touch
-	- touchscreen input device</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_output">wl_output
-	- compositor output region</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_region">wl_region
-	- region interface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_subcompositor">wl_subcompositor
-	- sub-surface compositing</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_subsurface">wl_subsurface
-	- sub-surface interface to a wl_surface</a></span></dt></dl></div><p>
-    </p><div class="literallayout"><p><br>
-    Copyright © 2008-2011 Kristian Høgsberg<br>
-    Copyright © 2010-2011 Intel Corporation<br>
-    Copyright © 2012-2013 Collabora, Ltd.<br>
-<br>
-    Permission is hereby granted, free of charge, to any person<br>
-    obtaining a copy of this software and associated documentation files<br>
-    (the "Software"), to deal in the Software without restriction,<br>
-    including without limitation the rights to use, copy, modify, merge,<br>
-    publish, distribute, sublicense, and/or sell copies of the Software,<br>
-    and to permit persons to whom the Software is furnished to do so,<br>
-    subject to the following conditions:<br>
-<br>
-    The above copyright notice and this permission notice (including the<br>
-    next paragraph) shall be included in all copies or substantial<br>
-    portions of the Software.<br>
-<br>
-    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,<br>
-    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF<br>
-    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND<br>
-    NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS<br>
-    BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN<br>
-    ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN<br>
-    CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE<br>
-    SOFTWARE.<br>
-  </p></div><p>
-  </p><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_display"></a>wl_display
-	- core global object</h2></div></div></div><p>
-      The core global object.  This is a special singleton object.  It
-      is used for internal Wayland protocol features.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152828142992"></a>Requests provided by wl_display</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_display-request-sync"></a>wl_display::sync
-        - asynchronous roundtrip</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">callback</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_callback" title="wl_callback - callback object">wl_callback</a>
-            - callback object for the sync request</dd></dl></div><p>
-        </p><p>
-	The sync request asks the server to emit the 'done' event
-	on the returned wl_callback object.  Since requests are
-	handled in-order and events are delivered in-order, this can
-	be used as a barrier to ensure all previous requests and the
-	resulting events have been handled.</p><p>	The object returned by this request will be destroyed by the
-	compositor after the callback is fired and as such the client must not
-	attempt to use it after that point.</p><p>	The callback_data passed in the callback is the event serial.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_display-request-get_registry"></a>wl_display::get_registry
-        - get global registry object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">registry</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_registry" title="wl_registry - global registry object">wl_registry</a>
-            - global registry object</dd></dl></div><p>
-        </p><p>
-	This request creates a registry object that allows the client
-	to list and bind the global objects available from the
-	compositor.</p><p>	It should be noted that the server side resources consumed in
-	response to a get_registry request can only be released when the
-	client disconnects, not when the client side proxy is destroyed.
-	Therefore, clients should invoke get_registry as infrequently as
-	possible to avoid wasting memory.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152827919648"></a>Events provided by wl_display</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_display-event-error"></a>wl_display::error
-        - fatal error event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">object_id</span></dt><dd>object
-            - object where the error occurred</dd><dt><span class="term">code</span></dt><dd>uint
-            - error code</dd><dt><span class="term">message</span></dt><dd>string
-            - error description</dd></dl></div><p>
-        </p><p>
-	The error event is sent out when a fatal (non-recoverable)
-	error has occurred.  The object_id argument is the object
-	where the error occurred, most often in response to a request
-	to that object.  The code identifies the error and is defined
-	by the object interface.  As such, each interface defines its
-	own set of error codes.  The message is a brief description
-	of the error, for (debugging) convenience.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_display-event-delete_id"></a>wl_display::delete_id
-        - acknowledge object ID deletion</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>uint
-            - deleted object ID</dd></dl></div><p>
-        </p><p>
-	This event is used internally by the object ID management
-	logic.  When a client deletes an object, the server will send
-	this event to acknowledge that it has seen the delete request.
-	When the client receives this event, it will know that it can
-	safely reuse the object ID.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152826386080"></a>Enums provided by wl_display</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_display-enum-error"></a>wl_display::error
-        - global error values</h4></div></div></div><p>
-	These errors are global and can be emitted in response to any
-	server request.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">invalid_object</span></dt><dd>0
-          - server couldn't find object</dd><dt><span class="term">invalid_method</span></dt><dd>1
-          - method doesn't exist on the specified interface</dd><dt><span class="term">no_memory</span></dt><dd>2
-          - server is out of memory</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_registry"></a>wl_registry
-	- global registry object</h2></div></div></div><p>
-      The singleton global registry object.  The server has a number of
-      global objects that are available to all clients.  These objects
-      typically represent an actual object in the server (for example,
-      an input device) or they are singleton objects that provide
-      extension functionality.</p><p>      When a client creates a registry object, the registry object
-      will emit a global event for each global currently in the
-      registry.  Globals come and go as a result of device or
-      monitor hotplugs, reconfiguration or other events, and the
-      registry will send out global and global_remove events to
-      keep the client up to date with the changes.  To mark the end
-      of the initial burst of events, the client can use the
-      wl_display.sync request immediately after calling
-      wl_display.get_registry.</p><p>      A client can bind to a global object by using the bind
-      request.  This creates a client-side handle that lets the object
-      emit events to the client and lets the client invoke requests on
-      the object.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152826374944"></a>Requests provided by wl_registry</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_registry-request-bind"></a>wl_registry::bind
-        - bind an object to the display</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">name</span></dt><dd>uint
-            - unique numeric name of the object</dd><dt><span class="term">id</span></dt><dd>new_id
-            - bounded object</dd></dl></div><p>
-        </p><p>
-	Binds a new, client-created object to the server using the
-	specified name as the identifier.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152836816304"></a>Events provided by wl_registry</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_registry-event-global"></a>wl_registry::global
-        - announce global object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">name</span></dt><dd>uint
-            - numeric name of the global object</dd><dt><span class="term">interface</span></dt><dd>string
-            - interface implemented by the object</dd><dt><span class="term">version</span></dt><dd>uint
-            - interface version</dd></dl></div><p>
-        </p><p>
-	Notify the client of global objects.</p><p>	The event notifies the client that a global object with
-	the given name is now available, and it implements the
-	given version of the given interface.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_registry-event-global_remove"></a>wl_registry::global_remove
-        - announce removal of global object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">name</span></dt><dd>uint
-            - numeric name of the global object</dd></dl></div><p>
-        </p><p>
-	Notify the client of removed global objects.</p><p>	This event notifies the client that the global identified
-	by name is no longer available.  If the client bound to
-	the global using the bind request, the client should now
-	destroy that object.</p><p>	The object remains valid and requests to the object will be
-	ignored until the client destroys it, to avoid races between
-	the global going away and a client sending a request to it.
-      </p></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_callback"></a>wl_callback
-	- callback object</h2></div></div></div><p>
-      Clients can handle the 'done' event to get notified when
-      the related request is done.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152823464544"></a>Events provided by wl_callback</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_callback-event-done"></a>wl_callback::done
-        - done event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">callback_data</span></dt><dd>uint
-            - request-specific data for the callback</dd></dl></div><p>
-        </p><p>
-	Notify the client when the related request is done.
-      </p></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_compositor"></a>wl_compositor
-	- the compositor singleton</h2></div></div></div><p>
-      A compositor.  This object is a singleton global.  The
-      compositor is in charge of combining the contents of multiple
-      surfaces into one displayable output.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152823457456"></a>Requests provided by wl_compositor</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_compositor-request-create_surface"></a>wl_compositor::create_surface
-        - create new surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - the new surface</dd></dl></div><p>
-        </p><p>
-	Ask the compositor to create a new surface.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_compositor-request-create_region"></a>wl_compositor::create_region
-        - create new region</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_region" title="wl_region - region interface">wl_region</a>
-            - the new region</dd></dl></div><p>
-        </p><p>
-	Ask the compositor to create a new region.
-      </p></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_shm_pool"></a>wl_shm_pool
-	- a shared memory pool</h2></div></div></div><p>
-      The wl_shm_pool object encapsulates a piece of memory shared
-      between the compositor and client.  Through the wl_shm_pool
-      object, the client can allocate shared memory wl_buffer objects.
-      All objects created through the same pool share the same
-      underlying mapped memory. Reusing the mapped memory avoids the
-      setup/teardown overhead and is useful when interactively resizing
-      a surface or for many small buffers.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152823444512"></a>Requests provided by wl_shm_pool</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shm_pool-request-create_buffer"></a>wl_shm_pool::create_buffer
-        - create a buffer from the pool</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_buffer" title="wl_buffer - content for a wl_surface">wl_buffer</a>
-            - buffer to create</dd><dt><span class="term">offset</span></dt><dd>int
-            - buffer byte offset within the pool</dd><dt><span class="term">width</span></dt><dd>int
-            - buffer width, in pixels</dd><dt><span class="term">height</span></dt><dd>int
-            - buffer height, in pixels</dd><dt><span class="term">stride</span></dt><dd>int
-            - number of bytes from the beginning of one row to the beginning of the next row</dd><dt><span class="term">format</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_shm-enum-format" title="wl_shm::format - pixel formats">wl_shm::format</a>
-          (uint)
-          
-            - buffer pixel format</dd></dl></div><p>
-        </p><p>
-	Create a wl_buffer object from the pool.</p><p>	The buffer is created offset bytes into the pool and has
-	width and height as specified.  The stride argument specifies
-	the number of bytes from the beginning of one row to the beginning
-	of the next.  The format is the pixel format of the buffer and
-	must be one of those advertised through the wl_shm.format event.</p><p>	A buffer will keep a reference to the pool it was created from
-	so it is valid to destroy the pool immediately after creating
-	a buffer from it.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shm_pool-request-destroy"></a>wl_shm_pool::destroy
-        - destroy the pool</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Destroy the shared memory pool.</p><p>	The mmapped memory will be released when all
-	buffers that have been created from this pool
-	are gone.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shm_pool-request-resize"></a>wl_shm_pool::resize
-        - change the size of the pool mapping</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">size</span></dt><dd>int
-            - new size of the pool, in bytes</dd></dl></div><p>
-        </p><p>
-	This request will cause the server to remap the backing memory
-	for the pool from the file descriptor passed when the pool was
-	created, but using the new size.  This request can only be
-	used to make the pool bigger.
-      </p></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_shm"></a>wl_shm
-	- shared memory support</h2></div></div></div><p>
-      A singleton global object that provides support for shared
-      memory.</p><p>      Clients can create wl_shm_pool objects using the create_pool
-      request.</p><p>      At connection setup time, the wl_shm object emits one or more
-      format events to inform clients about the valid pixel formats
-      that can be used for buffers.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152821399168"></a>Requests provided by wl_shm</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shm-request-create_pool"></a>wl_shm::create_pool
-        - create a shm pool</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_shm_pool" title="wl_shm_pool - a shared memory pool">wl_shm_pool</a>
-            - pool to create</dd><dt><span class="term">fd</span></dt><dd>fd
-            - file descriptor for the pool</dd><dt><span class="term">size</span></dt><dd>int
-            - pool size, in bytes</dd></dl></div><p>
-        </p><p>
-	Create a new wl_shm_pool object.</p><p>	The pool can be used to create shared memory based buffer
-	objects.  The server will mmap size bytes of the passed file
-	descriptor, to use as backing memory for the pool.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152822532016"></a>Events provided by wl_shm</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shm-event-format"></a>wl_shm::format
-        - pixel format description</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">format</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_shm-enum-format" title="wl_shm::format - pixel formats">wl_shm::format</a>
-          (uint)
-          
-            - buffer pixel format</dd></dl></div><p>
-        </p><p>
-	Informs the client about a valid pixel format that
-	can be used for buffers. Known formats include
-	argb8888 and xrgb8888.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152822526032"></a>Enums provided by wl_shm</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shm-enum-error"></a>wl_shm::error
-        - wl_shm error values</h4></div></div></div><p>
-	These errors can be emitted in response to wl_shm requests.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">invalid_format</span></dt><dd>0
-          - buffer format is not known</dd><dt><span class="term">invalid_stride</span></dt><dd>1
-          - invalid size or stride during pool or buffer creation</dd><dt><span class="term">invalid_fd</span></dt><dd>2
-          - mmapping the file descriptor failed</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shm-enum-format"></a>wl_shm::format
-        - pixel formats</h4></div></div></div><p>
-	This describes the memory layout of an individual pixel.</p><p>	All renderers should support argb8888 and xrgb8888 but any other
-	formats are optional and may not be supported by the particular
-	renderer in use.</p><p>	The drm format codes match the macros defined in drm_fourcc.h.
-	The formats actually supported by the compositor will be
-	reported by the format event.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">argb8888</span></dt><dd>0
-          - 32-bit ARGB format, [31:0] A:R:G:B 8:8:8:8 little endian</dd><dt><span class="term">xrgb8888</span></dt><dd>1
-          - 32-bit RGB format, [31:0] x:R:G:B 8:8:8:8 little endian</dd><dt><span class="term">c8</span></dt><dd>0x20203843
-          - 8-bit color index format, [7:0] C</dd><dt><span class="term">rgb332</span></dt><dd>0x38424752
-          - 8-bit RGB format, [7:0] R:G:B 3:3:2</dd><dt><span class="term">bgr233</span></dt><dd>0x38524742
-          - 8-bit BGR format, [7:0] B:G:R 2:3:3</dd><dt><span class="term">xrgb4444</span></dt><dd>0x32315258
-          - 16-bit xRGB format, [15:0] x:R:G:B 4:4:4:4 little endian</dd><dt><span class="term">xbgr4444</span></dt><dd>0x32314258
-          - 16-bit xBGR format, [15:0] x:B:G:R 4:4:4:4 little endian</dd><dt><span class="term">rgbx4444</span></dt><dd>0x32315852
-          - 16-bit RGBx format, [15:0] R:G:B:x 4:4:4:4 little endian</dd><dt><span class="term">bgrx4444</span></dt><dd>0x32315842
-          - 16-bit BGRx format, [15:0] B:G:R:x 4:4:4:4 little endian</dd><dt><span class="term">argb4444</span></dt><dd>0x32315241
-          - 16-bit ARGB format, [15:0] A:R:G:B 4:4:4:4 little endian</dd><dt><span class="term">abgr4444</span></dt><dd>0x32314241
-          - 16-bit ABGR format, [15:0] A:B:G:R 4:4:4:4 little endian</dd><dt><span class="term">rgba4444</span></dt><dd>0x32314152
-          - 16-bit RBGA format, [15:0] R:G:B:A 4:4:4:4 little endian</dd><dt><span class="term">bgra4444</span></dt><dd>0x32314142
-          - 16-bit BGRA format, [15:0] B:G:R:A 4:4:4:4 little endian</dd><dt><span class="term">xrgb1555</span></dt><dd>0x35315258
-          - 16-bit xRGB format, [15:0] x:R:G:B 1:5:5:5 little endian</dd><dt><span class="term">xbgr1555</span></dt><dd>0x35314258
-          - 16-bit xBGR 1555 format, [15:0] x:B:G:R 1:5:5:5 little endian</dd><dt><span class="term">rgbx5551</span></dt><dd>0x35315852
-          - 16-bit RGBx 5551 format, [15:0] R:G:B:x 5:5:5:1 little endian</dd><dt><span class="term">bgrx5551</span></dt><dd>0x35315842
-          - 16-bit BGRx 5551 format, [15:0] B:G:R:x 5:5:5:1 little endian</dd><dt><span class="term">argb1555</span></dt><dd>0x35315241
-          - 16-bit ARGB 1555 format, [15:0] A:R:G:B 1:5:5:5 little endian</dd><dt><span class="term">abgr1555</span></dt><dd>0x35314241
-          - 16-bit ABGR 1555 format, [15:0] A:B:G:R 1:5:5:5 little endian</dd><dt><span class="term">rgba5551</span></dt><dd>0x35314152
-          - 16-bit RGBA 5551 format, [15:0] R:G:B:A 5:5:5:1 little endian</dd><dt><span class="term">bgra5551</span></dt><dd>0x35314142
-          - 16-bit BGRA 5551 format, [15:0] B:G:R:A 5:5:5:1 little endian</dd><dt><span class="term">rgb565</span></dt><dd>0x36314752
-          - 16-bit RGB 565 format, [15:0] R:G:B 5:6:5 little endian</dd><dt><span class="term">bgr565</span></dt><dd>0x36314742
-          - 16-bit BGR 565 format, [15:0] B:G:R 5:6:5 little endian</dd><dt><span class="term">rgb888</span></dt><dd>0x34324752
-          - 24-bit RGB format, [23:0] R:G:B little endian</dd><dt><span class="term">bgr888</span></dt><dd>0x34324742
-          - 24-bit BGR format, [23:0] B:G:R little endian</dd><dt><span class="term">xbgr8888</span></dt><dd>0x34324258
-          - 32-bit xBGR format, [31:0] x:B:G:R 8:8:8:8 little endian</dd><dt><span class="term">rgbx8888</span></dt><dd>0x34325852
-          - 32-bit RGBx format, [31:0] R:G:B:x 8:8:8:8 little endian</dd><dt><span class="term">bgrx8888</span></dt><dd>0x34325842
-          - 32-bit BGRx format, [31:0] B:G:R:x 8:8:8:8 little endian</dd><dt><span class="term">abgr8888</span></dt><dd>0x34324241
-          - 32-bit ABGR format, [31:0] A:B:G:R 8:8:8:8 little endian</dd><dt><span class="term">rgba8888</span></dt><dd>0x34324152
-          - 32-bit RGBA format, [31:0] R:G:B:A 8:8:8:8 little endian</dd><dt><span class="term">bgra8888</span></dt><dd>0x34324142
-          - 32-bit BGRA format, [31:0] B:G:R:A 8:8:8:8 little endian</dd><dt><span class="term">xrgb2101010</span></dt><dd>0x30335258
-          - 32-bit xRGB format, [31:0] x:R:G:B 2:10:10:10 little endian</dd><dt><span class="term">xbgr2101010</span></dt><dd>0x30334258
-          - 32-bit xBGR format, [31:0] x:B:G:R 2:10:10:10 little endian</dd><dt><span class="term">rgbx1010102</span></dt><dd>0x30335852
-          - 32-bit RGBx format, [31:0] R:G:B:x 10:10:10:2 little endian</dd><dt><span class="term">bgrx1010102</span></dt><dd>0x30335842
-          - 32-bit BGRx format, [31:0] B:G:R:x 10:10:10:2 little endian</dd><dt><span class="term">argb2101010</span></dt><dd>0x30335241
-          - 32-bit ARGB format, [31:0] A:R:G:B 2:10:10:10 little endian</dd><dt><span class="term">abgr2101010</span></dt><dd>0x30334241
-          - 32-bit ABGR format, [31:0] A:B:G:R 2:10:10:10 little endian</dd><dt><span class="term">rgba1010102</span></dt><dd>0x30334152
-          - 32-bit RGBA format, [31:0] R:G:B:A 10:10:10:2 little endian</dd><dt><span class="term">bgra1010102</span></dt><dd>0x30334142
-          - 32-bit BGRA format, [31:0] B:G:R:A 10:10:10:2 little endian</dd><dt><span class="term">yuyv</span></dt><dd>0x56595559
-          - packed YCbCr format, [31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian</dd><dt><span class="term">yvyu</span></dt><dd>0x55595659
-          - packed YCbCr format, [31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian</dd><dt><span class="term">uyvy</span></dt><dd>0x59565955
-          - packed YCbCr format, [31:0] Y1:Cr0:Y0:Cb0 8:8:8:8 little endian</dd><dt><span class="term">vyuy</span></dt><dd>0x59555956
-          - packed YCbCr format, [31:0] Y1:Cb0:Y0:Cr0 8:8:8:8 little endian</dd><dt><span class="term">ayuv</span></dt><dd>0x56555941
-          - packed AYCbCr format, [31:0] A:Y:Cb:Cr 8:8:8:8 little endian</dd><dt><span class="term">nv12</span></dt><dd>0x3231564e
-          - 2 plane YCbCr Cr:Cb format, 2x2 subsampled Cr:Cb plane</dd><dt><span class="term">nv21</span></dt><dd>0x3132564e
-          - 2 plane YCbCr Cb:Cr format, 2x2 subsampled Cb:Cr plane</dd><dt><span class="term">nv16</span></dt><dd>0x3631564e
-          - 2 plane YCbCr Cr:Cb format, 2x1 subsampled Cr:Cb plane</dd><dt><span class="term">nv61</span></dt><dd>0x3136564e
-          - 2 plane YCbCr Cb:Cr format, 2x1 subsampled Cb:Cr plane</dd><dt><span class="term">yuv410</span></dt><dd>0x39565559
-          - 3 plane YCbCr format, 4x4 subsampled Cb (1) and Cr (2) planes</dd><dt><span class="term">yvu410</span></dt><dd>0x39555659
-          - 3 plane YCbCr format, 4x4 subsampled Cr (1) and Cb (2) planes</dd><dt><span class="term">yuv411</span></dt><dd>0x31315559
-          - 3 plane YCbCr format, 4x1 subsampled Cb (1) and Cr (2) planes</dd><dt><span class="term">yvu411</span></dt><dd>0x31315659
-          - 3 plane YCbCr format, 4x1 subsampled Cr (1) and Cb (2) planes</dd><dt><span class="term">yuv420</span></dt><dd>0x32315559
-          - 3 plane YCbCr format, 2x2 subsampled Cb (1) and Cr (2) planes</dd><dt><span class="term">yvu420</span></dt><dd>0x32315659
-          - 3 plane YCbCr format, 2x2 subsampled Cr (1) and Cb (2) planes</dd><dt><span class="term">yuv422</span></dt><dd>0x36315559
-          - 3 plane YCbCr format, 2x1 subsampled Cb (1) and Cr (2) planes</dd><dt><span class="term">yvu422</span></dt><dd>0x36315659
-          - 3 plane YCbCr format, 2x1 subsampled Cr (1) and Cb (2) planes</dd><dt><span class="term">yuv444</span></dt><dd>0x34325559
-          - 3 plane YCbCr format, non-subsampled Cb (1) and Cr (2) planes</dd><dt><span class="term">yvu444</span></dt><dd>0x34325659
-          - 3 plane YCbCr format, non-subsampled Cr (1) and Cb (2) planes</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_buffer"></a>wl_buffer
-	- content for a wl_surface</h2></div></div></div><p>
-      A buffer provides the content for a wl_surface. Buffers are
-      created through factory interfaces such as wl_drm, wl_shm or
-      similar. It has a width and a height and can be attached to a
-      wl_surface, but the mechanism by which a client provides and
-      updates the contents is defined by the buffer factory interface.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830357904"></a>Requests provided by wl_buffer</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_buffer-request-destroy"></a>wl_buffer::destroy
-        - destroy a buffer</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Destroy a buffer. If and how you need to release the backing
-	storage is defined by the buffer factory interface.</p><p>	For possible side-effects to a surface, see wl_surface.attach.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830353968"></a>Events provided by wl_buffer</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_buffer-event-release"></a>wl_buffer::release
-        - compositor releases buffer</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Sent when this wl_buffer is no longer used by the compositor.
-	The client is now free to reuse or destroy this buffer and its
-	backing storage.</p><p>	If a client receives a release event before the frame callback
-	requested in the same wl_surface.commit that attaches this
-	wl_buffer to a surface, then the client is immediately free to
-	reuse the buffer and its backing storage, and does not need a
-	second buffer for the next surface content update. Typically
-	this is possible, when the compositor maintains a copy of the
-	wl_surface contents, e.g. as a GL texture. This is an important
-	optimization for GL(ES) compositors with wl_shm clients.
-      </p></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_data_offer"></a>wl_data_offer
-	- offer to transfer data</h2></div></div></div><p>
-      A wl_data_offer represents a piece of data offered for transfer
-      by another client (the source client).  It is used by the
-      copy-and-paste and drag-and-drop mechanisms.  The offer
-      describes the different mime types that the data can be
-      converted to and provides the mechanism for transferring the
-      data directly from the source client.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830348128"></a>Requests provided by wl_data_offer</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_offer-request-accept"></a>wl_data_offer::accept
-        - accept one of the offered mime types</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the accept request</dd><dt><span class="term">mime_type</span></dt><dd>string
-            - mime type accepted by the client</dd></dl></div><p>
-        </p><p>
-	Indicate that the client can accept the given mime type, or
-	NULL for not accepted.</p><p>	For objects of version 2 or older, this request is used by the
-	client to give feedback whether the client can receive the given
-	mime type, or NULL if none is accepted; the feedback does not
-	determine whether the drag-and-drop operation succeeds or not.</p><p>	For objects of version 3 or newer, this request determines the
-	final result of the drag-and-drop operation. If the end result
-	is that no mime types were accepted, the drag-and-drop operation
-	will be cancelled and the corresponding drag source will receive
-	wl_data_source.cancelled. Clients may still use this event in
-	conjunction with wl_data_source.action for feedback.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_offer-request-receive"></a>wl_data_offer::receive
-        - request that the data is transferred</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">mime_type</span></dt><dd>string
-            - mime type desired by receiver</dd><dt><span class="term">fd</span></dt><dd>fd
-            - file descriptor for data transfer</dd></dl></div><p>
-        </p><p>
-	To transfer the offered data, the client issues this request
-	and indicates the mime type it wants to receive.  The transfer
-	happens through the passed file descriptor (typically created
-	with the pipe system call).  The source client writes the data
-	in the mime type representation requested and then closes the
-	file descriptor.</p><p>	The receiving client reads from the read end of the pipe until
-	EOF and then closes its end, at which point the transfer is
-	complete.</p><p>	This request may happen multiple times for different mime types,
-	both before and after wl_data_device.drop. Drag-and-drop destination
-	clients may preemptively fetch data or examine it more closely to
-	determine acceptance.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_offer-request-destroy"></a>wl_data_offer::destroy
-        - destroy data offer</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Destroy the data offer.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_offer-request-finish"></a>wl_data_offer::finish
-        - the offer will no longer be used</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Notifies the compositor that the drag destination successfully
-	finished the drag-and-drop operation.</p><p>	Upon receiving this request, the compositor will emit
-	wl_data_source.dnd_finished on the drag source client.</p><p>	It is a client error to perform other requests than
-	wl_data_offer.destroy after this one. It is also an error to perform
-	this request after a NULL mime type has been set in
-	wl_data_offer.accept or no action was received through
-	wl_data_offer.action.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_offer-request-set_actions"></a>wl_data_offer::set_actions
-        - set the available/preferred drag-and-drop actions</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">dnd_actions</span></dt><dd>uint
-            - actions supported by the destination client</dd><dt><span class="term">preferred_action</span></dt><dd>uint
-            - action preferred by the destination client</dd></dl></div><p>
-        </p><p>
-	Sets the actions that the destination side client supports for
-	this operation. This request may trigger the emission of
-	wl_data_source.action and wl_data_offer.action events if the compositor
-	needs to change the selected action.</p><p>	This request can be called multiple times throughout the
-	drag-and-drop operation, typically in response to wl_data_device.enter
-	or wl_data_device.motion events.</p><p>	This request determines the final result of the drag-and-drop
-	operation. If the end result is that no action is accepted,
-	the drag source will receive wl_drag_source.cancelled.</p><p>	The dnd_actions argument must contain only values expressed in the
-	wl_data_device_manager.dnd_actions enum, and the preferred_action
-	argument must only contain one of those values set, otherwise it
-	will result in a protocol error.</p><p>	While managing an "ask" action, the destination drag-and-drop client
-	may perform further wl_data_offer.receive requests, and is expected
-	to perform one last wl_data_offer.set_actions request with a preferred
-	action other than "ask" (and optionally wl_data_offer.accept) before
-	requesting wl_data_offer.finish, in order to convey the action selected
-	by the user. If the preferred action is not in the
-	wl_data_offer.source_actions mask, an error will be raised.</p><p>	If the "ask" action is dismissed (e.g. user cancellation), the client
-	is expected to perform wl_data_offer.destroy right away.</p><p>	This request can only be made on drag-and-drop offers, a protocol error
-	will be raised otherwise.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152825675600"></a>Events provided by wl_data_offer</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_offer-event-offer"></a>wl_data_offer::offer
-        - advertise offered mime type</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">mime_type</span></dt><dd>string
-            - offered mime type</dd></dl></div><p>
-        </p><p>
-	Sent immediately after creating the wl_data_offer object.  One
-	event per offered mime type.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_offer-event-source_actions"></a>wl_data_offer::source_actions
-        - notify the source-side available actions</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">source_actions</span></dt><dd>uint
-            - actions offered by the data source</dd></dl></div><p>
-        </p><p>
-	This event indicates the actions offered by the data source. It
-	will be sent right after wl_data_device.enter, or anytime the source
-	side changes its offered actions through wl_data_source.set_actions.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_offer-event-action"></a>wl_data_offer::action
-        - notify the selected action</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">dnd_action</span></dt><dd>uint
-            - action selected by the compositor</dd></dl></div><p>
-        </p><p>
-	This event indicates the action selected by the compositor after
-	matching the source/destination side actions. Only one action (or
-	none) will be offered here.</p><p>	This event can be emitted multiple times during the drag-and-drop
-	operation in response to destination side action changes through
-	wl_data_offer.set_actions.</p><p>	This event will no longer be emitted after wl_data_device.drop
-	happened on the drag-and-drop destination, the client must
-	honor the last action received, or the last preferred one set
-	through wl_data_offer.set_actions when handling an "ask" action.</p><p>	Compositors may also change the selected action on the fly, mainly
-	in response to keyboard modifier changes during the drag-and-drop
-	operation.</p><p>	The most recent action received is always the valid one. Prior to
-	receiving wl_data_device.drop, the chosen action may change (e.g.
-	due to keyboard modifiers being pressed). At the time of receiving
-	wl_data_device.drop the drag-and-drop destination must honor the
-	last action received.</p><p>	Action changes may still happen after wl_data_device.drop,
-	especially on "ask" actions, where the drag-and-drop destination
-	may choose another action afterwards. Action changes happening
-	at this stage are always the result of inter-client negotiation, the
-	compositor shall no longer be able to induce a different action.</p><p>	Upon "ask" actions, it is expected that the drag-and-drop destination
-	may potentially choose a different action and/or mime type,
-	based on wl_data_offer.source_actions and finally chosen by the
-	user (e.g. popping up a menu with the available options). The
-	final wl_data_offer.set_actions and wl_data_offer.accept requests
-	must happen before the call to wl_data_offer.finish.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152825657456"></a>Enums provided by wl_data_offer</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_offer-enum-error"></a>wl_data_offer::error</h4></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">invalid_finish</span></dt><dd>0
-          - finish request was called untimely</dd><dt><span class="term">invalid_action_mask</span></dt><dd>1
-          - action mask contains invalid values</dd><dt><span class="term">invalid_action</span></dt><dd>2
-          - action argument has an invalid value</dd><dt><span class="term">invalid_offer</span></dt><dd>3
-          - offer doesn't accept this request</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_data_source"></a>wl_data_source
-	- offer to transfer data</h2></div></div></div><p>
-      The wl_data_source object is the source side of a wl_data_offer.
-      It is created by the source client in a data transfer and
-      provides a way to describe the offered data and a way to respond
-      to requests to transfer the data.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830317984"></a>Requests provided by wl_data_source</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-request-offer"></a>wl_data_source::offer
-        - add an offered mime type</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">mime_type</span></dt><dd>string
-            - mime type offered by the data source</dd></dl></div><p>
-        </p><p>
-	This request adds a mime type to the set of mime types
-	advertised to targets.  Can be called several times to offer
-	multiple types.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-request-destroy"></a>wl_data_source::destroy
-        - destroy the data source</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Destroy the data source.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-request-set_actions"></a>wl_data_source::set_actions
-        - set the available drag-and-drop actions</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">dnd_actions</span></dt><dd>uint
-            - actions supported by the data source</dd></dl></div><p>
-        </p><p>
-	Sets the actions that the source side client supports for this
-	operation. This request may trigger wl_data_source.action and
-	wl_data_offer.action events if the compositor needs to change the
-	selected action.</p><p>	The dnd_actions argument must contain only values expressed in the
-	wl_data_device_manager.dnd_actions enum, otherwise it will result
-	in a protocol error.</p><p>	This request must be made once only, and can only be made on sources
-	used in drag-and-drop, so it must be performed before
-	wl_data_device.start_drag. Attempting to use the source other than
-	for drag-and-drop will raise a protocol error.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830304656"></a>Events provided by wl_data_source</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-event-target"></a>wl_data_source::target
-        - a target accepts an offered mime type</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">mime_type</span></dt><dd>string
-            - mime type accepted by the target</dd></dl></div><p>
-        </p><p>
-	Sent when a target accepts pointer_focus or motion events.  If
-	a target does not accept any of the offered types, type is NULL.</p><p>	Used for feedback during drag-and-drop.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-event-send"></a>wl_data_source::send
-        - send the data</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">mime_type</span></dt><dd>string
-            - mime type for the data</dd><dt><span class="term">fd</span></dt><dd>fd
-            - file descriptor for the data</dd></dl></div><p>
-        </p><p>
-	Request for data from the client.  Send the data as the
-	specified mime type over the passed file descriptor, then
-	close it.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-event-cancelled"></a>wl_data_source::cancelled
-        - selection was cancelled</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	This data source is no longer valid. There are several reasons why
-	this could happen:</p><p>	- The data source has been replaced by another data source.
-	- The drag-and-drop operation was performed, but the drop destination
-	  did not accept any of the mime types offered through
-	  wl_data_source.target.
-	- The drag-and-drop operation was performed, but the drop destination
-	  did not select any of the actions present in the mask offered through
-	  wl_data_source.action.
-	- The drag-and-drop operation was performed but didn't happen over a
-	  surface.
-	- The compositor cancelled the drag-and-drop operation (e.g. compositor
-	  dependent timeouts to avoid stale drag-and-drop transfers).</p><p>	The client should clean up and destroy this data source.</p><p>	For objects of version 2 or older, wl_data_source.cancelled will
-	only be emitted if the data source was replaced by another data
-	source.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-event-dnd_drop_performed"></a>wl_data_source::dnd_drop_performed
-        - the drag-and-drop operation physically finished</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	The user performed the drop action. This event does not indicate
-	acceptance, wl_data_source.cancelled may still be emitted afterwards
-	if the drop destination does not accept any mime type.</p><p>	However, this event might however not be received if the compositor
-	cancelled the drag-and-drop operation before this event could happen.</p><p>	Note that the data_source may still be used in the future and should
-	not be destroyed here.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-event-dnd_finished"></a>wl_data_source::dnd_finished
-        - the drag-and-drop operation concluded</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	The drop destination finished interoperating with this data
-	source, so the client is now free to destroy this data source and
-	free all associated data.</p><p>	If the action used to perform the operation was "move", the
-	source can now delete the transferred data.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-event-action"></a>wl_data_source::action
-        - notify the selected action</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">dnd_action</span></dt><dd>uint
-            - action selected by the compositor</dd></dl></div><p>
-        </p><p>
-	This event indicates the action selected by the compositor after
-	matching the source/destination side actions. Only one action (or
-	none) will be offered here.</p><p>	This event can be emitted multiple times during the drag-and-drop
-	operation, mainly in response to destination side changes through
-	wl_data_offer.set_actions, and as the data device enters/leaves
-	surfaces.</p><p>	It is only possible to receive this event after
-	wl_data_source.dnd_drop_performed if the drag-and-drop operation
-	ended in an "ask" action, in which case the final wl_data_source.action
-	event will happen immediately before wl_data_source.dnd_finished.</p><p>	Compositors may also change the selected action on the fly, mainly
-	in response to keyboard modifier changes during the drag-and-drop
-	operation.</p><p>	The most recent action received is always the valid one. The chosen
-	action may change alongside negotiation (e.g. an "ask" action can turn
-	into a "move" operation), so the effects of the final action must
-	always be applied in wl_data_offer.dnd_finished.</p><p>	Clients can trigger cursor surface changes from this point, so
-	they reflect the current action.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152827094448"></a>Enums provided by wl_data_source</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_source-enum-error"></a>wl_data_source::error</h4></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">invalid_action_mask</span></dt><dd>0
-          - action mask contains invalid values</dd><dt><span class="term">invalid_source</span></dt><dd>1
-          - source doesn't accept this request</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_data_device"></a>wl_data_device
-	- data transfer device</h2></div></div></div><p>
-      There is one wl_data_device per seat which can be obtained
-      from the global wl_data_device_manager singleton.</p><p>      A wl_data_device provides access to inter-client data transfer
-      mechanisms such as copy-and-paste and drag-and-drop.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152827085728"></a>Requests provided by wl_data_device</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-request-start_drag"></a>wl_data_device::start_drag
-        - start drag-and-drop operation</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">source</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_data_source" title="wl_data_source - offer to transfer data">wl_data_source</a>
-            - data source for the eventual transfer</dd><dt><span class="term">origin</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - surface where the drag originates</dd><dt><span class="term">icon</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - drag-and-drop icon surface</dd><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the implicit grab on the origin</dd></dl></div><p>
-        </p><p>
-	This request asks the compositor to start a drag-and-drop
-	operation on behalf of the client.</p><p>	The source argument is the data source that provides the data
-	for the eventual data transfer. If source is NULL, enter, leave
-	and motion events are sent only to the client that initiated the
-	drag and the client is expected to handle the data passing
-	internally.</p><p>	The origin surface is the surface where the drag originates and
-	the client must have an active implicit grab that matches the
-	serial.</p><p>	The icon surface is an optional (can be NULL) surface that
-	provides an icon to be moved around with the cursor.  Initially,
-	the top-left corner of the icon surface is placed at the cursor
-	hotspot, but subsequent wl_surface.attach request can move the
-	relative position. Attach requests must be confirmed with
-	wl_surface.commit as usual. The icon surface is given the role of
-	a drag-and-drop icon. If the icon surface already has another role,
-	it raises a protocol error.</p><p>	The current and pending input regions of the icon wl_surface are
-	cleared, and wl_surface.set_input_region is ignored until the
-	wl_surface is no longer used as the icon surface. When the use
-	as an icon ends, the current and pending input regions become
-	undefined, and the wl_surface is unmapped.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-request-set_selection"></a>wl_data_device::set_selection
-        - copy data to the selection</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">source</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_data_source" title="wl_data_source - offer to transfer data">wl_data_source</a>
-            - data source for the selection</dd><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the event that triggered this request</dd></dl></div><p>
-        </p><p>
-	This request asks the compositor to set the selection
-	to the data from the source on behalf of the client.</p><p>	To unset the selection, set the source to NULL.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-request-release"></a>wl_data_device::release
-        - destroy data device</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	This request destroys the data device.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830694240"></a>Events provided by wl_data_device</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-event-data_offer"></a>wl_data_device::data_offer
-        - introduce a new wl_data_offer</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_data_offer" title="wl_data_offer - offer to transfer data">wl_data_offer</a>
-            - the new data_offer object</dd></dl></div><p>
-        </p><p>
-	The data_offer event introduces a new wl_data_offer object,
-	which will subsequently be used in either the
-	data_device.enter event (for drag-and-drop) or the
-	data_device.selection event (for selections).  Immediately
-	following the data_device_data_offer event, the new data_offer
-	object will send out data_offer.offer events to describe the
-	mime types it offers.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-event-enter"></a>wl_data_device::enter
-        - initiate drag-and-drop session</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the enter event</dd><dt><span class="term">surface</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - client surface entered</dd><dt><span class="term">x</span></dt><dd>fixed
-            - surface-local x coordinate</dd><dt><span class="term">y</span></dt><dd>fixed
-            - surface-local y coordinate</dd><dt><span class="term">id</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_data_offer" title="wl_data_offer - offer to transfer data">wl_data_offer</a>
-            - source data_offer object</dd></dl></div><p>
-        </p><p>
-	This event is sent when an active drag-and-drop pointer enters
-	a surface owned by the client.  The position of the pointer at
-	enter time is provided by the x and y arguments, in surface-local
-	coordinates.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-event-leave"></a>wl_data_device::leave
-        - end drag-and-drop session</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	This event is sent when the drag-and-drop pointer leaves the
-	surface and the session ends.  The client must destroy the
-	wl_data_offer introduced at enter time at this point.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-event-motion"></a>wl_data_device::motion
-        - drag-and-drop session motion</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">time</span></dt><dd>uint
-            - timestamp with millisecond granularity</dd><dt><span class="term">x</span></dt><dd>fixed
-            - surface-local x coordinate</dd><dt><span class="term">y</span></dt><dd>fixed
-            - surface-local y coordinate</dd></dl></div><p>
-        </p><p>
-	This event is sent when the drag-and-drop pointer moves within
-	the currently focused surface. The new position of the pointer
-	is provided by the x and y arguments, in surface-local
-	coordinates.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-event-drop"></a>wl_data_device::drop
-        - end drag-and-drop session successfully</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	The event is sent when a drag-and-drop operation is ended
-	because the implicit grab is removed.</p><p>	The drag-and-drop destination is expected to honor the last action
-	received through wl_data_offer.action, if the resulting action is
-	"copy" or "move", the destination can still perform
-	wl_data_offer.receive requests, and is expected to end all
-	transfers with a wl_data_offer.finish request.</p><p>	If the resulting action is "ask", the action will not be considered
-	final. The drag-and-drop destination is expected to perform one last
-	wl_data_offer.set_actions request, or wl_data_offer.destroy in order
-	to cancel the operation.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-event-selection"></a>wl_data_device::selection
-        - advertise new selection</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_data_offer" title="wl_data_offer - offer to transfer data">wl_data_offer</a>
-            - selection data_offer object</dd></dl></div><p>
-        </p><p>
-	The selection event is sent out to notify the client of a new
-	wl_data_offer for the selection for this device.  The
-	data_device.data_offer and the data_offer.offer events are
-	sent out immediately before this event to introduce the data
-	offer object.  The selection event is sent to a client
-	immediately before receiving keyboard focus and when a new
-	selection is set while the client has keyboard focus.  The
-	data_offer is valid until a new data_offer or NULL is received
-	or until the client loses keyboard focus.  The client must
-	destroy the previous selection data_offer, if any, upon receiving
-	this event.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152821702960"></a>Enums provided by wl_data_device</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device-enum-error"></a>wl_data_device::error</h4></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">role</span></dt><dd>0
-          - given wl_surface has another role</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_data_device_manager"></a>wl_data_device_manager
-	- data transfer interface</h2></div></div></div><p>
-      The wl_data_device_manager is a singleton global object that
-      provides access to inter-client data transfer mechanisms such as
-      copy-and-paste and drag-and-drop.  These mechanisms are tied to
-      a wl_seat and this interface lets a client get a wl_data_device
-      corresponding to a wl_seat.</p><p>      Depending on the version bound, the objects created from the bound
-      wl_data_device_manager object will have different requirements for
-      functioning properly. See wl_data_source.set_actions,
-      wl_data_offer.accept and wl_data_offer.finish for details.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152821695616"></a>Requests provided by wl_data_device_manager</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device_manager-request-create_data_source"></a>wl_data_device_manager::create_data_source
-        - create a new data source</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_data_source" title="wl_data_source - offer to transfer data">wl_data_source</a>
-            - data source to create</dd></dl></div><p>
-        </p><p>
-	Create a new data source.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device_manager-request-get_data_device"></a>wl_data_device_manager::get_data_device
-        - create a new data device</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_data_device" title="wl_data_device - data transfer device">wl_data_device</a>
-            - data device to create</dd><dt><span class="term">seat</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_seat" title="wl_seat - group of input devices">wl_seat</a>
-            - seat associated with the data device</dd></dl></div><p>
-        </p><p>
-	Create a new data device for a given seat.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830934672"></a>Enums provided by wl_data_device_manager</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_data_device_manager-enum-dnd_action"></a>wl_data_device_manager::dnd_action
-        - bitfield
-      
-        - drag and drop actions</h4></div></div></div><p>
-	This is a bitmask of the available/preferred actions in a
-	drag-and-drop operation.</p><p>	In the compositor, the selected action is a result of matching the
-	actions offered by the source and destination sides.  "action" events
-	with a "none" action will be sent to both source and destination if
-	there is no match. All further checks will effectively happen on
-	(source actions ∩ destination actions).</p><p>	In addition, compositors may also pick different actions in
-	reaction to key modifiers being pressed. One common design that
-	is used in major toolkits (and the behavior recommended for
-	compositors) is:</p><p>	- If no modifiers are pressed, the first match (in bit order)
-	  will be used.
-	- Pressing Shift selects "move", if enabled in the mask.
-	- Pressing Control selects "copy", if enabled in the mask.</p><p>	Behavior beyond that is considered implementation-dependent.
-	Compositors may for example bind other modifiers (like Alt/Meta)
-	or drags initiated with other buttons than BTN_LEFT to specific
-	actions (e.g. "ask").
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">none</span></dt><dd>0
-          - no action</dd><dt><span class="term">copy</span></dt><dd>1
-          - copy action</dd><dt><span class="term">move</span></dt><dd>2
-          - move action</dd><dt><span class="term">ask</span></dt><dd>4
-          - ask action</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_shell"></a>wl_shell
-	- create desktop-style surfaces</h2></div></div></div><p>
-      This interface is implemented by servers that provide
-      desktop-style user interfaces.</p><p>      It allows clients to associate a wl_shell_surface with
-      a basic surface.</p><p>      Note! This protocol is deprecated and not intended for production use.
-      For desktop-style user interfaces, use xdg_shell.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830918960"></a>Requests provided by wl_shell</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell-request-get_shell_surface"></a>wl_shell::get_shell_surface
-        - create a shell surface from a surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_shell_surface" title="wl_shell_surface - desktop-style metadata interface">wl_shell_surface</a>
-            - shell surface to create</dd><dt><span class="term">surface</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - surface to be given the shell surface role</dd></dl></div><p>
-        </p><p>
-	Create a shell surface for an existing surface. This gives
-	the wl_surface the role of a shell surface. If the wl_surface
-	already has another role, it raises a protocol error.</p><p>	Only one shell surface can be associated with a given surface.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830909952"></a>Enums provided by wl_shell</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell-enum-error"></a>wl_shell::error</h4></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">role</span></dt><dd>0
-          - given wl_surface has another role</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_shell_surface"></a>wl_shell_surface
-	- desktop-style metadata interface</h2></div></div></div><p>
-      An interface that may be implemented by a wl_surface, for
-      implementations that provide a desktop-style user interface.</p><p>      It provides requests to treat surfaces like toplevel, fullscreen
-      or popup windows, move, resize or maximize them, associate
-      metadata like title and class, etc.</p><p>      On the server side the object is automatically destroyed when
-      the related wl_surface is destroyed. On the client side,
-      wl_shell_surface_destroy() must be called before destroying
-      the wl_surface object.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152830080656"></a>Requests provided by wl_shell_surface</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-pong"></a>wl_shell_surface::pong
-        - respond to a ping event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the ping event</dd></dl></div><p>
-        </p><p>
-	A client must respond to a ping event with a pong request or
-	the client may be deemed unresponsive.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-move"></a>wl_shell_surface::move
-        - start an interactive move</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">seat</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_seat" title="wl_seat - group of input devices">wl_seat</a>
-            - seat whose pointer is used</dd><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the implicit grab on the pointer</dd></dl></div><p>
-        </p><p>
-	Start a pointer-driven move of the surface.</p><p>	This request must be used in response to a button press event.
-	The server may ignore move requests depending on the state of
-	the surface (e.g. fullscreen or maximized).
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-resize"></a>wl_shell_surface::resize
-        - start an interactive resize</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">seat</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_seat" title="wl_seat - group of input devices">wl_seat</a>
-            - seat whose pointer is used</dd><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the implicit grab on the pointer</dd><dt><span class="term">edges</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_shell_surface-enum-resize" title="wl_shell_surface::resize - bitfield - edge values for resizing">wl_shell_surface::resize</a>
-          (uint)
-          
-            - which edge or corner is being dragged</dd></dl></div><p>
-        </p><p>
-	Start a pointer-driven resizing of the surface.</p><p>	This request must be used in response to a button press event.
-	The server may ignore resize requests depending on the state of
-	the surface (e.g. fullscreen or maximized).
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-set_toplevel"></a>wl_shell_surface::set_toplevel
-        - make the surface a toplevel surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Map the surface as a toplevel surface.</p><p>	A toplevel surface is not fullscreen, maximized or transient.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-set_transient"></a>wl_shell_surface::set_transient
-        - make the surface a transient surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">parent</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - parent surface</dd><dt><span class="term">x</span></dt><dd>int
-            - surface-local x coordinate</dd><dt><span class="term">y</span></dt><dd>int
-            - surface-local y coordinate</dd><dt><span class="term">flags</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_shell_surface-enum-transient" title="wl_shell_surface::transient - bitfield - details of transient behaviour">wl_shell_surface::transient</a>
-          (uint)
-          
-            - transient surface behavior</dd></dl></div><p>
-        </p><p>
-	Map the surface relative to an existing surface.</p><p>	The x and y arguments specify the location of the upper left
-	corner of the surface relative to the upper left corner of the
-	parent surface, in surface-local coordinates.</p><p>	The flags argument controls details of the transient behaviour.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-set_fullscreen"></a>wl_shell_surface::set_fullscreen
-        - make the surface a fullscreen surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">method</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_shell_surface-enum-fullscreen_method" title="wl_shell_surface::fullscreen_method - different method to set the surface fullscreen">wl_shell_surface::fullscreen_method</a>
-          (uint)
-          
-            - method for resolving size conflict</dd><dt><span class="term">framerate</span></dt><dd>uint
-            - framerate in mHz</dd><dt><span class="term">output</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_output" title="wl_output - compositor output region">wl_output</a>
-            - output on which the surface is to be fullscreen</dd></dl></div><p>
-        </p><p>
-	Map the surface as a fullscreen surface.</p><p>	If an output parameter is given then the surface will be made
-	fullscreen on that output. If the client does not specify the
-	output then the compositor will apply its policy - usually
-	choosing the output on which the surface has the biggest surface
-	area.</p><p>	The client may specify a method to resolve a size conflict
-	between the output size and the surface size - this is provided
-	through the method parameter.</p><p>	The framerate parameter is used only when the method is set
-	to "driver", to indicate the preferred framerate. A value of 0
-	indicates that the client does not care about framerate.  The
-	framerate is specified in mHz, that is framerate of 60000 is 60Hz.</p><p>	A method of "scale" or "driver" implies a scaling operation of
-	the surface, either via a direct scaling operation or a change of
-	the output mode. This will override any kind of output scaling, so
-	that mapping a surface with a buffer size equal to the mode can
-	fill the screen independent of buffer_scale.</p><p>	A method of "fill" means we don't scale up the buffer, however
-	any output scale is applied. This means that you may run into
-	an edge case where the application maps a buffer with the same
-	size of the output mode but buffer_scale 1 (thus making a
-	surface larger than the output). In this case it is allowed to
-	downscale the results to fit the screen.</p><p>	The compositor must reply to this request with a configure event
-	with the dimensions for the output on which the surface will
-	be made fullscreen.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-set_popup"></a>wl_shell_surface::set_popup
-        - make the surface a popup surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">seat</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_seat" title="wl_seat - group of input devices">wl_seat</a>
-            - seat whose pointer is used</dd><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the implicit grab on the pointer</dd><dt><span class="term">parent</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - parent surface</dd><dt><span class="term">x</span></dt><dd>int
-            - surface-local x coordinate</dd><dt><span class="term">y</span></dt><dd>int
-            - surface-local y coordinate</dd><dt><span class="term">flags</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_shell_surface-enum-transient" title="wl_shell_surface::transient - bitfield - details of transient behaviour">wl_shell_surface::transient</a>
-          (uint)
-          
-            - transient surface behavior</dd></dl></div><p>
-        </p><p>
-	Map the surface as a popup.</p><p>	A popup surface is a transient surface with an added pointer
-	grab.</p><p>	An existing implicit grab will be changed to owner-events mode,
-	and the popup grab will continue after the implicit grab ends
-	(i.e. releasing the mouse button does not cause the popup to
-	be unmapped).</p><p>	The popup grab continues until the window is destroyed or a
-	mouse button is pressed in any other client's window. A click
-	in any of the client's surfaces is reported as normal, however,
-	clicks in other clients' surfaces will be discarded and trigger
-	the callback.</p><p>	The x and y arguments specify the location of the upper left
-	corner of the surface relative to the upper left corner of the
-	parent surface, in surface-local coordinates.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-set_maximized"></a>wl_shell_surface::set_maximized
-        - make the surface a maximized surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">output</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_output" title="wl_output - compositor output region">wl_output</a>
-            - output on which the surface is to be maximized</dd></dl></div><p>
-        </p><p>
-	Map the surface as a maximized surface.</p><p>	If an output parameter is given then the surface will be
-	maximized on that output. If the client does not specify the
-	output then the compositor will apply its policy - usually
-	choosing the output on which the surface has the biggest surface
-	area.</p><p>	The compositor will reply with a configure event telling
-	the expected new surface size. The operation is completed
-	on the next buffer attach to this surface.</p><p>	A maximized surface typically fills the entire output it is
-	bound to, except for desktop elements such as panels. This is
-	the main difference between a maximized shell surface and a
-	fullscreen shell surface.</p><p>	The details depend on the compositor implementation.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-set_title"></a>wl_shell_surface::set_title
-        - set surface title</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">title</span></dt><dd>string
-            - surface title</dd></dl></div><p>
-        </p><p>
-	Set a short title for the surface.</p><p>	This string may be used to identify the surface in a task bar,
-	window list, or other user interface elements provided by the
-	compositor.</p><p>	The string must be encoded in UTF-8.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-request-set_class"></a>wl_shell_surface::set_class
-        - set surface class</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">class_</span></dt><dd>string
-            - surface class</dd></dl></div><p>
-        </p><p>
-	Set a class for the surface.</p><p>	The surface class identifies the general class of applications
-	to which the surface belongs. A common convention is to use the
-	file name (or the full path if it is a non-standard location) of
-	the application's .desktop file as the class.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152829324640"></a>Events provided by wl_shell_surface</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-event-ping"></a>wl_shell_surface::ping
-        - ping client</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the ping</dd></dl></div><p>
-        </p><p>
-	Ping a client to check if it is receiving events and sending
-	requests. A client is expected to reply with a pong request.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-event-configure"></a>wl_shell_surface::configure
-        - suggest resize</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">edges</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_shell_surface-enum-resize" title="wl_shell_surface::resize - bitfield - edge values for resizing">wl_shell_surface::resize</a>
-          (uint)
-          
-            - how the surface was resized</dd><dt><span class="term">width</span></dt><dd>int
-            - new width of the surface</dd><dt><span class="term">height</span></dt><dd>int
-            - new height of the surface</dd></dl></div><p>
-        </p><p>
-	The configure event asks the client to resize its surface.</p><p>	The size is a hint, in the sense that the client is free to
-	ignore it if it doesn't resize, pick a smaller size (to
-	satisfy aspect ratio or resize in steps of NxM pixels).</p><p>	The edges parameter provides a hint about how the surface
-	was resized. The client may use this information to decide
-	how to adjust its content to the new size (e.g. a scrolling
-	area might adjust its content position to leave the viewable
-	content unmoved).</p><p>	The client is free to dismiss all but the last configure
-	event it received.</p><p>	The width and height arguments specify the size of the window
-	in surface-local coordinates.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-event-popup_done"></a>wl_shell_surface::popup_done
-        - popup interaction is done</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	The popup_done event is sent out when a popup grab is broken,
-	that is, when the user clicks a surface that doesn't belong
-	to the client owning the popup surface.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152829306144"></a>Enums provided by wl_shell_surface</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-enum-resize"></a>wl_shell_surface::resize
-        - bitfield
-      
-        - edge values for resizing</h4></div></div></div><p>
-	These values are used to indicate which edge of a surface
-	is being dragged in a resize operation. The server may
-	use this information to adapt its behavior, e.g. choose
-	an appropriate cursor image.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">none</span></dt><dd>0
-          - no edge</dd><dt><span class="term">top</span></dt><dd>1
-          - top edge</dd><dt><span class="term">bottom</span></dt><dd>2
-          - bottom edge</dd><dt><span class="term">left</span></dt><dd>4
-          - left edge</dd><dt><span class="term">top_left</span></dt><dd>5
-          - top and left edges</dd><dt><span class="term">bottom_left</span></dt><dd>6
-          - bottom and left edges</dd><dt><span class="term">right</span></dt><dd>8
-          - right edge</dd><dt><span class="term">top_right</span></dt><dd>9
-          - top and right edges</dd><dt><span class="term">bottom_right</span></dt><dd>10
-          - bottom and right edges</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-enum-transient"></a>wl_shell_surface::transient
-        - bitfield
-      
-        - details of transient behaviour</h4></div></div></div><p>
-	These flags specify details of the expected behaviour
-	of transient surfaces. Used in the set_transient request.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">inactive</span></dt><dd>0x1
-          - do not set keyboard focus</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_shell_surface-enum-fullscreen_method"></a>wl_shell_surface::fullscreen_method
-        - different method to set the surface fullscreen</h4></div></div></div><p>
-	Hints to indicate to the compositor how to deal with a conflict
-	between the dimensions of the surface and the dimensions of the
-	output. The compositor is free to ignore this parameter.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">default</span></dt><dd>0
-          - no preference, apply default policy</dd><dt><span class="term">scale</span></dt><dd>1
-          - scale, preserve the surface's aspect ratio and center on output</dd><dt><span class="term">driver</span></dt><dd>2
-          - switch output mode to the smallest mode that can fit the surface, add black borders to compensate size mismatch</dd><dt><span class="term">fill</span></dt><dd>3
-          - no upscaling, center on output and add black borders to compensate size mismatch</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_surface"></a>wl_surface
-	- an onscreen surface</h2></div></div></div><p>
-      A surface is a rectangular area that is displayed on the screen.
-      It has a location, size and pixel contents.</p><p>      The size of a surface (and relative positions on it) is described
-      in surface-local coordinates, which may differ from the buffer
-      coordinates of the pixel content, in case a buffer_transform
-      or a buffer_scale is used.</p><p>      A surface without a "role" is fairly useless: a compositor does
-      not know where, when or how to present it. The role is the
-      purpose of a wl_surface. Examples of roles are a cursor for a
-      pointer (as set by wl_pointer.set_cursor), a drag icon
-      (wl_data_device.start_drag), a sub-surface
-      (wl_subcompositor.get_subsurface), and a window as defined by a
-      shell protocol (e.g. wl_shell.get_shell_surface).</p><p>      A surface can have only one role at a time. Initially a
-      wl_surface does not have a role. Once a wl_surface is given a
-      role, it is set permanently for the whole lifetime of the
-      wl_surface object. Giving the current role again is allowed,
-      unless explicitly forbidden by the relevant interface
-      specification.</p><p>      Surface roles are given by requests in other interfaces such as
-      wl_pointer.set_cursor. The request should explicitly mention
-      that this request gives a role to a wl_surface. Often, this
-      request also creates a new protocol object that represents the
-      role and adds additional functionality to wl_surface. When a
-      client wants to destroy a wl_surface, they must destroy this 'role
-      object' before the wl_surface.</p><p>      Destroying the role object does not remove the role from the
-      wl_surface, but it may stop the wl_surface from "playing the role".
-      For instance, if a wl_subsurface object is destroyed, the wl_surface
-      it was created for will be unmapped and forget its position and
-      z-order. It is allowed to create a wl_subsurface for the same
-      wl_surface again, but it is not allowed to use the wl_surface as
-      a cursor (cursor is a different role than sub-surface, and role
-      switching is not allowed).
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152821055744"></a>Requests provided by wl_surface</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-destroy"></a>wl_surface::destroy
-        - delete surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Deletes the surface and invalidates its object ID.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-attach"></a>wl_surface::attach
-        - set the surface contents</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">buffer</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_buffer" title="wl_buffer - content for a wl_surface">wl_buffer</a>
-            - buffer of surface contents</dd><dt><span class="term">x</span></dt><dd>int
-            - surface-local x coordinate</dd><dt><span class="term">y</span></dt><dd>int
-            - surface-local y coordinate</dd></dl></div><p>
-        </p><p>
-	Set a buffer as the content of this surface.</p><p>	The new size of the surface is calculated based on the buffer
-	size transformed by the inverse buffer_transform and the
-	inverse buffer_scale. This means that the supplied buffer
-	must be an integer multiple of the buffer_scale.</p><p>	The x and y arguments specify the location of the new pending
-	buffer's upper left corner, relative to the current buffer's upper
-	left corner, in surface-local coordinates. In other words, the
-	x and y, combined with the new surface size define in which
-	directions the surface's size changes.</p><p>	Surface contents are double-buffered state, see wl_surface.commit.</p><p>	The initial surface contents are void; there is no content.
-	wl_surface.attach assigns the given wl_buffer as the pending
-	wl_buffer. wl_surface.commit makes the pending wl_buffer the new
-	surface contents, and the size of the surface becomes the size
-	calculated from the wl_buffer, as described above. After commit,
-	there is no pending buffer until the next attach.</p><p>	Committing a pending wl_buffer allows the compositor to read the
-	pixels in the wl_buffer. The compositor may access the pixels at
-	any time after the wl_surface.commit request. When the compositor
-	will not access the pixels anymore, it will send the
-	wl_buffer.release event. Only after receiving wl_buffer.release,
-	the client may reuse the wl_buffer. A wl_buffer that has been
-	attached and then replaced by another attach instead of committed
-	will not receive a release event, and is not used by the
-	compositor.</p><p>	Destroying the wl_buffer after wl_buffer.release does not change
-	the surface contents. However, if the client destroys the
-	wl_buffer before receiving the wl_buffer.release event, the surface
-	contents become undefined immediately.</p><p>	If wl_surface.attach is sent with a NULL wl_buffer, the
-	following wl_surface.commit will remove the surface content.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-damage"></a>wl_surface::damage
-        - mark part of the surface damaged</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">x</span></dt><dd>int
-            - surface-local x coordinate</dd><dt><span class="term">y</span></dt><dd>int
-            - surface-local y coordinate</dd><dt><span class="term">width</span></dt><dd>int
-            - width of damage rectangle</dd><dt><span class="term">height</span></dt><dd>int
-            - height of damage rectangle</dd></dl></div><p>
-        </p><p>
-	This request is used to describe the regions where the pending
-	buffer is different from the current surface contents, and where
-	the surface therefore needs to be repainted. The compositor
-	ignores the parts of the damage that fall outside of the surface.</p><p>	Damage is double-buffered state, see wl_surface.commit.</p><p>	The damage rectangle is specified in surface-local coordinates,
-	where x and y specify the upper left corner of the damage rectangle.</p><p>	The initial value for pending damage is empty: no damage.
-	wl_surface.damage adds pending damage: the new pending damage
-	is the union of old pending damage and the given rectangle.</p><p>	wl_surface.commit assigns pending damage as the current damage,
-	and clears pending damage. The server will clear the current
-	damage as it repaints the surface.</p><p>	Alternatively, damage can be posted with wl_surface.damage_buffer
-	which uses buffer coordinates instead of surface coordinates,
-	and is probably the preferred and intuitive way of doing this.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-frame"></a>wl_surface::frame
-        - request a frame throttling hint</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">callback</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_callback" title="wl_callback - callback object">wl_callback</a>
-            - callback object for the frame request</dd></dl></div><p>
-        </p><p>
-	Request a notification when it is a good time to start drawing a new
-	frame, by creating a frame callback. This is useful for throttling
-	redrawing operations, and driving animations.</p><p>	When a client is animating on a wl_surface, it can use the 'frame'
-	request to get notified when it is a good time to draw and commit the
-	next frame of animation. If the client commits an update earlier than
-	that, it is likely that some updates will not make it to the display,
-	and the client is wasting resources by drawing too often.</p><p>	The frame request will take effect on the next wl_surface.commit.
-	The notification will only be posted for one frame unless
-	requested again. For a wl_surface, the notifications are posted in
-	the order the frame requests were committed.</p><p>	The server must send the notifications so that a client
-	will not send excessive updates, while still allowing
-	the highest possible update rate for clients that wait for the reply
-	before drawing again. The server should give some time for the client
-	to draw and commit after sending the frame callback events to let it
-	hit the next output refresh.</p><p>	A server should avoid signaling the frame callbacks if the
-	surface is not visible in any way, e.g. the surface is off-screen,
-	or completely obscured by other opaque surfaces.</p><p>	The object returned by this request will be destroyed by the
-	compositor after the callback is fired and as such the client must not
-	attempt to use it after that point.</p><p>	The callback_data passed in the callback is the current time, in
-	milliseconds, with an undefined base.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-set_opaque_region"></a>wl_surface::set_opaque_region
-        - set opaque region</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">region</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_region" title="wl_region - region interface">wl_region</a>
-            - opaque region of the surface</dd></dl></div><p>
-        </p><p>
-	This request sets the region of the surface that contains
-	opaque content.</p><p>	The opaque region is an optimization hint for the compositor
-	that lets it optimize the redrawing of content behind opaque
-	regions.  Setting an opaque region is not required for correct
-	behaviour, but marking transparent content as opaque will result
-	in repaint artifacts.</p><p>	The opaque region is specified in surface-local coordinates.</p><p>	The compositor ignores the parts of the opaque region that fall
-	outside of the surface.</p><p>	Opaque region is double-buffered state, see wl_surface.commit.</p><p>	wl_surface.set_opaque_region changes the pending opaque region.
-	wl_surface.commit copies the pending region to the current region.
-	Otherwise, the pending and current regions are never changed.</p><p>	The initial value for an opaque region is empty. Setting the pending
-	opaque region has copy semantics, and the wl_region object can be
-	destroyed immediately. A NULL wl_region causes the pending opaque
-	region to be set to empty.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-set_input_region"></a>wl_surface::set_input_region
-        - set input region</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">region</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_region" title="wl_region - region interface">wl_region</a>
-            - input region of the surface</dd></dl></div><p>
-        </p><p>
-	This request sets the region of the surface that can receive
-	pointer and touch events.</p><p>	Input events happening outside of this region will try the next
-	surface in the server surface stack. The compositor ignores the
-	parts of the input region that fall outside of the surface.</p><p>	The input region is specified in surface-local coordinates.</p><p>	Input region is double-buffered state, see wl_surface.commit.</p><p>	wl_surface.set_input_region changes the pending input region.
-	wl_surface.commit copies the pending region to the current region.
-	Otherwise the pending and current regions are never changed,
-	except cursor and icon surfaces are special cases, see
-	wl_pointer.set_cursor and wl_data_device.start_drag.</p><p>	The initial value for an input region is infinite. That means the
-	whole surface will accept input. Setting the pending input region
-	has copy semantics, and the wl_region object can be destroyed
-	immediately. A NULL wl_region causes the input region to be set
-	to infinite.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-commit"></a>wl_surface::commit
-        - commit pending surface state</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Surface state (input, opaque, and damage regions, attached buffers,
-	etc.) is double-buffered. Protocol requests modify the pending state,
-	as opposed to the current state in use by the compositor. A commit
-	request atomically applies all pending state, replacing the current
-	state. After commit, the new pending state is as documented for each
-	related request.</p><p>	On commit, a pending wl_buffer is applied first, and all other state
-	second. This means that all coordinates in double-buffered state are
-	relative to the new wl_buffer coming into use, except for
-	wl_surface.attach itself. If there is no pending wl_buffer, the
-	coordinates are relative to the current surface contents.</p><p>	All requests that need a commit to become effective are documented
-	to affect double-buffered state.</p><p>	Other interfaces may add further double-buffered surface state.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-set_buffer_transform"></a>wl_surface::set_buffer_transform
-        - sets the buffer transformation</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">transform</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_output-enum-transform" title="wl_output::transform - transform from framebuffer to output">wl_output::transform</a>
-          (int)
-          
-            - transform for interpreting buffer contents</dd></dl></div><p>
-        </p><p>
-	This request sets an optional transformation on how the compositor
-	interprets the contents of the buffer attached to the surface. The
-	accepted values for the transform parameter are the values for
-	wl_output.transform.</p><p>	Buffer transform is double-buffered state, see wl_surface.commit.</p><p>	A newly created surface has its buffer transformation set to normal.</p><p>	wl_surface.set_buffer_transform changes the pending buffer
-	transformation. wl_surface.commit copies the pending buffer
-	transformation to the current one. Otherwise, the pending and current
-	values are never changed.</p><p>	The purpose of this request is to allow clients to render content
-	according to the output transform, thus permitting the compositor to
-	use certain optimizations even if the display is rotated. Using
-	hardware overlays and scanning out a client buffer for fullscreen
-	surfaces are examples of such optimizations. Those optimizations are
-	highly dependent on the compositor implementation, so the use of this
-	request should be considered on a case-by-case basis.</p><p>	Note that if the transform value includes 90 or 270 degree rotation,
-	the width of the buffer will become the surface height and the height
-	of the buffer will become the surface width.</p><p>	If transform is not one of the values from the
-	wl_output.transform enum the invalid_transform protocol error
-	is raised.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-set_buffer_scale"></a>wl_surface::set_buffer_scale
-        - sets the buffer scaling factor</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">scale</span></dt><dd>int
-            - positive scale for interpreting buffer contents</dd></dl></div><p>
-        </p><p>
-	This request sets an optional scaling factor on how the compositor
-	interprets the contents of the buffer attached to the window.</p><p>	Buffer scale is double-buffered state, see wl_surface.commit.</p><p>	A newly created surface has its buffer scale set to 1.</p><p>	wl_surface.set_buffer_scale changes the pending buffer scale.
-	wl_surface.commit copies the pending buffer scale to the current one.
-	Otherwise, the pending and current values are never changed.</p><p>	The purpose of this request is to allow clients to supply higher
-	resolution buffer data for use on high resolution outputs. It is
-	intended that you pick the same buffer scale as the scale of the
-	output that the surface is displayed on. This means the compositor
-	can avoid scaling when rendering the surface on that output.</p><p>	Note that if the scale is larger than 1, then you have to attach
-	a buffer that is larger (by a factor of scale in each dimension)
-	than the desired surface size.</p><p>	If scale is not positive the invalid_scale protocol error is
-	raised.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-request-damage_buffer"></a>wl_surface::damage_buffer
-        - mark part of the surface damaged using buffer coordinates</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">x</span></dt><dd>int
-            - buffer-local x coordinate</dd><dt><span class="term">y</span></dt><dd>int
-            - buffer-local y coordinate</dd><dt><span class="term">width</span></dt><dd>int
-            - width of damage rectangle</dd><dt><span class="term">height</span></dt><dd>int
-            - height of damage rectangle</dd></dl></div><p>
-        </p><p>
-	This request is used to describe the regions where the pending
-	buffer is different from the current surface contents, and where
-	the surface therefore needs to be repainted. The compositor
-	ignores the parts of the damage that fall outside of the surface.</p><p>	Damage is double-buffered state, see wl_surface.commit.</p><p>	The damage rectangle is specified in buffer coordinates,
-	where x and y specify the upper left corner of the damage rectangle.</p><p>	The initial value for pending damage is empty: no damage.
-	wl_surface.damage_buffer adds pending damage: the new pending
-	damage is the union of old pending damage and the given rectangle.</p><p>	wl_surface.commit assigns pending damage as the current damage,
-	and clears pending damage. The server will clear the current
-	damage as it repaints the surface.</p><p>	This request differs from wl_surface.damage in only one way - it
-	takes damage in buffer coordinates instead of surface-local
-	coordinates. While this generally is more intuitive than surface
-	coordinates, it is especially desirable when using wp_viewport
-	or when a drawing library (like EGL) is unaware of buffer scale
-	and buffer transform.</p><p>	Note: Because buffer transformation changes and damage requests may
-	be interleaved in the protocol stream, it is impossible to determine
-	the actual mapping between surface and buffer damage until
-	wl_surface.commit time. Therefore, compositors wishing to take both
-	kinds of damage into account will have to accumulate damage from the
-	two requests separately and only transform from one to the other
-	after receiving the wl_surface.commit.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152828894240"></a>Events provided by wl_surface</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-event-enter"></a>wl_surface::enter
-        - surface enters an output</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">output</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_output" title="wl_output - compositor output region">wl_output</a>
-            - output entered by the surface</dd></dl></div><p>
-        </p><p>
-	This is emitted whenever a surface's creation, movement, or resizing
-	results in some part of it being within the scanout region of an
-	output.</p><p>	Note that a surface may be overlapping with zero or more outputs.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-event-leave"></a>wl_surface::leave
-        - surface leaves an output</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">output</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_output" title="wl_output - compositor output region">wl_output</a>
-            - output left by the surface</dd></dl></div><p>
-        </p><p>
-	This is emitted whenever a surface's creation, movement, or resizing
-	results in it no longer having any part of it within the scanout region
-	of an output.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152828882768"></a>Enums provided by wl_surface</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_surface-enum-error"></a>wl_surface::error
-        - wl_surface error values</h4></div></div></div><p>
-	These errors can be emitted in response to wl_surface requests.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">invalid_scale</span></dt><dd>0
-          - buffer scale value is invalid</dd><dt><span class="term">invalid_transform</span></dt><dd>1
-          - buffer transform value is invalid</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_seat"></a>wl_seat
-	- group of input devices</h2></div></div></div><p>
-      A seat is a group of keyboards, pointer and touch devices. This
-      object is published as a global during start up, or when such a
-      device is hot plugged.  A seat typically has a pointer and
-      maintains a keyboard focus and a pointer focus.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152828874304"></a>Requests provided by wl_seat</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_seat-request-get_pointer"></a>wl_seat::get_pointer
-        - return pointer object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_pointer" title="wl_pointer - pointer input device">wl_pointer</a>
-            - seat pointer</dd></dl></div><p>
-        </p><p>
-	The ID provided will be initialized to the wl_pointer interface
-	for this seat.</p><p>	This request only takes effect if the seat has the pointer
-	capability, or has had the pointer capability in the past.
-	It is a protocol violation to issue this request on a seat that has
-	never had the pointer capability.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_seat-request-get_keyboard"></a>wl_seat::get_keyboard
-        - return keyboard object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_keyboard" title="wl_keyboard - keyboard input device">wl_keyboard</a>
-            - seat keyboard</dd></dl></div><p>
-        </p><p>
-	The ID provided will be initialized to the wl_keyboard interface
-	for this seat.</p><p>	This request only takes effect if the seat has the keyboard
-	capability, or has had the keyboard capability in the past.
-	It is a protocol violation to issue this request on a seat that has
-	never had the keyboard capability.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_seat-request-get_touch"></a>wl_seat::get_touch
-        - return touch object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_touch" title="wl_touch - touchscreen input device">wl_touch</a>
-            - seat touch interface</dd></dl></div><p>
-        </p><p>
-	The ID provided will be initialized to the wl_touch interface
-	for this seat.</p><p>	This request only takes effect if the seat has the touch
-	capability, or has had the touch capability in the past.
-	It is a protocol violation to issue this request on a seat that has
-	never had the touch capability.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_seat-request-release"></a>wl_seat::release
-        - release the seat object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Using this request a client can tell the server that it is not going to
-	use the seat object anymore.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152823968240"></a>Events provided by wl_seat</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_seat-event-capabilities"></a>wl_seat::capabilities
-        - seat capabilities changed</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">capabilities</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_seat-enum-capability" title="wl_seat::capability - bitfield - seat capability bitmask">wl_seat::capability</a>
-          (uint)
-          
-            - capabilities of the seat</dd></dl></div><p>
-        </p><p>
-	This is emitted whenever a seat gains or loses the pointer,
-	keyboard or touch capabilities.  The argument is a capability
-	enum containing the complete set of capabilities this seat has.</p><p>	When the pointer capability is added, a client may create a
-	wl_pointer object using the wl_seat.get_pointer request. This object
-	will receive pointer events until the capability is removed in the
-	future.</p><p>	When the pointer capability is removed, a client should destroy the
-	wl_pointer objects associated with the seat where the capability was
-	removed, using the wl_pointer.release request. No further pointer
-	events will be received on these objects.</p><p>	In some compositors, if a seat regains the pointer capability and a
-	client has a previously obtained wl_pointer object of version 4 or
-	less, that object may start sending pointer events again. This
-	behavior is considered a misinterpretation of the intended behavior
-	and must not be relied upon by the client. wl_pointer objects of
-	version 5 or later must not send events if created before the most
-	recent event notifying the client of an added pointer capability.</p><p>	The above behavior also applies to wl_keyboard and wl_touch with the
-	keyboard and touch capabilities, respectively.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_seat-event-name"></a>wl_seat::name
-        - unique identifier for this seat</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">name</span></dt><dd>string
-            - seat identifier</dd></dl></div><p>
-        </p><p>
-	In a multiseat configuration this can be used by the client to help
-	identify which physical devices the seat represents. Based on
-	the seat configuration used by the compositor.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152823954944"></a>Enums provided by wl_seat</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_seat-enum-capability"></a>wl_seat::capability
-        - bitfield
-      
-        - seat capability bitmask</h4></div></div></div><p>
-	This is a bitmask of capabilities this seat has; if a member is
-	set, then it is present on the seat.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pointer</span></dt><dd>1
-          - the seat has pointer devices</dd><dt><span class="term">keyboard</span></dt><dd>2
-          - the seat has one or more keyboards</dd><dt><span class="term">touch</span></dt><dd>4
-          - the seat has touch devices</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_pointer"></a>wl_pointer
-	- pointer input device</h2></div></div></div><p>
-      The wl_pointer interface represents one or more input devices,
-      such as mice, which control the pointer location and pointer_focus
-      of a seat.</p><p>      The wl_pointer interface generates motion, enter and leave
-      events for the surfaces that the pointer is located over,
-      and button and axis events for button presses, button releases
-      and scrolling.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152823943968"></a>Requests provided by wl_pointer</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-request-set_cursor"></a>wl_pointer::set_cursor
-        - set the pointer surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the enter event</dd><dt><span class="term">surface</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - pointer surface</dd><dt><span class="term">hotspot_x</span></dt><dd>int
-            - surface-local x coordinate</dd><dt><span class="term">hotspot_y</span></dt><dd>int
-            - surface-local y coordinate</dd></dl></div><p>
-        </p><p>
-	Set the pointer surface, i.e., the surface that contains the
-	pointer image (cursor). This request gives the surface the role
-	of a cursor. If the surface already has another role, it raises
-	a protocol error.</p><p>	The cursor actually changes only if the pointer
-	focus for this device is one of the requesting client's surfaces
-	or the surface parameter is the current pointer surface. If
-	there was a previous surface set with this request it is
-	replaced. If surface is NULL, the pointer image is hidden.</p><p>	The parameters hotspot_x and hotspot_y define the position of
-	the pointer surface relative to the pointer location. Its
-	top-left corner is always at (x, y) - (hotspot_x, hotspot_y),
-	where (x, y) are the coordinates of the pointer location, in
-	surface-local coordinates.</p><p>	On surface.attach requests to the pointer surface, hotspot_x
-	and hotspot_y are decremented by the x and y parameters
-	passed to the request. Attach must be confirmed by
-	wl_surface.commit as usual.</p><p>	The hotspot can also be updated by passing the currently set
-	pointer surface to this request with new values for hotspot_x
-	and hotspot_y.</p><p>	The current and pending input regions of the wl_surface are
-	cleared, and wl_surface.set_input_region is ignored until the
-	wl_surface is no longer used as the cursor. When the use as a
-	cursor ends, the current and pending input regions become
-	undefined, and the wl_surface is unmapped.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-request-release"></a>wl_pointer::release
-        - release the pointer object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Using this request a client can tell the server that it is not going to
-	use the pointer object anymore.</p><p>	This request destroys the pointer proxy object, so clients must not call
-	wl_pointer_destroy() after using this request.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152823631392"></a>Events provided by wl_pointer</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-event-enter"></a>wl_pointer::enter
-        - enter event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the enter event</dd><dt><span class="term">surface</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - surface entered by the pointer</dd><dt><span class="term">surface_x</span></dt><dd>fixed
-            - surface-local x coordinate</dd><dt><span class="term">surface_y</span></dt><dd>fixed
-            - surface-local y coordinate</dd></dl></div><p>
-        </p><p>
-	Notification that this seat's pointer is focused on a certain
-	surface.</p><p>	When a seat's focus enters a surface, the pointer image
-	is undefined and a client should respond to this event by setting
-	an appropriate pointer image with the set_cursor request.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-event-leave"></a>wl_pointer::leave
-        - leave event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the leave event</dd><dt><span class="term">surface</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - surface left by the pointer</dd></dl></div><p>
-        </p><p>
-	Notification that this seat's pointer is no longer focused on
-	a certain surface.</p><p>	The leave notification is sent before the enter notification
-	for the new focus.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-event-motion"></a>wl_pointer::motion
-        - pointer motion event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">time</span></dt><dd>uint
-            - timestamp with millisecond granularity</dd><dt><span class="term">surface_x</span></dt><dd>fixed
-            - surface-local x coordinate</dd><dt><span class="term">surface_y</span></dt><dd>fixed
-            - surface-local y coordinate</dd></dl></div><p>
-        </p><p>
-	Notification of pointer location change. The arguments
-	surface_x and surface_y are the location relative to the
-	focused surface.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-event-button"></a>wl_pointer::button
-        - pointer button event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the button event</dd><dt><span class="term">time</span></dt><dd>uint
-            - timestamp with millisecond granularity</dd><dt><span class="term">button</span></dt><dd>uint
-            - button that produced the event</dd><dt><span class="term">state</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_pointer-enum-button_state" title="wl_pointer::button_state - physical button state">wl_pointer::button_state</a>
-          (uint)
-          
-            - physical state of the button</dd></dl></div><p>
-        </p><p>
-	Mouse button click and release notifications.</p><p>	The location of the click is given by the last motion or
-	enter event.
-	The time argument is a timestamp with millisecond
-	granularity, with an undefined base.</p><p>	The button is a button code as defined in the Linux kernel's
-	linux/input-event-codes.h header file, e.g. BTN_LEFT.</p><p>	Any 16-bit button code value is reserved for future additions to the
-	kernel's event code list. All other button codes above 0xFFFF are
-	currently undefined but may be used in future versions of this
-	protocol.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-event-axis"></a>wl_pointer::axis
-        - axis event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">time</span></dt><dd>uint
-            - timestamp with millisecond granularity</dd><dt><span class="term">axis</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_pointer-enum-axis" title="wl_pointer::axis - axis types">wl_pointer::axis</a>
-          (uint)
-          
-            - axis type</dd><dt><span class="term">value</span></dt><dd>fixed
-            - length of vector in surface-local coordinate space</dd></dl></div><p>
-        </p><p>
-	Scroll and other axis notifications.</p><p>	For scroll events (vertical and horizontal scroll axes), the
-	value parameter is the length of a vector along the specified
-	axis in a coordinate space identical to those of motion events,
-	representing a relative movement along the specified axis.</p><p>	For devices that support movements non-parallel to axes multiple
-	axis events will be emitted.</p><p>	When applicable, for example for touch pads, the server can
-	choose to emit scroll events where the motion vector is
-	equivalent to a motion event vector.</p><p>	When applicable, a client can transform its content relative to the
-	scroll distance.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-event-frame"></a>wl_pointer::frame
-        - end of a pointer event sequence</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Indicates the end of a set of events that logically belong together.
-	A client is expected to accumulate the data in all events within the
-	frame before proceeding.</p><p>	All wl_pointer events before a wl_pointer.frame event belong
-	logically together. For example, in a diagonal scroll motion the
-	compositor will send an optional wl_pointer.axis_source event, two
-	wl_pointer.axis events (horizontal and vertical) and finally a
-	wl_pointer.frame event. The client may use this information to
-	calculate a diagonal vector for scrolling.</p><p>	When multiple wl_pointer.axis events occur within the same frame,
-	the motion vector is the combined motion of all events.
-	When a wl_pointer.axis and a wl_pointer.axis_stop event occur within
-	the same frame, this indicates that axis movement in one axis has
-	stopped but continues in the other axis.
-	When multiple wl_pointer.axis_stop events occur within the same
-	frame, this indicates that these axes stopped in the same instance.</p><p>	A wl_pointer.frame event is sent for every logical event group,
-	even if the group only contains a single wl_pointer event.
-	Specifically, a client may get a sequence: motion, frame, button,
-	frame, axis, frame, axis_stop, frame.</p><p>	The wl_pointer.enter and wl_pointer.leave events are logical events
-	generated by the compositor and not the hardware. These events are
-	also grouped by a wl_pointer.frame. When a pointer moves from one
-	surface to another, a compositor should group the
-	wl_pointer.leave event within the same wl_pointer.frame.
-	However, a client must not rely on wl_pointer.leave and
-	wl_pointer.enter being in the same wl_pointer.frame.
-	Compositor-specific policies may require the wl_pointer.leave and
-	wl_pointer.enter event being split across multiple wl_pointer.frame
-	groups.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-event-axis_source"></a>wl_pointer::axis_source
-        - axis source event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">axis_source</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_pointer-enum-axis_source" title="wl_pointer::axis_source - axis source types">wl_pointer::axis_source</a>
-          (uint)
-          
-            - source of the axis event</dd></dl></div><p>
-        </p><p>
-	Source information for scroll and other axes.</p><p>	This event does not occur on its own. It is sent before a
-	wl_pointer.frame event and carries the source information for
-	all events within that frame.</p><p>	The source specifies how this event was generated. If the source is
-	wl_pointer.axis_source.finger, a wl_pointer.axis_stop event will be
-	sent when the user lifts the finger off the device.</p><p>	If the source is wl_pointer.axis_source.wheel,
-	wl_pointer.axis_source.wheel_tilt or
-	wl_pointer.axis_source.continuous, a wl_pointer.axis_stop event may
-	or may not be sent. Whether a compositor sends an axis_stop event
-	for these sources is hardware-specific and implementation-dependent;
-	clients must not rely on receiving an axis_stop event for these
-	scroll sources and should treat scroll sequences from these scroll
-	sources as unterminated by default.</p><p>	This event is optional. If the source is unknown for a particular
-	axis event sequence, no event is sent.
-	Only one wl_pointer.axis_source event is permitted per frame.</p><p>	The order of wl_pointer.axis_discrete and wl_pointer.axis_source is
-	not guaranteed.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-event-axis_stop"></a>wl_pointer::axis_stop
-        - axis stop event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">time</span></dt><dd>uint
-            - timestamp with millisecond granularity</dd><dt><span class="term">axis</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_pointer-enum-axis" title="wl_pointer::axis - axis types">wl_pointer::axis</a>
-          (uint)
-          
-            - the axis stopped with this event</dd></dl></div><p>
-        </p><p>
-	Stop notification for scroll and other axes.</p><p>	For some wl_pointer.axis_source types, a wl_pointer.axis_stop event
-	is sent to notify a client that the axis sequence has terminated.
-	This enables the client to implement kinetic scrolling.
-	See the wl_pointer.axis_source documentation for information on when
-	this event may be generated.</p><p>	Any wl_pointer.axis events with the same axis_source after this
-	event should be considered as the start of a new axis motion.</p><p>	The timestamp is to be interpreted identical to the timestamp in the
-	wl_pointer.axis event. The timestamp value may be the same as a
-	preceding wl_pointer.axis event.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-event-axis_discrete"></a>wl_pointer::axis_discrete
-        - axis click event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">axis</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_pointer-enum-axis" title="wl_pointer::axis - axis types">wl_pointer::axis</a>
-          (uint)
-          
-            - axis type</dd><dt><span class="term">discrete</span></dt><dd>int
-            - number of steps</dd></dl></div><p>
-        </p><p>
-	Discrete step information for scroll and other axes.</p><p>	This event carries the axis value of the wl_pointer.axis event in
-	discrete steps (e.g. mouse wheel clicks).</p><p>	This event does not occur on its own, it is coupled with a
-	wl_pointer.axis event that represents this axis value on a
-	continuous scale. The protocol guarantees that each axis_discrete
-	event is always followed by exactly one axis event with the same
-	axis number within the same wl_pointer.frame. Note that the protocol
-	allows for other events to occur between the axis_discrete and
-	its coupled axis event, including other axis_discrete or axis
-	events.</p><p>	This event is optional; continuous scrolling devices
-	like two-finger scrolling on touchpads do not have discrete
-	steps and do not generate this event.</p><p>	The discrete value carries the directional information. e.g. a value
-	of -2 is two steps towards the negative direction of this axis.</p><p>	The axis number is identical to the axis number in the associated
-	axis event.</p><p>	The order of wl_pointer.axis_discrete and wl_pointer.axis_source is
-	not guaranteed.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152821444208"></a>Enums provided by wl_pointer</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-enum-error"></a>wl_pointer::error</h4></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">role</span></dt><dd>0
-          - given wl_surface has another role</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-enum-button_state"></a>wl_pointer::button_state
-        - physical button state</h4></div></div></div><p>
-	Describes the physical state of a button that produced the button
-	event.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">released</span></dt><dd>0
-          - the button is not pressed</dd><dt><span class="term">pressed</span></dt><dd>1
-          - the button is pressed</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-enum-axis"></a>wl_pointer::axis
-        - axis types</h4></div></div></div><p>
-	Describes the axis types of scroll events.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">vertical_scroll</span></dt><dd>0
-          - vertical axis</dd><dt><span class="term">horizontal_scroll</span></dt><dd>1
-          - horizontal axis</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_pointer-enum-axis_source"></a>wl_pointer::axis_source
-        - axis source types</h4></div></div></div><p>
-	Describes the source types for axis events. This indicates to the
-	client how an axis event was physically generated; a client may
-	adjust the user interface accordingly. For example, scroll events
-	from a "finger" source may be in a smooth coordinate space with
-	kinetic scrolling whereas a "wheel" source may be in discrete steps
-	of a number of lines.</p><p>	The "continuous" axis source is a device generating events in a
-	continuous coordinate space, but using something other than a
-	finger. One example for this source is button-based scrolling where
-	the vertical motion of a device is converted to scroll events while
-	a button is held down.</p><p>	The "wheel tilt" axis source indicates that the actual device is a
-	wheel but the scroll event is not caused by a rotation but a
-	(usually sideways) tilt of the wheel.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">wheel</span></dt><dd>0
-          - a physical wheel rotation</dd><dt><span class="term">finger</span></dt><dd>1
-          - finger on a touch surface</dd><dt><span class="term">continuous</span></dt><dd>2
-          - continuous coordinate space</dd><dt><span class="term">wheel_tilt</span></dt><dd>3
-          - a physical wheel tilt</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_keyboard"></a>wl_keyboard
-	- keyboard input device</h2></div></div></div><p>
-      The wl_keyboard interface represents one or more keyboards
-      associated with a seat.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152824807072"></a>Requests provided by wl_keyboard</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_keyboard-request-release"></a>wl_keyboard::release
-        - release the keyboard object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p></p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152824803952"></a>Events provided by wl_keyboard</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_keyboard-event-keymap"></a>wl_keyboard::keymap
-        - keyboard mapping</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">format</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_keyboard-enum-keymap_format" title="wl_keyboard::keymap_format - keyboard mapping format">wl_keyboard::keymap_format</a>
-          (uint)
-          
-            - keymap format</dd><dt><span class="term">fd</span></dt><dd>fd
-            - keymap file descriptor</dd><dt><span class="term">size</span></dt><dd>uint
-            - keymap size, in bytes</dd></dl></div><p>
-        </p><p>
-	This event provides a file descriptor to the client which can be
-	memory-mapped to provide a keyboard mapping description.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_keyboard-event-enter"></a>wl_keyboard::enter
-        - enter event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the enter event</dd><dt><span class="term">surface</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - surface gaining keyboard focus</dd><dt><span class="term">keys</span></dt><dd>array
-            - the currently pressed keys</dd></dl></div><p>
-        </p><p>
-	Notification that this seat's keyboard focus is on a certain
-	surface.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_keyboard-event-leave"></a>wl_keyboard::leave
-        - leave event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the leave event</dd><dt><span class="term">surface</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - surface that lost keyboard focus</dd></dl></div><p>
-        </p><p>
-	Notification that this seat's keyboard focus is no longer on
-	a certain surface.</p><p>	The leave notification is sent before the enter notification
-	for the new focus.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_keyboard-event-key"></a>wl_keyboard::key
-        - key event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the key event</dd><dt><span class="term">time</span></dt><dd>uint
-            - timestamp with millisecond granularity</dd><dt><span class="term">key</span></dt><dd>uint
-            - key that produced the event</dd><dt><span class="term">state</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_keyboard-enum-key_state" title="wl_keyboard::key_state - physical key state">wl_keyboard::key_state</a>
-          (uint)
-          
-            - physical state of the key</dd></dl></div><p>
-        </p><p>
-	A key was pressed or released.
-	The time argument is a timestamp with millisecond
-	granularity, with an undefined base.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_keyboard-event-modifiers"></a>wl_keyboard::modifiers
-        - modifier and group state</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the modifiers event</dd><dt><span class="term">mods_depressed</span></dt><dd>uint
-            - depressed modifiers</dd><dt><span class="term">mods_latched</span></dt><dd>uint
-            - latched modifiers</dd><dt><span class="term">mods_locked</span></dt><dd>uint
-            - locked modifiers</dd><dt><span class="term">group</span></dt><dd>uint
-            - keyboard layout</dd></dl></div><p>
-        </p><p>
-	Notifies clients that the modifier and/or group state has
-	changed, and it should update its local state.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_keyboard-event-repeat_info"></a>wl_keyboard::repeat_info
-        - repeat rate and delay</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">rate</span></dt><dd>int
-            - the rate of repeating keys in characters per second</dd><dt><span class="term">delay</span></dt><dd>int
-            - delay in milliseconds since key down until repeating starts</dd></dl></div><p>
-        </p><p>
-	Informs the client about the keyboard's repeat rate and delay.</p><p>	This event is sent as soon as the wl_keyboard object has been created,
-	and is guaranteed to be received by the client before any key press
-	event.</p><p>	Negative values for either rate or delay are illegal. A rate of zero
-	will disable any repeating (regardless of the value of delay).</p><p>	This event can be sent later on as well with a new value if necessary,
-	so clients should continue listening for the event past the creation
-	of wl_keyboard.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152827240288"></a>Enums provided by wl_keyboard</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_keyboard-enum-keymap_format"></a>wl_keyboard::keymap_format
-        - keyboard mapping format</h4></div></div></div><p>
-	This specifies the format of the keymap provided to the
-	client with the wl_keyboard.keymap event.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">no_keymap</span></dt><dd>0
-          - no keymap; client must understand how to interpret the raw keycode</dd><dt><span class="term">xkb_v1</span></dt><dd>1
-          - libxkbcommon compatible; to determine the xkb keycode, clients must add 8 to the key event keycode</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_keyboard-enum-key_state"></a>wl_keyboard::key_state
-        - physical key state</h4></div></div></div><p>
-	Describes the physical state of a key that produced the key event.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">released</span></dt><dd>0
-          - key is not pressed</dd><dt><span class="term">pressed</span></dt><dd>1
-          - key is pressed</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_touch"></a>wl_touch
-	- touchscreen input device</h2></div></div></div><p>
-      The wl_touch interface represents a touchscreen
-      associated with a seat.</p><p>      Touch interactions can consist of one or more contacts.
-      For each contact, a series of events is generated, starting
-      with a down event, followed by zero or more motion events,
-      and ending with an up event. Events relating to the same
-      contact point can be identified by the ID of the sequence.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152827225296"></a>Requests provided by wl_touch</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_touch-request-release"></a>wl_touch::release
-        - release the touch object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p></p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152822289456"></a>Events provided by wl_touch</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_touch-event-down"></a>wl_touch::down
-        - touch down event and beginning of a touch sequence</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the touch down event</dd><dt><span class="term">time</span></dt><dd>uint
-            - timestamp with millisecond granularity</dd><dt><span class="term">surface</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - surface touched</dd><dt><span class="term">id</span></dt><dd>int
-            - the unique ID of this touch point</dd><dt><span class="term">x</span></dt><dd>fixed
-            - surface-local x coordinate</dd><dt><span class="term">y</span></dt><dd>fixed
-            - surface-local y coordinate</dd></dl></div><p>
-        </p><p>
-	A new touch point has appeared on the surface. This touch point is
-	assigned a unique ID. Future events from this touch point reference
-	this ID. The ID ceases to be valid after a touch up event and may be
-	reused in the future.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_touch-event-up"></a>wl_touch::up
-        - end of a touch event sequence</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">serial</span></dt><dd>uint
-            - serial number of the touch up event</dd><dt><span class="term">time</span></dt><dd>uint
-            - timestamp with millisecond granularity</dd><dt><span class="term">id</span></dt><dd>int
-            - the unique ID of this touch point</dd></dl></div><p>
-        </p><p>
-	The touch point has disappeared. No further events will be sent for
-	this touch point and the touch point's ID is released and may be
-	reused in a future touch down event.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_touch-event-motion"></a>wl_touch::motion
-        - update of touch point coordinates</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">time</span></dt><dd>uint
-            - timestamp with millisecond granularity</dd><dt><span class="term">id</span></dt><dd>int
-            - the unique ID of this touch point</dd><dt><span class="term">x</span></dt><dd>fixed
-            - surface-local x coordinate</dd><dt><span class="term">y</span></dt><dd>fixed
-            - surface-local y coordinate</dd></dl></div><p>
-        </p><p>
-	A touch point has changed coordinates.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_touch-event-frame"></a>wl_touch::frame
-        - end of touch frame event</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Indicates the end of a set of events that logically belong together.
-	A client is expected to accumulate the data in all events within the
-	frame before proceeding.</p><p>	A wl_touch.frame terminates at least one event but otherwise no
-	guarantee is provided about the set of events within a frame. A client
-	must assume that any state not updated in a frame is unchanged from the
-	previously known state.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_touch-event-cancel"></a>wl_touch::cancel
-        - touch session cancelled</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Sent if the compositor decides the touch stream is a global
-	gesture. No further events are sent to the clients from that
-	particular gesture. Touch cancellation applies to all touch points
-	currently active on this client's surface. The client is
-	responsible for finalizing the touch points, future touch points on
-	this surface may reuse the touch point ID.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_touch-event-shape"></a>wl_touch::shape
-        - update shape of touch point</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>int
-            - the unique ID of this touch point</dd><dt><span class="term">major</span></dt><dd>fixed
-            - length of the major axis in surface-local coordinates</dd><dt><span class="term">minor</span></dt><dd>fixed
-            - length of the minor axis in surface-local coordinates</dd></dl></div><p>
-        </p><p>
-	Sent when a touchpoint has changed its shape.</p><p>	This event does not occur on its own. It is sent before a
-	wl_touch.frame event and carries the new shape information for
-	any previously reported, or new touch points of that frame.</p><p>	Other events describing the touch point such as wl_touch.down,
-	wl_touch.motion or wl_touch.orientation may be sent within the
-	same wl_touch.frame. A client should treat these events as a single
-	logical touch point update. The order of wl_touch.shape,
-	wl_touch.orientation and wl_touch.motion is not guaranteed.
-	A wl_touch.down event is guaranteed to occur before the first
-	wl_touch.shape event for this touch ID but both events may occur within
-	the same wl_touch.frame.</p><p>	A touchpoint shape is approximated by an ellipse through the major and
-	minor axis length. The major axis length describes the longer diameter
-	of the ellipse, while the minor axis length describes the shorter
-	diameter. Major and minor are orthogonal and both are specified in
-	surface-local coordinates. The center of the ellipse is always at the
-	touchpoint location as reported by wl_touch.down or wl_touch.move.</p><p>	This event is only sent by the compositor if the touch device supports
-	shape reports. The client has to make reasonable assumptions about the
-	shape if it did not receive this event.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_touch-event-orientation"></a>wl_touch::orientation
-        - update orientation of touch point</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>int
-            - the unique ID of this touch point</dd><dt><span class="term">orientation</span></dt><dd>fixed
-            - angle between major axis and positive surface y-axis in degrees</dd></dl></div><p>
-        </p><p>
-	Sent when a touchpoint has changed its orientation.</p><p>	This event does not occur on its own. It is sent before a
-	wl_touch.frame event and carries the new shape information for
-	any previously reported, or new touch points of that frame.</p><p>	Other events describing the touch point such as wl_touch.down,
-	wl_touch.motion or wl_touch.shape may be sent within the
-	same wl_touch.frame. A client should treat these events as a single
-	logical touch point update. The order of wl_touch.shape,
-	wl_touch.orientation and wl_touch.motion is not guaranteed.
-	A wl_touch.down event is guaranteed to occur before the first
-	wl_touch.orientation event for this touch ID but both events may occur
-	within the same wl_touch.frame.</p><p>	The orientation describes the clockwise angle of a touchpoint's major
-	axis to the positive surface y-axis and is normalized to the -180 to
-	+180 degree range. The granularity of orientation depends on the touch
-	device, some devices only support binary rotation values between 0 and
-	90 degrees.</p><p>	This event is only sent by the compositor if the touch device supports
-	orientation reports.
-      </p></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_output"></a>wl_output
-	- compositor output region</h2></div></div></div><p>
-      An output describes part of the compositor geometry.  The
-      compositor works in the 'compositor coordinate system' and an
-      output corresponds to a rectangular area in that space that is
-      actually visible.  This typically corresponds to a monitor that
-      displays part of the compositor space.  This object is published
-      as global during start up, or when a monitor is hotplugged.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152824102928"></a>Requests provided by wl_output</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_output-request-release"></a>wl_output::release
-        - release the output object</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Using this request a client can tell the server that it is not going to
-	use the output object anymore.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152824099488"></a>Events provided by wl_output</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_output-event-geometry"></a>wl_output::geometry
-        - properties of the output</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">x</span></dt><dd>int
-            - x position within the global compositor space</dd><dt><span class="term">y</span></dt><dd>int
-            - y position within the global compositor space</dd><dt><span class="term">physical_width</span></dt><dd>int
-            - width in millimeters of the output</dd><dt><span class="term">physical_height</span></dt><dd>int
-            - height in millimeters of the output</dd><dt><span class="term">subpixel</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_output-enum-subpixel" title="wl_output::subpixel - subpixel geometry information">wl_output::subpixel</a>
-          (int)
-          
-            - subpixel orientation of the output</dd><dt><span class="term">make</span></dt><dd>string
-            - textual description of the manufacturer</dd><dt><span class="term">model</span></dt><dd>string
-            - textual description of the model</dd><dt><span class="term">transform</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_output-enum-transform" title="wl_output::transform - transform from framebuffer to output">wl_output::transform</a>
-          (int)
-          
-            - transform that maps framebuffer to output</dd></dl></div><p>
-        </p><p>
-	The geometry event describes geometric properties of the output.
-	The event is sent when binding to the output object and whenever
-	any of the properties change.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_output-event-mode"></a>wl_output::mode
-        - advertise available modes for the output</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">flags</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_output-enum-mode" title="wl_output::mode - bitfield - mode information">wl_output::mode</a>
-          (uint)
-          
-            - bitfield of mode flags</dd><dt><span class="term">width</span></dt><dd>int
-            - width of the mode in hardware units</dd><dt><span class="term">height</span></dt><dd>int
-            - height of the mode in hardware units</dd><dt><span class="term">refresh</span></dt><dd>int
-            - vertical refresh rate in mHz</dd></dl></div><p>
-        </p><p>
-	The mode event describes an available mode for the output.</p><p>	The event is sent when binding to the output object and there
-	will always be one mode, the current mode.  The event is sent
-	again if an output changes mode, for the mode that is now
-	current.  In other words, the current mode is always the last
-	mode that was received with the current flag set.</p><p>	The size of a mode is given in physical hardware units of
-	the output device. This is not necessarily the same as
-	the output size in the global compositor space. For instance,
-	the output may be scaled, as described in wl_output.scale,
-	or transformed, as described in wl_output.transform.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_output-event-done"></a>wl_output::done
-        - sent all information about output</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	This event is sent after all other properties have been
-	sent after binding to the output object and after any
-	other property changes done after that. This allows
-	changes to the output properties to be seen as
-	atomic, even if they happen via multiple events.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_output-event-scale"></a>wl_output::scale
-        - output scaling properties</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">factor</span></dt><dd>int
-            - scaling factor of output</dd></dl></div><p>
-        </p><p>
-	This event contains scaling geometry information
-	that is not in the geometry event. It may be sent after
-	binding the output object or if the output scale changes
-	later. If it is not sent, the client should assume a
-	scale of 1.</p><p>	A scale larger than 1 means that the compositor will
-	automatically scale surface buffers by this amount
-	when rendering. This is used for very high resolution
-	displays where applications rendering at the native
-	resolution would be too small to be legible.</p><p>	It is intended that scaling aware clients track the
-	current output of a surface, and if it is on a scaled
-	output it should use wl_surface.set_buffer_scale with
-	the scale of the output. That way the compositor can
-	avoid scaling the surface, and the client can supply
-	a higher detail image.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152822859840"></a>Enums provided by wl_output</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_output-enum-subpixel"></a>wl_output::subpixel
-        - subpixel geometry information</h4></div></div></div><p>
-	This enumeration describes how the physical
-	pixels on an output are laid out.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">unknown</span></dt><dd>0
-          - unknown geometry</dd><dt><span class="term">none</span></dt><dd>1
-          - no geometry</dd><dt><span class="term">horizontal_rgb</span></dt><dd>2
-          - horizontal RGB</dd><dt><span class="term">horizontal_bgr</span></dt><dd>3
-          - horizontal BGR</dd><dt><span class="term">vertical_rgb</span></dt><dd>4
-          - vertical RGB</dd><dt><span class="term">vertical_bgr</span></dt><dd>5
-          - vertical BGR</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_output-enum-transform"></a>wl_output::transform
-        - transform from framebuffer to output</h4></div></div></div><p>
-	This describes the transform that a compositor will apply to a
-	surface to compensate for the rotation or mirroring of an
-	output device.</p><p>	The flipped values correspond to an initial flip around a
-	vertical axis followed by rotation.</p><p>	The purpose is mainly to allow clients to render accordingly and
-	tell the compositor, so that for fullscreen surfaces, the
-	compositor will still be able to scan out directly from client
-	surfaces.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">normal</span></dt><dd>0
-          - no transform</dd><dt><span class="term">90</span></dt><dd>1
-          - 90 degrees counter-clockwise</dd><dt><span class="term">180</span></dt><dd>2
-          - 180 degrees counter-clockwise</dd><dt><span class="term">270</span></dt><dd>3
-          - 270 degrees counter-clockwise</dd><dt><span class="term">flipped</span></dt><dd>4
-          - 180 degree flip around a vertical axis</dd><dt><span class="term">flipped_90</span></dt><dd>5
-          - flip and rotate 90 degrees counter-clockwise</dd><dt><span class="term">flipped_180</span></dt><dd>6
-          - flip and rotate 180 degrees counter-clockwise</dd><dt><span class="term">flipped_270</span></dt><dd>7
-          - flip and rotate 270 degrees counter-clockwise</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_output-enum-mode"></a>wl_output::mode
-        - bitfield
-      
-        - mode information</h4></div></div></div><p>
-	These flags describe properties of an output mode.
-	They are used in the flags bitfield of the mode event.
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">current</span></dt><dd>0x1
-          - indicates this is the current mode</dd><dt><span class="term">preferred</span></dt><dd>0x2
-          - indicates this is the preferred mode</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_region"></a>wl_region
-	- region interface</h2></div></div></div><p>
-      A region object describes an area.</p><p>      Region objects are used to describe the opaque and input
-      regions of a surface.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152823421200"></a>Requests provided by wl_region</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_region-request-destroy"></a>wl_region::destroy
-        - destroy region</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Destroy the region.  This will invalidate the object ID.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_region-request-add"></a>wl_region::add
-        - add rectangle to region</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">x</span></dt><dd>int
-            - region-local x coordinate</dd><dt><span class="term">y</span></dt><dd>int
-            - region-local y coordinate</dd><dt><span class="term">width</span></dt><dd>int
-            - rectangle width</dd><dt><span class="term">height</span></dt><dd>int
-            - rectangle height</dd></dl></div><p>
-        </p><p>
-	Add the specified rectangle to the region.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_region-request-subtract"></a>wl_region::subtract
-        - subtract rectangle from region</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">x</span></dt><dd>int
-            - region-local x coordinate</dd><dt><span class="term">y</span></dt><dd>int
-            - region-local y coordinate</dd><dt><span class="term">width</span></dt><dd>int
-            - rectangle width</dd><dt><span class="term">height</span></dt><dd>int
-            - rectangle height</dd></dl></div><p>
-        </p><p>
-	Subtract the specified rectangle from the region.
-      </p></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_subcompositor"></a>wl_subcompositor
-	- sub-surface compositing</h2></div></div></div><p>
-      The global interface exposing sub-surface compositing capabilities.
-      A wl_surface, that has sub-surfaces associated, is called the
-      parent surface. Sub-surfaces can be arbitrarily nested and create
-      a tree of sub-surfaces.</p><p>      The root surface in a tree of sub-surfaces is the main
-      surface. The main surface cannot be a sub-surface, because
-      sub-surfaces must always have a parent.</p><p>      A main surface with its sub-surfaces forms a (compound) window.
-      For window management purposes, this set of wl_surface objects is
-      to be considered as a single window, and it should also behave as
-      such.</p><p>      The aim of sub-surfaces is to offload some of the compositing work
-      within a window from clients to the compositor. A prime example is
-      a video player with decorations and video in separate wl_surface
-      objects. This should allow the compositor to pass YUV video buffer
-      processing to dedicated overlay hardware when possible.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152819394656"></a>Requests provided by wl_subcompositor</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subcompositor-request-destroy"></a>wl_subcompositor::destroy
-        - unbind from the subcompositor interface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Informs the server that the client will not be using this
-	protocol object anymore. This does not affect any other
-	objects, wl_subsurface objects included.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subcompositor-request-get_subsurface"></a>wl_subcompositor::get_subsurface
-        - give a surface the role sub-surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">id</span></dt><dd>
-          id for the new
-          <a class="link" href="apa.html#protocol-spec-wl_subsurface" title="wl_subsurface - sub-surface interface to a wl_surface">wl_subsurface</a>
-            - the new sub-surface object ID</dd><dt><span class="term">surface</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - the surface to be turned into a sub-surface</dd><dt><span class="term">parent</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - the parent surface</dd></dl></div><p>
-        </p><p>
-	Create a sub-surface interface for the given surface, and
-	associate it with the given parent surface. This turns a
-	plain wl_surface into a sub-surface.</p><p>	The to-be sub-surface must not already have another role, and it
-	must not have an existing wl_subsurface object. Otherwise a protocol
-	error is raised.</p><p>	Adding sub-surfaces to a parent is a double-buffered operation on the
-	parent (see wl_surface.commit). The effect of adding a sub-surface
-	becomes visible on the next time the state of the parent surface is
-	applied.</p><p>	This request modifies the behaviour of wl_surface.commit request on
-	the sub-surface, see the documentation on wl_subsurface interface.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152819379440"></a>Enums provided by wl_subcompositor</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subcompositor-enum-error"></a>wl_subcompositor::error</h4></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">bad_surface</span></dt><dd>0
-          - the to-be sub-surface is invalid</dd></dl></div></div></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="protocol-spec-wl_subsurface"></a>wl_subsurface
-	- sub-surface interface to a wl_surface</h2></div></div></div><p>
-      An additional interface to a wl_surface object, which has been
-      made a sub-surface. A sub-surface has one parent surface. A
-      sub-surface's size and position are not limited to that of the parent.
-      Particularly, a sub-surface is not automatically clipped to its
-      parent's area.</p><p>      A sub-surface becomes mapped, when a non-NULL wl_buffer is applied
-      and the parent surface is mapped. The order of which one happens
-      first is irrelevant. A sub-surface is hidden if the parent becomes
-      hidden, or if a NULL wl_buffer is applied. These rules apply
-      recursively through the tree of surfaces.</p><p>      The behaviour of a wl_surface.commit request on a sub-surface
-      depends on the sub-surface's mode. The possible modes are
-      synchronized and desynchronized, see methods
-      wl_subsurface.set_sync and wl_subsurface.set_desync. Synchronized
-      mode caches the wl_surface state to be applied when the parent's
-      state gets applied, and desynchronized mode applies the pending
-      wl_surface state directly. A sub-surface is initially in the
-      synchronized mode.</p><p>      Sub-surfaces have also other kind of state, which is managed by
-      wl_subsurface requests, as opposed to wl_surface requests. This
-      state includes the sub-surface position relative to the parent
-      surface (wl_subsurface.set_position), and the stacking order of
-      the parent and its sub-surfaces (wl_subsurface.place_above and
-      .place_below). This state is applied when the parent surface's
-      wl_surface state is applied, regardless of the sub-surface's mode.
-      As the exception, set_sync and set_desync are effective immediately.</p><p>      The main surface can be thought to be always in desynchronized mode,
-      since it does not have a parent in the sub-surfaces sense.</p><p>      Even if a sub-surface is in desynchronized mode, it will behave as
-      in synchronized mode, if its parent surface behaves as in
-      synchronized mode. This rule is applied recursively throughout the
-      tree of surfaces. This means, that one can set a sub-surface into
-      synchronized mode, and then assume that all its child and grand-child
-      sub-surfaces are synchronized, too, without explicitly setting them.</p><p>      If the wl_surface associated with the wl_subsurface is destroyed, the
-      wl_subsurface object becomes inert. Note, that destroying either object
-      takes effect immediately. If you need to synchronize the removal
-      of a sub-surface to the parent surface update, unmap the sub-surface
-      first by attaching a NULL wl_buffer, update parent, and then destroy
-      the sub-surface.</p><p>      If the parent wl_surface object is destroyed, the sub-surface is
-      unmapped.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152819368880"></a>Requests provided by wl_subsurface</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subsurface-request-destroy"></a>wl_subsurface::destroy
-        - remove sub-surface interface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	The sub-surface interface is removed from the wl_surface object
-	that was turned into a sub-surface with a
-	wl_subcompositor.get_subsurface request. The wl_surface's association
-	to the parent is deleted, and the wl_surface loses its role as
-	a sub-surface. The wl_surface is unmapped immediately.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subsurface-request-set_position"></a>wl_subsurface::set_position
-        - reposition the sub-surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">x</span></dt><dd>int
-            - x coordinate in the parent surface</dd><dt><span class="term">y</span></dt><dd>int
-            - y coordinate in the parent surface</dd></dl></div><p>
-        </p><p>
-	This schedules a sub-surface position change.
-	The sub-surface will be moved so that its origin (top left
-	corner pixel) will be at the location x, y of the parent surface
-	coordinate system. The coordinates are not restricted to the parent
-	surface area. Negative values are allowed.</p><p>	The scheduled coordinates will take effect whenever the state of the
-	parent surface is applied. When this happens depends on whether the
-	parent surface is in synchronized mode or not. See
-	wl_subsurface.set_sync and wl_subsurface.set_desync for details.</p><p>	If more than one set_position request is invoked by the client before
-	the commit of the parent surface, the position of a new request always
-	replaces the scheduled position from any previous request.</p><p>	The initial position is 0, 0.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subsurface-request-place_above"></a>wl_subsurface::place_above
-        - restack the sub-surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">sibling</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - the reference surface</dd></dl></div><p>
-        </p><p>
-	This sub-surface is taken from the stack, and put back just
-	above the reference surface, changing the z-order of the sub-surfaces.
-	The reference surface must be one of the sibling surfaces, or the
-	parent surface. Using any other surface, including this sub-surface,
-	will cause a protocol error.</p><p>	The z-order is double-buffered. Requests are handled in order and
-	applied immediately to a pending state. The final pending state is
-	copied to the active state the next time the state of the parent
-	surface is applied. When this happens depends on whether the parent
-	surface is in synchronized mode or not. See wl_subsurface.set_sync and
-	wl_subsurface.set_desync for details.</p><p>	A new sub-surface is initially added as the top-most in the stack
-	of its siblings and parent.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subsurface-request-place_below"></a>wl_subsurface::place_below
-        - restack the sub-surface</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">sibling</span></dt><dd><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a>
-            - the reference surface</dd></dl></div><p>
-        </p><p>
-	The sub-surface is placed just below the reference surface.
-	See wl_subsurface.place_above.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subsurface-request-set_sync"></a>wl_subsurface::set_sync
-        - set sub-surface to synchronized mode</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Change the commit behaviour of the sub-surface to synchronized
-	mode, also described as the parent dependent mode.</p><p>	In synchronized mode, wl_surface.commit on a sub-surface will
-	accumulate the committed state in a cache, but the state will
-	not be applied and hence will not change the compositor output.
-	The cached state is applied to the sub-surface immediately after
-	the parent surface's state is applied. This ensures atomic
-	updates of the parent and all its synchronized sub-surfaces.
-	Applying the cached state will invalidate the cache, so further
-	parent surface commits do not (re-)apply old state.</p><p>	See wl_subsurface for the recursive effect of this mode.
-      </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subsurface-request-set_desync"></a>wl_subsurface::set_desync
-        - set sub-surface to desynchronized mode</h4></div></div></div><p>
-          </p><div class="variablelist"><dl class="variablelist"></dl></div><p>
-        </p><p>
-	Change the commit behaviour of the sub-surface to desynchronized
-	mode, also described as independent or freely running mode.</p><p>	In desynchronized mode, wl_surface.commit on a sub-surface will
-	apply the pending state directly, without caching, as happens
-	normally with a wl_surface. Calling wl_surface.commit on the
-	parent surface has no effect on the sub-surface's wl_surface
-	state. This mode allows a sub-surface to be updated on its own.</p><p>	If cached state exists when wl_surface.commit is called in
-	desynchronized mode, the pending state is added to the cached
-	state, and applied as a whole. This invalidates the cache.</p><p>	Note: even if a sub-surface is set to desynchronized, a parent
-	sub-surface may override it to behave as synchronized. For details,
-	see wl_subsurface.</p><p>	If a surface's parent surface behaves as desynchronized, then
-	the cached state is applied on set_desync.
-      </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152823564032"></a>Enums provided by wl_subsurface</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="protocol-spec-wl_subsurface-enum-error"></a>wl_subsurface::error</h4></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">bad_surface</span></dt><dd>0
-          - wl_surface is not a sibling or the parent</dd></dl></div></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch05.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="apb.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 5. X11 Application Support </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix B. Client API</td></tr></table></div></body></html>
diff --git a/docs/html/apb.html b/docs/html/apb.html
deleted file mode 100644
index 30d5ed0..0000000
--- a/docs/html/apb.html
+++ /dev/null
@@ -1,624 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Appendix B. Client API</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="apa.html" title="Appendix A. Wayland Protocol Specification"><link rel="next" href="apc.html" title="Appendix C. Server API"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix B. Client API</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="apa.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="apc.html">Next</a></td></tr></table><hr></div><div class="appendix"><div class="titlepage"><div><div><h1 class="title"><a name="sect-Library-Client"></a>Appendix B. Client API</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="apb.html#idm140152827541248">Introduction</a></span></dt><dt><span class="section"><a href="apb.html#Client-unionwl__argument">wl_argument
-                - 
-Protocol message argument data types.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-structwl__array">wl_array
-                - 
-Dynamic array.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-classwl__display">wl_display
-                - 
-Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-classwl__event__queue">wl_event_queue
-                - 
-A queue for wl_proxy object events.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-structwl__interface">wl_interface
-                - 
-Protocol object interface.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-structwl__list">wl_list
-                - 
-Doubly-linked list.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-structwl__message">wl_message
-                - 
-Protocol message signature.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-classwl__proxy">wl_proxy
-                - 
-Represents a protocol object on the client side.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-Functions">Functions</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idm140152827541248"></a>Introduction</h2></div></div></div><p>
-    The open-source reference implementation of Wayland protocol is
-    split in two C libraries, libwayland-client and <a class="link" href="apc.html" title="Appendix C. Server API">libwayland-server</a>. Their main
-    responsibility is to handle the Inter-process communication
-    (<span class="emphasis"><em>IPC</em></span>) with each other, therefore guaranteeing
-    the protocol objects marshaling and messages synchronization.
-  </p><p>
-    A client uses libwayland-client to communicate with one or more
-    wayland servers. A <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> object is
-    created and manages each open connection to a server. At least one
-    <a class="link" href="apb.html#Client-classwl__event__queue" title="wl_event_queue - A queue for wl_proxy object events.">wl_event_queue</a>
-    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.
-  </p><p>
-    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.
-  </p><p>
-    The library only provides low-level access to the wayland objects.
-    Each object created by the client is represented by a <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> 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 <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> object,
-    which is generated from the xml and identifies the object's class
-    and can be used for introspection into the messages and events.
-  </p><p>
-    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 <a class="link" href="apa.html" title="Appendix A. Wayland Protocol Specification">Wayland protocols</a>. For
-    instance the C header file generated from the xml defines the
-    following inline function to transmit the <a class="link" href="apa.html#protocol-spec-wl_surface-request-attach" title="wl_surface::attach - set the surface contents">wl_surface::attach</a>
-    message:
-  </p><pre class="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);
-}</pre><p>
-    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 <a class="link" href="apa.html#protocol-spec-wl_surface-event-enter" title="wl_surface::enter - surface enters an output">wl_surface::enter</a>
-    event defines this pointer in the wl_surface_listener object:
-  </p><pre class="programlisting">struct wl_surface_listener {
-  void (*enter)(void *data, struct wl_surface *, struct wl_output *);
-  ...
-}</pre><p>
-  </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Client-unionwl__argument"></a>wl_argument
-                - 
-Protocol message argument data types.     </h2></div></div></div><p>This union represents all of the argument types in the Wayland protocol wire format. The protocol implementation uses <a class="link" href="apb.html#Client-unionwl__argument" title="wl_argument - Protocol message argument data types.">wl_argument</a> within its marshalling machinery for dispatching messages between a client and a compositor.</p><p>
-  See also: <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> 
-
-  See also: <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> 
-
-  See also: Wire Format 
-</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Client-structwl__array"></a>wl_array
-                - 
-Dynamic array.     </h2></div></div></div><p>A <a class="link" href="apb.html#Client-structwl__array" title="wl_array - Dynamic array.">wl_array</a> is a dynamic array that can only grow until released. It is intended for relatively small allocations whose size is variable or not known in advance. While construction of a <a class="link" href="apb.html#Client-structwl__array" title="wl_array - Dynamic array.">wl_array</a> does not require all elements to be of the same size, <a class="link" href="apb.html#Client-structwl__array_1ab050f7375dcae916506142763080ed80">wl_array_for_each()</a> does require all elements to have the same type and size. </p><div class="variablelist"><dl class="variablelist"><dt><a name="Client-structwl__array_1ae246c66cbd633063e2649c503d764d3f"></a><span class="term">size
-            - 
-Array size.         </span></dt><dd><pre class="synopsis">size_t wl_array::size</pre></dd><dt><a name="Client-structwl__array_1a4b33519c8f628d650631ebecee45b771"></a><span class="term">alloc
-            - 
-Allocated space.         </span></dt><dd><pre class="synopsis">size_t wl_array::alloc</pre></dd><dt><a name="Client-structwl__array_1af20153b7fcf63135eea72dd5d9e8b87b"></a><span class="term">data
-            - 
-Array data.         </span></dt><dd><pre class="synopsis">void* wl_array::data</pre></dd><dt><a name="Client-structwl__array_1ada9b770427b901be34eaf3683cf04d5a"></a><span class="term">wl_array_init
-            - 
-Initializes the array.         </span></dt><dd><pre class="synopsis">void wl_array_init(struct wl_array *array)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">array</span></dt><dd>
-Array to initialize </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__array_1a0e8845f61f1e1fccfce050830ed5b279"></a><span class="term">wl_array_release
-            - 
-Releases the array data.         </span></dt><dd><pre class="synopsis">void wl_array_release(struct wl_array *array)</pre><p><span class="emphasis"><em>Note: Leaves the array in an invalid state.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">array</span></dt><dd>
-Array whose data is to be released </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__array_1a3c3d1079a20b0609f6e4914ea21c2d03"></a><span class="term">wl_array_add
-            - 
-Increases the size of the array by size bytes.         </span></dt><dd><pre class="synopsis">void * wl_array_add(struct wl_array *array, size_t size)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">array</span></dt><dd>
-Array whose size is to be increased </dd><dt><span class="term">size</span></dt><dd>
-Number of bytes to increase the size of the array by</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A pointer to the beginning of the newly appended space, or NULL when resizing fails. </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__array_1a4de64390294de78da813dcfb16f47617"></a><span class="term">wl_array_copy
-            - 
-Copies the contents of source to array.         </span></dt><dd><pre class="synopsis">int wl_array_copy(struct wl_array *array, struct wl_array *source)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">array</span></dt><dd>
-Destination array to copy to </dd><dt><span class="term">source</span></dt><dd>
-Source array to copy from</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success, or -1 on failure </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__array_1ab050f7375dcae916506142763080ed80"></a><span class="term">wl_array_for_each
-            - 
-Iterates over an array.         </span></dt><dd><pre class="synopsis"></pre><p>This macro expresses a for-each iterator for <a class="link" href="apb.html#Client-structwl__array" title="wl_array - Dynamic array.">wl_array</a>. It assigns each element in the array to pos, which can then be referenced in a trailing code block. pos must be a pointer to the array element type, and all array elements must be of the same type and size.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each array element will be assigned to </dd><dt><span class="term">array</span></dt><dd>
-Array to iterate over</dd></dl></div><p>
-
-  See also: <a class="link" href="apb.html#Client-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb">wl_list_for_each()</a> 
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Client-classwl__display"></a>wl_display
-                - 
-Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.     </h2></div></div></div><p>A <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> object represents a client connection to a Wayland compositor. It is created with either <a class="link" href="apb.html#Client-classwl__display_1af048371dfef7577bd39a3c04b78d0374">wl_display_connect()</a> or <a class="link" href="apb.html#Client-classwl__display_1a90663db371e1b11704be98c1568c5206">wl_display_connect_to_fd()</a>. A connection is terminated using <a class="link" href="apb.html#Client-classwl__display_1a9150a7e3213a58b469a6966e60a9f108">wl_display_disconnect()</a>.</p><p>A <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> is also used as the <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> for the <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> singleton object on the compositor side.</p><p>A <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> object handles all the data sent from and to the compositor. When a <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> marshals a request, it will write its wire representation to the display's write buffer. The data is sent to the compositor when the client calls <a class="link" href="apb.html#Client-classwl__display_1a8463b6e5f4cf9a2a3ad2d543aedcf429">wl_display_flush()</a>.</p><p>Incoming data is handled in two steps: queueing and dispatching. In the queue step, the data coming from the display fd is interpreted and added to a queue. On the dispatch step, the handler for the incoming event set by the client on the corresponding <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> is called.</p><p>A <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> has at least one event queue, called the default queue. Clients can create additional event queues with <a class="link" href="apb.html#Client-classwl__display_1a9a44f497851dc7bd5b683121104015ac">wl_display_create_queue()</a> and assign <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a>'s to it. Events occurring in a particular proxy are always queued in its assigned queue. A client can ensure that a certain assumption, such as holding a lock or running from a given thread, is true when a proxy event handler is called by assigning that proxy to an event queue and making sure that this queue is only dispatched when the assumption holds.</p><p>The default queue is dispatched by calling <a class="link" href="apb.html#Client-classwl__display_1a30a9c4f020f3e77581c7a81ecdb4913d">wl_display_dispatch()</a>. This will dispatch any events queued on the default queue and attempt to read from the display fd if it's empty. Events read are then queued on the appropriate queues according to the proxy assignment.</p><p>A user created queue is dispatched with <a class="link" href="apb.html#Client-classwl__display_1ae027b09801474ac7c6b0f1ef25ff6e17">wl_display_dispatch_queue()</a>. This function behaves exactly the same as <a class="link" href="apb.html#Client-classwl__display_1a30a9c4f020f3e77581c7a81ecdb4913d">wl_display_dispatch()</a> but it dispatches given queue instead of the default queue.</p><p>A real world example of event queue usage is Mesa's implementation of eglSwapBuffers() for the Wayland platform. This function might need to block until a frame callback is received, but dispatching the default queue could cause an event handler on the client to start drawing again. This problem is solved using another event queue, so that only the events handled by the EGL code are dispatched during the block.</p><p>This creates a problem where a thread dispatches a non-default queue, reading all the data from the display fd. If the application would call poll(2) after that it would block, even though there might be events queued on the default queue. Those events should be dispatched with <a class="link" href="apb.html#Client-classwl__display_1ac4b6b5ad31932bc3830ff362d2938560">wl_display_dispatch_pending()</a> or <a class="link" href="apb.html#Client-classwl__display_1a8a14a809eb2c083a806db2ee15523041">wl_display_dispatch_queue_pending()</a> before flushing and blocking. </p><div class="variablelist"><dl class="variablelist"><dt><a name="Client-classwl__display_1a9a44f497851dc7bd5b683121104015ac"></a><span class="term">wl_display_create_queue
-            - 
-Create a new event queue for this display.         </span></dt><dd><pre class="synopsis">struct wl_event_queue * wl_display_create_queue(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A new event queue associated with this display or NULL on failure. </dd></dl></div><p>
-</p></dd><dt><a name="Client-classwl__display_1a90663db371e1b11704be98c1568c5206"></a><span class="term">wl_display_connect_to_fd
-            - 
-Connect to Wayland display on an already open fd.         </span></dt><dd><pre class="synopsis">struct wl_display * wl_display_connect_to_fd(int fd)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">fd</span></dt><dd>
-The fd to use for the connection </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> object or NULL on failure</dd></dl></div><p>
-The <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> takes ownership of the fd and will close it when the display is destroyed. The fd will also be closed in case of failure. </p></dd><dt><a name="Client-classwl__display_1af048371dfef7577bd39a3c04b78d0374"></a><span class="term">wl_display_connect
-            - 
-Connect to a Wayland display.         </span></dt><dd><pre class="synopsis">struct wl_display * wl_display_connect(const char *name)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">name</span></dt><dd>
-Name of the Wayland display to connect to </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> object or NULL on failure</dd></dl></div><p>
-Connect to the Wayland display named name. If name is NULL, its value will be replaced with the WAYLAND_DISPLAY environment variable if it is set, otherwise display "wayland-0" will be used.</p><p>If name is an absolute path, then that path is used as-is for the location of the socket at which the Wayland server is listening; no qualification inside XDG_RUNTIME_DIR is attempted.</p><p>If name is NULL and the WAYLAND_DISPLAY environment variable is set to an absolute pathname, then that pathname is used as-is for the socket in the same manner as if name held an absolute path. Support for absolute paths in name and WAYLAND_DISPLAY is present since Wayland version 1.15. </p></dd><dt><a name="Client-classwl__display_1a9150a7e3213a58b469a6966e60a9f108"></a><span class="term">wl_display_disconnect
-            - 
-Close a connection to a Wayland display.         </span></dt><dd><pre class="synopsis">void wl_display_disconnect(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object</dd></dl></div><p>
-Close the connection to display and free all resources associated with it. </p></dd><dt><a name="Client-classwl__display_1a2d5d249e81cbf43c3521d4bce575f1ca"></a><span class="term">wl_display_get_fd
-            - 
-Get a display context's file descriptor.         </span></dt><dd><pre class="synopsis">int wl_display_get_fd(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>Display object file descriptor</dd></dl></div><p>
-Return the file descriptor associated with a display so it can be integrated into the client's main loop. </p></dd><dt><a name="Client-classwl__display_1a73f44c38fa4e535f5eaf700933b0b2e6"></a><span class="term">wl_display_roundtrip_queue
-            - 
-Block until all pending request are processed by the server.         </span></dt><dd><pre class="synopsis">int wl_display_roundtrip_queue(struct wl_display *display, struct wl_event_queue *queue)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd><dt><span class="term">queue</span></dt><dd>
-The queue on which to run the roundtrip </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The number of dispatched events on success or -1 on failure</dd></dl></div><p>
-This function blocks until the server has processed all currently issued requests by sending a request to the display server and waiting for a reply before returning.</p><p>This function uses <a class="link" href="apb.html#Client-classwl__display_1ae027b09801474ac7c6b0f1ef25ff6e17">wl_display_dispatch_queue()</a> internally. It is not allowed to call this function while the thread is being prepared for reading events, and doing so will cause a dead lock.</p><p><span class="emphasis"><em>Note: This function may dispatch other events being received on the given queue.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-classwl__display_1ab60f38c2f80980ac84f347e932793390">wl_display_roundtrip()</a> 
-</p></dd><dt><a name="Client-classwl__display_1ab60f38c2f80980ac84f347e932793390"></a><span class="term">wl_display_roundtrip
-            - 
-Block until all pending request are processed by the server.         </span></dt><dd><pre class="synopsis">int wl_display_roundtrip(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The number of dispatched events on success or -1 on failure</dd></dl></div><p>
-This function blocks until the server has processed all currently issued requests by sending a request to the display server and waiting for a reply before returning.</p><p>This function uses <a class="link" href="apb.html#Client-classwl__display_1ae027b09801474ac7c6b0f1ef25ff6e17">wl_display_dispatch_queue()</a> internally. It is not allowed to call this function while the thread is being prepared for reading events, and doing so will cause a dead lock.</p><p><span class="emphasis"><em>Note: This function may dispatch other events being received on the default queue. </em></span>
-</p></dd><dt><a name="Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4"></a><span class="term">wl_display_read_events
-            - 
-Read events from display file descriptor.         </span></dt><dd><pre class="synopsis">int wl_display_read_events(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success or -1 on error. In case of error errno will be set accordingly</dd></dl></div><p>
-Calling this function will result in data available on the display file descriptor being read and read events will be queued on their corresponding event queues.</p><p>Before calling this function, depending on what thread it is to be called from, <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> or <a class="link" href="apb.html#Client-classwl__display_1a040dca18775e3177883f06bd6fdf395f">wl_display_prepare_read()</a> needs to be called. See <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> for more details.</p><p>When being called at a point where other threads have been prepared to read (using <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> or <a class="link" href="apb.html#Client-classwl__display_1a040dca18775e3177883f06bd6fdf395f">wl_display_prepare_read()</a>) this function will sleep until all other prepared threads have either been cancelled (using <a class="link" href="apb.html#Client-classwl__display_1a978fcabf13f1915e565435ab097bd590">wl_display_cancel_read()</a>) or them self entered this function. The last thread that calls this function will then read and queue events on their corresponding event queues, and finally wake up all other <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a> calls causing them to return.</p><p>If a thread cancels a read preparation when all other threads that have prepared to read has either called <a class="link" href="apb.html#Client-classwl__display_1a978fcabf13f1915e565435ab097bd590">wl_display_cancel_read()</a> or <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a>, all reader threads will return without having read any data.</p><p>To dispatch events that may have been queued, call <a class="link" href="apb.html#Client-classwl__display_1ac4b6b5ad31932bc3830ff362d2938560">wl_display_dispatch_pending()</a> or <a class="link" href="apb.html#Client-classwl__display_1a8a14a809eb2c083a806db2ee15523041">wl_display_dispatch_queue_pending()</a>.</p><p>
-  See also: <a class="link" href="apb.html#Client-classwl__display_1a040dca18775e3177883f06bd6fdf395f">wl_display_prepare_read()</a>, <a class="link" href="apb.html#Client-classwl__display_1a978fcabf13f1915e565435ab097bd590">wl_display_cancel_read()</a>, <a class="link" href="apb.html#Client-classwl__display_1ac4b6b5ad31932bc3830ff362d2938560">wl_display_dispatch_pending()</a>, <a class="link" href="apb.html#Client-classwl__display_1a30a9c4f020f3e77581c7a81ecdb4913d">wl_display_dispatch()</a> 
-</p></dd><dt><a name="Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0"></a><span class="term">wl_display_prepare_read_queue
-            - 
-Prepare to read events from the display's file descriptor to a queue.         </span></dt><dd><pre class="synopsis">int wl_display_prepare_read_queue(struct wl_display *display, struct wl_event_queue *queue)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd><dt><span class="term">queue</span></dt><dd>
-The event queue to use </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success or -1 if event queue was not empty</dd></dl></div><p>
-This function (or <a class="link" href="apb.html#Client-classwl__display_1a040dca18775e3177883f06bd6fdf395f">wl_display_prepare_read()</a>) must be called before reading from the file descriptor using <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a>. Calling <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> announces the calling thread's intention to read and ensures that until the thread is ready to read and calls <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a>, no other thread will read from the file descriptor. This only succeeds if the event queue is empty, and if not -1 is returned and errno set to EAGAIN.</p><p>If a thread successfully calls <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a>, it must either call <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a> when it's ready or cancel the read intention by calling <a class="link" href="apb.html#Client-classwl__display_1a978fcabf13f1915e565435ab097bd590">wl_display_cancel_read()</a>.</p><p>Use this function before polling on the display fd or integrate the fd into a toolkit event loop in a race-free way. A correct usage would be (with most error checking left out):</p><p>
-          </p><pre class="programlisting">while (wl_display_prepare_read_queue(display, queue) != 0)
-        wl_display_dispatch_queue_pending(display, queue);
-wl_display_flush(display);
-
-ret = poll(fds, nfds, -1);
-if (has_error(ret))
-        wl_display_cancel_read(display);
-else
-        wl_display_read_events(display);
-
-wl_display_dispatch_queue_pending(display, queue);
-</pre><p>
-        </p><p>Here we call <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a>, which ensures that between returning from that call and eventually calling <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a>, no other thread will read from the fd and queue events in our queue. If the call to <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> fails, we dispatch the pending events and try again until we're successful.</p><p>The <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> function doesn't acquire exclusive access to the display's fd. It only registers that the thread calling this function has intention to read from fd. When all registered readers call <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a>, only one (at random) eventually reads and queues the events and the others are sleeping meanwhile. This way we avoid races and still can read from more threads.</p><p>
-  See also: <a class="link" href="apb.html#Client-classwl__display_1a978fcabf13f1915e565435ab097bd590">wl_display_cancel_read()</a>, <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a>, <a class="link" href="apb.html#Client-classwl__display_1a040dca18775e3177883f06bd6fdf395f">wl_display_prepare_read()</a> 
-</p></dd><dt><a name="Client-classwl__display_1a040dca18775e3177883f06bd6fdf395f"></a><span class="term">wl_display_prepare_read
-            - 
-Prepare to read events from the display's file descriptor.         </span></dt><dd><pre class="synopsis">int wl_display_prepare_read(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success or -1 if event queue was not empty</dd></dl></div><p>
-This function does the same thing as <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> with the default queue passed as the queue.</p><p>
-  See also: <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue</a> 
-</p></dd><dt><a name="Client-classwl__display_1a978fcabf13f1915e565435ab097bd590"></a><span class="term">wl_display_cancel_read
-            - 
-Cancel read intention on display's fd.         </span></dt><dd><pre class="synopsis">void wl_display_cancel_read(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object</dd></dl></div><p>
-After a thread successfully called <a class="link" href="apb.html#Client-classwl__display_1a040dca18775e3177883f06bd6fdf395f">wl_display_prepare_read()</a> it must either call <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a> or <a class="link" href="apb.html#Client-classwl__display_1a978fcabf13f1915e565435ab097bd590">wl_display_cancel_read()</a>. If the threads do not follow this rule it will lead to deadlock.</p><p>
-  See also: <a class="link" href="apb.html#Client-classwl__display_1a040dca18775e3177883f06bd6fdf395f">wl_display_prepare_read()</a>, <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a> 
-</p></dd><dt><a name="Client-classwl__display_1ae027b09801474ac7c6b0f1ef25ff6e17"></a><span class="term">wl_display_dispatch_queue
-            - 
-Dispatch events in an event queue.         </span></dt><dd><pre class="synopsis">int wl_display_dispatch_queue(struct wl_display *display, struct wl_event_queue *queue)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd><dt><span class="term">queue</span></dt><dd>
-The event queue to dispatch </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The number of dispatched events on success or -1 on failure</dd></dl></div><p>
-Dispatch events on the given event queue.</p><p>If the given event queue is empty, this function blocks until there are events to be read from the display fd. Events are read and queued on the appropriate event queues. Finally, events on given event queue are dispatched. On failure -1 is returned and errno set appropriately.</p><p>In a multi threaded environment, do not manually wait using poll() (or equivalent) before calling this function, as doing so might cause a dead lock. If external reliance on poll() (or equivalent) is required, see <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> of how to do so.</p><p>This function is thread safe as long as it dispatches the right queue on the right thread. It is also compatible with the multi thread event reading preparation API (see <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a>), and uses the equivalent functionality internally. It is not allowed to call this function while the thread is being prepared for reading events, and doing so will cause a dead lock.</p><p>It can be used as a helper function to ease the procedure of reading and dispatching events.</p><p><span class="emphasis"><em>Note: Since Wayland 1.5 the display has an extra queue for its own events (i. e. delete_id). This queue is dispatched always, no matter what queue we passed as an argument to this function. That means that this function can return non-0 value even when it haven't dispatched any event for the given queue.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-classwl__display_1a30a9c4f020f3e77581c7a81ecdb4913d">wl_display_dispatch()</a>, <a class="link" href="apb.html#Client-classwl__display_1ac4b6b5ad31932bc3830ff362d2938560">wl_display_dispatch_pending()</a>, <a class="link" href="apb.html#Client-classwl__display_1a8a14a809eb2c083a806db2ee15523041">wl_display_dispatch_queue_pending()</a>, <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> 
-</p></dd><dt><a name="Client-classwl__display_1a8a14a809eb2c083a806db2ee15523041"></a><span class="term">wl_display_dispatch_queue_pending
-            - 
-Dispatch pending events in an event queue.         </span></dt><dd><pre class="synopsis">int wl_display_dispatch_queue_pending(struct wl_display *display, struct wl_event_queue *queue)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd><dt><span class="term">queue</span></dt><dd>
-The event queue to dispatch </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The number of dispatched events on success or -1 on failure</dd></dl></div><p>
-Dispatch all incoming events for objects assigned to the given event queue. On failure -1 is returned and errno set appropriately. If there are no events queued, this function returns immediately.</p><p>
-  Since: 1.0.2 
-</p></dd><dt><a name="Client-classwl__display_1a30a9c4f020f3e77581c7a81ecdb4913d"></a><span class="term">wl_display_dispatch
-            - 
-Process incoming events.         </span></dt><dd><pre class="synopsis">int wl_display_dispatch(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The number of dispatched events on success or -1 on failure</dd></dl></div><p>
-Dispatch events on the default event queue.</p><p>If the default event queue is empty, this function blocks until there are events to be read from the display fd. Events are read and queued on the appropriate event queues. Finally, events on the default event queue are dispatched. On failure -1 is returned and errno set appropriately.</p><p>In a multi threaded environment, do not manually wait using poll() (or equivalent) before calling this function, as doing so might cause a dead lock. If external reliance on poll() (or equivalent) is required, see <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a> of how to do so.</p><p>This function is thread safe as long as it dispatches the right queue on the right thread. It is also compatible with the multi thread event reading preparation API (see <a class="link" href="apb.html#Client-classwl__display_1a40039c1169b153269a3dc0796a54ddb0">wl_display_prepare_read_queue()</a>), and uses the equivalent functionality internally. It is not allowed to call this function while the thread is being prepared for reading events, and doing so will cause a dead lock.</p><p><span class="emphasis"><em>Note: It is not possible to check if there are events on the queue or not. For dispatching default queue events without blocking, see <a class="link" href="apb.html#Client-classwl__display_1ac4b6b5ad31932bc3830ff362d2938560">wl_display_dispatch_pending()</a>.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-classwl__display_1ac4b6b5ad31932bc3830ff362d2938560">wl_display_dispatch_pending()</a>, <a class="link" href="apb.html#Client-classwl__display_1ae027b09801474ac7c6b0f1ef25ff6e17">wl_display_dispatch_queue()</a>, <a class="link" href="apb.html#Client-classwl__display_1a1b1619d9b0930a6d1b70ccd1488335b4">wl_display_read_events()</a> 
-</p></dd><dt><a name="Client-classwl__display_1ac4b6b5ad31932bc3830ff362d2938560"></a><span class="term">wl_display_dispatch_pending
-            - 
-Dispatch default queue events without reading from the display fd.         </span></dt><dd><pre class="synopsis">int wl_display_dispatch_pending(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The number of dispatched events or -1 on failure</dd></dl></div><p>
-This function dispatches events on the main event queue. It does not attempt to read the display fd and simply returns zero if the main queue is empty, i.e., it doesn't block.</p><p>
-  See also: <a class="link" href="apb.html#Client-classwl__display_1a30a9c4f020f3e77581c7a81ecdb4913d">wl_display_dispatch()</a>, <a class="link" href="apb.html#Client-classwl__display_1ae027b09801474ac7c6b0f1ef25ff6e17">wl_display_dispatch_queue()</a>, <a class="link" href="apb.html#Client-classwl__display_1a8463b6e5f4cf9a2a3ad2d543aedcf429">wl_display_flush()</a> 
-</p></dd><dt><a name="Client-classwl__display_1a1ceca1c6f280ac1308ee0e16cd186f94"></a><span class="term">wl_display_get_error
-            - 
-Retrieve the last error that occurred on a display.         </span></dt><dd><pre class="synopsis">int wl_display_get_error(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The last error that occurred on display or 0 if no error occurred</dd></dl></div><p>
-Return the last error that occurred on the display. This may be an error sent by the server or caused by the local client.</p><p><span class="emphasis"><em>Note: Errors are fatal. If this function returns non-zero the display can no longer be used. </em></span>
-</p></dd><dt><a name="Client-classwl__display_1a8fbec062c9430f8cbdf71a12ec443f7d"></a><span class="term">wl_display_get_protocol_error
-            - 
-Retrieves the information about a protocol error:         </span></dt><dd><pre class="synopsis">uint32_t wl_display_get_protocol_error(struct wl_display *display, const struct wl_interface **interface, uint32_t *id)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The Wayland display </dd><dt><span class="term">interface</span></dt><dd>
-if not NULL, stores the interface where the error occurred, or NULL, if unknown. </dd><dt><span class="term">id</span></dt><dd>
-if not NULL, stores the object id that generated the error, or 0, if the object id is unknown. There's no guarantee the object is still valid; the client must know if it deleted the object. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The error code as defined in the interface specification.</dd></dl></div><p>
-</p><pre class="programlisting">int err = wl_display_get_error(display);
-
-if (err == EPROTO) {
-       code = wl_display_get_protocol_error(display, &interface, &id);
-       handle_error(code, interface, id);
-}
-
-...
-</pre><p> </p></dd><dt><a name="Client-classwl__display_1a8463b6e5f4cf9a2a3ad2d543aedcf429"></a><span class="term">wl_display_flush
-            - 
-Send all buffered requests on the display to the server.         </span></dt><dd><pre class="synopsis">int wl_display_flush(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display context object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The number of bytes sent on success or -1 on failure</dd></dl></div><p>
-Send all buffered data on the client side to the server. Clients should always call this function before blocking on input from the display fd. On success, the number of bytes sent to the server is returned. On failure, this function returns -1 and errno is set appropriately.</p><p><a class="link" href="apb.html#Client-classwl__display_1a8463b6e5f4cf9a2a3ad2d543aedcf429">wl_display_flush()</a> never blocks. It will write as much data as possible, but if all data could not be written, errno will be set to EAGAIN and -1 returned. In that case, use poll on the display file descriptor to wait for it to become writable again. </p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Client-classwl__event__queue"></a>wl_event_queue
-                - 
-A queue for wl_proxy object events.     </h2></div></div></div><p>Event queues allows the events on a display to be handled in a thread-safe manner. See <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> for details. </p><div class="variablelist"><dl class="variablelist"><dt><a name="Client-classwl__event__queue_1acfbc75d82d1f8a90e805712b972c4edf"></a><span class="term">wl_event_queue_destroy
-            - 
-Destroy an event queue.         </span></dt><dd><pre class="synopsis">void wl_event_queue_destroy(struct wl_event_queue *queue)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">queue</span></dt><dd>
-The event queue to be destroyed</dd></dl></div><p>
-Destroy the given event queue. Any pending event on that queue is discarded.</p><p>The <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> object used to create the queue should not be destroyed until all event queues created with it are destroyed with this function. </p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Client-structwl__interface"></a>wl_interface
-                - 
-Protocol object interface.     </h2></div></div></div><p>A <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> describes the API of a protocol object defined in the Wayland protocol specification. The protocol implementation uses a <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> within its marshalling machinery for encoding client requests.</p><p>The name of a <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> is the name of the corresponding protocol interface, and version represents the version of the interface. The members method_count and event_count represent the number of methods (requests) and events in the respective <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> members.</p><p>For example, consider a protocol interface foo, marked as version 1, with two requests and one event.</p><p>
-    </p><pre class="programlisting"><interface name="foo" version="1">
-  <request name="a"></request>
-  <request name="b"></request>
-  <event name="c"></event>
-</interface>
-</pre><p>
-  </p><p>Given two <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> arrays foo_requests and foo_events, a <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> for foo might be:</p><p>
-    </p><pre class="programlisting">struct wl_interface foo_interface = {
-        "foo", 1,
-        2, foo_requests,
-        1, foo_events
-};
-</pre><p>
-  </p><p><span class="emphasis"><em>Note: The server side of the protocol may define interface implementation types that incorporate the term interface in their name. Take care to not confuse these server-side structs with a <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> variable whose name also ends in interface. For example, while the server may define a type struct wl_foo_interface, the client may define a struct <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> wl_foo_interface.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> 
-
-  See also: <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> 
-
-  See also: Interfaces 
-
-  See also: Versioning 
-</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Client-structwl__list"></a>wl_list
-                - 
-Doubly-linked list.     </h2></div></div></div><p>On its own, an instance of struct <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> represents the sentinel head of a doubly-linked list, and must be initialized using <a class="link" href="apb.html#Client-structwl__list_1a1d5c9d41e224538b2edf324c7f8b1ac8">wl_list_init()</a>. When empty, the list head's next and prev members point to the list head itself, otherwise next references the first element in the list, and prev refers to the last element in the list.</p><p>Use the struct <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> type to represent both the list head and the links between elements within the list. Use <a class="link" href="apb.html#Client-structwl__list_1a5c6aa8f61fa63374f1c77e7e4462a38a">wl_list_empty()</a> to determine if the list is empty in O(1).</p><p>All elements in the list must be of the same type. The element type must have a struct <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> member, often named link by convention. Prior to insertion, there is no need to initialize an element's link - invoking <a class="link" href="apb.html#Client-structwl__list_1a1d5c9d41e224538b2edf324c7f8b1ac8">wl_list_init()</a> on an individual list element's struct <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> member is unnecessary if the very next operation is <a class="link" href="apb.html#Client-structwl__list_1aa7eaac0d363c0473bfc3e8172b0dfd98">wl_list_insert()</a>. However, a common idiom is to initialize an element's link prior to removal - ensure safety by invoking <a class="link" href="apb.html#Client-structwl__list_1a1d5c9d41e224538b2edf324c7f8b1ac8">wl_list_init()</a> before <a class="link" href="apb.html#Client-structwl__list_1aa16d739aaa041dde9d34ad4bcb4d4c83">wl_list_remove()</a>.</p><p>Consider a list reference struct <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> foo_list, an element type as struct element, and an element's link member as struct <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> link.</p><p>The following code initializes a list and adds three elements to it.</p><p>
-    </p><pre class="programlisting">struct wl_list foo_list;
-
-struct element {
-        int foo;
-        struct wl_list link;
-};
-struct element e1, e2, e3;
-
-wl_list_init(&foo_list);
-wl_list_insert(&foo_list, &e1.link);   // e1 is the first element
-wl_list_insert(&foo_list, &e2.link);   // e2 is now the first element
-wl_list_insert(&e2.link, &e3.link); // insert e3 after e2
-</pre><p>
-  </p><p>The list now looks like [e2, e3, e1].</p><p>The <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> API provides some iterator macros. For example, to iterate a list in ascending order:</p><p>
-    </p><pre class="programlisting">struct element *e;
-wl_list_for_each(e, foo_list, link) {
-        do_something_with_element(e);
-}
-</pre><p>
-  </p><p>See the documentation of each iterator for details. 
-  See also: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/list.h 
-</p><div class="variablelist"><dl class="variablelist"><dt><a name="Client-structwl__list_1a72c2827d3103691f9e3299babfbf0704"></a><span class="term">prev
-            - 
-Previous list element.         </span></dt><dd><pre class="synopsis">struct wl_list* wl_list::prev</pre></dd><dt><a name="Client-structwl__list_1aa0454596900ed769fb2f033fbb96bf2c"></a><span class="term">next
-            - 
-Next list element.         </span></dt><dd><pre class="synopsis">struct wl_list* wl_list::next</pre></dd><dt><a name="Client-structwl__list_1a1d5c9d41e224538b2edf324c7f8b1ac8"></a><span class="term">wl_list_init
-            - 
-Initializes the list.         </span></dt><dd><pre class="synopsis">void wl_list_init(struct wl_list *list)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List to initialize </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__list_1aa7eaac0d363c0473bfc3e8172b0dfd98"></a><span class="term">wl_list_insert
-            - 
-Inserts an element into the list, after the element represented by list.         </span></dt><dd><pre class="synopsis">void wl_list_insert(struct wl_list *list, struct wl_list *elm)</pre><p>When list is a reference to the list itself (the head), set the containing struct of elm as the first element in the list.</p><p><span class="emphasis"><em>Note: If elm is already part of a list, inserting it again will lead to list corruption.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List element after which the new element is inserted </dd><dt><span class="term">elm</span></dt><dd>
-Link of the containing struct to insert into the list </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__list_1aa16d739aaa041dde9d34ad4bcb4d4c83"></a><span class="term">wl_list_remove
-            - 
-Removes an element from the list.         </span></dt><dd><pre class="synopsis">void wl_list_remove(struct wl_list *elm)</pre><p><span class="emphasis"><em>Note: This operation leaves elm in an invalid state.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">elm</span></dt><dd>
-Link of the containing struct to remove from the list </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__list_1a2710186b02864dc2b18a46993aa9c2e0"></a><span class="term">wl_list_length
-            - 
-Determines the length of the list.         </span></dt><dd><pre class="synopsis">int wl_list_length(const struct wl_list *list)</pre><p><span class="emphasis"><em>Note: This is an O(n) operation.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List whose length is to be determined</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>Number of elements in the list </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__list_1a5c6aa8f61fa63374f1c77e7e4462a38a"></a><span class="term">wl_list_empty
-            - 
-Determines if the list is empty.         </span></dt><dd><pre class="synopsis">int wl_list_empty(const struct wl_list *list)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List whose emptiness is to be determined</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>1 if empty, or 0 if not empty </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__list_1ac714f6eedd52286c8b6d9884cc7c8492"></a><span class="term">wl_list_insert_list
-            - 
-Inserts all of the elements of one list into another, after the element represented by list.         </span></dt><dd><pre class="synopsis">void wl_list_insert_list(struct wl_list *list, struct wl_list *other)</pre><p><span class="emphasis"><em>Note: This leaves other in an invalid state.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List element after which the other list elements will be inserted </dd><dt><span class="term">other</span></dt><dd>
-List of elements to insert </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb"></a><span class="term">wl_list_for_each
-            - 
-Iterates over a list.         </span></dt><dd><pre class="synopsis"></pre><p>This macro expresses a for-each iterator for <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a>. Given a list and <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> link member name (often named link by convention), this macro assigns each element in the list to pos, which can then be referenced in a trailing code block. For example, given a <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> of struct message elements:</p><p>
-          </p><pre class="programlisting">struct message {
-        char *contents;
-        wl_list link;
-};
-
-struct wl_list *message_list;
-// Assume message_list now "contains" many messages
-
-struct message *m;
-wl_list_for_each(m, message_list, link) {
-        do_something_with_message(m);
-}
-</pre><p>
-        </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each list element will be assigned to </dd><dt><span class="term">head</span></dt><dd>
-Head of the list to iterate over </dd><dt><span class="term">member</span></dt><dd>
-Name of the link member within the element struct </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__list_1a43d51e3b5ae8b58f3391f3d43687f852"></a><span class="term">wl_list_for_each_safe
-            - 
-Iterates over a list, safe against removal of the list element.         </span></dt><dd><pre class="synopsis"></pre><p><span class="emphasis"><em>Note: Only removal of the current element, pos, is safe. Removing any other element during traversal may lead to a loop malfunction.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb">wl_list_for_each()</a>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each list element will be assigned to </dd><dt><span class="term">tmp</span></dt><dd>
-Temporary pointer of the same type as pos </dd><dt><span class="term">head</span></dt><dd>
-Head of the list to iterate over </dd><dt><span class="term">member</span></dt><dd>
-Name of the link member within the element struct </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__list_1a2ee1918119b03d36ed3004984efb9dc9"></a><span class="term">wl_list_for_each_reverse
-            - 
-Iterates backwards over a list.         </span></dt><dd><pre class="synopsis"></pre><p>
-  See also: <a class="link" href="apb.html#Client-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb">wl_list_for_each()</a>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each list element will be assigned to </dd><dt><span class="term">head</span></dt><dd>
-Head of the list to iterate over </dd><dt><span class="term">member</span></dt><dd>
-Name of the link member within the element struct </dd></dl></div><p>
-</p></dd><dt><a name="Client-structwl__list_1ac84e06e7914226b2678ff5f351d7f9e8"></a><span class="term">wl_list_for_each_reverse_safe
-            - 
-Iterates backwards over a list, safe against removal of the list element.         </span></dt><dd><pre class="synopsis"></pre><p><span class="emphasis"><em>Note: Only removal of the current element, pos, is safe. Removing any other element during traversal may lead to a loop malfunction.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb">wl_list_for_each()</a>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each list element will be assigned to </dd><dt><span class="term">tmp</span></dt><dd>
-Temporary pointer of the same type as pos </dd><dt><span class="term">head</span></dt><dd>
-Head of the list to iterate over </dd><dt><span class="term">member</span></dt><dd>
-Name of the link member within the element struct </dd></dl></div><p>
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Client-structwl__message"></a>wl_message
-                - 
-Protocol message signature.     </h2></div></div></div><p>A <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> describes the signature of an actual protocol message, such as a request or event, that adheres to the Wayland protocol wire format. The protocol implementation uses a <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> within its demarshal machinery for decoding messages between a compositor and its clients. In a sense, a <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> is to a protocol message like a class is to an object.</p><p>The name of a <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> is the name of the corresponding protocol message.</p><p>The signature is an ordered list of symbols representing the data types of message arguments and, optionally, a protocol version and indicators for nullability. A leading integer in the signature indicates the since version of the protocol message. A ? preceding a data type symbol indicates that the following argument type is nullable. While it is a protocol violation to send messages with non-nullable arguments set to NULL, event handlers in clients might still get called with non-nullable object arguments set to NULL. This can happen when the client destroyed the object being used as argument on its side and an event referencing that object was sent before the server knew about its destruction. As this race cannot be prevented, clients should - as a general rule - program their event handlers such that they can handle object arguments declared non-nullable being NULL gracefully.</p><p>When no arguments accompany a message, signature is an empty string.</p><p>Symbols:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">i: int</li><li class="listitem">u: uint</li><li class="listitem">f: fixed</li><li class="listitem">s: string</li><li class="listitem">o: object</li><li class="listitem">n: new_id</li><li class="listitem">a: array</li><li class="listitem">h: fd</li><li class="listitem">?: following argument is nullable</li></ul></div><p>
-</p><p>While demarshaling primitive arguments is straightforward, when demarshaling messages containing object or new_id arguments, the protocol implementation often must determine the type of the object. The types of a <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> is an array of <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> references that correspond to o and n arguments in signature, with NULL placeholders for arguments with non-object types.</p><p>Consider the protocol event <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> delete_id that has a single uint argument. The <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> is:</p><p>
-    </p><pre class="programlisting">{ "delete_id", "u", [NULL] }
-</pre><p>
-  </p><p>Here, the message name is "delete_id", the signature is "u", and the argument types is [NULL], indicating that the uint argument has no corresponding <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> since it is a primitive argument.</p><p>In contrast, consider a wl_foo interface supporting protocol request bar that has existed since version 2, and has two arguments: a uint and an object of type wl_baz_interface that may be NULL. Such a <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> might be:</p><p>
-    </p><pre class="programlisting">{ "bar", "2u?o", [NULL, &wl_baz_interface] }
-</pre><p>
-  </p><p>Here, the message name is "bar", and the signature is "2u?o". Notice how the 2 indicates the protocol version, the u indicates the first argument type is uint, and the ?o indicates that the second argument is an object that may be NULL. Lastly, the argument types array indicates that no <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> corresponds to the first argument, while the type wl_baz_interface corresponds to the second argument.</p><p>
-  See also: <a class="link" href="apb.html#Client-unionwl__argument" title="wl_argument - Protocol message argument data types.">wl_argument</a> 
-
-  See also: <a class="link" href="apb.html#Client-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> 
-
-  See also: Wire Format 
-</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Client-classwl__proxy"></a>wl_proxy
-                - 
-Represents a protocol object on the client side.     </h2></div></div></div><p>A <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> acts as a client side proxy to an object existing in the compositor. The proxy is responsible for converting requests made by the clients with <a class="link" href="apb.html#Client-classwl__proxy_1a1430215e7558bfea8179c1a5d7201a7f">wl_proxy_marshal()</a> into Wayland's wire format. Events coming from the compositor are also handled by the proxy, which will in turn call the handler set with <a class="link" href="apb.html#Client-classwl__proxy_1a29a8596b88ede807f96a63c128c6e8b7">wl_proxy_add_listener()</a>.</p><p><span class="emphasis"><em>Note: With the exception of function <a class="link" href="apb.html#Client-classwl__proxy_1acc5f51ea5d172df68f61018b2879e0cc">wl_proxy_set_queue()</a>, functions accessing a <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> are not normally used by client code. Clients should normally use the higher level interface generated by the scanner to interact with compositor objects. </em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><a name="Client-classwl__proxy_1a5917991abd28c23949ad200e9399e813"></a><span class="term">wl_proxy_create
-            - 
-Create a proxy object with a given interface.         </span></dt><dd><pre class="synopsis">struct wl_proxy * wl_proxy_create(struct wl_proxy *factory, const struct wl_interface *interface)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">factory</span></dt><dd>
-Factory proxy object </dd><dt><span class="term">interface</span></dt><dd>
-Interface the proxy object should use </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A newly allocated proxy object or NULL on failure</dd></dl></div><p>
-This function creates a new proxy object with the supplied interface. The proxy object will have an id assigned from the client id space. The id should be created on the compositor side by sending an appropriate request with <a class="link" href="apb.html#Client-classwl__proxy_1a1430215e7558bfea8179c1a5d7201a7f">wl_proxy_marshal()</a>.</p><p>The proxy will inherit the display and event queue of the factory object.</p><p><span class="emphasis"><em>Note: This should not normally be used by non-generated code.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a>, <a class="link" href="apb.html#Client-classwl__event__queue" title="wl_event_queue - A queue for wl_proxy object events.">wl_event_queue</a>, <a class="link" href="apb.html#Client-classwl__proxy_1a1430215e7558bfea8179c1a5d7201a7f">wl_proxy_marshal()</a> 
-</p></dd><dt><a name="Client-classwl__proxy_1a2d3fe909fed5b7ace56ca01178763381"></a><span class="term">wl_proxy_destroy
-            - 
-Destroy a proxy object.         </span></dt><dd><pre class="synopsis">void wl_proxy_destroy(struct wl_proxy *proxy)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy to be destroyed</dd></dl></div><p>
-proxy must not be a proxy wrapper. </p></dd><dt><a name="Client-classwl__proxy_1a29a8596b88ede807f96a63c128c6e8b7"></a><span class="term">wl_proxy_add_listener
-            - 
-Set a proxy's listener.         </span></dt><dd><pre class="synopsis">int wl_proxy_add_listener(struct wl_proxy *proxy, void(**implementation)(void), void *data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">implementation</span></dt><dd>
-The listener to be added to proxy </dd><dt><span class="term">data</span></dt><dd>
-User data to be associated with the proxy </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success or -1 on failure</dd></dl></div><p>
-Set proxy's listener to implementation and its user data to data. If a listener has already been set, this function fails and nothing is changed.</p><p>implementation is a vector of function pointers. For an opcode n, implementation[n] should point to the handler of n for the given object.</p><p>proxy must not be a proxy wrapper. </p></dd><dt><a name="Client-classwl__proxy_1a30175804b647e683773172d50812c88f"></a><span class="term">wl_proxy_get_listener
-            - 
-Get a proxy's listener.         </span></dt><dd><pre class="synopsis">const void * wl_proxy_get_listener(struct wl_proxy *proxy)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The address of the proxy's listener or NULL if no listener is set</dd></dl></div><p>
-Gets the address to the proxy's listener; which is the listener set with <a class="link" href="apb.html#Client-classwl__proxy_1a29a8596b88ede807f96a63c128c6e8b7">wl_proxy_add_listener</a>.</p><p>This function is useful in clients with multiple listeners on the same interface to allow the identification of which code to execute. </p></dd><dt><a name="Client-classwl__proxy_1a45ec4f95c2cead639976b27bf4af55c1"></a><span class="term">wl_proxy_add_dispatcher
-            - 
-Set a proxy's listener (with dispatcher)         </span></dt><dd><pre class="synopsis">int wl_proxy_add_dispatcher(struct wl_proxy *proxy, wl_dispatcher_func_t dispatcher, const void *implementation, void *data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">dispatcher</span></dt><dd>
-The dispatcher to be used for this proxy </dd><dt><span class="term">implementation</span></dt><dd>
-The dispatcher-specific listener implementation </dd><dt><span class="term">data</span></dt><dd>
-User data to be associated with the proxy </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success or -1 on failure</dd></dl></div><p>
-Set proxy's listener to use dispatcher_func as its dispatcher and dispatcher_data as its dispatcher-specific implementation and its user data to data. If a listener has already been set, this function fails and nothing is changed.</p><p>The exact details of dispatcher_data depend on the dispatcher used. This function is intended to be used by language bindings, not user code.</p><p>proxy must not be a proxy wrapper. </p></dd><dt><a name="Client-classwl__proxy_1a8e89b859b28d48949a1b4b00e9a39f05"></a><span class="term">wl_proxy_marshal_array_constructor
-            - 
-Prepare a request to be sent to the compositor.         </span></dt><dd><pre class="synopsis">struct wl_proxy * wl_proxy_marshal_array_constructor(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">opcode</span></dt><dd>
-Opcode of the request to be sent </dd><dt><span class="term">args</span></dt><dd>
-Extra arguments for the given request </dd><dt><span class="term">interface</span></dt><dd>
-The interface to use for the new proxy</dd></dl></div><p>
-This function translates a request given an opcode, an interface and a <a class="link" href="apb.html#Client-unionwl__argument" title="wl_argument - Protocol message argument data types.">wl_argument</a> array to the wire format and writes it to the connection buffer.</p><p>For new-id arguments, this function will allocate a new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> and send the ID to the server. The new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> will be returned on success or NULL on error with errno set accordingly. The newly created proxy will inherit their version from their parent.</p><p><span class="emphasis"><em>Note: This is intended to be used by language bindings and not in non-generated code.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-classwl__proxy_1a1430215e7558bfea8179c1a5d7201a7f">wl_proxy_marshal()</a> 
-</p></dd><dt><a name="Client-classwl__proxy_1ae61b4c579eba754bdbefd04c0e3f8b13"></a><span class="term">wl_proxy_marshal_array_constructor_versioned
-            - 
-Prepare a request to be sent to the compositor.         </span></dt><dd><pre class="synopsis">struct wl_proxy * wl_proxy_marshal_array_constructor_versioned(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface, uint32_t version)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">opcode</span></dt><dd>
-Opcode of the request to be sent </dd><dt><span class="term">args</span></dt><dd>
-Extra arguments for the given request </dd><dt><span class="term">interface</span></dt><dd>
-The interface to use for the new proxy </dd><dt><span class="term">version</span></dt><dd>
-The protocol object version for the new proxy</dd></dl></div><p>
-Translates the request given by opcode and the extra arguments into the wire format and write it to the connection buffer. This version takes an array of the union type <a class="link" href="apb.html#Client-unionwl__argument" title="wl_argument - Protocol message argument data types.">wl_argument</a>.</p><p>For new-id arguments, this function will allocate a new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> and send the ID to the server. The new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> will be returned on success or NULL on error with errno set accordingly. The newly created proxy will have the version specified.</p><p><span class="emphasis"><em>Note: This is intended to be used by language bindings and not in non-generated code.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-classwl__proxy_1a1430215e7558bfea8179c1a5d7201a7f">wl_proxy_marshal()</a> 
-</p></dd><dt><a name="Client-classwl__proxy_1a1430215e7558bfea8179c1a5d7201a7f"></a><span class="term">wl_proxy_marshal
-            - 
-Prepare a request to be sent to the compositor.         </span></dt><dd><pre class="synopsis">void wl_proxy_marshal(struct wl_proxy *proxy, uint32_t opcode,...)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">opcode</span></dt><dd>
-Opcode of the request to be sent </dd><dt><span class="term">...</span></dt><dd>
-Extra arguments for the given request</dd></dl></div><p>
-This function is similar to <a class="link" href="apb.html#Client-classwl__proxy_1aa2d70d86a2467bf20867fb93699a6d28">wl_proxy_marshal_constructor()</a>, except it doesn't create proxies for new-id arguments.</p><p><span class="emphasis"><em>Note: This should not normally be used by non-generated code.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-classwl__proxy_1a5917991abd28c23949ad200e9399e813">wl_proxy_create()</a> 
-</p></dd><dt><a name="Client-classwl__proxy_1aa2d70d86a2467bf20867fb93699a6d28"></a><span class="term">wl_proxy_marshal_constructor
-            - 
-Prepare a request to be sent to the compositor.         </span></dt><dd><pre class="synopsis">struct wl_proxy * wl_proxy_marshal_constructor(struct wl_proxy *proxy, uint32_t opcode, const struct wl_interface *interface,...)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">opcode</span></dt><dd>
-Opcode of the request to be sent </dd><dt><span class="term">interface</span></dt><dd>
-The interface to use for the new proxy </dd><dt><span class="term">...</span></dt><dd>
-Extra arguments for the given request </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> for the new_id argument or NULL on error</dd></dl></div><p>
-This function translates a request given an opcode, an interface and extra arguments to the wire format and writes it to the connection buffer. The types of the extra arguments must correspond to the argument types of the method associated with the opcode in the interface.</p><p>For new-id arguments, this function will allocate a new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> and send the ID to the server. The new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> will be returned on success or NULL on error with errno set accordingly. The newly created proxy will inherit their version from their parent.</p><p><span class="emphasis"><em>Note: This should not normally be used by non-generated code. </em></span>
-</p></dd><dt><a name="Client-classwl__proxy_1a397e6d324ce0c262afe09d365be2b8e2"></a><span class="term">wl_proxy_marshal_constructor_versioned
-            - 
-Prepare a request to be sent to the compositor.         </span></dt><dd><pre class="synopsis">struct wl_proxy * wl_proxy_marshal_constructor_versioned(struct wl_proxy *proxy, uint32_t opcode, const struct wl_interface *interface, uint32_t version,...)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">opcode</span></dt><dd>
-Opcode of the request to be sent </dd><dt><span class="term">interface</span></dt><dd>
-The interface to use for the new proxy </dd><dt><span class="term">version</span></dt><dd>
-The protocol object version of the new proxy </dd><dt><span class="term">...</span></dt><dd>
-Extra arguments for the given request </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> for the new_id argument or NULL on error</dd></dl></div><p>
-Translates the request given by opcode and the extra arguments into the wire format and write it to the connection buffer.</p><p>For new-id arguments, this function will allocate a new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> and send the ID to the server. The new <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> will be returned on success or NULL on error with errno set accordingly. The newly created proxy will have the version specified.</p><p><span class="emphasis"><em>Note: This should not normally be used by non-generated code. </em></span>
-</p></dd><dt><a name="Client-classwl__proxy_1a8f4cc90edff2f7bd3dfbb2db57f7d873"></a><span class="term">wl_proxy_marshal_array
-            - 
-Prepare a request to be sent to the compositor.         </span></dt><dd><pre class="synopsis">void wl_proxy_marshal_array(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">opcode</span></dt><dd>
-Opcode of the request to be sent </dd><dt><span class="term">args</span></dt><dd>
-Extra arguments for the given request</dd></dl></div><p>
-This function is similar to <a class="link" href="apb.html#Client-classwl__proxy_1a8e89b859b28d48949a1b4b00e9a39f05">wl_proxy_marshal_array_constructor()</a>, except it doesn't create proxies for new-id arguments.</p><p><span class="emphasis"><em>Note: This is intended to be used by language bindings and not in non-generated code.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-classwl__proxy_1a1430215e7558bfea8179c1a5d7201a7f">wl_proxy_marshal()</a> 
-</p></dd><dt><a name="Client-classwl__proxy_1a97fa4ee5b728a372cff9ac5164153fef"></a><span class="term">wl_proxy_set_user_data
-            - 
-Set the user data associated with a proxy.         </span></dt><dd><pre class="synopsis">void wl_proxy_set_user_data(struct wl_proxy *proxy, void *user_data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">user_data</span></dt><dd>
-The data to be associated with proxy</dd></dl></div><p>
-Set the user data associated with proxy. When events for this proxy are received, user_data will be supplied to its listener. </p></dd><dt><a name="Client-classwl__proxy_1abc50a9d788e0007f144a7bea7f170c3f"></a><span class="term">wl_proxy_get_user_data
-            - 
-Get the user data associated with a proxy.         </span></dt><dd><pre class="synopsis">void * wl_proxy_get_user_data(struct wl_proxy *proxy)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The user data associated with proxy </dd></dl></div><p>
-</p></dd><dt><a name="Client-classwl__proxy_1a918c3bff4543bcfd0d6cb689d0666db2"></a><span class="term">wl_proxy_get_version
-            - 
-Get the protocol object version of a proxy object.         </span></dt><dd><pre class="synopsis">uint32_t wl_proxy_get_version(struct wl_proxy *proxy)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The protocol object version of the proxy or 0</dd></dl></div><p>
-Gets the protocol object version of a proxy object, or 0 if the proxy was created with unversioned API.</p><p>A returned value of 0 means that no version information is available, so the caller must make safe assumptions about the object's real version.</p><p><a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a>'s version will always return 0. </p></dd><dt><a name="Client-classwl__proxy_1acd609baf53e8691c5307fdaf12d4d176"></a><span class="term">wl_proxy_get_id
-            - 
-Get the id of a proxy object.         </span></dt><dd><pre class="synopsis">uint32_t wl_proxy_get_id(struct wl_proxy *proxy)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The id the object associated with the proxy </dd></dl></div><p>
-</p></dd><dt><a name="Client-classwl__proxy_1a365697bb1c59f3714e5654348d7b480a"></a><span class="term">wl_proxy_get_class
-            - 
-Get the interface name (class) of a proxy object.         </span></dt><dd><pre class="synopsis">const char * wl_proxy_get_class(struct wl_proxy *proxy)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The interface name of the object associated with the proxy </dd></dl></div><p>
-</p></dd><dt><a name="Client-classwl__proxy_1acc5f51ea5d172df68f61018b2879e0cc"></a><span class="term">wl_proxy_set_queue
-            - 
-Assign a proxy to an event queue.         </span></dt><dd><pre class="synopsis">void wl_proxy_set_queue(struct wl_proxy *proxy, struct wl_event_queue *queue)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object </dd><dt><span class="term">queue</span></dt><dd>
-The event queue that will handle this proxy or NULL</dd></dl></div><p>
-Assign proxy to event queue. Events coming from proxy will be queued in queue from now. If queue is NULL, then the display's default queue is set to the proxy.</p><p><span class="emphasis"><em>Note: By default, the queue set in proxy is the one inherited from parent.</em></span>
-
-  See also: <a class="link" href="apb.html#Client-classwl__display_1ae027b09801474ac7c6b0f1ef25ff6e17">wl_display_dispatch_queue()</a> 
-</p></dd><dt><a name="Client-classwl__proxy_1afb9d0eb81d1fd4931f566aed090d6f28"></a><span class="term">wl_proxy_create_wrapper
-            - 
-Create a proxy wrapper for making queue assignments thread-safe.         </span></dt><dd><pre class="synopsis">void * wl_proxy_create_wrapper(void *proxy)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy</span></dt><dd>
-The proxy object to be wrapped </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A proxy wrapper for the given proxy or NULL on failure</dd></dl></div><p>
-A proxy wrapper is type of 'struct <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a>' instance that can be used when sending requests instead of using the original proxy. A proxy wrapper does not have an implementation or dispatcher, and events received on the object is still emitted on the original proxy. Trying to set an implementation or dispatcher will have no effect but result in a warning being logged.</p><p>Setting the proxy queue of the proxy wrapper will make new objects created using the proxy wrapper use the set proxy queue. Even though there is no implementation nor dispatcher, the proxy queue can be changed. This will affect the default queue of new objects created by requests sent via the proxy wrapper.</p><p>A proxy wrapper can only be destroyed using <a class="link" href="apb.html#Client-classwl__proxy_1a0261dbfa5f690667643940ab2ec1ee99">wl_proxy_wrapper_destroy()</a>.</p><p>A proxy wrapper must be destroyed before the proxy it was created from.</p><p>If a user reads and dispatches events on more than one thread, it is necessary to use a proxy wrapper when sending requests on objects when the intention is that a newly created proxy is to use a proxy queue different from the proxy the request was sent on, as creating the new proxy and then setting the queue is not thread safe.</p><p>For example, a module that runs using its own proxy queue that needs to do display roundtrip must wrap the <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">wl_display</a> proxy object before sending the wl_display.sync request. For example:</p><pre class="programlisting">struct wl_event_queue *queue = ...;
-struct wl_display *wrapped_display;
-struct wl_callback *callback;
-
-wrapped_display = wl_proxy_create_wrapper(display);
-wl_proxy_set_queue((struct wl_proxy *) wrapped_display, queue);
-callback = wl_display_sync(wrapped_display);
-wl_proxy_wrapper_destroy(wrapped_display);
-wl_callback_add_listener(callback, ...);
-</pre><p> </p></dd><dt><a name="Client-classwl__proxy_1a0261dbfa5f690667643940ab2ec1ee99"></a><span class="term">wl_proxy_wrapper_destroy
-            - 
-Destroy a proxy wrapper.         </span></dt><dd><pre class="synopsis">void wl_proxy_wrapper_destroy(void *proxy_wrapper)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">proxy_wrapper</span></dt><dd>
-The proxy wrapper to be destroyed </dd></dl></div><p>
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Client-Functions"></a>Functions</h2></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><a name="Client-wayland-client-core_8h_1acfbc75d82d1f8a90e805712b972c4edf"></a><span class="term">wl_event_queue_destroy</span></dt><dd><pre class="synopsis">void wl_event_queue_destroy(struct wl_event_queue *queue)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a090ac75892250e69176e0bebabfc9dff"></a><span class="term">wl_proxy_marshal</span></dt><dd><pre class="synopsis">void wl_proxy_marshal(struct wl_proxy *p, uint32_t opcode,...)</pre></dd><dt><a name="Client-wayland-client-core_8h_1ac73b3ca33662501fd71e564d29f80fc2"></a><span class="term">wl_proxy_marshal_array</span></dt><dd><pre class="synopsis">void wl_proxy_marshal_array(struct wl_proxy *p, uint32_t opcode, union wl_argument *args)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a83b0c474e347e65075246d239c227eca"></a><span class="term">wl_proxy_create</span></dt><dd><pre class="synopsis">struct wl_proxy* wl_proxy_create(struct wl_proxy *factory, const struct wl_interface *interface)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a9fc96dd300247a74b07e5e97e7779d78"></a><span class="term">wl_proxy_create_wrapper</span></dt><dd><pre class="synopsis">void* wl_proxy_create_wrapper(void *proxy)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a0261dbfa5f690667643940ab2ec1ee99"></a><span class="term">wl_proxy_wrapper_destroy</span></dt><dd><pre class="synopsis">void wl_proxy_wrapper_destroy(void *proxy_wrapper)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a74b1e45b6cf8d73885bf60a0973ac27b"></a><span class="term">wl_proxy_marshal_constructor</span></dt><dd><pre class="synopsis">struct wl_proxy* wl_proxy_marshal_constructor(struct wl_proxy *proxy, uint32_t opcode, const struct wl_interface *interface,...)</pre></dd><dt><a name="Client-wayland-client-core_8h_1ac50a545bda02164d6a8998df8656702f"></a><span class="term">wl_proxy_marshal_constructor_versioned</span></dt><dd><pre class="synopsis">struct wl_proxy* wl_proxy_marshal_constructor_versioned(struct wl_proxy *proxy, uint32_t opcode, const struct wl_interface *interface, uint32_t version,...)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a7f71ea679958ca01e5febf391795a256"></a><span class="term">wl_proxy_marshal_array_constructor</span></dt><dd><pre class="synopsis">struct wl_proxy* wl_proxy_marshal_array_constructor(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a4d365f3486201a1c8da23d93a649dfa9"></a><span class="term">wl_proxy_marshal_array_constructor_versioned</span></dt><dd><pre class="synopsis">struct wl_proxy* wl_proxy_marshal_array_constructor_versioned(struct wl_proxy *proxy, uint32_t opcode, union wl_argument *args, const struct wl_interface *interface, uint32_t version)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a2d3fe909fed5b7ace56ca01178763381"></a><span class="term">wl_proxy_destroy</span></dt><dd><pre class="synopsis">void wl_proxy_destroy(struct wl_proxy *proxy)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a29a8596b88ede807f96a63c128c6e8b7"></a><span class="term">wl_proxy_add_listener</span></dt><dd><pre class="synopsis">int wl_proxy_add_listener(struct wl_proxy *proxy, void(**implementation)(void), void *data)</pre></dd><dt><a name="Client-wayland-client-core_8h_1acb35a3a56239c15ad86856b4753d0684"></a><span class="term">wl_proxy_get_listener</span></dt><dd><pre class="synopsis">const void* wl_proxy_get_listener(struct wl_proxy *proxy)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a1d4975c4e2f01bddd3beaf28dd3e2818"></a><span class="term">wl_proxy_add_dispatcher</span></dt><dd><pre class="synopsis">int wl_proxy_add_dispatcher(struct wl_proxy *proxy, wl_dispatcher_func_t dispatcher_func, const void *dispatcher_data, void *data)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a97fa4ee5b728a372cff9ac5164153fef"></a><span class="term">wl_proxy_set_user_data</span></dt><dd><pre class="synopsis">void wl_proxy_set_user_data(struct wl_proxy *proxy, void *user_data)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a46da640b2112269327958ff4efd3e79f"></a><span class="term">wl_proxy_get_user_data</span></dt><dd><pre class="synopsis">void* wl_proxy_get_user_data(struct wl_proxy *proxy)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a918c3bff4543bcfd0d6cb689d0666db2"></a><span class="term">wl_proxy_get_version</span></dt><dd><pre class="synopsis">uint32_t wl_proxy_get_version(struct wl_proxy *proxy)</pre></dd><dt><a name="Client-wayland-client-core_8h_1acd609baf53e8691c5307fdaf12d4d176"></a><span class="term">wl_proxy_get_id</span></dt><dd><pre class="synopsis">uint32_t wl_proxy_get_id(struct wl_proxy *proxy)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a26926726c79c73604235728d23c10b1a"></a><span class="term">wl_proxy_get_class</span></dt><dd><pre class="synopsis">const char* wl_proxy_get_class(struct wl_proxy *proxy)</pre></dd><dt><a name="Client-wayland-client-core_8h_1acc5f51ea5d172df68f61018b2879e0cc"></a><span class="term">wl_proxy_set_queue</span></dt><dd><pre class="synopsis">void wl_proxy_set_queue(struct wl_proxy *proxy, struct wl_event_queue *queue)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a86382b9754bbb891860e6ab4ff5efa20"></a><span class="term">wl_display_connect</span></dt><dd><pre class="synopsis">struct wl_display* wl_display_connect(const char *name)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a7ef5808b89561fb447cd012e9b9c7235"></a><span class="term">wl_display_connect_to_fd</span></dt><dd><pre class="synopsis">struct wl_display* wl_display_connect_to_fd(int fd)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a9150a7e3213a58b469a6966e60a9f108"></a><span class="term">wl_display_disconnect</span></dt><dd><pre class="synopsis">void wl_display_disconnect(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a2d5d249e81cbf43c3521d4bce575f1ca"></a><span class="term">wl_display_get_fd</span></dt><dd><pre class="synopsis">int wl_display_get_fd(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a30a9c4f020f3e77581c7a81ecdb4913d"></a><span class="term">wl_display_dispatch</span></dt><dd><pre class="synopsis">int wl_display_dispatch(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1ae027b09801474ac7c6b0f1ef25ff6e17"></a><span class="term">wl_display_dispatch_queue</span></dt><dd><pre class="synopsis">int wl_display_dispatch_queue(struct wl_display *display, struct wl_event_queue *queue)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a8a14a809eb2c083a806db2ee15523041"></a><span class="term">wl_display_dispatch_queue_pending</span></dt><dd><pre class="synopsis">int wl_display_dispatch_queue_pending(struct wl_display *display, struct wl_event_queue *queue)</pre></dd><dt><a name="Client-wayland-client-core_8h_1ac4b6b5ad31932bc3830ff362d2938560"></a><span class="term">wl_display_dispatch_pending</span></dt><dd><pre class="synopsis">int wl_display_dispatch_pending(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a1ceca1c6f280ac1308ee0e16cd186f94"></a><span class="term">wl_display_get_error</span></dt><dd><pre class="synopsis">int wl_display_get_error(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a8fbec062c9430f8cbdf71a12ec443f7d"></a><span class="term">wl_display_get_protocol_error</span></dt><dd><pre class="synopsis">uint32_t wl_display_get_protocol_error(struct wl_display *display, const struct wl_interface **interface, uint32_t *id)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a8463b6e5f4cf9a2a3ad2d543aedcf429"></a><span class="term">wl_display_flush</span></dt><dd><pre class="synopsis">int wl_display_flush(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a73f44c38fa4e535f5eaf700933b0b2e6"></a><span class="term">wl_display_roundtrip_queue</span></dt><dd><pre class="synopsis">int wl_display_roundtrip_queue(struct wl_display *display, struct wl_event_queue *queue)</pre></dd><dt><a name="Client-wayland-client-core_8h_1ab60f38c2f80980ac84f347e932793390"></a><span class="term">wl_display_roundtrip</span></dt><dd><pre class="synopsis">int wl_display_roundtrip(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a6607ab92946184c1ecefba21987b0a83"></a><span class="term">wl_display_create_queue</span></dt><dd><pre class="synopsis">struct wl_event_queue* wl_display_create_queue(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a40039c1169b153269a3dc0796a54ddb0"></a><span class="term">wl_display_prepare_read_queue</span></dt><dd><pre class="synopsis">int wl_display_prepare_read_queue(struct wl_display *display, struct wl_event_queue *queue)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a040dca18775e3177883f06bd6fdf395f"></a><span class="term">wl_display_prepare_read</span></dt><dd><pre class="synopsis">int wl_display_prepare_read(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a978fcabf13f1915e565435ab097bd590"></a><span class="term">wl_display_cancel_read</span></dt><dd><pre class="synopsis">void wl_display_cancel_read(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a1b1619d9b0930a6d1b70ccd1488335b4"></a><span class="term">wl_display_read_events</span></dt><dd><pre class="synopsis">int wl_display_read_events(struct wl_display *display)</pre></dd><dt><a name="Client-wayland-client-core_8h_1a2201f511aa0db7cdb2ecdcb01d61dc9f"></a><span class="term">wl_log_set_handler_client</span></dt><dd><pre class="synopsis">void wl_log_set_handler_client(wl_log_func_t handler)</pre></dd><dt><a name="Client-wayland-client_8c_1a2201f511aa0db7cdb2ecdcb01d61dc9f"></a><span class="term">wl_log_set_handler_client</span></dt><dd><pre class="synopsis">void wl_log_set_handler_client(wl_log_func_t handler)</pre></dd><dt><a name="Client-wayland-util_8h_1a3b28bd92b6af30b28f13c09e45269d5b"></a><span class="term">WL_EXPORT
-            - 
-Visibility attribute.         </span></dt><dd><pre class="synopsis"></pre></dd><dt><a name="Client-wayland-util_8h_1a9ef5a521a018de9c5b28a5ef9909cd33"></a><span class="term">WL_DEPRECATED
-            - 
-Deprecated attribute.         </span></dt><dd><pre class="synopsis"></pre></dd><dt><a name="Client-wayland-util_8h_1aa7cbf0ab788d6898c97f322630577424"></a><span class="term">WL_PRINTF
-            - 
-Printf-style argument attribute.         </span></dt><dd><pre class="synopsis"></pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">x</span></dt><dd>
-Ordinality of the format string argument </dd><dt><span class="term">y</span></dt><dd>
-Ordinality of the argument to check against the format string</dd></dl></div><p>
-
-  See also: https://gcc.gnu.org/onlinedocs/gcc-3.2.1/gcc/Function-Attributes.html 
-</p></dd><dt><a name="Client-wayland-util_8h_1a09e3b64ee2195e1b80191aa1884d45aa"></a><span class="term">wl_container_of
-            - 
-Retrieves a pointer to a containing struct, given a member name.         </span></dt><dd><pre class="synopsis"></pre><p>This macro allows "conversion" from a pointer to a member to its containing struct. This is useful if you have a contained item like a <a class="link" href="apb.html#Client-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a>, wl_listener, or wl_signal, provided via a callback or other means, and would like to retrieve the struct that contains it.</p><p>To demonstrate, the following example retrieves a pointer to example_container given only its destroy_listener member:</p><p>
-          </p><pre class="programlisting">struct example_container {
-        struct wl_listener destroy_listener;
-        // other members...
-};
-
-void example_container_destroy(struct wl_listener *listener, void *data)
-{
-        struct example_container *ctr;
-
-        ctr = wl_container_of(listener, ctr, destroy_listener);
-        // destroy ctr...
-}
-</pre><p>
-        </p><p><span class="emphasis"><em>Note: sample need not be a valid pointer. A null or uninitialised pointer is sufficient.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">ptr</span></dt><dd>
-Valid pointer to the contained member </dd><dt><span class="term">sample</span></dt><dd>
-Pointer to a struct whose type contains ptr </dd><dt><span class="term">member</span></dt><dd>
-Named location of ptr within the sample type</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The container for the specified pointer </dd></dl></div><p>
-</p></dd><dt><a name="Client-wayland-util_8h_1adb093d005a4b7e04111b7e385349cf23"></a><span class="term">wl_iterator_result
-            - 
-Return value of an iterator function.         </span></dt><dd><pre class="synopsis"></pre><p>
-  See also: wl_client_for_each_resource_iterator_func_t 
-
-  See also: wl_client_for_each_resource 
-</p></dd><dt><a name="Client-wayland-util_8h_1a546c8b2b06f97d0617000db4fb4feeeb"></a><span class="term">wl_fixed_t
-            - 
-Fixed-point number.         </span></dt><dd><pre class="synopsis">typedef int32_t wl_fixed_t</pre><p>A wl_fixed_t is a 24.8 signed fixed-point number with a sign bit, 23 bits of integer precision and 8 bits of decimal precision. Consider wl_fixed_t as an opaque struct with methods that facilitate conversion to and from double and int types. </p></dd><dt><a name="Client-wayland-util_8h_1abdec454d1dffed08d355d225e21ac8bd"></a><span class="term">wl_dispatcher_func_t
-            - 
-Dispatcher function type alias.         </span></dt><dd><pre class="synopsis">typedef int(* wl_dispatcher_func_t) (const void *, void *, uint32_t, const struct wl_message *, union wl_argument *))(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)</pre><p>A dispatcher is a function that handles the emitting of callbacks in client code. For programs directly using the C library, this is done by using libffi to call function pointers. When binding to languages other than C, dispatchers provide a way to abstract the function calling process to be friendlier to other function calling systems.</p><p>A dispatcher takes five arguments: The first is the dispatcher-specific implementation associated with the target object. The second is the object upon which the callback is being invoked (either <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> or wl_resource). The third and fourth arguments are the opcode and the <a class="link" href="apb.html#Client-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> corresponding to the callback. The final argument is an array of arguments received from the other process via the wire protocol.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">const void *</span></dt><dd>
-Dispatcher-specific implementation data </dd><dt><span class="term">void *</span></dt><dd>
-Callback invocation target (<a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> or wl_resource) </dd><dt><span class="term">uint32_t</span></dt><dd>
-Callback opcode </dd><dt><span class="term">const struct wl_message *</span></dt><dd>
-Callback message signature </dd><dt><span class="term">union wl_argument *</span></dt><dd>
-Array of received arguments</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success, or -1 on failure </dd></dl></div><p>
-</p></dd><dt><a name="Client-wayland-util_8h_1a8bbe3cc915acdaf00f7a183bf03d809c"></a><span class="term">wl_log_func_t
-            - 
-Log function type alias.         </span></dt><dd><pre class="synopsis">typedef void(* wl_log_func_t) (const char *, va_list))(const char *, va_list)</pre><p>The C implementation of the Wayland protocol abstracts the details of logging. Users may customize the logging behavior, with a function conforming to the wl_log_func_t type, via wl_log_set_handler_client and wl_log_set_handler_server.</p><p>A wl_log_func_t must conform to the expectations of vprintf, and expects two arguments: a string to write and a corresponding variable argument list. While the string to write may contain format specifiers and use values in the variable argument list, the behavior of any wl_log_func_t depends on the implementation.</p><p><span class="emphasis"><em>Note: Take care to not confuse this with wl_protocol_logger_func_t, which is a specific server-side logger for requests and events.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">const char *</span></dt><dd>
-String to write to the log, containing optional format specifiers </dd><dt><span class="term">va_list</span></dt><dd>
-Variable argument list</dd></dl></div><p>
-
-  See also: <a class="link" href="apb.html#Client-wayland-client-core_8h_1a2201f511aa0db7cdb2ecdcb01d61dc9f">wl_log_set_handler_client</a> 
-
-  See also: wl_log_set_handler_server 
-</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="apa.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="apc.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Appendix A. Wayland Protocol Specification </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix C. Server API</td></tr></table></div></body></html>
diff --git a/docs/html/apc.html b/docs/html/apc.html
deleted file mode 100644
index 243a291..0000000
--- a/docs/html/apc.html
+++ /dev/null
@@ -1,674 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Appendix C. Server API</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="apb.html" title="Appendix B. Client API"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Appendix C. Server API</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="apb.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> </td></tr></table><hr></div><div class="appendix"><div class="titlepage"><div><div><h1 class="title"><a name="sect-Library-Server"></a>Appendix C. Server API</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="apc.html#idm140152826989984">Introduction</a></span></dt><dt><span class="section"><a href="apc.html#Server-unionwl__argument">wl_argument
-                - 
-Protocol message argument data types.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__array">wl_array
-                - 
-Dynamic array.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__buffer">wl_buffer</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__client">wl_client</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__display">wl_display</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__event__loop">wl_event_loop
-                - 
-An event loop context.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__event__source">wl_event_source
-                - 
-An abstract event source.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__global">wl_global</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__interface">wl_interface
-                - 
-Protocol object interface.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__list">wl_list
-                - 
-Doubly-linked list.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__listener">wl_listener
-                - 
-A single listener for Wayland signals.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__message">wl_message
-                - 
-Protocol message signature.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__object">wl_object</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__protocol__logger">wl_protocol_logger</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__protocol__logger__message">wl_protocol_logger_message</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__resource">wl_resource</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__resource__iterator__context">wl_resource_iterator_context</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__shm__buffer">wl_shm_buffer</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__shm__pool">wl_shm_pool</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__shm__sigbus__data">wl_shm_sigbus_data</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__signal">wl_signal
-                - 
-A source of a type of observable event.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__socket">wl_socket</a></span></dt><dt><span class="section"><a href="apc.html#Server-Functions">Functions</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="idm140152826989984"></a>Introduction</h2></div></div></div><p>
-    The open-source reference implementation of Wayland protocol is
-    split in two C libraries, <a class="link" href="apb.html" title="Appendix B. Client API">libwayland-client</a> and
-    libwayland-server. Their main responsibility is to handle the
-    Inter-process communication (<span class="emphasis"><em>IPC</em></span>) with each
-    other, therefore guaranteeing the protocol objects marshaling and
-    messages synchronization.
-  </p><p>
-    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.
-  </p><p>
-    Each open socket to a client is represented by a <a class="link" href="apc.html#Server-structwl__client" title="wl_client">wl_client</a>.  The equvalent
-    of the <a class="link" href="apb.html#Client-classwl__proxy" title="wl_proxy - Represents a protocol object on the client side.">wl_proxy</a> that
-    libwayland-client uses to represent an object is <a class="link" href="apc.html#Server-structwl__resource" title="wl_resource">wl_resource</a> for
-    client-created objects, and <a class="link" href="apc.html#Server-structwl__global" title="wl_global">wl_global</a> for objects
-    created by the server.
-  </p><p>
-    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 <a class="link" href="apb.html#Client-classwl__display" title="wl_display - Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.">client wl_display</a> and
-    <a class="link" href="apc.html#Server-structwl__display" title="wl_display">server wl_display</a>,
-    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.
-  </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-unionwl__argument"></a>wl_argument
-                - 
-Protocol message argument data types.     </h2></div></div></div><p>This union represents all of the argument types in the Wayland protocol wire format. The protocol implementation uses <a class="link" href="apc.html#Server-unionwl__argument" title="wl_argument - Protocol message argument data types.">wl_argument</a> within its marshalling machinery for dispatching messages between a client and a compositor.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> 
-
-  See also: <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> 
-
-  See also: Wire Format 
-</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__array"></a>wl_array
-                - 
-Dynamic array.     </h2></div></div></div><p>A <a class="link" href="apc.html#Server-structwl__array" title="wl_array - Dynamic array.">wl_array</a> is a dynamic array that can only grow until released. It is intended for relatively small allocations whose size is variable or not known in advance. While construction of a <a class="link" href="apc.html#Server-structwl__array" title="wl_array - Dynamic array.">wl_array</a> does not require all elements to be of the same size, <a class="link" href="apc.html#Server-structwl__array_1ab050f7375dcae916506142763080ed80">wl_array_for_each()</a> does require all elements to have the same type and size. </p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__array_1ae246c66cbd633063e2649c503d764d3f"></a><span class="term">size
-            - 
-Array size.         </span></dt><dd><pre class="synopsis">size_t wl_array::size</pre></dd><dt><a name="Server-structwl__array_1a4b33519c8f628d650631ebecee45b771"></a><span class="term">alloc
-            - 
-Allocated space.         </span></dt><dd><pre class="synopsis">size_t wl_array::alloc</pre></dd><dt><a name="Server-structwl__array_1af20153b7fcf63135eea72dd5d9e8b87b"></a><span class="term">data
-            - 
-Array data.         </span></dt><dd><pre class="synopsis">void* wl_array::data</pre></dd><dt><a name="Server-structwl__array_1ada9b770427b901be34eaf3683cf04d5a"></a><span class="term">wl_array_init
-            - 
-Initializes the array.         </span></dt><dd><pre class="synopsis">void wl_array_init(struct wl_array *array)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">array</span></dt><dd>
-Array to initialize </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__array_1a0e8845f61f1e1fccfce050830ed5b279"></a><span class="term">wl_array_release
-            - 
-Releases the array data.         </span></dt><dd><pre class="synopsis">void wl_array_release(struct wl_array *array)</pre><p><span class="emphasis"><em>Note: Leaves the array in an invalid state.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">array</span></dt><dd>
-Array whose data is to be released </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__array_1a3c3d1079a20b0609f6e4914ea21c2d03"></a><span class="term">wl_array_add
-            - 
-Increases the size of the array by size bytes.         </span></dt><dd><pre class="synopsis">void * wl_array_add(struct wl_array *array, size_t size)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">array</span></dt><dd>
-Array whose size is to be increased </dd><dt><span class="term">size</span></dt><dd>
-Number of bytes to increase the size of the array by</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A pointer to the beginning of the newly appended space, or NULL when resizing fails. </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__array_1a4de64390294de78da813dcfb16f47617"></a><span class="term">wl_array_copy
-            - 
-Copies the contents of source to array.         </span></dt><dd><pre class="synopsis">int wl_array_copy(struct wl_array *array, struct wl_array *source)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">array</span></dt><dd>
-Destination array to copy to </dd><dt><span class="term">source</span></dt><dd>
-Source array to copy from</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success, or -1 on failure </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__array_1ab050f7375dcae916506142763080ed80"></a><span class="term">wl_array_for_each
-            - 
-Iterates over an array.         </span></dt><dd><pre class="synopsis"></pre><p>This macro expresses a for-each iterator for <a class="link" href="apc.html#Server-structwl__array" title="wl_array - Dynamic array.">wl_array</a>. It assigns each element in the array to pos, which can then be referenced in a trailing code block. pos must be a pointer to the array element type, and all array elements must be of the same type and size.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each array element will be assigned to </dd><dt><span class="term">array</span></dt><dd>
-Array to iterate over</dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb">wl_list_for_each()</a> 
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__buffer"></a>wl_buffer</h2></div></div></div><p></p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__client"></a>wl_client</h2></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__client_1a6a045ad15d6ca216c4da41ba67c9ef4a"></a><span class="term">wl_client_flush
-            - 
-Flush pending events to the client.         </span></dt><dd><pre class="synopsis">void wl_client_flush(struct wl_client *client)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The client object</dd></dl></div><p>
-Events sent to clients are queued in a buffer and written to the socket later - typically when the compositor has handled all requests and goes back to block in the event loop. This function flushes all queued up events for a client immediately. </p></dd><dt><a name="Server-structwl__client_1a9b2abda633c67a4cd06ea5d9be0482f3"></a><span class="term">wl_client_get_display
-            - 
-Get the display object for the given client.         </span></dt><dd><pre class="synopsis">struct wl_display * wl_client_get_display(struct wl_client *client)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The client object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The display object the client is associated with. </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__client_1a82a97cb3a66c1c56826a09a7b42453d9"></a><span class="term">wl_client_get_credentials
-            - 
-Return Unix credentials for the client.         </span></dt><dd><pre class="synopsis">void wl_client_get_credentials(struct wl_client *client, pid_t *pid, uid_t *uid, gid_t *gid)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The display object </dd><dt><span class="term">pid</span></dt><dd>
-Returns the process ID </dd><dt><span class="term">uid</span></dt><dd>
-Returns the user ID </dd><dt><span class="term">gid</span></dt><dd>
-Returns the group ID</dd></dl></div><p>
-This function returns the process ID, the user ID and the group ID for the given client. The credentials come from getsockopt() with SO_PEERCRED, on the client socket fd. All the pointers can be NULL, if the caller is not interested in a particular ID.</p><p>Be aware that for clients that a compositor forks and execs and then connects using socketpair(), this function will return the credentials for the compositor. The credentials for the socketpair are set at creation time in the compositor. </p></dd><dt><a name="Server-structwl__client_1ad5a94921b39efad0985632e865479ca2"></a><span class="term">wl_client_get_fd
-            - 
-Get the file descriptor for the client.         </span></dt><dd><pre class="synopsis">int wl_client_get_fd(struct wl_client *client)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The display object </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The file descriptor to use for the connection</dd></dl></div><p>
-This function returns the file descriptor for the given client.</p><p>Be sure to use the file descriptor from the client for inspection only. If the caller does anything to the file descriptor that changes its state, it will likely cause problems.</p><p>See also <a class="link" href="apc.html#Server-structwl__client_1a82a97cb3a66c1c56826a09a7b42453d9">wl_client_get_credentials()</a>. It is recommended that you evaluate whether <a class="link" href="apc.html#Server-structwl__client_1a82a97cb3a66c1c56826a09a7b42453d9">wl_client_get_credentials()</a> can be applied to your use case instead of this function.</p><p>If you would like to distinguish just between the client and the compositor itself from the client's request, it can be done by getting the client credentials and by checking the PID of the client and the compositor's PID. Regarding the case in which the socketpair() is being used, you need to be careful. Please note the documentation for <a class="link" href="apc.html#Server-structwl__client_1a82a97cb3a66c1c56826a09a7b42453d9">wl_client_get_credentials()</a>.</p><p>This function can be used for a compositor to validate a request from a client if there are additional information provided from the client's file descriptor. For instance, suppose you can get the security contexts from the client's file descriptor. The compositor can validate the client's request with the contexts and make a decision whether it permits or deny it. </p></dd><dt><a name="Server-structwl__client_1ab9d04dffa9409db43154230c64bc1f84"></a><span class="term">wl_client_get_object
-            - 
-Look up an object in the client name space.         </span></dt><dd><pre class="synopsis">struct wl_resource * wl_client_get_object(struct wl_client *client, uint32_t id)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The client object </dd><dt><span class="term">id</span></dt><dd>
-The object id </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The object or NULL if there is not object for the given ID</dd></dl></div><p>
-This looks up an object in the client object name space by its object ID. </p></dd><dt><a name="Server-structwl__client_1ade7bddc335d60cb95f9d1bd4fb60d25b"></a><span class="term">wl_client_get_link
-            - 
-Get the link by which a client is inserted in the client list.         </span></dt><dd><pre class="synopsis">struct wl_list * wl_client_get_link(struct wl_client *client)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The client object</dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-wayland-server-core_8h_1af1e9ad8dd32ea89265936930cd173ec5">wl_client_for_each()</a> 
-
-  See also: <a class="link" href="apc.html#Server-structwl__display_1a99b9c187d88633fa5ba86d1424f06d7f">wl_display_get_client_list()</a> 
-
-  See also: <a class="link" href="apc.html#Server-structwl__client_1aec831218471327f37b4e1f11b571545d">wl_client_from_link()</a> 
-</p></dd><dt><a name="Server-structwl__client_1aec831218471327f37b4e1f11b571545d"></a><span class="term">wl_client_from_link
-            - 
-Get a wl_client by its link.         </span></dt><dd><pre class="synopsis">struct wl_client * wl_client_from_link(struct wl_list *link)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">link</span></dt><dd>
-The link of a <a class="link" href="apc.html#Server-structwl__client" title="wl_client">wl_client</a></dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-wayland-server-core_8h_1af1e9ad8dd32ea89265936930cd173ec5">wl_client_for_each()</a> 
-
-  See also: <a class="link" href="apc.html#Server-structwl__display_1a99b9c187d88633fa5ba86d1424f06d7f">wl_display_get_client_list()</a> 
-
-  See also: <a class="link" href="apc.html#Server-structwl__client_1ade7bddc335d60cb95f9d1bd4fb60d25b">wl_client_get_link()</a> 
-</p></dd><dt><a name="Server-structwl__client_1a62a52be27947e43ce7884a68759d1b4e"></a><span class="term">wl_client_add_resource_created_listener
-            - 
-Add a listener for the client's resource creation signal.         </span></dt><dd><pre class="synopsis">void wl_client_add_resource_created_listener(struct wl_client *client, struct wl_listener *listener)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The client object </dd><dt><span class="term">listener</span></dt><dd>
-The listener to be added</dd></dl></div><p>
-When a new resource is created for this client the listener will be notified, carrying the new resource as the data argument. </p></dd><dt><a name="Server-structwl__client_1a4a0a6bb48f63ed80ab4575fda4c5d01a"></a><span class="term">wl_client_for_each_resource
-            - 
-Iterate over all the resources of a client.         </span></dt><dd><pre class="synopsis">void wl_client_for_each_resource(struct wl_client *client, wl_client_for_each_resource_iterator_func_t iterator, void *user_data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The client object </dd><dt><span class="term">iterator</span></dt><dd>
-The iterator function </dd><dt><span class="term">user_data</span></dt><dd>
-The user data pointer</dd></dl></div><p>
-The function pointed by iterator will be called for each resource owned by the client. The user_data will be passed as the second argument of the iterator function. If the iterator function returns WL_ITERATOR_CONTINUE the iteration will continue, if it returns WL_ITERATOR_STOP it will stop.</p><p>Creating and destroying resources while iterating is safe, but new resources may or may not be picked up by the iterator.</p><p>
-  See also: <a class="link" href="apc.html#Server-wayland-util_8h_1adb093d005a4b7e04111b7e385349cf23">wl_iterator_result</a> 
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__display"></a>wl_display</h2></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__display_1aa2436b6a0b56cd65d8f6e33b76cd292c"></a><span class="term">wl_client_create
-            - 
-Create a client for the given file descriptor.         </span></dt><dd><pre class="synopsis">struct wl_client * wl_client_create(struct wl_display *display, int fd)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display object </dd><dt><span class="term">fd</span></dt><dd>
-The file descriptor for the socket to the client </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The new client object or NULL on failure.</dd></dl></div><p>
-Given a file descriptor corresponding to one end of a socket, this function will create a <a class="link" href="apc.html#Server-structwl__client" title="wl_client">wl_client</a> struct and add the new client to the compositors client list. At that point, the client is initialized and ready to run, as if the client had connected to the servers listening socket. When the client eventually sends requests to the compositor, the <a class="link" href="apc.html#Server-structwl__client" title="wl_client">wl_client</a> argument to the request handler will be the <a class="link" href="apc.html#Server-structwl__client" title="wl_client">wl_client</a> returned from this function.</p><p>The other end of the socket can be passed to wl_display_connect_to_fd() on the client side or used with the WAYLAND_SOCKET environment variable on the client side.</p><p>Listeners added with <a class="link" href="apc.html#Server-wayland-server_8c_1a8c1cdf513c91fa498c4d9259eae3ed71">wl_display_add_client_created_listener()</a> will be notified by this function after the client is fully constructed.</p><p>On failure this function sets errno accordingly and returns NULL. </p></dd><dt><a name="Server-structwl__display_1ac3dd9a1294b2b6103228a55e08709e9f"></a><span class="term">wl_display_create
-            - 
-Create Wayland display object.         </span></dt><dd><pre class="synopsis">struct wl_display * wl_display_create(void)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The Wayland display object. Null if failed to create</dd></dl></div><p>
-This creates the <a class="link" href="apc.html#Server-structwl__display" title="wl_display">wl_display</a> object. </p></dd><dt><a name="Server-structwl__display_1acd9ad2e1ca3ffb0ba0f1b77ae616f8ee"></a><span class="term">wl_display_destroy
-            - 
-Destroy Wayland display object.         </span></dt><dd><pre class="synopsis">void wl_display_destroy(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The Wayland display object which should be destroyed. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>None.</dd></dl></div><p>
-This function emits the <a class="link" href="apc.html#Server-structwl__display" title="wl_display">wl_display</a> destroy signal, releases all the sockets added to this display, free's all the globals associated with this display, free's memory of additional shared memory formats and destroy the display object.</p><p>
-  See also: <a class="link" href="apc.html#Server-wayland-server-core_8h_1a9ea24547f07538f2a326c42c7793b937">wl_display_add_destroy_listener</a> 
-</p></dd><dt><a name="Server-structwl__display_1a3905b9734d8bb84f2c851bb4abbc52f8"></a><span class="term">wl_display_set_global_filter
-            - 
-Set a filter function for global objects.         </span></dt><dd><pre class="synopsis">void wl_display_set_global_filter(struct wl_display *display, wl_display_global_filter_func_t filter, void *data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The Wayland display object. </dd><dt><span class="term">filter</span></dt><dd>
-The global filter funtion. </dd><dt><span class="term">data</span></dt><dd>
-User data to be associated with the global filter. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>None.</dd></dl></div><p>
-Set a filter for the <a class="link" href="apc.html#Server-structwl__display" title="wl_display">wl_display</a> to advertise or hide global objects to clients. The set filter will be used during <a class="link" href="apc.html#Server-structwl__global" title="wl_global">wl_global</a> advertisment to determine whether a global object should be advertised to a given client, and during <a class="link" href="apc.html#Server-structwl__global" title="wl_global">wl_global</a> binding to determine whether a given client should be allowed to bind to a global.</p><p>Clients that try to bind to a global that was filtered out will have an error raised.</p><p>Setting the filter NULL will result in all globals being advertised to all clients. The default is no filter. </p></dd><dt><a name="Server-structwl__display_1a43f04f76ea1457edcf37c95de68b29ef"></a><span class="term">wl_display_get_serial
-            - 
-Get the current serial number.         </span></dt><dd><pre class="synopsis">uint32_t wl_display_get_serial(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display object</dd></dl></div><p>
-This function returns the most recent serial number, but does not increment it. </p></dd><dt><a name="Server-structwl__display_1a145f7d3e4b41fc9014c11bf01bd7eb4f"></a><span class="term">wl_display_next_serial
-            - 
-Get the next serial number.         </span></dt><dd><pre class="synopsis">uint32_t wl_display_next_serial(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display object</dd></dl></div><p>
-This function increments the display serial number and returns the new value. </p></dd><dt><a name="Server-structwl__display_1ab50365739904f91579a66f4b054a3ecb"></a><span class="term">wl_display_destroy_clients
-            - 
-Destroy all clients connected to the display.         </span></dt><dd><pre class="synopsis">void wl_display_destroy_clients(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display object</dd></dl></div><p>
-This function should be called right before <a class="link" href="apc.html#Server-structwl__display_1acd9ad2e1ca3ffb0ba0f1b77ae616f8ee">wl_display_destroy()</a> to ensure all client resources are closed properly. Destroying a client from within <a class="link" href="apc.html#Server-structwl__display_1ab50365739904f91579a66f4b054a3ecb">wl_display_destroy_clients()</a> is safe, but creating one will leak resources and raise a warning. </p></dd><dt><a name="Server-structwl__display_1a54f1cf58cc74cd44c889b2cdf029345d"></a><span class="term">wl_display_add_socket_fd
-            - 
-Add a socket with an existing fd to Wayland display for the clients to connect.         </span></dt><dd><pre class="synopsis">int wl_display_add_socket_fd(struct wl_display *display, int sock_fd)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-Wayland display to which the socket should be added. </dd><dt><span class="term">sock_fd</span></dt><dd>
-The existing socket file descriptor to be used </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 if success. -1 if failed.</dd></dl></div><p>
-The existing socket fd must already be created, opened, and locked. The fd must be properly set to CLOEXEC and bound to a socket file with both bind() and listen() already called. </p></dd><dt><a name="Server-structwl__display_1a9fdf7264f0a3a28a75c141db252067b8"></a><span class="term">wl_display_add_socket
-            - 
-Add a socket to Wayland display for the clients to connect.         </span></dt><dd><pre class="synopsis">int wl_display_add_socket(struct wl_display *display, const char *name)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-Wayland display to which the socket should be added. </dd><dt><span class="term">name</span></dt><dd>
-Name of the Unix socket. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 if success. -1 if failed.</dd></dl></div><p>
-This adds a Unix socket to Wayland display which can be used by clients to connect to Wayland display.</p><p>If NULL is passed as name, then it would look for WAYLAND_DISPLAY env variable for the socket name. If WAYLAND_DISPLAY is not set, then default wayland-0 is used.</p><p>The Unix socket will be created in the directory pointed to by environment variable XDG_RUNTIME_DIR. If XDG_RUNTIME_DIR is not set, then this function fails and returns -1.</p><p>The length of socket path, i.e., the path set in XDG_RUNTIME_DIR and the socket name, must not exceed the maximum length of a Unix socket path. The function also fails if the user do not have write permission in the XDG_RUNTIME_DIR path or if the socket name is already in use. </p></dd><dt><a name="Server-structwl__display_1a4dc118c686e362aba0b3c6c8874efc3d"></a><span class="term">wl_display_add_protocol_logger
-            - 
-Adds a new protocol logger.         </span></dt><dd><pre class="synopsis">struct wl_protocol_logger * wl_display_add_protocol_logger(struct wl_display *display, wl_protocol_logger_func_t func, void *user_data)</pre><p>When a new protocol message arrives or is sent from the server all the protocol logger functions will be called, carrying the user_data pointer, the type of the message (request or event) and the actual message. The lifetime of the messages passed to the logger function ends when they return so the messages cannot be stored and accessed later.</p><p>errno is set on error.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display object </dd><dt><span class="term">func</span></dt><dd>
-The function to call to log a new protocol message </dd><dt><span class="term">user_data</span></dt><dd>
-The user data pointer to pass to func </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The protol logger object on success, NULL on failure.</dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-structwl__protocol__logger_1ac5bfbf098cbecb788190bc12e3becad7">wl_protocol_logger_destroy</a> 
-</p></dd><dt><a name="Server-structwl__display_1ad806e5d1f937b32f62998c44a0a16421"></a><span class="term">wl_display_add_shm_format
-            - 
-Add support for a wl_shm pixel format.         </span></dt><dd><pre class="synopsis">uint32_t * wl_display_add_shm_format(struct wl_display *display, uint32_t format)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display object </dd><dt><span class="term">format</span></dt><dd>
-The wl_shm pixel format to advertise </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A pointer to the wl_shm format that was added to the list or NULL if adding it to the list failed.</dd></dl></div><p>
-Add the specified wl_shm format to the list of formats the wl_shm object advertises when a client binds to it. Adding a format to the list means that clients will know that the compositor supports this format and may use it for creating wl_shm buffers. The compositor must be able to handle the pixel format when a client requests it.</p><p>The compositor by default supports WL_SHM_FORMAT_ARGB8888 and WL_SHM_FORMAT_XRGB8888. </p></dd><dt><a name="Server-structwl__display_1a99b9c187d88633fa5ba86d1424f06d7f"></a><span class="term">wl_display_get_client_list
-            - 
-Get the list of currently connected clients.         </span></dt><dd><pre class="synopsis">struct wl_list * wl_display_get_client_list(struct wl_display *display)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display object</dd></dl></div><p>
-This function returns a pointer to the list of clients currently connected to the display. You can iterate on the list by using the wl_client_for_each macro. The returned value is valid for the lifetime of the display. You must not modify the returned list, but only access it.</p><p>
-  See also: <a class="link" href="apc.html#Server-wayland-server-core_8h_1af1e9ad8dd32ea89265936930cd173ec5">wl_client_for_each()</a> 
-
-  See also: <a class="link" href="apc.html#Server-structwl__client_1ade7bddc335d60cb95f9d1bd4fb60d25b">wl_client_get_link()</a> 
-
-  See also: <a class="link" href="apc.html#Server-structwl__client_1aec831218471327f37b4e1f11b571545d">wl_client_from_link()</a> 
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__event__loop"></a>wl_event_loop
-                - 
-An event loop context.     </h2></div></div></div><p>Usually you create an event loop context, add sources to it, and call <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a> in a loop to process events.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__event__source" title="wl_event_source - An abstract event source.">wl_event_source</a> 
-</p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__event__loop_1afb0958142b950045cd91011c71706979"></a><span class="term">wl_event_loop_create
-            - 
-Create a new event loop context.         </span></dt><dd><pre class="synopsis">struct wl_event_loop * wl_event_loop_create(void)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A new event loop context object.</dd></dl></div><p>
-This creates a new event loop context. Initially this context is empty. Event sources need to be explicitly added to it.</p><p>Normally the event loop is run by calling <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a> in a loop until the program terminates. Alternatively, an event loop can be embedded in another event loop by its file descriptor, see <a class="link" href="apc.html#Server-structwl__event__loop_1a58c8aa06a2d240a49a95a91eddcba8e5">wl_event_loop_get_fd()</a>. </p></dd><dt><a name="Server-structwl__event__loop_1ad50f13e2c738e68f7576757aa862513a"></a><span class="term">wl_event_loop_destroy
-            - 
-Destroy an event loop context.         </span></dt><dd><pre class="synopsis">void wl_event_loop_destroy(struct wl_event_loop *loop)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop to be destroyed.</dd></dl></div><p>
-This emits the event loop destroy signal, closes the event loop file descriptor, and frees loop.</p><p>If the event loop has existing sources, those cannot be safely removed afterwards. Therefore one must call <a class="link" href="apc.html#Server-structwl__event__source_1afe37015d67b81ae82609f2b8aa78cc4f">wl_event_source_remove()</a> on all event sources before destroying the event loop context. </p></dd><dt><a name="Server-structwl__event__loop_1aefc44b3062c22d2506ff42460f091396"></a><span class="term">wl_event_loop_dispatch_idle
-            - 
-Dispatch the idle sources.         </span></dt><dd><pre class="synopsis">void wl_event_loop_dispatch_idle(struct wl_event_loop *loop)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop whose idle sources are dispatched.</dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1a90d88ae62b26a25f709977c45b300716">wl_event_loop_add_idle()</a> 
-</p></dd><dt><a name="Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b"></a><span class="term">wl_event_loop_dispatch
-            - 
-Wait for events and dispatch them.         </span></dt><dd><pre class="synopsis">int wl_event_loop_dispatch(struct wl_event_loop *loop, int timeout)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop whose sources to wait for. </dd><dt><span class="term">timeout</span></dt><dd>
-The polling timeout in milliseconds. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 for success, -1 for polling error.</dd></dl></div><p>
-All the associated event sources are polled. This function blocks until any event source delivers an event (idle sources excluded), or the timeout expires. A timeout of -1 disables the timeout, causing the function to block indefinitely. A timeout of zero causes the poll to always return immediately.</p><p>All idle sources are dispatched before blocking. An idle source is destroyed when it is dispatched. After blocking, all other ready sources are dispatched. Then, idle sources are dispatched again, in case the dispatched events created idle sources. Finally, all sources marked with <a class="link" href="apc.html#Server-structwl__event__source_1aa079264c57dd12168c691c000724efcf">wl_event_source_check()</a> are dispatched in a loop until their dispatch functions all return zero. </p></dd><dt><a name="Server-structwl__event__loop_1a58c8aa06a2d240a49a95a91eddcba8e5"></a><span class="term">wl_event_loop_get_fd
-            - 
-Get the event loop file descriptor.         </span></dt><dd><pre class="synopsis">int wl_event_loop_get_fd(struct wl_event_loop *loop)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop context. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The aggregate file descriptor.</dd></dl></div><p>
-This function returns the aggregate file descriptor, that represents all the event sources (idle sources excluded) associated with the given event loop context. When any event source makes an event available, it will be reflected in the aggregate file descriptor.</p><p>When the aggregate file descriptor delivers an event, one can call <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a> on the event loop context to dispatch all the available events. </p></dd><dt><a name="Server-structwl__event__loop_1a6b564d8d4183d71f1fdf06e751d84d51"></a><span class="term">wl_event_loop_add_destroy_listener
-            - 
-Register a destroy listener for an event loop context.         </span></dt><dd><pre class="synopsis">void wl_event_loop_add_destroy_listener(struct wl_event_loop *loop, struct wl_listener *listener)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop context whose destruction to listen for. </dd><dt><span class="term">listener</span></dt><dd>
-The listener with the callback to be called.</dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a> 
-</p></dd><dt><a name="Server-structwl__event__loop_1af282cb9f57fadd1fc0dd47ea68c3bae3"></a><span class="term">wl_event_loop_get_destroy_listener
-            - 
-Get the listener struct for the specified callback.         </span></dt><dd><pre class="synopsis">struct wl_listener * wl_event_loop_get_destroy_listener(struct wl_event_loop *loop, wl_notify_func_t notify)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop context to inspect. </dd><dt><span class="term">notify</span></dt><dd>
-The destroy callback to find. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The <a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a> registered to the event loop context with the given callback pointer. </dd></dl></div><p>
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__event__source"></a>wl_event_source
-                - 
-An abstract event source.     </h2></div></div></div><p>This is the generic type for fd, timer, signal, and idle sources. Functions that operate on specific source types must not be used with a different type, even if the function signature allows it. </p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__event__source_1a09e702384ed869548c72f3576399c581"></a><span class="term">wl_event_loop_fd_func_t
-            - 
-File descriptor dispatch function type.         </span></dt><dd><pre class="synopsis">typedef int(* wl_event_loop_fd_func_t) (int fd, uint32_t mask, void *data))(int fd, uint32_t mask, void *data)</pre><p>Functions of this type are used as callbacks for file descriptor events.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">fd</span></dt><dd>
-The file descriptor delivering the event. </dd><dt><span class="term">mask</span></dt><dd>
-Describes the kind of the event as a bitwise-or of: WL_EVENT_READABLE, WL_EVENT_WRITABLE, WL_EVENT_HANGUP, WL_EVENT_ERROR. </dd><dt><span class="term">data</span></dt><dd>
-The user data argument of the related <a class="link" href="apc.html#Server-structwl__event__source_1a0e7ce1f52dfe04c73b6a7c2263c7ef25">wl_event_loop_add_fd()</a> call. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>If the event source is registered for re-check with <a class="link" href="apc.html#Server-structwl__event__source_1aa079264c57dd12168c691c000724efcf">wl_event_source_check()</a>: 0 for all done, 1 for needing a re-check. If not registered, the return value is ignored and should be zero.</dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1a0e7ce1f52dfe04c73b6a7c2263c7ef25">wl_event_loop_add_fd()</a> 
-</p></dd><dt><a name="Server-structwl__event__source_1a59bc490bf28b48e0af908ab91649938a"></a><span class="term">wl_event_loop_timer_func_t
-            - 
-Timer dispatch function type.         </span></dt><dd><pre class="synopsis">typedef int(* wl_event_loop_timer_func_t) (void *data))(void *data)</pre><p>Functions of this type are used as callbacks for timer expiry.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">data</span></dt><dd>
-The user data argument of the related <a class="link" href="apc.html#Server-structwl__event__source_1a39374f19a73472f63fab4267a14adc10">wl_event_loop_add_timer()</a> call. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>If the event source is registered for re-check with <a class="link" href="apc.html#Server-structwl__event__source_1aa079264c57dd12168c691c000724efcf">wl_event_source_check()</a>: 0 for all done, 1 for needing a re-check. If not registered, the return value is ignored and should be zero.</dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1a39374f19a73472f63fab4267a14adc10">wl_event_loop_add_timer()</a> 
-</p></dd><dt><a name="Server-structwl__event__source_1a431b418976144a8ebe6b19bc24206d20"></a><span class="term">wl_event_loop_signal_func_t
-            - 
-Signal dispatch function type.         </span></dt><dd><pre class="synopsis">typedef int(* wl_event_loop_signal_func_t) (int signal_number, void *data))(int signal_number, void *data)</pre><p>Functions of this type are used as callbacks for (POSIX) signals.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">signal_number</span></dt><dd>
-</dd><dt><span class="term">data</span></dt><dd>
-The user data argument of the related <a class="link" href="apc.html#Server-structwl__event__source_1a1706e2490502a95f24ccb59cbae3e2f8">wl_event_loop_add_signal()</a> call. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>If the event source is registered for re-check with <a class="link" href="apc.html#Server-structwl__event__source_1aa079264c57dd12168c691c000724efcf">wl_event_source_check()</a>: 0 for all done, 1 for needing a re-check. If not registered, the return value is ignored and should be zero.</dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1a1706e2490502a95f24ccb59cbae3e2f8">wl_event_loop_add_signal()</a> 
-</p></dd><dt><a name="Server-structwl__event__source_1ae526dfa099f9ba69285e275c82794a9b"></a><span class="term">wl_event_loop_idle_func_t
-            - 
-Idle task function type.         </span></dt><dd><pre class="synopsis">typedef void(* wl_event_loop_idle_func_t) (void *data))(void *data)</pre><p>Functions of this type are used as callbacks before blocking in <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a>.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">data</span></dt><dd>
-The user data argument of the related <a class="link" href="apc.html#Server-structwl__event__source_1a90d88ae62b26a25f709977c45b300716">wl_event_loop_add_idle()</a> call.</dd></dl></div><p>
-
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1a90d88ae62b26a25f709977c45b300716">wl_event_loop_add_idle()</a> <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a> 
-</p></dd><dt><a name="Server-structwl__event__source_1a0e7ce1f52dfe04c73b6a7c2263c7ef25"></a><span class="term">wl_event_loop_add_fd
-            - 
-Create a file descriptor event source.         </span></dt><dd><pre class="synopsis">struct wl_event_source * wl_event_loop_add_fd(struct wl_event_loop *loop, int fd, uint32_t mask, wl_event_loop_fd_func_t func, void *data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop that will process the new source. </dd><dt><span class="term">fd</span></dt><dd>
-The file descriptor to watch. </dd><dt><span class="term">mask</span></dt><dd>
-A bitwise-or of which events to watch for: WL_EVENT_READABLE, WL_EVENT_WRITABLE. </dd><dt><span class="term">func</span></dt><dd>
-The file descriptor dispatch function. </dd><dt><span class="term">data</span></dt><dd>
-User data. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A new file descriptor event source.</dd></dl></div><p>
-The given file descriptor is initially watched for the events given in mask. This can be changed as needed with <a class="link" href="apc.html#Server-structwl__event__source_1afe73f9ff59d489e9f27eb9c0e3058a02">wl_event_source_fd_update()</a>.</p><p>If it is possible that program execution causes the file descriptor to be read while leaving the data in a buffer without actually processing it, it may be necessary to register the file descriptor source to be re-checked, see <a class="link" href="apc.html#Server-structwl__event__source_1aa079264c57dd12168c691c000724efcf">wl_event_source_check()</a>. This will ensure that the dispatch function gets called even if the file descriptor is not readable or writable anymore. This is especially useful with IPC libraries that automatically buffer incoming data, possibly as a side-effect of other operations.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1a09e702384ed869548c72f3576399c581">wl_event_loop_fd_func_t</a> 
-</p></dd><dt><a name="Server-structwl__event__source_1afe73f9ff59d489e9f27eb9c0e3058a02"></a><span class="term">wl_event_source_fd_update
-            - 
-Update a file descriptor source's event mask.         </span></dt><dd><pre class="synopsis">int wl_event_source_fd_update(struct wl_event_source *source, uint32_t mask)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">source</span></dt><dd>
-The file descriptor event source to update. </dd><dt><span class="term">mask</span></dt><dd>
-The new mask, a bitwise-or of: WL_EVENT_READABLE, WL_EVENT_WRITABLE. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success, -1 on failure.</dd></dl></div><p>
-This changes which events, readable and/or writable, cause the dispatch callback to be called on.</p><p>File descriptors are usually writable to begin with, so they do not need to be polled for writable until a write actually fails. When a write fails, the event mask can be changed to poll for readable and writable, delivering a dispatch callback when it is possible to write more. Once all data has been written, the mask can be changed to poll only for readable to avoid busy-looping on dispatch.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1a0e7ce1f52dfe04c73b6a7c2263c7ef25">wl_event_loop_add_fd()</a> 
-</p></dd><dt><a name="Server-structwl__event__source_1a39374f19a73472f63fab4267a14adc10"></a><span class="term">wl_event_loop_add_timer
-            - 
-Create a timer event source.         </span></dt><dd><pre class="synopsis">struct wl_event_source * wl_event_loop_add_timer(struct wl_event_loop *loop, wl_event_loop_timer_func_t func, void *data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop that will process the new source. </dd><dt><span class="term">func</span></dt><dd>
-The timer dispatch function. </dd><dt><span class="term">data</span></dt><dd>
-User data. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A new timer event source.</dd></dl></div><p>
-The timer is initially disarmed. It needs to be armed with a call to <a class="link" href="apc.html#Server-structwl__event__source_1a0164a47e9e8356af90c9d5c1de9f5487">wl_event_source_timer_update()</a> before it can trigger a dispatch call.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1a59bc490bf28b48e0af908ab91649938a">wl_event_loop_timer_func_t</a> 
-</p></dd><dt><a name="Server-structwl__event__source_1a0164a47e9e8356af90c9d5c1de9f5487"></a><span class="term">wl_event_source_timer_update
-            - 
-Arm or disarm a timer.         </span></dt><dd><pre class="synopsis">int wl_event_source_timer_update(struct wl_event_source *source, int ms_delay)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">source</span></dt><dd>
-The timer event source to modify. </dd><dt><span class="term">ms_delay</span></dt><dd>
-The timeout in milliseconds. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success, -1 on failure.</dd></dl></div><p>
-If the timeout is zero, the timer is disarmed.</p><p>If the timeout is non-zero, the timer is set to expire after the given timeout in milliseconds. When the timer expires, the dispatch function set with <a class="link" href="apc.html#Server-structwl__event__source_1a39374f19a73472f63fab4267a14adc10">wl_event_loop_add_timer()</a> is called once from <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a>. If another dispatch is desired after another expiry, <a class="link" href="apc.html#Server-structwl__event__source_1a0164a47e9e8356af90c9d5c1de9f5487">wl_event_source_timer_update()</a> needs to be called again. </p></dd><dt><a name="Server-structwl__event__source_1a1706e2490502a95f24ccb59cbae3e2f8"></a><span class="term">wl_event_loop_add_signal
-            - 
-Create a POSIX signal event source.         </span></dt><dd><pre class="synopsis">struct wl_event_source * wl_event_loop_add_signal(struct wl_event_loop *loop, int signal_number, wl_event_loop_signal_func_t func, void *data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop that will process the new source. </dd><dt><span class="term">signal_number</span></dt><dd>
-Number of the signal to watch for. </dd><dt><span class="term">func</span></dt><dd>
-The signal dispatch function. </dd><dt><span class="term">data</span></dt><dd>
-User data. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A new signal event source.</dd></dl></div><p>
-This function blocks the normal delivery of the given signal in the calling thread, and creates a "watch" for it. Signal delivery no longer happens asynchronously, but by <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a> calling the dispatch callback function func.</p><p>It is the caller's responsibility to ensure that all other threads have also blocked the signal.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1a431b418976144a8ebe6b19bc24206d20">wl_event_loop_signal_func_t</a> 
-</p></dd><dt><a name="Server-structwl__event__source_1a90d88ae62b26a25f709977c45b300716"></a><span class="term">wl_event_loop_add_idle
-            - 
-Create an idle task.         </span></dt><dd><pre class="synopsis">struct wl_event_source * wl_event_loop_add_idle(struct wl_event_loop *loop, wl_event_loop_idle_func_t func, void *data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">loop</span></dt><dd>
-The event loop that will process the new task. </dd><dt><span class="term">func</span></dt><dd>
-The idle task dispatch function. </dd><dt><span class="term">data</span></dt><dd>
-User data. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>A new idle task (an event source).</dd></dl></div><p>
-Idle tasks are dispatched before <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a> goes to sleep. See <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a> for more details.</p><p>Idle tasks fire once, and are automatically destroyed right after the callback function has been called.</p><p>An idle task can be cancelled before the callback has been called by <a class="link" href="apc.html#Server-structwl__event__source_1afe37015d67b81ae82609f2b8aa78cc4f">wl_event_source_remove()</a>. Calling <a class="link" href="apc.html#Server-structwl__event__source_1afe37015d67b81ae82609f2b8aa78cc4f">wl_event_source_remove()</a> after or from within the callback results in undefined behaviour.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__event__source_1ae526dfa099f9ba69285e275c82794a9b">wl_event_loop_idle_func_t</a> 
-</p></dd><dt><a name="Server-structwl__event__source_1aa079264c57dd12168c691c000724efcf"></a><span class="term">wl_event_source_check
-            - 
-Mark event source to be re-checked.         </span></dt><dd><pre class="synopsis">void wl_event_source_check(struct wl_event_source *source)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">source</span></dt><dd>
-The event source to be re-checked.</dd></dl></div><p>
-This function permanently marks the event source to be re-checked after the normal dispatch of sources in <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a>. Re-checking will keep iterating over all such event sources until the dispatch function for them all returns zero.</p><p>Re-checking is used on sources that may become ready to dispatch as a side-effect of dispatching themselves or other event sources, including idle sources. Re-checking ensures all the incoming events have been fully drained before <a class="link" href="apc.html#Server-structwl__event__loop_1aaa3fdd5590365a4a2106c9814ca9b31b">wl_event_loop_dispatch()</a> returns. </p></dd><dt><a name="Server-structwl__event__source_1afe37015d67b81ae82609f2b8aa78cc4f"></a><span class="term">wl_event_source_remove
-            - 
-Remove an event source from its event loop.         </span></dt><dd><pre class="synopsis">int wl_event_source_remove(struct wl_event_source *source)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">source</span></dt><dd>
-The event source to be removed. </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>Zero.</dd></dl></div><p>
-The event source is removed from the event loop it was created for, and is effectively destroyed. This invalidates source . The dispatch function of the source will no longer be called through this source. </p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__global"></a>wl_global</h2></div></div></div><p></p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__interface"></a>wl_interface
-                - 
-Protocol object interface.     </h2></div></div></div><p>A <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> describes the API of a protocol object defined in the Wayland protocol specification. The protocol implementation uses a <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> within its marshalling machinery for encoding client requests.</p><p>The name of a <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> is the name of the corresponding protocol interface, and version represents the version of the interface. The members method_count and event_count represent the number of methods (requests) and events in the respective <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> members.</p><p>For example, consider a protocol interface foo, marked as version 1, with two requests and one event.</p><p>
-    </p><pre class="programlisting"><interface name="foo" version="1">
-  <request name="a"></request>
-  <request name="b"></request>
-  <event name="c"></event>
-</interface>
-</pre><p>
-  </p><p>Given two <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> arrays foo_requests and foo_events, a <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> for foo might be:</p><p>
-    </p><pre class="programlisting">struct wl_interface foo_interface = {
-        "foo", 1,
-        2, foo_requests,
-        1, foo_events
-};
-</pre><p>
-  </p><p><span class="emphasis"><em>Note: The server side of the protocol may define interface implementation types that incorporate the term interface in their name. Take care to not confuse these server-side structs with a <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> variable whose name also ends in interface. For example, while the server may define a type struct wl_foo_interface, the client may define a struct <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> wl_foo_interface.</em></span>
-
-  See also: <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> 
-
-  See also: wl_proxy 
-
-  See also: Interfaces 
-
-  See also: Versioning 
-</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__list"></a>wl_list
-                - 
-Doubly-linked list.     </h2></div></div></div><p>On its own, an instance of struct <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> represents the sentinel head of a doubly-linked list, and must be initialized using <a class="link" href="apc.html#Server-structwl__list_1a1d5c9d41e224538b2edf324c7f8b1ac8">wl_list_init()</a>. When empty, the list head's next and prev members point to the list head itself, otherwise next references the first element in the list, and prev refers to the last element in the list.</p><p>Use the struct <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> type to represent both the list head and the links between elements within the list. Use <a class="link" href="apc.html#Server-structwl__list_1a5c6aa8f61fa63374f1c77e7e4462a38a">wl_list_empty()</a> to determine if the list is empty in O(1).</p><p>All elements in the list must be of the same type. The element type must have a struct <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> member, often named link by convention. Prior to insertion, there is no need to initialize an element's link - invoking <a class="link" href="apc.html#Server-structwl__list_1a1d5c9d41e224538b2edf324c7f8b1ac8">wl_list_init()</a> on an individual list element's struct <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> member is unnecessary if the very next operation is <a class="link" href="apc.html#Server-structwl__list_1aa7eaac0d363c0473bfc3e8172b0dfd98">wl_list_insert()</a>. However, a common idiom is to initialize an element's link prior to removal - ensure safety by invoking <a class="link" href="apc.html#Server-structwl__list_1a1d5c9d41e224538b2edf324c7f8b1ac8">wl_list_init()</a> before <a class="link" href="apc.html#Server-structwl__list_1aa16d739aaa041dde9d34ad4bcb4d4c83">wl_list_remove()</a>.</p><p>Consider a list reference struct <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> foo_list, an element type as struct element, and an element's link member as struct <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> link.</p><p>The following code initializes a list and adds three elements to it.</p><p>
-    </p><pre class="programlisting">struct wl_list foo_list;
-
-struct element {
-        int foo;
-        struct wl_list link;
-};
-struct element e1, e2, e3;
-
-wl_list_init(&foo_list);
-wl_list_insert(&foo_list, &e1.link);   // e1 is the first element
-wl_list_insert(&foo_list, &e2.link);   // e2 is now the first element
-wl_list_insert(&e2.link, &e3.link); // insert e3 after e2
-</pre><p>
-  </p><p>The list now looks like [e2, e3, e1].</p><p>The <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> API provides some iterator macros. For example, to iterate a list in ascending order:</p><p>
-    </p><pre class="programlisting">struct element *e;
-wl_list_for_each(e, foo_list, link) {
-        do_something_with_element(e);
-}
-</pre><p>
-  </p><p>See the documentation of each iterator for details. 
-  See also: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/list.h 
-</p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__list_1a72c2827d3103691f9e3299babfbf0704"></a><span class="term">prev
-            - 
-Previous list element.         </span></dt><dd><pre class="synopsis">struct wl_list* wl_list::prev</pre></dd><dt><a name="Server-structwl__list_1aa0454596900ed769fb2f033fbb96bf2c"></a><span class="term">next
-            - 
-Next list element.         </span></dt><dd><pre class="synopsis">struct wl_list* wl_list::next</pre></dd><dt><a name="Server-structwl__list_1a1d5c9d41e224538b2edf324c7f8b1ac8"></a><span class="term">wl_list_init
-            - 
-Initializes the list.         </span></dt><dd><pre class="synopsis">void wl_list_init(struct wl_list *list)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List to initialize </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__list_1aa7eaac0d363c0473bfc3e8172b0dfd98"></a><span class="term">wl_list_insert
-            - 
-Inserts an element into the list, after the element represented by list.         </span></dt><dd><pre class="synopsis">void wl_list_insert(struct wl_list *list, struct wl_list *elm)</pre><p>When list is a reference to the list itself (the head), set the containing struct of elm as the first element in the list.</p><p><span class="emphasis"><em>Note: If elm is already part of a list, inserting it again will lead to list corruption.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List element after which the new element is inserted </dd><dt><span class="term">elm</span></dt><dd>
-Link of the containing struct to insert into the list </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__list_1aa16d739aaa041dde9d34ad4bcb4d4c83"></a><span class="term">wl_list_remove
-            - 
-Removes an element from the list.         </span></dt><dd><pre class="synopsis">void wl_list_remove(struct wl_list *elm)</pre><p><span class="emphasis"><em>Note: This operation leaves elm in an invalid state.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">elm</span></dt><dd>
-Link of the containing struct to remove from the list </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__list_1a2710186b02864dc2b18a46993aa9c2e0"></a><span class="term">wl_list_length
-            - 
-Determines the length of the list.         </span></dt><dd><pre class="synopsis">int wl_list_length(const struct wl_list *list)</pre><p><span class="emphasis"><em>Note: This is an O(n) operation.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List whose length is to be determined</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>Number of elements in the list </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__list_1a5c6aa8f61fa63374f1c77e7e4462a38a"></a><span class="term">wl_list_empty
-            - 
-Determines if the list is empty.         </span></dt><dd><pre class="synopsis">int wl_list_empty(const struct wl_list *list)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List whose emptiness is to be determined</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>1 if empty, or 0 if not empty </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__list_1ac714f6eedd52286c8b6d9884cc7c8492"></a><span class="term">wl_list_insert_list
-            - 
-Inserts all of the elements of one list into another, after the element represented by list.         </span></dt><dd><pre class="synopsis">void wl_list_insert_list(struct wl_list *list, struct wl_list *other)</pre><p><span class="emphasis"><em>Note: This leaves other in an invalid state.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">list</span></dt><dd>
-List element after which the other list elements will be inserted </dd><dt><span class="term">other</span></dt><dd>
-List of elements to insert </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb"></a><span class="term">wl_list_for_each
-            - 
-Iterates over a list.         </span></dt><dd><pre class="synopsis"></pre><p>This macro expresses a for-each iterator for <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a>. Given a list and <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> link member name (often named link by convention), this macro assigns each element in the list to pos, which can then be referenced in a trailing code block. For example, given a <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a> of struct message elements:</p><p>
-          </p><pre class="programlisting">struct message {
-        char *contents;
-        wl_list link;
-};
-
-struct wl_list *message_list;
-// Assume message_list now "contains" many messages
-
-struct message *m;
-wl_list_for_each(m, message_list, link) {
-        do_something_with_message(m);
-}
-</pre><p>
-        </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each list element will be assigned to </dd><dt><span class="term">head</span></dt><dd>
-Head of the list to iterate over </dd><dt><span class="term">member</span></dt><dd>
-Name of the link member within the element struct </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__list_1a43d51e3b5ae8b58f3391f3d43687f852"></a><span class="term">wl_list_for_each_safe
-            - 
-Iterates over a list, safe against removal of the list element.         </span></dt><dd><pre class="synopsis"></pre><p><span class="emphasis"><em>Note: Only removal of the current element, pos, is safe. Removing any other element during traversal may lead to a loop malfunction.</em></span>
-
-  See also: <a class="link" href="apc.html#Server-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb">wl_list_for_each()</a>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each list element will be assigned to </dd><dt><span class="term">tmp</span></dt><dd>
-Temporary pointer of the same type as pos </dd><dt><span class="term">head</span></dt><dd>
-Head of the list to iterate over </dd><dt><span class="term">member</span></dt><dd>
-Name of the link member within the element struct </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__list_1a2ee1918119b03d36ed3004984efb9dc9"></a><span class="term">wl_list_for_each_reverse
-            - 
-Iterates backwards over a list.         </span></dt><dd><pre class="synopsis"></pre><p>
-  See also: <a class="link" href="apc.html#Server-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb">wl_list_for_each()</a>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each list element will be assigned to </dd><dt><span class="term">head</span></dt><dd>
-Head of the list to iterate over </dd><dt><span class="term">member</span></dt><dd>
-Name of the link member within the element struct </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__list_1ac84e06e7914226b2678ff5f351d7f9e8"></a><span class="term">wl_list_for_each_reverse_safe
-            - 
-Iterates backwards over a list, safe against removal of the list element.         </span></dt><dd><pre class="synopsis"></pre><p><span class="emphasis"><em>Note: Only removal of the current element, pos, is safe. Removing any other element during traversal may lead to a loop malfunction.</em></span>
-
-  See also: <a class="link" href="apc.html#Server-structwl__list_1a449407fe3c8f273e38bc2253093cb6fb">wl_list_for_each()</a>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">pos</span></dt><dd>
-Cursor that each list element will be assigned to </dd><dt><span class="term">tmp</span></dt><dd>
-Temporary pointer of the same type as pos </dd><dt><span class="term">head</span></dt><dd>
-Head of the list to iterate over </dd><dt><span class="term">member</span></dt><dd>
-Name of the link member within the element struct </dd></dl></div><p>
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__listener"></a>wl_listener
-                - 
-A single listener for Wayland signals.     </h2></div></div></div><p><a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a> provides the means to listen for <a class="link" href="apc.html#Server-structwl__signal" title="wl_signal - A source of a type of observable event.">wl_signal</a> notifications. Many Wayland objects use <a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a> for notification of significant events like object destruction.</p><p>Clients should create <a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a> objects manually and can register them as listeners to signals using <a class="link" href="apc.html#Server-structwl__signal_1aa8bcd3b8e250cfe35ed064d5af589096">wl_signal_add</a>, assuming the signal is directly accessible. For opaque structs like <a class="link" href="apc.html#Server-structwl__event__loop" title="wl_event_loop - An event loop context.">wl_event_loop</a>, adding a listener should be done through provided accessor methods. A listener can only listen to one signal at a time.</p><p>
-    </p><pre class="programlisting">struct wl_listener your_listener;
-
-your_listener.notify = your_callback_method;
-
-// Direct access
-wl_signal_add(&some_object->destroy_signal, &your_listener);
-
-// Accessor access
-wl_event_loop *loop = ...;
-wl_event_loop_add_destroy_listener(loop, &your_listener);
-</pre><p>
-  </p><p>If the listener is part of a larger struct, <a class="link" href="apc.html#Server-wayland-util_8h_1a09e3b64ee2195e1b80191aa1884d45aa">wl_container_of</a> can be used to retrieve a pointer to it:</p><p>
-    </p><pre class="programlisting">void your_listener(struct wl_listener *listener, void *data)
-{
-        struct your_data *data;
-
-        your_data = wl_container_of(listener, data, your_member_name);
-}
-</pre><p>
-  </p><p>If you need to remove a listener from a signal, use <a class="link" href="apc.html#Server-structwl__list_1aa16d739aaa041dde9d34ad4bcb4d4c83">wl_list_remove()</a>.</p><p>
-    </p><pre class="programlisting">wl_list_remove(&your_listener.link);
-</pre><p>
-  </p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__signal" title="wl_signal - A source of a type of observable event.">wl_signal</a> 
-</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__message"></a>wl_message
-                - 
-Protocol message signature.     </h2></div></div></div><p>A <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> describes the signature of an actual protocol message, such as a request or event, that adheres to the Wayland protocol wire format. The protocol implementation uses a <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> within its demarshal machinery for decoding messages between a compositor and its clients. In a sense, a <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> is to a protocol message like a class is to an object.</p><p>The name of a <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> is the name of the corresponding protocol message.</p><p>The signature is an ordered list of symbols representing the data types of message arguments and, optionally, a protocol version and indicators for nullability. A leading integer in the signature indicates the since version of the protocol message. A ? preceding a data type symbol indicates that the following argument type is nullable. While it is a protocol violation to send messages with non-nullable arguments set to NULL, event handlers in clients might still get called with non-nullable object arguments set to NULL. This can happen when the client destroyed the object being used as argument on its side and an event referencing that object was sent before the server knew about its destruction. As this race cannot be prevented, clients should - as a general rule - program their event handlers such that they can handle object arguments declared non-nullable being NULL gracefully.</p><p>When no arguments accompany a message, signature is an empty string.</p><p>Symbols:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem">i: int</li><li class="listitem">u: uint</li><li class="listitem">f: fixed</li><li class="listitem">s: string</li><li class="listitem">o: object</li><li class="listitem">n: new_id</li><li class="listitem">a: array</li><li class="listitem">h: fd</li><li class="listitem">?: following argument is nullable</li></ul></div><p>
-</p><p>While demarshaling primitive arguments is straightforward, when demarshaling messages containing object or new_id arguments, the protocol implementation often must determine the type of the object. The types of a <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> is an array of <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> references that correspond to o and n arguments in signature, with NULL placeholders for arguments with non-object types.</p><p>Consider the protocol event <a class="link" href="apc.html#Server-structwl__display" title="wl_display">wl_display</a> delete_id that has a single uint argument. The <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> is:</p><p>
-    </p><pre class="programlisting">{ "delete_id", "u", [NULL] }
-</pre><p>
-  </p><p>Here, the message name is "delete_id", the signature is "u", and the argument types is [NULL], indicating that the uint argument has no corresponding <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> since it is a primitive argument.</p><p>In contrast, consider a wl_foo interface supporting protocol request bar that has existed since version 2, and has two arguments: a uint and an object of type wl_baz_interface that may be NULL. Such a <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> might be:</p><p>
-    </p><pre class="programlisting">{ "bar", "2u?o", [NULL, &wl_baz_interface] }
-</pre><p>
-  </p><p>Here, the message name is "bar", and the signature is "2u?o". Notice how the 2 indicates the protocol version, the u indicates the first argument type is uint, and the ?o indicates that the second argument is an object that may be NULL. Lastly, the argument types array indicates that no <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> corresponds to the first argument, while the type wl_baz_interface corresponds to the second argument.</p><p>
-  See also: <a class="link" href="apc.html#Server-unionwl__argument" title="wl_argument - Protocol message argument data types.">wl_argument</a> 
-
-  See also: <a class="link" href="apc.html#Server-structwl__interface" title="wl_interface - Protocol object interface.">wl_interface</a> 
-
-  See also: Wire Format 
-</p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__object"></a>wl_object</h2></div></div></div><p></p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__protocol__logger"></a>wl_protocol_logger</h2></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__protocol__logger_1ac5bfbf098cbecb788190bc12e3becad7"></a><span class="term">wl_protocol_logger_destroy
-            - 
-Destroys a protocol logger.         </span></dt><dd><pre class="synopsis">void wl_protocol_logger_destroy(struct wl_protocol_logger *logger)</pre><p>This function destroys a protocol logger and removes it from the display it was added to with wl_display_add_protocol_logger. The logger object becomes invalid after calling this function.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__display_1a4dc118c686e362aba0b3c6c8874efc3d">wl_display_add_protocol_logger</a> 
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__protocol__logger__message"></a>wl_protocol_logger_message</h2></div></div></div><p></p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__resource"></a>wl_resource</h2></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__resource_1aabbdc4ffb1abf525d1818c943a8c80d6"></a><span class="term">wl_resource_get_class
-            - 
-Retrieve the interface name (class) of a resource object.         </span></dt><dd><pre class="synopsis">const char * wl_resource_get_class(struct wl_resource *resource)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">resource</span></dt><dd>
-The resource object </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__resource_1a50388ae686cecfe7a9940c995d5d120b"></a><span class="term">wl_resource_create
-            - 
-Create a new resource object.         </span></dt><dd><pre class="synopsis">struct wl_resource * wl_resource_create(struct wl_client *client, const struct wl_interface *interface, int version, uint32_t id)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The client owner of the new resource. </dd><dt><span class="term">interface</span></dt><dd>
-The interface of the new resource. </dd><dt><span class="term">version</span></dt><dd>
-The version of the new resource. </dd><dt><span class="term">id</span></dt><dd>
-The id of the new resource. If 0, an available id will be used.</dd></dl></div><p>
-Listeners added with wl_client_add_resource_created_listener will be notified at the end of this function. </p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__resource__iterator__context"></a>wl_resource_iterator_context</h2></div></div></div><p></p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__shm__buffer"></a>wl_shm_buffer</h2></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__shm__buffer_1a9104a38eae80c5ba92c8ab030c70192f"></a><span class="term">wl_shm_buffer_get_data
-            - 
-Get a pointer to the memory for the SHM buffer.         </span></dt><dd><pre class="synopsis">void * wl_shm_buffer_get_data(struct wl_shm_buffer *buffer)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">buffer</span></dt><dd>
-The buffer object</dd></dl></div><p>
-Returns a pointer which can be used to read the data contained in the given SHM buffer.</p><p>As this buffer is memory-mapped, reading from it may generate SIGBUS signals. This can happen if the client claims that the buffer is larger than it is or if something truncates the underlying file. To prevent this signal from causing the compositor to crash you should call wl_shm_buffer_begin_access and wl_shm_buffer_end_access around code that reads from the memory. </p></dd><dt><a name="Server-structwl__shm__buffer_1abc49a49c3586821d6ec4efe7ea915305"></a><span class="term">wl_shm_buffer_ref_pool
-            - 
-Get a reference to a shm_buffer's shm_pool.         </span></dt><dd><pre class="synopsis">struct wl_shm_pool * wl_shm_buffer_ref_pool(struct wl_shm_buffer *buffer)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">buffer</span></dt><dd>
-The buffer object</dd></dl></div><p>
-Returns a pointer to a buffer's shm_pool and increases the shm_pool refcount.</p><p>The compositor must remember to call wl_shm_pool_unref when it no longer needs the reference to ensure proper destruction of the pool.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__shm__pool_1a2349156a6b7940645a4754e6c1690051">wl_shm_pool_unref</a> 
-</p></dd><dt><a name="Server-structwl__shm__buffer_1a809cb5d6b33338c62bbca6daa4138667"></a><span class="term">wl_shm_buffer_begin_access
-            - 
-Mark that the given SHM buffer is about to be accessed.         </span></dt><dd><pre class="synopsis">void wl_shm_buffer_begin_access(struct wl_shm_buffer *buffer)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">buffer</span></dt><dd>
-The SHM buffer</dd></dl></div><p>
-An SHM buffer is a memory-mapped file given by the client. According to POSIX, reading from a memory-mapped region that extends off the end of the file will cause a SIGBUS signal to be generated. Normally this would cause the compositor to terminate. In order to make the compositor robust against clients that change the size of the underlying file or lie about its size, you should protect access to the buffer by calling this function before reading from the memory and call wl_shm_buffer_end_access afterwards. This will install a signal handler for SIGBUS which will prevent the compositor from crashing.</p><p>After calling this function the signal handler will remain installed for the lifetime of the compositor process. Note that this function will not work properly if the compositor is also installing its own handler for SIGBUS.</p><p>If a SIGBUS signal is received for an address within the range of the SHM pool of the given buffer then the client will be sent an error event when wl_shm_buffer_end_access is called. If the signal is for an address outside that range then the signal handler will reraise the signal which would will likely cause the compositor to terminate.</p><p>It is safe to nest calls to these functions as long as the nested calls are all accessing the same buffer. The number of calls to wl_shm_buffer_end_access must match the number of calls to wl_shm_buffer_begin_access. These functions are thread-safe and it is allowed to simultaneously access different buffers or the same buffer from multiple threads. </p></dd><dt><a name="Server-structwl__shm__buffer_1a030db6056ef08836e9dee21a8087e2c1"></a><span class="term">wl_shm_buffer_end_access
-            - 
-Ends the access to a buffer started by wl_shm_buffer_begin_access.         </span></dt><dd><pre class="synopsis">void wl_shm_buffer_end_access(struct wl_shm_buffer *buffer)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">buffer</span></dt><dd>
-The SHM buffer</dd></dl></div><p>
-This should be called after wl_shm_buffer_begin_access once the buffer is no longer being accessed. If a SIGBUS signal was generated in-between these two calls then the resource for the given buffer will be sent an error. </p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__shm__pool"></a>wl_shm_pool</h2></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__shm__pool_1a2349156a6b7940645a4754e6c1690051"></a><span class="term">wl_shm_pool_unref
-            - 
-Unreference a shm_pool.         </span></dt><dd><pre class="synopsis">void wl_shm_pool_unref(struct wl_shm_pool *pool)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">pool</span></dt><dd>
-The pool object</dd></dl></div><p>
-Drops a reference to a <a class="link" href="apc.html#Server-structwl__shm__pool" title="wl_shm_pool">wl_shm_pool</a> object.</p><p>This is only necessary if the compositor has explicitly taken a reference with <a class="link" href="apc.html#Server-structwl__shm__buffer_1abc49a49c3586821d6ec4efe7ea915305">wl_shm_buffer_ref_pool()</a>, otherwise the pool will be automatically destroyed when appropriate.</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__shm__buffer_1abc49a49c3586821d6ec4efe7ea915305">wl_shm_buffer_ref_pool</a> 
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__shm__sigbus__data"></a>wl_shm_sigbus_data</h2></div></div></div><p></p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__signal"></a>wl_signal
-                - 
-A source of a type of observable event.     </h2></div></div></div><p>Signals are recognized points where significant events can be observed. Compositors as well as the server can provide signals. Observers are <a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a>'s that are added through <a class="link" href="apc.html#Server-structwl__signal_1aa8bcd3b8e250cfe35ed064d5af589096">wl_signal_add</a>. Signals are emitted using <a class="link" href="apc.html#Server-structwl__signal_1afe73f44f7f1b517c9c0ba90829c93309">wl_signal_emit</a>, which will invoke all listeners until that listener is removed by <a class="link" href="apc.html#Server-structwl__list_1aa16d739aaa041dde9d34ad4bcb4d4c83">wl_list_remove()</a> (or whenever the signal is destroyed).</p><p>
-  See also: <a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a> for more information on using <a class="link" href="apc.html#Server-structwl__signal" title="wl_signal - A source of a type of observable event.">wl_signal</a> 
-</p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-structwl__signal_1aeb25ddd9c813189203d15723e983b320"></a><span class="term">wl_signal_init
-            - 
-Initialize a new wl_signal for use.         </span></dt><dd><pre class="synopsis">static void wl_signal_init(struct wl_signal *signal)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">signal</span></dt><dd>
-The signal that will be initialized </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__signal_1aa8bcd3b8e250cfe35ed064d5af589096"></a><span class="term">wl_signal_add
-            - 
-Add the specified listener to this signal.         </span></dt><dd><pre class="synopsis">static void wl_signal_add(struct wl_signal *signal, struct wl_listener *listener)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">signal</span></dt><dd>
-The signal that will emit events to the listener </dd><dt><span class="term">listener</span></dt><dd>
-The listener to add </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__signal_1ab0ade7ac929136ad457cc1e0f34f9e10"></a><span class="term">wl_signal_get
-            - 
-Gets the listener struct for the specified callback.         </span></dt><dd><pre class="synopsis">static struct wl_listener * wl_signal_get(struct wl_signal *signal, wl_notify_func_t notify)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">signal</span></dt><dd>
-The signal that contains the specified listener </dd><dt><span class="term">notify</span></dt><dd>
-The listener that is the target of this search </dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>the list item that corresponds to the specified listener, or NULL if none was found </dd></dl></div><p>
-</p></dd><dt><a name="Server-structwl__signal_1afe73f44f7f1b517c9c0ba90829c93309"></a><span class="term">wl_signal_emit
-            - 
-Emits this signal, notifying all registered listeners.         </span></dt><dd><pre class="synopsis">static void wl_signal_emit(struct wl_signal *signal, void *data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">signal</span></dt><dd>
-The signal object that will emit the signal </dd><dt><span class="term">data</span></dt><dd>
-The data that will be emitted with the signal </dd></dl></div><p>
-</p></dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-structwl__socket"></a>wl_socket</h2></div></div></div><p></p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="Server-Functions"></a>Functions</h2></div></div></div><p></p><div class="variablelist"><dl class="variablelist"><dt><a name="Server-wayland-server-core_8h_1af1e9ad8dd32ea89265936930cd173ec5"></a><span class="term">wl_client_for_each
-            - 
-Iterate over a list of clients.         </span></dt><dd><pre class="synopsis"></pre></dd><dt><a name="Server-wayland-server-core_8h_1a869353bf26daf40e7317cd00473f8dcd"></a><span class="term">wl_display_global_filter_func_t
-            - 
-A filter function for wl_global objects.         </span></dt><dd><pre class="synopsis">typedef bool(* wl_display_global_filter_func_t) (const struct wl_client *client, const struct wl_global *global, void *data))(const struct wl_client *client, const struct wl_global *global, void *data)</pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">client</span></dt><dd>
-The client object </dd><dt><span class="term">global</span></dt><dd>
-The global object to show or hide </dd><dt><span class="term">data</span></dt><dd>
-The user data pointer</dd></dl></div><p>
-A filter function enables the server to decide which globals to advertise to each client.</p><p>When a <a class="link" href="apc.html#Server-structwl__global" title="wl_global">wl_global</a> filter is set, the given callback funtion will be called during <a class="link" href="apc.html#Server-structwl__global" title="wl_global">wl_global</a> advertisment and binding.</p><p>This function should return true if the global object should be made visible to the client or false otherwise. </p></dd><dt><a name="Server-wayland-server-core_8h_1adf933ad178be05536668da731acc6871"></a><span class="term">wl_event_loop_create</span></dt><dd><pre class="synopsis">struct wl_event_loop* wl_event_loop_create(void)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ad50f13e2c738e68f7576757aa862513a"></a><span class="term">wl_event_loop_destroy</span></dt><dd><pre class="synopsis">void wl_event_loop_destroy(struct wl_event_loop *loop)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a677f7df496a70388151e56a88c46ad36"></a><span class="term">wl_event_loop_add_fd</span></dt><dd><pre class="synopsis">struct wl_event_source* wl_event_loop_add_fd(struct wl_event_loop *loop, int fd, uint32_t mask, wl_event_loop_fd_func_t func, void *data)</pre></dd><dt><a name="Server-wayland-server-core_8h_1afe73f9ff59d489e9f27eb9c0e3058a02"></a><span class="term">wl_event_source_fd_update</span></dt><dd><pre class="synopsis">int wl_event_source_fd_update(struct wl_event_source *source, uint32_t mask)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a2881e5ca8c07dea463fbd526b6506f7f"></a><span class="term">wl_event_loop_add_timer</span></dt><dd><pre class="synopsis">struct wl_event_source* wl_event_loop_add_timer(struct wl_event_loop *loop, wl_event_loop_timer_func_t func, void *data)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a0baa596851764fb5a91da83642777000"></a><span class="term">wl_event_loop_add_signal</span></dt><dd><pre class="synopsis">struct wl_event_source* wl_event_loop_add_signal(struct wl_event_loop *loop, int signal_number, wl_event_loop_signal_func_t func, void *data)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a0164a47e9e8356af90c9d5c1de9f5487"></a><span class="term">wl_event_source_timer_update</span></dt><dd><pre class="synopsis">int wl_event_source_timer_update(struct wl_event_source *source, int ms_delay)</pre></dd><dt><a name="Server-wayland-server-core_8h_1afe37015d67b81ae82609f2b8aa78cc4f"></a><span class="term">wl_event_source_remove</span></dt><dd><pre class="synopsis">int wl_event_source_remove(struct wl_event_source *source)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aa079264c57dd12168c691c000724efcf"></a><span class="term">wl_event_source_check</span></dt><dd><pre class="synopsis">void wl_event_source_check(struct wl_event_source *source)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aaa3fdd5590365a4a2106c9814ca9b31b"></a><span class="term">wl_event_loop_dispatch</span></dt><dd><pre class="synopsis">int wl_event_loop_dispatch(struct wl_event_loop *loop, int timeout)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aefc44b3062c22d2506ff42460f091396"></a><span class="term">wl_event_loop_dispatch_idle</span></dt><dd><pre class="synopsis">void wl_event_loop_dispatch_idle(struct wl_event_loop *loop)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a2a1b5d6c1947954b0f74cfeb5f067b76"></a><span class="term">wl_event_loop_add_idle</span></dt><dd><pre class="synopsis">struct wl_event_source* wl_event_loop_add_idle(struct wl_event_loop *loop, wl_event_loop_idle_func_t func, void *data)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a58c8aa06a2d240a49a95a91eddcba8e5"></a><span class="term">wl_event_loop_get_fd</span></dt><dd><pre class="synopsis">int wl_event_loop_get_fd(struct wl_event_loop *loop)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a6b564d8d4183d71f1fdf06e751d84d51"></a><span class="term">wl_event_loop_add_destroy_listener</span></dt><dd><pre class="synopsis">void wl_event_loop_add_destroy_listener(struct wl_event_loop *loop, struct wl_listener *listener)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a2b199278145924742fd2672755d6f8e0"></a><span class="term">wl_event_loop_get_destroy_listener</span></dt><dd><pre class="synopsis">struct wl_listener* wl_event_loop_get_destroy_listener(struct wl_event_loop *loop, wl_notify_func_t notify)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a496bcdc506013f5fd47641777deb9618"></a><span class="term">wl_display_create</span></dt><dd><pre class="synopsis">struct wl_display* wl_display_create(void)</pre></dd><dt><a name="Server-wayland-server-core_8h_1acd9ad2e1ca3ffb0ba0f1b77ae616f8ee"></a><span class="term">wl_display_destroy</span></dt><dd><pre class="synopsis">void wl_display_destroy(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1afe7a4b1d6fbf166a66f686c830e2946c"></a><span class="term">wl_display_get_event_loop</span></dt><dd><pre class="synopsis">struct wl_event_loop* wl_display_get_event_loop(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a9fdf7264f0a3a28a75c141db252067b8"></a><span class="term">wl_display_add_socket</span></dt><dd><pre class="synopsis">int wl_display_add_socket(struct wl_display *display, const char *name)</pre></dd><dt><a name="Server-wayland-server-core_8h_1af867e52066bc5fff5bb0c1d971735f8f"></a><span class="term">wl_display_add_socket_auto</span></dt><dd><pre class="synopsis">const char* wl_display_add_socket_auto(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a54f1cf58cc74cd44c889b2cdf029345d"></a><span class="term">wl_display_add_socket_fd</span></dt><dd><pre class="synopsis">int wl_display_add_socket_fd(struct wl_display *display, int sock_fd)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a40e3041d2432d3941b3e8eb96c5284dc"></a><span class="term">wl_display_terminate</span></dt><dd><pre class="synopsis">void wl_display_terminate(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a999da1b9acb5808a3bbad60aaed8a7ff"></a><span class="term">wl_display_run</span></dt><dd><pre class="synopsis">void wl_display_run(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aeb502f6fdde16d9ee08f31aed040355f"></a><span class="term">wl_display_flush_clients</span></dt><dd><pre class="synopsis">void wl_display_flush_clients(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ab50365739904f91579a66f4b054a3ecb"></a><span class="term">wl_display_destroy_clients</span></dt><dd><pre class="synopsis">void wl_display_destroy_clients(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a43f04f76ea1457edcf37c95de68b29ef"></a><span class="term">wl_display_get_serial</span></dt><dd><pre class="synopsis">uint32_t wl_display_get_serial(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a145f7d3e4b41fc9014c11bf01bd7eb4f"></a><span class="term">wl_display_next_serial</span></dt><dd><pre class="synopsis">uint32_t wl_display_next_serial(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a9ea24547f07538f2a326c42c7793b937"></a><span class="term">wl_display_add_destroy_listener</span></dt><dd><pre class="synopsis">void wl_display_add_destroy_listener(struct wl_display *display, struct wl_listener *listener)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a8c1cdf513c91fa498c4d9259eae3ed71"></a><span class="term">wl_display_add_client_created_listener
-            - 
-Registers a listener for the client connection signal.         </span></dt><dd><pre class="synopsis">void wl_display_add_client_created_listener(struct wl_display *display, struct wl_listener *listener)</pre><p>When a new client object is created, listener will be notified, carrying a pointer to the new <a class="link" href="apc.html#Server-structwl__client" title="wl_client">wl_client</a> object.</p><p><a class="link" href="apc.html#Server-structwl__display_1aa2436b6a0b56cd65d8f6e33b76cd292c">wl_client_create</a> <a class="link" href="apc.html#Server-structwl__display" title="wl_display">wl_display</a> <a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display object </dd><dt><span class="term">listener</span></dt><dd>
-Signal handler object </dd></dl></div><p>
-</p></dd><dt><a name="Server-wayland-server-core_8h_1ad2e481a3157b1d182bb665a145230ae9"></a><span class="term">wl_display_get_destroy_listener</span></dt><dd><pre class="synopsis">struct wl_listener* wl_display_get_destroy_listener(struct wl_display *display, wl_notify_func_t notify)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a85f5bc1c041738f5663835c5565ce0b8"></a><span class="term">wl_global_create</span></dt><dd><pre class="synopsis">struct wl_global* wl_global_create(struct wl_display *display, const struct wl_interface *interface, int version, void *data, wl_global_bind_func_t bind)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ab466d94d1f204fb5f07c57e5f558ab7a"></a><span class="term">wl_global_destroy</span></dt><dd><pre class="synopsis">void wl_global_destroy(struct wl_global *global)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a3905b9734d8bb84f2c851bb4abbc52f8"></a><span class="term">wl_display_set_global_filter</span></dt><dd><pre class="synopsis">void wl_display_set_global_filter(struct wl_display *display, wl_display_global_filter_func_t filter, void *data)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a82c2f11ffbb50bdb57e07e275b2362e6"></a><span class="term">wl_global_get_interface</span></dt><dd><pre class="synopsis">const struct wl_interface* wl_global_get_interface(const struct wl_global *global)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ac8aa5d6a692cd28378c051b6a35c41da"></a><span class="term">wl_global_get_user_data</span></dt><dd><pre class="synopsis">void* wl_global_get_user_data(const struct wl_global *global)</pre></dd><dt><a name="Server-wayland-server-core_8h_1afb954d2c512f4d0140e25cd331c2cd9f"></a><span class="term">wl_client_create</span></dt><dd><pre class="synopsis">struct wl_client* wl_client_create(struct wl_display *display, int fd)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aa3a43d9b00d83d21af1274e186d7cd1d"></a><span class="term">wl_display_get_client_list</span></dt><dd><pre class="synopsis">struct wl_list* wl_display_get_client_list(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a495543089904236f253c1f0095f942a1"></a><span class="term">wl_client_get_link</span></dt><dd><pre class="synopsis">struct wl_list* wl_client_get_link(struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aee7e1851a470ebe47651db71bf24682d"></a><span class="term">wl_client_from_link</span></dt><dd><pre class="synopsis">struct wl_client* wl_client_from_link(struct wl_list *link)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a661c0b1a9deef909c5d43f5efe4cb524"></a><span class="term">wl_client_destroy</span></dt><dd><pre class="synopsis">void wl_client_destroy(struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a6a045ad15d6ca216c4da41ba67c9ef4a"></a><span class="term">wl_client_flush</span></dt><dd><pre class="synopsis">void wl_client_flush(struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a82a97cb3a66c1c56826a09a7b42453d9"></a><span class="term">wl_client_get_credentials</span></dt><dd><pre class="synopsis">void wl_client_get_credentials(struct wl_client *client, pid_t *pid, uid_t *uid, gid_t *gid)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ad5a94921b39efad0985632e865479ca2"></a><span class="term">wl_client_get_fd</span></dt><dd><pre class="synopsis">int wl_client_get_fd(struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a9062fe6277721ec5b4b7d3cec9e34981"></a><span class="term">wl_client_add_destroy_listener</span></dt><dd><pre class="synopsis">void wl_client_add_destroy_listener(struct wl_client *client, struct wl_listener *listener)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a6f20471027c1fe02e79af96426ef5bf4"></a><span class="term">wl_client_get_destroy_listener</span></dt><dd><pre class="synopsis">struct wl_listener* wl_client_get_destroy_listener(struct wl_client *client, wl_notify_func_t notify)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aa589ab039ac7e67a9da5ccdada9fcb4c"></a><span class="term">wl_client_get_object</span></dt><dd><pre class="synopsis">struct wl_resource* wl_client_get_object(struct wl_client *client, uint32_t id)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a12352da895372907cf30449435d8ee5f"></a><span class="term">wl_client_post_no_memory</span></dt><dd><pre class="synopsis">void wl_client_post_no_memory(struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a62a52be27947e43ce7884a68759d1b4e"></a><span class="term">wl_client_add_resource_created_listener</span></dt><dd><pre class="synopsis">void wl_client_add_resource_created_listener(struct wl_client *client, struct wl_listener *listener)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a4a0a6bb48f63ed80ab4575fda4c5d01a"></a><span class="term">wl_client_for_each_resource</span></dt><dd><pre class="synopsis">void wl_client_for_each_resource(struct wl_client *client, wl_client_for_each_resource_iterator_func_t iterator, void *user_data)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a67150e8e41fed1358dfd59d46fcda23b"></a><span class="term">wl_resource_post_event</span></dt><dd><pre class="synopsis">void wl_resource_post_event(struct wl_resource *resource, uint32_t opcode,...)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a97deed922e68853cb3785947926d56a7"></a><span class="term">wl_resource_post_event_array</span></dt><dd><pre class="synopsis">void wl_resource_post_event_array(struct wl_resource *resource, uint32_t opcode, union wl_argument *args)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a67891685eff3a9ebd5371d78ca83d516"></a><span class="term">wl_resource_queue_event</span></dt><dd><pre class="synopsis">void wl_resource_queue_event(struct wl_resource *resource, uint32_t opcode,...)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a9b63bd8423712f6edebfd6dae9e48225"></a><span class="term">wl_resource_queue_event_array</span></dt><dd><pre class="synopsis">void wl_resource_queue_event_array(struct wl_resource *resource, uint32_t opcode, union wl_argument *args)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a75428b89fa7e6aa97027bb74b348c386"></a><span class="term">wl_resource_post_error</span></dt><dd><pre class="synopsis">void wl_resource_post_error(struct wl_resource *resource, uint32_t code, const char *msg,...)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aefff369c8182adc3c29ea561e23b9fd8"></a><span class="term">wl_resource_post_no_memory</span></dt><dd><pre class="synopsis">void wl_resource_post_no_memory(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a1a69200af1f06ccbcd218b2328f3c885"></a><span class="term">wl_client_get_display</span></dt><dd><pre class="synopsis">struct wl_display* wl_client_get_display(struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a26b54247cd0b84c9e228e2a2f9227f8c"></a><span class="term">wl_resource_create</span></dt><dd><pre class="synopsis">struct wl_resource* wl_resource_create(struct wl_client *client, const struct wl_interface *interface, int version, uint32_t id)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a9ac84b9077dcf2020f2b847189d4ebc0"></a><span class="term">wl_resource_set_implementation</span></dt><dd><pre class="synopsis">void wl_resource_set_implementation(struct wl_resource *resource, const void *implementation, void *data, wl_resource_destroy_func_t destroy)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a6d127d9e4489ae795850a9b32d8c5637"></a><span class="term">wl_resource_set_dispatcher</span></dt><dd><pre class="synopsis">void wl_resource_set_dispatcher(struct wl_resource *resource, wl_dispatcher_func_t dispatcher, const void *implementation, void *data, wl_resource_destroy_func_t destroy)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a4fd83132742252516c9a3df7f4eaa4d7"></a><span class="term">wl_resource_destroy</span></dt><dd><pre class="synopsis">void wl_resource_destroy(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ae265d2902bc8e0994b26a3f43e63448c"></a><span class="term">wl_resource_get_id</span></dt><dd><pre class="synopsis">uint32_t wl_resource_get_id(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ab1de3c23a75ddb99ff8c29c0e759a39b"></a><span class="term">wl_resource_get_link</span></dt><dd><pre class="synopsis">struct wl_list* wl_resource_get_link(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a6ed2f937f570b36e7842c5a0bd3d754b"></a><span class="term">wl_resource_from_link</span></dt><dd><pre class="synopsis">struct wl_resource* wl_resource_from_link(struct wl_list *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a4ac3fbd1d228f441c6846f3ebccc9c6e"></a><span class="term">wl_resource_find_for_client</span></dt><dd><pre class="synopsis">struct wl_resource* wl_resource_find_for_client(struct wl_list *list, struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a300147832089811f11d345fbc3f47fe6"></a><span class="term">wl_resource_get_client</span></dt><dd><pre class="synopsis">struct wl_client* wl_resource_get_client(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aa9b40199dbf513b6a25263872b8490c6"></a><span class="term">wl_resource_set_user_data</span></dt><dd><pre class="synopsis">void wl_resource_set_user_data(struct wl_resource *resource, void *data)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a07f2328aa269ff1968afc4836018204f"></a><span class="term">wl_resource_get_user_data</span></dt><dd><pre class="synopsis">void* wl_resource_get_user_data(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a8f0f7d0b0f0fb9f44ccd3694b3dd58d5"></a><span class="term">wl_resource_get_version</span></dt><dd><pre class="synopsis">int wl_resource_get_version(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ab69024ab2f0f502aa70cf18bb2761882"></a><span class="term">wl_resource_set_destructor</span></dt><dd><pre class="synopsis">void wl_resource_set_destructor(struct wl_resource *resource, wl_resource_destroy_func_t destroy)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a8849a58c3ba7a528c643591369125844"></a><span class="term">wl_resource_instance_of</span></dt><dd><pre class="synopsis">int wl_resource_instance_of(struct wl_resource *resource, const struct wl_interface *interface, const void *implementation)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ae570127d26c63db09db82afa3a8cda2d"></a><span class="term">wl_resource_get_class</span></dt><dd><pre class="synopsis">const char* wl_resource_get_class(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a6eac87009589e0bdc52830833ca46694"></a><span class="term">wl_resource_add_destroy_listener</span></dt><dd><pre class="synopsis">void wl_resource_add_destroy_listener(struct wl_resource *resource, struct wl_listener *listener)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a46364ef94b5671f41f4cb9587070b23f"></a><span class="term">wl_resource_get_destroy_listener</span></dt><dd><pre class="synopsis">struct wl_listener* wl_resource_get_destroy_listener(struct wl_resource *resource, wl_notify_func_t notify)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a55964fd7a5774ed9f94bfadce6f8a8ce"></a><span class="term">wl_shm_buffer_get</span></dt><dd><pre class="synopsis">struct wl_shm_buffer* wl_shm_buffer_get(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a809cb5d6b33338c62bbca6daa4138667"></a><span class="term">wl_shm_buffer_begin_access</span></dt><dd><pre class="synopsis">void wl_shm_buffer_begin_access(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a030db6056ef08836e9dee21a8087e2c1"></a><span class="term">wl_shm_buffer_end_access</span></dt><dd><pre class="synopsis">void wl_shm_buffer_end_access(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-server-core_8h_1adeb4b01f2ecca2cbd9002d6d64f16ac4"></a><span class="term">wl_shm_buffer_get_data</span></dt><dd><pre class="synopsis">void* wl_shm_buffer_get_data(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ad132f92b616451c67aeb6a25cc60f282"></a><span class="term">wl_shm_buffer_get_stride</span></dt><dd><pre class="synopsis">int32_t wl_shm_buffer_get_stride(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-server-core_8h_1af27bd34e94cc995f25a08a0beadd8bc9"></a><span class="term">wl_shm_buffer_get_format</span></dt><dd><pre class="synopsis">uint32_t wl_shm_buffer_get_format(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ada7167ed92985de64ff9116b09a07708"></a><span class="term">wl_shm_buffer_get_width</span></dt><dd><pre class="synopsis">int32_t wl_shm_buffer_get_width(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-server-core_8h_1acd6812b7699de5a1b80eb4bf1c78aa0e"></a><span class="term">wl_shm_buffer_get_height</span></dt><dd><pre class="synopsis">int32_t wl_shm_buffer_get_height(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ae4dc5539543e07f3c9b9b69f0566d53f"></a><span class="term">wl_shm_buffer_ref_pool</span></dt><dd><pre class="synopsis">struct wl_shm_pool* wl_shm_buffer_ref_pool(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a2349156a6b7940645a4754e6c1690051"></a><span class="term">wl_shm_pool_unref</span></dt><dd><pre class="synopsis">void wl_shm_pool_unref(struct wl_shm_pool *pool)</pre></dd><dt><a name="Server-wayland-server-core_8h_1aef08c24892f8fa98431e0610ee487ef7"></a><span class="term">wl_display_init_shm</span></dt><dd><pre class="synopsis">int wl_display_init_shm(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a17e2cee84d163f938f8906b6f9a5089e"></a><span class="term">wl_display_add_shm_format</span></dt><dd><pre class="synopsis">uint32_t* wl_display_add_shm_format(struct wl_display *display, uint32_t format)</pre></dd><dt><a name="Server-wayland-server-core_8h_1a2c1c1d3e116c9491e1e66525e74a85bb"></a><span class="term">wl_shm_buffer_create</span></dt><dd><pre class="synopsis">struct wl_shm_buffer* wl_shm_buffer_create(struct wl_client *client, uint32_t id, int32_t width, int32_t height, int32_t stride, uint32_t format) WL_DEPRECATED</pre></dd><dt><a name="Server-wayland-server-core_8h_1a0a0e1384dce2524161299fcd1669d59f"></a><span class="term">wl_log_set_handler_server</span></dt><dd><pre class="synopsis">void wl_log_set_handler_server(wl_log_func_t handler)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ad50c4a699b66a468825fd14d09a9c864"></a><span class="term">wl_display_add_protocol_logger</span></dt><dd><pre class="synopsis">struct wl_protocol_logger* wl_display_add_protocol_logger(struct wl_display *display, wl_protocol_logger_func_t, void *user_data)</pre></dd><dt><a name="Server-wayland-server-core_8h_1ac5bfbf098cbecb788190bc12e3becad7"></a><span class="term">wl_protocol_logger_destroy</span></dt><dd><pre class="synopsis">void wl_protocol_logger_destroy(struct wl_protocol_logger *logger)</pre></dd><dt><a name="Server-wayland-server_8c_1a97deed922e68853cb3785947926d56a7"></a><span class="term">wl_resource_post_event_array</span></dt><dd><pre class="synopsis">void wl_resource_post_event_array(struct wl_resource *resource, uint32_t opcode, union wl_argument *args)</pre></dd><dt><a name="Server-wayland-server_8c_1a67150e8e41fed1358dfd59d46fcda23b"></a><span class="term">wl_resource_post_event</span></dt><dd><pre class="synopsis">void wl_resource_post_event(struct wl_resource *resource, uint32_t opcode,...)</pre></dd><dt><a name="Server-wayland-server_8c_1a9b63bd8423712f6edebfd6dae9e48225"></a><span class="term">wl_resource_queue_event_array</span></dt><dd><pre class="synopsis">void wl_resource_queue_event_array(struct wl_resource *resource, uint32_t opcode, union wl_argument *args)</pre></dd><dt><a name="Server-wayland-server_8c_1a67891685eff3a9ebd5371d78ca83d516"></a><span class="term">wl_resource_queue_event</span></dt><dd><pre class="synopsis">void wl_resource_queue_event(struct wl_resource *resource, uint32_t opcode,...)</pre></dd><dt><a name="Server-wayland-server_8c_1a75428b89fa7e6aa97027bb74b348c386"></a><span class="term">wl_resource_post_error</span></dt><dd><pre class="synopsis">void wl_resource_post_error(struct wl_resource *resource, uint32_t code, const char *msg,...)</pre></dd><dt><a name="Server-wayland-server_8c_1a12352da895372907cf30449435d8ee5f"></a><span class="term">wl_client_post_no_memory</span></dt><dd><pre class="synopsis">void wl_client_post_no_memory(struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server_8c_1aefff369c8182adc3c29ea561e23b9fd8"></a><span class="term">wl_resource_post_no_memory</span></dt><dd><pre class="synopsis">void wl_resource_post_no_memory(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server_8c_1a4fd83132742252516c9a3df7f4eaa4d7"></a><span class="term">wl_resource_destroy</span></dt><dd><pre class="synopsis">void wl_resource_destroy(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server_8c_1ae265d2902bc8e0994b26a3f43e63448c"></a><span class="term">wl_resource_get_id</span></dt><dd><pre class="synopsis">uint32_t wl_resource_get_id(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server_8c_1ab1de3c23a75ddb99ff8c29c0e759a39b"></a><span class="term">wl_resource_get_link</span></dt><dd><pre class="synopsis">struct wl_list* wl_resource_get_link(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server_8c_1a9851271c75c89ed572987126278834d9"></a><span class="term">wl_resource_from_link</span></dt><dd><pre class="synopsis">struct wl_resource* wl_resource_from_link(struct wl_list *link)</pre></dd><dt><a name="Server-wayland-server_8c_1a4ac3fbd1d228f441c6846f3ebccc9c6e"></a><span class="term">wl_resource_find_for_client</span></dt><dd><pre class="synopsis">struct wl_resource* wl_resource_find_for_client(struct wl_list *list, struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server_8c_1a300147832089811f11d345fbc3f47fe6"></a><span class="term">wl_resource_get_client</span></dt><dd><pre class="synopsis">struct wl_client* wl_resource_get_client(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server_8c_1aa9b40199dbf513b6a25263872b8490c6"></a><span class="term">wl_resource_set_user_data</span></dt><dd><pre class="synopsis">void wl_resource_set_user_data(struct wl_resource *resource, void *data)</pre></dd><dt><a name="Server-wayland-server_8c_1a07f2328aa269ff1968afc4836018204f"></a><span class="term">wl_resource_get_user_data</span></dt><dd><pre class="synopsis">void* wl_resource_get_user_data(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server_8c_1a8f0f7d0b0f0fb9f44ccd3694b3dd58d5"></a><span class="term">wl_resource_get_version</span></dt><dd><pre class="synopsis">int wl_resource_get_version(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-server_8c_1ab69024ab2f0f502aa70cf18bb2761882"></a><span class="term">wl_resource_set_destructor</span></dt><dd><pre class="synopsis">void wl_resource_set_destructor(struct wl_resource *resource, wl_resource_destroy_func_t destroy)</pre></dd><dt><a name="Server-wayland-server_8c_1a8849a58c3ba7a528c643591369125844"></a><span class="term">wl_resource_instance_of</span></dt><dd><pre class="synopsis">int wl_resource_instance_of(struct wl_resource *resource, const struct wl_interface *interface, const void *implementation)</pre></dd><dt><a name="Server-wayland-server_8c_1a6eac87009589e0bdc52830833ca46694"></a><span class="term">wl_resource_add_destroy_listener</span></dt><dd><pre class="synopsis">void wl_resource_add_destroy_listener(struct wl_resource *resource, struct wl_listener *listener)</pre></dd><dt><a name="Server-wayland-server_8c_1a46364ef94b5671f41f4cb9587070b23f"></a><span class="term">wl_resource_get_destroy_listener</span></dt><dd><pre class="synopsis">struct wl_listener* wl_resource_get_destroy_listener(struct wl_resource *resource, wl_notify_func_t notify)</pre></dd><dt><a name="Server-wayland-server_8c_1a9062fe6277721ec5b4b7d3cec9e34981"></a><span class="term">wl_client_add_destroy_listener</span></dt><dd><pre class="synopsis">void wl_client_add_destroy_listener(struct wl_client *client, struct wl_listener *listener)</pre></dd><dt><a name="Server-wayland-server_8c_1a6f20471027c1fe02e79af96426ef5bf4"></a><span class="term">wl_client_get_destroy_listener</span></dt><dd><pre class="synopsis">struct wl_listener* wl_client_get_destroy_listener(struct wl_client *client, wl_notify_func_t notify)</pre></dd><dt><a name="Server-wayland-server_8c_1a661c0b1a9deef909c5d43f5efe4cb524"></a><span class="term">wl_client_destroy</span></dt><dd><pre class="synopsis">void wl_client_destroy(struct wl_client *client)</pre></dd><dt><a name="Server-wayland-server_8c_1a85f5bc1c041738f5663835c5565ce0b8"></a><span class="term">wl_global_create</span></dt><dd><pre class="synopsis">struct wl_global* wl_global_create(struct wl_display *display, const struct wl_interface *interface, int version, void *data, wl_global_bind_func_t bind)</pre></dd><dt><a name="Server-wayland-server_8c_1ab466d94d1f204fb5f07c57e5f558ab7a"></a><span class="term">wl_global_destroy</span></dt><dd><pre class="synopsis">void wl_global_destroy(struct wl_global *global)</pre></dd><dt><a name="Server-wayland-server_8c_1a82c2f11ffbb50bdb57e07e275b2362e6"></a><span class="term">wl_global_get_interface</span></dt><dd><pre class="synopsis">const struct wl_interface* wl_global_get_interface(const struct wl_global *global)</pre></dd><dt><a name="Server-wayland-server_8c_1ac8aa5d6a692cd28378c051b6a35c41da"></a><span class="term">wl_global_get_user_data</span></dt><dd><pre class="synopsis">void* wl_global_get_user_data(const struct wl_global *global)</pre></dd><dt><a name="Server-wayland-server_8c_1afe7a4b1d6fbf166a66f686c830e2946c"></a><span class="term">wl_display_get_event_loop</span></dt><dd><pre class="synopsis">struct wl_event_loop* wl_display_get_event_loop(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server_8c_1a40e3041d2432d3941b3e8eb96c5284dc"></a><span class="term">wl_display_terminate</span></dt><dd><pre class="synopsis">void wl_display_terminate(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server_8c_1a999da1b9acb5808a3bbad60aaed8a7ff"></a><span class="term">wl_display_run</span></dt><dd><pre class="synopsis">void wl_display_run(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server_8c_1aeb502f6fdde16d9ee08f31aed040355f"></a><span class="term">wl_display_flush_clients</span></dt><dd><pre class="synopsis">void wl_display_flush_clients(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server_8c_1af867e52066bc5fff5bb0c1d971735f8f"></a><span class="term">wl_display_add_socket_auto</span></dt><dd><pre class="synopsis">const char* wl_display_add_socket_auto(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-server_8c_1a9ea24547f07538f2a326c42c7793b937"></a><span class="term">wl_display_add_destroy_listener</span></dt><dd><pre class="synopsis">void wl_display_add_destroy_listener(struct wl_display *display, struct wl_listener *listener)</pre></dd><dt><a name="Server-wayland-server_8c_1a8c1cdf513c91fa498c4d9259eae3ed71"></a><span class="term">wl_display_add_client_created_listener
-            - 
-Registers a listener for the client connection signal.         </span></dt><dd><pre class="synopsis">void wl_display_add_client_created_listener(struct wl_display *display, struct wl_listener *listener)</pre><p>When a new client object is created, listener will be notified, carrying a pointer to the new <a class="link" href="apc.html#Server-structwl__client" title="wl_client">wl_client</a> object.</p><p><a class="link" href="apc.html#Server-structwl__display_1aa2436b6a0b56cd65d8f6e33b76cd292c">wl_client_create</a> <a class="link" href="apc.html#Server-structwl__display" title="wl_display">wl_display</a> <a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a></p><div class="variablelist"><dl class="variablelist"><dt><span class="term">display</span></dt><dd>
-The display object </dd><dt><span class="term">listener</span></dt><dd>
-Signal handler object </dd></dl></div><p>
-</p></dd><dt><a name="Server-wayland-server_8c_1ad2e481a3157b1d182bb665a145230ae9"></a><span class="term">wl_display_get_destroy_listener</span></dt><dd><pre class="synopsis">struct wl_listener* wl_display_get_destroy_listener(struct wl_display *display, wl_notify_func_t notify)</pre></dd><dt><a name="Server-wayland-server_8c_1a9ac84b9077dcf2020f2b847189d4ebc0"></a><span class="term">wl_resource_set_implementation</span></dt><dd><pre class="synopsis">void wl_resource_set_implementation(struct wl_resource *resource, const void *implementation, void *data, wl_resource_destroy_func_t destroy)</pre></dd><dt><a name="Server-wayland-server_8c_1a6d127d9e4489ae795850a9b32d8c5637"></a><span class="term">wl_resource_set_dispatcher</span></dt><dd><pre class="synopsis">void wl_resource_set_dispatcher(struct wl_resource *resource, wl_dispatcher_func_t dispatcher, const void *implementation, void *data, wl_resource_destroy_func_t destroy)</pre></dd><dt><a name="Server-wayland-server_8c_1a0a0e1384dce2524161299fcd1669d59f"></a><span class="term">wl_log_set_handler_server</span></dt><dd><pre class="synopsis">void wl_log_set_handler_server(wl_log_func_t handler)</pre></dd><dt><a name="Server-wayland-server_8h_1a86592c8dfc359094d1cfd8e6abb47cb7"></a><span class="term">wl_client_add_resource</span></dt><dd><pre class="synopsis">uint32_t wl_client_add_resource(struct wl_client *client, struct wl_resource *resource) WL_DEPRECATED</pre></dd><dt><a name="Server-wayland-server_8h_1a8a87f8712025b4d92e5fe718ea9d745d"></a><span class="term">wl_client_add_object</span></dt><dd><pre class="synopsis">struct wl_resource* wl_client_add_object(struct wl_client *client, const struct wl_interface *interface, const void *implementation, uint32_t id, void *data) WL_DEPRECATED</pre></dd><dt><a name="Server-wayland-server_8h_1ab9570639a66efe77ae813c7edaf29c21"></a><span class="term">wl_client_new_object</span></dt><dd><pre class="synopsis">struct wl_resource* wl_client_new_object(struct wl_client *client, const struct wl_interface *interface, const void *implementation, void *data) WL_DEPRECATED</pre></dd><dt><a name="Server-wayland-server_8h_1a81dc2de5891114d1ae89449a048f3b6c"></a><span class="term">wl_display_add_global</span></dt><dd><pre class="synopsis">struct wl_global* wl_display_add_global(struct wl_display *display, const struct wl_interface *interface, void *data, wl_global_bind_func_t bind) WL_DEPRECATED</pre></dd><dt><a name="Server-wayland-server_8h_1ab9bbf24496934f296decd98ebf7940b9"></a><span class="term">wl_display_remove_global</span></dt><dd><pre class="synopsis">void wl_display_remove_global(struct wl_display *display, struct wl_global *global) WL_DEPRECATED</pre></dd><dt><a name="Server-wayland-shm_8c_1aef08c24892f8fa98431e0610ee487ef7"></a><span class="term">wl_display_init_shm</span></dt><dd><pre class="synopsis">int wl_display_init_shm(struct wl_display *display)</pre></dd><dt><a name="Server-wayland-shm_8c_1a55964fd7a5774ed9f94bfadce6f8a8ce"></a><span class="term">wl_shm_buffer_get</span></dt><dd><pre class="synopsis">struct wl_shm_buffer* wl_shm_buffer_get(struct wl_resource *resource)</pre></dd><dt><a name="Server-wayland-shm_8c_1ad132f92b616451c67aeb6a25cc60f282"></a><span class="term">wl_shm_buffer_get_stride</span></dt><dd><pre class="synopsis">int32_t wl_shm_buffer_get_stride(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-shm_8c_1af27bd34e94cc995f25a08a0beadd8bc9"></a><span class="term">wl_shm_buffer_get_format</span></dt><dd><pre class="synopsis">uint32_t wl_shm_buffer_get_format(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-shm_8c_1ada7167ed92985de64ff9116b09a07708"></a><span class="term">wl_shm_buffer_get_width</span></dt><dd><pre class="synopsis">int32_t wl_shm_buffer_get_width(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-shm_8c_1acd6812b7699de5a1b80eb4bf1c78aa0e"></a><span class="term">wl_shm_buffer_get_height</span></dt><dd><pre class="synopsis">int32_t wl_shm_buffer_get_height(struct wl_shm_buffer *buffer)</pre></dd><dt><a name="Server-wayland-util_8h_1a3b28bd92b6af30b28f13c09e45269d5b"></a><span class="term">WL_EXPORT
-            - 
-Visibility attribute.         </span></dt><dd><pre class="synopsis"></pre></dd><dt><a name="Server-wayland-util_8h_1a9ef5a521a018de9c5b28a5ef9909cd33"></a><span class="term">WL_DEPRECATED
-            - 
-Deprecated attribute.         </span></dt><dd><pre class="synopsis"></pre></dd><dt><a name="Server-wayland-util_8h_1aa7cbf0ab788d6898c97f322630577424"></a><span class="term">WL_PRINTF
-            - 
-Printf-style argument attribute.         </span></dt><dd><pre class="synopsis"></pre><div class="variablelist"><dl class="variablelist"><dt><span class="term">x</span></dt><dd>
-Ordinality of the format string argument </dd><dt><span class="term">y</span></dt><dd>
-Ordinality of the argument to check against the format string</dd></dl></div><p>
-
-  See also: https://gcc.gnu.org/onlinedocs/gcc-3.2.1/gcc/Function-Attributes.html 
-</p></dd><dt><a name="Server-wayland-util_8h_1a09e3b64ee2195e1b80191aa1884d45aa"></a><span class="term">wl_container_of
-            - 
-Retrieves a pointer to a containing struct, given a member name.         </span></dt><dd><pre class="synopsis"></pre><p>This macro allows "conversion" from a pointer to a member to its containing struct. This is useful if you have a contained item like a <a class="link" href="apc.html#Server-structwl__list" title="wl_list - Doubly-linked list.">wl_list</a>, <a class="link" href="apc.html#Server-structwl__listener" title="wl_listener - A single listener for Wayland signals.">wl_listener</a>, or <a class="link" href="apc.html#Server-structwl__signal" title="wl_signal - A source of a type of observable event.">wl_signal</a>, provided via a callback or other means, and would like to retrieve the struct that contains it.</p><p>To demonstrate, the following example retrieves a pointer to example_container given only its destroy_listener member:</p><p>
-          </p><pre class="programlisting">struct example_container {
-        struct wl_listener destroy_listener;
-        // other members...
-};
-
-void example_container_destroy(struct wl_listener *listener, void *data)
-{
-        struct example_container *ctr;
-
-        ctr = wl_container_of(listener, ctr, destroy_listener);
-        // destroy ctr...
-}
-</pre><p>
-        </p><p><span class="emphasis"><em>Note: sample need not be a valid pointer. A null or uninitialised pointer is sufficient.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">ptr</span></dt><dd>
-Valid pointer to the contained member </dd><dt><span class="term">sample</span></dt><dd>
-Pointer to a struct whose type contains ptr </dd><dt><span class="term">member</span></dt><dd>
-Named location of ptr within the sample type</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>The container for the specified pointer </dd></dl></div><p>
-</p></dd><dt><a name="Server-wayland-util_8h_1adb093d005a4b7e04111b7e385349cf23"></a><span class="term">wl_iterator_result
-            - 
-Return value of an iterator function.         </span></dt><dd><pre class="synopsis"></pre><p>
-  See also: <a class="link" href="">wl_client_for_each_resource_iterator_func_t</a> 
-
-  See also: <a class="link" href="apc.html#Server-structwl__client_1a4a0a6bb48f63ed80ab4575fda4c5d01a">wl_client_for_each_resource</a> 
-</p></dd><dt><a name="Server-wayland-util_8h_1a546c8b2b06f97d0617000db4fb4feeeb"></a><span class="term">wl_fixed_t
-            - 
-Fixed-point number.         </span></dt><dd><pre class="synopsis">typedef int32_t wl_fixed_t</pre><p>A wl_fixed_t is a 24.8 signed fixed-point number with a sign bit, 23 bits of integer precision and 8 bits of decimal precision. Consider wl_fixed_t as an opaque struct with methods that facilitate conversion to and from double and int types. </p></dd><dt><a name="Server-wayland-util_8h_1abdec454d1dffed08d355d225e21ac8bd"></a><span class="term">wl_dispatcher_func_t
-            - 
-Dispatcher function type alias.         </span></dt><dd><pre class="synopsis">typedef int(* wl_dispatcher_func_t) (const void *, void *, uint32_t, const struct wl_message *, union wl_argument *))(const void *, void *, uint32_t, const struct wl_message *, union wl_argument *)</pre><p>A dispatcher is a function that handles the emitting of callbacks in client code. For programs directly using the C library, this is done by using libffi to call function pointers. When binding to languages other than C, dispatchers provide a way to abstract the function calling process to be friendlier to other function calling systems.</p><p>A dispatcher takes five arguments: The first is the dispatcher-specific implementation associated with the target object. The second is the object upon which the callback is being invoked (either wl_proxy or <a class="link" href="apc.html#Server-structwl__resource" title="wl_resource">wl_resource</a>). The third and fourth arguments are the opcode and the <a class="link" href="apc.html#Server-structwl__message" title="wl_message - Protocol message signature.">wl_message</a> corresponding to the callback. The final argument is an array of arguments received from the other process via the wire protocol.</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">const void *</span></dt><dd>
-Dispatcher-specific implementation data </dd><dt><span class="term">void *</span></dt><dd>
-Callback invocation target (wl_proxy or <a class="link" href="apc.html#Server-structwl__resource" title="wl_resource">wl_resource</a>) </dd><dt><span class="term">uint32_t</span></dt><dd>
-Callback opcode </dd><dt><span class="term">const struct wl_message *</span></dt><dd>
-Callback message signature </dd><dt><span class="term">union wl_argument *</span></dt><dd>
-Array of received arguments</dd></dl></div><p>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Returns:</span></dt><dd>0 on success, or -1 on failure </dd></dl></div><p>
-</p></dd><dt><a name="Server-wayland-util_8h_1a8bbe3cc915acdaf00f7a183bf03d809c"></a><span class="term">wl_log_func_t
-            - 
-Log function type alias.         </span></dt><dd><pre class="synopsis">typedef void(* wl_log_func_t) (const char *, va_list))(const char *, va_list)</pre><p>The C implementation of the Wayland protocol abstracts the details of logging. Users may customize the logging behavior, with a function conforming to the wl_log_func_t type, via wl_log_set_handler_client and wl_log_set_handler_server.</p><p>A wl_log_func_t must conform to the expectations of vprintf, and expects two arguments: a string to write and a corresponding variable argument list. While the string to write may contain format specifiers and use values in the variable argument list, the behavior of any wl_log_func_t depends on the implementation.</p><p><span class="emphasis"><em>Note: Take care to not confuse this with wl_protocol_logger_func_t, which is a specific server-side logger for requests and events.</em></span>
-</p><div class="variablelist"><dl class="variablelist"><dt><span class="term">const char *</span></dt><dd>
-String to write to the log, containing optional format specifiers </dd><dt><span class="term">va_list</span></dt><dd>
-Variable argument list</dd></dl></div><p>
-
-  See also: wl_log_set_handler_client 
-
-  See also: <a class="link" href="apc.html#Server-wayland-server-core_8h_1a0a0e1384dce2524161299fcd1669d59f">wl_log_set_handler_server</a> 
-</p></dd></dl></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="apb.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">Appendix B. Client API </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
diff --git a/docs/html/ch01.html b/docs/html/ch01.html
deleted file mode 100644
index ac01b2f..0000000
--- a/docs/html/ch01.html
+++ /dev/null
@@ -1,73 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Chapter 1. Introduction</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="pr02.html" title="Acknowledgments"><link rel="next" href="ch02.html" title="Chapter 2. Types of Compositors"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 1. Introduction</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="pr02.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch02.html">Next</a></td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="chap-Introduction"></a>Chapter 1. Introduction</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="ch01.html#sect-Motivation">Motivation</a></span></dt><dt><span class="section"><a href="ch01.html#sect-Compositing-manager-display-server">The compositing manager as the display server</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Motivation"></a>Motivation</h2></div></div></div><p>
-      Most Linux and Unix-based systems rely on the X Window System (or
-      simply <span class="emphasis"><em>X</em></span>) 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).
-    </p><p>
-      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.
-    </p><div class="mediaobject"><img src="images/x-architecture.png" alt="X architecture diagram"></div><p>
-      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.
-    </p><p>
-      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.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Compositing-manager-display-server"></a>The compositing manager as the display server</h2></div></div></div><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      Overall, the philosophy of Wayland is to provide clients with a way to
-      manage windows and how their contents is displayed.  Rendering is left
-      to clients, and system wide memory management interfaces are used to
-      pass buffer handles between clients and the compositing manager.
-    </p><div class="mediaobject"><img src="images/wayland-architecture.png" alt="Wayland architecture diagram"></div><p>
-      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).
-    </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="pr02.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Acknowledgments </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 2. Types of Compositors</td></tr></table></div></body></html>
diff --git a/docs/html/ch02.html b/docs/html/ch02.html
deleted file mode 100644
index 1aec416..0000000
--- a/docs/html/ch02.html
+++ /dev/null
@@ -1,77 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Chapter 2. Types of Compositors</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="ch01.html" title="Chapter 1. Introduction"><link rel="next" href="ch03.html" title="Chapter 3. Wayland Architecture"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 2. Types of Compositors</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch01.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch03.html">Next</a></td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="chap-Compositors"></a>Chapter 2. Types of Compositors</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="ch02.html#sect-Compositors-System-Compositor">System Compositor</a></span></dt><dt><span class="section"><a href="ch02.html#sect-Compositors-Session-Compositor">Session Compositor</a></span></dt><dt><span class="section"><a href="ch02.html#sect-Compositors-Embedding-Compositor">Embedding Compositor</a></span></dt></dl></div><p>
-    Compositors come in different types, depending on which
-    role they play in the overall architecture of the OS.
-    For instance, a
-    <a class="link" href="ch02.html#sect-Compositors-System-Compositor" title="System Compositor">system compositor</a>
-    can be used for booting the system, handling multiple user switching, a
-    possible console terminal emulator and so forth. A different compositor, a
-    <a class="link" href="ch02.html#sect-Compositors-Session-Compositor" title="Session Compositor">session compositor</a>
-    would provide the actual desktop environment. There are many ways for
-    different types of compositors to co-exist.
-  </p><p>
-    In this section, we introduce three types of Wayland compositors relying
-    on <a class="link" href="apc.html" title="Appendix C. Server API">libwayland-server</a>.
-  </p><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Compositors-System-Compositor"></a>System Compositor</h2></div></div></div><p>
-      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.
-    </p><p>
-      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).
-    </p><p>
-      A linux implementation of a system compositor will typically
-      use libudev, egl, kms, evdev and cairo.
-    </p><p>
-      For fullscreen clients, the system compositor can reprogram the
-      video scanout address to read directly from the client provided
-      buffer.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Compositors-Session-Compositor"></a>Session Compositor</h2></div></div></div><p>
-      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 hw.
-     </p><p>
-      X applications can continue working under a session compositor
-      by means of a root-less X server that is activated on demand.
-     </p><p>
-       Possible examples for session compositors include
-      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
-	    gnome-shell
-	  </p></li><li class="listitem"><p>
-	    moblin
-	  </p></li><li class="listitem"><p>
-	    kwin
-	  </p></li><li class="listitem"><p>
-	    kmscon
-	  </p></li><li class="listitem"><p>
-	    rdp session
-	  </p></li><li class="listitem"><p>
-	    Weston with X11 or Wayland backend is a session compositor nested
-	    in another session compositor.
-	  </p></li><li class="listitem"><p>
-	    fullscreen X session under Wayland
-	  </p></li></ul></div><p>
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Compositors-Embedding-Compositor"></a>Embedding Compositor</h2></div></div></div><p>
-      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.
-    </p><p>
-      An example for this kind of setup is firefox embedding the flash
-      player as a kind of special-purpose compositor.
-    </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch01.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch03.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 1. Introduction </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 3. Wayland Architecture</td></tr></table></div></body></html>
diff --git a/docs/html/ch03.html b/docs/html/ch03.html
deleted file mode 100644
index 9b6de01..0000000
--- a/docs/html/ch03.html
+++ /dev/null
@@ -1,237 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Chapter 3. Wayland Architecture</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="ch02.html" title="Chapter 2. Types of Compositors"><link rel="next" href="ch04.html" title="Chapter 4. Wayland Protocol and Model of Operation"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 3. Wayland Architecture</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch02.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch04.html">Next</a></td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="chap-Wayland-Architecture"></a>Chapter 3. Wayland Architecture</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="ch03.html#sect-Wayland-Architecture-wayland_architecture">X vs. Wayland Architecture</a></span></dt><dt><span class="section"><a href="ch03.html#sect-Wayland-Architecture-wayland_rendering">Wayland Rendering</a></span></dt><dt><span class="section"><a href="ch03.html#sect-Wayland-Architecture-wayland_hw_enabling">Hardware Enabling for Wayland</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Wayland-Architecture-wayland_architecture"></a>X vs. Wayland Architecture</h2></div></div></div><p>
-      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.
-    </p><p>
-      This is where we are now with X:
-    </p><div class="figure"><a name="idm140152825430224"></a><p class="title"><b>Figure 3.1. X architecture diagram</b></p><div class="figure-contents"><div class="mediaobjectco"><img border="0" usemap="#map1" src="images/x-architecture.png" alt="X architecture diagram"><map name="map1"><area shape="rect" href="ch03.html#x_flow_1" coords="198,346,221,373"><area shape="rect" href="ch03.html#x_flow_2" coords="124,160,146,187"><area shape="rect" href="ch03.html#x_flow_3" coords="37,65,60,92"><area shape="rect" href="ch03.html#x_flow_4" coords="230,265,252,292"><area shape="rect" href="ch03.html#x_flow_5" coords="250,211,273,238"><area shape="rect" href="ch03.html#x_flow_6" coords="118,305,141,332"></map></div></div></div><br class="figure-break"><p>
-      </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p><a name="x_flow_1"></a>
-	    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.
-	  </p></li><li class="listitem"><p><a name="x_flow_2"></a>
-	    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).
-	  </p></li><li class="listitem"><p><a name="x_flow_3"></a>
-	    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.
-	  </p></li><li class="listitem"><p><a name="x_flow_4"></a>
-	    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.
-	  </p></li><li class="listitem"><p><a name="x_flow_5"></a>
-	    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.
-	  </p></li><li class="listitem"><p><a name="x_flow_6"></a>
-	    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.
-	  </p></li></ol></div><p>
-    </p><p>
-      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.
-    </p><p>
-      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:
-    </p><div class="figure"><a name="idm140152825611760"></a><p class="title"><b>Figure 3.2. Wayland architecture diagram</b></p><div class="figure-contents"><div class="mediaobjectco"><img border="0" usemap="#mapB" src="images/wayland-architecture.png" alt="Wayland architecture diagram"><map name="mapB"><area shape="rect" href="ch03.html#wayland_flow_1" coords="271,414,293,440"><area shape="rect" href="ch03.html#wayland_flow_2" coords="337,132,360,159"><area shape="rect" href="ch03.html#wayland_flow_3" coords="290,81,312,107"><area shape="rect" href="ch03.html#wayland_flow_4" coords="185,414,207,441"></map></div></div></div><br class="figure-break"><p>
-      </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p><a name="wayland_flow_1"></a>
-	    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.
-	  </p></li><li class="listitem"><p><a name="wayland_flow_2"></a>
-	    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.
-	  </p></li><li class="listitem"><p><a name="wayland_flow_3"></a>
-	    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.
-	  </p></li><li class="listitem"><p><a name="wayland_flow_4"></a>
-	    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.
-	  </p></li></ol></div><p>
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Wayland-Architecture-wayland_rendering"></a>Wayland Rendering</h2></div></div></div><p>
-      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.
-    </p><p>
-      This leaves an application with two ways to update its window contents:
-    </p><p>
-      </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
-	    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.
-	  </p></li><li class="listitem"><p>
-	    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.
-	  </p></li></ol></div><p>
-    </p><p>
-      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.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Wayland-Architecture-wayland_hw_enabling"></a>Hardware Enabling for Wayland</h2></div></div></div><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch02.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch04.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 2. Types of Compositors </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 4. Wayland Protocol and Model of Operation</td></tr></table></div></body></html>
diff --git a/docs/html/ch04.html b/docs/html/ch04.html
deleted file mode 100644
index 3a16f2b..0000000
--- a/docs/html/ch04.html
+++ /dev/null
@@ -1,381 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Chapter 4. Wayland Protocol and Model of Operation</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="ch03.html" title="Chapter 3. Wayland Architecture"><link rel="next" href="ch05.html" title="Chapter 5. X11 Application Support"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 4. Wayland Protocol and Model of Operation</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch03.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch05.html">Next</a></td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="chap-Protocol"></a>Chapter 4. Wayland Protocol and Model of Operation</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="ch04.html#sect-Protocol-Basic-Principles">Basic Principles</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Code-Generation">Code Generation</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Wire-Format">Wire Format</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Interfaces">Interfaces</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Versioning">Versioning</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Connect-Time">Connect Time</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Security-and-Authentication">Security and Authentication</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Creating-Objects">Creating Objects</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Compositor">Compositor</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Surface">Surfaces</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Input">Input</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Output">Output</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-data-sharing">Data sharing between clients</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Basic-Principles"></a>Basic Principles</h2></div></div></div><p>
-      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.
-    </p><p>
-      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
-      <a class="xref" href="ch04.html#sect-Protocol-Wire-Format" title="Wire Format">the section called “Wire Format”</a> for a list of argument types).
-    </p><p>
-      Additionally, the protocol can specify <span class="type">enum</span>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.
-    </p><p>
-      <span class="type">enum</span>s can be defined as just a set of integers, or as
-      bitfields.  This is specified via the <span class="type">bitfield</span> boolean
-      attribute in the <span class="type">enum</span> 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.
-    </p><p>
-      The <span class="type">enum</span> attribute can be used on either <span class="type">uint</span>
-      or <span class="type">int</span> arguments, however if the <span class="type">enum</span> is
-      defined as a <span class="type">bitfield</span>, it can only be used on
-      <span class="type">uint</span> args.
-    </p><p>
-      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.
-    </p><p>
-      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
-	    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.
-	  </p></li><li class="listitem"><p>
-	    The server will broadcast the presence of a number of global objects,
-	    which in turn will broadcast their current state.
-	  </p></li></ul></div><p>
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Code-Generation"></a>Code Generation</h2></div></div></div><p>
-      The interfaces, requests and events are defined in
-      <code class="filename">protocol/wayland.xml</code>.
-      This xml is used to generate the function prototypes that can be used by
-      clients and compositors.
-    </p><p>
-      The protocol entry points are generated as inline functions which just
-      wrap the <code class="function">wl_proxy_*</code> 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.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Wire-Format"></a>Wire Format</h2></div></div></div><p>
-      The protocol is sent over a UNIX domain stream socket, where the endpoint
-      usually is named <code class="systemitem">wayland-0</code>
-      (although it can be changed via <span class="emphasis"><em>WAYLAND_DISPLAY</em></span>
-      in the environment). Beginning in Wayland 1.15, implementations can
-      optionally support server socket endpoints located at arbitrary
-      locations in the filesystem by setting <span class="emphasis"><em>WAYLAND_DISPLAY</em></span>
-      to the absolute path at which the server endpoint listens.
-    </p><p>
-      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:
-      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
-	    The first word is the sender's object ID (32-bit).
-	  </p></li><li class="listitem"><p>
-	    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.
-	  </p></li></ul></div><p>
-      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.
-    </p><p>
-
-      The representation of argument types are as follows:
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">int, </span><span class="term">uint</span></dt><dd><p>
-	      The value is the 32-bit value of the signed/unsigned
-	      int.
-	    </p></dd><dt><span class="term">fixed</span></dt><dd><p>
-	      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.
-	    </p></dd><dt><span class="term">string</span></dt><dd><p>
-	      Starts with an unsigned 32-bit length, followed by the
-	      string contents, including terminating null byte, then padding
-	      to a 32-bit boundary.
-	    </p></dd><dt><span class="term">object</span></dt><dd><p>
-	      32-bit object ID.
-	    </p></dd><dt><span class="term">new_id</span></dt><dd><p>
-	      The 32-bit object ID.  On requests, the client
-	      decides the ID.  The only events with <span class="type">new_id</span> are
-	      advertisements of globals, and the server will use IDs below
-	      0x10000.
-	    </p></dd><dt><span class="term">array</span></dt><dd><p>
-	      Starts with 32-bit array size in bytes, followed by the array
-	      contents verbatim, and finally padding to a 32-bit boundary.
-	    </p></dd><dt><span class="term">fd</span></dt><dd><p>
-	      The file descriptor is not stored in the message buffer, but in
-	      the ancillary data of the UNIX domain socket message (msg_control).
-	    </p></dd></dl></div><p>
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Interfaces"></a>Interfaces</h2></div></div></div><p>
-      The protocol includes several interfaces which are used for
-      interacting with the server.  Each interface provides requests,
-      events, and errors (which are really just special events) as described
-      above.  Specific compositor implementations may have their own
-      interfaces provided as extensions, but there are several which are
-      always expected to be present.
-    </p><p>
-      Core interfaces:
-      </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_display" title="wl_display - core global object">wl_display</a></span></dt><dd>core global object</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_registry" title="wl_registry - global registry object">wl_registry</a></span></dt><dd>global registry object</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_callback" title="wl_callback - callback object">wl_callback</a></span></dt><dd>callback object</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_compositor" title="wl_compositor - the compositor singleton">wl_compositor</a></span></dt><dd>the compositor singleton</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_shm_pool" title="wl_shm_pool - a shared memory pool">wl_shm_pool</a></span></dt><dd>a shared memory pool</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_shm" title="wl_shm - shared memory support">wl_shm</a></span></dt><dd>shared memory support</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_buffer" title="wl_buffer - content for a wl_surface">wl_buffer</a></span></dt><dd>content for a wl_surface</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_data_offer" title="wl_data_offer - offer to transfer data">wl_data_offer</a></span></dt><dd>offer to transfer data</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_data_source" title="wl_data_source - offer to transfer data">wl_data_source</a></span></dt><dd>offer to transfer data</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_data_device" title="wl_data_device - data transfer device">wl_data_device</a></span></dt><dd>data transfer device</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_data_device_manager" title="wl_data_device_manager - data transfer interface">wl_data_device_manager</a></span></dt><dd>data transfer interface</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_shell" title="wl_shell - create desktop-style surfaces">wl_shell</a></span></dt><dd>create desktop-style surfaces</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_shell_surface" title="wl_shell_surface - desktop-style metadata interface">wl_shell_surface</a></span></dt><dd>desktop-style metadata interface</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">wl_surface</a></span></dt><dd>an onscreen surface</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_seat" title="wl_seat - group of input devices">wl_seat</a></span></dt><dd>group of input devices</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_pointer" title="wl_pointer - pointer input device">wl_pointer</a></span></dt><dd>pointer input device</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_keyboard" title="wl_keyboard - keyboard input device">wl_keyboard</a></span></dt><dd>keyboard input device</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_touch" title="wl_touch - touchscreen input device">wl_touch</a></span></dt><dd>touchscreen input device</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_output" title="wl_output - compositor output region">wl_output</a></span></dt><dd>compositor output region</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_region" title="wl_region - region interface">wl_region</a></span></dt><dd>region interface</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_subcompositor" title="wl_subcompositor - sub-surface compositing">wl_subcompositor</a></span></dt><dd>sub-surface compositing</dd><dt><span class="term"><a class="link" href="apa.html#protocol-spec-wl_subsurface" title="wl_subsurface - sub-surface interface to a wl_surface">wl_subsurface</a></span></dt><dd>sub-surface interface to a wl_surface</dd></dl></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Versioning"></a>Versioning</h2></div></div></div><p>
-      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.
-    </p><p>
-      In order to keep things sane, this has a few implications for
-      interface versions:
-      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
-	    The object creation hierarchy must be a tree.  Otherwise,
-	    infering object versions from the parent object becomes a much
-	    more difficult to properly track.
-	  </p></li><li class="listitem"><p>
-	    When the version of an interface increases, so does the version
-	    of its parent (recursively until you get to a global interface)
-	  </p></li><li class="listitem"><p>
-	    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.
-	  </p></li></ul></div><p>
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Connect-Time"></a>Connect Time</h2></div></div></div><p>
-      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.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Security-and-Authentication"></a>Security and Authentication</h2></div></div></div><p>
-      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
-	    mostly about access to underlying buffers, need new drm auth
-	    mechanism (the grant-to ioctl idea), need to check the cmd stream?
-	  </p></li><li class="listitem"><p>
-	    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.
-	  </p></li></ul></div><p>
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Creating-Objects"></a>Creating Objects</h2></div></div></div><p>
-      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-existant 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.  Any ID allocation
-      algorithm that does not maintain this property is incompatible with
-      the implementation in libwayland.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Compositor"></a>Compositor</h2></div></div></div><p>
-      The compositor is a global object, advertised at connect time.
-    </p><p>
-      See <a class="xref" href="apa.html#protocol-spec-wl_compositor" title="wl_compositor - the compositor singleton">the section called “wl_compositor
-	- the compositor singleton”</a> for the
-      protocol description.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Surface"></a>Surfaces</h2></div></div></div><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      See <a class="xref" href="apa.html#protocol-spec-wl_surface" title="wl_surface - an onscreen surface">the section called “wl_surface
-	- an onscreen surface”</a> for the protocol
-      description.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Input"></a>Input</h2></div></div></div><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      See <a class="xref" href="apa.html#protocol-spec-wl_seat" title="wl_seat - group of input devices">the section called “wl_seat
-	- group of input devices”</a> for the
-      protocol description.
-    </p><p>
-      Talk about:
-
-      </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
-	    keyboard map, change events
-	  </p></li><li class="listitem"><p>
-	    xkb on Wayland
-	  </p></li><li class="listitem"><p>
-	    multi pointer Wayland
-	  </p></li></ul></div><p>
-    </p><p>
-      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.
-    </p><p>
-      The compositor will revert the pointer image back to a default image
-      when no surface has the pointer focus for that device.  Clients can
-      revert the pointer image back to the default image by setting a NULL
-      image.
-    </p><p>
-      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.  Broken app, I suppose.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-Output"></a>Output</h2></div></div></div><p>
-      An output is a global object, advertised at connect time or as it
-      comes and goes.
-    </p><p>
-      See <a class="xref" href="apa.html#protocol-spec-wl_output" title="wl_output - compositor output region">the section called “wl_output
-	- compositor output region”</a> for the protocol
-      description.
-    </p><p>
-    </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
-	  laid out in a big (compositor) coordinate system
-	</p></li><li class="listitem"><p>
-	  basically xrandr over Wayland
-	</p></li><li class="listitem"><p>
-	  geometry needs position in compositor coordinate system
-	</p></li><li class="listitem"><p>
-	  events to advertise available modes, requests to move and change
-	  modes
-	</p></li></ul></div></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-Protocol-data-sharing"></a>Data sharing between clients</h2></div></div></div><p>
-      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
-      <code class="function">wl_data_source</code> object and the clients
-      obtaining the data will see it as <code class="function">wl_data_offer</code>
-      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.
-    </p><p>
-      The next section explains the negotiation between data source and
-      data offer objects. <a class="xref" href="ch04.html#sect-Protocol-data-sharing-devices" title="Data devices">the section called “Data devices”</a>
-      explains how these objects are created and passed to different
-      clients using the <code class="function">wl_data_device</code> interface
-      that implements copy-paste and drag-and-drop support.
-    </p><p>
-      See <a class="xref" href="apa.html#protocol-spec-wl_data_offer" title="wl_data_offer - offer to transfer data">the section called “wl_data_offer
-	- offer to transfer data”</a>,
-      <a class="xref" href="apa.html#protocol-spec-wl_data_source" title="wl_data_source - offer to transfer data">the section called “wl_data_source
-	- offer to transfer data”</a>,
-      <a class="xref" href="apa.html#protocol-spec-wl_data_device" title="wl_data_device - data transfer device">the section called “wl_data_device
-	- data transfer device”</a> and
-      <a class="xref" href="apa.html#protocol-spec-wl_data_device_manager" title="wl_data_device_manager - data transfer interface">the section called “wl_data_device_manager
-	- data transfer interface”</a> for
-      protocol descriptions.
-    </p><p>
-      MIME is defined in RFC's 2045-2049. A
-      <a class="ulink" href="ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/" target="_top">
-      registry of MIME types</a> is maintained by the Internet Assigned
-      Numbers Authority (IANA).
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="idm140152825031120"></a>Data negotiation</h3></div></div></div><p>
-	A client providing data to other clients will create a <code class="function">wl_data_source</code>
-	object and advertise the mime types for the formats it supports for
-	that data through the <code class="function">wl_data_source.offer</code>
-	request. On the receiving end, the data offer object will generate one
-	<code class="function">wl_data_offer.offer</code> event for each supported mime
-	type.
-      </p><p>
-	The actual data transfer happens when the receiving client sends a
-	<code class="function">wl_data_offer.receive</code> request. This request takes
-	a mime type and a file descriptor as arguments. This request will generate a
-	<code class="function">wl_data_source.send</code> 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.
-      </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="sect-Protocol-data-sharing-devices"></a>Data devices</h3></div></div></div><p>
-	Data devices glue data sources and offers together. A data device is
-	associated with a <code class="function">wl_seat</code> and is obtained by the clients using the
-	<code class="function">wl_data_device_manager</code> factory object, which is also responsible for
-	creating data sources.
-      </p><p>
-	Clients are informed of new data offers through the
-	<code class="function">wl_data_device.data_offer</code> 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.
-      </p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="idm140152819621744"></a>Selection</h4></div></div></div><p>
-	  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
-	  <code class="function">wl_data_device.selection</code> event. This event is
-	  also generated on a client immediately before it receives keyboard
-	  focus.
-	</p><p>
-	  The data offer is introduced with
-	  <code class="function">wl_data_device.data_offer</code> event before the
-	  selection event.
-	</p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a name="idm140152824513488"></a>Drag and Drop</h4></div></div></div><p>
-	  A drag-and-drop operation is started using the
-	  <code class="function">wl_data_device.start_drag</code> 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
-	  <code class="function">wl_data_device.enter</code> event. The data offer
-	  is introduced to the client prior to the enter event with the
-	  <code class="function">wl_data_device.data_offer</code> event.
-	</p><p>
-	  Clients are expected to provide feedback to the data sending client
-	  by calling the <code class="function">wl_data_offer.accept</code> 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 <code class="function">wl_data_source.target</code> event with the
-	  chosen mime type.
-	</p><p>
-	  When the drag ends, the receiving client receives a
-	  <code class="function">wl_data_device.drop</code> event at which it is expected
-	  to transfer the data using the
-	  <code class="function">wl_data_offer.receive</code> request.
-	</p></div></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch03.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch05.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 3. Wayland Architecture </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 5. X11 Application Support</td></tr></table></div></body></html>
diff --git a/docs/html/ch05.html b/docs/html/ch05.html
deleted file mode 100644
index d3df824..0000000
--- a/docs/html/ch05.html
+++ /dev/null
@@ -1,120 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Chapter 5. X11 Application Support</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="ch04.html" title="Chapter 4. Wayland Protocol and Model of Operation"><link rel="next" href="apa.html" title="Appendix A. Wayland Protocol Specification"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 5. X11 Application Support</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch04.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="apa.html">Next</a></td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="chap-X11-Application-Support"></a>Chapter 5. X11 Application Support</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="section"><a href="ch05.html#sect-X11-Application-Support-introduction">Introduction</a></span></dt><dt><span class="section"><a href="ch05.html#sect-X11-Application-Support-two-modes">Two Modes for Foreign Windows</a></span></dt><dt><span class="section"><a href="ch05.html#sect-X11-Application-Support-architecture">Architecture</a></span></dt><dt><span class="section"><a href="ch05.html#sect-X11-Application-Support-xwm">X Window Manager (XWM)</a></span></dt></dl></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-X11-Application-Support-introduction"></a>Introduction</h2></div></div></div><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-X11-Application-Support-two-modes"></a>Two Modes for Foreign Windows</h2></div></div></div><p>
-      In general, windows from a foreign window system can be presented in one
-      of two ways: rootless and rootful (not rootless).
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      This chapter concentrates on the rootless mode, and ignores the rootful
-      mode.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-X11-Application-Support-architecture"></a>Architecture</h2></div></div></div><p>
-      A Wayland compositor usually takes care of launching Xwayland.
-      Xwayland works in cooperation with a Wayland compositor as follows:
-    </p><div class="figure"><a name="idm140152827324336"></a><p class="title"><b>Figure 5.1. Xwayland architecture diagram</b></p><div class="figure-contents"><div class="mediaobjectco"><img border="0" usemap="#" src="images/xwayland-architecture.png" alt="Xwayland architecture diagram"><map name=""></map></div></div></div><br class="figure-break"><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sect-X11-Application-Support-xwm"></a>X Window Manager (XWM)</h2></div></div></div><p>
-      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.
-    </p><p>
-      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 asynchonous by design.
-    </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a name="sect-X11-Application-Support-xwm-window-identification"></a>Window identification</h3></div></div></div><p>
-        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.
-      </p><p>
-        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.
-      </p></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch04.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="apa.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 4. Wayland Protocol and Model of Operation </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Appendix A. Wayland Protocol Specification</td></tr></table></div></body></html>
diff --git a/docs/html/css/brand.css b/docs/html/css/brand.css
deleted file mode 100644
index d86cba9..0000000
--- a/docs/html/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/docs/html/css/common.css b/docs/html/css/common.css
deleted file mode 100644
index a05648e..0000000
--- a/docs/html/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/docs/html/css/default.css b/docs/html/css/default.css
deleted file mode 100644
index bf38ebb..0000000
--- a/docs/html/css/default.css
+++ /dev/null
@@ -1,3 +0,0 @@
- at import url("common.css");
- at import url("overrides.css");
- at import url("lang.css");
diff --git a/docs/html/css/epub.css b/docs/html/css/epub.css
deleted file mode 100644
index b0ffd43..0000000
--- a/docs/html/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/docs/html/css/print.css b/docs/html/css/print.css
deleted file mode 100644
index 54088f4..0000000
--- a/docs/html/css/print.css
+++ /dev/null
@@ -1,15 +0,0 @@
- at import url("common.css");
- at import url("overrides.css");
- at import url("lang.css");
-
-#tocframe {
-	display: none;
-}
-
-body.toc_embeded {
-	margin-left: 30px;
-}
-
-.producttitle {
-	color: #336699;
-}
diff --git a/docs/html/images/icon.svg b/docs/html/images/icon.svg
deleted file mode 100644
index b2f16d0..0000000
--- a/docs/html/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/docs/html/images/wayland-architecture.png b/docs/html/images/wayland-architecture.png
deleted file mode 100644
index 84dcbbfe03f72e837ccc42721fb259563f391b18..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 28435
zcmb at uby!y2w>D}aAt=&~Al-s=DS~u&i*$o at D}qQXNVjyibO-{{3Os~#OGqOPXFTt3
z|MtGFbDgu#+28kF?;pNAJZr7F<{Wd3d))Uu306{&#KIuKxOVLtmb8?(%C&3Php%0`
zp^kPNJ_)>{JcNI4zm$~}zjlTEFTE)@`r5Sz*QCXts<|g`PP at 5BFQ2yV+6yq?F_7x;
z1d0)(e9Er)WUC$Wo$ocLcn9Ue^~iM8gV!N<)Sg73eRjV#p=!$D6|4N5Q3=De$D-Hf
z%@$pYD23Qjk7xA3rJiO<R`;36V9NWt{XR`|4kAo6ssQXZ6E+>x2Lae(d;-!rV(>`<
zO#%jdZWd+21fRxBN9ALSp&8Nrum6&__$Id4($lnCZanRO`gb at mRkp0jKVo|f*F7yK
zQCcU?JLYs(8x^1~9O|YW4=7XZu9;h)$F3ua+O{AM$Icn9d$MMpF)FE)(=_^1E09K&
zYBT)lJx%lW!0r#PG&d{)%8FzzTDM7e@;<xJ5YTq3p?Q5)d_CMwWtBhr5zR=LLga_L
zuzU3n0i4i}@JdZm%~)LxPi at MOzw{|d{b9lQX*(OPq(WZ#Lh7CI^xT$f at x%LVu6iMD
z(SqqCsydP{d9+C$1_+~hJ;TXo at IFAt{)LKDYDpeE0dtj6EvP%+d80TJTZ}ZAcWzUw
zIFlm at Mp<Pd^``P_L;!=T3cm?w%jTy5Mx_)dzL>0X at 7#PonPEgTYQ4hx-^t75P-1Sb
zKegOmP9j@>Cf4JhmnPh=Ob}?weHq`R&_IO2w5RZE)oc6B+Om+G(ssj{c%BG$2#UWZ
zy9M8knM8ESK~p~iyR?LdzNr)SkJUHO`l#VeSS2nKH+u19-}-SMx{n1XM^5 at spLOw*
zk2O1rEaDPWnz0|>)eyDdp$KTP7ZbyoihMg9XEd<=!v+sC8N-dtJGzi(JMWgLpYe5t
z`UX-QHf?5_!f2R2jVSy4-65eW`_EfWGEp_gRGS!TOwnhKM-;8yp~Ss-UmhLZ`z<JO
z_*kv*8rO{fuxR^R(Yg8Cd}pG^j$~B at _j+Ah2a~EIwC>z~Z;<VRO&8td5%@!9lZx9c
zF~~I>5w}~8=8k=jHpJB1N0EUD6MG!vZ<_yyeQZ)xgH-LvVNo5lF}7B*?WaqO$3<4*
zB$z+yh>H at E4_h(}@m;)Fu{Hi^6eG at m3G{!Sw_>J~+CY<|V}+%_ at nbX$B5p8IJuG8S
znnws{tT)>}v>2A6?en2`5-G7$-(l0;aR{^&iNDv)s8oHU=$yfty1&R?kZ81 at r+gyi
z_>PX`3r^Sq7PQ=cT-pVnPz@;$`5M^t7M*Nwj<9wuQqT?`EM}KG?riWNP_+GsKK;(H
z3paRsw2~jpn;<dshI)D=e*9x4f7itW3YouZT^9+1 at +oq`U3qJy1tq3}b25(`FT)d;
z7Jp(fHQ%}rQJ$XX50(vJyrbSEkruS)lfH3g<vpxMXxBQLxxPCdm#*eG+}k7VOZVUp
zy1H?B=U}E9ySrJK06k;Sz<pJb!46#ne<!8S!xrhJ+U$*6m+gD*Tz9=CXx3Kn#kfvp
zy^DNs4?B|irA6KcEv~A|Rx05CSR2{z{AP(47tf<wrC)C%;G4QGHn2HD>!N#1Xp?pq
z%Q~lNMW5ib>dmqsqHe#_lybjxQq8-X`B|LViC0?Ax9EvC9PW#{G4bJcovl6kJF7-$
zr*}z4zPk at hpZ(YsM#R{CipTUrDV!XS+avTd6O70e_AL*$G>vb6 at w(jU#Y$q>Abs|e
zAC at j>E~MutrlUsJAF7Hda#4R#d&)x(Ye at FmF>K$VHu1Vu)fHY=R!+5)wdU=#3T(2w
zyTQbfvc4lXq(x8i<j{$T(foYSR|%h<Kd=2lrlF{T&U{MIxMw=*KI2)HvL5w^xW!~R
zspjc)%g=|b-K!lV?n6m+x0zy<SM?09yN%^L%4}CKjqdJOq;gs1$Yga0%{BbQu9iVG
zxzP!!Q#R|Tv>bDBeVJ+$%80Fj(JxlguJ1D#;E9kG(FqGrrHc#);;NN)z2T^4p{GYV
z5khsl(XL at Jt#om*$ah$?>)IK7ME5Z^ANy|Wc%q!#ySL^;^;Y4F>1*_O)#ysa at blaR
z9dTsga<N%7iBD?3=Wx%mT5qMxGYbyAYKzF^Kr<Jv&fz?|<i;!=o=i_OmPLnJfx&k2
zcP{-`XOFp44|?MKFDlc;@~c)2Y%+C>Z;Ax6N{%d2M>by!7zE-sj4bkRw-)LT4OmYr
z$?xRz;+0JIT%B>$lNWCFdg7n!IZ4dE&6gcnL_}v;?^lfp3BQmscW=9w*p%;!Cr^Ht
zo5_?lH$BbVi1wcqDUD2Qy^%2biG-dqTQMiRf`9AhqAQA)p-z67OkX;VlbQXY#?gdJ
zFG-qLUDGM&mw?8FM<g?>i-ax8UGyV9Dl(nlj=QcS$aQ*kY2*7s2m^O7<Rf*NH;xKt
zg6S_f>4pwS5Ne__nD3I~)bJ1XS&A at D?9r*nBpa?F{5gErXtP^0xU5uUU)%q3OrWQt
z&Ca4t+vKqxca<x)7Q(wb2AK-c_j%jY$4-jg{YtVLZ}mz1`dt*nVU10YXL4OfB4tje
zv097g-@!O`loB>84QD;EU;CXU<MbD;v_V_HSNN;^_f at u(Lk|>+ELW2j$1 at -88Q-7#
zn^$ey_&naxg!6*C-EN7auJAu+B*3wV>vt6iy|DB1 at U$;>pB|w<{;O{6{4^KAw>Iy*
zn47?BeLSYeP3qk3`o1>SXTd*gvFbT(NOtwoP>lkiz53(|_uoKs5`s<PMBGT_pVS^>
z(Y}eHj`HSqy at 5<|y$yYvM7YW}WO`wbi!oKFeI9F1y--4DS1*l~U&C6j>m!`)v(&JE
zDmvIE16BKO+qlFT$J21)t?ryqLN)98{M(jX?%`e8hA(egsSJ%VBNlnR+P+RWSYy%H
zDkO1m<{582BBrNiolW>+UhKG_{8TqP_I(!~EoJ}9e%p!u!^xbO3!8dMc59~zt_czu
z5uHJSvS*#rPxz<luqtf52cG})&=#F~)|=0U!{3@!CjDG2nfZ}?v^f1rd|Gr&O}^1`
zt+bwYdKl|6xhc_04$CSp;C>p~otnI at nGgF+Pw^k`YEx6F66r>EQ4hJk?_uGKJFKe9
z*XOsj*_}jS at BgTJCHM1KdF*Onv4Flkc2Cf2G670z+Z&?jr2%Y26tm8)#Iat_WJjE+
zUB2(XI;=OD4iCOJm&gaH5jq-NvQLZC7`tuHMOd;npI4{}p&*)K>RTLc`u3X at E**=<
ze`!0|6D7^?#nx*=XZI at _omnwEq|hpxI5-W1&19xJTYFR0sU_9F1E0NM%Snf4ISk7G
z{FAWa-u|EwLUrb=%{UsOv{`S4V(w2Kbfu5b?S*coT^5*`(9z_h^G6drN$WldT?-tw
zlG{Bn)jIec^~pYwWB0qtE}mMGmDT8@)+DaEmJLMCt>EtUAgSD4ru&Hn*)6}u4RTeB
zx8FS+`PIMEqOR%fO`Y6uTh!J+cSfT at boxtcKsM8|(L!d)WcMATALeC8StJh?<lf1C
zEEsz^bOWtyhxTM$L;Xm$rf}w#ZcSMAgG!G;hX<Vj7Ml@$LIzf9eb4$8gt2oj75o@^
zGYKd2mKry1dDlLf9<o+?7G8eo_~0mhN^kyfYyFO(dg-Vc&)@!w<V`Im3e`RjNuRZ#
z<e;Ck`MRE0-sooWwT?IQ%9k;+=ZdwhtegFO)Aq}63bwvql`my(l76cu>;4OaJKwtd
z?`EV^wL_(ql=)#M&2f=VrnOpW;=bL~17uQ>dcw+}%lT(JIm&WntU}jt{qx&?!&W~7
zWma at IUIh1K7LPaVZNIcHRS(%8HslIZAejADwYXCKnO0HG%-STMsZC2vrOQck&zwxs
zb9}wAA!lfJkC3pv=;x2(Kr4RF+CuH0$hh;eVPiR|DVW4 at 7C3%ILza-~8e5>N?vhEk
zuOup$YF)t7!*>{My3S>#eD5+IgFIE~%D_qI)smd^?Pn|KLt<!2wdb_rjioMl1m%Ye
z&J?Ai6bAY^Q32Q}8hwPR{P6idX+F_0HEpA_$vVg-Mx3c{zV=G-dwf2&jw5S^%Pq4|
z*?<#LglW%|-tcG&h7k at g7SE$E*hrL-t;JgWkVAWkd}l3gx6bYKi9A+G7<IDLBV4nR
z33TK)Ito#KPqlt%7qPqBDuIe%Dqt at 5=F<W++|GRXY4m=)9Nh!-jO at iX4qnlt%4kNY
z&Oc76 at v6sTI&Ec;zoFgsvmk$i{Wn8SFi1Y at 0RTo@b&_keB$niX*uM(7wf~JG*QQ$S
z- at y$sie)Y``YLrKjR=rWFSe1)6VlsY2>9_X=-#nUrVE}K5*!NeTwU*R{sEBJrZ=16
zvB4dRnCggcHc at hcWvBvfXj&Puy=clrwVooUyt6VJQY>PzooGgi0H=9wP{&!22V;*e
z&fg3l6GTKxS|(r^De8rYwRb4l^VG&61W2e@<WOU7i-kT^h>?1#lOr}>x-{vqi~C;h
zR<~PK#B;RaH9dsQw9eI=A=~PRPA1rzM%xF{4y%f_O~e%M@@bMzpKRm>d`}o4pX$w%
zCz27qiGL>0L6bR!1m$Q{eKf}ZKieO1HXIzBs=H75uEA8GeGHWdC2%}Hb}Vkkb{&x4
zxCSki#@0+zZ!*6VpVwa&UtizGla-`T%$jUtP6H`|UH&L{#%t^;1yTl{f5eb{n8brd
zg%SAuyVQ*vH{J&aKP??wTv+grizB3>qEgFOq3zl~Jy>i1Rc)<Z_Tu`ppu5%jt!)`n
zyrtNmmEr|lm>xZPL_<#>otP-|>J?{sdAavqH+@|yAqB<V)>_BKTDR>~Rx$j$QjnQH
zEAcu1#_sO!CQg-AP at rRAU>MtHGi=6eeT#Z8{;_2gVgWZo{-5vVX;;#fl#~#sIypLK
zXcX)4r#fwnvQmh6qvd at QG#?;~AQv=4 at C6zpJ46P&=iwxW?nQWN)Z9dvVHCmwT~2Iz
zwIAl~2?+_GhY`IoD6O$7YTHFlG9JdD$QjGVXmKW7Q`^v>+T!b at QEDKctB~?aXmz0@
zl-O)%{m>I`-^t!`{_^enz=t2RABnve%hW72U@>Tnr%!eFM-*zVdYlK|A>?3lXV54j
zD%P#ZaatX?b?cUvpxXS4EK?Yh8Z|X_o@%Z_bA;_g1+CxtF6vmRA?l0oAE?48MN<h_
zb+ov|=U at Npt1#Fne|}Z(yV!I^kW-5OJvyR){CGsi2ptuPI>j^YlatHK$;mbA=B#ns
zO~vEVD`-(M&0`{)WQ_3l at 6ld+*T at auK|}ixoB#bIw0+_kj+f^iLPA1$I at MNh2C>l4
z<~qYk#U&+msW|6<|Ld~-)j`!ljbfH0-X+P!&hYDe9(!5Y?KlcgkkkKz;k(>SUt?2K
zzEXyNSW<|MG;-=lR%lc|II4c+f|z?R_K=#oEvsAd`QgTxpEo`+)ljqxgkl2$K7L2N
z%LdxryL3!UA)h5e7gkp#;k7*ePMA|}S0}}J9c?+D{k5%($}cUoZ+2C{35=|g3&eJ1
z6c9+f|M2;bENR>bGJdhiFSZ_Me`<(1P0$Ps47?A1N{$rk##LL7trRv^nh)MkDm4&}
zHZIU_;Q9FRqmcVf>k?;xQxu at uwyn+CmNXHcQx50fN&{)4in|LPT#Yl8=8AN3 at vRxp
zf`|m18Fatc7<Gmb<1wnxbaA$~w==3_p>bP{aPYGk7ycc}mVInB at _p%5z&;Wtx0M9E
zdpDG;NJ+qM&_`(K{S<B}EhY7Uh9;mtiMP_UmjIq}FR#fde7eQBE26)8YG=pc{QO)_
zhroDgV<S`{*GsPj`#EGFY}bdhw1HpWqVAuprinH`{*}mWy|cIX*>X5X=<0mmd2J|A
zz-9eMjy$PCs!(ulE`2Bg>&w-Flp?)4&aMg=X8-yE%Fe+-mP)ovl$->?P(O1(8L4b6
zONQs+IwmR4=B|^pw6xIKW at VM#bfOia;Nz!H-(U%ld;QIuH+r=W*A*2N3E1?$_p-P2
zg|aulPtqMN{Q|?SciXme4TISoc=gkP3K=1ro#!X}37n=f?^bVP61Bd*ev?zkJUQUt
zXx7hZz71u4v{<&%tUpgV^ERwhruA3}am3ihp}4qs{4^&@j9j)U6KAxY0abwh`^ZR$
z=1+hBOs;xt!u0>xICS^$Fda9qF&|8|nf$`qyQ^8EM<pUM^Rin_Cx at B~(k|7e|E at qL
ze=#XJ|0|lOPoGY;_ at yyxmZT4_#q-)zq^71uM(!RRnQzZDX%BGQRVmfj=~pfmsbph}
zmFROdkj?8M_f^>)n2b6$TSpg{ehvaF4kEr+OF*r_wvdvM>3Ox4z-7*0*etZ%6T>B_
zKuJjn$>saS*-<~6EZ;q3R&7u!e<|_#^XFII7eSQ1bH}@jdd=Pm>FEz-J~4c)vK)pG
z_w|-jQ^Uh&*64dxLTk21;^F0W6PuXW^5b5B(+9{*Wp_FW4DHYnzw>ibKb!W(z9tdn
z#=yWpF1U6?jS1)B?(TKu)+At5<U{@EnR5#ZVlQ4ikd0&O-#IVQZ;+Cc>)V-%Vb<jH
zJ?Fayi3jz;qemZIHb#GDN=CAnrU`qEzU;1g*%4A(UoX?EX7T{{Ljbm`@%izt^XB+R
zm~NGNXUl6MCrh~gZ{J$ZH1fk>m!Je}&NL+*AG at b|tPsO)z1<o{%w;iFLf+imOxzO|
z9=;68{`l-nm*%;qrY4hG9>AiHZy>V-Oz*(F|NfD2usxfGMana`vhuve_X0*q!^amN
zA5SzjH3i?uHEi*1Jlkrht*a}y9%C~bOqEwsQi|nNOcM$J`l9T&LH*3k%n&C&@o&uA
zZ=Y at e_1E_O1qa8A)@v_czSR0+GqFg(^u)@_Dz?dGtXQ{8*S at J^9Z~3Ux|Un{>1bF{
z^pRN~(H89T?cVBTS`Lm6A^6OD5Yk#%Li5KaeQIb%n$7~`Fo)UNm1d7^#y`M6j{7U}
zue*XrUT`?fwO&8{`=|G8yJawzRkuPuD_tiCvRI84H3~PnG=!k=KT82Mux%t?b)w#d
zSu&C$+o=8BNTFur7u!h at 3PEx%GfZ*;=LZnj at 32T$v_|t)b6@#P<H2ijnlW*Hc!Zp)
z0>c)Omh-(k`T6;JO`b8oe_IF%3+Kb$eYZ6`l`P;AvYP5O at Y(U?_!ue^F|s<13&V6<
zjpQlM-SHwd-_yx7^@OSy6&>y9=2l}d(e_9hif)@_ihv8o+pjNnP1Y9|;ok=W0>3^l
zV{{>T$N4G+nB&}B^EbLx9*nwQSgyHk&s1B~wK*bFIA1YTq at U?eZ-x#mp)jZy;9Y~-
zO~9(j$A*04T+{G`M!;bv|GH68jGVBru%naHLmr;d1=BlSG|2mZf)%QD{X>F9^0>@>
zLLem~idGf^Pl)cHUn(T?U4H`Qq*%olUX&&wqzjo#l2xRn&>;M?p&V&28b;+yDMFQL
zV+;%kK&Jb`nC<0dTH~CBNB at k%8GuY7ovLL*$iY7sD_B`E<tnDdnlRZQySuivWMQw^
z+FCy8oHnz6eF5%nXJ<E3YB+1<;_m5*Lr7>|y%%VVq*@&W0K-5et5#Vk7b51@*Fyjd
z=$y2bBd42>+*(oOMvR=Qib|1AkOLVqMJsgu>V5fyc6ek&t#FizEC?C&s&yXwbi8&`
z>9B7#iY5O&{(Le~U$U|p9)B?t_zb%(KOi7r?$00jY?+uM9Yw%G5+QiyR^)At|2zv{
zS5D*xWF9~)6iA at zz!Y?kG6#U0Mk(@+g8<uXIzM1YE2k?0PfWG9vVyX;TpiIi|Lxm1
z?ECkh?yvM08)&Mi;B0Me!6kgRR~2#?-Keba#aRQ#-+o|fh(SYLFu2>}dVSk3&x_C!
zWqJAg$A`ZUJ(H^BC`G*A=jP at jHtt7!<&U;p_o+P~);l3M2-cB&7+ at J?Ur6b%Ec>+`
z)ynU#Na;0!;)j*GFu2ai$)uhbX5FTe2DfdMFE-kRV-LyR?uRGL{JQq^aBhe&N-A()
zs_}YmP}_Vi)n()8&++1ik`X^DOl6ZsT()O~W#ZUuqw51MoJveQZ7Gu7pZe^g&4<0b
z*ES#P;Fdf3aXh;{=-#ABBOU}wSTcP=>J at LY$4$%%%^ZhU-EMR4ytPf*8&aD+fUjzu
z*P>`tGtgJ1a(D?^vj?jq#Ly;x(u-M$x?>l((6~P2<0E=))}N@|#MWe>2uWE)L`0)h
zmhX0#Voo_K)g~5j<86Ocw%dbeJ^%=p+H9L|56TCS3Hh+fQ=iv<hK7+bm`S}rtBGx%
zh)ghn<N#abHfFbuBy|AK0((KihCjU8cv0vPWX5YzavjDIDRK`9#Wtysq`R(W^BW{T
zo58QEAi_zfs>|{fX1Y9jZI;W)oAH$5w?O`+{h1Tn%aOjS#nH|FliC{dLSvF9v*(Rw
z>j$YJMt=qVykyAxE at +vyEzITlkdiL%XxfKbjS{Wn#@9l^$7I*-`vWppD at 56A2K(-d
z4%)2Y&i~RY&itWfVnPGBvPPS;>D4j at l(Jr@;dgm?3 at ZaEy|DUgh(f}P(?jEhZ^1UR
z&E!o6_R(5_wtRM+KJK at -C<k|!L$bfNBziV(h!1pZihR6SOpdT-*L10<<M#UMR(ATd
za`(Zx4=zsBoG)2&Gp3VokXh!7Ikj3R!wrl6;T7_jxmA0XxnN~kM42R&%khqpvp|YG
z9p&|apdi&!gC;V=$cPBDZ}0Cvwj2sT2F4d#-5K9A+jp46$mW95=iojRGE+dlJi(e;
zX^UI0ot<1#gR1Orm|qU?OV30EmN6^kV~S71e0klQTk5Fd4E)n~@$8U-2ve!}M&lW$
zv*ld`v%doBnBCVB?D!V+*gvn$e0NHHbtH at 51hmZia=1^Jwcqf<#lsVyu6MEhqPE<Z
zz{O8D3}t>80NuO0<UJ?*tBeMX?(fFD{%&>$pyMJN6lifETe0 at VKYGT~@8%GZB)3i3
zyZ_<;t_|d!M%}eRIa7T4-Q#`uP4>Z}t~IR49?UYOb85w}=IYiXFJ2Gyzvy2oy283B
z$eXl&Q)X3TRlG7bYDs{l>2(x||I4J_epcjHm8EgzX<K{y+IYEf?CP^;&(?->?}ZYw
z=RmT4{i~gqg=KSBCGqrdL$yfjk<J$zX$J?6XYVkLHpk1)k6Ny(wa?r3$ZC>!A8`&o
z3)8R2_Z)X)+Su at -VEt)5iT3NU3cAy5cXDK*E`FmavqI9z3lW;!CkTwPz09KE$Cb^0
zUTE=7elv at U+Pm~?Bc`RN$0Z}{;~Eq)jy_#jSg7?pw2F<jl##)J7HwsJP&5|?MMF!w
zd%i!Ynj=T7Q)Tfql0w*Gw1^nMiTU5niEEI7D=dCeyKYT&L-w%6X(_wgC7<)I at o2hO
zg~FS%IDeqz&e*Zu<TaPx-CD`+#~1FFHe~1ZSf>haPTSMP at 3~kXkTmit$~Shi?A^s%
z%jx_Uk=)O}g}SR$kt?t at I43ll)4fZ??eh##ZG);8{BEp8IoeyO{%J>C`Ye5cpb))d
zFo$VILCx=drRICiK8E4;iR*1x<DP256lXY}m{QMnbG{GW$`a17Vi`U5__U5P7^b{R
zvs^Y2%b2#hP`pmI7}@-BHcNhL$mPbB(TV%B{M{4J*?|>Uoo^i-6D$eu0s_*<HY}(3
z7H@^n%El at +dAhvAQoSmVii#R<^x$IEsd}-u)O`*!6h<x>3;oXS-%0yQ?~_+gXh)!F
z<TPr#rJ`bj$}72CJKcCP(j0vHav+(8@>~1venGZ&ZU~9r+p7PPL9X072UYdIC#2M8
z+1<JF|1+Fn)L%8$*ejOCQ|6s3;5JjcX?*FD6jJJH`a5dy1n++?gADbvdi`{5a*HI!
z<Z!*)rx(3 at l7)vRP;A#?_g1u}Pk`lxNzW=HhTYZW#Xl4R`qNnFgWt+BF-#K0I at O#)
zqJEd&IdTbm$M*N`-MdRJ at M-y#10y4&_tCUlkxq5U<;B at etFassZmTleNuGMwKUNpK
zR4fCIx;ZB%WQ#&%C1$Tl{)nP5=3BB3{fhaT%W^B|nfJ at i#VE=PExG?MJ!L(6E6!%{
zm^Nvq5o`T2oWfFCggvJ-dZv$CsXR<z^%SGFK_Oh#GfurcA}#JPS(!_nnsw#+Y`8{T
zWcVzamwB7&;rwLdYOrbV_^bWB0G*kf7^8^6*u23^cjaRTj^s;X3Ol8=wKnvEvBf9x
zI<e8w{@$r?1>YDkSJ~xVUOFb9PPz+LwkB?mmj3}jnw#cJqVIcU{%E+|xXT at Q5UvqI
zN=iiw3x+?FHGb#G4Gmsj#?-kDlp3|l!xjmIz5bd&`=k+~qm{HzKP*|?{mq2Wo$imv
zBA>-6x`gcwwcdvfi&h?m6IsvGT5 at z^Q<CyamOe|Qzv4&iP4Qs$#Hz9W>YJ|nL-H&$
z(Q10BbmH94iBB(Ob^dNU#?DOy2usX{7=H&<R*ydg4$-O=I&|u;AF at hvy4t2TVKBSq
zcR9_x`N^I~D=iV4msRGHC?k+l`;QKj;M&ap8GE*<<lkO^?XM%W>$~gSJG)AGhU7xR
zBjy5GTsD_CLTd9VCE_wG*g=!Y<p7xfp}*e!X|-G$ut1oD`n3*kpkOX8M4f3`xx4f2
zujCslmo}eTy&F5fxCnm#{`=PB`D at 7{38$xd=qw*B<?|i)luu25F(fTg2-|7CKFp5k
z$@_*$j9d9rw+Z3nI$hDZYG7B|9L7pj>K^va?JdT{$iyzXOWLQ;v7d=99G|!ZjqYin
z(^W1=7<u~*FOK${UKF at 3NQ?eXY^S&uZY5S(zkab=l~n+PWvK0qV|O}SS5KlHhE_-+
zMIeSYfsU4Txvpv%dSB;1zhY4DQE>R4AG1`x5&l=#IB#RLo$T9(r?%nL{kMv}DGQI!
z`MJCm`i{IH+dfU!LGj2x;t!_p%q;*#r>xw~iP{HEMT1ytx3;hHVi(BJRHrl2>n~&f
zC`C#hvK)h6Mv-}nsPt?0W^`~-uKc`+GnC5f+99%r%Eo_C#$B4!GS0<(lqcayKU%fl
z at 3{Gs=%gIYVdFCeDFth|r}NRV{cBQwxh<yO$PGH%?8EPxtJ4l`9{|nIP+W;qOSQ_W
zm6iFOmD6MUkOTv;d^0{r`pxH at 8}YJgYM<nJ)(A)E4_H;DNH;JAiaVw6r6 at 1v7L%IF
z-3a$V5b6K0<W}(Hn?AN&=_k45*6hEnUqMb?VwzU_V3Ds_Irya|Yu!QdaEGq?k-f2@
zdydi9nN0p&BK-cY#9e3prQO7Vsn|Q}Y;kT06OZUVkMq at 9EaFqTQQCT0aO4HV6=?S6
z9Na$CI~B*^cS8^y?Bk&j;^BS6RTTQT`o%Z4!fo52KrLS^oP^js0@|dVo%wbf+;vDO
zme8vL?}KC-<<dliCoA6i`&;~~%2!_?7}aEm$}bQ7YvfPDH5DyS$euUariwLWwnGvr
z+w$%9NLE%UB`dmDB|TX(R?X;>p_MB1hi at xNRtH-7?pvM=R0&&$<3?iqVyYGw%3(P9
zea2j4$~$JCr17_M&9||r-*nK#n&HI4;Ct&`V*2aL&Pk8If7uOweD?QG<(m6iv(Fi{
z(fYBg`g(e3n3yJOL)pZsvrrUL1l{Q9=-y3KnsZqWW!dxspJxJ)<ly(ub|%L=8_am!
zBQ1#}ytlYDPTk2KCryV at xE;P*X{6kaeYk#Emt(acFYAY3T}v$)KHo%48CxkmqYXP2
z*Q%9pIeM3 at iC&N%JczR!-!|?kMDX#;Gc~iXb#m at K@_%|PjYDTk-o*#y#2ANkM%G`t
zQD_Pie=*5K&sUfS1Psj9FO~!#JpKLsUrkwB0&gIf#1rmyG@>N~AiBxxh>ndd0w^R-
z;9Mbt9~|?%XnozaIuQTpt?Qp(^BWsUwi9ia_#q}3meQ}x-&=L#v)<^h)Q&Yv4lohA
zTj9D((jX%&Tv2L0Oofn0j=PfOz27}PEm&);6UyGgg0J}0#XftBed at JgjhT<I$o-sR
zj;8a$=XsR3H0|4ZDGRG>>a?3s32b<pM3B1B#0c+J>xf}Ld+CD^LiHnl)+8LuyJUP%
z0G=p{UR24i3%YI+9c at kbelf+c;@SF<@oa6jMHFgLR!$C*hird`<s=`~;QHq!0F{Y|
zOpGpN3kVjMx|0v5pRJZlV|h%>ynXjGsz#Mo5*j;c8h5e1PYV-2CVa at ETawec=0ms2
zo<pcp_^1P%DnAJhr;_O8gpewpdTC;!3+B!W=JB>?HRIEl6{l1~mW?t2IaX_>u^)ds
z7aUGI1n4vnU)HRLL at EY2jm_oC?~F`Z9pz3E#FwdM3(0wpxCnYsVV+|CO;t1g7ToQ?
zsB)+SkGxLMOk+4*u<pC&ib#5~5nKLnqQy at XuvRYcdp!Bur7f3j(5JzRrT*Ai%S}V_
zJ)Q@@-vE0^ubA4m3uFrCC~zpPZ*FRrzYOf32`Y;adz3^tg!8#vkaOQXU-{8JZo$JR
z at uz|p*;7c7F>1dAcW3^Fi)`srEbh+Jt~XQ0ubcwM8VcDr)tYpYCdLB{C}cZ~L- at Dz
z*e^cpbDRpg$Zn^xf5pV*wY$dsMK1%dkz3Zb|7dXANyPO9D$#D^noBmX<p(QtMcoWK
z7uJc?3&#?IOMZc@%2Q<=Z-R9!d9P*z?ulBeN^(Khoz2R at Uq#KVx?g_OIj!pP2K`ub
zX3?+zbWimB15hnU at O1kwnN%Q#W#|aj?VFIHO+cJT7V?OKOO_JT1C1FTvkt%3v0A*5
z`Cs~-YUtmq{SYhZ+J^j+3A$>;jjQ(AT-HC|d%tg4LL%;&<sS{pP4Dse+MKZS6I<Qw
zJ}-l+O1RtQUv#;$R)OKT$@Y#84(rFx))_hx6kDLuza?Rsr%1XZds)2x<yOkwW- at fi
zmAsT}P&uc6cL<H#i(XAE2<KF|FiAKK(;0aynj;oOKhiRm97~4pijIzc3k79&%4u*S
zs~L!lzuU8ls{<1(c>{ni1A$4ZaM{p^pb(aUaLv~&rLdj+lI^j-qE at 8!@sV*S1U0JI
zvuCs)1<+Hze(?C*@|JJv#>@S>JB{R%o_GS0n%4J9*;J*)(4t4;uemgX5|%XH>>~(M
zy9C6xc5J>@`$~TjIws~4P-<!=dUa1$b8>QCK^^>@nYjz(GT=I%hOL4!a at 4IA7lgpI
zP>wBq!J<MM6(hQon^)U<PhgX!!{+Ca&bmg*W0UT<*omT$bq&-SAg<cY$}yn9<Sq3g
z2K7)@kGfB%kWF=ECGpFa8d`K6VQT0fC{rnb634UH-hOR`uEt|NkkCdY%|R~WOm%da
z(oXjUc|f?t%=I*1;xw<^dm|%rJq&H#ct>LbH<H|U=B@)XVFr1VC!ZZC$Cj&0-KhNU
zF^ga1dinoyU+Fn3Wkw~|?gs|OX}%Zxj=+^MZ at K(Au{lv0w6wH at 87EkYr214dpJOG0
z-gNZ!^N&|kv6d4GN?ABG%Z+ta!h39mU(#{gKKC5m8p8pt5f}Nkz89x-;f9GXA!9cl
zFNE?m7!<&8Cpi&yZ)$8pm~LGYc~%|KYUa8*ZdAED1d0rR2?=1QZQ- at _pnbe<C4a*W
zw^W2Rpps$oevivAED8v1^UzZ8=o;3W^^-uS6u0QxC`QEZ%IU&<vstwY2#!C$r!uzO
zJSbObpqUB=;%d#^axfK1$xYpVWJC%K#Pxy*f0>(mA_{2cYHoCRrJ(upR2p~Pg_jdM
z*&E&d7!ne)09${kgL$uGH=0qvVu#DUdPo49%BJv_C?c|3%mgYI&&Gm&i?1*R1;xoP
zF(ov5shrock1S46KiL(!(1?vcKP;c))!$&SSqG{bxzi%ZiygAhY>Et9QrYzDl^We0
zlSb&tlALH%m2f|%j_c%^afgU~&qg~QL}{^qvP!0FwK4{m?(XcAN%tNA`)o5^9|NUQ
z2e=k8;C=j0KU<bPp+zjbqP;zD(&HKsE1A)=p(FV at IGmJs5BACY+M4BIJ;;E8p`mx0
zJiA5GsQr?e6G(_#oJr0xO$G4k4R_jtYh#r*^3%pu^89G%=;<q=*|>4 at rme~>gguf7
zF)+}mcg=7R7!aJDgt1|&)?`V&NB2Jt{qTzL0EixX at c}(yL`CVsVa5p8`nH%IOf_(C
zJLmfZ^`~BJC59~nslr}b)mAZx4V-~?k7!FziN=h!P#sCC0FIx?_XFY^_Ju~N^+bg!
z9=k!Z-84qmbD}oR<jN#Xw0SiiyD2FsPPQszFd~n&>^KIUsyz91+<~V^_OL|1(fwmt
z8AnoBT&k#FD)1%1R6i*kqfHJ)a*+CyWkxq?Wj>_?s)HwVN6~&_H=HpeeTKG*bd4H~
z@!0+nk7Lu{fl2n%2V|S;cXe4oSjxch51EZmNjV4;Z#&dMii6VzIVLMqGhRF at zf2ZX
zm}STWIzd#AzxbTFE-WtEa#p$ma8WBYNP&Ll*SZV(>ceg|t!a=P5*``f7QH-vsI07f
zB9Lp+9aUvB5p@&wt`@(5(I9dJ!#VOm{D!D+JR-tmF>FqLa})LR at LG{hoPz?etLi?W
z<2|;YNk+$|+ZolhS8i~%h0sn|^#Hn#2=g|y3S9s;iYW8S1aH56GwXLXO(*;EFBJ4_
z**GGOCv2+>a>${`1LK?Kd&&sk$;zTpQBeVr$$V$->xsY>lt4Ou{sc_}k3e_`^y$T9
z<z at 6xCYE4}@l4qGe)UHIq4r0Wr7Ci6qiIx)xX+HZ2RWHlO2?dli}DT+`eKE^aC39J
z)_i$to$7b#0hD(UPGOm7p=N34*jOB$e4<u$Dx{$bD+H5)*B|b}(TB-kw>9F1Q4W0J
z&L3XetA67S43e~h#u-CyPEG|(EO6f)(EYPez>Ta&i!xw&G)m1oLhxzm==LK0&fAgm
z49vThJgB9N%Aaqsu~}aAO-)a)!K^e#S%TWeDR&zrEh-_QWXPXVcM#p=BHr<L2-$#^
ztO0o%84&+ at 6S(mNL`=06;)Ysi733opy;=^#RWA<@0Bv`6_^4WT+U_9JBIps?^cF^h
zNEIB~dH022`XZgdj!?ph1~+!7K$TX)Z6_ceXdvoctU=TUN&hzF#0M-aVbS!8D`)4h
z?AMgCW$;1z`90mhizra9)TnJ!C^BeDj5G9|SnpNyJzb**Y84rtMLLlVz5*ax{18A>
zc6a{$<2p?AB~T^a<Sj40-T=j`(`&n_3m&4?<jFlhKR?9j@)9Y(fP_OP;QSsboEN78
zId3&u)SdqHEo5W%B8^A}GEf4NPJy3V8!aaN`t|E$nBpg^GfiG`Aa8Mk5}YHSWR{H<
zI7+9G{2fB9*88MFT{j1G%jN7i18N~5GEq^{Lc~K1km1@^5_#<vAQZHly*=Ixrf`|x
zHSP>UCTpZDjPVn_7*T4Nwl&?r<#Xy>I69oKN*{v9*ajJ(Sm!@RqTB4v|MoT(H495o
zE9(tlq(N$D(64_Cx^uZofEY7~5|3?veF8Bt)pMP(5aF~n#Sfd%yplXNU_TmNs%- at n
zs?gHXQfd8aHa51tWd3MC0p-3Ip3LI(RaHRB6=)R8z)fMPU=i~Tn(F0weh>z}g(!4_
zN_ at Uyc=d9=El{t;x2bhibia=alZ@{JRO*i(KD-D-3)Ijk(d(9FZ!$rY4*>#!S^Wkg
zTVP>fA!7Z0AS9fOU`<1xm{-d^fH*Lt2d>r&OW#LCd^xR6EK8Z2dohsAZ+w`7Tn%wO
zJu;*v#7g+H0|+jUVadJ<Za20AUTd9haJ%E}8^ff23^ZlGd74k>a&KHQc1Bq>gctCL
z<b`ZO*SUj>VJiT*`B`xIzD*)3|3 at FF$__3r%OKG4uARf6l_9!7yniwOJ)k%{E2|8s
zG~ke5BG_gC)nG$D`~5SsSR;rb*@UO`$4HiRG*TrdWH-oi-(5fvxdO>L7gR8iJkNIR
zq}z6FepLmxwmyMuZjInhgF&uBCv;MuQ-X~GsnlW}r0S6(?dV9+%XnaM64jp9*iFOB
z)A8}~wdb6+IbxDLeh&$@61vkugyTvdF$s^&cL=lJ6P3Bh>5KN>N0SH1He$@sF9pbs
z5MURgdyZF<?9s5W`j2j(wlxcRAAgwjJ!73E4Ch6Fmb|mSAMKLehI9<|HyzD*A?pqV
zbCR<!M3MWS>M{4Li=*K1 at M;I=wqH;OB|rxPe at X>n9R_9w#Q>?c4tY@(iCwCr_k#@0
z_3|59^ZA}E4lb at d)8b;JDBYt+%6~Uqo&c{*2Z|}Itafn(Y^wR?Wz)maQieu&bOQ&V
zYe0b~vsahqLnru5YA--JfCf7Sv{Y>#J|k|>8q6U*X~@5FbaXu5X}<?<n?z8bwTmf~
zYavOvW<Xccc)DIF2W$$Y=I9<GP)d=0nYZ^u%3$z1u`JqR!8o+g99QX(g9(LRL?l%?
z^SO5MU8L=x;gRElIQ7Ga+7%|j(yN4wDgp48Q4lq{E*g1d$q+WfrG}z~)kM+J(I=-H
zr5+cDV~mE)jq2;zH%u(U%D6yKGKU%q#;4o7yu8spzlXB#)Y#9i0CT`O at hu_{oE)`|
z#!#gtpbIQg>6)r at B8Cxy$s!Xx6dL)@kS3ZkF0j}v?Jf5fX_dDvaYE{N4h5&>^0W};
zA#Us!$W!o^5<uL6%n9NoND1c0JM*B1A*6fN##6xH;RO6BcsMLy_3j;x8Ja^?1WjZS
zP|Q49U>)$pV9a5HoMJSTC9RRa=y!ES3H6=^5<650?d-c$VPIg`9QYQDi+=B(d4D1|
zUED4dHXKsY-kMoo>#yGfvWs+UA_U#Gc3 at -bWP3Lm3_=tUJ+}A&FdY|^b=Q2 at Q~`m3
zNLN_2ZZ1&u^BbitEAYB%1!~=G_c5H1{1&xD$PVl>-RyIiVlImx50JRE$@8#CB?x;B
zxtwbtfIkMy5&U|%#@;Zx$NhMR3hZPDe<tG~c(nP%j0#$=E|Xx`<;Y^_K93R_S30)g
z0aYXq<Zq~fmF_2?kJftx>RXMMQNeO at LfLp;I+mpN9E>yxLLQu==Q}rH0V*8=+SDK-
za=lOXG$tRqK_LOKIb>yA4%h4CwAlp)2L8-beu#`9prYlO9&&TXKrL26TDVH|U}`0v
zt{r;9(sTggJ%Pf&Vt`zp>({Rfoh(Izd24)O`OZgNNbn_~UcU#gP6Bu35lm<%GCNE+
z#6h2|%O|Fc-MJC_E--L at d)t0@&+lZJ5Lx4ineln(yVb_4!RUol&@UmS?IO$e(klVi
zO)1ENfFdMwhqXE220mwhm*Hj_b$o6h17BWVLZN#@>39AUIRH{(E_~Pi!NJJuH*a%z
z?3n<3kz-qh-M%{a^(|oP8ULTb{<SU}1W41^!{=dTGN4fnu0nY at KbyV!B6A|P^c<#R
zOF~>6`RW8LS}#Ts5=fKI?qU}@7FNgf^tAu|kn?yRTM|gJ%g|yG%t}3^qPh+x4!J_j
zXIp}yv8>|0QV^|8;5g!dl?MX<rR&B4Ak)4y(ODS6Ip-x&MQ4PX(@NhwAjcsl{6xs_
zWNqMu`3^Xz at 0WcIBqF4*P%c#{VSHTc&U5;`3a=x(wzf7R5%1cL-U#S$DhEZ3p;<dV
zKGtgVrrLW3anN4&4c`>piLzj0a0iPQgg}MqO+0=Qju+SB*bTuI_<h0DZ|5s&Uy5KH
z^in;stk%1Gf#2_eF(_y^?dm)T8F3(-C+Ix~gOdAp(^0&Lj{xZNWiOnm>46q3(r*}L
zB3x|-n*yMwm$1oTZ|1<3BI^NBbmEIGDO4#sMQRx-sdR%TPv?!%aNrtr_{2U=0O0Kb
zFAT_DOz?ziiwR^xfsBVtD4=d2r|l_B8{a4CXgbG>Q<qA*`}nLnpBPnhcEFe7xIV%N
z)4(Y!FK>Ezeu7CUGPMx=7)&Ba*~evFO*%`=2{z~5)ju_}W{2wtq+LpgORaQlxY5I@
zK)sO8TCvyyNeiwG2mQ-L#-ig2b|6T*t5D<Uwj*c*vcI=HnRfsf1Ew2H*g9{!O>1jw
zcfe7$KWX1m4oDM5Fq8zK1#VR7PCZ?2jGDw_y8zoiR-9?mAIx^o5;=@+h+ds at 5whu}
z1Bj=K8_t#`1eD9?F!$Pq%fe`NFfG?^x*nNhpykmi(lajguc_fB<+ZEQsuPQU<~xKQ
zbZ~jL9UT?b28wDwlR1c(w@^_lUv^;Jk)R7}zPj{60+bgo(j|H?Aag<CTP`eZuCPE}
z4Z&+9pTHSt-*OQP=rz8YWg$k>zzF(fNLbzC1b2cXBXc36gpu+Nd~U#*2J;tG*C9y!
zm3~s_M$*U`+?aNo?Pza*3yzEg^#Onu&w<O<HZG&i1m)K8>e46F-s)<%i!wSs{<|cl
zkIBzhfgEugCKI=x^W{O-11H%rWKM`vKIo}9^2ylQ*<TtPC%~2gOAA=5R6yH=hQWOP
zead8`$37BJfHz7m at o_L1fcAQrOSOv5VOQ?MP4+qn4SzKIc!kC=2hbv8qY4@&q&6yY
zb?#Kz1K3R99)-|cW~9i1;ngW2q at Fpz#pQAz0>43FOn^H>hSIBd4u(4Od2EAK;}X#C
z&f(!QRE`?01Tn1;8rAt9Aq1>FsFdEVNL&SF5Q;hgP?({+04^cNfTtEX&b>}jdxxVf
z{X3GIjayT7ZyOqrZ4|gSIDOCE*GKZ(;hKInFQ{DSAW0(iZMHP}O)yr>?>vtnlZK3Y
z0`%K8DQGevYG+p|g*`uIWo5Ap($ms9LP-nlSlfjA?jPfL0I3S at u6eM#fJw2Bi5Ge<
zw;7Kh2p32pgt7rl0UZghYgkm9?_m&>zQ<IhO at B$kNw{B*7HJ=!o>sszd8Zh{EJYjO
z5=%%(80nGCZEZpQaT$lU1-cim!YQaQ_wV2T3NA^O`#IPe0M7VOz^DhU#5Vxr*OA`1
zqdJ&8q%#x(NytvSuC5N*Q-Y7V2&a^*9&9`5B7$(q7yDVezmXq7{6Jda082iB&B6N5
zO{W{%GH7XNepFj)LX`cjH8tTNs`b4P0G95AseO7n1-j4_aFz)BmH-KN4pGl3qIs=z
zcNyLjNwt7Wwx4Yu!Z91H(%|i#*{ldCqnoID%GZdz5@?Pna7J5MtuL-BCi5xJ#b!UE
zk~*^c>fzyG#6g6#W&+8<)6fW9`%sC#;An}yEbIhU><sMDhpezLp5RLWn;LKh40d)_
zOJcdhjzC`Dh*O8Tlg^@(l9!h#9jmk)rVFJR`t%9!c_f8A6jR!d7(ow=bJ`fItj8h%
z;ttn2nS*0465L`!;F>SP2#1!q47g#W``{HZ_^Zs||Na9uK?c{VdzFoniPz={pe%QH
zDO&Lr*gI0aw)lZCr0yPhhZKK7_m>m70+3Q=@e|qO01FS^BrqZ_tgl;rWe6;zfU|xI
z9ndjDJ)8&nT}vx|bpE~f>A|ofCB4erZYME7r!hWGsy%Q(IS8m1YAizugf`Y-LrGi&
zu$qWM)^mvLWIji+%=ZBdL{PdJV;EK6foaDiewukRuBF8<mQ5d8NRr1E>B{0_cwsEz
z_r)x>;5J}^B}q{@a%UC;PaUwSOz7%-w~*e_$72QR%rJ$|K&SyC<SyVHBt-@#q8+f`
zKL?GGU;96D{Fv=78=2(#GY%R!)KJD<GxS;k4lI0+fiA6Oi!$i9x`Ugb5L(~}s*WU0
zRl3ugmo9MBSE(8G(>4klg^nbx`0a|HO=Y4-f1iGHe?L*`LeoZppMMQ;g at U+5XOlpl
zH~_nL8GZ1WI!?IWjqjqeA5j%Wcg_fU+{VB{21_S+-wRvJ;B}T1943y)`9&0?=E9k#
zVgb|r!(ikUpD^aZE;yXX)WJLPRm|aVL;y!w3UJ at A`X+QSPk$=)4XJ=kW<oT1-<v6g
zqaWXkNu5drxKgD0N8f}1>#c3NKj4?{g7^6Y7_WakU%$!s0}Y4GnmpKn=Q?x7OGB_m
z1%^Sr;bHTk3s%$Wnkct=dymQnP6CuQ9p7<S)`c$&FzqtwU5afmh*JTxGd`0&_#_Q(
z*_NPxLZI>zSWrA_AdYOaMPBD+1JjnQzy9pRjm`!Rmz5O@>QZsTgo+zEI5myle=mmQ
zvx>dWsv at 4?5j;BkXv-K_4A#3Z_- at ZP(8P^C;uQY%B51n}(=sX3oau7wGsj0i`?lxE
zpQA#(?&uEDTamwEpn;$N&n!N$djET;)*;+2C1!8x)4QD6`VDl2CnmT~B{uO>9{sg(
zk;@!op|tjO at l@>K at Jexggr~NYQZ;xqbF(<}ewzTiL#}%H<6}+LNVk;lC$-b`6 at JOX
zj(<p#D3h?;>R?tBihXch(o~}w$?q6xrmG}OMK&B=Q!wb$%E1;Rf)G$Bp3c-*LY{<9
zJ3JK5c)_B_iTJk{faA#v<~&U-v4LkcdVl}J^kmQ|hK6*A@^Kr-*%VOxP3bv3O;vK4
z{c^v`G7D#=IhvnRvxdn%u3Di8z6d-QUp3S6*D*=q|DhX*Zjp>X$!Y4|LWYT=%T(G|
zj}}GM#Ya}B?+UCZ?$+X9mHOR8p!!Sl<{jf4oQb;xt<tdF&tXwJB=Di=IeJsF-QM~3
zBvc<way7^0nwXaE8J)xY^HG|U2NV%$nymc->Q8c22T5^rmG!8}gmWosWaH$z2H)2C
znG|pTPtPGwhUri98oyX(JKpEG<%5c4Wg at h?<@5VEbzO#6M($mUKf-oX_9WC0O%l$B
z&mV*tCkM4tQ8E5GxyXG$%Uvv?)4&O?jX8(+ihb^SuR=VNefN|Ta5y-zFHdm>*!_>g
z9c=lFQj2gj4usvIRo!hw$WF6^xOU9a`v2;MxjQPSA$sHGqFUR4&4^r#RH#R*TPBrN
zOo7+7oO^+YcY}c6?w$GX0F{$d%efQcF;NGzTo5E(Plpv5tZ>tHj8F$#E9E&UG<!)4
z)TIRf?%RweX|Uz$q!yEky`3+R at LFPdT$uDI^*Q(a5-s8eIfBcWIH(=rL9xYAWPLfC
zo4=c-*^IZDhJr7XEqwHnR7&Q}^|Ut7xE()A&XSpzwuR`g?<Tv=A=oTetL at NqbDuV4
zIQ-GLoDIT`kOJJec5?azAt}w#o~W|8lzGryrOeYM>^W6(Z9|qhMmd;R?d8B`@yxnN
zgPr!G6MKzjcR$WvNSB3sO<3?q-XiY02qUfW%k#z8iCFr*r0<*uJPmd~b2PWCIo_FP
zfS1MybiH1ni-;$RR+;-j%%Dzo!+SWQR|uVvk(Twuq(-~_i}B7r9p8U*t~aLszdhG0
zEv<O^M)vOX&weKhlsofs$Y-J~YMKAzviKcFB5FI$V2oq2dB-4iy><x?v1~;q+TW<%
z-m+5g=OWf7=)Ls>J==Fa1#7j>S~{|9J{!)v8t(Dw3;$)jV2yGUe&-yyElRTAZ(FCd
z{K_MaF(4BR#~3Kagn!y^ahuiBC$SkQ6_ at 6cWcAN+Q^ffOW93Op8<wg?&TgWknzt8o
zf2bnH)J51Tbxj#_Dv0YebJ-5+EPl)M|02VBKax?#v*2thc3Q8+_QW%=j28}}V4z%C
zSxs at Qmyj^~2;EKWw|fqMksvDKpv!b?;XjYvb`MMx)^&}fze`-I;<`m(_a^qTV6rC5
z{3~u6?ZTtLa@}LCfL}Y*4J9*kdZWV_^DM}@!7^rc{<o`O!&G>H553!+%;e7kw`+{2
zr-|WM&a;A0KK83PJL;(N1~-SUDgr}aZKhQJ^%<FI!`kaDcKxTG-qdosM*j>I&dg*O
z+34GeWYL{g?J4Rmd`#Uv=?{9alHtj=FK1wkGvkgXa-rVuATOnY`-+bBwMg_n;qaYe
zMEt^9Z<$4?=axJ!9R>3K1)B2x0=M0rZlAj~{aT`Wq<w+C_L!n%rb=O2Y#bPd&p$Zm
z#24QkCUnV$hj`>o<aaI(8TR!5?%-kKC&dJHJx}0T2ueY9vZ|l at Vxe$qk02edrh8L^
zXL5n2H5cjGim!qz3w|WyO5;s=t3t;WIN$mQHB{tY at vJiXVOqt_D27|$nHGDPPVk8}
z;jf!Q_v3x*iDGt_pI=wl=R`~M`nRX2)y8b1e}P?#?_BuPevhHve|J)~n&+ at a@r8d8
z7k=RDffpP^dm?gZcliI&m7Tn({^NA%D>z;1DuP2Ww7}ucJtlymj0W8fS~&4h3Hhix
zPCj;o44kFR_*g3*-=eIa)7Q^!I}N%P^4MKlC-wGg#g?$areRboPix#r>^5(x>ObCx
z-Yrm9)6_X}C>#9==O2+u7U at 1Hut&IJeD at Mw)BHdD^%pqb!50vOUiN~^MgTK|aOARd
z%TB4-|JU>F>L=AG>1B-y+xejpe!L{lThd(~i;dF*m}{s({;iRBV7lf`@S9ajs-2Bg
zCH*#dLY^4z|3-Cwz^6EqRqt2h&3Xl^rXuXX1i&o%NoS~GiTOMZr5e{~e2D8G2d(2j
z%~jQuoWQ at a&-=B4{72utO9cD&t3d3wC at 8lL_}&`T&#`X*p28fJdxz7(NwKIYF>P=s
zK)pfTT3u^&)KW+CLBIuU#LZFEeJXyG0*%)(l&11o35T}kNwopk)LckjXsr#)g&Y5M
zIs4Q6g`BvUf}k|scBgHzIzl*anKwjv>hrmzCLub<K5w at b{$$6dI?-OBz+fgRIK_?4
za>IX;VD1dlxtn2r+QRB+DC{D=x1#Slj!$&%p);Y5+WOu8RZHHN{B1_0(dM;AW`-KO
zx?#9qYvtmLQJq at yq{C#GJ1z54SueX?jl-#CNtf{R=NGn(C-*Al8rMW~oyJ}qJLmCB
zb?C3gBoE at Yjlve)9Ew=9j5M?{_T-0}d?Z<Rq1CxsI{PlBVdT%S5r?DFfa#`ie)G3Q
z+~L%-Gdk}Yh5lE<2ZltaG3#au?7tr$B;R7by6N-E{a%A&Yni2$Sj^9AT`RG{UrlAU
ziS=~(v@@zNIjbm9gW9=7{AhKiT~l6XuFl2n^7|3wlzsDiE1aQyMf&?NHe40W3CU+=
zmocx;^x|42lwUu;>Q^ybuq#==bGDuRp$t7 at Fpxqq-<Xb7iR+!y-t3`LC5}xz26(`h
zWRA`7YU}eRzOl}z1aD8r%^wWzIJ~VVa;vOQ=WT5e%{$xdJJHwI^IDd~J|msF(htYd
zEKJu4_7NS3x9Im!Y&p-z$<IYS-%)h=GxDt;3iD=4zUQ@`xSrWnf!gR_IOQ(S4v!)i
zM`k-G6HsC=>~}8gm9mA3&WN^(HC^<yl3TO_%TNIBu at N_r_If55bk<py{r*W&YZ#%%
znpS{6!u>31<lSM~lU#bl1|{3~x at 3%OwF-2bY#hUEPNv-hKaC~|R}{JyjN#eWrwH{5
zD+59TzjT8Zy!<FTS3T#lT`uk!-67TRJ1yh4dHgb>T)uH1yCj*;sQ#945nb?b&kT}L
zfD`Ml_+#)|h_h$j(rT}_JpD;scF6quBFsboQcMdZq4}yyzVuE`=9o8E8!3k_aaZ=+
zGwqoLTNjZn^jvixZb{YN601cI at M<N%d#XnB08gUvMbjG;mKF_=soo1)RWn#2(%x5l
z3fVTLQzKN${WVb3)Sie-;C#4wy$*xw$%7{kOrrSxSYD+CnEd7NQe4^hOcmnV)UMo5
zN#RH<sva{~<fKBQ+vK_W?I)`0dz&?JbjsImHsoT8zj<X*STO#<?PH^wD<4A<yi=F_
zx+XXJ;}Z_2t7&}v$>PSGzs3E3>TTy(cMTQGP&UjR+NFMvtQ;U1U&gelk>xLUQ><MV
z#r?l}JMVa^|M&lskewr=h)75>GAkpZWLEYL*_-T at JsJohaw>Zr2^q&8Ee=IGIQBTQ
z=Si}D*LlDD{PVm0e*b+x-#@GKdcI!IbzRr<`M6(KRtt-}$&IZcW*XX`kcx5`HMQG;
zs}**Xhd7;Q-7YaF`q>FMzM&BomYvX`dklxT)-Bf(tj(;XCI{)QINMLvI6C)_n|N6_
zGp3iN)IWM(Y0te%<3s3D>v-gvpT at W-a__z6e;a%vs{vnS)-{at8^Jd?&;A<d?EJnT
ztVNJXAIng1Np=d=G8&CZ&~vWbc+qFvTA-aVx$x3|Z7ZnOk>WuuOMqr{!GVLY3U&Uy
zecCSv?u;ISQAIL+Zx5Ka$5GZ+YGz-?UWJZW1hTu`>SXsb+PyuTY_V%?<1JnGAh>J*
z`@LMfQ at MDXD@x(uh_GzG>7PyXVe}%W!*8cTb(uX{<#0ty!KdG=Pv1Z27(q&M(Vuqt
zEgz7*G>RIv5~f+7>!M?Btavx(E>LzbeuWcf?;7Y^JjhatO-VVH(;Kd!5t*mmwqe)3
z@%YeGfA at BYg0R78LQH$_HD0z8`BR1oBlbOc%iZGbNjIMkjD{T8;gfB?n0h|-uk6K0
zr`6~hEJU0vf3e$mMX9E0V!+(OEtG!9#L0F1E!o&!$A}0zD0k^#-cQqxP-<xD=tLGh
zz%<qE;?iC at xh8&`iUNk=$B^9Qd?qGy{ielrB)jFW=7~_>bSk-z@!ff>p`lzob<7_Q
zD;B8bM{(_h4E(`Xb6bvE`s4>D^M0NBDbnBW)&4;raub_nTOvQFk7qgwC2)vatO~_^
z+fLVusDEGLM|W>oQZwX;Yf#@(XgmF8BlV*RG-mCQLWcK~(K`ortl0d(K(E~ocg1y0
zgP*(qJDwNL#N~_z71cG&;O)8v<!TfR0&z|;nN9*10#~Fq8*H2=n-5%@iUZduc7G7|
z35NZdO&hH*63$6SNw3E64cJms{&}%M-}XiX^Dd-%r~iAry8VLnlxqL9X(MBRM)BZS
z&h^eVI<3Q#u}33dEw2{SOxW4At8=ASyH<ug4CYthXt0jYD3u^s$y7RF=A at oTt8X-J
zg&Ao}EmHQMbsFe4<qyEkx|`qlX`z!r^QZOV^u#1~GI>>_x8B=pGk~kMwKP)K>{a>v
zEE?mDTt$h_srb%hc%?2Iw<eCcZ`Q^$KUr8T<$UYTC%eN^`Z+A(rX%Xt%oZ|CRkSv!
zX_#;MQ5J>8OLFp(WmKDw-N6^y at +J=vQ?J*f0}@tt!Q>c<VY4V at l9%GljEohkmV!Jy
zR!MET%E}!)QAM$_u_`Yx7px*AMF!2nVvi;V<O6`fa$W<Z523s1 at v*UnxuXA{=csky
z>hRHt|LOx&Vriq~s=OZa7qyhGH#;DVSMq%f&Lnm8cdt<MDhX(utC||dnT07+8=UCK
zC3f>zR8gdUKN32l9RGV|LhCJ>I_@~N4pkXT&JyYxkIJKO at I0fkrQqw-uQV?XzOM-K
zBB~lcKx^U9+SZj3M_=;3K}q)eP0C8dUtxby*!w&m)l<!x4d3El7FObU+@`D4%S=9M
zm*b>0Tcz4a`Yf9GVz#KF!JM6YKm7{e$JR{Pll5|zzRZX)Q+Z^soi8Kebx>ZSH~CDX
zwePt;w%W|L7LhYz?JH`$M~dtOe|e}VBC!&8luI8u9@#%AI>U?;(C9Q at QD$4Cs%q?k
zUzv91zZieb!a8IYrz{F at 5)tg#y4~wXVhY_kJDIz4kL~w4iK{sHB_wYa$*52A4L+b;
zGP&=2Zt8wTk^6^;uPbSP?z4Fug)Q74cJA%s<-u+F6wXTYDUbLLT6<~o;n70vGl-ja
z(&H;rPqe+Bb(dg||MgIMd?lVY<;@iLm6KC}*ESXLeXNX>f0sov-T(4RQEfcI!ZK_Y
z9%~KDGuND`8GCqCjM~J?JcH%DU<23 at F~{F0jeAN}7}+~li9VL(uJ>#F<E-b9>F0U9
z+qbWQrXLp<M^x2;s_I*Lrp%!tr;|i7gU5Rk1`LuD6R!mY$xeSvAPU?*Y2L%mgKtTZ
zy&wO at vZ6<4V`ZMg2BFh6HvUpKm)!;QfmsN>7?f3b{Fs)=&f%8d*R at Rq&ZZiqU$UXj
z%gd`Bb^UwYyezEVA@*II+2IvjM!y3%Krq=O{?Q{4_uM{x`SPyfUH=^D#2=^ENsdE(
z2auYbQK}tAu)FBCfGzm(XAr<0CBs`kK`}z at CB#fkS&ap*%E|AoUC%5*c+k^r#!Gx9
zV*CC1bmz{U(|dnYMFr3bdLWzZbZiQMetik5oXJkJnJ_EdgX7VwO-?E8!#s3(*+r^k
z)xem2<P4-u>rw&93o at 2TK)J}dL*a1e4kJk5M_Z=X6Q4i-03sZ*8VNZ$xs(C_6zxJr
z{84*Qm>+XoepZ62k2i6xivp2#eC3(eBLG&`TPeA|f}~^~w5~!d>>xcJWbJFj^Yo1<
zGu2lBjei0$_!raiNn=8U?&8L4r=MPhk|p+A*dOr{k<tDtM|7nai^S-ce?Zx_mmuIL
zW at bA1p8wkhj0hl}ui;YLCk=6Fetw<=xRcL#HRUW7OF_gdGqle);!jSkXlQDl<K_mx
zd-qA3F7Gu^Yn~Qzn~SD(5EXi;Fo83RkIfO#P&ty4nW^sRSUhSIX&M8Wiz2CvjMs at x
z!R at -r_np2=kYZ$z9<MuHfhJ+RI*Z4 at 15klTb-B6<1Fex;P>`IF@%gP~du)91{wfBZ
z60`sM>bU+Qt%HL@(BAq- at Anm+rYdboAvx!GmO&0 at cWX$3N!tV+%4^Jj&SSBx<`Uo;
zAjf>*I#{EGnh`yqIGQcW1HjCcgj_T-=#^mmsK+a`qs&7rlriblpZ~-S=<FsKoA1Lb
zkfFZ?qGy+HzozsKfT at nMW03tlexba<^NPB6E+|`HDSty-7B+!zpO&b~-0junQPbCF
zF);NYC#pvYa=+L>m6=UA4YE{L7Kf*&=UPBxR`9Q(+4dCQ5s#ax`>+Q+AuTd?DdRcj
z9%^s?a`kB}D7Zk2w1Xbsh5O+R9fXjNCmOqG(-ui3`{!rQV>YojU##Vk2}C?9J6kIt
zAYez-7PcCoJA#nLMCH~<(D&bk{Kq4SAh6W4P8_#MMnT#E$#+>4>>^@47Z6LofrQ)F
z-+%JT1N+qA?>>Lu^8ttp$m=`{%mZqD5cWzB<je2Livaa<*$XcU09k{%$h`nl63t90
zxnT0Ex}c^#j2A5nF;!Pr&rk at JhnWT*Cg;cg at 2e=DNi|DB#%Z_EU3Spg?4B%J1QQ_a
z3snFDvy at OrMnU_EDENm3&U|7d0rE#%yMmqtYR7=G>z}T#fZ|Mu0bnXIE$t&PV~ZmO
zglRzp>O?+*5z5`%fPrQ;byrMXzWJ16vVIYD7SdI~gf#X9Ll)!vJxzsYf%*3W3U+pO
zsyVTMNMQplQWHv4YwxD3DG$E0p at 9Wm<`F#Y7P83>6O%6K!~(KYxfd7YxIuLw%EDv)
zs!JJ4D(OFbOxfRTcra5LQ0v4U<JZbM!^fBZ<vj at S#2gdh#;v>gS}y~>1b2M+;5pSn
z)v{$j>M9NEw;<2FKwV9ZM?qnH)x)Lm3oJBK2XfxHW1vLp$wzpBQ5<>DujwbtDU4pa
z1Vv5^^Y%faoBx(W33V1+cixYTm;!1+LM)^K%`p<<#8M?8F&PXhRt6PT81#3>lmHn4
z;P9NZbQ+M2#FRy-*g*moQ|-ww=`p{v0AyJ~qV+6Jztpfb!!DaDy-QIx`_uj^6Fa*)
zaIsIOPsRT8aVjh5Fy$0T#)d*O?XZ_xLG;%Gl*|u|xl>i9j0X=1&<Sq<+?>TdijOyh
z+Db&Gm87$?6H4{O<oi*^Lm>_*J0khi>AIf6e`bFLy~-ypo(%lKH_)*_%DkPUX_Rj6
zGi37sq}iZdzz{G1184(mNkY)Dwzj?;uqAMtQ2YF%l?O%=oA~mj*%%*m4ur`g?!9u`
zDO|e?#IgM6bF)Cdz2wlxi-HtAfcs{oX?M5g$!^=+#Sp;=fH}IL)W(;ZB0I-`{M*|e
zz~Krg<PYrpXKBt(#&F?ZIH4w=sS8_<HTX+DC+qI%L2ay()3CU2Vx+}G5B3DHTE%vb
zJsHo7LQLl{nFe#4PX9cf_CZzIqt3Kp{R2BKo9II*;Ijs4$go%q@}Bh0S;LSMH(KCI
zT}*=fpIBh5aJm)ZsVONFKIpE)vT4C2E!Z3UP;&_Cy1esSw`$tKvxDuq4l1S0YQrX*
zjQbf_DI-2O7r-*IN=t>B+fz6b_}^fY2?33g(RC3XumJRCp6cA{SOnWo1eL&5EsfMA
zgGWL at 5~s28 at OcHg56eDKE&}mJ?PURA7e6drFAxXsyvDhyx=~kPX_TRo)WSXoLBr{n
zMhVSKZG7Yf at P0?n^tD%^z?tzvd~)=f<*A`Gia6Z@@HN+x`7{NDgsRZAI3nK)sTnx4
z=vZr_y(cot4d!mCP8ZMK3JGcAV~W!ydZ%kcG2v;!D2Lq3ersny9VLboY}61aC<mk$
z+X>zU^Ttb(#E}mcEj;`PK|@6l;-;goKujl at MaG@F1?;f$ty^&rDy07N7AV(XD$Ghu
zU_+-Q;_AHkAF>p(7D0H4cnAeuh$yV9D{3?^as<c+5-9x=fk};(i6Ocwm*FZRwc(S-
z=!vUw<G*~lE~wB%8KMGGb$G$2?0GN~)nh1CN#fV3c=lESaz*@F0pg#l9r~leHVm5G
z_~bHLulFDK2US%BkdK+p2g!3SV#|r#rcWBrzfX8W`Xc1f-T3~e0RZF)(0K3Pzd!gN
z at Aw_C12uK^p{8Ioe5{6#j}!^Gxav9tqaCsTKOc+tklX_vP09dq#mLAAh%Chtt~lKs
z7}48cbRl6fzEBj?)1zOm+ra>54{|VQkPZKF<&qLH9?5}{HpFk2frAANz`5%B`p>}=
zD=R9J!gtPPdG%DFPcVLjR~aTIB at vm0CE>HYU?UV^DBAuu33Uhffi&UKS26}b7!ZUU
zpn8e@`?uBYRfZM_iCj=KTf2a-v0b_!`!|5>2nYAo4-;^ME8o044T1_WzqNa4bw&?f
z_*50B@!+(ToCrZ)C!nl#Kz1(+t8^s6Ot3(<OZm5LjWmGfjEzsp1#G>A&%6n%&@cr)
z6Nm?Jp+0Gz!$L;yB9qSE940P4h+u^lAaM?`42UsXSMF*(YHL#h#_pD_ZT at Iptju%h
z&>JGz0CWvtlFP!gRZz9(BpCC1074QwWC+9bXv9?-$Q-E)`lWBtDg8tqIm;iP0YpO2
z%3Wm+by#6Xp^kw=m1RBD3lOfGL7=;idq_kTsUD~0lud_7^jTV(o$q<Y)YQ~Y=s$Bl
zPr)mgu5j4=)1GxiL}4`V=m1O(_yub4fmOt=>A++w0ucjUwSREE5vFzu#*$A^&5fDI
z``h91q%%-cOf~1lw_WhY5bCM{w+%1hc}m=k&!Fi_02v`H?y at -8V1?~y=X>ipAaTgZ
z$fHm)&W8BQIf$^5+-o3!B}R at wJ70$gYKQ-`?AF)oQU<md$R0j<)kg at t3~?y at h(iI;
zVjBdg?&#5!loXPQbw9wosxhhL!eEJe6%Ml?{OpH8X$yz2QV6nl5U^FsF5UXLNB~;Y
z%33eXsQ$rupi=KcbOUg(sPmvGS{*?}LyU4;X+#>XL9)tvK;!Qq`G;?5`hhRX_?*l?
z?Snpl at nYw)k2uszBGO2*oQ-<1--)M+Gr*0^4%s2g-d!At_7B}gkCWcMdpEpyu6>cP
zF<@X(;XbL9d4b789%ds^BTI&uc{br$M`AxvoQh!{urN30q@?F4tdN7_#nO^9yC8x}
z1a|eAKLDPq0q*L79tE$DGt+7$M(=?Cox(Mmi<s3vsCdnjv_>>zZvf&a0wu;!yld<_
z9VNI<NIj*i!I?E(ghnAGar{P+6!5k5NYWYf!JoyU2LH-Y8;QaF?QtS$BGRyS1Y(i<
zwzeB^V1mQZJzocynT=FUxf4mRz|t4>bulG<(ERsCp(o>i>armCXr at eNIUBuD*#2t!
zq}#-xzQAQiUp)l%9nM$>GOA#1f3~Xn6IMFQD76leV8_QYI`bZb at -#jNC*yr^W=~|o
zy2#2zB7_+fm9)_%j73V8f<2Y1W`llLIdE2R9#%%#+lMke$RN$e!`b-=9JFr*nGgOp
z8QjSlO;we#_oUbgWkviMG>eOc%bvDO2B(kL5ALEbB)LzyQU}i|m8dVFlzFn+be9Y~
zPc+GoYltEo1Pmmyb~vlpEPc-*S|2z(9_%upUgQ%{J?GwJ^{F25^gizIxqUI_WMWMV
zTsn;S)7)F0t#?*)2J^VffuqI2VVv4Q=;`dw?OV<{d?TXjBqa2?#Q!4z{@uCZwA!Nu
z=S!1!+ at C!Bw*7s~cANC4TxXS2 at VU|<)6E?e<8e9a4f+AIzD%TkmG6^>Se9KkgQckE
zCQ4S#7^!J)+p3+h{rt88hF0}MF>lEmf%Li@$cURusQec$+Sexe&?Sk-a+wo5IAio%
znxdZjR-R>u9w)zye&s at AxN&rAWv02T=IGeo(GYReul>fRneXFXtBOo3<9OZCrq#rq
zFMnDiJrn5PPUZzPpP-8F;~D&OZ0ko at +E=iGaz2gs{8<&2#1!kj8LHe|!m9!U55Xvl
z$`#kCJ2CW=#Y`%cyfSK_8f!DYg2DDkD4t at cYi>Nk_xNFtOAF;vcf{c+>1tW{MdRAf
zoOOo}S1MbQ;a&rw2w`<V6QZlJPZO<?xY8Zb<6=3V?0y3`j6<f8THJ4sC-4Pb-F4Xg
zQQ+Q2gSBbHA<0789xSsM{wb?FoRX+@^&9vY=zGZ`je+iWUYuUu$9spAU-6DG)5qR;
zLEASgU;Bl&Xj?SX^)$C1bqF{WBvrC<hCJ4 at RgyKlm(ne0sabRA_$nczdbPmW9y=Re
z(&Og0jNqY68-m*>xDSdPOY$aFAfPd#OIqUhacCx?Oq*!G#hg;s%h+E3Z_9y`o6h1K
zL6guxyNQ)+u)GXgTZyQA*QNHZ)8$cv- at fkMW%Fd0MYn9_U%*u}$g*ZoDW&pT>lqjx
z#Ry9-vjiJ$Rw(p at nJ06v*nM4~X7grf*v>l)9x`*IyGeF<nu!W%Z>4e>kyiy}W5-y>
zY;0$Ktx_XpZQ9D4C?3RQpFR^<auQYMymFT*5o>yE<;sD9ZuZCnY-syB6I}om9e%TQ
zxi=&GcS8auvV_T8KtSU9j~aOz))C7CGrltB#~k-on)ei!ce9&m=~<N=Y1o4GJAdu9
zi*D7dO>hjpC5w- at 3?&V!Jtf at 4%6S-5xj<O#Xws25P9+Q at V?Mu5p<vT5%qE6u_=X%H
zlMg`{Q?7+^V_$N#y)<#5n!swCAJM at c7iqcN*u71ezR8$tMu%0f3NS5^*55LXm`$n^
z-L*(OPPwi9kRa0bP37$(m#AGm)tl7uc1&f7yxYdl<Z`FDy2l at pX$lfGOgHuS$)@s$
zY-P~5g!Xn=KJD{!1Tx4YUCa+lcY2Dk<$cx#_Gb{La8XEO;?w>*xxKjekmXq>#e3wt
z*JJ)%ndT?bUr#TU+48NmtavMo&xY3=+AEQF(@xZ>YbGp~W^y}l?Co(gvFR_%9TT5>
zvAf9?c{2Hx!Ohr&D4&a(g?n>ivFqul-p}gG`i>m8|MuOqxYFGQ6YMrl!&NS}&Hto$
zu*svKu9ULdqiOb%>aFlvHkld*p%BOw(OF>jpoS5P+Nz2tY1|_fKP!FQ43}{RiauCm
z$(HFO<8G$rRfo^^wxAg at -CeQorYdqiVoE1kYuX+gkd;()U+tPSWZaWDeS>amJm1Yu
zJZO2d^<6bH&N^puI5|`%h451_aQ6CUmRCSV%Y{n!yrGaACQKm%=Q>(Pt2Lfg=a at 4V
ze9aR>u+-<ajRbOUqT-`Yow~GB_-^r%X0OKzq8}%iIcl<hDXqTN)cx~iJWY4^l!$ct
zwT$hGlf^+3%uGTyE~gf7$uv7bnbv$iuc^4zFXdzlhT?Sy%xQcH;mr-!e00ll_5tZO
z_ at D>xFh7fXcS6v0`wsOPq|4eajlNfj13=I?=S;gqzp6kTrzyzdJjm4YEZBg7EP;K@
znBq~hn4+JL_Rr at melE)<?WuDao8erCp|SEib_<)U6ivN*$?AlipxbvHo795wU2`R;
zG;Vu6UwXKb=n;K6!NlLFqxW5R{2fgzOhw_++UGb$Z_TCR5vCe6^!#?Zn&HVlN|qjp
zxk;(z at NS0!bGMrM6kfJ<9j}lT>E3h~!s)591g~A)ZmInclZjo2;f at jWs~ka(wD-No
z36k4)ek2FZD=_1}*mj$Xop`~oyPLg^e~(hQ8&W!pu>7ZQFu5;56$n3xm&N^Y5#4YV
zXDsCY(&p7KEG{lFD3{H`- at 6(x61JLS!Rod9`9+Hzl{TAYz~>>8$;BslV@!<}%5K8#
zQ`J(?OwHx|oAbR3PkM?BI?jW6e13yoRQ!gutgX~a;XHF?@Z$74FU?h!Gn)lp`7Zla
zpO&FrEx)wA>q{4;kj5YxD!L?3B5uLp%vF}z-Wk!opC(^et6ynNO}kwwqhf at +h`u1q
zTD)Y)D7&8T^><a4J)&%F*wt8dBi#5sv^uFOCnBQZY=sKlx){xHYK<{{Q$hT~j_ew>
z(9RDb$IzdJMh%u-uA3Fkb0b!KUmw<0@!obQn;1*J{+gjj3|kqJ?b4Q4IM{7({+?we
zkm^#1(QXJIvLR*WN#2^mqwf7%Io-U)3jq%vmI#Y(hwfKp98dB66x2Msc&}p=&r$i$
zR>9y?-}>y__FLY at KMCv%s8s6RP0-)E5>Ynj)YKbK at UD6Et3{_->Uy94h;QQ#*<_qF
zraEJQHB&$b%R^yJk&*4|+C(LtMib(3XL%WUSXMW-g~qsdAu$FvH5OFb*mv#`rwQ>g
zVFCGwUnovn`POq^Yy#w`R}_M~_RPFVOMi>Y$_|;T4^>8FoS62=T)fx2K-wQdzj)wU
zW?=kbHe5k7svH?pWZm6{Sg)|PbxPB%e7cs?EHPd##aVNi)d;^wyE!sk<xFAG9j%}t
zF)s4K+S~-MJu%MEx^+eVap%(jm8_Q8O+DmWVb2#XyG%19*1pVr>5}tDt}hr$TJU~?
zJLdnl&huZ^Yq*#=$+5 at Sg0+`je7GKt>1d#T7__~>ye{b#KAWF`-Ca6 at zQE|gk}ygh
z8<}(3Uvy9S(-66fNy{_-SHAq{5(Fc<&`z-Ln!-}p=BlXTaFb-vpOkQ2-agPr`baW;
zGC1dZWPgsZJeQ}ktExr|GFD{5`I=A_k~yCQ&VNhdxAXIGU1eH`rsaZaPDYPX1=6Q;
zkJ?mrA9pj8?+SOaQ~Kz{?IR)4d?I?pmTxs{?N4Y=M)M`6AbhZMK&wu6WDhoT&KKPp
ziU!AgD5tj`d>0joR5&{B#t;(BGlhg>gO(-XMy>so8LsF9v&o!~ue~>ial1jFNP{oZ
zt3j@{#S`$0gmY`HNQh?+gM*&igl`$%>3rYU_hMN;grWHbIe8Q_ZiBwn1ldMu(HgIS
zl|`~Y{-c~L2zLkzZynO=ICu|5vxx5S9Yh*__fb^EkutTRM at mB(p9+VY9X`C=&s~;E
z)tYICZAzFsa2dXsPD(jWI&L+%VT|#qJS0E=S at clx_qygM3zEZtuic`;0+Hy$xvlT~
zJbEyWcVl1=uP7XvsJa^a?lw|d;!V9m4<bYz?{!+QSBQG>?(v?c*gJ(6j>^z^rIYz$
zH||kbXTol1={tRl<&L->*}=x^{4{?|``R}wKIAcfEg?=-56(y5x#h}uu8D+_yk99o
z?_cf0d|lG+FQL%03BKC?aK*OPd&v0E#g)yd`FQ4~;ZW_%oBa4+k*q$;G%&DtQ(+pt
ze?Fu3T8-*P3$i#CI&FNb$<!LdKb+(78lSuBuRahOVWjdIawHcGEXtoA)YLfAuLua7
zk7}E4E!S2qhD+?36BIr%Ah~z&*|tVc`eqn49?Wow)yN~M-aWf3K*$h5mOI{7T&}d$
zdA49+V%lAV(>-|JTKw<Bxt!5kVNv3i-K&_~+-`@p&pMJZhM7`gHCXzXx<lqaSF}6l
z32~7Zh;uX_9%Ad`;#_6aVmUMFKH)wfwO^l()Bf?WhIdOcJHCIBiFoOnM8S5sr91q|
zdU_Pc4b7PAH!pBD2NhD`Mk(*%7vHBET`0iv6R(AN=pL+}N%!UQ8?jZ4LGE)t<q%H*
zUmjR4z0H+HhE+I%v}>PK5)hQC3`;AE+BFY<Y!Th$^UuQ%df*BwjUfsf;?`#08BqJ%
zT>RE~d6pIQSmYv;+Y2YjIblLGLyczWmn)6(N$$C#sb3$(SEIvU)dr-`V>ClXw(uWD
z8CK<;Z3hn=1WmoTWe?qcKPWTe7^lpAFN#etmpCr0fX%Kq6Sl*$o_I3jtI-w%u2cS`
z`HTc^Q?L|0`F&aWNUFpMiXdB%ITa-m&%RFkid&)1tx*4I?MsfZB!=g4`z>Da15+xc
zs?>90j#M`xzLGPLsN!$|lVzyVd94dM^dISTR2O|A at k24e=J at CrI3Kmaxs3DTC2s$8
zqMSOtacypQ38lo72*<AeX`@X%KSF3Zlq~L~j{!F$XxhJS{Ulp<drv$;S?Rp)A|w7a
z+~ogK3q?GO!I?!xq6=j{{bu!hwhU*t6li2NKKgOZnI<$G`35}|S6N^0T=rq*Vbp+U
z9=Vb#7}3V<!%y2Zb%nMv$Xrm>XhfX5vDWRZoS9>#nI!(Ja6F8R`1w3hjO&@mTQq`^
zpwX!~5{GXvNSNzp&x^GXwhuf_`$tPr at agO9A{m`^(%+K_Yt!SeXMPsp)bFdFqBi5|
z_Y5Q6N_j}Fa(@bB|8+=7-4s1-(mDsmjVkr0e&QhOGm*$22I;#z^e}yEI-W;^I-y?$
znfz4lFl?%gaJL95ecw^u|Gp0Yf4^aaWXFe<n}-L{bHMP)^7f$`z6T5c%N at xr6)k0y
I(!KEi10HJcL;wH)

diff --git a/docs/html/images/wayland.png b/docs/html/images/wayland.png
deleted file mode 100644
index c9937928ce9584a660ee10f7092eed2033f6eab8..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 5649
zcmbVQWl$6jum_G3j_#I21j(bNB at QGcJmOG5QsQVhQo0W007a!+=|3QNgw#nRNJt&s
za5U1*<9&S}-_GprY|Zb>Z)ayV&OlF-f{c|64-bz*>$&>Ndylx+FQmlxc5$pH`Q8zF
zt7;jM-pe~uJLG-*z~i}@Hy$4GtN&GetAJm&_emBX2+RlS{?^CO+RGl#&(BZ9$qnvp
zYwck#;_l^;xu?L2hsThprLJP+pS7DEkjB`R-J`51!48lBPI~li;sIFc2@|^M4&xtd
zFaOuD?OY&6JIOPWW}JemY|3yMn=3Ix#n~K>@NfOJ+%C}S=LUgFNWDtIq#fXaU at GsE
zTf=?w{Si%LzmtK3^&5qus{!4%@o}k}-LlHd at v0De*cS+~D?L6F!P$u&cS1tRt91IC
z3wwP=5RWtK$MI33-n`s|5~t at HW0H^lH$x*u(TB{4u~UDcCSFj)&0;v3{QoO^1^&dF
zi+8fa2ZX%^nV9M`@d^FyNS~1eS_v5dby2rM#4&)#WhKDMpfkbNiqdDyDbC^b at dhVo
z+HIHxqmgG04M}9rDag=xv#4$*0;W2bD<Iw~Vu6th0lom>NSLeAQ3kQgxRHpd50X_y
za>boUG?BbWjJN at K&gem#%(iv1<AiSl&<Wo_!oDdQ5bH-E<!JrspK_fCEe`!8Lr{-0
z<C)``hx_{nLVGI7!QsW>sd2DB8Ar<GhGt)QEE)b1(ws0ZhAc`gnzyB6ZCIh<ufui1
z75)o|RpY6SYCqyy!KNw$ll2*Go~&|U25{d|n0NH^T`D=(wCWqnvG|A2J0;&*vFe2V
z!HlzWMzmwO);zCcO-CE7DT=-mj;1Z~q>j?uosqNC(l0VEG6}E{m6m?zTxa9l^a?8s
z=fUrghI9$0l)gK9IW4&U+ at f*o1ulNO>R31`B4uu9vm`dd?`w@|(E`j-5Ku00i(|vg
zsSBlN$m3(9j?~OafM105l0BU(uJ*g7FrlCr+J5R6y-XNjUU=d(nZQEU`wtS4w<{0j
z-8!x9RNQEQN)(5Q_(CPOf|BnDjCJU$K8|x;>eIJvZ~%BjB5H~;&awDi!-nLD@(#Ka
z3};gzd6+jC#TPb%gc*y-W<>^-8{s7YeEaEps)gX}9&8>82TxQ<Iaab39?riP)29BT
zZ81iA09Z7|7$kw(k>q(T8kV1S6mTv^qMrUnfO<fZJhP&uhR at Tvr<CXF>ozg=W`bd(
z1)=VcA4?ow_J~zGE8f!moeeN5D69+leQkji9$t=w<??b=wI40L^_R@%yB|3Uzk?{e
z-~%}u8B73bUD~FuZ=`?Uj+u5yQJTIA+m3_1FASwpy9aSp%^zjn=AR>|z at I-d?6pfI
zl71R8Gld6F44<%I6+ys`fYnH(6o=>j95w>yqD=$m<SQ78LPT%ZPhEgdxL>4_h0pdC
z$gnA;0=7#mr1U|%rUEQI>K4(Cj6NO_4)IG1(MubSKeIH76!0W0!*{>~y>+^UzFiiy
zo1Ze!X(c+;-Ea<U5+vnG$a5ehkPgMRI7*&31^-&~A;k7d>+7L0v?+HM#Ow!6vY7u;
zQ`}@~5Z20L|MH@&^wLrILnt at uPRy=Pp~RYdvLs4-fkwPEu(~Lt8~x*pUb5bTAAQ0l
z$$yXoI~)u6l*@X$5G?t(WwK69Z;Z37w8#_x0C^Zd7ouH1o>rwuo^ofQpxYG6H;}0K
zf=k~}9{*dwYegmPB2PIRCF2`z7BIu1gGxuBFvQb-1~F{Nbc?X-V*#4w_@=e+zdHX2
z=_PnvZWrdnPSi|>Otqa+`ZkKsf1P+K>$dt-*YWtVic00?u1kf%A8E5Oo2a2A_M#8(
z)9wVH`d2vBI<w>*D2Vm{4Fw&ihVpVfDpv+(Q$hD)S8hRXeJM$ZwFV?jG9e>Z?}}XN
z`u^;jj0x$q0gCw8ou&&s0zWmgfcvAS{kpPNzm%^HDF%uqn3HO7Vb6drKk28-$NPur
z*ga8x85OsY>1Y?8hl;mHcY0E&{_ygbiC3ki4~cIx+lqY$lilNo27~fk#Mt?d{C0D!
zF!apglk#)bwN^8Tlyk><YLJ&i!L0&U6xB!|?TsUm*^RYZO4_PPej%j^V|<*eS<O*i
zIg8Jgy~9RazW&L~aH*A}M9pfy_=OC3$z<Q>WZP=)ffYguzcvmw)2#PT{_6#gZv=r4
zT6LT9gx#BLHD}gej_rh;417-i^in^0MXHOX2jc`@*Yt8ixiIf4?RzHg%5>fKgd?x^
z;(nGCdGdOc!CBj0c;s6at1lP{M~_4F+yqX4d{Nyj^m2;L;dbDx2-a^{VqYG^-S|OX
z7>zPV4Cqm!lpq|922Ven5F5$A&Zap0ue-M`MW=qFZ6|S_Y5W(>c*dn5=BiTW3WpCk
zW+9fC58E92Rca63Pz;O?HsLdC1h at BdJa80@jlZkADx%JhJmURIZp&Irt>-j<?izwm
z9BeU$&El>;ayvf9oPc6PsS^n-KeZ*}h%<Yo3>94rOH1#BvRj?V!@JI}-<FX11tf|l
zurr6&R&XnQ{y at I=*SLA-)Rj?{sz<a%3}tIz_G)B`@IUQZNZb!&%zW4UW?)1?C=Dm=
zXf9M)Mvy5cxL at 8P=o`4R!Q0I!mEI0T<(GHq1)ts-S|zDI(i4;1LVdcm^oc*cphjTR
zy(+~SsvZYj%~(J5X%xC3-_LMn?ZWWR^J;;5gV5*Jh?QuzsQ~b)T-s^cIWRkEpAxq1
z#(#lUcJEb<qojSdD=@__8n=}aru(9WNO{FfS$dIKL;Cm$y&@(LcqPq#W4GMkF+gQK
zbE2mf;{mRL at M*<-8M62Oql)u(JydbfEmXFV&6iVg7C^@B<lXaB!m^eNr++DPm(3yC
zZJrtEa^Pgs`#3TqckG*CHs!K0V2C&5)r)B9H7AVvDtk>9i=<}SB`~&|-=X>-f;3Wu
z&3$I+qjxt4qU@|P?5kcyYRO09-_$s!>LSjQsCwuOPOz&1CS$K(%*hr~H`|CBe9vb7
ze7Mi-o(yrYf_Vu-*N|@+U_heLtD)_rS<q4)kJ^o#vguR7GNwgKC=<a{NM&AhUctIN
zt2r%8>$8FCM=6Tb-E(*;dk;(~!>m7|>96B6P{ZUNOvcl}Ao>W&HX^>bY3^w2{c!Mw
z5`Qzbuap1&Z|N4i6ZnngTAt<U{UMjO9EDrLNC>j^7I?06<+r at h$2=msigh=S&mD6}
z1*xMd%r63#C#v$g&ITuoH4xtH#e?{dDh5S-BnjoR at l%>dvDU}oAL8pi-qNYN%eHPF
z9b$S}2mwVZZ9JWP@?1c+NR76CsxX#_3+ at dbpDT=(Q9zO^pBx~5+C9MoWhlkO7-AZt
zz&uo4J3j9~#P_R#OD%}O=q5MKuunKXB#~bE3TP^*=CN at Y5G7DH{see6b!sU(&zvm(
zAmgLy-yrbq+t5 at taZ$N(KCSV;V_~4a0doQN9=mF}{7ccp$$AIQ19)-bM{^vTXvD+>
zzH`VLeHOoSG8b8EzMqr5i3rdH_hqb-wpQX-8o-x>ca*<Vz9foWMV_TGz96x!>keIW
z`O5&sahvZ at B5Yad59v1+L#Z}pI7>J}AIVd7TZ$?WM&`YQdcR+FP{}%&@tMirQa8QG
zs1(#E*BrY}w?bfA!^HT#i+hVX{0h?^JZMiI<qq|&R(Ph%_Io-|1!()~UBmb^-NzDi
zd8eJ%aK!r1u^zyNxlm3TVbiW3xnX!ffo91otB-thL|s=PV3d at +DWMCbYGyuly|7N0
zJooN|42L$GTk4gx5=Wc`uB6-Wm6hu|)u)J#&~OQx>15V-#Q&=9>)M~_rCHH$TcyX)
zkdZgzZOxyBwiv}=<5&kie$7<rX$sASKD at h~_AG|6L3c-HQ5WHNdh^)r?8%;K&%CjP
z3`>W at UG-fHG2fO6kHiK8w|7(LPd<s#wAGt7zAmdditc~UWfatM`__K8m)sH>o6D0k
zSlye8Do?@U_WRdrS5hCHgSZYz3&DFDBluA6@?03aT-BgH*N9+ZOob0)sNde|aKi8;
zJxgT}E#>|bmcI_Ud9~!rqF>&#TpVIM&PRNhloGd;Y(%*$#_9?$Gq)<l?*boDVDCUa
zV>n?G@#u{yF0R_=d)FU>ph;4$$4c(a%Lm;_a9w!ZrR?5uEuFEOLp1hMyNRucP2RAU
z<ad{qvvBzDNodk!rJmv!-CJGRq)X<=<___qybcQK50B*y*Hm9k{uhm63Tn&r0UzLu
z<PXx|kkOs49L=3n<_Rq%nZfnzMjt#PCH385PL<|gdPa?<pMOv0y=@F)&DP;thQob1
zb(`m|vML#|S5Y^9|20L`w=e;U;u|eQFB#)YRgHi8xI3s7h8o&C&Xo!aKAvTz_-2bF
z(iW#1zPjCM_4ltDa}JW_D&$`H)GwHGs_i&a6_O)gCuRI5X!tt1t^y~o8nq at HP<+i?
zb4_%%uM<jTLECCX7qZ?`r|B!MkaHs%7f02CoiGYsM**7V7zfL2S9`0zZo7m{ukATa
z3*?#GJbvOQp3s0*MCCTZlm#~)d7<fy7Y4&kQs*DTqRYN{QH^o-F{f+JZz`Z=4&Yw<
zbN-Z{epjfRbWC_ah+1A$lYO>idkralLn2H|HIFG=M2^9%!ZO~tCmixd(O>4Vsh`wK
zKYB{>^6HRu2k`dmOP_iq<img?$@e+_P|F*3Sr^D$;-F at UylQKamCAcn^6zh6j<ptA
zy?W`bXjgetLm~63HR|$Vri`2o{tOg?f(hfMJf7!;GPY*|zBw;#Y)$?y=4v!hKP9$4
z$n}p6ybxG0Qr1kQ1)02uDqHjvsYOgwMN}CZL(l*lgi4{Rx5afbsRVetYQz8#pU_G`
z9JB-4Ogh5^gnydfC2wkaFn{&+QkH_NuUM+46E@{;zLZ6f)<U*k!T8u9xEU~5ATk=j
z>ul=yXYljHoPljw?j*k$yfE{6N{+o@#f(_5K%;`zr`7Z%u)h&{`pGZhSyLQdi_BzZ
zCFA!Rz1;NbM`fAYmqx*8^wP>+P}N at O$gRJLNJ1mA9 at dcyQPCnj>%}{Yc-DZ$t>js{
zar;@4JPL+1S4Xj}^7rA=L!7F-+%%G|?InMofM~p=(yRF{ZGU`0I`zjS`2^8$W=Z<e
zN!1mX<shWS-J?aF|B$iAVtLQn6LaNd{``5PK13nw>@><qv++iBoU{e6eqF`}jej}7
z$xyW^wKuc$7IPNgGc%Rvy%{O7WWI7yVj1Sw%aMr{i|@R4kazA{o&`T}epp56#B=H2
zPD+*gHKnP9W*ZPSHLR>DthDNE#`)W5l>2S-1BhST+GR-fk^SF4*lnw2SFe7pRV?TD
z=0kBYk~?bLM~dzIhg<fh7e8SZoWxCBF;$$@oMC*s#}3RTVjW4AudYOZIpixL1%f^F
z!FKAwz<;1q%|Bk>k2#})jVG3LJ|AvGmk5$ucM$Yum*i+V)b4d at m;Nw~OZ<DvhFCR0
z4fEl<8}gX&9OUiyPlTr7sMsDg)Y5UF4Y=mYTgoA%woKZ3F?n$37G}?-{8)vjR2nB*
z&!ktkJI)c$Yp0iL8!TknsnL7E7nI1<*G^sKzif at 4jvVs73uw|-cq79~{qyTXKIhJ|
zUqkaHV#_3_;%@0>SQfghG at q&<p}6~1-)C*J%s$mV_gAXO0TDdg7SmFq9p@$byf|<M
z`1MD``dp~Axmah9sNc4^BFNRi0XnAnDsx|jLY3<E>OI3hV_d`ELz`Y=BM=44KfSD~
z&II$i={J3bYXH8t at B@GPxLL;W4#sitRw&^Fp+Mp|5icvqyW4T at +kzV$ak1~noAR2F
z?zZm^EBjf>f9Im;v2$ll7z7zya|1p3l0}CG3ZRXm#kuHqeI?z((6ws{j4hjlj1Yu}
zdT>W15*_|fjh(vb$%JFZ6x37AFh8K_70EziBJ24vL3Ya~N#WT7L)%r<H9M&^3;%ZN
zcJ#b#pZfi2b(O(ME{4W8?B|@*N!g%5r)B at z_KFTEejF3C$q)^7#2qqSXG*~r#;4x9
z5sJjk`{`fr<9K{$Kb!w{RofN`rL_6y!$C at WjLjS*{*KgQD2MI at 6(&K%<=J~k>s~-R
z0~!5i&o16v3&92=*Z&iraUd%E9h<b*>fqDL$eA?n;N-K at g5X&k(q6D6%FPl!wfU!3
zXd`6xX3~JZXKPH>?lr2RO`DL(*#9_`<bX-O$f*{`UFHG~J(zW)MqhZNHyaK&x at 3P%
z5egya-|!yqd}R7wMiYcRm)MzT24pgp4cW)k(t~Nrp|?vT4zMYrtTnrt6V-)@SQ<E$
zDlF8y>gr8Q(h%*aqxcWwXW6ae+?8WGf&2S6YSk!mA_h#ly3m5JHtNcZfCf%}->=t-
z7PP)8^-`SvZQ5~oru9vu-LJHTwH4URW-JTNMKbh8Kd&mmqk(gHkcB8-v&sA->1p3v
zkbD0Y at jx_oub{irTeoF}sbFOzmjlx$&d4Kr{GLob_eaVB9I at pRv#T6_Qj8Ui77C)x
zIIcwbe*2Gr)qD@}$BX~PKLJB)fU1FT<erB*5fWyPaSFQ|H$?1r#P)RbIB;ep&EC<v
zH0eRP89c;U>UQa}74E7c7%-daLaz8m!2Y>KF7{CzVD>%sgG}00kY4zmn5%&o+2W_a
zox#3xTh<-2A#+fnMf^odP)N7;V3epca1 at 585M61{uK24VlQJ3&zaWs#+LrkNm-67H
z(HX7K0L}3UggGUs39TJ8@)(F(jjgr+Fgwdxc<d)tos49NsQr=`1R(;W*cTr!iUhu<
zKk#r;zaFBZ9pPFR%GqO*ig8N7zXgazr|vc5&FXe;#Uz(2KDmc|3Rr4meW#o?-(#{!
z3^G~VWi%#rf6nv%Jhm8+3YfFX-)B@(yH*};dToHCkdopY1&19`yRosJZfyBZ0M78L
z{AFXKwf1SHI7fuuL{po2l`nGU6ZsRtX6ev>6Xyl*A$mzfh%2ALN>nY|M5Bo+)P+ui
zKOh<YF0+LmhZwGiq5fggksQGr1k(y%d9ma|n(8V6nMj6qZBfN2?k$j&a2~bl0AG<|
z0`)nem4E?|-;K~shu4PaMtTuoWj4H7z4r)cIHcK7_dKZW!j7!nR&nI}gk%h;6ZJrW
ze^Ua_k$5XbNsPN*Q&E=kHD%Sh%!hsa#~~Juf73e5#(<Q^&HuO~egDtPuv0i5w*WH3
z at LRn*-bX)U9_;EudV2D&ELE#35;Z*kmxaJcj4bFAGJ+I#Z%M>#dA^$oR1wfbX?E#^
z#cN_$NN2pRO}g{}ZAQI3-GDIYYGNx=>~!TEcKt{VwlcPa!G5*v;jVb*j_)fHKK^VV
zM~>hro1yI<aSWb#X7gtP9vZ4`PIXt at gSU$c|2$Z1);9?se)3qnqiXSiS>)1LJiLG3
O;%Pzj)GJl3BK`-1qQLwB

diff --git a/docs/html/images/x-architecture.png b/docs/html/images/x-architecture.png
deleted file mode 100644
index b727914481933b2850608da2db5210e0d5a50df6..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 32329
zcmZs at by!vH)-?_)h?FQGpa`N80 at 6rG2qH)$-AHXxx?3p$1qnem-5s)(ZbZ6EI;2Co
z>zn($zw`UvKfdc+=X#z;wrj6-uX)cg<{0B9NI_150QW8~1_lO!<ZCfS3=B*Z{J#?i
z8~#KuRy-2^fo&iyA%<~@{$FxU7W~Nr3`sE&WtaH%NmmaUlhc;%9+`s&26*4^y!u#h
zpktns5l#0&Q7goJKP6gdEUTd4{7J5gKyH-zkY;%EOO+cUS{BTtziO?61aF7$pIz`q
z;NFOB<BN@*cdOHNjqTh?$di>T<U6eB at x%{KWx%2FBPwO8H(kN?BNF`>AAz9rBWhff
z<Rliw(cevvy+Pww?AqT6Kl>wKh7iS}u}tLRgun8vM at XWm)|)6*wK0M1qcEOi88 at T!
zTQ!XMb|0-r45P%sPS?`XGV*S_y_WUSx<|v0VQ?VYsPZ}p<)Gpk_>$cw=h`dXfC$fI
z1s!R%#}04V*3wtv)@C|eh}^{jBg8V-LtY%SE9f(m>oDtl?iDo`(Ef%=W+Jk4Us^5F
zn<W3n*DR53wWm5ky>dQgUF);2c!gxnNuDq_9b;`FuQ&5+RNf9JE_+tLJ-fB_A%m%{
zF4!?(6|X)gKZEHOpNS}E$S9t-bKtKv{*lLtJs70)FES*fS;W5m?YHFR#*R{!R(lvP
zkaD1DV_~`?CDv_Z&zGllProjViz6?kzM{>>E<FS9Rwh6D6}iv|am3Txg$<b0<uz^n
zUq4d1d2xn3$Cl7lYdQ3Htk}~l=N;%*`M6%mc9o^)rvvGn<dd5-#lpYD)!`1W_E;e#
z%VrhmU)RP+FW^KbP+c$cDuWNXTD|k(q}Hg!4gVT-y5-FCy4GSv$}cu?va>r>jouSy
zEhD`?X!grVFMMNu`tPRgLnG6^F+qWwCiL)^^fUA0G$!7Z?|8CAKkU5YeTT)vc!g0+
zmBl0HB86mlbEk}B!ZfYK3PFbOi8$*dqZYyoz2DGFct_Zz^rE$5byvW>VdHc$3fK0g
zz7<aO$&IMZt1Jl(1@~NT2F#*n>vKBwM*dB&y7v&UZ?MPN+0v!cX;$KHrw at vib1hZK
zN4{&5Vra85i_XX+LbO)LW(fJ+>$&`#uXE$~zN&Rt!p#wsI)+h;{<kXC8bNOolBY&)
zDI(sY8D4A#ES7(+##q%iiIrbsgzETg4vU;Sr}U8Q^4M7P&3W#JHKr2KRWlqDPDC4;
zs4fi$SQdPGG#(+;IToEd((1=^FUpm(>L>enq|om}-_?a#E9UB$w(GsuZ)^>#B{TFE
z-FL7?xP{{l`(7G-ti at Z9s?VRbv1I>M7+9`1JAYf97yGVSpo)I+5zoN%Bl(ZG#SU0=
zl6 at 8>=gOne`C at kX6H}HejDA5JdU5P at 0^^u+gvF-JKPWT2=I~C4&os|=k0kJBJ5{!r
zaqXu#YwEWmSLt8BdVjD_V|ts!!+<-B(Ri?kCPBZ8aGx0A<loI!Lzn01os_{uBp=*%
z(IZw$%XFKVu(=BT0zY&fcHU-*BkAwF7vQXBUB at GFZghhpQ0&g9fQJbDpfi(Ok7-|y
z-X>z3UHQBzc~LOa6`ENmpSacgBPp&GtK{h at -DtF>++r7VvtO8Dn9O~AQmI_SbHk;)
z>)!?f#ISz^7Rt)9{#)n95lo(<n!Jij#wPgJwZy*nBn)T&NaR>(X7CoSvoGS&(8yy1
zyF}(cHg0DXa_vt6WhNK9ZeditYxW;K=JErLQ&uf5_;bC49WqZm$6`j}dXB>+gSrm9
z%UWqmo*F+GkLZ=|X2IP3_JL)U{&y&K4(fZiu2P_w6q)ZRJO+l}{gb6q>yZ4UEV5Vc
z`=%S#lRq8O(=`<uu8!<H-8yx!vF{QvbbgF~ifur38t3$v>Y8QX^kGBcrRZnelXD)N
z at kir|ixeeKgG~DN=Hl<)eQ|lPy7A6C at 6t;cdjby`6LVnJ(M8G_-R|m{d1BySxlL-L
zdb68aE1&9d-45Q_8BNraLaVn;CMF5&&v68TU(7r%ue|%uFS~_Nid2QC-8L+teWd6<
zLrU+2*16X#`TpsTqQAnc$9hcpL6*``=aK>;i)zRVk6z(2t>F)9_u`TqnZ(b_vbE$G
zIpp_rzLkj9+~>U^bT7S|%id8 at nC8&>=Dn=<X at dEGaLH0RdY<T#J9WRgIq!Z)<&ylk
zRKX-1({d_le=E3kT8MhD=iO+uk=E^=Ojpjh%AKTf at B8ls!!_$({!_0ao+D1yCEZuD
zLzvfM?C0gaWOz<!auHv~FB;S+KRtawyFdNQsN7B|GU62#ERpzsR%rbjMSZmI)_KwD
z29mWte3xzBf|re&vePBYAWZ1hRA^sr<NEU>Q!GE<tcDBHeW$Un)BP+Mheuy$3XN?e
zEcSO|r}e7Y{!q}+l2Wyn1kc?lc`7JdO1sUB+=!j@#_*-?DtF6E<F}ky%(e0h^KRsN
zHO6Y)d6hS&BSx`m*OVhNHT#~V6k|H$YD}up#L<JbSpt)mr8>0(*8QhDS4X2cdcx5Q
zif~6jof=LWOV at Wg59QS9)e>xWet6O`WUnfdU^cI`lr-Mp-AL|Tkn3418rI#gGJvh>
z5%0dq<Yy@@`b{oU5Y=_6Kb!Wm=g#NzCCcbBJ%81oL-Lw0YgL7VVpHu_yni><-SBg_
z)l`lX{K=GaY4!YC+mnjJS`6%$|7w$psY;%jNtb4vJ!<J<UhMmVlPx_X;N>&&Rw3&b
z|MT3XaF43ty)#zqycQgmX`jR-k#+mwOZ>B|ULM`Ke at AD>MRjzS$KLG^*jO>n<X_w~
zJUK3H3}`D&7aWb=38Umeu}|mZS;ZXs6ivIHZ08#5&tdEzv<MpsZaic9Ts at dmhV6Tj
zGvr?ER@)XNz1o<!eZyuI_iXDP7exw7s++X0?}Tx16TNkI8T~oFwFjm*)tfMr$B!G1
z*H-iM<h}hgU)o)Gh2?3go;xq7^1AXJ3U}dle0e8XN~>Q>d7txCQ2V_3y5sA|d7OvB
z%Qx!$8d5k{%P*~!WZjcyCkLNYG%aO!jDAAK?AxFIc;Ap9)6vtOWu2X*Ym%?p<E`<X
zdv|Hn%;UpL*k$yaTagOydW8?wnCR)<7gb80=0L43a-6Cy>BjRr-CT9?Iz7=49+ at Ka
zI(l*bYO?%hG}6}5Ke1qTg5%pR>+&Ck^B+s|$t>qeX&)-XskD=+-aa$AHQY&#&*sUn
zen}YMq$<2n!T&ylSb4`UX036M#%AyOyD3)LCi7x1+#jxzHM(El{6631`p+KWGf{}5
zr~iHBR?P#=!q3K$W9{=sc_ptd+{PY<B`R3_1RxqE`*NHZE3)e^B4)+*N2Bt}_G4&~
zk!KUoCWYDE at t9}m?7D>_e|q^DkGA#vq8qK!s=T6~+8Gxs{Z*UgrD@|&B)U`EeSOzP
zSE2gT0jp6gmIw7vs6xxXH^7}qTJ1ria{5pB$l{lzxURP9*b43_dAibUWxfCWs3Z)2
zlxgRB3s=xkDyLXVgL;8^Uz{bH#xDQuyM1Z(7*SS{24r-h=(k4uWcVnewKDcAHGy1W
zg?eynI9V3laQN5u9n^P<P}-D<*V1Y<onIU|QB2pqX3ZNsX|!yv5 at G)wZB8`Cbiqin
z1~4V&q#R3ws(3eulF!_tyhbHxmvvj8DvM)gKLJ*wN6GX3CkOSah?-<&Vf4lJ;yJGp
z%+!!f++C96ZsZat%f5e2E(7?L3sqK$f{EZC(qaeNhn)VaFZZc2HNH2i3SM$Kr{N81
z;8_tQo+^ijtm6rvRB)BRhpKRgl!QH6*`gh7Ev`9wV^uM$I^TIl<8D#P8|`=E-8yJ(
zF{^m%?itprajnYR`njn^FMJbLdlb|Y1BD0ilrDeYh>JeQYW>tbQ-g1Qb}ckxFYmQc
z*9^vjxJcSnh5GUSAsl<sEmiM;1 at R9w5^DOl7wvYgZ6*yh`x%EZ%eQ(Aoh?a*zL!SL
zo^ZI>C<c~@VITaPnZ3TyBKrPrbfLKElYb1_M|Z8RiR=ghmprUc^;bMkIXhkb^e$ZO
z+P9HTDl%e1=duQ0&MywqaV6LOkX~CVSv6;VrH7donZb11P0ACej7OwX$i)Rq(cr1h
zo2gj^d~H4Dn3c${f;)@^NDU#|g?7^Rs3(Ri9Dc=`COwH6iWySTEHCHfHMDz}!(K~D
z&dxOWuK)S&>wakW%x at q|K8ex<NB?O=WaQ`%Gh*S3qes^XDO+u)a+I>Z@!F<hf4!lf
zC@|jHo$y>@veGd}t%#~Xt1MF{mLp&Nd*ga_YwPQi{k6dLR$MLT-9_2e!JL<Yg!f%e
zH_CGK>V&Rh<G1#09{dU-KK>gf%$2W*GcZ4j7%tKimW$^Nzwp%7ru4-onA=+!KrGPG
z)1$o3-7;muX>0x7-4k?kIC1(CACF(Zv(TYY>rtWMN-v){AEW0rJJ%dCQAyj<<!?OS
zhPXpa+*GJj^;$~GZS{L^uL6o=K<KC3H at 5em@9`{V3(+t?;o^$=_3Ib at A;o9$QmaXG
z)v2THzwCEEGX#sexRl?a#nmqn80}P4QbKt!)6&vP#A5rt*R650UF at Vl+4&W7nV2kP
z{o^FZFE20u7Vo&X{N~D)E3f6`e)si-d!8Pcy-6ja>xk^?oSaOkbX+sAPTKYx92`_0
z`(YNDwhsS7CFJpXq);a)B&6d_G*NVKo*FA9B_+p1Onm&OqN1WU4PrW(*VEnT^{;U+
zqvOWa&xPB;P|a5t87(m$sB?C3Fq*1%RW8yMY#Ei5loS&e-#Hk!UgDMhIB_s)lGK+W
zO@@!{_(sRX#01eDFInZZA=A!hH;>cM(6G{UoRgCS^HVdd`r^Vua}Y88(fQ#tJbh;z
z5358M{l+(qG5RrFQbvUeJ7WXGg?Uwdt@!wO2DL&;U0q#DUK^i#JXUPxgA9 at ObTZ$3
zQW<#p`7@`T*M^@KYFDHhSBM%(C+d=S!&<26y826fWwbrsS)eqgz{iGvfA#nG=b(=t
zX9jbW$UnOtpnO`JNM6zK at _yr)_K1wpb!%IXFPn11qo$_*@Zkfm*BP%rF6kV+?e+08
z`8(u96)f^RD6XlgDM~>%E(wY_9_vi~rU1(4PM<V?nt!(#VL|d(7ryZqoll&sa<*UT
zr*+$F9rbsva#*=i4;8_noK3VgTyXUP4Gm2TdRaZbTf9Lbx&R1&f4*nPbvH)?MF$Ug
z4IA5BIf1BxiH+?Gqe`wqmD4-forez}W~=0>o*c at _m4s%udLF07y1KjDLwRR)7qF{^
zQ3<M}5TEn0A6hEf*suw at 9}GTbdh#SlDND}S6d|fET5E=YcNH&?)3spkwzu4nAssV+
z?Tx<u!Nz#YD9XfM;MccBD8t8ebW)tecVbwP8b8g4ip$D+wiOJKurxvKUzs`-(u(=s
zzkgr7)riN3JlZb*_z?$6CtLGpE}g6BHzqwUPI`KJMzz9x4bH1uySs+_t3$|z8{zk^
zT)nyiUvk2S;B%aBy;WUZ%^}l6)_B{}>Y1UkG6}4QUtl0HDXBjS#i^33obqnG^yuiw
zh)+j1gyM79T3_0APDJO-X5D3`TmnCG0XHQE_O$KEo>^A_xyU4Eo(3ut0XNWrIOt4G
zOQR5QVRKv^)W5tq|6w^AaqE$IZ=JXI#KgomHvKEGhP1rAyaOX6`5KXrBtlJ9<<rDJ
zGw9V;<8$N2-6AJ{4MlD?m>rIYmG3qpX*3|Yw>6^Y{e)IJT3P69>m}{8XU{s8Hbzkr
zIl48KJO8RS8E at RUK|zH_NT`aB?Q6HxeZOnf?ehHatNBo_Sv0+0Vy;?I;U_9VO;ok}
z;lC%?z9Prdmls(YnM4T9cl+*$Teof<9Up(U9OcNAjT3)=1<U1Vi^lu%oCoUMXm_z|
zh3O9ul)LAV?cQ=9h232qt52y6>(h05s4?_=gbnoZ)2BgZB^*Jh$|&f5vVr6`sRTZz
zG9YE?Zat*WuZ)F8HUJ$C77tmAW3He;WMySFSfCXHi at Dv-RJ1i0!rGtu3NMtB??YZ5
zlXMJ=@p$RGYuB!&o4C5UDVADl9Q>Qi)9~zy<7pWfh~%~yHjRGbM>U+U at iIp-!*uLN
z4kEV7c{9^trJv%?-knCpe77sD!K6&Er~=lt$A}Zppr9alpS{(t_E1F<1_lq|I~I!S
zE>i86y5j}i at 2IJ%d0iZvxE-tq6%|>Z&@$fTHcwyKkNzb7sJ6Bi_5+94nM;?Qf3N1-
zw+}8ZE|7)vl_ot at NG`KfjYJ|ogO&H)CT62086}Qu!%IS}&z`A5L%~gs=e2!!?ghKq
z820_jw0r`;%J$yg;E&%=wMrR$?9PsCW$pcY+hGYwUfjUL8{jGf6lsUv&)r4RC^PKd
z$t)z42sN%*W_3QX^l!2%2HGdo5eL4j!^YTGxJtVBboQG^u(vZ;Xc^&Sp92H0Lp39f
zaZ at sUd@!V<nI$`-pK^CpdmMA96>6v0{{0O<3nx|u{7Mv*UTFV{qP#=F at 4x_ynl9>(
z`@?Ji+qa?qaN0X8FVEt{9(D?^=ZV9~A;G<8zf8Hz-6lG_yF;xeE89ps^?$;)+TP!9
z?(UXDbwbB6G%=AlKiTK*Ac41D8cRz at CuFaJ`TTj+o}vDWOit2-_;?Ox7VT^W8n`T%
zpcVFN{_m|V8y4;IWV1pdKF5C(e1!M;(^r_q6~bbmxhNIC6 at dj}iy3;xdGqGY)YQ}x
z508tpV at iI9k9cG(#nA9@?=ZK1qTu9UzPJawH!x5lV1(Oz at b!Qor%&m-amDo4x1f=7
zb&)>I0*qqN{J|h3B!pc22fHVL++XGU7-Df{MN(UPg7cmxl1>(xUSz)Ik~a3!f(%|{
z*Ve=j`#yj{?!2LfhW9Kwm95Z!_|0B^3JWusSC*2(1zzw4L6;v4_m|f9dZ{}>127}t
zw9I<?V(_aat8R5`%F93ubQvb=ZajPZ`0=@Uxfzt!uNwD5=<em2`v=Q?zB*M-w)?9p
z=qDX%4j~&Yv!?d)@<J|(i-{4Dk<oX_sFUWsLtsD&8UFr6F;U~rb6(pcd>J1>E8SnH
z^ZevsL%JpO{`St!9Q0Byi{Ve9_n%*3vlwOuP<WLg^_9bDI7jI^4-b#i`kxfDf}-jj
zTr6CYR=anvY3#<4+!hSl<!sRKhPa%25(P;Zl|QZy<yjz^#N^Z+Id^w<40 at AA_Wn)A
z&CeTQxb3gLD$x9ibMvMNl#b<Si9hV8UBKM$uDgi!jg8S-&*!kEj8FDf<c-J1#|NMh
zms(F3niX_+cf<C4rF!+2>LY-a5nXrL-42xHbZr8n3u(sxT=63%YA at ERClZOw-CG@!
zUg=F~QVO{S?Ob^OY-Z+d^T2 at 8XobB=bgWyvKmkMWZF2H#^3UQ6aIZ)cJpJH~7*;0n
zv^N at MRtbxvfGw)fY;s+ps@~Sn%Vx2Y<L7HvL;x at QyRp#~&u3q5`xpDg3H{4gZ~nk~
z!jAUX>yxmYsy>dj=si9<ve_8pmP-`KF)K*mcWfLQ`ufvi#2m at wmjf05L?QXb2{KcY
z&vx#bT9NLMhf_KcpYeVd{$Se!rA!$bAXitf6V7aG$O3?wj+W38+~uloYVr+#B+;KK
zdk=7Q>)^l(p$jw*4am^x27btqk&*E`|6_jnxp5ASRZ}(3VZo4#0sj7PU=#3ZXsX}$
zO=Sqq2w_u!x{G1eqvPkl3tbC%t#4ITl_bS|eure2?Kx(>TJ3=`sP*N6tebFmo~x8R
zG<Hq<Ya>szN|`N&^JjmK=nin5?vLov)6oUMt~P}?O^Eg9SK?^o`ucjdLdq5NRv#Z9
zpBKkoMF#8Z>mx at FR`ZJH*4NRuX8^ZnYikR2O^94%3~q#yGyeESoi@%Ap=ml<$qmHr
zFR&ZrVr6Az|93+P3UiV>!~kkBEIKx}wtZYY92^mABSq4j#HvrGpP|G*-+hz(0<$Y?
z`RdW>DGGMoUJ#?`d^Av-ofc|u)7m?a>R}_J7YeX^KtStbe0y0}Cu~OmtJVI_N{5vX
zzP?v4Pp2=rdhX0=pzqGXAstu;(!_ea^s{P#rdcIdG?8Xo8N8q;Cz?H`*BI1`AHZ^b
z`FZzMAs#+{IutAkgTjjeZ77EChJpC(xOrcT;zm1I>pB-YVuAqN1jeVQlYmKEP1hE<
zmJ-EQIIi7+g{j16rvmPkoy}l|Xf$6~LkySO8UpV81~$dr^KZD|o|BUk#~_29?CaM!
z2L}fZ|0Xnc*Jb0Ly at 9@@>$XDMh4Swet+hhH$9`Ch$i*O3p*N0|S+l<U{1E5?Dgbu!
z+~Q)U>w$IMxj0M_MuOt{KX)8CuP*=j{%E|+njVm5cb!Vmt=MdU?%za38r)r2mHQ!!
zR+-h1 at ke$R7Px}bGDnUWPQh!=wLjs%eu?QIxSckq?)yMZSR_9E^;c9>l#Lu8 at I+;I
z9R`_*Z{M<yCI5(;KAGl0!KC!2%u2`Wbc3f0H90wHHd2 at n|Kh0w8NAWcgN-NJ<;9Dm
zb>|27;9^-uZ4s~)Q@(mkcfQcs&@KA8h~@`Cn&f0;KCv8&PSkm$7xC=;+_4S#$uzod
z1kDiHUF#DS_DI%uSTk#DA*l?oU=Ap!4NXNwMF$FlPoF-`uaBaDu at 6Neu({riMWwz9
zS>+g1M=zn*u`$$Fr3MN?urc;C&9pBS-uj>7_wbQ^fJOB3MsRV$Ye%=YjM(@5gGb}m
zb+(rmo;o|PE=cd)>wqe9h;7E<pw;_BXod)LSRD+4&u-5&T<t=6dU{IA$wgbdxX}gc
z5}Ka=7{-}QS0@<Jyf2Qkpibf*bghTO3P*hTlH5UZ4pZ1brK1Jh5)uy=x3Q%q at HVZK
zY2y96ccl~+Z$sY=UK|xQl|_y|N=!@~%u|yu3o$=|s at HGAo|~I<Xd^rBIX^u-hP?@7
zHH+mKeOI^Pt^i|cA3yesiX!Pkx$iBDC at Mze4>52NQ&P&<*_E)gbO1*EhtqXzWe~Zs
zF$AZoSK?UM?#xT(s^tBK`-3i&v3Q*D-1+y^l+fWl%|_Dl3e36C7yYuYW!onYd-6UJ
z&L~{L9riOwXvlFWto6*2OR#Zp7&PXZ4HLdd2Fi+_G0?D($m;j|$~>ccSdQjT#-Thl
zdR|`j7{qXvJT>-Bs!muY2G#s;i^mjCh<@HJWcH~V7m*w~KHuT<y*1&P+{p$;6x;HN
z6OYxz189 at brdK1VNl3(?QKpCAh@)xxBoD0p5d#B`pp*Lf*%|sCylKx*Pid-YDP8aX
z^OJnkK_JCAF^VhU)^wq2bD3OdUFNoL4)fV^e at 4jSXmBbKC1w8jcV3!3cr`bGyJ?r(
zyoYvdny3S9M%Qy+MYT{n$JMDaFXXMBQu$$w*CtKk#=oTEqFdS*s%2&B6?U}1WU}5i
zd_bB61_s*CHeyY7>ky0H?C(resPpn<RLy^FV^hp>?0K at M53s9U>!I=22utqs`_`1?
zR(AFfrHI*Ibu)wNFUD)mLdaN4?3d&K4b#l5koEO1(0>~=1IIQp^aVM#$1I9&5fLRz
zI{|mFb#^ux%2gS|PD;QbtLuBFG(XWCYx9p&_K{k?`g>^dR!iRgetyfPrr(L&!V%Fo
z^z`%qqa=-t(icZVLqmbYn>`<N@#Kp?72eqKEA5sGVAv3<M&lj~@3YIx*%}BWkV()P
z-X|p`K`AavA~on>WDL#9q8AYnshmGt83=^MvH>w9K9E+tA!ycAFpBm^`iuGTFE&qG
zB*VkQDTO at LM`(U?7`OLAv(wq}?+xKX$p8|g_l6ed?)G*HS_#pu;a}3vx*%w?E8xnD
zv7_$xi1_;rx~Wp7gPD%peaxS+$H&L|Y|HNE?};=c5z$!iFoaYBt;f4d+&$0kent}x
z<BsTsbrPR)LmSUnC;uCsI(k=ZTe`d|QW^3!e+CPAp1kEUuUkpvcMOIxs+Cz>KQcYm
zcy=L1FY|Ty!?T?Z*8h1RPLpmTDk>|l)_r3EYnSaU4V!hG0H<P?zo at _B-6}~-qj*+v
zu0N6Gfowe2bkDD~A7aLI&kPe(UvJtPwRsS-mQ;FLb~0uEQpUYAlOc!b=frx<=0rs#
zT(-B&T8|*)L;_|4TB)eyS0Q&Q=kZeL%@7(;xaoktXJ at -TmGeBNy*{vaP)2RHIf<hz
zWf`;ouk~haa#4LhQ2$?=O88>fhg5%=B8Fx8?7^Gjo&E&wGyMcE-*678>%Ze|P4Z`7
zvh2kgc%gpWc{-(bZ~dWC(W?FAS&*=FG;<1YDCj3W>z_<Cz8hfGxa~(+#N3E`+_g?I
z<?@#RI>7H~@5=(|i~9FhfuhpFz?fObdm->Esbg5F<-gt>&(cZ at _2YUiz4xgv>YRFO
zVpkTJ)o)%z(wwkFF=3(tn!Yy^RZ-1(`A15>oh3KbzOU-vVBlHkYkof0Q{NPlS;s7t
z2s6i&$FA)C;19mnZ{EIjtKpt?b&7N?ky|9<03YVJEI<@yJ*$h}Uew;^bP^1tv1MB}
zXR(&TLv5IMK4YbcOuFNqaQ^*E{nU?BtpUZ*>DsfW*eIXtZWw%JV=Yg1-BbAI`#Uz+
zYV_HP*Z~d!lb8NJHxxRbo*t)gzPRD<U4w9Yr at A6?$FQJ>2s(?UWxmzRPe2Z{>=xR&
z%=*P*JZSdlU|sOBuYy)(4BAYk_8s)(SiRHEv`D~><n{d?%Y(mJIOSy>S{Z{)5lBY%
zAD54{-R=qLf3pA=|DWS$p2oPmv%Yj%_JQX)@<PZ}d`B=+uLNE+zvHSH%%)td^xWKE
zp?~(l_#4~IU>VJYT5|dOnWx-spApUcXuW6Z-=AHaZfe)K4gFF>PHATm2H?^T{YASj
zk=*?OWY_=W4u;NyJLvi2)50>9Lb=ZhMNeeHjR)Rh*)4NWuUVlA<@dPm<<!!#^X-ld
z-p^bt#Ptp7+dAm<*4^y8>gGupF8>LK1y4n9cjV3fX$t4i=0I(A2{*3kSkFHo at RpO6
zU!h4N_bS(M2?&7LGgWTvgKCl<D;O9PLk9e{_g!}1$Vg11KOV|5_CjeLuQJ<RFS*-t
zeJ6;&TD_9I^O>Q`tq1F1ym>xlyCL`H?Vx}ux8^&k7_00qrbWzk{!BveQmO*4q_30V
z3Klrb6I(rN))T%y8@=;-tMjDNnk7az{PD<!jr~0o0?FgJ%tWCRLYI8V^P00GfM?3Z
z7n&!PfXi<^F-|^y{{AXw>pQHv`L0d~elDMjjiK>zsxFITFZ}YjiX*qN#E>{9<w37&
z>lL-?m?+;tL;Js{IW22YxlDESJ=CJHbLObKLeJMejf%{?xpsxVVQ9#P{@MpRk(^X>
zV#>pF;hv2VIYF<H|7|mxUrv`htSF+l6QB)OkJr`=Cg_QKYa{ZzmNa&eTqw)s at iJBr
zKHfruubjV0$@_(vUar`AQ&(pvY414M+o~)dt7!4<LaJ66;Up=yzG$Fo>SkjU>FP$k
z<ksi|$Nr$a$jY+OIzh{L?9hW^119Z{?E+aY`hWPYpJ`@CzMa6!b&o{_<b_#-DXEY#
z<+L%@y#2Su at ty%bAt9ZRkZz$49fUzpmRnm}$uLt^5^z5=AN&YI;P!yL at JhsGdQMov
z>fXq$KWXP~?G*+aav$Y=+*AeyyE_LxFjv)70v|b3cAxQCJNn)BPpYlkkY23|YO`6$
zqyuu_7D4L*133Vo&Q8ozEpZ?S at HM@(dLJhqb}`4Hmjz7{LHu%T+Z-vPW>U?60Jju#
z#-&BrcvzQPW>JfggNuKxnef>(^v9EfvZuuY^9>T56E_pFPt^uls}5FUw)<jI65Q7D
zXEg87e^O&jIzDg4^PNn4I^Xc}okdS*;7w}i>2=FaRvHctTq!9j9KRTLu9+c5=Yck&
zP$;VrzI(hj4`4W1Ot6oZg|;~(fg+n;%_eN9sAvq|r8pdx2_MEWpsKG}Lw-d*b*4(t
zO=kEKk?WNK9_Y^Unym%_DZj~IDaPn>IuXG5!lmc}_3u|;%BpnQ$b}|W0eJb0ltBRl
zz-p4tJc?N(0`!WlzhV5H4_u7aJ@(7rjNWG3)p4}@6=R(jCaYmJl`ojYe>p*T!MV1y
zlG2;DJ9_e?jrYc*ydwE`mbM|(UPtdi1Djo0$&tS3&ye0eJZx!R;G at UJ)xVk^8~b*-
zHw7&?11VgK5H at NhdiHMYSB_F<5z)3l++m(lkBAPz;|-7E|1ni-qG|N<+_^KewNH`^
zrKhho*6?nadnJy29rP}{|G{XZ$IP3qrspZ(CKpTx#(#?SE9W=I%fbNg*<7~X0+hGD
z>+h85EislhAI at +4fQ9GKwmJ5b2~gXlFZC62 at wdQT-D{4LIW6?k<oK(5b|w=0fBMTT
zWP2_R*m(amE!^wf<^1T`tzTC!Jkzq2Ka+I7_UT|oW#OdiA+x;_rpf-aNkUyT at wDgR
zedsZ1h7z99QX0i?F+s3N*5Ks4Ge^>hE6K^(*PHSZjbiNVV?8d#DAeDAvMGb at xn=>6
z?8#5Q;Mme%{eL*N{(@-7)@&WyxAOY3pt_**+AmtiTYrzP at j7C89T6ZuDUdy`&1kr+
z<!GLblz15!=@r0J>mwYN-GWUVF>~hVi2XN9IG6sFMUJ_~{`6O^*?Hr4hxmX0{?&li
z)D%E4V2pKodbo)Kwi$4fx)A29=!adMVqoXIctbLoxpMP9e-xk@=(pLDQ=7Bq#F&mQ
zeO+MDdiD~ps;VC5PQ at CZoZ@d{*Lmc2V^otD6t>Uq(~-E4YU}yuULDf!6bxTwFKkHY
zytH<k0GBtWoSl5ozD+Y!u_$SA;s)b^@37%uO(}g$Mtcr4JpZ^RdC{LDGrbK_3;Buf
zU^WIrht0G%IX=*MZYjx|j*m|xy6CoRFc&9rMOD=R%0zy#C#guf7N{Qdr-8?py76N#
zUI;!LzM#lr935}CNu90K$MerOBTm-4?tl5hllFFY3Nd}TZ$#d?Tqmm!4(rnD<>kb_
zDnpHXTIZXRFeFH)MsH*LK`L>}PUjo{wa|;?uG0)Nb%J5}_s>{!M!Y!9UGU$5Xb1H4
z4UoSLQEHTF-$S%$75?xQ%sh>^@q>5fuOYStz^6%tQEq*zChqrV`(h9AJEAXNnoZXV
z!p_fxK|WUai5r1fYc9dF990aLBa at R}AT_e^G$5TewX{g=mQ7XI(*wyc*_^83vizg4
z>p{c(_{BkIXYUU)rPbkrym7HFXjKr#4U^4;QDb&phWsR*VLW}W!%1fsSJyrm-gKti
z8a`lwf+2A?w$&asp;_w}8Z_U0?)=X*@f{mE`7=v$P>;LZQiGH<x~A3UBbdFM4mYRK
zf>`x#_w!0^wRKQx(bK#0w5J+?1G6kLHWnM7+^43d#)?>E%5Ci_%(m(k93dHe+BNlZ
zX;<YR9{#Bkd2b#o^aC&^A|hgWx~`7J`W*VUKG)rqfvhkXpVeWM<s=1p4%j at q^^}0l
z4h-bbF_x+}Ydg+vh)Xc^>BJn~;b)x1!w!_8*8E|53lwgCV5LI~1!PY(#p=AyZR}C?
zw1j at Wv0Nxh^n(DQKZ9|za=z~LU)34R<gob9cj==d<o`U&GFlWy!OUp4H6t?RN*_s#
z$zAMu>J&;P*bX}sz`3#C=$RoQx8<KN;B0N9TXTdS00esG1Q8_BOF`0q>o*Z`VTU{3
zXHvHtcLRK9S9-pH^tlKFJ=)QVDFY#v9+aW>6W?&6QdtD&;@~%SLmYhk`Oa9*%6agV
zkT7G~AFPjNQFD=}tXjTU^1tGbjlbH%7%A=qaxsXz<j<Y*SvEb;|KaOP!HGaC4eD3T
z5PU$0Ss9hH>p|^<MmAZ+W85A!TX%VGy(rHxfiKlz at Ljd2lg-9DcID-?$1VX(8_m<g
zyY at YH=8K)NQA}!t!otGP6pOL at JMCIQ^adNJ7%CUE?+n*k(41iCFq&=j*I07z at _oo^
zaWN(O=-<;6^F<54$y(1iYVWh~H)-Pf*49PGTGQ|cNnR&GeQ6SF5v+bczaTQ-gMtP_
zf9m*c$djEvBP1kb1{rpjo}6+}g%)>saN+zFAxS>gPv3^+sFfzLVVW8mM9QSUdw`D&
z_R-d`mi5YiFLebAm(5{W0d6~O#r)6=yvtu8b96xomUKHaU=uir*jAVq4>1g5u3n~G
zSaO7a`BGo)y6du(;LM=Twx%M|`8E0yjHFe#Aa^(-GaMe(=J21+q+BW$pWS2Ue-mvd
zkIfZgBy%CTM*rbWA(bUNL=w0tR?lz`{81ib09_TXyO~xo2FJ%sNfq`>gqJ5Hb?D8F
zY#sC<s5xGYTOa!wV%QR@&t-nerw at uUlt5sbM3|89<*Y03IgQx$_YwK7PahIvyKgOH
zvdUdw!tL?MO=TDalMK`}l*_h3m$YPub$|K|;j`pz+N*xWLYV!XTn^yonU559!Sv~}
zKcwc^0Tn0+McX|Ua at +dFo_To%mBFJ2E7<9D=DJ$7Mh at 2kZ?D>ZpVMhbqvwro9hM#`
z(vvT<n&fradH{}HU-b`AAp2_EodMUyKvLocld%0Y=YS^6=Rsj%^vujMF=v3-=oK6;
z(1J}+0i7ohUclB`QQeqPEs?6Y9CCOJbi~opclX>6*86BLeQydqfWKJgVG$D%A^Q6D
z$Bd5FaPU3Q!uYskzuOX?{%4~end{KR|2C898NolF#TI2PFPq+B(QXA=40<sFs6cro
z;&RLqK*o4$rU5;N$8 at C62cV64Fd_*ldEZ7t<)>hfq*TDBL5tyh9!JHpi)#ze&7 at L9
z{YfMwB$}tDbZu>H6u{O^pQv(X9jAc2gBk|fpW;`|O#*qK*_4YBEY`|-YC$(;aIvIb
zyzoJ9shpt_lgz8H-ehZ)u>fMb94Nanb&Z77)d{1;R|p$O)%AcZD=&2H2YwcUDGkOe
zzkq<bzkk!lZ6yV34#q6BD;<L1xpfYh;UT(UGoWvfh11->SP`xbIfmm`=r0r#^Mkui
z(XOz={W9C}mW`pP_QbqYHwlDENF1cs9Y9=zUoF1?F4YV_1vPnuR_~x)OsG^-sB-1k
z^fa}#wRP>$99~@K$jb`5g~ZC9si{P8(M{I&L9~1%Bt)ffxLkX($|SosFrJm<B?YDx
z%3ISvNa%E(6Wmf3JlqfuNo1 at X*ndeLJ2&#wis(2v6wA)w4*k)VZDLWN_xYM0MZhq8
z0`df-x;$*m%=p)@?=yCR$&H2!kbYJb^M;{GwL$$JgTv`Sp)26DPL7F*DHG58CV=c!
z?c<hChbSac3JNXfO<Dj8=gol~zzD}G-t1woquJ|17e|IxQ`JFbWjtU%CxhfZ>b8NF
zr9pI;JpK9;g);2?#_n;v5aSk|9|Xt-I%Iv4_eGAh7dSa+e*z?92$1hQ;zMMXp-mK6
zuK(1eFayJD at I=}#&QBfNMw&j}dK7i%sphvmBtR`AI1j-I2?+)!CNW+Uon2jB>7!qw
ziw#={u at o8`8y(uF%dC?O*vO;66G3+jf-j?=DpCNr%PT6r+x`{T*@=7hP71&s7^W}F
zvF6%zoiIB)d%jN9v+<$|hn3r)oTP(R4F2xS;^J?3?UFDlZ|&{<ShaBcX*GElJRcys
z>C#^CvcS02Km0fO%>7>i5g*Ch8gI;<FJ=RoXrzXFaXB{LU`^$FH^$}R;qeDH9NOJm
zve<xV4hgI7MEVG{@lbGpv3+0^v-$g*;O;ZaYzbH72_W6*cf;$zIQnV5;cK8!!Mas7
zGkT~8iA8OY0*Y)lrvxX31j{T&(38iilZ?1DTEBpvzS7mE43_;v0f7m+3oZ1p3hY#)
z&Z~yy7_|Lnh`mgEoyvmHVClCWyAb_EDHAP~4HxQkSQOP{x?Yg!d5A>P$*M!A(y4S{
zXL`iQ82sf6QDak6P;hYL=x8i#&fd~@TJTI<aq2dw2k(MOo){dg0o+%(9~RR6Tz&#-
zFyQEIDyl+hFGyRU-|1659Ib}~iFT4eR$b5cM~-KFZ at zy0x>ukMZW+iIyVV45M5Jt$
z7kYXEaR!}a02e<g`l%L&!7rSX!_Ba`xO))2Nrv3Owd>a{6xYz;KiG*&#$vhO#SB at F
zo5E*bAc~LxE}&T=Y{yn`(UvEx%Ah^`q3n=*(WVC;X?l5OC8M6_{#TY`$Xcnuup9+|
zfH>v$KHrZ~EHRQ?Xu2t^Y+z`J@|a2#bdLgMjA^s>v=D0dOBz2|#8H66vF9h?gfd~_
z-RXQo;C8wgXH5cOo(1p;D(AhS-h)FzLhLTiT+#T<o|h53Py&-M6Ql~-!H58N0iGT0
z6EH$+cl&35lUgVrhBd`e at c&OdzkmPUUh8=p1)pRBMz034!j}tmZSDBErKK!<YN3hs
z698tC2NKf!SXfw3e83PfbqYvCdp{&hsxrqt-WO at oUdqZ*isd%?#*KbAK=jl1O^;nD
zEidQIfUeaJge*_m3rr96;~ImQ+T)=Mn!O_AXpEs$;E;!usOSf at JJ#ILK+`l91kb8=
z0bLZ4T?d9(J1j|8?k1R(xXJLBoAO7Pf>S}GQNfG?TMU_yf-b@*R8&;$pj11yc>^Q(
z3VN)7y}af}4{>BH?b*@aF!T<#im^F{U=%6z{e}6qNDUzq7~`dYZ}r#Jd0*CEVdz3~
zE1_L)X5DIa3PHCY2EbM at +JV6JC*6bEQqEU at BPk`tQBew8mf=OH+|E>;cij~RlkRx-
z=Py|yD5r{ky`b5yMR)@cqrnAD0MOh}T#^%ob}TX=pd<wi!J$oFPEHjD%N(dh<KuWJ
zJ4P5oWiN%;+24#pdPAw_9=n0x6$bEPDgGU9Z?mr<4PfJ`Vk|%^h_3FLEa==<)E7vv
zRyuDM4rae;$`?<%zcF5>2CJ2oo}Ru8t>|-v%I?z!Q!Wno150QR>S#0g7|b<vi at b(~
z^&JRE7F8JF_``=E0KT)Pmu6<ZtVp(+;hk2Nmm8JWS&S5dsogw31{HuIQ(3te*>CQ;
zHS>Oy!VTSC;K#<mvMTdm- at biY)YOy#WzrM9Pv-CP!SdFfei$+!K+?9{m*yCoJDsCM
z&+oL}n*Ap2wXAH{)*px;<!D#z*k3+K<hA_(t{9aMXl at 9X&W?@{z~DG-HBC+?g=C+$
zBH74coPwO#jLgiPhU?V5uzM_7<1K at K<Q#$LkOF)j35;PaJyxSvP0zC#y6`t1>qM4g
zct?-nxxiFGltaV4B_YvbQhNYI+F`l({hvST07DWWIdTg8o1YgmFi36VUKm1 at f>sG!
z=NDv79NUrv-JgNAT$-~saw9wrz5pU{3*_A9BuSnJ6g<{bg93H1_3<e<`~c-2*92j>
zxVR9Jl73xS15+E!H!Lz1?YB^|u@~<{p_4T=HO(VocljhF+?SJ+gLn8jBm at uQCFV#C
z4-Wxo$wmMX!0?oI&(N7V<93pZ^G$E16j7|MUH?`*xPd<s)SiBj$@<$8HbU#YGvD^>
z_iqkJLF}Ch2nwPDgg;U?K#Par(DwYqQRwn)m$_)M8gd~p?OE6ff)>QbuZz9PE&-U5
zXNCY<7(yulz)w~qgdx#`PLDtj1ETtn^$P-_4{19Ch*)@lJ6V~Z|8I7-fj-Hj5%MLx
z-WLMN&wK$_P at p5@_e_ at CK7!g?nyPW{On4q6FMQ55(CO!Q4ZPG&&8r+NEG!Z)KbdLk
z=oF;JCh*w at z+A#+J12%ZP);&|VSril$45Xhvz<%XkJVDDU1hi7V)Ot5p!8(*JQ$RM
zgc1-@$ZjyMj1WDC93YsI3s6|)RaKBudj+bsq>Rk3=4N!h(6}`lVtaY21y|mJ(FD8@
z?X$#bcL1=q!35d@^<%d;tz4+hCmu%C1 at o0%RHPCB&+OUpE~S8r!fuk5ogK&LyWEXk
zU7w4K*(!d85NY6j5#(e-Pnm!c%`ic6^*BN562|y^pnvDe7_6+U*aUaQV9*AOl#Z6x
zA216d59i8{+$VsY#6EW}93{Sgo0ypUIL(^C9RX6QB^a}CFXmIN7+_a4!)E*@>|M*n
zL6g|hZ&DfLEraBev~_e;fm{-F&m<wwD4=XvtiHgI{+kFvr`r;iYK6dbgdCMJkSjAM
z0)Q-q>YAD^FVDNc`;6y)1 at U#Wj{w3&k?FdKP_VrP`U-`q053aRCQ(2GfO&_U&uk2N
zwj_KBv>3PgaLT=Mz9*h95@>10rV4liU=m6KDclC)-5t+20dKp>g5(vNi9kwWw at -o^
zop(V#duQ%M0DKR*-u!2LJTfXO>My0e=f&~T1k8Kzepe!d0a>BpK8+OeYo#+os6Kwj
z3pC_2Qs?=)ExcWW{&Y#1B%uV at 3K*+KUw|nP-M!lmZ2=g6CJ49a^dKzr3>0E(_#?O?
z0fhBHhh54JSdaf3eIGIfbb4j7OrXXZKwmnWzC5P}YZ<vz1nL76(DtPB^z8b2zH2R!
zYq$)?cTv##(2+h!%%Z_d7Nw-9m<^$1z!J-`A5R8aSoLaUfF2YU7Dhc$!gh9c?wUe7
z^(K&HJcGv0*KP(M1CoR8f_GJ-J%J%C!dn87^2M%ko`Hb at v^#9bR?Gxad-ZZ at eH4(P
z^HEQW<ur+iiu#o<8OhaC3W6RCr?g=I*4Nj|P#69GffKC(aqQAMlTuLFo>@(_0 at gcf
zcyB{UdU3WXu#!LzH(U)cMYK7X)DWV?XNPr{3t(p<m!L7lV_wBZM{<ExaQArMDF}__
z<K>+{VMkrRNyP at d2W?5ga%Q+*0PsWA384pmu<UvT^gdS0AY;F}tre7+4&{;pcX~ui
z`)c<LloRC9kqdMb`z}-x?UN^Mh{H~RN--H3eCQ%W0?+yQVgcGf7{vpi&O)zn0v9Kf
zF&p`}=guquTnJDtkV|Ats-Jp<PMJN~=O!W`-<*)36KZeg-op%?8YnY6^gJEalW*J>
zcR-2(1wf(u32`HSe`mfrY)EopF9FaI*uiEV5b#F#O2|w?v2Nyc{92X_5gxAiPfFVr
z=6IKtj2LvpoV!QZb>}hE(|n}7PzrPhz>09{*PJLjYR|n}fE5Us9g#PA#zsfCfrk~l
zA6mhXnQc}&WoN%>45{jM2pIzHGA&U%E{CvT06v8%$Yn=cO*gr_?mQF at M<5m;=QU9D
zbsuyii$p!(G(cIJp^KK=Ed(zfyR{W?N)_tXw8LE04pm?}ta2rBDX*y30D1+pMu}Jq
z?RURc*7Vp>v?t1`-*^pD)b)^!;_68faOHrP@^-#89BH!lgy*0e9<^qV>89yZ2n|8g
z<}mAj4CEB#7oy`JF3x+~vw_t8$s$*=2`RIWzdwWw6+Fv-+<B(3Wg4D?PDlf3R5?9G
zt0&FPuLjm3!Umsx4VkVZD4zneQljH<xDIG+8laZJ8=zqMk at FQAXDkdxyYTI{pn`Pm
z{>)?uE_6r05L115af*MJ>mztCW{JX%tICAbLY+X1laFnAX?7l&A)fsLIB$!j=XBjM
z(#ae^Hx(d3=s~UvwV!OldAghy2CSUzRFS7=2U3>1-j|2oG70?LEfzYsG|K&*mYtv-
zm`#+kqYnzOO=LIs8h$ruJ^}`;4neTc5xK#*;iga9+uJK;hwGzFpwfR6bT3_GvVBZT
z%MLRBT`tqN_ALzl#R$08r#{npcn@<R0La8W`wS9hFF0rD1cam)z>q5_CKMb-IKYnw
zA9M2aBhdv7MkSy*FH{lO$f>}X;)T7Z@?{DFDPYsc0y;JU>qIA<0kX2Jr)!Z5S+Vfq
z&`RRofILSvgI_eW^Hc6{V&Egn6O)r)A*RUa(+>i4SIGbiJ|DcpE)FJ;AIR~sv0h*9
zKp%(rifnf!j5hr+CuP9)YHtd>X|JtiZl0_7!}JZ7f>abk3h(phYj*Dk0U?<{ENh4M
zz}<7_VNzs>{a7lz*MCzr(y%w78C-jd?yv<a>a`xO=z$)cY6jku1Hc8BU4n2Y!lZV8
zSc^h67EThR!z0jb>OinU0T2 at QY!f<a^_5WtB%$O{M@)$Det at 9WRrDAJ2NzmlDJ#I!
z3$-&eG(<o5yRjcBFz4V?34B9OQXWTJlnb~t9QrFxj56@*(|?!`F*Z at jjg7!YP8mIA
z)~Qs+BuVSb#t2SJOH<60p;!P?fmqNfx0%fmM1gG=8-=Da&CSiUF9U$X?=<4Ee)}01
zg8=LWPCu!1DSRED{H+rLCJ4nWx%=n|qDJn;F(mXlyGcZiBo8_*KiAX<LOymrBSyE~
zrn4E2BA|1A2SU&muD#YnK^=#KxD?HzW3H+TRKg6Jm|GX*%hMqpOlOQ1gdwVGRL%;p
zzPr?859$(X^$PG`trM!$zHF=8Ac1uDHM74I73H;?e|_>R{zpdZJioE%@=IhaK`sP?
z07n-<y9Ox<L<Dr)8i at 1IV_~qu;kE=E>l)t9z&wIjg2V^;t2Z__Hp%iyLaHeKGgw0O
zL6U|BOc?iI_r?mkJB6~;x&o<`(es9VyhkHT<L3n3gTdY19o>)B)yd(`uMIAQ|4`TK
zGv!i*-I9g;oXVh_r`oly?d|PNdH+5PF{u#8psTBO-CgA6<1;Sr0YMi;>K)K!kSYV9
zuvb7JG at 0d|6O1uuXJ?)5ZWAG_wcl16dts;~d7}8Z<yiFNC-~lSG}m0$tTi$GZx-MW
zyRP at SBd`N>+0Dzva$voB(;qkq=MorHa!Fttvpq+>cz*?mgHo>YlgL1Fk^4w(@V9_$
zf at B7HcCfZlhdU6?#jO8A^YRbM<R&STDi_m|B*d3Mz+my*e(T%d(`RaQcC at XEl3*0m
zHBgAs*7VX|W_j?y2hjNYR$RD^;nRspOj`+>m1pTlukJsK=UW?^<#xoH!ym#<d;;CO
z&G7{>>i)gAp5hk%t4q259J4#LxA-pa!rSl1`qSAIFZtt=Fn#(cD1${Yt!=EaXe;eE
zytemhmLSx|Y59i@{EIJjaT@)y<+rYsy_~%ed0meE<nXD^*H&5VM}NpLW29z=ae|!#
zQj2^V&h$MWyg+K`+L<u%9D0k{HVH|qMPw*r$?0Mj*+mzMkvd+NTIF6<D}SPVA<WP(
zp2bs4b0cQ9)8(V)jhq`j-nFfI at lr40_YF8*BfsAz`2`V8FCcI;OUP&W1^gxej=z0Z
zb3L%SS=B2eCSp#ASiA_9vP7lgGxBZ?cmKSre2yLL$g%$w+TYZMEKwg`guT;;qTW~?
zk?e}w!Oq_uXe;Pv?^6CFWFLO6_#j`oB3!|kj=ZF1Udsm<lCfHC;7gtK at X-%Z>bz%n
zwUO^ur0gUtulezWi_>-5n-QK(VnrC1oI@<Hbah9YR|ucv9qZr|hxGLNwl}LiEUfM}
zR}RVo0?FX4Ua at i6v&Ly18g6zi`4|Ku#Oj=oUP23wlNUy&%`Cb}tEGgckFQcE&p(GX
zna6T=t`Az5^^8U!ET|F#AJx3*L%h+~$CSdQ^n7`)vG^qTr0RGk3VzXnYuixsD$Um=
zm{=_2K69H<YN+STlRILY>)!r}Yi0f2f%G9O|9QAu=o}{iKdp1AsKXaHWT+WLsBDt9
zh?TQ#b0Q2!8|PKpoCkMFl0=ZPPx*Fp;FP20^XF~-q^5s&JY0_U<_1Mg7grliE<%BI
zk$w-HonnELi9ejIWB5N$4(n*VUBMO8%}UR1=_&b=)?6&cQhCb&erJWQmEVg7%{%U=
zkcx$A2$JG3*Wki#&Q;D4g*FVxC8=l0FKrvX>Htw3r$^TqWxMxiM&Uc0FX4p0D68}3
zkJfQ<2?<U>GdNw;1W*h|D`+2ye at gbgya17r9Y{m2YJrrE%@)dc-dSlr`VY?Q+PIaM
zB_;@_xra}6-uFsReAo8w0CozRPD`?gFR%R~K05Qh<pTNSV<0o2IIuzh+W=ZhCz2aa
zqDAJ;`=2k)AJ!=j*7^I#3GIL6;?&xXH_K at Zpq*?TDhv7evA(A#45X<(h};9%bU at GG
z^tAe)Fnku=7 at V*{0(2a#(6?=7w#sUp)wZ#v6 at 2MH%<EJfp=9OcGQpYvr2h)s0h7)9
z!UGm0Vr2v*FdIil<CXplONcA``1r`I_DtEm6g7PqV!_#-7)x~gzfQ6&Dusdc{t*ZY
zUy~<HdDrV9nht_*EL>#{QV=yYXDdX*ue=`lw at QGX`)j@}wg=k+7H=R^wqxffI;0Ep
z4m!3EGyk$mDiI=FUz}zK&c?W)CwQ<@GsD304`Da_jUHElhQBs9UsdW^ff#^RX={W^
z<4G&}mVW(@m|+*a^cg*V!#ZbrPXiJ2I^S0l5D at 6!gkuA9J;G1z8Q&B2Jak8h&J%->
z8!J~(q*`znmi#Xmh;ZyC8YF2rtR>^(!VB7V*OoR+>9>iE8v~1lN=)d)gl1=FMU<5X
zl at 3o&P7p`62F<}BIG_*lpuY!<1sLx!2Zuzdrj>{rHUD#Ceqe9IpT<7>L7&lOAR{SB
z1Ecu)1;8pg#yn|G(x?qd;#PW)?ct^oVA)dqo33`{3{C~O+n8T2G44>zS7*lnc?ajl
zjTG>CE0l_f=)Ry=DICzT4?qwGGQX;-=gEYel~q+rz<=RD&PO=Y2fPg^4Wjeg`-Zm|
zZ{ctfKz}eWaE%>dk&iNM=ym%DX)36?ROij9$Mp19dx2|#S%=0juoxCWOmNtoN&tGb
zd$Lw^6>YXIb|-XzH1kxWmPmtxK|YifXYEHb>^#53vBfDwHUlo&;f1Nx5aLoR?xq;v
zMaaue-n?-`|7dF#jxF{7SQ)^pzTJnH%Bis^g(EnqNkAo-RLujXxL>OYWZ;<83e&yL
zPhh45x<+X=p+NRr&cY}-6+IY0Q2Q9@>K|C}#m_Q0Of+3GA3a(@U4x+ooOwQ*8H}l^
zDZts!0NZFD4zHdZ{6e5aG!GwMfni)ahWQs~+chGZo$o;QcYzXwM?^G2;Rc0<{)W<p
zD;be{ku;8>f4$9HpbCJAZ~_4|tXqxD9GwjR>o?yReS3ow{tkk}Z$Uvt8%e<9IBjNL
z#53ze5xwRlZZuC2_D<xpUt|MHqU$n?B^}cQJlw1|857cu48b2#89EaM<2)~?rxIFT
zsr<W1d5Mo7lKdgKJb8{V*y7(4tMY{iwUWU>7Nlxf{|}B0H5Ls7f+wbW1kw`PRS^Ld
zPLnZA2u()w1uFxb%nvxN{B^=qP6!(x{ce1Z>7tS9MVrNV&grK3*iF~OU4b5rm9V(s
zh9Eonh*+X$i%=Xe-F*SD2BHk%BAcKH4QP)C at 3i10fFg|*jTUr9M=5HAHswFSIVPuR
z6r4APu{lc64yPVWK=o4Ho_oH*_Y;Zk(6r^_^LbK?)#2orZEcR|pJ5Di0JbLiiFD=K
z984?xj5ywmL}D{t;-y at l8Kf<Drxut<QB^Tjy@~DMgL!{wx>10Ff&xyv#G(~_aADzW
zN4#g&5<2<|0}o8my8<A9mL!2|E}^M;7w#`TBjXk|bq}a2;PjQKe*%Ks9@&b~-`{_<
z-FcruoI~0LgUP8el$vIaV<Pw}z2IO0p`d1i-}|lC#CTY&JIkB|2WR+6)%dKJuhvYN
zUq)z9^yku4vtL;(@E;NKe}7-4q<wS7OubY?)|)@WG>Dn*4tA$c66<2ZrAfS-nD%>u
z>-9w}XO*c(r;55p=gHoCmM`JdTR>XcqZdw+?QLyAFia)E=?2i;KpN`YMTg*EoPmZh
zv%LHf+Jak6B5cOlxw#Kua{#F;FQ3;Q%>}vs;M53O1`Qt{Ur+U?Px$Buzw}!8s>bX5
zPdm|g&rMKhiZr--I*zbu`cB^8CuP^4*!)AfF;8E4<lZ1mN47yuN;|MYdNi$Zbf)4c
zs?Yj3_A5JQOMT|ct&YvDe#Jk$^qXrzZEP2h*vQ|?P?MjS_LT~oCrTNy$Zbg#kBOh(
zeT(tXy1{xx|CGI)(l|$uaXj=Kw@#P7%B|-u+YD&6=H`sa0f}yKOK6<{v>DBSb{Iok
zL1;ore}Z8M+Rg?44<Va|^$m|w(u-2D`@W8OO&0Q^bq5MP_Z;}kx9KT)vGmq`iVj7p
z=(bLjGEnlV>tBpif0y$%kQIr{kT at Pxt*~8l?r`<|y=1d;Qw6JhFC+Ec>7MbQQxx*T
z?ykV(^Ubv`&mlwgvJY#xf8Bn*x%q+RHYsT{^epswHJB{tL0<+L-Ubd=bP-e3``sXh
zN|^)k2+kQ{0}V&dz+=M~Jioq`eg3<o-_P;2^`z8S);`&w_Ja;F_5L?DqFO$j?Vvl;
zU+t_9MGGDk3rHf2d($wt<`mTLWJ;OTjQf~0R}Y0G$@(+C%KtyDop(Hz{r~rsva&+<
z$SRkJjFLi`8QCW?li6vnWUEdqqatL>Je_7nHbu&eaH8yF%U+qk_i<g<@Atj$$K$^5
zzwUpoM;FIFKF8<t9?#cHO&iXze}1BEIWF=Z_Qq`l6 at i8_p)+Xxq5hcbqU&`xQ7lY3
z=E5|aiOkP&>*C`XhJ{4Clm%+Z{QF!TPF1WnO=`UlYa$Yl1$GAllRW#k$}q&&@!{Q@
zL7Xj&1X6+~QY_ at uNty>klnU5|cJIs&Rs at f4Qoc~vYrDqVwJYh6N^HV``t3d${3CuZ
z6TcUkriIek^G7Gd#H%%WJ`mCMHx{h?O}zL?&lmvO`w+WFaL6?5vi!yS$BEV=sza+}
z|Dw3m7Af8qTh%K%(UH=#D2}~Ko=hCrP4albM8b7o)4N(Gf8&+#Hep3-2f<c?hAENf
zPkbp6;ek)c-houe)BW?}^`osWF#*Gk2b2~wv-Y)L at 4VT4hkIVRDb35<+(gkcZ{<-}
zLryTB`*t?JWYeh1uXsYzFDK6+K4`krsLZHq-)zR`?t#H!%GN4}O~PZ<#eFW`G7;Q^
z)2KaWVL3ME_)Oic2fxuJS)uswdx^8m?^m`o at Y^OSU1sC=1M at n}+j8nQbb8MpBzqT(
z5{?T6wqKCE%=TQ9I6%ATJsA_z#8ft}@X-;;rN)pJA!f4x3+oD0Ar6Pn7Joq7-Vk%W
zk2mjmL)s}hn`vDyn?F<U(dI1P1Y<13PLWsZBb#l={PhN%^5`3U{DUoy17A|1#BCfW
zXYaQTQ%l}(+VXQG)@ZH@!d+2~V+m+t7 at iz%F0tV(ceG6KQ&A6MFK&9#IGu9r6XDG&
zK_O!j80+-r$c!$8SDH{Yz%0vBFL=v|%3>ckf0*09(P)Z7MYVjZW^!NE>C1nVS61?E
zCBLk8YSvA~F{iFko%f8VK3;QrB>rUyh2sIS-d%mt`8lE0pEP~LyR)9?>XK^eS|;+^
z$#v$fA61=2Bz8MkoPdSik-pT6-)Ew#qmFu`?qYk%urW`F#KRj?;^S}}TJ at QGAL|;}
z*_Q%i(mqanMJH71V;5U;4lK&hRpk!s2i2sG!A)NRbiRD5w(FTxh<$A8BQk5SyO!2d
z^p_>0u7gr=*nZyS at soJ|e00Ch`0WFF4~G&*50nbC^fjl9OKsAH2d2Ct*BJ03*Vpat
zjO9fQH>>KB4s|rw9WTC-UU>66(W^48+YA+8BjsAD{{EBA{rQz}o-&c;(U-~dAL4|u
zI%}2LeIF}VuvtVnN$XKlkK2vS;W+-8JWu=!fB!4*gq>0n$0Ueng0a#M9WUd`CEg1y
z9S|gMp_2wPBEL*5kk`uS77B0Z>rnXViccPiQod&wtXf{Vay|Rm%cFtFyT5cjQH90_
z4#rg{@;&qCPt)QP0#X)mlRArvC4WrjHbTAqtT|2Oa6VX${U<59Kl8K{4p(2y<(VE&
zd%oGw-<|uDZ1L7l$6zDJ`*7iI>}G^Z&&TZ@{8odCBQDO;;F<^db;%DcEDM+pnteJK
z1u2<*#+xz*yu>#3l8&`R*i(n!Hmncrx~%iMKlF|>z+5wOuywuf_y(a2qq3O7<kV at U
zxTd%rUAxae at UEt+kJE7sHEK_*^EZkr|AgYyA7_Q}Ut#XcXpr0xXVgVSUg_RM4W5j2
zae1nhASh6#a=+Sd%dFz}*RFo5*WwnmaqqUUd*o={C-K4bzN5Euqp7i$Zu3-A!%W9-
z)*9?gjDFeA;wMj=?G)$JaDF&PJE{@vq2njLVYhrnV at tQssL5?6-ZE`LSHIh)SgOwY
zleWMXlfm9T*I;LRiIhxp<NLgM`mM=M)SFe$-FY4HURjrUcN{-wz9i>5{lRL!3Ypo8
z4$8NzQM--PE+I{{mh;e8OT3?8D~JHEB)Bt9pye6S=y~g~$%19j48`eid^@(P&TZ7p
z6<^e8wH_Jqpm3<Y7M;LbdP9+!=gne#XRl^{@WQW_H|j?VyXtp!WO5?W491 at ui`G2K
zqT*}DaAMZ(3H<2t=uehY#g#jvYytZ at CH_uh+9t}|5A8V&Rx5Dpb_WqEStf-2q(*uf
zWn!v+L~%zAciIXfo at -!iM2&=^IMQ(v{Iz+QxY}}SQV(1+?URKcy$y}CJnhp)u5r~q
zW-veF&gpsw*UY>$*W4igQzY{SeSPlmWfDiF9ho2twya;g)@_F4xhDR`Ib&B`bOD=@
zS3HWjA)Z9vk=}`AM`S;Fy69}H#>$(%JF}@_(r7BXDogd|oP#e4afv9k;+S)uzC~J}
zRZ2CaO`Rt!P$tY?XXu?U7iVQhwR-GXeGek%7r(Sv{WE_4N{H1e_QMtZ?$0Y)=#m<l
zY at VG6YC%`!PmXT9S1*5EbOIMU5x1HwDiNrXa2Tez73^_r^Jk~aVT9nZM>X>W{(PM6
z^v=TdDx;5kUUr}LQn&0=L=S(PPvIX^#cUD&`Qp&mk(E7r5SWPeGE8(F6F)T68;Nz@
zD!w!?U4h0jmwp=4AIyJoh-3C;lgRcbZtBka%oq0{Kkdou&h~VZixV5a(R<;8uKsmt
zET=||@}gTXjY*D?DD8WLT$|Ow#~n4nCC8TYgTG(QXR3tQ6g7oy;3WCP%ECO3_!aHG
z=%tF|C~iC8H!~us^&=XdA0=eh_Qj*h+%5cf#dF1?_kUn3SdR-|4t~v_9l01C_v2#s
z^96a=0fV9aS2gbo`|_4g=P>6pX7-&sswwm*itcQG<CB07PY)(+A5FiVtJCFRl7j#K
zL*}Xxw17V~M_HgHJ<Sr$M|BUq``J(;0(bFJu7(apyVAK%_oSS}nN|D;A`0t#j_-M7
zob^&gg^UKYrXR6T<<UHf`<Q}vVf7o_T}v`=edya?z%I7^&Uk5NZ at WbDRr|`|Vu^WU
z;@6tEWN{Pb{r-<KHkjCa1?+%FH|zB--L3S0FHS!`|7+S--Q<c8op1d^wl^u?JC2Tz
z9BLA(ufSQ(Qd<XPGsho1GD$I!xuca*Dl<-*V)m7ZRBES?*SF49QuFJ*?7dtz>C9*~
zSKMAH+s(qgobqJNI=^lQW9z>CEgv`LkC at GC{sRwx54D#?9pU6^)pOC*CsR>}`~I~>
zDm}_=xcMFUB4?F_4^ry54a5owGoSTuZg%6h#$_Dye+2i%b3VR$uv6vj=NO9jq|%g`
zAspBBD_Fjm_hp6~P4H}!93|WJgP8BTbfghh-SirVR@=IN^qx#=&8YyB^eA&B;;F(*
zcOM!mNfnRhD=N2{8JWXaF&4cf*C12mf9e)WC=r+Mf2h3MEiJy(cP8BYi|@w!v_w0x
zh$e~o$ti|@sXSL7pYpv@!IAVmyTV~RUq7WY$qy)&vJxqk#!+F)xz8H6MeFOtEiSE?
z`WnZkni=Evj_&@+owrij((}W*?$26QjD74|z$_g{kW*ZrW%~Wu!`D2N|E~0v+zC4r
z|Ht429H+Kp%V at 6AJG8-jAy0Z^>5ivi3U=Qm-WT(`u*p#Qb6($Y8y{$+mm!4NTi*C-
z4JFaS4}<YXIq~=#xFpX<zRDEG<=*;V?{Efrl at j+Cllu5;7ZMgL<m0L_#5gzGsUHhm
z$DeMa`!^2UCAV6bzn_T<$PNAxR+pXFIEcgTC2!hMHP_HDnrYtW__Fz=F$C9GTZsv-
zP!n?M8p24%u`gnAPb!boC6A91yxhKek6r(wm85uju<%z-Fvf7L9{rBlMIj~hF-q_7
z(*-IW!c(@{N|zpc at zqu8iGQl{)8JkCB8fA6Rij9w>az22ngusL80YL^va~1Y(R*+B
z47)=S5o<T|w`OCugZqm&clqelO?4?$*Uii-Te@%A2){w!=eKW94Ka>Aw=LKj)fjwM
z<F*=hK+CqMYXj%)bZE4Yb?0?-9LtCOwgWf0>|S}WmK}|;ynvxVtfw9W)-qsDV(!V4
zKx$41EUG$Sh)|vT2>cq*Xf!k`&V3S`?M%wnvbIZ26eN_CGc$MbOnltj&ydbCC|4h{
zCLrooaK37S8lAF6yy<k)Rb>%cS&O7&Vz7)Fad-!v9q4i*U2AALqYYKUU%WsVBrtdg
zhejTPq&4g>--wQ8 at 13enzWyhn=3>0qQBSZ~7lW*Y=gPCMcbt|%c5PVEK3_1qw4?@E
zCvbvUkjLrfX$L|5{^$HWP#|ZPmzQ;Mx};ELgc1Z|VE{=IprR8qaeece#e+I|(XaN?
z7!ha}=$O*usPJ$LK%ab}{RLaC4q3c7J2FZ1EHO`7SJqYm@^$7#W`d2u+4`*#)8bsH
z`2o8a2Z$042*#m0b4G0(l<ZKkfrhS{tn5j6Xi&{@16~k#2W9oEE@{zRt!cZxz5VGv
zpa%o?H=>FK at 1m^j_XX4QoJW*X>}m<^&5cgc at 7XDvo9;kPd;-bcL#P;qRi?dsc}qn_
zz0?<hj!+oDX5{7NLDzBq7Vr1+axrv2_M=<3)E8*C+Byf+Y>Lt*{{2D`*)lLPP$o}?
zLJJ7PBXV=C9Cv>$FGtn-tgWbWoXd91D;Qk#I#~OX047AhHZ*^`vhkkeY+R^zX!I)>
z6p?d){*Tt$iKXA?1e^kChyrNyv7<wE(HSGG0#7AF6AFkn;5cCz!YTh288$Yc_X6?7
z6cAeSN=j1;3o5`hl8}*QKu1hM;?4^et)o^gAxuhWSlA?(gk;0OLHcRX at PO9MC#Z=4
z5hVf!R2hIaAYi*;2tNj|+@?ly!x{Q8!1F`tW)k4?)6DJ&bp$0>x22&gP&XL at hZZ1g
zKY#yzFEcc#<nmu|F;h^&gi#7?iMa3TM`AA;D6pJl5HkG*9SkU6d;{QQY2gbLRnUwT
z)C0V57M8fUxX%E at AVdJ5Rc#xIAMYcYE6|Bz-~y?cm`DSmSO9O at 8UP4Pu*$KJmh>GF
z+NNN{4**ao7{FC0i~V*dLjY(0GUp9t1%&;D>$G_>#3_I80&<dVV7gbKJxBlM7(P1@
zw;45XcyMwZg*x!$;-a0%B&k*$a!^IET7wS-Qduuzsk(q;X at n{Q78eHJ`yL0lfBEPH
zJ_h8mXI=(O0|->IO%@;M`&T_);|ix2L>^+0V>38az>|ryej__{3clSTER>K=-d!9l
zH2MNy-(zF|NVxoztAt8Ow9QL%&UXHJ8+iNcfRac`O75>f-Tr91vhnTU;-3z)qb9)Q
zHUt`>;|X1{IjFg9*FozL#z!H28MWcx;|7jO5AO*EfKH|&1r%jI1DZ+z?1Jx;X#mIW
zffV)=q~>L_K_MYfhi1ud5y0sEeH+jsV+6$>0Nlu^5_24R1K>J?fg^PL2mq1d>ptuT
z6F6jm0qCI at evhPZ4jis-FP_IRZO@fQ-FlsKe#)%bEZ{IUJ^egjLw4&&){-fbSHXx)
z7D2jag$zmpfvuA%Z?OndxXF8MmTsWWmGH4lLVzRobtk689AHBX1|tlV4$#xVre>>`
zSg5H9Ugo}Q1qjFBy*(3 at p!LF0B!bFzik$W%fFp!JDG91z7p`7?|6vh8$VmX~`io3h
z0)d=DKnSo@!Rq8jRWzTIrHzJDxJaf%!DrJ4T?24sF{p9>3z*dQvIuB_0?!4wX)>^3
zh?5aGnPg~vk~K)<5%rmz$nZFoQ7)nTc$bTk5{&6yAVpy)pMqIHU|Jdn at cHFV<Lppj
zy`Yh*24Dqv%C#1Gmy=z;8YG^u+t4Zw$M|)+?OJ)1>}#T2w6)L=FycX=CU0*^C_sW%
z4AARfAR*g`xU#>tsV425n~n*C{15gUGmgG at 5A|*?n-92AUq3%^pAZZReBN4LJ#aSE
zRgQSME24o5AF<ses<}ua|8Q+C$Kw<)_m`ZKxaWnpoa%^VqZ8_}M+}AB)Y&a#GDe;O
zThtllC=T>Gud?-a#sk&Wmje&2qLdi0L$Zr}Dn;9FhDzt#B~!TjFH1xi(Ze=b-+bUl
z0)>;TPy~vQ6bj6zFm9x^itly{Vz-FyTvCo5n>fS_XpyL{u~VY<AF>5mN$3WC=CEZ8
z;>+JerB9B?GQ6_1c1rX;wbyQ_#HpfU#*`?~FG<#cyK)jo1l#k4GY72pTs{v6i?s8z
zeRsmWH^0eoo|W@{;hsPT9Sot-L|e8{K2`J!eN+S$XIm#bYLV(L1F~yTPWVT=k^!yP
zl)1Pb?{FMFO-9zu+GpdgW%RL@*2N2T<VR^wzA7)?!Bo3P at xQ`*-CMk)5}(9TeuJQB
zt2|16s0>ZmANK0mMsqwYHGUgjlt1iG*M|(e3Jq~7ASrB0U%q6h^nmT0k?ek^X7#gy
zS0p~Vo+9OAhFRMu;CfB){yp<q<*wycV;Z++LraY+Y at e$N+Inhw{N>_4D9LP2HFA*N
z^~knH9&btaWaMFuKy at v{<$4MiSGms_HO_>Pg0?%-k6 at J;w&YB+D^FiT=SFi+_Ns-N
zQZcm|DskIKsybkI`1=zqA5}b%ehYzm#{OAnJJC<<7);qqZ(<R4gH1ul at n<pd>1bZt
zQ4&^n`q4W4Z^;u-eI6QlupIs at pSf$ezPiTN<WR`U!jei=^^n#v=wr$#bpVZa#`)i=
z16rhZz1Oisvgerd(6+_5H7lHyjcip#Xccx~jX;Pf_M4idh?5#H&-kJhG}zWTf?lu#
zFhqoP8JHyDe11W<C?SmNy2k>YP{ZznM_hzZt!0G<e4j9X2f{-QRk>tBbi?`l4osTS
z(EoWmI9o^wB(4?A<UAMSBkef5Z*Gu7zb@(T&2Ax^LG{<Y<|#ugl;o}6e*SS^_$72J
zVCsPoqfe5R6O+IL=bQ(XH?&#2W}sjUYR}O8qDt*u0s^)l$lnOa&sWrnHC{fI0t*X#
z^}tk%L8YBpkryKz&m*eE0~n_j&=y`eW&mD0Vb!lVgQLsJ$tiUhzB=Z&V^S!0R`$(p
z#eBh#|L4j|=O2XtMu;OOuuP8uUV~MOFe*x6al+QFRK*%<-4HAwLOk#pWx8tr=JP93
z&Q53>utFPdvg_KoC3IqM9_>y+i%2_PPY at v84}fMO<z)b95LH{yQRqcpUKdc+A@~eX
zmxWct+4&H&MX+9vhWW1- at Mc6%>TySwL{wR(%=IS#il7>xrJ-qp8PUb_nsi+cthh)Q
z4T1px%o%NFpVqH|OjaKHRlpUK!SfNCZY|{I<U9f77S!2+iIzs>HUS4~A>Te<mL*Bz
zKJ09N2AU*@1duS2!*})eBQDiDcfd1&5HT%?xu_AHnyL<bTv<K`K#*v6ADFNK4$ti5
z5h3vO+*w)-MBG$ox{@I7ke$L}sAr;~?46yReZ{(y5pDpu6F&lcoj-s-hyWBQC4_iG
za3Sba0@{gaS^!AgUK!W0wY7cX5DaTrg`K|L%5!`<NL4 at x4hu()2OshjL at rIiYN-U+
z)Oth at GLE5prwX_tKrB~5ImEkCw?PS1AD5IA8v(en0Z7sUy**`B)sC_*2;TbOk>)Rl
zR8TMq!)T;_Bwv&e>jLvWjOMYoK(7!a-}H)xvq8+;22l)Fzj&2}ZyO?MSU?beNdizP
zL_&iRM6pt^`d!-EtyuqEISxpYGxD3<++5_#A-f1Aqf!W}AzFe3NNKwcpum%sl|O*d
zX9k?z8n`gU$}1o?her}~xC1 at 36R30gai@uhK=UI3f~|qKB%Gb+p#@b7o`P^c?R`!_
zGoB2DaOE|;@pYhMuR!a>8zf#j8d9+)U2j_ciAk)F{TBNF0ttXJ>{U=k%M6xvh~O9O
z{O&AjVyLa5BN3dPl|^T32>tZKrFm!+x<Nk*D4|f0K!M`l7wlcV;yj^S1F_Qn3Xo#4
zf3)w#f!x*&M5=|&)bQ~@XK4n!*WBIRQ at wy|B>-!WAOL|+XlQ64K#|x(8UmyD_HAXp
zz_~*E at _T@iynGLQD%w#aSK)JT{rQO$y1(U=3M6aPF#DANHwuZv%ZqQtoyJ%L;R~3)
zH_*{>CUAFm_vQv5?g*8euJ~F82yuu!FLjkTD8c|&zI%5X;#<QIF3e*R$WGsYU=)FG
z;l+I4fZ=>X!h4es`fA at dz$}pRm&4F2$R(f;44)R!c>uwIB?q5C%g9x6eSo|m-h!#_
zHS*-yW#I;QKC?KLI8Qb$eZqs+EfRJB1fUFW5d4X`0PQvh&qv)t!&taBtKwSFPJ(7a
z9oW_rK$)FPS8Nj!g1bT@;2ZEBBQ|z+E`p#4M4y(P{-%&gAW8x$sT7!5pTa+df&KxO
zzbphR2_0WJvIPjFzYo_y)Cuu!KMtiDZt_hYd}VndG$n at a7vW0%4m)7T2ondogXENy
z1VCazX?amlFcMG$5O>K#Ab5i0%oz*#RuL{7Vnj=)S%~x at 2&^)uXc)$!E&&&(KM|ZI
zOESy_6Iai?dx2SFDg at 0C1ATxk5f8Ro+kUMuSu4F@w}O5*XyFhqMX>*kzd2kDgA at 8L
zCEf>yXt1SgYim0IDGc&H_%J+Wu1z3S1QzTaEG_<f^A{mBLyV`um=Kyrh(#daY4ac%
zhIkxgYIH-2U=j=3GG_T=Hc$n-OPXwN$#P;GqLbX>MB%Ml07#IPn at h{Y1YKNmcq+)?
za3^nqP#F};1$221z<9I_4=2I5X at U&(AQ<ZEU}S<o8(?|-eG#JP_&??a5fE&}BFR_`
zTG2cXutw-c0^Of8 at YcWt=9Q{PzY~$=ij1>O?F}zD06zPuc{wHljsRJueKL=zc^q`&
z2sA6us7UU24UnNAEFtn;&_PrttU7SN7E)zqr3ZfSdO-fEu_*lawOr@~krN5zI!T{j
z8JNM81;AW8`)vgha~}xQ%U;h$-ve4bux{rmt?UqlXiWmJj?8U&gZihOvSk5Wtw`wV
zq at t*s9zh~w4bMOz9u;w(SCn(<30xCBTxAgv<JT@|ZwCSm8_5le92eX{OIuss$kjj~
z{)j#RpF4F2L!E;h;M?NX^!8OgBz*RR|J-YLYZJ)#)`Cg#y(-*BcuWjDX(mfcOIx<*
zf2WJX7m??&7;<wlr2b~xkJ*CY^Du0<kssQreFl8fjx}scK|x`1W+rY_-t6Do0t0Eb
zK+qsPM1BcGJP;!Pc~o8+)`%cjlAKeX6L|(mBYA1b_;Sp5ShtXoK85 at goP7$7FNh-P
z=RWfPU>*6oHc2-pH`ndYy4Av9aWO0np|Z$L*#SBKPq<-#7iv6!B=#f_w1bj#|DFK+
zuwrX1AAu(<w6IA at NP7PM&88vo`K1sD`N6yuTGZ7e5y37nLm^(;v(k>=zJ0?41-ZaJ
z5H5grA{+XhpmRc&F;>=JtXd>?F-|GMNoi?j+u~X4pp2mXj*0;M^XC3i87yCk0EALA
zGPVMk4=Q?r*h~7>P=r7{_5ftko5BY11-OG;C*6a(Ng8~awez%jf%_n(q#Te;)<(3<
zP>(^9BycPJUzdK*Yc*g0x24}8_ybLoq-?h3h0YmBJK%0Eswcz!<x9BFQNu`rIV2oV
zAUJn3F^BKVlvZGSs$qJ8MX$>=7ZBv{_!kIt&*#e7&Y^6baR(7r!5PXaoB2Tl5(XM%
z$ntD}kcIU$1fn=_=un4Xa19s$cp~oL&E5TXZf;ti2>dWDGc!(WQ}(q`bf^3)L>vWZ
z?mOcVGHZw<`isrd{z>d52t-6gAdKV&H~@4Qy}xSylikM;?|&dQzx&_&gYNILX&u&s
zFPk4gby!4cn3&oCc~6uwD;{)%FAzKfS^$G48&w3w>FU;&707e5*@~#AQ~wSMf0Ta&
z=?%cic5EtnKT55TdX{mce+u|I{_-m1lQW|DJNc*9JKv^87Y1 at DV3%ef1TqZK#$B}^
zx&{7YVC{ZctMN)ez_Ezg^K(t~Fya&jGL@)cI?MH7%$|V=2yx9#Pfw at 0R`|~X+9C@<
zp&F#{&kG<zL(T^<kS$yRa??;iBL_#5xw$zShf6TgK&p90;Q~e&QWm~a#Ik02`75OQ
z<&@dFz8hWFkf|P)Ay_CiGcfe*?CP)<2{5KmH!;HNYBe at ChN92|h^h=j9=IS5p`hS~
zK$3=-m>78cRuE8xR}{i*2bw*`n~zI^GU;T0!6!}E0q7o5>VZHE_S6DXp$~x9-+o4P
zV)dUDP!`dV#xntQBxqRPy6i*G#&#D<A&3?YyiVIp9RU_Xm at 3H14LvVn_(C9pe}KU2
zh))y57;w}pP^pBn1C-;sEnh^htgL8&Str1Td_8}@Ln#yt&7kr at X1@r}Tfpdj1ZX1+
zcpq`L-(a#epd03XakDA&g>*Y`V=xhNfv at IWh@Y<eYzu%^xI5Je>_Xt$U<CPsBKNVk
zH+ at YC)Co*|*Ax)84wRTGH|#kv<YEFU4?vdzV4lLFu)qvRyb)7UFB+ym^;`=G8NeJg
z3N8eQ?RKa<tqWK{BnI&Vj2IgL^1)g`l_r5&kB3)O%U<SSl at Nx<1<;oO0cgvn9yU_v
zMGJ8%g2Kb3qjq@*4qtNr<4L6CixgC$@B`XjAhf>$!UbDE4Dlc}$%~9r#RNO@(2&ju
zMC6F92VP$$#H=6`3WJXoBBmS<TZQfU+%#=4Jywijy*KCje_IO6_q0f~yt81a{RUtJ
z<_b6PI|h-63X~(@BX1cT)L(?kDDdF`*R2jV9>v1i{E#h*I%5vm>Fa%AVPHOCevkti
z2?{DuHN9nGR>}ac4)UlHaN>sf&ucP>p`22gL`$ugK%Oo^J$EYXV(NJ~CRm6r$rHV{
z)ikx+104mTt%45{XpB^drrS$&WQVTo?@ph+Y6EEnFk-d0)=NVyAAx%&+*BLP(I-5b
zyAa5-a@^l&sue at sVzu9Rvk9p)hI7gV|9V($Lxqok0pA3m{YZRxUvIBLy>~^h7AdC+
zth#(xQ`EmerUzBxw#%=+%ZYSIiJ=@JM3nm>M{1r11Cj=SB}<rlKsbGJTdNBO{NPDB
z9Y`;~L8eiA=d*0+)2xRLg(6w9P1o-<kk0RvN6oxFD*Hpioo1xgSuKP$Ei4_Fq-%$#
zbnyMfpGW&wl2bObvU7FtWn4<{>y at U6#4FBpz7whHKeaQH9-}@eOLrT~BWe_#O7hK2
zZZqKgHi0FN9h=sxx+A8#>tyyf<E at 4_M3W_`#Bm>JpJ={&I&jv?)%ip>yQamden!$L
zM?)nZOks?rH7z;Q>K6v*KMr at Qw^pYebPXjL$tQT~83eynON#kYp*09ne(O(?y*;aJ
zofv*h>Ysp34HC}o<?dN>+Y-REYAALM>ULg`ILjBNcGLJk!@2H~Ji|)SpzLdp=+5%>
zeI at EE#wHhOn^>8sCOU0BmPk0)Us~n_VT&i4#BQM<D`+wGzjK>%D<nMI1Ytwj`=RF5
z#SN(UER8w|eH`_Je_^^_T3X+oUvr-MtJcm{$o?hgxvx=rUtUwgdqJ6aF+^t~1+sH(
zTF%o_g_+b%7vL~)S>eupZE_4Oq8#pi_dk&Lb;yrCnVG`7;?n|S;>n7N7YWr5C-sac
zS1KoOeO<4SF0rm$o7V1w25XO#WIrS2SHgau%0v?Gv7mD|P{vl at x^7%QP8- at cREp`|
zYFQYf$w-b_E*x0j|MK#c_RlWk#?$p?A>r53tx-c|)QL$|@7xR}?T4s at D8%dQD}30G
zQm?$@uRcm%xwg?Qu at zdC5uIUXvg;A_y_QRWll!#48M%K4RFz2XDvOj6$?=Z}cpax-
zx`yJa^`-?{Agtga+f>Iu0ZxT(aXV4n+ViLR>=o=%4vkqxn5tLiOrHGA&r`*xn%_uk
zHU^`^nY_;U*HR9 at _-K`P8~?ehqR0JJ#4KOCxU%&Cwa=;Ei1A0Cj2RrU^7LM376vi(
z9JkFaeiFUM9H%^4b>shozgB8LcjAunv)pGB!_9%OEFbNOEFA*Scby`2Ib~;SreWbq
zfzdn9yRUT(3nV||HhUy#IK{XJI}0YqsCW$zN5to(QM{!Wq at 8WGCd0@-+$QGs$$LjL
zm}L7g1=S)U*}D0t6i4qN`MA{Qn+1a&&2i?yS(3MZ!Nt9FuO7;W&Zd+Z3KiVtH#xzD
zYO#$f(C(My9&GV{@ub;C*Tb^-YEI>=xS~`FqR_j1hD*FIe6lE~0hZI32|rA^Ja!im
zIHQx at HsW|dy62C3qPYB7_z&*|x#=%>*I|FY-5)pd)4xkN`;pf at eS1tk<T&FMS}`S9
z<;=-KlfepujN&2HLv7opwT+%d4?Nd95ALDkcPi2|=s~)J#ioROT#az0hY#v0v=~{>
zTqkqAcG>Gt=dtGcRe>N8#{2CuDCNyXKio%E73L9DT~tm?-0c^63o8QBrahG at iKc(*
z=N+7G0vo59&rd%0QuNsIrn}GSnS!Tg#d5CvBMrpIQk2ieo>CoK7_Bj*n$Y%~ODQ~}
zcEVW<Ua at DcrFV;M$$`Pww%;kd)bpbO4I4eqqTwXZqaU3Yc7sq?PP#khjB(t at UtVQ8
zkvXo<8}&E#6t{jPX;4Z!Vq!kSD6zxKWB-ih_z9{H#U-(KrtVE~d~?-_g#8L74{l-W
z=>Yu3P=gok?syz_p`YyXYFh{OAq9^^NV97Hk<brY<f0-h)Iv+4fe~55dfFuc at 7-bc
zgg^FqWl90=bMa1|_9-l`LsTE7+PZ!BjG0;PGpBJanT2%2TSde9Dy(d#r at G&+_SY^D
z*JeF<U_K@(UhhKLN%6#b>qFORw7!na!VMV$oBHRIhVEZ$<T!$GvAX(C3YE?{?(Z-T
zd1~Jc+3ZdTkk<CNM6ea$|3_%zH)+w=9&v(4Lb{}FdOy#}GG1)!R1{xpQ at -D9olhUu
z@(uf5MSd`2GQb9Z(~a5x*UW#TK&}NQg0mISI!0N>D+_yitUc%~{X at dT+su78J-}zG
zqa0g|)1V-dcr0nt5KbG>t~PRyH*ut4uh=lxO*GcI)LsfVa}Appt>M31wECH3I82|!
zJXx%(Qj5awV@>7xxvk`=UWJDTuZH_><9?MpzTkJTtZ?ic?`#m3WFucLU{5#HJ6g@(
zyM64PhT~5<jNLQuHq62LH at y4<Fwe`t<X+2x!_%(gDp!v~xu^D;Wv=EcvRrwG!^B!4
z7!T1eliB!j{08 at 3-7}gNYO$sjp~(4PciI~OoMR!aTkx{ae9!tya0K%=+RZ3xZ|X<K
zSu|Qo0k%sz2SW?GAs0{LJ>L2S5a)LGWlS4AZ|tf~kW*kHf0_E0or!2mm~s6A5#NwX
ziHVNw_gf}kI-~>!-;#(wP&v)8)z~U1U1qLmPGRR7FJBRboR&wFWyhAlJ|(xP833@`
zeeBX>5B$ecduGpi_|0Tzqf at I<5i at hlFZ+Hh$J at 1xt7nrfc<DL`FZu6I{r+~k@)auj
z-aAnnQ@!wy6OI#;sVh>W{ch$LNdrdSr#ud#{tUArp_Jk6A!Cn}X_!~`gVCW{bobg8
zn<(%iUwds1P@=^v^K9Xbk$M#PjiZ<rC*JEhFZg*=tH~~Y&2KP#ON_Vsj9V%#QUXpY
z78`Nhf9%n}BSn4FA=j|;`Xb8i(@~$B;f=&8ArsU*<@vd at SgjV<ccWn;Y+w4_7ZqE^
zzm_=in=6ez at v;lAj9g$B#>OO?uKB5(6?%{L4BweuEwB<&ns(Q375s~d-m&DrFPr<B
z<i|m${NC=hjn$zfXPLG-k4t)*hiQNp?o)LJbVr8t-=QySd at 3cAe>-T3Mt63;Lu=u^
zaEh581>-Go2cgRxLXR(%@jHIy$EW>XW!jobO~x6zv)`m}Dh`aJRdcd2w$|C+@|iRn
z?svZvfDh%BX{=eboOu~6B%ntj;@Fb6bHkN>ukLNpl^-f~vLsVk;+ZK-0~7;wdHxd3
z-FavEA9Z&B<#Epto#>sm>J}t4n-%iHOcRyCyS8l`o6g{<=~uSyx&2k!;Nnl9_S!`E
zic~I3vK>^U%}>WSX6z-U)SMCu$Y8I&>vfVoX-=Y0p$>^}EUiNnH+8v(Zp`&39QPz-
zU+e6Tkve}s``9UYL3P?pUtFc<2F~9ZK!_hYfVlHsinaPSfB&Pr#5>jtl)7xSqsF=&
z4Z#)t644tMu{)v)E7&3htNAhQLOYd;_SHsSVY>ov8JqeamFe$SM{9*g<z++*;f2y=
zi88KVJ5Nu~utxU at gNF7_M_n2w?!x6|QmySE6{wK?i%d{AEhA(DiTMts`S2%reV{G@
ze}Y#EI;<p|OOVFFpWuCjp#HKXwUD{|f7y*7B7v$#TKInOyj8~Xt&KHw^@7HSHr0V}
zjZ47r9-7eSc<{)EHqBK~-Wm#7tW4iobY3IsFCg=wmvu8M%%qVeQBbk|`L<{Tv#f*S
z%GY6|^c4tGBQZCEn3~LEGMN9B!r0S2aq|_Wp7b2(%5ch?YKzcbNU6<Hv3ymT9!AA#
z$b)R31h<^2Zt^s>xT)&~PGt>QT at BvIofSs2_y5oGS&F{-D%#pN<!X065k0_$*&o(8
zZXbR_AAas;G+W+be7roBytC$iGS!>G|Ig_98Y$<}GhNZ=C!^9r{QD*yZ<afrs+Gnp
zu;;{IW4yoMYEb&u%E4<f5}90fyPXd^XVOcP)*M)$YlaE at b=}5PQSsw+)X~Xqp{G7!
z*EbwnZqJ?AJyIe$&YIY|sru<6ro;hm#LKwqZDQtlWC*2y$x3DuFzNe?x*5)%K?xQU
z{~>vaIfP;{rp6DvS&k3X1sSd~Jh=AE{F<?;j&n6{(uZ0y`((lZ`@mZBl7~@fb1$K@
zW4rqE|2accdxGf^nQor$?)v`#v3r%>UR_<MKW_)UzneaKro>UGlZC25oXqhHp6OA5
z?Loyz-OY*C-a67p2G>yS%zxOIB;V$wY{f-tkeCm{t68`G858p%xGOmS+8Hzdjk756
z-8(ULVO*8;TW?KtP@|r!<!e@{^LC~*OfnxHD__ADdaElxV+k;nmWGmKOmsqPrn#WO
z4*jY6)IP16lFuA6X05&rB!H&>xZmn~VP!mB@$8ig=?z|M;`uhd4e`VhlDE8xc%(~w
zeW7S}0g}jD|E>q=l4?8tCKYJ0nPtB%dtt16bn1zJXL>T>QFPC6U)_*#3P*$5a%H*h
zzdM`vXPzkWU?=z05ho)}B-)p`Y|x^g_tcvm&oXeBwl(F;X!HVZlnEJWTejJT3^fvY
zl>L6=fj8E?;veEQrB-A}AI=ZFSTnbmg8Q+8LPpTSuzJNw_ksMV{=-~3W7)5Z%{6(J
z3?9TYg?ItAnE%<1N*qh;dw6w at 4HdHRWel^gydVy9p<Q`mY8jbgBUMQEEnhC4T-?A*
z;Kqk9rB9z){NlI>15rS(2ugS4i$r!~x^3qVSjoLr#c5pJo>VI3|9bEIY$3nGv3Siv
z0`0zFiEOT-9-SaQ=WeKU|17sRuD7#_3iZ%>PHkvC6>VO1pDSYNbVuVe!d(2sC!%yc
z6h5H9%!hFRl~m;+IULo^)!usLg1pN-dGJAGOi)V-3zgO-BnPpoNDHzygAO*eA!+RM
zb9T;og+KrlxaDPgoRYN#`bJzAor(M;f5>o=1k>{x;yY|Fi at U3r_G_9HZr%B854wN0
zlRyRG{E$PUQ2S4H#38Mb)rsyb$o|@a^x1JWF#t}Gbiw*a53Se2#sRI+(i}9kE(;bp
z0CH>M_fAP(gx#!y)QhA3;>7TX=DRu(QH%{pl4<FQy&*kk1oI^I)!Wet72<D5#g**X
zf=WEcG;kKmBq#2O^aZL%_D?WjJ<d0odJ)Nf;J+1ILc;}MfuKZ{?68TZTLjY4o;u_y
zKQv{NlMS_pRPX0R#@8a225vT7OY{8Zg2BT-9M0Hu4>52RW3nBh=Q$#p&29S4W~jtv
zuN7<B;~plqP2E(kscilJSGNOoHTm+=Nx7PVZzO{AtoT-T4^urqx*+NxKmcO2S3Zo^
z|I>IDG+hkEh|gVm;wC6A>=8SLW)$PZT>p1Aca=dV at a_NO1b!%UpgrP3{_e>!{B3vw
NWd(KlBH8;-{|hl>z`y_i

diff --git a/docs/html/images/xwayland-architecture.png b/docs/html/images/xwayland-architecture.png
deleted file mode 100644
index f24dc1837f2e190c9d38719420a844aeb5997efa..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

literal 7611
zcmb`M2UJsQx`q)I=^!9T^#n0UM?ktDD2S1wp?9SBE*;SWNbe|wdJqEAdq)riaw1JY
zdI<=j_Yz7d_jk&fxpU8)nLBH;Ru(%DcK+=D``+()-yQZ;^$`Ur6Da`!0mWmbhj0Rd
z3&P-OMob8PGhO9-27X+0lYgv1OiVm6t2P5(k~k~rx)Bgu`TFB|p*~_UlYoHL=<!22
z4X?EIDc`5+R?}Cu7GqzjJmeT7B&uRfR*KUvRxFBE-A`wIwDohZj^jp0mriUtcXote
z1D{br`g%p<-FIbtbEJ{<uRE9{8pN-;bN7CSy>;nSoP6=<(bY%PJS4RoeR$L|+aL!!
zA=*3MPc}fDv(MW#10#VRS&Z!>$>Qx_-M^G(a<qf(^=c9l7Vel9?)x at 6x^&Znf?$Rq
zp5zmI{^;eVr|Rkn%23)y(gPee$@mN_5a7~!zfh}qyxc5=jA+Mxcd>7Cd3iQzOl4uh
zsf918tD~gtqe_Yh`tHTkH7nUv8UF^m&K(mOnZCZ~E}~?g*g0rlDJVe+B4U*Z=phIK
zUU{JlIzi at yWyI)9CRcxa>L0x!PMcGhkI$j&9p8zos;a7wk7P^tY0L|&kf<4$(Y{x?
zugXP+ugmV++uLX~I&mN+C1rS6t2rGGBQE!T$}0LZkN40VcE~Lkp3lq0rQ7JS-tc0T
zl1=)<)7y$oT+wrWetzui>?^CQ!S7B^`~m{b>+0&>y`vA|+k!Q%Z11d?)5z1%(gp?w
zer{`{=hG8OS$_&sfevOp2oZIf<`rq)?qrT(yLUVjNENhNF<$$LXZt;>i;;nt?anHX
z95Xo)L!^$rexX+3knIaY!}K2RkSnO?*{XSDR8&bYWDs at OL-suprl>@CVCzo_XqFoB
ziQaUnqrl}g9yu#ZOGz_4P8z>WN=!TxlUHj@(ok6`%)?XI)YMc|#49XZSy*UiK7sD*
zJO3Ub(9qauXJ^-AS^3pSOKW&yLSIjhiI#TvJ^gi=QlF-#<7>aHt*za)8}3F3hfr7e
z?5}{A*^gpq3X>=fFCPz%&=fIyx16p!2 at 46$yLxMBz1zo~<1y#WXUD5ouU at sVun@3)
zJ-b_i>bmT<w^e^;KkU60Q at k2evzXo^NktaJ&}(@?C&XNmtXk6F=NVa9U^R;D-`U<j
z-2c$2Rf6j3YP7jfd7-mYdU|>Z<I?hAUajMlYmW|Fw`n<X*BaFAcyHM>iQw~#y`^Vo
zrn-V!&VQ{r7WJg43LRd5e}7Z$S@?~YhqGYYe0+S;B*P!FGm1G*COdhUn0zu9iaN3^
z&L3Lwoc7LZXc*7WF0-7hbFn{7U!I%0`KR(m9 at -r?E*s&Gemo>z5J%5((1fM3W%hp>
z<Ndw5c9*rWvC*%wpG|UebsZQSJhIpbD3X%0-?Ptf at f-CSx%B2i-e3m`#mUL34zshh
z)zjBM@;DyEM6tZ at uk`NRmJ^za`D?-QLFQ*#14)DB*TP4?Gor4b-JgVog|)V}Ha9m%
z(DTtW($jl?+HS=l9G5o(&V8+{7C(njsb$LWdGPV>yqXJ?7(8|N at UXP7(A3sehpDTp
zmm0T}XmEG%heN<(1g#n}e=7{Djmi2#?b6=f-i3+ak?Y0A_U at xgW72bnW&4J-0*MHO
zE*x%pYT;2vPfsuEw$QDfry6D$TKK&8clvntRQakwv!AZc#?n%m4G9%hrie{Eu|;`S
zVd0a~5i+qWL_`_V-lqP3mfgv-k#<bwM4Kt0Ki#>ry*5@!seN>O{PO(t08}17e;BKw
zq2cW8tnA5F;OFYWJT)g9o98Q0k2qV$iik-`NsX#jl3GrXVyJlP_Zr;bU7s0>PY>r}
zK0 at AIa?91B7clbMn3PDRx~_zTe>B>}qB(-xU%dEuw2(>^*m{fxn at r2h?7KdGSKu*p
zLD^+(vVIWyjs<nPqTM3TO9Fu*U3V9HMBUzWn2y!E<t4SpoAlDf^;CtC45su{Ej!Rc
zThqAMS8Zr%b17171}C7(KTD_^L@)@Hl$PctnzmJODyOobyeEPlH?5y`Z)|L=j+90i
zcDMn#IzL3o5<|cyHh6AMfAl?QFA3%2(JB)6I}}9jogQFXytdzuVx`3##;ay#OctZ%
zK0Y=x%XW)_dWD3ClUm7YZ+ik+ZCbV0`s8A8|Ng5{&6800ie`Y^N19y9-b$-J101WT
zfQse)`}aLPYezL-r6NQf#t$$7n<?eLb;*CM%zxOr|CYA@<qU6xz8jlbEpkpy(Zw%A
z1_lOd?8n*!7U$=4^710|sUqVw)(B1Pm)si;4-e<(&0#hwDk^q%g`?M6KbZ9HQNxfG
zIXUL*<JGIf#Zq2dzsP6JOlWdz`ugJQ-4?~8 at e8R=8<>_GG&F6c-^F`D)3LL^Z*I<@
z9{Bc+j+ND+T!$Ev2(Q*F9$768DO>JynasH7OL*}jIE979El3U$d5fRF7lV<NmBqZp
zZ^Xqa_r)bAUuR)qp{K90?q|<(>5OD_aB#>BIP-q_ at +|ZGWO1U_3Dw!TQ+OK*O<4Y#
z^&nNu2^!R$E+xjzU67mmhI(hc7Ne-3 at Ns`we|VyHS&jJFZMyaK^$<$d?`k>1!oonB
z4ww3~%gO{t)+#u&r*q27<1njXw4C9FU89A?#hPH8R5z5As9K*aWyiR>xq+8s_F%}=
z*Vm_tI=oL at ac|h#a?aO)5yvTU_*s24D($zvjbs+J7Y{g-MrwGy89m?(O75|I$%j#a
zCNM at R!tz^9wtmgi($JtgKgs{_!5OE+=5_dHrWNgXa_FL?qob}qh<uU+Rm+$h8$;LL
zkbODX*S9&SCW}nmn5gXo$AzWM?-PkGUHUdOw7<9aZFpEO&w8#iYG`PPjDdgNiL`JH
zuaAi^9<~<g=;%<)F8}a>7|n8vO4{$i){J>>PR`nBd7yD`SJx926>Jjd2A;RD8!~=M
zTn<i7U{Zn|PaK$P^i)d|e};sEz3!4!U}a^Mlas?@u_r3e-}(pO&5b_#+!Yno;!j${
zVj+m^`PU&%#B6EZ<))&kgM))WaN7BU6iSq#(|2Ekx=854g2e$5H68iB9;@sX4d?bC
z*}B<eNB9>Y$z2pgDCg(rn`&=ofBUA9fadVH=17j-W6{*qWQuxIw!Mr)2wQ1sYSzCr
zh<R=96CEBNewmD(THamKP*Za#n2dpmnHh+?yJY%mgl?IMoPt8|Dr*0_QtqO)qhoYr
zB!|G6d!q^XuHb91phz(9?d|OJ>zuP%S^@x;xVZ^Kg68T}QbobcS>8YX`t at sbvy8lw
zlarIR^-{5Z?VF`OCqW^hoiA^B_$NH6=GVlO5#Pr$MPgx~>>k%i_~O>QcNZkqB%Zeg
z#mCc}370e-?Jg$0dxzWKPnYqRl#$5*l*GluGbhWKnwI7_^XURCU#rlt+_d8fULAJj
z$`vF$ztTgK<B&YI(#t~#Ku}|2<B>&3rXvH3gzNm2Cx(KYocH$a8U4<f8v-X*e10bW
z&d#yMzRLqhF7 at 2Ky**`wQ1H1k=IbdJQY}N8goMQ9`*e8gTXg$a(V~))Qr(MHdPvUy
zfts#dD at DalY*$iWx|Ft#&absiyS-9KB$6obHJrOC_e(%!5Ver!#w7R*UgPGID6#2e
zVXNLJcv|`K at o~$Z6m0j at zB9PWN>83NI?ob9IHaU}ds6O#frXIr+*lbZtgNhb at YxA?
z4uwJ;G0o{tTmk~61qJYYjo|=4y@?u!32>ci9VSG(&!VED>b|2ti2K4V!>uxVC at CpH
zsfHSM#K7V3A~nZ*7iIb>Z$jR}jtXCvy-J5o(*3}of17RpYYO_$`8p10XM6w1NK$Gl
zkH at tcOSXGH^A+VyB8bz|)8OD>Q|${|^5UtNP2xOz5P&Jb^rvqOe^&3lJaCFXP=~{R
zv<$e^Hnz4q+uOS3roqZkx9R&%%}2SrqP=ssk-cmeJD(~lDjFJ2fyvy#A0z=y;Ns?9
z0T at dkVKJDif<M?~Xng;yb&S_5w6x{y7;}DB+hGa`@;kyNQL#x=gTKiMwbCXl=Ysae
zAD$fgZES9ypKb;SI6lq}GXI&gEJM(HL&kv}F at v**DrYpRr7A(|?%_!i7KaC+ at gy5P
z=0fXZl_At^V=k*UgN at UDm-@0tRu}s+WdqLq&K71rhvX?EcBXwdx5e<s$K95d581Dl
ze!AL*M>rB~T2b=-^pnY0g~g+2maC1i{cXR`bHBqke={--#3&d3=9_hQId-wRs_6wI
zt0WMhO+Z<IrU%6W at dsKTX2=xzx~i&*PrqiXOF}|od3pJyV(XsTYA+>o`UOm%Uwuwa
z&YL%HYNvfx54Y!N!sh4E3A(zv6ciKy6ikzd%<lhRVmu>@7li;sBTp7Kj#h(0=10rT
zz_~e9(|!ul;Y^qlzi}foG&J=1*hgLofS<d&NWeB3EMKp9A<y8oN<j1+Zf%VA`t=X+
zd~O~d5(pn3pNosj+1VKooRTSRryLFLCotG>iD9GTR72nuDsDQ`avt^|YWZ1<<KyGD
z&z~C`8t6znz`kE2Rq*umR9220v!_2!?pf&U?ELWI_SpiErow`P+eiihBZCTa66Cjq
zr}|*>u!uW<vKGmZaD$47B*F{&t$}iq69sA&R at a*WJ_jU|a4;IBk}L?hdDHBYXWBhq
zT$A_i+61d*`{h<Sp%4qOVW3U*oBbq^B3xWHc-%UGszvSP|26iqjY>zXMG^-nm_^fM
z12XjPy~CZ7K;(Ztauh;zTZ_P96hs%}k6?=Ly2r=$!2H)LTwPhQ*McCFdHDI+#2gJ=
zT<#z>3Wu6;<92zf>EE?4|NV56HDMNWEGj86s&j?}sOwl at FvmtG6^hwh{QRO!Q3?tQ
zN((%UazbEI0!|qI_6>9t5}m;5>EWSQsvv~$IM^_h|2198^EMK&gKK?S=HP8)qvvLZ
zxXXJOa=h9uY5(GIfB#iFIt?SEUJRYq*g>t@!cd{MnVA{Z)!WF3?Z?t%yAu-=S*1L-
zy1c!;!KgZ^_}qdwz at dIB`HJPGkH9jt94hGQB1%g)uRGFfFEOQ{46?{JQ^YT$TwLp$
z8XA1;%}Ay%qTNZ;!am&w#QqQdyp*84*IxAec%%jN<f7BrZsz&g`no>=^I*!$moJx>
zm$PeL>HXQfLX|!4gGNDHoBXQ44X~U at YSVI^_t`%l3VhUQgjSV~KZ%KHLldsb^U5j^
z9|1UbcxlHdeUVK=jGBezBo%Ygxo{5-s?}yNS2uI`XHH;%F3LLS1w0=yEvKWSGilq?
z at G_VR{1bK0K at g6gea72^mbbUQHc&kOaYT_**PY0`yt$dA#9>*f%b!$gP!C^o)%i9t
z;XB)Qc{pRJ1wXY3X2UIyYXn>Bz*LqV_t>QM5SA?+S-q;LsL<ek8;T@|oNo5Vv){a_
zU95M at 0}@2NgOWYl4!QC2`j~%ai!2UIJe5ot|40}i^%Zq(W`wl&4p2!F2squ7Bz}J+
z{<}T>KbPYFhuY`T>KenR?s~Ggt!aFBh*d`Yfv%)HA<+(g^w5wT?G6%-{H(0k)UJTp
z!XCQr%s-Y_dhp<)9fQziwP15eD97&K1VUB?igJ;WkpUKKe}6wHHa9nSY03I5Y4<kL
zwmK!#^|I)xMD#?Zm70mkFEC_5Q4vQFkgxWRjw3vNadB~C#0}7$gxf+SvzTgfV~KG~
zMr^F$%ag;gN-IpAOCV-}Gt=+=)7$d$@<3b2NJ$f6*qp}+1%-u2)j(c=$N;GUf<sw*
zpLnd%)9LBc*e(5Z(eoWL%8=<Qn}p0v%%}|MePRg4|6r=nsAxD4tTH$x#Ph`qF1qkM
zwM=fhaNwl?h*ysB?%hf40h9XKvu7tgZ+Wx<l0Ab77&X<IqiJAVkanNcVbJ(jC|LxV
zqO5w;NGK?fiMAps at 87crw*E3?>#(83l at 5}T#ms=|krB=+YZ0bmt%<?G>>*oP8k$1~
z+iJb+elOgbuCcN4a|vGFNMjy*<LrL%NkXK1TM)^uTelRm<65{hObz2dXLWt~QbZN4
z1659rjf;bLT$3dwBb)nt_h%ltn+Sm_`>_g#i5foR<}`RpVq%p)9=E?bvRep%(aWn&
zgZoyH5(iE5v(k~>zQf;CD|H=!P0-?<AEdtREqI+AhfYMB1M8X_yonhc1Odf*txcuB
zd}x_JLV3ZNEOFrGqv$65M&s+(uR)XUT}Hc$@6F82C`Iq+>?WIkx5ov?$H(I~F`3E9
zO2oQNUfY>xdz`ZxqO!8*5dzIi8yh9X#dlMC{LIYF=ZkbJ&v3OZQ_cRMje>_$T}Lqs
zNlm7vreD5%@$vP2^5n^SL|8-w4;L5cz1n3b5vCt%(b?WU>NI$k)E2b9d&=qvRD5m+
z+qKx6&cn-F)m*9!oiir#?PonY_cU31-dpAJ4_as-j+*%4hQnwzxre~?2^}&Y_y;L$
zW at z!-Ul|%5)u}hgNJ at INw$MF1JRB5s>1?d87St)&Lxgf}zcu*p1?SY^uAtbaCh2+u
zHemGkS2RQPe>s;5^EurgIoO!8`<M=3`WTPj6$@e0Ghh?8Vn>*v?M3tQ@~FtkLk&YO
zt_7j;rJ)G%i;Ti7C^U9wWyKbhLb=_A+7R<-Mq7WPHnz^Li_Bh^iT^9j|DPtM{XFL{
z7e0NuudSUV47=djF3Xq*LyiW6NML+o0>3r;V3FbuXiySbsJIip=FO4a7J!SALXuba
z^lKe04n}5x>Rn at ImhzAy+pzt!E4ksf^?Ee8uI<yOPe2$Agol4kK%}Hd)*xR=9j{gP
z$v=1iI=h{}{Ti6s2Je)c2rvC{nENj!FispjFYegw>qC`*o?k01&dbeBQHJJGUU)#u
ziAaP$>wF;~aBQ4kPyoyBr<VVxs`$~JujLeM)ALHexNV`p9TXK5xK5W)0LA(HD4B6;
zqwZ!}PebNktsCf!L$X{}*_Q_FacR=t at zeufzs9DeoeWer0j1wPe*zo;n~a~1weg?*
z9FOOh6xBSyI1SFT@?bQps6?se-OQd~^_-tHFVHB!;c#w?y)G;VJz|*2mH=4}jv$>L
zA{G=NR!%{|r%1S_mex)bSk-Uf<<|uy0q72}RI<Rq0mvXPx3FVD`R|}PNrTxrIC8+W
z`sJ7V`5LMzB99L<-~NsAjv20*Vb+b$kG1XXd5zgxZUV9Z=6mnpASNcp$<dLmcM0cN
z&X|r7Lb>41x5dQ79w{o)6mqVXo1t7?T~*V><ydYF&gxA^G777vODYfplcxlS$A4vG
zWc0><d8_SThYJ5|Ecv$_{nsTA)W?qlntUJ#mrUz@{P-~gzkw1A_NA}SxWXJHR&(d4
znDg!P!fjUK|E0oM=DSQP&z{A#ntZjb_EU>e1d8kH<5Q*QATQrWtzV-^+;3a0nEfLW
z1Tfv^s-u(q6=g3fCMx<PJo#`P?+7-Q7x30~a==@D-r&ZB03YA_>Z+9gvAdt&iL+vD
zOT_6?+p`Mb&{Uwb$g0v(0cq(bkU(ZVmG(c@$a?DT>4|D at 2gI6Gf~^ez90?>OqGJa)
z;e-KU!*v&D=cn9nDHkE{y0A=9mg4t}hrnVMdr~<kS$Z}i-&*x$T-7!l8mLGAeh?$8
zlDi*=WiS^)^jqg7GLaKCKeGnpAJ>I_U_WMwDH3xOj{W<a0Xy$a*BZx?#9p3w%?j at L
z8%Z{t8m{4+mcp*FuuM)(^#}-nP#KVKSCT+pBJ|cR2TZg7>G8gNU)IRZgmJm4f`^9(
z3>Lm0`WLq?-ax^5tFop>3&8ErN<)KWmP>o1u$D9 at 0u^)PV0Rb4H>k#i1Ydg>9Iq6X
zE~zEh7?QU90*E{!0_=w%*EZh?ucX~@5v0bx(&+*3mA^yaaZWj%n$6BW#4xreRjjnC
z>YIrmd4M~<ar7V#Z4SI$nQQ^TA_qsug`|jx2viiawt;~%7s#qgKjOyo)$@Wf9+YAq
z)q8ETL*~Jqr0SBa`g(7G$+!m-Zi>H0&e5)(o#BfdyBkxD at ccdC>=FlXIFEdd at o(QA
z8o%oX<`o!^FW4QR_08o-q(XN8uOQr4bOU+OU)KL4X8qnC#{JfIq{Q$6$6)gW-~~Xc
zSl6S4o>bt8xsc~aeE~oQ2nh)fZ%U-~uWy=StU$5|hy|xs3ZnJ%S*if)XhFz4u(*i>
zH8rC32EBcYpLOk8EV8hbeKJz6^Tez~Rvf~&ZdstBSx;PzjErn;xm%>aPciajBq&o2
zV=%@#I at YHlv0dbplsi^-y$SL0LgM1$X&JqEsRX$a<ptu>{tYaMsFXPF+_?jikCGdP
z+;8<-+}Fr^r)8Sx;w5P4G7||nKXXzL{1?&&kv2P~$tLfF79~b62~hoOW5NR7LVGw|
zgMHCes2jLaC)M)=dp at VWn;$tnu4OE|O^^VQG;s6dj9?PjIyl at 4YDb|W3`19mTU_Qf
zO4GVyW2w(-5d_2#FClRfqYH%p`aa)pqoGe$Y+`I|tiK;(%0<A|X<8n6*xZ+J1iXhI
zZ}^2*cV1QM{@JF)%Xn?wUt=PWPJ`$B4K<#~HrpL{hvd3L!0lIp#|o+sOXN*{{vZCR
Bvx)!!

diff --git a/docs/html/index.html b/docs/html/index.html
deleted file mode 100644
index d037652..0000000
--- a/docs/html/index.html
+++ /dev/null
@@ -1,89 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Wayland</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><meta name="description" content="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."><link rel="home" href="index.html" title="Wayland"><link rel="next" href="pr01.html" title="Preface"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Wayland</th></tr><tr><td width="20%" align="left"> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="pr01.html">Next</a></td></tr></table><hr></div><div class="book"><div class="titlepage"><div><div><h1 class="title"><a name="idm140152836716704"></a>Wayland</h1></div><div><h2 class="subtitle">The Wayland Protocol</h2></div><div><h3 class="corpauthor">
-    <span class="inlinemediaobject"><img src="images/wayland.png" alt="Wayland logo"></span>
-  </h3></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Kristian</span> <span class="surname">Høgsberg</span></h3><div class="affiliation"><span class="orgname">Intel Corporation<br></span></div><code class="email"><<a class="email" href="mailto:krh at bitplanet.net">krh at bitplanet.net</a>></code></div></div></div><div><div lang="en-US" class="legalnotice"><a name="idm140152828077856"></a><p>
-      Copyright <span class="trademark"></span>© 2012 Kristian Høgsberg, Intel Corporation
-    </p><p>
-	  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:
-	</p><p>
-	  The above copyright notice and this permission notice (including the next
-	  paragraph) shall be included in all copies or substantial portions of the
-	  Software.
-	</p><p>
-	  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.
-	</p></div></div><div><div class="abstract"><p class="title"><b>Abstract</b></p><p>
-      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.
-    </p></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl class="toc"><dt><span class="preface"><a href="pr01.html">Preface</a></span></dt><dt><span class="preface"><a href="pr02.html">Acknowledgments</a></span></dt><dt><span class="chapter"><a href="ch01.html">1. Introduction</a></span></dt><dd><dl><dt><span class="section"><a href="ch01.html#sect-Motivation">Motivation</a></span></dt><dt><span class="section"><a href="ch01.html#sect-Compositing-manager-display-server">The compositing manager as the display server</a></span></dt></dl></dd><dt><span class="chapter"><a href="ch02.html">2. Types of Compositors</a></span></dt><dd><dl><dt><span class="section"><a href="ch02.html#sect-Compositors-System-Compositor">System Compositor</a></span></dt><dt><span class="section"><a href="ch02.html#sect-Compositors-Session-Compositor">Session Compositor</a></span></dt><dt><span class="section"><a href="ch02.html#sect-Compositors-Embedding-Compositor">Embedding Compositor</a></span></dt></dl></dd><dt><span class="chapter"><a href="ch03.html">3. Wayland Architecture</a></span></dt><dd><dl><dt><span class="section"><a href="ch03.html#sect-Wayland-Architecture-wayland_architecture">X vs. Wayland Architecture</a></span></dt><dt><span class="section"><a href="ch03.html#sect-Wayland-Architecture-wayland_rendering">Wayland Rendering</a></span></dt><dt><span class="section"><a href="ch03.html#sect-Wayland-Architecture-wayland_hw_enabling">Hardware Enabling for Wayland</a></span></dt></dl></dd><dt><span class="chapter"><a href="ch04.html">4. Wayland Protocol and Model of Operation</a></span></dt><dd><dl><dt><span class="section"><a href="ch04.html#sect-Protocol-Basic-Principles">Basic Principles</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Code-Generation">Code Generation</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Wire-Format">Wire Format</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Interfaces">Interfaces</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Versioning">Versioning</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Connect-Time">Connect Time</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Security-and-Authentication">Security and Authentication</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Creating-Objects">Creating Objects</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Compositor">Compositor</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Surface">Surfaces</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Input">Input</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-Output">Output</a></span></dt><dt><span class="section"><a href="ch04.html#sect-Protocol-data-sharing">Data sharing between clients</a></span></dt></dl></dd><dt><span class="chapter"><a href="ch05.html">5. X11 Application Support</a></span></dt><dd><dl><dt><span class="section"><a href="ch05.html#sect-X11-Application-Support-introduction">Introduction</a></span></dt><dt><span class="section"><a href="ch05.html#sect-X11-Application-Support-two-modes">Two Modes for Foreign Windows</a></span></dt><dt><span class="section"><a href="ch05.html#sect-X11-Application-Support-architecture">Architecture</a></span></dt><dt><span class="section"><a href="ch05.html#sect-X11-Application-Support-xwm">X Window Manager (XWM)</a></span></dt></dl></dd><dt><span class="appendix"><a href="apa.html">A. Wayland Protocol Specification</a></span></dt><dd><dl><dt><span class="section"><a href="apa.html#protocol-spec-wl_display">wl_display
-	- core global object</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_registry">wl_registry
-	- global registry object</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_callback">wl_callback
-	- callback object</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_compositor">wl_compositor
-	- the compositor singleton</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_shm_pool">wl_shm_pool
-	- a shared memory pool</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_shm">wl_shm
-	- shared memory support</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_buffer">wl_buffer
-	- content for a wl_surface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_data_offer">wl_data_offer
-	- offer to transfer data</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_data_source">wl_data_source
-	- offer to transfer data</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_data_device">wl_data_device
-	- data transfer device</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_data_device_manager">wl_data_device_manager
-	- data transfer interface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_shell">wl_shell
-	- create desktop-style surfaces</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_shell_surface">wl_shell_surface
-	- desktop-style metadata interface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_surface">wl_surface
-	- an onscreen surface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_seat">wl_seat
-	- group of input devices</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_pointer">wl_pointer
-	- pointer input device</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_keyboard">wl_keyboard
-	- keyboard input device</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_touch">wl_touch
-	- touchscreen input device</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_output">wl_output
-	- compositor output region</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_region">wl_region
-	- region interface</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_subcompositor">wl_subcompositor
-	- sub-surface compositing</a></span></dt><dt><span class="section"><a href="apa.html#protocol-spec-wl_subsurface">wl_subsurface
-	- sub-surface interface to a wl_surface</a></span></dt></dl></dd><dt><span class="appendix"><a href="apb.html">B. Client API</a></span></dt><dd><dl><dt><span class="section"><a href="apb.html#idm140152827541248">Introduction</a></span></dt><dt><span class="section"><a href="apb.html#Client-unionwl__argument">wl_argument
-                - 
-Protocol message argument data types.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-structwl__array">wl_array
-                - 
-Dynamic array.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-classwl__display">wl_display
-                - 
-Represents a connection to the compositor and acts as a proxy to the wl_display singleton object.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-classwl__event__queue">wl_event_queue
-                - 
-A queue for wl_proxy object events.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-structwl__interface">wl_interface
-                - 
-Protocol object interface.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-structwl__list">wl_list
-                - 
-Doubly-linked list.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-structwl__message">wl_message
-                - 
-Protocol message signature.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-classwl__proxy">wl_proxy
-                - 
-Represents a protocol object on the client side.     </a></span></dt><dt><span class="section"><a href="apb.html#Client-Functions">Functions</a></span></dt></dl></dd><dt><span class="appendix"><a href="apc.html">C. Server API</a></span></dt><dd><dl><dt><span class="section"><a href="apc.html#idm140152826989984">Introduction</a></span></dt><dt><span class="section"><a href="apc.html#Server-unionwl__argument">wl_argument
-                - 
-Protocol message argument data types.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__array">wl_array
-                - 
-Dynamic array.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__buffer">wl_buffer</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__client">wl_client</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__display">wl_display</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__event__loop">wl_event_loop
-                - 
-An event loop context.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__event__source">wl_event_source
-                - 
-An abstract event source.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__global">wl_global</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__interface">wl_interface
-                - 
-Protocol object interface.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__list">wl_list
-                - 
-Doubly-linked list.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__listener">wl_listener
-                - 
-A single listener for Wayland signals.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__message">wl_message
-                - 
-Protocol message signature.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__object">wl_object</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__protocol__logger">wl_protocol_logger</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__protocol__logger__message">wl_protocol_logger_message</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__resource">wl_resource</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__resource__iterator__context">wl_resource_iterator_context</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__shm__buffer">wl_shm_buffer</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__shm__pool">wl_shm_pool</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__shm__sigbus__data">wl_shm_sigbus_data</a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__signal">wl_signal
-                - 
-A source of a type of observable event.     </a></span></dt><dt><span class="section"><a href="apc.html#Server-structwl__socket">wl_socket</a></span></dt><dt><span class="section"><a href="apc.html#Server-Functions">Functions</a></span></dt></dl></dd></dl></div><div class="list-of-figures"><p><b>List of Figures</b></p><dl><dt>3.1. <a href="ch03.html#idm140152825430224">X architecture diagram</a></dt><dt>3.2. <a href="ch03.html#idm140152825611760">Wayland architecture diagram</a></dt><dt>5.1. <a href="ch05.html#idm140152827324336">Xwayland architecture diagram</a></dt></dl></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="pr01.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top"> </td><td width="20%" align="center"> </td><td width="40%" align="right" valign="top"> Preface</td></tr></table></div></body></html>
diff --git a/docs/html/pr01.html b/docs/html/pr01.html
deleted file mode 100644
index 9ab64a4..0000000
--- a/docs/html/pr01.html
+++ /dev/null
@@ -1,15 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Preface</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="index.html" title="Wayland"><link rel="next" href="pr02.html" title="Acknowledgments"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Preface</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="pr02.html">Next</a></td></tr></table><hr></div><div class="preface"><div class="titlepage"><div><div><h1 class="title"><a name="idm140152828117280"></a>Preface</h1></div></div></div><p>
-  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.
-  </p><p>
-  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.
-  </p><div class="literallayout"><p><br>
-Yours,<br>
-<br>
-        the Wayland open-source community<br>
-        November 2012<br>
-  </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="index.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="pr02.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Wayland </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Acknowledgments</td></tr></table></div></body></html>
diff --git a/docs/html/pr02.html b/docs/html/pr02.html
deleted file mode 100644
index 8e42784..0000000
--- a/docs/html/pr02.html
+++ /dev/null
@@ -1,8 +0,0 @@
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title>Acknowledgments</title><link rel="stylesheet" type="text/css" href="css/default.css"><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot"><link rel="home" href="index.html" title="Wayland"><link rel="up" href="index.html" title="Wayland"><link rel="prev" href="pr01.html" title="Preface"><link rel="next" href="ch01.html" title="Chapter 1. Introduction"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Acknowledgments</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="pr01.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="ch01.html">Next</a></td></tr></table><hr></div><div class="preface"><div class="titlepage"><div><div><h1 class="title"><a name="idm140152831142048"></a>Acknowledgments</h1></div></div></div><p>
-  TODO: Kristian has to fill up this with one or two paragraphs and a small
-  "thank you": http://en.wikipedia.org/wiki/Preface
-  </p><div class="literallayout"><p><br>
-Best,<br>
-<br>
-        Kristian Høgsberg<br>
-  </p></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="pr01.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="ch01.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Preface </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 1. Introduction</td></tr></table></div></body></html>
-- 
2.1.4



More information about the wayland-devel mailing list