specs: add dbelib and synclib. Remove trailing spaces

Signed-off-by: Gaetan Nadon <memsize@videotron.ca>

5 files changed, 1665 insertions, 135 deletions

diff --git a/specs/Makefile.am b/specs/Makefile.am
index 26cec9a..8986e3e 100644
--- a/specs/Makefile.am
+++ b/specs/Makefile.am
@@ -22,7 +22,7 @@
 #
 
 if ENABLE_SPECS
-doc_sources = dpmslib.xml shapelib.xml
+doc_sources = dbelib.xml dpmslib.xml shapelib.xml synclib.xml
 dist_doc_DATA = $(doc_sources)
 
 if HAVE_XMLTO
diff --git a/specs/dbelib.xml b/specs/dbelib.xml
new file mode 100644
index 0000000..83edf7b
--- /dev/null
+++ b/specs/dbelib.xml
@@ -0,0 +1,728 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
+
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="dbelib">
+
+<bookinfo>
+   <title>Double Buffer Extension Library</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <!-- <releaseinfo>X Version 11, Release 6.4</releaseinfo> -->
+   <authorgroup>
+      <author>
+         <firstname>Ian</firstname><surname>Elliot</surname>
+      </author>
+   </authorgroup>
+   <othercredit>
+      <firstname>Davide</firstname><surname>Wiggins</surname>
+   </othercredit>
+   <corpname>Hewlett-Packard Company</corpname>
+   <copyright><year>1989</year><holder>X Consortium, Inc and Digital Equipment Corporation</holder></copyright>
+   <copyright><year>1992</year><holder>X Consortium, Inc and Intergraph Corporation</holder></copyright>
+   <copyright><year>1993</year><holder>X Consortium, Inc and Silicon Graphics, Inc.</holder></copyright>
+   <copyright><year>1994</year><holder>X Consortium, Inc and Hewlett-Packard Company</holder></copyright>
+   <copyright><year>1995</year><holder>X Consortium, Inc and Hewlett-Packard Company</holder></copyright>
+   <releaseinfo>Version 1.0</releaseinfo>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 7</productnumber>
+
+<legalnotice>
+<para>
+Permission to use, copy, modify, and distribute this documentation for any
+purpose and without fee is hereby granted, provided that the above copyright
+notice and this permission notice appear in all copies. Digital Equipment
+Corporation, Intergraph Corporation, Silicon Graphics, Hewlett-Packard, and
+the X Consortium make no representations about the suitability for any
+purpose of the information in this document. This documentation is provided
+"as is" without express or implied warranty.
+</para>
+
+</legalnotice>
+
+</bookinfo>
+
+<chapter id="introduction">
+<title>Introduction</title>
+<para>
+The Double Buffer Extension (DBE) provides a standard way to utilize
+double-buffering within the framework of the X Window System.
+Double-buffering uses two buffers, called front and back, which hold images.
+The front buffer is visible to the user; the back buffer is not. Successive
+frames of an animation are rendered into the back buffer while the previously
+rendered frame is displayed in the front buffer. When a new frame is ready,
+the back and front buffers swap roles, making the new frame visible. Ideally,
+this exchange appears to happen instantaneously to the user and with no
+visual artifacts. Thus, only completely rendered images are presented to the
+user, and they remain visible during the entire time it takes to render a new
+frame. The result is a flicker-free animation.
+</para>
+
+</chapter>
+
+<chapter id="goals">
+<title>Goals</title>
+
+<para>
+This extension should enable clients to:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Allocate and deallocate double-buffering for a window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Draw to and read from the front and back buffers associated with a window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Swap the front and back buffers associated with a window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Specify a wide range of actions to be taken when a window is swapped.
+This includes explicit, simple swap actions (defined below), and more
+complex actions (for example, clearing ancillary buffers) that can be put
+together within explicit "begin" and "end" requests (defined below).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Request that the front and back buffers associated with multiple
+double-buffered windows be swapped simultaneously.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+In addition, the extension should:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Allow multiple clients to use double-buffering on the same window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Support a range of implementation methods that can capitalize on
+existing hardware features.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Add no new event types.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Be reasonably easy to integrate with a variety of direct graphics
+hardware access (DGHA) architectures.
+    </para>
+  </listitem>
+</itemizedlist>
+
+</chapter>
+
+<chapter id="concepts">
+<title>Concepts</title>
+<para>
+Normal windows are created using the core CreateWindow request, which
+allocates a set of window attributes and, for InputOutput windows, a front
+buffer, into which an image can be drawn. The contents of this buffer will be
+displayed when the window is visible.
+</para>
+<para>
+This extension enables applications to use double-buffering with a window.
+This involves creating a second buffer, called a back buffer, and associating
+one or more back buffer names (XIDs) with the window for use when referring
+to (that is, drawing to or reading from) the window’s back buffer. The back
+buffer name is a DRAWABLE of type BACKBUFFER.
+</para>
+<para>
+DBE provides a relative double-buffering model. One XID, the window,
+always refers to the front buffer. One or more other XIDs, the back buffer
+names, always refer to the back buffer. After a buffer swap, the window
+continues to refer to the (new) front buffer, and the back buffer name
+continues to refer to the (new) back buffer. Thus, applications and toolkits
+that want to just render to the back buffer always use the back buffer name
+for all drawing requests to the window. Portions of an application that want
+to render to the front buffer always use the window XID for all drawing
+requests to the window.
+</para>
+<para>
+Multiple clients and toolkits can all use double-buffering on the same window.
+DBE does not provide a request for querying whether a window has
+double-buffering support, and if so, what the back buffer name is. Given the
+asynchronous nature of the X Window System, this would cause race
+conditions. Instead, DBE allows multiple back buffer names to exist for the
+same window; they all refer to the same physical back buffer. The first time a
+back buffer name is allocated for a window, the window becomes
+double-buffered and the back buffer name is associated with the window.
+Subsequently, the window already is a double-buffered window, and nothing
+about the window changes when a new back buffer name is allocated, except
+that the new back buffer name is associated with the window. The window
+remains double-buffered until either the window is destroyed or until all of the
+back buffer names for the window are deallocated.
+</para>
+<para>
+In general, both the front and back buffers are treated the same.
+particular, here are some important characteristics:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Only one buffer per window can be visible at a time (the front buffer).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Both buffers associated with a window have the same visual type, depth,
+width, height, and shape as the window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Both buffers associated with a window are "visible" (or "obscured") in
+the same way. When an Expose event is generated for a window, both
+buffers should be considered to be damaged in the exposed area.
+Damage that occurs to either buffer will result in an Expose event on
+the window. When a double-buffered window is exposed, both buffers
+are tiled with the window background, exactly as stated by the core
+protocol. Even though the back buffer is not visible, terms such as
+obscure apply to the back buffer as well as to the front buffer.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+It is acceptable at any time to pass a BACKBUFFER in any request,
+notably any core or extension drawing request, that expects a
+DRAWABLE.  This enables an application to draw directly into
+BACKBUFFERs in the same fashion as it would draw into any other
+DRAWABLE.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+It is an error (Window) to pass a BACKBUFFER in a core request that
+expects a Window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+A BACKBUFFER will never be sent by core X in a reply, event, or
+error where a Window is specified.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If core X11 backing-store and save-under applies to a double-buffered
+window, it applies to both buffers equally.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If the core ClearArea request is executed on a double-buffered window,
+the same area in both the front and back buffers is cleared.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The effect of passing a window to a request that accepts a
+<function>DRAWABLE</function> is
+unchanged by this extension. The window and front buffer are synonomous
+with each other. This includes obeying the <function>GetImage</function>
+semantics and the
+subwindow-mode semantics if a core graphics context is involved. Regardless
+of whether the window was explicitly passed in a
+<function>GetImage</function> request, or
+implicitly referenced (that is, one of the window’s ancestors was passed in the
+request), the front (that is, visible) buffer is always referenced. Thus,
+DBE-naive screen dump clients will always get the front buffer.
+<function>GetImage</function> on
+a back buffer returns undefined image contents for any obscured regions of the
+back buffer that fall within the image.
+</para>
+<para>
+Drawing to a back buffer always uses the clip region that would be used to
+draw to the front buffer with a GC subwindow-mode of
+<function>ClipByChildren</function>. If
+an ancestor of a double-buffered window is drawn to with a core GC having a
+subwindow-mode of IncludeInferiors, the effect on the double-buffered
+window’s back buffer depends on the depth of the double-buffered window
+and the ancestor. If the depths are the same, the contents of the back buffer
+of the double-buffered window are not changed. If the depths are different,
+the contents of the back buffer of the double-buffered window are undefined
+for the pixels that the <function>IncludeInferiors</function> drawing touched.
+</para>
+
+
+<para>
+DBE adds no new events. DBE does not extend the semantics of any existing
+events with the exception of adding a new DRAWABLE type called
+BACKBUFFER. If events, replies, or errors that contain a DRAWABLE (for
+example, <function>GraphicsExpose</function>) are generated in response to
+a request, the
+DRAWABLE returned will be the one specified in the request.
+</para>
+<para>
+DBE advertises which visuals support double-buffering.
+</para>
+<para>
+DBE does not include any timing or synchronization facilities. Applications
+that need such facilities (for example, to maintain a constant frame rate)
+should investigate the Synchronization Extension, an X Consortium standard.
+</para>
+
+<sect1 id="window_management_operations">
+<title>Window Management Operations</title>
+
+<para>
+The basic philosophy of DBE is that both buffers are treated the same by core
+X window management operations.
+</para>
+<para>
+When the core <function>DestroyWindow</function> is executed on a
+double-buffered window, both buffers associated with the window are
+destroyed, and all back buffer names associated with the window are freed.
+</para>
+<para>
+If the core <function>ConfigureWindow</function> request changes the size
+of a window, both buffers assume the new size. If the window’s size
+increases, the effect on the buffers depends on whether the implementation
+honors bit gravity for buffers.
+If bit gravity is implemented, then the contents of both buffers are moved in
+accordance with the window’s bit gravity (see the core
+<function>ConfigureWindow</function>
+request), and the remaining areas are tiled with the window background. If
+bit gravity is not implemented, then the entire unobscured region of both
+buffers is tiled with the window background. In either case,
+<function>Expose</function> events are
+generated for the region that is tiled with the window background.
+If the core GetGeometry request is executed on a BACKBUFFER, the
+returned x, y, and border-width will be zero.
+</para>
+<para>
+If the Shape extension
+<function>ShapeRectangles</function>,
+<function>ShapeMask</function>,
+<function>ShapeCombine</function>, or
+<function>ShapeOffset</function>
+request is executed on a double-buffered window, both buffers
+are reshaped to match the new window shape. The region difference is the
+following:
+</para>
+
+<literallayout remap='Ds'>
+        D = newshape − oldshape
+</literallayout>
+
+<para>
+It is tiled with the window background in both buffers, and
+<function>Expose</function>
+events are generated for D.
+</para>
+
+</sect1>
+
+<sect1 id="complex_swap_actions">
+<title>Complex Swap Actions</title>
+<para>
+DBE has no explicit knowledge of ancillary buffers (for example, depth buffers
+or alpha buffers), and only has a limited set of defined swap actions. Some
+applications may need a richer set of swap actions than DBE provides. Some
+DBE implementations have knowledge of ancillary buffers, and/or can provide
+a rich set of swap actions. Instead of continually extending DBE to increase
+its set of swap actions, DBE provides a flexible "idiom" mechanism. If an
+application’s needs are served by the defined swap actions, it should use them;
+otherwise, it should use the following method of expressing a complex swap
+action as an idiom. Following this policy will ensure the best possible
+performance across a wide variety of implementations.
+</para>
+<para>
+As suggested by the term "idiom," a complex swap action should be expressed
+as a group/series of requests. Taken together, this group of requests may be
+combined into an atomic operation by the implementation, in order to
+maximize performance. The set of idioms actually recognized for optimization
+is implementation dependent.
+To help with idiom expression and
+interpretation, an idiom must be surrounded by two protocol requests:
+<function>DBEBeginIdiom</function> and <function>DBEEndIdiom</function>.
+Unless this begin-end pair surrounds the idiom, it may not be recognized
+by a given implementation, and performance will suffer.
+</para>
+<para>
+For example, if an application wants to swap buffers for two windows, and use
+core X to clear only certain planes of the back buffers, the application would
+issue the following protocol requests as a group, and in the following order:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+<function>DBEBeginIdiom</function> request.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>DBESwapBuffers</function> request with XIDs for two windows, each of which uses
+a swap action of Untouched.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Core X <function>PolyFillRectangle</function> request to the back buffer of one window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Core X <function>PolyFillRectangle</function> request to the back buffer of the other
+window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>DBEEndIdiom</function> request.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The <function>DBEBeginIdiom</function> and <function>DBEEndIdiom</function>
+requests do not perform any actions
+themselves. They are treated as markers by implementations that can
+combine certain groups/series of requests as idioms, and are ignored by other
+implementations or for nonrecognized groups/series of requests. If these
+requests are sent out of order, or are mismatched, no errors are sent, and the
+requests are executed as usual, though performance may suffer.
+</para>
+
+<para>
+
+An idiom need not include a <function>DBESwapBuffers</function> request.
+For example, if a swap action of <function>Copied</function> is desired,
+but only some of the planes should be copied, a core X
+<function>CopyArea</function> request may be used instead of
+<function>DBESwapBuffers</function>. If
+<function>DBESwapBuffers</function> is included in an idiom, it should
+immediately follow the
+<function>DBEBeginIdiom</function> request. Also, when the
+<function>DBESwapBuffers</function> is included in an idiom, that
+request’s swap action will still be valid, and if the swap action
+might overlap with another request, then the final result of the idiom must be
+as if the separate requests were executed serially. For example, if the
+specified swap action is <function>Untouched</function>, and if a
+<function>PolyFillRectangle</function> using a client clip
+rectangle is done to the window’s back buffer after the
+<function>DBESwapBuffers</function> request, then the contents of the new
+back buffer (after the idiom) will be the
+same as if the idiom was not recognized by the implementation.
+</para>
+<para>
+It is highly recommended that Application Programming Interface (API)
+providers define, and application developers use, "convenience" functions that
+allow client applications to call one procedure that encapsulates common
+idioms. These functions will generate the
+<function>DBEBeginIdiom</function> request, the idiom
+requests, and <function>DBEEndIdiom</function> request. Usage of these
+functions will ensure best possible performance across a wide
+variety of implementations.
+</para>
+
+</sect1>
+</chapter>
+
+<chapter id="c_language_bindings">
+<title>C Language Binding</title>
+<para>
+All identifier The header for this extension is &lt;X11/extensions/Xdbe.h&gt;.
+names provided by this header begin with Xdbe.
+</para>
+
+<sect1 id="types">
+<title>Types</title>
+
+<para>
+The type <function>XdbeBackBuffer</function> is a <function>Drawable</function>.
+</para>
+
+<para>
+The type <function>XdbeSwapAction</function> can be one of the constants
+<function>XdbeUndefined</function>,
+<function>XdbeBackground</function>,
+<function>XdbeUntouched</function>, or
+<function>XdbeCopied</function>.
+</para>
+
+</sect1>
+
+<sect1 id="c_functions">
+<title>C Functions</title>
+<para>
+The C functions provide direct access to the protocol and add no additional
+semantics. For complete details on the effects of these functions, refer to the
+appropriate protocol request, which can be derived by replacing Xdbe at the
+start of the function name with DBE. All functions that have return type
+<function>Status</function> will return nonzero for success and
+zero for failure.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XdbeQueryExtension</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>int <parameter> *major_version_return</parameter></paramdef>
+    <paramdef>int <parameter> *minor_version_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeQueryExtension</function> sets major version return and minor
+version return to the major and minor DBE protocol version supported by
+the server. If the DBE library is compatible with the version returned by
+the server, it returns nonzero. If dpy does not support the DBE extension,
+or if there was an error during communication with the server, or if the
+server and library protocol versions are incompatible, it returns zero.
+No other Xdbe functions may be called before this function. If a client
+violates this rule, the effects of all subsequent Xdbe calls that it makes
+are undefined.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>XdbeScreenVisualInfo *<function>XdbeGetVisualInfo</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>Drawable <parameter> *screen_specifiers</parameter></paramdef>
+    <paramdef>int <parameter> *num_screens</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+
+<function>XdbeGetVisualInfo</function> returns information about which
+visuals support double buffering. The argument num_screens specifies how
+many elements there are in the screen_specifiers list. Each drawable in
+screen_specifiers designates a screen for which the supported visuals are
+being requested. If num_screens is zero, information for all screens is
+requested. In this case, upon return from this function, num_screens will
+be set to the number of screens that were found. If an error occurs,
+this function returns NULL; otherwise, it returns a pointer to a list of
+<function>XdbeScreenVisualInfo</function>
+structures of length num_screens.  The nth element in the returned list
+corresponds to the nth drawable in the screen_specifiers list, unless
+
+element in the returned list corresponds to the nth screen of the server,
+starting with screen zero.
+</para>
+
+
+<para>
+The XdbeScreenVisualInfo structure has the following fields:
+</para>
+<literallayout remap='Ds'>
+int                     count      number of items in visinfo
+XdbeVisualInfo*    visinfo     list of visuals and depths for this screen
+</literallayout>
+
+<para>
+The <function>XdbeVisualInfo</function> structure has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+VisualID         visual    one visual ID that supports double-buffering
+int              depth     depth of visual in bits
+int              perflevel  performance level of visual
+</literallayout>
+
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void XdbeFreeVisualInfo <function>XdbeGetVisualInfo</function></funcdef>
+    <paramdef>XdbeScreenVisualInfo <parameter> *visual_info</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeFreeVisualInfo</function> frees the list of
+<function>XdbeScreenVisualInfo</function> returned by
+<function>XdbeGetVisualInfo</function>.
+</para>
+
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>XdbeBackBuffer <function>XdbeAllocateBackBufferName</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>Window <parameter> *window</parameter></paramdef>
+    <paramdef>XdbeSwapAction <parameter> swap_action</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+
+<para>
+<function>XdbeAllocateBackBufferName</function> returns a drawable ID used
+to refer to the back buffer of the specified window. The swap_action is a
+hint to indicate the swap_action that will likely be used in subsequent
+calls to <function>XdbeSwapBuffers</function>.  The actual swap_action
+used in calls to <function>XdbeSwapBuffers</function> does not have to be
+the same as the swap_action passed to this function, though clients are
+encouraged to provide accurate information whenever possible.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XdbeDeallocateBackBufferName</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>XdbeBackBuffer <parameter> buffer</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeDeallocateBackBufferName</function> frees the specified
+drawable ID, buffer, that was obtained via
+<function>XdbeAllocateBackBufferName</function>. The buffer must be a valid
+name for the back buffer of a window, or an
+<function>XdbeBadBuffer</function> error results.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XdbeSwapBuffers</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>XdbeSwapInfo <parameter> *swap_info</parameter></paramdef>
+    <paramdef>int <parameter> num_windows</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeSwapBuffers</function> swaps the front and back buffers
+for a list of windows. The argument num_windows specifies how many windows
+are to have their buffers swapped; it is the number of elements in the
+swap_info array. The argument swap_info specifies the information needed
+per window to do the swap.
+</para>
+<para>
+The XdbeSwapInfo structure has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+Window              swap_window    window for which to swap buffers
+XdbeSwapAction      swap_action    swap action to use for this swap window
+</literallayout>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XdbeBeginIdiom</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeBeginIdiom</function> marks the beginning of an idiom
+sequence. See
+<link linkend="complex_swap_actions">
+<xref linkend="complex_swap_actions"></xref></link>
+for a complete discussion of idioms.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XdbeEndIdiom</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeEndIdiom</function> marks the end of an idiom sequence.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>XdbeBackBufferAttributes *<function>XdbeGetBackBufferAttributes</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>XdbeBackBuffer <parameter> buffer</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeGetBackBufferAttributes</function> returns the attributes associated with
+the specified buffer.
+</para>
+<para>
+The XdbeBackBufferAttributes structure has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+Window           window           window that buffer belongs to
+</literallayout>
+
+<para>
+If buffer is not a valid <function>XdbeBackBuffer</function>, window is
+set to None.
+</para>
+<para>
+The returned <function>XdbeBackBufferAttributes</function> structure
+can be freed with the Xlib function <function>XFree</function>.
+</para>
+</sect1>
+
+<sect1 id="errors">
+<title>Errors</title>
+<para>
+The <function>XdbeBufferError</function> structure has the following fields:
+</para>
+<literallayout remap='Ds'>
+int                 type
+Display *           display       Display the event was read from
+XdbeBackBuffer      buffer        resource id
+unsigned long       serial        serial number of failed request
+unsigned char       error code    error base + <function>XdbeBadBuffer</function>
+unsigned char       request code  Major op-code of failed request
+unsigned char       minor code    Minor op-code of failed request
+</literallayout>
+</sect1>
+</chapter>
+
+<chapter id="acknowledgements">
+<title>Acknowledgements</title>
+
+<para>
+We wish to thank the following individuals who have contributed their time
+and talent toward shaping the DBE specification:
+</para>
+<para>
+T. Alex Chen, IBM; Peter Daifuku, Silicon Graphics, Inc.; Ian Elliott,
+Hewlett-Packard Company; Stephen Gildea, X Consortium, Inc.; Jim Graham,
+Sun; Larry Hare, AGE Logic; Jay Hersh, X Consortium, Inc.; Daryl Huff,
+Sun; Deron Dann Johnson, Sun; Louis Khouw, Sun; Mark Kilgard, Silicon
+Graphics, Inc.; Rob Lembree, Digital Equipment Corporation; Alan Ricker,
+Metheus; Michael Rosenblum, Digital Equipment Corporation; Bob Scheifler,
+X Consortium, Inc.; Larry Seiler, Digital Equipment Corporation; Jeanne
+Sparlin Smith, IBM; Jeff Stevenson, Hewlett-Packard Company; Walter
+Strand, Metheus; Ken Tidwell, Hewlett-Packard Company; and David P.
+Wiggins, X Consortium, Inc.
+</para>
+<para>
+Mark provided the impetus to start the DBE project. Ian wrote the first draft
+of the specification. David served as architect.
+</para>
+
+</chapter>
+<chapter id="references">
+<title>References</title>
+<para>
+Jeffrey Friedberg, Larry Seiler, and Jeff Vroom, "Multi-buffering Extension
+Specification Version 3.3."
+</para>
+<para>
+Tim Glauert, Dave Carver, Jim Gettys, and David P. Wiggins, "X
+Synchronization Extension Version 3.0."
+</para>
+</chapter>
+</book>
diff --git a/specs/dpmslib.xml b/specs/dpmslib.xml
index 1e29494..79fcffe 100644
--- a/specs/dpmslib.xml
+++ b/specs/dpmslib.xml
@@ -58,7 +58,7 @@ The United States' Environmental Protection Agency (EPA) Energy Star program
 requires that monitors power down after some idle time by default.
 While it is possible to simply overload the existing screen saver timeouts,
 this solution leaves the non-privileged user little to no control over
-the DPMS characteristics of his or her system.  For example, disabling 
+the DPMS characteristics of his or her system.  For example, disabling
 DPMS would require some unintended side effect in the core screen saver,
 such as disabling the changing of a non-blanking screen saver.  Providing
 clients with this control requires an extension to the core X Window System
@@ -110,13 +110,13 @@ These are mapped onto the X DPMS Extension like this:
 </variablelist>
 
 <para>
-The DPMSQueryExtension function queries the X server to determine the 
-availability of the DPMS Extension.  If the extension is available, the 
-return value is TRUE, and <emphasis remap='I'>event_base</emphasis> and 
-<emphasis remap='I'>error_base</emphasis> are set to the base event number 
-and base error number for the extension, respectively.  Otherwise, the 
-return value is FALSE, and the values of 
-<emphasis remap='I'>event_base</emphasis> and 
+The DPMSQueryExtension function queries the X server to determine the
+availability of the DPMS Extension.  If the extension is available, the
+return value is TRUE, and <emphasis remap='I'>event_base</emphasis> and
+<emphasis remap='I'>error_base</emphasis> are set to the base event number
+and base error number for the extension, respectively.  Otherwise, the
+return value is FALSE, and the values of
+<emphasis remap='I'>event_base</emphasis> and
 <emphasis remap='I'>error_base</emphasis> are undefined.
 </para>
 
@@ -146,13 +146,13 @@ return value is FALSE, and the values of
 
 
 <para>
-The DPMSGetVersion function returns the version of the DPMS extension 
-implemented by the X server.  The version is returned in 
-<emphasis remap='I'>major_version</emphasis> and 
+The DPMSGetVersion function returns the version of the DPMS extension
+implemented by the X server.  The version is returned in
+<emphasis remap='I'>major_version</emphasis> and
 <emphasis remap='I'>minor_version</emphasis>.
-The major version and minor version for this specification are '1' and '1', 
-respectively.  The major version will be incremented for protocol 
-incompatible changes, and the minor version will be incremented for small, 
+The major version and minor version for this specification are '1' and '1',
+respectively.  The major version will be incremented for protocol
+incompatible changes, and the minor version will be incremented for small,
 upwardly compatible changes.
 </para>
 
@@ -173,9 +173,9 @@ upwardly compatible changes.
 
 <para>
 The DPMSCapable function returns the DPMS capability of the X server, either
-TRUE (capable of DPMS) or FALSE (incapable of DPMS).  The capability of an 
+TRUE (capable of DPMS) or FALSE (incapable of DPMS).  The capability of an
 X server is implementation defined.  For example, if a multi-headed  X server
-is capable of DPMS on one head, and incapable on another, the truth value of 
+is capable of DPMS on one head, and incapable on another, the truth value of
 this function is defined by the X server implementation.
 </para>
 
@@ -211,47 +211,47 @@ this function is defined by the X server implementation.
 <para>
 The DPMSSetTimeouts function permits applications to set the timeout values
 used by the X server for DPMS timings.
-</para>  
+</para>
 
 <para>
-The value <emphasis remap='I'>standby</emphasis> is the amount of time of 
-inactivity in seconds before standby mode is invoked. The actual effects of 
-this mode are implementation defined, but in the case of DPMS compliant 
-hardware, it is implemented by shutting off the horizontal sync signal, 
+The value <emphasis remap='I'>standby</emphasis> is the amount of time of
+inactivity in seconds before standby mode is invoked. The actual effects of
+this mode are implementation defined, but in the case of DPMS compliant
+hardware, it is implemented by shutting off the horizontal sync signal,
 and pulsing the vertical sync signal.
-Standby mode provides the quickest monitor recovery time.  Note also that 
-many monitors implement this mode identically to suspend mode.  A value 
+Standby mode provides the quickest monitor recovery time.  Note also that
+many monitors implement this mode identically to suspend mode.  A value
 of zero disables this mode.
 </para>
 
 <para>
-The value <emphasis remap='I'>suspend</emphasis> is the amount of time of 
-inactivity in seconds before the second level of power savings is invoked. 
-Suspend mode's physical and electrical characteristics are implementation 
-defined, but in DPMS compliant hardware, results in the pulsing of the 
-horizontal sync signal, and shutting off of the vertical sync signal.  
-Suspend mode recovery is considered to be slower than standby mode, but 
-faster than off mode, however this is monitor dependent.  As noted above, 
-many monitors implement this mode identically to standby mode.  A value of 
+The value <emphasis remap='I'>suspend</emphasis> is the amount of time of
+inactivity in seconds before the second level of power savings is invoked.
+Suspend mode's physical and electrical characteristics are implementation
+defined, but in DPMS compliant hardware, results in the pulsing of the
+horizontal sync signal, and shutting off of the vertical sync signal.
+Suspend mode recovery is considered to be slower than standby mode, but
+faster than off mode, however this is monitor dependent.  As noted above,
+many monitors implement this mode identically to standby mode.  A value of
 zero disables this mode.
 </para>
 
 <para>
-The value <emphasis remap='I'>off</emphasis> is the amount of time of 
-inactivity in seconds before the third and final level of power savings is 
-invoked. Off mode's physical and electrical characteristics are 
-implementation defined, but in DPMS compliant hardware, is implemented by 
-shutting off both horizontal and vertical sync signals, resulting in 
-the power-down of the monitor.  Recovery time is implementation dependant, 
-but frequently is similar to the power-up time of the monitor.  A value 
+The value <emphasis remap='I'>off</emphasis> is the amount of time of
+inactivity in seconds before the third and final level of power savings is
+invoked. Off mode's physical and electrical characteristics are
+implementation defined, but in DPMS compliant hardware, is implemented by
+shutting off both horizontal and vertical sync signals, resulting in
+the power-down of the monitor.  Recovery time is implementation dependant,
+but frequently is similar to the power-up time of the monitor.  A value
 of zero disables this mode.
 </para>
 
 <para>
-Chronologically, standby mode occurs before or simultaneously with 
-suspend mode, and suspend mode must occur before or simultaneously with 
-off mode.  Therefore, non-zero mode timeout values must be greater than 
-or equal to the timeout values of earlier modes.  If inconsistent values 
+Chronologically, standby mode occurs before or simultaneously with
+suspend mode, and suspend mode must occur before or simultaneously with
+off mode.  Therefore, non-zero mode timeout values must be greater than
+or equal to the timeout values of earlier modes.  If inconsistent values
 are supplied, a BadValue error will result.
 </para>
 
@@ -285,25 +285,25 @@ are supplied, a BadValue error will result.
 </variablelist>
 
 <para>
-The DPMSGetTimeouts function retrieves the timeout values used by the X 
+The DPMSGetTimeouts function retrieves the timeout values used by the X
 server for DPMS timings.
-</para>  
+</para>
 
 <para>
-The value <emphasis remap='I'>standby</emphasis> is the amount of time of 
-inactivity in seconds before standby mode is invoked. A value of zero 
+The value <emphasis remap='I'>standby</emphasis> is the amount of time of
+inactivity in seconds before standby mode is invoked. A value of zero
 indicates that this mode has been disabled.
 </para>
 
 <para>
-The value <emphasis remap='I'>suspend</emphasis> is the amount of time of 
-inactivity in seconds before the second level of power savings is invoked.  
+The value <emphasis remap='I'>suspend</emphasis> is the amount of time of
+inactivity in seconds before the second level of power savings is invoked.
 A value of zero indicates that this mode has been disabled.
 </para>
 
 <para>
-The value <emphasis remap='I'>off</emphasis> is the amount of time of 
-inactivity in seconds before the third and final level of power savings is 
+The value <emphasis remap='I'>off</emphasis> is the amount of time of
+inactivity in seconds before the third and final level of power savings is
 invoked. A value of zero indicates that this mode has been disabled.
 </para>
 
@@ -374,7 +374,7 @@ without support for DPMS, no change is made and no error is returned.
 
 <para>
 The DPMSForceLevel function forces a DPMS capable display into the
-specified power level.  The <emphasis remap='I'>level</emphasis> must be one of 
+specified power level.  The <emphasis remap='I'>level</emphasis> must be one of
 DPMSModeOn, DPMSModeStandby, DPMSModeSuspend, or DPMSModeOff.
 Values other than these will result in a BadValue error.  If DPMS
 is disabled on the display, a BadMatch protocol error will result.
@@ -408,13 +408,12 @@ is disabled on the display, a BadMatch protocol error will result.
 
 <para>
 The DPMSInfo function returns information about the current DPMS state.
-The <emphasis remap='I'>state</emphasis> return parameter indicates whether 
-or not DPMS is enabled (TRUE) or disabled (FALSE).  The 
-<emphasis remap='I'>power_level</emphasis> return parameter indicates the 
-current power level (one of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend, 
+The <emphasis remap='I'>state</emphasis> return parameter indicates whether
+or not DPMS is enabled (TRUE) or disabled (FALSE).  The
+<emphasis remap='I'>power_level</emphasis> return parameter indicates the
+current power level (one of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend,
 or DPMSModeOff.)
 </para>
 
 </chapter>
 </book>
-
diff --git a/specs/shapelib.xml b/specs/shapelib.xml
index 376db60..2a2fd8f 100644
--- a/specs/shapelib.xml
+++ b/specs/shapelib.xml
@@ -24,11 +24,11 @@
 
 <para>
 Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files 
-(the &ldquo;Software&rdquo;), 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 
+of this software and associated documentation files
+(the &ldquo;Software&rdquo;), to deal in the Software without restriction,
+including without limitation the rights to use, copy, modify, merge,
+publish, distribute, sublicense, and/or sell copies of the Software, and
+to permit persons to whom the Software is furnished to do so, subject to
 the following conditions:
 </para>
 
@@ -38,12 +38,12 @@ all copies or substantial portions of the Software.
 </para>
 
 <para>
-THE SOFTWARE IS PROVIDED &ldquo;AS IS&rdquo;, 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 X CONSORTIUM 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 
+THE SOFTWARE IS PROVIDED &ldquo;AS IS&rdquo;, 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 X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR
+OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 OTHER DEALINGS IN THE SOFTWARE.
 </para>
 
@@ -58,19 +58,19 @@ in this Software without prior written authorization from the X Consortium.
 <chapter id='overview'>
 <title>Overview</title>
 
-<para>This extension provides arbitrary window and border shapes within 
+<para>This extension provides arbitrary window and border shapes within
 the X11 protocol.
 </para>
 
 <para>
 The restriction of rectangular windows within the X protocol is a significant
 limitation in the implementation of many styles of user interface.  For
-example, many transient windows would like to display a 
-&ldquo;drop shadow&rdquo; to give the illusion of 3 dimensions.  As 
-another example, some user interface style guides call for buttons with 
-rounded corners; the full simulation of a nonrectangular shape, 
-particularly with respect to event distribution and cursor shape, is not 
-possible within the core X protocol.  As a final example, round clocks 
+example, many transient windows would like to display a
+&ldquo;drop shadow&rdquo; to give the illusion of 3 dimensions.  As
+another example, some user interface style guides call for buttons with
+rounded corners; the full simulation of a nonrectangular shape,
+particularly with respect to event distribution and cursor shape, is not
+possible within the core X protocol.  As a final example, round clocks
 and nonrectangular icons are desirable visual addition to the desktop.
 </para>
 
@@ -94,23 +94,23 @@ window manager.
 
 <para>
 Each window (even with no shapes specified) is defined by two regions:  the
-<emphasis remap='I'>bounding region</emphasis> and the 
-<emphasis remap='I'>clip region</emphasis>.  The bounding region is the 
-area of the parent window that the window will occupy (including border). 
-The clip region is the subset of the bounding region that is available for 
-subwindows and graphics.  The area between the bounding region and the 
+<emphasis remap='I'>bounding region</emphasis> and the
+<emphasis remap='I'>clip region</emphasis>.  The bounding region is the
+area of the parent window that the window will occupy (including border).
+The clip region is the subset of the bounding region that is available for
+subwindows and graphics.  The area between the bounding region and the
 clip region is defined to be the border of the window.
 </para>
 
 <para>
-A nonshaped window will have a bounding region that is a rectangle spanning 
+A nonshaped window will have a bounding region that is a rectangle spanning
 the window, including its border; the clip region will be a rectangle
 filling the inside dimensions (not including the border).  In this document,
-these areas are referred to as the 
+these areas are referred to as the
 <emphasis remap='I'>default bounding region</emphasis> and the
-<emphasis remap='I'>default clip region</emphasis>.  For a window with 
+<emphasis remap='I'>default clip region</emphasis>.  For a window with
 inside size of <emphasis remap='I'>width</emphasis> by
-<emphasis remap='I'>height</emphasis> and border width 
+<emphasis remap='I'>height</emphasis> and border width
 <emphasis remap='I'>bwidth</emphasis>, the default bounding and clip
 regions are the rectangles (relative to the window origin):
 </para>
@@ -130,15 +130,15 @@ clip.height = <emphasis remap='I'>height</emphasis>
 <para>
 This extension allows a client to modify either or both of the bounding or
 clip regions by specifying new regions that combine with the default
-regions.  These new regions are called the 
-<emphasis remap='I'>client bounding region</emphasis> and the 
-<emphasis remap='I'>client clip region</emphasis>.  They are specified 
-relative to the origin of the window and are always defined by offsets 
-relative to the window origin (that is, region adjustments are not 
-required when the window is moved).  Three mechanisms for specifying 
-regions are provided:  a list of rectangles, a bitmap, and an existing 
-bounding or clip region from a window.  This is modeled on the specification 
-of regions in graphics contexts in the core protocol and allows a variety 
+regions.  These new regions are called the
+<emphasis remap='I'>client bounding region</emphasis> and the
+<emphasis remap='I'>client clip region</emphasis>.  They are specified
+relative to the origin of the window and are always defined by offsets
+relative to the window origin (that is, region adjustments are not
+required when the window is moved).  Three mechanisms for specifying
+regions are provided:  a list of rectangles, a bitmap, and an existing
+bounding or clip region from a window.  This is modeled on the specification
+of regions in graphics contexts in the core protocol and allows a variety
 of different uses of the extension.
 </para>
 
@@ -149,12 +149,12 @@ default region is used instead.
 </para>
 
 <para>
-The <emphasis remap='I'>effective bounding region</emphasis> of a window is 
-defined to be the intersection of the client bounding region with the default 
-bounding region.  Any portion of the client bounding region that is not 
-included in the default bounding region will not be included in the 
-effective bounding region on the screen.  This means that window managers 
-(or other geometry managers) used to dealing with rectangular client windows 
+The <emphasis remap='I'>effective bounding region</emphasis> of a window is
+defined to be the intersection of the client bounding region with the default
+bounding region.  Any portion of the client bounding region that is not
+included in the default bounding region will not be included in the
+effective bounding region on the screen.  This means that window managers
+(or other geometry managers) used to dealing with rectangular client windows
 will be able to constrain the client to a rectangular area of the screen.
 </para>
 
@@ -167,11 +167,11 @@ be enlarged to include more of the client bounding region.
 </para>
 
 <para>
-The <emphasis remap='I'>effective clip region</emphasis> of a window is 
-defined to be the intersection of the client clip region with both the 
-default clip region and the client bounding region.  Any portion of the 
-client clip region that is not included in both the default clip region 
-and the client bounding region will not be included in the effective clip 
+The <emphasis remap='I'>effective clip region</emphasis> of a window is
+defined to be the intersection of the client clip region with both the
+default clip region and the client bounding region.  Any portion of the
+client clip region that is not included in both the default clip region
+and the client bounding region will not be included in the effective clip
 region on the screen.
 </para>
 
@@ -213,13 +213,13 @@ a nonrectangular border of a window will be delivered to that window, just
 as for events that occur in a normal rectangular border.
 </para>
 
-<para>An 
+<para>An
 <function>InputOnly</function>
 window can have its bounding region set, but it is a
 <function>Match</function>
 error to attempt to set a clip region on an
 <function>InputOnly</function>
-window or to specify its clip region as a source to a request 
+window or to specify its clip region as a source to a request
 in this extension.
 </para>
 
@@ -271,7 +271,7 @@ if the specified display supports the SHAPE extension else
 If the extension is supported, *event_base is set to the event number for
 <function>ShapeNotify</function>
 events and *error_base would be set to the error number for the first error for
-this extension.  Because no errors are defined for this version of 
+this extension.  Because no errors are defined for this version of
 the extension, the value returned here is not defined (nor useful).
 </para>
 
@@ -285,7 +285,7 @@ the extension, the value returned here is not defined (nor useful).
 </funcsynopsis>
 
 <para>
-If the extension is supported, 
+If the extension is supported,
 <function>XShapeQueryVersion</function>
 sets the major and minor version numbers of the
 extension supported by the display and returns a nonzero value.
@@ -328,9 +328,9 @@ converts the specified region into a list of rectangles and calls
 </funcsynopsis>
 
 <para>
-If the extension is supported, 
+If the extension is supported,
 <function>XShapeCombineRectangles</function>
-performs a 
+performs a
 <function>ShapeRectangles</function>
 operation; otherwise, the request is ignored.
 </para>
@@ -425,7 +425,7 @@ corresponding default region are used.
 </para>
 
 <para>
-If the extension is supported, a nonzero value is returned; otherwise, 
+If the extension is supported, a nonzero value is returned; otherwise,
 zero is returned.
 </para>
 
@@ -495,9 +495,9 @@ If the extension is not supported, it returns zero.
 </funcsynopsis>
 
 <para>
-If the extension is not supported, 
+If the extension is not supported,
 <function>XShapeGetRectangles</function>
-returns NULL.  Otherwise, it returns a list of rectangles that describe the 
+returns NULL.  Otherwise, it returns a list of rectangles that describe the
 region specified by kind.
 </para>
 </chapter>
@@ -508,37 +508,37 @@ region specified by kind.
 <title>Glossary</title>
 <glossentry id='bounding_region'>
   <glossterm>bounding region</glossterm>
-  <glossdef><para>The area of the parent window that this window will occupy.  
+  <glossdef><para>The area of the parent window that this window will occupy.
 This area is divided into two parts:  the border and the interior.</para>
   </glossdef>
 </glossentry>
 
 <glossentry id='clip_region'>
   <glossterm>clip region</glossterm>
-  <glossdef><para>The interior of the window, as a subset of the bounding 
-region.  This region describes the area that will be painted with the 
-window background when the window is cleared, will contain all graphics 
+  <glossdef><para>The interior of the window, as a subset of the bounding
+region.  This region describes the area that will be painted with the
+window background when the window is cleared, will contain all graphics
 output to the window, and will clip any subwindows.</para></glossdef>
 </glossentry>
 
 <glossentry id='default_bounding_region'>
   <glossterm>default bounding region</glossterm>
-  <glossdef><para>The rectangular area, as described by the core protocol 
+  <glossdef><para>The rectangular area, as described by the core protocol
 window size, that covers the interior of the window and its border.</para>
   </glossdef>
 </glossentry>
 
 <glossentry id='default_clip_region'>
   <glossterm>default clip region</glossterm>
-  <glossdef><para>The rectangular area, as described by the core protocol 
+  <glossdef><para>The rectangular area, as described by the core protocol
 window size, that covers the interior of the window and excludes the border.
   </para></glossdef>
 </glossentry>
 
 <glossentry id='client_bounding_region'>
   <glossterm>client bounding region</glossterm>
-  <glossdef><para>The region associated with a window that is directly 
-modified via this extension when specified by 
+  <glossdef><para>The region associated with a window that is directly
+modified via this extension when specified by
 <function>ShapeBounding</function>
 This region is used in conjunction with the default bounding region
 to produce the effective bounding region.</para></glossdef>
@@ -546,32 +546,32 @@ to produce the effective bounding region.</para></glossdef>
 
 <glossentry id='client_clip_region'>
   <glossterm>client clip region</glossterm>
-  <glossdef><para>The region associated with a window that is directly 
-modified via this extension when specified by 
+  <glossdef><para>The region associated with a window that is directly
+modified via this extension when specified by
 <function>ShapeClip</function>
-This region is used in conjunction with the default clip region 
+This region is used in conjunction with the default clip region
 and the client bounding region to produce the effective clip region.</para>
   </glossdef>
 </glossentry>
 
 <glossentry id='effective_bounding_region'>
   <glossterm>effective bounding region</glossterm>
-  <glossdef><para>The actual shape of the window on the screen, including 
-border and interior (but excluding the effects of overlapping windows).  
-When a window has a client bounding region, the effective bounding region 
-is the intersection of the default bounding region and the client bounding 
-region.  Otherwise, the effective bounding region is the same as the 
+  <glossdef><para>The actual shape of the window on the screen, including
+border and interior (but excluding the effects of overlapping windows).
+When a window has a client bounding region, the effective bounding region
+is the intersection of the default bounding region and the client bounding
+region.  Otherwise, the effective bounding region is the same as the
 default bounding region.</para>
   </glossdef>
 </glossentry>
 
 <glossentry id='effective_clip_region'>
   <glossterm>effective clip region</glossterm>
-  <glossdef><para>The actual shape of the interior of the window on the 
-screen (excluding the effects of overlapping windows).  When a window 
-has a client clip region or a client bounding region, the effective 
-clip region is the intersection of the default clip region, the client 
-clip region (if any) and the client bounding region (if any).  Otherwise, 
+  <glossdef><para>The actual shape of the interior of the window on the
+screen (excluding the effects of overlapping windows).  When a window
+has a client clip region or a client bounding region, the effective
+clip region is the intersection of the default clip region, the client
+clip region (if any) and the client bounding region (if any).  Otherwise,
 the effective clip region is the same as the default clip region.</para>
   </glossdef>
 </glossentry>
@@ -579,4 +579,3 @@ the effective clip region is the same as the default clip region.</para>
 </glossdiv>
 </glossary>
 </book>
-
diff --git a/specs/synclib.xml b/specs/synclib.xml
new file mode 100644
index 0000000..febf27f
--- /dev/null
+++ b/specs/synclib.xml
@@ -0,0 +1,804 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
+
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="recordlib">
+
+<bookinfo>
+   <title>X Synchronization Extension Library</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>X Version 11, Release 6.4</releaseinfo>
+   <authorgroup>
+      <author>
+        <firstname>Tim</firstname><surname>Glauert</surname>
+        <affiliation><orgname>Olivetti Research/MultiWorks</orgname></affiliation>
+      </author>
+      <othercredit>
+          <firstname>Dave</firstname>
+          <surname>Carver</surname>
+          <affiliation><orgname>Digital EquipmentCorporation, MIT/Project Athena</orgname></affiliation>
+      </othercredit>
+      <othercredit>
+        <firstname>Jim</firstname>
+        <surname>Gettys</surname>
+        <affiliation><orgname>Digital EquipmentCorporation, Cambridge Research Laboratory</orgname></affiliation>
+      </othercredit>
+      <othercredit>
+        <firstname>David</firstname>
+        <surname>Wiggins</surname>
+        <affiliation><orgname>X Consortium, Inc.</orgname></affiliation>
+      </othercredit>
+   </authorgroup>
+   <copyright><year>1991</year><holder>Olivetti Research Limited, Cambridge England and Digital Equipment Corporation, Maynard, Massachusetts</holder></copyright>
+   <copyright><year>1991</year><holder>X Consortium</holder></copyright>
+   <releaseinfo>Version 3.0</releaseinfo>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 6.4</productnumber>
+<legalnotice>
+
+<para>
+Permission to use, copy, modify, and distribute this documentation for any
+purpose and without fee is hereby granted, provided that the above
+copyright notice appear in all copies. Olivetti, Digital, MIT, and the
+X Consortium make no representations about the suitability for any purpose
+of the information in this document. This documentation is provided as
+is without express or implied warranty.
+</para>
+
+<para>
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files
+(the "Software"), to deal in the Software without
+restriction, including without limitation the rights to use, copy,
+modify, merge, publish, distribute, sublicense, and/or sell copies of
+the Software, and to permit persons to whom the Software is furnished
+to do so, subject to the following conditions:
+</para>
+
+<para>
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+</para>
+
+<para>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR
+OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+OTHER DEALINGS IN THE SOFTWARE.
+</para>
+
+<para>
+Except as contained in this notice, the name of the X Consortium shall
+not be used in advertising or otherwise to promote the sale, use or other
+dealings in this Software without prior written authorization from the
+X Consortium.
+</para>
+
+</legalnotice>
+</bookinfo>
+
+<chapter id="synchronization_protocol">
+<title>Synchronization Protocol</title>
+
+<para>
+The core X protocol makes no guarantees about the relative order of
+execution of requests for different clients.  This means that any
+synchronization between clients must be done at the client level in an
+operating system-dependent and network-dependent manner. Even if there
+was an accepted standard for such synchronization, the use of a network
+introduces unpredictable delays between the synchronization of the clients and
+the delivery of the resulting requests to the X server.
+</para>
+<para>
+The core X protocol also makes no guarantees about the time at which
+requests are executed, which means that all clients with real-time constraints
+must implement their timing on the host computer. Any such timings are
+subject to error introduced by delays within the operating system and
+network and are inefficient because of the need for round-trip requests that
+keep the client and server synchronized.
+</para>
+<para>
+The synchronization extension provides primitives that allow synchronization
+between clients to take place entirely within the X server. This removes any
+error introduced by the network and makes it possible to synchronize clients
+on different hosts running different operating systems. This is important for
+multimedia applications, where audio, video, and graphics data streams are
+being synchronized. The extension also provides internal timers within the X
+server to which client requests can be synchronized. This allows simple
+animation applications to be implemented without any round-trip requests
+and makes best use of buffering within the client, network, and server.
+</para>
+
+<sect1 id="description">
+<title>Description</title>
+<para>
+The mechanism used by this extension for synchronization within the X server
+is to block the processing of requests from a client until a specific
+synchronization condition occurs. When the condition occurs, the client is
+released and processing of requests continues. Multiple clients may block on
+the same condition to give inter-client synchronization. Alternatively, a single
+client may block on a condition such as an animation frame marker.
+</para>
+<para>
+The extension adds <function>Counter</function> and
+<function>Alarm</function> to the set of resources managed by
+the server. A counter has a 64-bit integer value that may be increased or
+decreased by client requests or by the server internally. A client can
+block by sending an <function>Await</function> request that waits until
+one of a set of synchronization conditions, called TRIGGERs, becomes TRUE.
+</para>
+<para>
+The <function>CreateCounter</function> request allows a client to create
+a <function>Counter</function> that can be changed by explicit
+<function>SetCounter</function> and <function>ChangeCounter</function>
+requests. These can be used to implement synchronization between
+different clients.
+</para>
+<para>
+There are some counters, called <function>System Counters</function>,
+that are changed by the server internally rather than by client
+requests. The effect of any change to a system counter is not visible
+until the server has finished processing the current request. In other
+words, system counters are apparently updated in the gaps between the
+execution of requests rather than during the actual execution of a
+request. The extension provides a system counter that advances with the
+server time as defined by the core protocol, and it may also provide
+counters that advance with the real-world time or that change each
+time the CRT screen is refreshed. Other extensions may provide their own
+extension-specific system counters.
+</para>
+<para>
+The extension provides an <function>Alarm</function> mechanism that allows clients to receive an
+event on a regular basis when a particular counter is changed.
+</para>
+</sect1>
+</chapter>
+
+<chapter id="c_language_binding">
+<title>C Language Binding</title>
+
+<para>
+The C routines provide direct access to the protocol and add no additional
+semantics.
+</para>
+<para>
+The include file for this extension is &lt;X11/extensions/sync.h&gt;.
+Most of the names in the language binding are derived from the protocol
+names by prepending XSync to the protocol name and changing the
+capitalization.
+</para>
+
+<sect1 id="c_functions">
+<title>C Functions</title>
+
+<para>
+Most of the following functions generate SYNC protocol requests.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncQueryExtension</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>int <parameter> *event_base_return</parameter></paramdef>
+    <paramdef>int <parameter> *error_base_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If dpy supports the SYNC extension,
+<function>XSyncQueryExtension</function> returns True,
+sets *event_base_return to the event number for the first SYNC event, and
+sets *error_base_return to the error number for the first SYNC error. If dpy
+does not support the SYNC extension, it returns False.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncInitialize</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>int <parameter> *major_version_return</parameter></paramdef>
+    <paramdef>int <parameter> *minor_version_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncInitialize</function> sets *major_version_return and
+*minor version return to the major/minor SYNC protocol version supported
+by the server. If the XSync library is compatible with the version
+returned by the server, this function returns <function>True</function>.
+If dpy does not support the SYNC extension, or if there was an error
+during communication with the server, or if the server and library protocol
+versions are incompatible, this function returns <function>False</function>.
+The only XSync function that may be called before this function is
+XSyncQueryExtension. If a client violates this rule, the effects of all XSync
+calls that it makes are undefined.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>XSyncSystemCounter *<function>XSyncListSystemCounters</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>int <parameter> *n_counters_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncListSystemCounters</function> returns a pointer to an array
+of system counters supported by the display and sets *n_counters_return
+to the number of counters in the array.  The array should be freed with
+<function>XSyncFreeSystemCounterList</function>. If dpy does not support
+the SYNC extension, or if there was an error during communication with
+the server, or if the server does not support any system counters,
+this function returns NULL.
+</para>
+
+<para>
+XSyncSystemCounter has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+char *              name;        /* null-terminated name of system counter */
+XSyncCounter        counter;     /* counter id of this system counter */
+XSyncValue          resolution;  /* resolution of this system counter */
+</literallayout>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void <function>XSyncFreeSystemCounterList</function></funcdef>
+    <paramdef>XSyncSystemCounter <parameter> *list</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncFreeSystemCounterList</function> frees the memory
+associated with the system counter list returned by
+<function>XSyncListSystemCounters</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>XSyncCounter <function>XSyncCreateCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> initial_value</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncCreateCounter</function> creates a counter on the dpy
+with the given initial value and returns the counter ID. It returns
+<function>None</function> if dpy does not support the SYNC extension.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncSetCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> value</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+
+<para>
+<function>XSyncSetCounter</function> sets counter to value. It returns
+<function>False </function> if dpy does not
+support the SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncChangeCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> value</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncChangeCounter</function> adds value to counter. It returns
+<function>False</function> if dpy does not support the SYNC extension;
+otherwise, it returns
+<function>True</function>.
+</para>
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncDestroyCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncDestroyCounter</function> destroys counter. It returns
+<function>False</function> if dpy does not support the SYNC extension;
+otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncQueryCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> *value_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncQueryCounter</function> sets *value_return to the current
+value of counter. It returns <function>False</function> if there was an
+error during communication with the server or if dpy does not support the
+SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncAwait</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncWaitCondition<parameter> *wait_list</parameter></paramdef>
+    <paramdef>int<parameter> n_conditions</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncAwait</function> awaits on the conditions in wait_list.
+The n_conditions is the number of wait conditions in wait_list. It
+returns <function>False</function> if dpy does not support the SYNC
+extension; otherwise, it returns <function>True</function>. The await is
+processed asynchronously by the server; this function always returns
+immediately after issuing the request.
+</para>
+<para>
+XSyncWaitCondition has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+XSyncCounter     trigger.counter;    /*counter to trigger on */
+XSyncValueType   trigger.value_type; /*absolute/relative */
+XSyncValue       trigger.wait_value; /*value to compare counter to */
+XSyncTestType    trigger.test_type;  /*pos/neg comparison/transtion */
+XSyncValue       event_threshold;    /*send event if past threshold */
+</literallayout>
+
+<para>
+<function>XSyncValueType</function> can be either
+<function>XSyncAbsolute</function> or <function>XSyncRelative</function>.
+</para>
+
+<para>
+<function>XSyncTestType</function> can be one of
+<function>XSyncPositiveTransition</function>,
+<function>XSyncNegativeTransition</function>,
+<function>XSyncPositiveComparison</function>, or
+<function>XSyncNegativeComparison</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>XSyncAlarm <function>XSyncCreateAlarm</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>unsigned long<parameter> values_mask</parameter></paramdef>
+    <paramdef>XSyncAlarmAttributes<parameter> *values`</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncCreateAlarm</function> creates an alarm and returns the
+alarm ID. It returns None if the display does not support the SYNC
+extension. The values_mask and values specify the alarm attributes.
+</para>
+
+<para>
+<function>XSyncAlarmAttributes</function> has the following fields. The
+attribute_mask column specifies the symbol that the caller should OR
+into values_mask to indicate that the value for the corresponding
+attribute was actually supplied. Default values are used for all
+attributes that do not have their attribute_mask OR’ed into values_mask.
+See the protocol description for <function>CreateAlarm</function> for the
+defaults.
+</para>
+
+<literallayout remap='Ds'>
+type                 field name           attribute_mask
+XSyncCounter       trigger.counter;     XSyncCACounter
+XSyncValueType     trigger.value_type;  XSyncCAValueType
+XSyncValue         trigger.wait_value;  XSyncCAValue
+XSyncTestType      trigger.test_type;   XSyncCATestType
+XSyncValue         delta;               XSyncCADelta
+Bool               events;              XSyncCAEvents
+XSyncAlarmState    state;               client cannot set this
+</literallayout>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncDestroyAlarm</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncAlarm<parameter> alarm</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncDestroyAlarm</function> destroys alarm. It returns
+<function>False</function> if dpy does not support
+the SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncQueryAlarm</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncAlarm<parameter> alarm</parameter></paramdef>
+    <paramdef>XSyncAlarmAttributes<parameter> *values_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+
+<para>
+<function>XSyncQueryAlarm</function> sets *values_return to the alarm’s
+attributes. It returns <function>False</function> if there was an error
+during communication with the server or if dpy does not support the
+SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncChangeAlarm</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncAlarm<parameter> alarm</parameter></paramdef>
+    <paramdef>unsigned long<parameter> values_mask</parameter></paramdef>
+    <paramdef>XSyncAlarmAttributes<parameter> *values</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncChangeAlarm</function> changes alarm’s attributes. The
+attributes to change are specified as in
+<function>XSyncCreateAlarm</function>. It returns
+<function>False</function> if dpy does not support
+the SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncSetPriority</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XID<parameter> client_resource_id</parameter></paramdef>
+    <paramdef>int<parameter> priority</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncSetPriority</function> sets the priority of the client
+owning client_resource_id to priority. If client_resource_id is None, it
+sets the caller’s priority. It returns
+<function>False</function> if dpy does not support the SYNC extension;
+otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSyncGetPriority</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XID<parameter> client_resource_id</parameter></paramdef>
+    <paramdef>int<parameter> *return_priority</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncGetPriority</function> sets *return_priority to the
+priority of the client owning client_resource_id. If client_resource_id
+is None, it sets *return_priority to the caller’s priority. It returns
+<function>False</function> if there was an error during communication
+with the server or if dpy does not support the SYNC extension; otherwise, it
+returns <function>True</function>.
+</para>
+
+</sect1>
+
+<sect1 id="c_macros_functions">
+<title>C Macros/Functions</title>
+
+<para>
+The following procedures manipulate 64-bit values. They are defined both as
+macros and as functions. By default, the macro form is used. To use the
+function form, #undef the macro name to uncover the function.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void <function>XSyncIntToValue</function></funcdef>
+    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>
+    <paramdef>int<parameter> i</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Converts i to an <function>XSyncValue</function> and stores it in *pv.
+Performs sign extension (*pv will have the same sign as i.)
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void <function>XSyncIntsToValue</function></funcdef>
+    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>
+    <paramdef>unsigned int<parameter> low</parameter></paramdef>
+    <paramdef>int<parameter> high</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Stores low in the low 32 bits of *pv and high in the high 32 bits of *pv.
+</para>
+
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueGreaterThan</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is greater than b, else returns
+<function>False</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueLessThan</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is less than b, else returns
+<function>False</function>.
+</para>
+
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueGreaterOrEqual</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is greater than or equal to b,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueLessOrEqual</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is less than or equal to b,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueEqual</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is equal to b,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueIsNegative</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if v is negative,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueIsZero</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if v is zero,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueIsPositive</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if v is positive,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>unsigned int <function>XSyncValueLow32</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns the low 32 bits of v.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>unsigned int <function>XSyncValueHigh32</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns the high 32 bits of v.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void <function>XSyncValueAdd</function></funcdef>
+    <paramdef>XSyncValue<parameter> *presult</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+    <paramdef>Bool<parameter> *poverflow</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Adds a to b and stores the result in *presult. If the result could not
+fit in 64 bits, *poverflow is set to <function>True</function>, else it is
+set to <function>False</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void <function>XSyncValueSubtract</function></funcdef>
+    <paramdef>XSyncValue<parameter> *presult</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+    <paramdef>Bool<parameter> *poverflow</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Subtracts b from a and stores the result in *presult. If the result could not
+fit in 64 bits, *poverflow is set to <function>True</function>, else it is
+set to <function>False</function>.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void <function>XSyncMaxValue</function></funcdef>
+    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Sets *pv to the maximum value expressible in 64 bits.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void <function>XSyncMinValue</function></funcdef>
+    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Sets *pv to the minimum value expressible in 64 bits.
+</para>
+
+</sect1>
+
+<sect1 id="events">
+<title>Events</title>
+
+<para>
+Let <emphasis remap='I'>event_base</emphasis> be the value event base return as defined in the function
+<function>XSyncQueryExtension</function>.
+</para>
+
+<para>
+An <function>XSyncCounterNotifyEvent</function>’s type field has the value
+event_base + <function>XSyncCounterNotify</function>. The fields of this
+structure are:
+</para>
+
+<literallayout remap='Ds'>
+int              type;          /* event base + XSyncCounterNotify */
+unsigned long    serial;        /* number of last request processed by server */
+Bool             send event;    /* true if this came from a SendEvent request */
+Display *        display;       /* Display the event was read from */
+XSyncCounter     counter;       /* counter involved in await */
+XSyncValue       wait_value;    /* value being waited for */
+XSyncValue       counter_value; /* counter value when this event was sent */
+Time             time;          /* milliseconds */
+int              count;         /* how many more events to come */
+Bool             destroyed;     /* True if counter was destroyed */
+</literallayout>
+
+<para>
+An <function>XSyncAlarmNotifyEvent</function>’s type field has the value
+event_base + <function>XSyncAlarmNotify</function>. The fields of
+this structure are:
+</para>
+
+<literallayout remap='Ds'>
+int             type;         /* event_base + XSyncAlarmNotify */
+unsigned long   serial;       /* number of last request processed by server */
+Bool            send_event;   /* true if this came from a SendEvent request */
+Display *       display;      /*Display the event was read from */
+XSyncAlarm      alarm;        /* alarm that triggered */
+XSyncValue      counter_value /* value that triggered the alarm */
+XSyncValue      alarm_value   /* test value of trigger in alarm */
+Time            time;         /* milliseconds */
+XSyncAlarmState state;        /* new state of alarm */
+</literallayout>
+
+</sect1>
+
+<sect1 id="errors">
+<title>Errors</title>
+<para>
+Let <emphasis remap='I'>error_base</emphasis> be the value
+<emphasis remap='I'>error_base_return</emphasis> as defined in the function
+<function>XSyncQueryExtension</function>.
+</para>
+
+<para>
+An <function>XSyncAlarmError</function>’s error_code field has
+<function>XSyncBadAlarm</function>. The fields of this structure are:
+</para>
+
+<literallayout remap='Ds'>
+int                type
+Display *          display;      /* Display the event was read from */
+XSyncCounter       counter;      /* resource id */
+unsigned long      serial;       /* serial number of failed request */
+unsigned char      error_code;   /* error_base + XSyncBadAlarm */
+unsigned char      request_code; /* Major op-code of failed request */
+unsigned char      minor_code;   /* Minor op-code of failed request */
+</literallayout>
+
+<para>
+An <function>XSyncCounterError</function>’s error code field has the value
+error_base + <function>XSyncBadCounter</function>. The fields of this
+structure are:
+</para>
+<literallayout remap='Ds'>
+int                type
+Display *          display;      /* Display the event was read from */
+XSyncCounter       counter;      /* resource id */
+unsigned long      serial;       /* serial number of failed request */
+unsigned char      error_code;   /* error_base + XSyncBadCounter */
+unsigned char      request_code; /* Major op-code of failed request */
+unsigned char      minor_code;   /* Minor op-code of failed request */
+</literallayout>
+
+</sect1>
+</chapter>
+</book>