specs: convert protocol .ms specs from xorg-docs module to DocBook XML

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

5 files changed, 3725 insertions, 0 deletions

diff --git a/specs/.gitignore b/specs/.gitignore
new file mode 100644
index 0000000..12fe512
--- /dev/null
+++ b/specs/.gitignore
@@ -0,0 +1,6 @@
+#		Add & Override for this directory and it's subdirectories
+*.html
+*.ps
+*.pdf
+*.txt
+*.css
diff --git a/specs/Makefile.am b/specs/Makefile.am
new file mode 100644
index 0000000..9d94e85
--- /dev/null
+++ b/specs/Makefile.am
@@ -0,0 +1,64 @@
+#
+# Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
+#
+# 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:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# 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.
+#
+
+if ENABLE_SPECS
+doc_sources = dbe.xml security.xml sync.xml
+dist_doc_DATA = $(doc_sources)
+
+if HAVE_XMLTO
+doc_DATA = $(doc_sources:.xml=.html)
+
+if HAVE_FOP
+doc_DATA += $(doc_sources:.xml=.ps) $(doc_sources:.xml=.pdf)
+endif
+
+if HAVE_XMLTO_TEXT
+doc_DATA += $(doc_sources:.xml=.txt)
+endif
+
+if HAVE_STYLESHEETS
+XMLTO_FLAGS = -m $(XSL_STYLESHEET)
+
+doc_DATA += xorg.css
+xorg.css: $(STYLESHEET_SRCDIR)/xorg.css
+	$(AM_V_GEN)cp -pf $(STYLESHEET_SRCDIR)/xorg.css $@
+endif
+
+CLEANFILES = $(doc_DATA)
+
+SUFFIXES = .xml .ps .pdf .txt .html
+
+.xml.txt:
+	$(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) txt $<
+
+.xml.html:
+	$(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) xhtml-nochunks $<
+
+.xml.pdf:
+	$(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop pdf $<
+
+.xml.ps:
+	$(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop ps $<
+
+endif HAVE_XMLTO
+endif ENABLE_SPECS
diff --git a/specs/dbe.xml b/specs/dbe.xml
new file mode 100644
index 0000000..ce7a327
--- /dev/null
+++ b/specs/dbe.xml
@@ -0,0 +1,1061 @@
+<?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">
+
+
+<!--
+by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)
+xhtml,docbook,html,refcaption -->
+
+<book id="dbe">
+
+<bookinfo>
+  <title>Double Buffer Extension Protocol</title>
+  <subtitle>X Consortium Standard</subtitle>
+  <releaseinfo>X Version 11, Release 6.4</releaseinfo>
+  <authorgroup>
+   <author>
+     <firstname>Ian</firstname><surname>Elliott</surname>
+   </author>
+  </authorgroup>
+  <othercredit>
+   <firstname>David</firstname><surname>Wiggins</surname>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+  </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>
+  <releaseinfo>Version 1.0</releaseinfo>
+
+<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 <function>CreateWindow</function>
+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. In
+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 <function>ClearArea</function> 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 DRAWABLE 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 windo'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 <function>IncludeInferiors</function>, 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 windo'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 windo'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.
+</para>
+
+<para>
+If the core <function>GetGeometry</function> 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>
+   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>DBEBeginIdiom 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 PolyFillRectangle request to the back buffer of one window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Core X PolyFillRectangle request to the back buffer of the other window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>DBEEndIdiom 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 Copied 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 Untouched, and if a <function>PolyFillRectangle</function>
+using a client clip rectangle is done to the windo'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="requests">
+<title>Requests</title>
+<para>The DBE defines the following requests.</para>
+
+<sect1 id="dbegetversion">
+<title>DBEGetVersion</title>
+<para>
+This request returns the major and minor version numbers of this extension.
+</para>
+
+<para>DBEGetVersion</para>
+<informaltable>
+  <tgroup cols="2">
+    <colspec colname="c1"/>
+    <colspec colname="c2" />
+    <tbody>
+      <row>
+        <entry align="left">client-major-version</entry>
+        <entry align="left">CARD8</entry>
+      </row>
+      <row>
+        <entry align="left">client-minor-version </entry>
+        <entry align="left">CARD8</entry>
+      </row>
+      <row>
+        <entry align="left">=></entry>
+        <entry align="left"></entry>
+      </row>
+      <row>
+        <entry align="left">server-major-version </entry>
+        <entry align="left">CARD8</entry>
+      </row>
+      <row>
+        <entry align="left">server-minor-version </entry>
+        <entry align="left">CARD8</entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The client-major-version and client-minor-version numbers indicate what
+version of the protocol the client wants the server to implement. The
+server-major-version and the server-minor-version numbers returned indicate
+the protocol this extension actually supports. This might not equal the
+version sent by the client. An implementation can (but need not) support
+more than one version simultaneously.  The server-major-version and
+server-minor-version allow the creation of future revisions of the DBE
+protocol that may be necessary. In general, the major version
+would increment for incompatible changes, and the minor version would increment
+for small, upward-compatible changes. Servers that support the protocol
+defined in this document will return a server-major-version of one (1), and a
+server-minor-version of zero (0).
+</para>
+
+<para>
+The DBE client must issue a DBEGetVersion request before any other double
+buffering request in order to negotiate a compatible protocol version;
+otherwise, the client will get undefined behavior (DBE may or may not work).
+</para>
+
+</sect1>
+
+<sect1 id="dbegetvisualinfo">
+<title>DBEGetVisualInfo</title>
+<para>
+This request returns information about which visuals support double buffering.
+</para>
+
+<para>DBEGetVisualInfo</para>
+
+<informaltable>
+  <tgroup cols="2">
+    <colspec colname="c1"/>
+    <colspec colname="c2"/>
+    <tbody>
+      <row>
+        <entry align="left">screen-specifiers</entry>
+        <entry align="left">LISTofDRAWABLE</entry>
+      </row>
+      <row>
+        <entry align="left">=></entry>
+        <entry align="left"></entry>
+      </row>
+      <row>
+        <entry align="left">visinfo</entry>
+        <entry align="left">LISTofSCREENVISINFO</entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+<para>where:</para>
+
+<informaltable>
+  <tgroup cols="2">
+    <colspec colname="c1"/>
+    <colspec colname="c2"/>
+    <tbody>
+      <row>
+        <entry align="left">SCREENVISINFO</entry>
+        <entry align="left">LISTofVISINFO</entry>
+      </row>
+      <row>
+        <entry align="left">VISINFO</entry>
+        <entry align="left">[ visual: VISUALID</entry>
+      </row>
+      <row>
+        <entry align="left"></entry>
+        <entry align="left">depth: CARD8</entry>
+      </row>
+      <row>
+        <entry align="left"></entry>
+        <entry align="left">perflevel: CARD8 ]</entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>Errors: Drawable</para>
+
+<para>
+All of the values passed in screen-specifiers must be valid DRAWABLEs (or a
+<function>Drawable</function> error results). For each drawable in
+screen-specifiers, the reply will contain a list of VISINFO structures for
+visuals that support double-buffering on the screen on which the drawable
+resides. The visual member specifies the VISUALID. The depth member specifies
+the depth in bits for the visual. The perflevel is a performance hint. The
+only operation defined on a perflevel is comparison to a perflevel of another
+visual on the same screen. The visual having the higher perflevel is likely
+to have better double-buffer graphics performance than the visual having the
+lower perflevel. Nothing can be deduced from any of the following: the
+magnitude of the difference of two perflevels, a perflevel value in isolation,
+or comparing perflevels from different servers.
+</para>
+
+<para>
+If the list of screen-specifiers is empty, information for all screens is
+returned, starting with screen zero.
+</para>
+
+</sect1>
+
+<sect1 id="dbeallocatebackbuffername">
+<title>DBEAllocateBackBufferName</title>
+
+<para>
+This request allocates a drawable ID used to refer to the back buffer of a
+window.
+</para>
+
+<para>DBEAllocateBackBufferName</para>
+
+<informaltable>
+  <tgroup cols="2">
+    <colspec colname="c1"/>
+    <colspec colname="c2"/>
+    <tbody>
+      <row>
+        <entry align="left">window</entry>
+        <entry align="left">WINDOW</entry>
+      </row>
+      <row>
+        <entry align="left">back-buffer-name</entry>
+        <entry align="left">BACKBUFFER</entry>
+      </row>
+      <row>
+        <entry align="left">swap-action-hint</entry>
+        <entry align="left">SWAPACTION </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+Errors: Alloc, Value, IDChoice, Match, Window
+</para>
+
+<para>
+If the window is not already a double-buffered window, the window becomes
+double-buffered, and the back-buffer-name is associated with the window. The
+swap-action-hint tells the server which swap action is most likely to be
+used with the window in subsequent <function>DBESwapBuffers</function>
+requests. The swap-action-hint must have one of the values specified for type
+SWAPACTION (or a Value error results). See the description of the
+<function>DBESwapBuffers</function> request for a complete discussion of
+swap actions and the SWAPACTION type.
+</para>
+
+<para>
+If the window already is a double-buffered window, nothing about the window
+changes, except that an additional 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>
+The window passed into the request must be a valid WINDOW (or a Window error
+results). The window passed into the request must be an InputOutput window (or
+a Match error results). The visual of the window must be in the list returned
+by <function>DBEGetVisualInfo</function> (or a Match error results). The
+back-buffer-name must be in the range assigned to the client, and must not
+already be in use (or an IDChoice error results). If the server cannot
+allocate all resources associated with turning on double-buffering for the
+window, an Alloc error results, the windo's double-buffer status (whether it
+is already double-buffered or not) remains unchanged, and the
+back-buffer-name is freed.
+</para>
+</sect1>
+
+<sect1 id="dbedeallocatebackbuffername">
+<title>DBEDeallocateBackBufferName</title>
+<para>
+This request frees a drawable ID that was obtained by
+<function>DBEAllocateBackBufferName</function>.
+</para>
+
+<para>DBEDeallocateBackBufferName</para>
+
+<informaltable>
+  <tgroup cols="2">
+  <colspec colname="c1"/>
+  <colspec colname="c2"/>
+  <tbody>
+    <row>
+      <entry align="left">back-buffer-name</entry>
+      <entry align="left">BACKBUFFER</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>Errors: Buffer</para>
+
+<para>
+The back-buffer-name passed in the request is freed and no longer associated
+with the window. If this is the last back-buffer-name associated with the
+window, then the back buffer is no longer accessible to clients, and all
+double-buffering resources associated with the window may be freed. The
+window's current front buffer remains the front buffer.
+</para>
+
+<para>
+The back-buffer-name must be a valid BACKBUFFER associated with a window (or
+a Buffer error results).
+</para>
+</sect1>
+
+<sect1 id="dbeswapbuffers">
+<title>DBESwapBuffers</title>
+<para>
+This request swaps the buffers for all windows listed, applying the
+appropriate swap action for each window.
+</para>
+
+<para><function>DBESwapBuffers</function></para>
+
+<informaltable>
+  <tgroup cols="2">
+  <colspec colname="c1" /><colspec colname="c2"/>
+  <tbody>
+    <row>
+      <entry align="left">windows</entry>
+      <entry align="left">LISTofSWAPINFO</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+<para>where:</para>
+<informaltable>
+  <tgroup cols="2">
+  <colspec colname="c1" /><colspec colname="c2"/>
+  <tbody>
+    <row>
+      <entry align="left">SWAPINFO</entry>
+      <entry align="left">[ window: WINDOW</entry>
+    </row>
+    <row>
+      <entry align="left"></entry>
+      <entry align="left">swap-action: SWAPACTION ]</entry>
+    </row>
+    <row>
+      <entry align="left">SWAPACTION</entry>
+      <entry align="left">{ Undefined, Background, Untouched, Copied }</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>Errors: Match, Window, Value</para>
+
+<para>
+Each window passed into the request must be a valid WINDOW (or a
+<function>Window</function> error results). Each window passed into the
+request must be a double-buffered window (or a <function>Match</function>
+error results). Each window passed into the request must only be listed
+once (or a <function>Match</function> error results). Each swap-action in
+the list must have one of the values specified for type SWAPACTION (or a
+<function>Value</function> error results). If an error results, none of
+the valid double-buffered windows will have their buffers swapped.
+</para>
+
+<para>
+The swap-action determines what will happen to the new back buffer of the
+window it is paired with in the list in addition to making the old back
+buffer become visible.  The defined actions are as follows:
+</para>
+
+<variablelist>
+  <varlistentry>
+    <term>Undefined</term>
+      <listitem><para>
+The contents of the new back buffer become undefined. This may be the
+most efficient action since it allows the implementation to discard the
+contents of the buffer if it needs to.
+      </para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>Background</term>
+    <listitem><para>
+The unobscured region of the new back buffer will be tiled with the window
+background. The background action allows devices to use a fast clear
+capability during a swap.
+    </para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>Untouched</term>
+    <listitem><para>
+The unobscured region of the new back buffer will be unmodified by the swap.
+    </para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>Copied</term>
+    <listitem><para>
+The unobscured region of the new back buffer will be the contents of the
+old back buffer.
+    </para></listitem>
+  </varlistentry>
+</variablelist>
+
+<para>
+If <function>DBESwapBuffers</function> is included in a "swap and clear"
+type of idiom, it must immediately follow the
+<function>DBEBeginIdiom</function> request.
+</para>
+</sect1>
+
+<sect1 id="dbebeginidiom">
+<title>DBEBeginIdiom</title>
+<para>
+This request informs the server that a complex swap will immediately follow
+this request.
+</para>
+
+<para><function>DBEBeginIdiom</function></para>
+
+<para>
+As previously discussed, a complex swap action is a group/series of
+requests that, taken together, may be combined into an atomic operation by
+the implementation.  The sole function of this request is to serve as a
+"marker" that the server can use to aid in idiom processing. The server is
+free to implement this request as a no-op.
+</para>
+</sect1>
+
+<sect1 id="dbeendidiom">
+<title>DBEEndIdiom</title>
+
+
+<para>
+This request informs the server that a complex swap has concluded.
+</para>
+
+<para><function>DBEEndIdiom</function></para>
+
+<para>
+The sole function of this request is to serve as a "marker" that the server
+can use to aid in idiom processing. The server is free to implement this
+request as a no-op.
+</para>
+
+</sect1>
+
+<sect1 id="dbegetbackbufferattributes">
+<title>DBEGetBackBufferAttributes</title>
+
+<para>This request returns information about a back buffer.</para>
+
+<para><function>DBEGetBackBufferAttributes</function></para>
+
+<informaltable>
+  <tgroup cols="2">
+  <colspec colname="c1"/>
+  <colspec colname="c2"/>
+  <tbody>
+    <row>
+      <entry align="left">back-buffer-name</entry>
+      <entry align="left">BACKBUFFER</entry>
+    </row>
+    <row>
+      <entry align="left">=></entry>
+      <entry align="left"></entry>
+    </row>
+    <row>
+      <entry align="left">attributes</entry>
+      <entry align="left">BUFFER_ATTRIBUTES</entry>
+    </row>
+  </tbody>
+  </tgroup>
+</informaltable>
+
+<para>where:</para>
+
+<para>BUFFER_ATTRIBUTES: [ window: WINDOW ]</para>
+
+<para>
+If back-buffer-name is a valid BACKBUFFER, the window field of the
+attributes in the reply will be the window which has the back buffer that
+back-buffer-name refers to. If back-buffer-name is not a valid BACKBUFFER,
+the window field of the attributes in the reply will be None.
+</para>
+
+</sect1>
+</chapter>
+
+<chapter id="encoding">
+<title>Encoding</title>
+<para>
+Please refer to the X11 Protocol Encoding document as this section uses
+syntactic conventions and data types established there.
+</para>
+
+<para>The name of this extension is "DOUBLE-BUFFER".</para>
+
+<sect1 id="type">
+<title>Type</title>
+<para>The following new types are used by the extension.
+</para>
+
+<para>BACKBUFFER: XID</para>
+<para>SWAPACTION</para>
+<literallayout class="monospaced">
+#x00  Undefined
+#x01  Background
+#x02  Untouched
+#x03  Copied
+</literallayout>
+
+<para>SWAPINFO</para>
+<literallayout class="monospaced">
+4     WINDOW                 window
+1     SWAPACTION             swap action
+3                            unused
+</literallayout>
+
+<literallayout class="monospaced">
+VISINFO
+4     VISUALID                visual
+1     CARD8                   depth
+1     CARD8                   perflevel
+2                             unused
+
+SCREENVISINFO
+4     CARD32                  n, number in list
+8n    LISTofVISINFO           n VISINFOs
+
+BUFFER_ATTRIBUTES
+4     WINDOW                 window
+</literallayout>
+</sect1>
+
+<sect1 id="error">
+<title>Error</title>
+<para><function>Buffer</function></para>
+<literallayout class="monospaced">
+1     0                       error
+1     error base + 0          code
+2     CARD16                  sequence number
+4     CARD32                  bad buffer
+2     CARD16                  minor-opcode
+1     CARD8                   major-opcode
+21                            unused
+</literallayout>
+</sect1>
+
+<sect1 id="request">
+<title>Request</title>
+
+<literallayout class="monospaced">
+DBEGetVersion
+1     CARD8                  major-opcode
+1     0                      minor-opcode
+2     2                      request length
+1     CARD8                  client-major-version
+1     CARD8                  client-minor-version
+2                            unused
+=>
+1                            unused
+2     CARD16                 sequence number
+4     0                      reply length
+1     CARD8                  server-major-version
+1     CARD8                  server-minor-version
+22                           unused
+</literallayout>
+
+<para><function>DBEAllocateBackBufferName</function></para>
+<literallayout class="monospaced">
+1     CARD8                  major-opcode
+1     1                      minor-opcode
+2     4                      request length
+4     WINDOW                 window
+4     BACKBUFFER             back buffer name
+1     SWAPACTION             swap action hint
+3                            unused
+</literallayout>
+
+<para><function>DBEDeallocateBackBufferName</function></para>
+<literallayout class="monospaced">
+1     CARD8                  major-opcode
+1     2                      minor-opcode
+2     2                      request length
+4     BACKBUFFER             back buffer name
+</literallayout>
+
+
+<para><function>DBESwapBuffers</function></para>
+<literallayout class="monospaced">
+1     CARD8                   major-opcode
+1     3                       minor-opcode
+2     2+2n                    request length
+4     CARD32                  n, number of window/swap action pairs in list
+8n    LISTofSWAPINFO          window/swap action pairs
+</literallayout>
+
+
+<para><function>DBEBeginIdiom</function></para>
+<literallayout class="monospaced">
+1     CARD8                   major-opcode
+1     4                       minor-opcode
+2     1                       request length
+</literallayout>
+
+<para><function>DBEEndIdiom</function></para>
+<literallayout class="monospaced">
+1     CARD8                   major-opcode
+1     5                       minor-opcode
+2     1                       request length
+</literallayout>
+
+<para><function>DBEGetVisualInfo</function></para>
+<literallayout class="monospaced">
+1     CARD8                   major-opcode
+1     6                       minor-opcode
+2     2+n                     request length
+4     CARD32                  n, number of screen specifiers in list
+4n    LISTofDRAWABLE          n screen specifiers
+=>
+1     1                       Reply
+1                             unused
+2     CARD16                  sequence number
+4     CARD32                  reply length
+4     CARD32                  m, number of SCREENVISINFOs in list
+20                            unused
+4j    LISTofSCREENVISINFO     m SCREENVISINFOs
+</literallayout>
+
+<para><function>DBEGetBackBufferAttributes</function></para>
+<literallayout class="monospaced">
+1     CARD8                   major-opcode
+1     7                       minor-opcode
+2     2                       request length
+4     BACKBUFFER              back-buffer-name
+=>
+1                             unused
+2     CARD16                  sequence number
+4     0                       reply length
+4     BUFFER_ATTRIBUTES       attributes
+20                            unused
+</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/security.xml b/specs/security.xml
new file mode 100644
index 0000000..bcf0153
--- /dev/null
+++ b/specs/security.xml
@@ -0,0 +1,1532 @@
+<?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">
+<!--translated from security.tex, on 2010-06-27 15:29:00,
+by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)
+xhtml,docbook,html,refcaption -->
+
+<book id="security">
+
+<bookinfo>
+   <title>Security Extension Specification</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>X Version 11, Release 6.8</releaseinfo>
+   <date>November 15, 1996</date>
+   <authorgroup>
+      <author>
+         <firstname>David</firstname><surname>Wiggins</surname>
+      </author>
+   </authorgroup>
+   <corpname>X Consortium Standard</corpname>
+   <copyright><year>1996</year><holder>X Consortium</holder></copyright>
+   <releaseinfo>Version 7.1</releaseinfo>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 6.8</productnumber>
+
+<legalnotice>
+
+<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 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="introduction">
+<title>Introduction</title>
+
+<para>
+The Security extension contains new protocol needed to provide enhanced X
+server security. The Security extension should not be exposed to untrusted
+clients (defined below).
+</para>
+
+</chapter>
+
+<chapter id="requests">
+<title>Requests</title>
+
+<sect1 id="securityqueryversion">
+<title>SecurityQueryVersion</title>
+<para>
+This request returns the major and minor version numbers of this extension.
+</para>
+
+<para>SecurityQueryVersion</para>
+
+<informaltable>
+  <tgroup cols="2">
+    <tbody>
+      <row>
+        <entry align="left">
+          <para>client-major-version</para>
+        </entry>
+        <entry align="left">
+          <para>CARD16</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>client-minor-version</para>
+        </entry>
+        <entry align="left">
+          <para>CARD16</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>=&gt;</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>server-major-version</para>
+        </entry>
+        <entry align="left">
+          <para>CARD16</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>server-minor-version</para>
+        </entry>
+        <entry align="left">
+          <para>CARD16</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The client-major-version and client-minor-version numbers indicate what
+version of the protocol the client wants the server to implement. The
+server-major-version and the server-minor-version numbers returned
+indicate the protocol this extension actually supports. This might not
+equal the version sent by the client. An implementation can (but need not)
+support more than one version simultaneously.  The server-major-version
+and server-minor-version allow the creation of future revisions of the
+Security protocol that may be necessary. In general, the major version
+would increment for incompatible changes, and the minor version would
+increment for small, upward-compatible changes. Servers that support
+the protocol defined in this document will return a server-major-version
+of one (1), and a server-minor-version of zero (0).
+</para>
+
+<para>
+Clients using the Security extension must issue a SecurityQueryVersion
+request before any other Security request in order to negotiate a compatible
+protocol version; otherwise, the client will get undefined behavior
+(Security may or may not work).
+</para>
+</sect1>
+
+<sect1 id="securitygenerateauthentication">
+<title>SecurityGenerateAuthorization</title>
+
+<para>
+This request causes the server to create and return a new authorization with
+specific characteristics. Clients can subsequently connect using the new
+authorization and will inherit some of the characteristics of the
+authorization.
+</para>
+
+<para>
+SecurityGenerateAuthorization
+</para>
+<informaltable>
+  <tgroup cols="2">
+    <tbody>
+      <row>
+        <entry align="left">
+          <para>authorization-protocol-name</para>
+        </entry>
+        <entry align="left">
+          <para>STRING8</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>authorization-protocol-data</para>
+        </entry>
+        <entry align="left">
+          <para>STRING8</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>value-mask</para>
+        </entry>
+        <entry align="left">
+          <para>BITMASK</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>value-list</para>
+        </entry>
+        <entry align="left">
+          <para>LISTofVALUE</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>=></para>
+        </entry>
+        <entry>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>authorization-id</para>
+        </entry>
+        <entry align="left">
+          <para>AUTHID</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>authorization-data-return</para>
+        </entry>
+        <entry align="left">
+          <para>STRING8</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+        <entry>
+        </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+Errors: <function>AuthorizationProtocol</function>, <function>Value</function>, <function>Alloc</function>
+</para>
+
+<para>
+authorization-protocol-name is the name of the authorization method for
+which the server should generate a new authorization that subsequent
+clients can use to connect to the server. If the authorization-protocol-name
+is not one that the server supports, or if authorization-protocol-data
+does not make sense for the given authorization-protocol-name, an
+AuthorizationProtocol error results.
+</para>
+
+<para>
+authorization-protocol-data is authorization-method specific data that can
+be used in some way to generate the authorization.
+</para>
+
+<note><para>
+In this version of the extension, the only authorization method
+required to be supported is "MIT-MAGIC-COOKIE-1" with any amount
+of authorization-protocol-data (including none). The server may use the
+authorization-protocol-data as an additional source of randomness used
+to generate the authorization. Other authorization methods can supply
+their own interpretation of authorization-protocol-data.
+</para></note>
+
+<para>
+The value-mask and value-list specify attributes of the authorization
+that are to be explicitly initialized. The possible values are:
+</para>
+
+<informaltable>
+  <tgroup cols="3">
+    <tbody>
+      <row rowsep="1">
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para>Attribute</para>
+        </entry>
+        <entry align="left">
+          <para>Type</para>
+        </entry>
+        <entry align="left">
+          <para>Default</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>timeout</para>
+        </entry>
+        <entry align="left">
+          <para>CARD32</para>
+        </entry>
+        <entry align="left">
+          <para>60</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>group</para>
+        </entry>
+        <entry align="left">
+          <para>XID or None</para>
+        </entry>
+        <entry align="left">
+          <para>None</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>trust-level</para>
+        </entry>
+        <entry align="left">
+          <para>{SecurityClientTrusted,</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+        <entry align="left">
+          <para>SecurityClientUntrusted}</para>
+        </entry>
+        <entry align="left">
+          <para>SecurityClientUntrusted</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>event-mask</para>
+        </entry>
+        <entry align="left">
+          <para>SecurityAuthorizationRevoked,</para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para></para>
+        </entry>
+        <entry align="left">
+          <para>or None</para>
+        </entry>
+        <entry align="left">
+          <para>None</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+timeout is the timeout period in seconds for this authorization. A
+timeout value of zero means this authorization will never expire. For
+non-zero timeout values, when timeout seconds have elapsed since the
+last time that the authorization entered the state of having no
+connections authorized by it, and if no new connections used the
+authorization during that time, the authorization is automatically purged.
+(Note that when an authorization is created, it enters the state of having no
+connections authorized by it.) Subsequent connection attempts using that
+authorization will fail. This is to facilitate "fire and forget" launching of
+applications.
+</para>
+
+<para>
+group is an application group ID as defined by the Application Group
+extension, or None. Any other values will cause a Value error. When a
+group is destroyed, all authorizations specifying that group are revoked
+as described under the SecurityRevokeAuthorization request. The Application
+Group extension attaches additional semantics to the group.
+</para>
+
+<para>
+trust-level tells whether clients using the authorization are trusted or
+untrusted. If trust-level is not one of the constants SecurityClientTrusted
+or SecurityClientUntrusted, a Value error results.
+</para>
+
+<para>
+event-mask defines which events the client is interested in for this
+authorization.  When the authorization expires or is revoked if event-mask
+contains SecurityAuthorizationRevoked a SecurityAuthorizationRevoked event
+is reported to the client.
+</para>
+
+<para>
+The SecurityAuthorizationRevoked event contains the following field:
+</para>
+
+<informaltable>
+  <tgroup cols="2">
+    <tbody>
+      <row rowsep="1">
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para>Field</para>
+        </entry>
+        <entry align="left">
+          <para>Type</para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para>authorization-id</para>
+        </entry>
+        <entry align="left">
+          <para>AUTHID</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+where authorization-id is the identification of the authorization that was
+revoked.
+</para>
+<para>
+If an invalid value-mask is specified, a Value error occurs.
+</para>
+
+<para>
+The returned authorization-id is a non-zero value that uniquely identifies
+this authorization for use in other requests. The value space for type
+AUTHID is not required to be disjoint from values spaces of other core
+X types, e.g. resource ids, atoms, visual ids, and keysyms. Thus, a given
+numeric value might be both a valid AUTHID and a valid atom, for example.
+</para>
+
+<para>
+authorization-data-return is the data that a client should use in some
+authorization-method-specific way to make a connection with this
+authorization. For "MIT-MAGIC-COOKIE-1," authorization-data-return should
+be sent as the authorization-protocol-data in the connection setup message.
+It is not required that other authorization methods use
+authorization-data-return this way.
+</para>
+
+</sect1>
+
+<sect1 id="securityrevokeauthorization">
+<title>SecurityRevokeAuthorization</title>
+
+<para>
+This request deletes an authorization created by SecurityGenerateAuthorization.
+</para>
+
+<para>
+SecurityRevokeAuthorization
+</para>
+
+<informaltable>
+  <tgroup cols="2">
+    <tbody>
+      <row>
+        <entry align="left">
+          <para><emphasis remap='I'>authorization-id</emphasis></para>
+        </entry>
+        <entry align="left">
+          <para>AUTHID</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+Errors: <function>Authorization</function>
+</para>
+
+<para>
+If authorization-id does not name a valid authorization, an Authorization
+error occurs. Otherwise, this request kills all clients currently connected
+using the authorization specified by authorization-id. The authorization is
+deleted from the server's database, so future attempts by clients to connect
+with this authorization will fail.
+</para>
+
+</sect1>
+</chapter>
+
+<chapter id="changes_to_core_requests">
+<title>Changes to Core Requests</title>
+
+<para>
+A server supporting this extension modifies the handling of some core
+requests in the following ways.
+</para>
+<sect1 id="resource_id_usage">
+<title>Resource ID Usage</title>
+
+<para>
+If an untrusted client makes a request that specifies a resource ID that is
+not owned by another untrusted client, a protocol error is sent to the
+requesting client indicating that the specified resource does not exist.
+The following exceptions apply. An untrusted client can:
+</para>
+
+<orderedlist>
+  <listitem>
+    <para>
+use  the  QueryTree,  GetGeometry,  and  TranslateCoordinates  requests
+without restriction.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+use colormap IDs that are returned in the default-colormap field of its
+connection setup information in any colormap requests.
+    </para>
+  </listitem>
+  <listitem>
+     <para>specify a root window as:</para>
+     <orderedlist>
+       <listitem>
+         <para>
+the drawable field of CreatePixmap, CreateGC, and QueryBestSize.
+         </para>
+       </listitem>
+       <listitem>
+         <para>the parent field of CreateWindow.</para>
+       </listitem>
+       <listitem>
+         <para>
+the window field of CreateColormap, ListProperties, and GetWindowAttributes.
+         </para>
+       </listitem>
+       <listitem>
+         <para>the grab-window or confine-to fields of GrabPointer.
+         </para>
+       </listitem>
+       <listitem>
+         <para>the grab-window field of UngrabButton.</para>
+       </listitem>
+       <listitem>
+         <para>
+the destination of SendEvent, but only if all of the following are true.
+(These conditions cover all the events that the ICCCM specifies with
+a root window destination.)
+         </para>
+         <orderedlist>
+           <listitem>
+             <para>The propogate field of SendEvent is False.</para>
+           </listitem>
+           <listitem>
+             <para>
+The   event-mask   field   of   SendEvent   is   ColormapChange,
+StructureNotify, or the logical OR of SubstructureRedirect with
+SubstructureNotify.
+             </para>
+           </listitem>
+           <listitem>
+             <para>
+The event type being sent is UnmapNotify, ConfigureRequest, or
+ClientMessage.
+             </para>
+           </listitem>
+         </orderedlist>
+       </listitem>
+       <listitem>
+         <para>
+the window field of ChangeWindowAttributes, but only if the value-mask
+contains only event-mask and the corresponding value is StructureNotify,
+PropertyChange, or the logical OR of both.
+         </para>
+       </listitem>
+    </orderedlist>
+  </listitem>
+</orderedlist>
+
+<note>
+<para>
+ISSUE: are root window exceptions needed for these? WarpPointer, ReparentWindow
+(parent), CirculateWindow, QueryPointer (emacs does this), GetMotionEvents.
+</para>
+</note>
+
+</sect1>
+<sect1 id="extension_security">
+<title>Extension Security</title>
+
+<para>
+This extension introduces the notion of secure and insecure extensions. A
+secure extension is believed to be safe to use by untrusted clients; that
+is, there are no significant security concerns known that an untrusted
+client could use to destroy, modify, or steal data of trusted clients. This
+belief may be founded on a careful analysis of the extension protocol,
+its implementation, and measures taken to "harden" the extension to close
+security weaknesses. All extensions not considered secure are called
+insecure. The implementation details of how an extension is identified as
+secure or insecure are beyond the scope of this specification.
+</para>
+
+<para>
+<function>ListExtensions</function> will only return names of secure
+extensions to untrusted clients.
+</para>
+
+<para>
+If an untrusted client uses <function>QueryExtension</function> on an
+insecure extension that the server supports, the reply will have the
+present field set to False and the major-opcode field set to zero to
+indicate that the extension is not supported.
+</para>
+
+<para>
+If an untrusted client successfully guesses the major opcode of an
+insecure extension, attempts by it to execute requests with that major
+opcode will fail with a Request error.
+</para>
+
+</sect1>
+
+<sect1 id="keyboard_security">
+<title>Keyboard Security</title>
+
+
+<para>
+The protocol interpretation changes in this section are intended to prevent
+untrusted applications from stealing keyboard input that was meant for
+trusted clients and to prevent them from interfering with the use of the
+keyboard.
+</para>
+
+<para>
+The behavior of some keyboard-related requests and events is modified when
+the client is untrusted depending on certain server state at the time of
+request execution or event generation. Specifically, if a hypothetical
+keyboard event were generated given the current input focus, pointer
+position, keyboard grab state, and window event selections, and if that
+keyboard event would not be delivered to any untrusted client, the
+following changes apply:
+</para>
+
+<orderedlist>
+  <listitem>
+    <para>
+The bit vector representing the up/down state of the keys returned by
+<function>QueryKeymap</function> and
+<function>KeymapNotify</function> is all zeroes.
+    </para>
+  </listitem>
+  <listitem>
+    <para>GrabKeyboard returns a status of AlreadyGrabbed.</para>
+  </listitem>
+  <listitem>
+    <para>
+<function>SetInputFocus</function> does nothing. Note that this means the
+Globally Active
+Input and WM_TAKE_FOCUS mechanisms specified in the ICCCM will
+not work with untrusted clients.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Passive grabs established by GrabKey that would otherwise have activated
+do not activate.
+    </para>
+  </listitem>
+</orderedlist>
+
+<para>
+If an untrusted client attempts to use any of the following requests, the
+only effect is that the client receives an Access error: SetModifierMapping,
+ChangeKeyboardMapping, ChangeKeyboardControl.
+</para>
+
+<para>
+If an InputOnly window owned by an untrusted client has a parent owned by a
+trusted client, all attempts to map the window will be ignored. This includes
+mapping attempts resulting from MapWindow, MapSubwindows, ReparentWindow,
+and save-set processing.
+</para>
+<para>
+However, if the parent of an InputOnly window owned by an untrusted client
+is the root window, attempts to map that window will be performed as
+expected. This is in line with the root window exceptions above.
+</para>
+</sect1>
+
+<sect1 id="image_security">
+<title>Image Security</title>
+
+<para>
+It should be impossible for an untrusted client to retrieve the image
+contents of a trusted window unless a trusted client takes action to allow
+this. We introduce the following defenses in support of this requirement.
+</para>
+
+<para>
+The restrictions on resource ID usage listed above prevent untrusted clients
+from using GetImage directly on windows not belonging to trusted clients.
+</para>
+
+<para>
+If an untrusted client tries to set the background-pixmap attribute of an
+untrusted window to None, the server will instead use a server-dependent
+background which must be different than None.
+</para>
+
+<para>
+The X protocol description of <function>GetImage</function> states that the
+returned contents of regions of a window obscured by noninferior windows are
+undefined if the window has no backing store. Some implementations return the
+contents of the obscuring windows in these regions. When an untrusted client
+uses <function>GetImage</function>, this behavior is forbidden; the server must
+fill the obscured regions in the returned image with a server-dependent pattern.
+</para>
+
+<para>
+If an untrusted window has trusted inferiors, their contents are vulnerable
+to theft via <function>GetImage</function> on the untrusted parent, as well
+as being vulnerable to destruction via drawing with subwindow-mode
+IncludeInferiors on the untrusted parent. An untrusted window having trusted
+inferiors can only occur at the request of a trusted client. It is expected
+to be an unusual configuration.
+</para>
+
+</sect1>
+
+<sect1 id="property_security">
+
+<title>Property Security</title>
+
+<para>
+Unlike the other security provisions described in this document, security for
+property access is not amenable to a fixed policy because properties are
+used for inter-client communication in diverse ways and may contain data of
+varying degrees of sensitivity. Therefore, we only list the possible
+restrictions the server may decide to impose on use of properties on trusted
+windows by untrusted clients. How the server chooses which restrictions from
+this list to apply to a particular property access is implementation dependent
+  <footnote><para>
+In the X Consortium server implementation, property access is controlled by
+a configuration file; see the -sp option in the Xserver(1) manual page.
+  </para></footnote>.
+</para>
+
+<para>The X Protocol property requests are
+<function>ChangeProperty</function>,
+<function>GetProperty</function>,
+<function>DeleteProperty</function>,
+<function>RotateProperties</function>, and
+<function>ListProperties</function>. For these requests, the server can
+allow the request to execute normally (as if it had been issued by a
+trusted client), ignore the request completely (as if it were a NoOperation),
+or ignore the request except to send an Atom error to the client. Ignoring
+a <function>ListProperties</function> request means replying that
+the window has no properties. <function>ListProperties</function> may also
+reply with a subset of the existing properties if the server is doing
+property hiding; see below. An ignored <function>GetProperty</function>
+request may reply that the property does not exist, or that it exists but
+contains no data.
+</para>
+
+<para>
+The server may decide to hide certain properties on certain windows from
+untrusted clients
+  <footnote><para>
+The X Consortium server implementation does not currently provide a way to
+hide properties.
+  </para></footnote>.
+If a property is to be hidden, it must be done consistently to avoid
+confusing clients.  This means that for untrusted clients:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+That property should not be returned by
+<function>ListProperties</function>.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>PropertyNotify</function> events should not be sent for that
+property.</para>
+    </listitem>
+  <listitem>
+    <para>
+<function>GetProperty</function> on that property should reply that the
+property does not exist (the return type is None, the format and
+bytes-after are zero, and the value is empty).
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+For a property that the server is protecting but not hiding, consistency
+must also be maintained:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+That property should be returned by <function>ListProperties</function>.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>PropertyNotify</function> events should be sent for that property.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>GetProperty</function> on that property should reply that the
+property exists (if it really does) but the value is empty
+(return type and format are their real values, and the "length of value"
+field in the reply is zero).
+    </para>
+  </listitem>
+</itemizedlist>
+
+</sect1>
+
+<sect1 id="miscellaneous_security">
+<title>Miscellaneous Security</title>
+
+<para>
+If an untrusted client attempts to use
+<function>ChangeHosts</function>,
+<function>ListHosts</function>, or
+<function>SetAccessControl</function>,
+the only effect is that the client receives an Access error.
+</para>
+
+<para>
+If an untrusted client attempts to use <function>ConvertSelection</function>
+on a selection with a trusted selection owner window, the server generates
+a SelectionNotify event to the requestor with property None.
+</para>
+</sect1>
+</chapter>
+
+<chapter id="new_authorization_method">
+<title>New Authorization Method</title>
+
+<para>
+This extension includes a new authorization method named
+"XC-QUERY-SECURITY-1".  Its purpose is to allow an external agent such as
+the X firewall proxy to probe an X server to determine whether that server
+meets certain security criteria without requiring the agent to have its
+own authorization for that server. The agent may use the returned information
+to make a decision. For example, the X firewall proxy may choose not to
+forward client connections to servers that do not meet the criteria.
+</para>
+
+<para>
+To use this authorization method, the client (or proxy) sends
+"XC-QUERY-SECURITY-1" as the authorization-protocol-name in the initial
+connection setup message. The authorization-protocol-data may be empty or
+may contain additional security criteria desribed below. If the success
+field of the server's reply is Authenticate, the server supports the
+security extension, and the server meets all specified additional security
+criteria. In this case, the client should resend the initial connection
+setup message substituting the authorization protocol name and data
+that should be used to authorize the connection. If the success field of the
+server's reply is anything other than Authenticate, either the server does not
+support the security extension, does not meet (or cannot determine if it
+meets) all of the additional security criteria, or chooses for internal reasons
+not to answer with Authenticate. In this case, the client should close the
+connection.
+</para>
+
+<para>
+If the authorization-protocol-data sent with "XC-QUERY-SECURITY-1" is not
+empty, it specifies additional security criteria for the server to check, as
+follows.
+</para>
+
+<para>
+<function>authorization-protocol-data</function>
+</para>
+
+<informaltable>
+  <tgroup cols="2">
+    <tbody>
+      <row>
+        <entry align="left">
+          <para>policy-mask</para>
+        </entry>
+        <entry align="left">
+          <para>BITMASK</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>policies</para>
+        </entry>
+        <entry align="left">
+          <para>LISTofSECURITYPOLICY</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+The policy-mask field is any logical-OR combination of the constants
+Extensions and SitePolicies. For each bit set in policy-mask, there is a
+SECURITYPOLICY element in policies. The nth element in policies corresponds
+to the nth 1-bit in policy-mask, counting upward from bit 0.
+</para>
+
+<para><function>SECURITYPOLICY</function></para>
+
+<informaltable>
+  <tgroup cols="2">
+    <tbody>
+      <row>
+        <entry align="left">
+          <para>policy-type</para>
+        </entry>
+        <entry align="left">
+          <para>{Disallow, Permit}</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>names</para>
+        </entry>
+        <entry align="left">
+          <para>LISTofSTR</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+For a SECURITYPOLICY corresponding to policy-mask Extensions, if
+policy-type is Disallow the server is required to consider as insecure
+all extensions given in names.  No policy is specified for extensions
+not listed in names. If policy-type is Permit the server may consider
+only those extensions given in names to be secure; all other extensions
+must be treated as insecure. If these constraints are not met, the server
+should not return Authenticate in the success field of the reply.
+Servers can but need not dynamically configure themselves in response
+to an Extensions SECURITYPOLICY; a conforming server might simply compare
+the policy with a compiled-in table of extensions and their security status.
+</para>
+
+<para>
+For a SECURITYPOLICY corresponding to policy-mask SitePolicies, policy-type
+Disallow means the server must not have been configured with any of the site
+policies given in names. Policy-type Permit means the server must have
+been configured with at least one of the site policies given in names. If
+these constraints are not met, the server should not return Authenticate in
+the success field of the reply.
+</para>
+
+<para>
+SitePolicies provide a way to express new forms of security-relevant
+information that could not be anticipated at the time of this writing.
+For example, suppose the server is found to have a critical security defect.
+When a fix is developed, a site policy string could be associated with the
+fix. Servers with the fix would advertise that site policy, and the X
+firewall proxy would specify that site policy in a SECURITYPOLICY with
+policy-type Permit.
+</para>
+
+</chapter>
+
+<chapter id="encoding">
+<title>Encoding</title>
+
+<para>
+Please refer to the X11 Protocol Encoding document as this section
+uses syntactic conventions and data types established there.
+</para>
+
+<para>
+The name of this extension is "SECURITY".
+</para>
+
+<sect1 id="types">
+<title>Types</title>
+<para>
+AUTHID: CARD32
+</para>
+</sect1>
+
+<sect1 id="request_encoding">
+<title>Request Encoding</title>
+
+<para>
+SecurityQueryVersion
+</para>
+<literallayout remap='FD'>
+1         CARD8         major-opcode
+1         0                minor-opcode
+2         2              request length
+2         CARD16        client-major-version
+2         CARD16        client-minor-version
+=>
+1         1     Reply
+1               unused
+2         CARD16    sequence number
+4         0     reply length
+2         CARD16    server-major-version
+2         CARD16    server-minor-version
+20                            unused
+</literallayout>
+
+<para>
+<function>SecurityRevokeAuthorization</function>
+</para>
+
+<literallayout remap='FD'>
+1         CARD8          major-opcode
+1         2                  minor-opcode
+2         2                  request length
+4         AUTHID         authorization-id
+</literallayout>
+
+<para>
+SecurityGenerateAuthorization
+</para>
+
+<literallayout remap='FD'>
+1         CARD8              major-opcode
+1         1                      minor-opcode
+2         3 + (m+n+3)/4 + s  request length
+2         CARD16             m, number of bytes in authorization protocol name
+2         CARD16             n, number of bytes in authorization data
+m        STRING8             authorization protocol name
+n         STRING8            authorization protocol data
+p                                  unused, p=pad(m+n)
+4         BITMASK          value-mask (has s bits set to 1)
+       #x00000001          timeout
+       #x00000002          trust-level
+       #x00000004          group
+       #x00000008          event-mask
+4s        LISTofVALUE       value-list
+</literallayout>
+
+<para>
+VALUES
+</para>
+<literallayout remap='FD'>
+4      CARD32        timeout
+4                          trust-level
+       0                   SecurityClientTrusted
+       1                   SecurityClientUntrusted
+4      XID              group
+0                          None
+4      CARD32           event-mask
+       #x00000001       SecurityAuthorizationRevoked
+=>
+1         1               Reply
+1                         unused
+2         CARD16     sequence number
+4         (q+3)/4        reply length
+4         AUTHID       authorization-id
+2         CARD16       data-length
+18                        unused
+q         STRING8      authorization-data-return
+r                         unused, r=pad(q)
+</literallayout>
+
+</sect1>
+
+<sect1 id="event_encoding">
+<title>Event Encoding</title>
+<para>
+<function>SecurityAuthorizationRevoked</function>
+</para>
+
+<literallayout remap='FD'>
+1         0+extension event base        code
+1                                                 unused
+2         CARD16                             sequence number
+4         AUTHID                             authorization id
+24                                                unused
+</literallayout>
+
+</sect1>
+
+<sect1 id="authorization_method_encoding">
+<title>Authorization Method Encoding</title>
+
+<para>
+For authorization-protocol-name "XC-QUERY-SECURITY-1", the
+authorization-protocol-data is interpreted as follows:
+</para>
+
+<para>
+<function>authorization-protocol-data</function>
+</para>
+<literallayout remap='FD'>
+1         BITMASK                              policy-mask
+          #x00000001            Extensions
+          #x00000002            SitePolicies
+m        LISTofSECURITYPOLICY                  policies
+</literallayout>
+
+<para>
+<function>SECURITYPOLICY</function>
+</para>
+
+<literallayout remap='FD'>
+1                                                             policy-type
+          0                         Permit
+          1                         Disallow
+1         CARD8                                          number of STRs in names
+n         LISTofSTR                                      names
+</literallayout>
+
+<para>
+LISTofSTR has the same encoding as in the X protocol: each STR is a single
+byte length, followed by that many characters, and there is no padding or
+termination between STRs.
+</para>
+</sect1>
+
+</chapter>
+<chapter id="c_language_binding">
+<title>C Language Binding</title>
+
+<para>
+The header for this extension is &lt;X11/extensions/security.h&gt;. All
+identifier names provided by this header begin with XSecurity.
+</para>
+
+<para>
+All functions that have return type Status will return nonzero for
+success and zero for failure.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Status <function>XSecurityQueryExtension</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>XSecurityQueryExtension</function> sets major_version_return and
+minor_version_return to the major and minor Security protocol version
+supported by the server. If the Security library is compatible with the
+version returned by the server, it returns nonzero. If dpy does not support
+the Security 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 XSecurity functions may be called before this
+function. If a client violates this rule, the effects of all subsequent
+XSecurity calls that it makes are undefined.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Xauth *<function>XSecurityAllocXauth</function></funcdef>
+    <paramdef><parameter>void</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+<para>
+In order to provide for future evolution, Xauth structures are used to
+pass and return authorization data, and the library provides ways to
+allocate and deallocate them.
+</para>
+
+<para>
+<function>XSecurityAllocXauth</function> must be used to allocate the
+Xauth structure that is passed to
+<function>XSecurityGenerateAuthorization</function>.
+</para>
+
+<para>
+For the purposes of the Security extension, the Xauth structure has
+the following fields:
+</para>
+
+<informaltable>
+  <tgroup cols="3">
+    <tbody>
+      <row rowsep="1">
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para>Type</para>
+        </entry>
+        <entry align="left">
+          <para>Field name</para>
+        </entry>
+        <entry align="left">
+          <para>Description</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>unsigned short</para>
+        </entry>
+        <entry align="left">
+          <para>name_length</para>
+        </entry>
+        <entry align="left">
+          <para>number of bytes in name</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>char *</para>
+        </entry>
+        <entry align="left">
+          <para>name</para>
+        </entry>
+        <entry align="left">
+          <para>authorization protocol name</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>unsigned short</para>
+        </entry>
+        <entry align="left">
+          <para>data_length</para>
+        </entry>
+        <entry align="left">
+          <para>number of bytes in data</para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para>char *</para>
+        </entry>
+        <entry align="left">
+           <para>data</para>
+        </entry>
+        <entry align="left">
+          <para>authorization protocol data</para>
+        </entry>
+     </row>
+     <row>
+       <entry align="left">
+         <para></para>
+       </entry>
+     </row>
+     <row>
+       <entry align="left">
+         <para></para>
+       </entry>
+     </row>
+   </tbody>
+  </tgroup>
+</informaltable>
+<para>
+The Xauth structure returned by this function is initialized as follows:
+name_length and data_length are zero, and name and data are NULL.
+</para>
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void <function>XSecurityFreeXauth</function></funcdef>
+    <paramdef>Xauth<parameter> *auth</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSecurityFreeXauth</function> must be used to free Xauth
+structures allocated by
+<function>XSecurityAllocXauth</function> or returned by
+<function>XSecurityGenerateAuthorization</function>. It is the
+caller's responsibility to fill in the name and data fields of Xauth structures
+allocated with <function>XSecurityAllocXauth</function>, so this function
+will not attempt to free them. In contrast, all storage associated with
+Xauth structures returned from
+<function>XSecurityGenerateAuthorization</function> will be freed by this
+function, including the name and data fields.
+</para>
+
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Bool <function>XSecurityRevokeAuthorization</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSecurityAuthorization<parameter> auth_id</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSecurityRevokeAuthorization</function> deletes the authorization
+specified by auth_id, which must be a value returned in the auth_id_return
+parameter of <function>XSecurityGenerateAuthorization</function>. All
+clients that connected with that authorization are be killed. Subsequently,
+clients that attempt to connect using that authorization will be refused.
+</para>
+
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>Xauth *<function>XSecurityGenerateAuthorization</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>Xauth<parameter> *auth_in</parameter></paramdef>
+    <paramdef>unsigned long<parameter> valuemask</parameter></paramdef>
+    <paramdef>XSecurityAutorizationAttributes <parameter> *attributes</parameter></paramdef>
+    <paramdef>XSecurityAutorization<parameter> *auth_id_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSecurityGenerateAuthorization</function> creates a new
+authorization with the specified attributes. The auth_in argument must be
+allocated by <function>XSecurityAllocXauth</function>. The
+name and name_length fields of auth_in should be initialized to the
+authorization protocol name and its length in characters respectively.
+If there is authorization data, the data and data_length fields of
+auth_in should be initialized to the data and its length in characters
+respectivley. The library does not assume that name and data are
+null-terminated strings. The auth_in argument must be freed with
+<function>XSecurityFreeXauth</function>.
+</para>
+
+<para>
+The XSecurityAuthorizationAttributes structure has the following fields:
+</para>
+
+<informaltable>
+  <tgroup cols="3">
+    <tbody>
+      <row rowsep="1">
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para>Type</para>
+        </entry>
+        <entry align="left">
+          <para>Field name</para>
+        </entry>
+        <entry align="left">
+          <para>Mask</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>unsigned int</para>
+        </entry>
+        <entry align="left">
+          <para>trust_level</para>
+        </entry>
+        <entry align="left">
+          <para>XSecurityTrustLevel</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>unsigned int</para>
+        </entry>
+        <entry align="left">
+          <para>timeout</para>
+        </entry>
+        <entry align="left">
+          <para>XSecurityTimeout</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>XID</para>
+        </entry>
+        <entry align="left">
+          <para>group</para>
+        </entry>
+        <entry align="left">
+          <para>XSecurityGroup</para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para>long</para>
+        </entry>
+        <entry align="left">
+          <para>event_mask</para>
+        </entry>
+        <entry align="left">
+          <para>XSecurityEventMask</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+These correspond to the trust-level, timeout, group, and event-mask
+described in the SecurityGenerateAuthorization protocol request. The
+caller can fill in values for any subset of these attributes. The valuemask
+argument must be the bitwise OR of the symbols listed in the Mask column
+for all supplied attributes. The event_mask attribute can be None,
+XSecurityAuthorizationRevokedMask, or XSecurityAllEventMasks. In this
+revision of the protocol specification XSecurityAllEventMasks is equivalent
+to XSecurityAuthorizationRevokedMask. If the caller does not need to
+specify any attributes, the attributes argument can be NULL, and the
+valuemask argument must be zero.
+</para>
+<para>
+If the function fails, NULL is returned and auth_id_return is filled in
+with zero.  Otherwise, a pointer to an Xauth structure is returned. The name
+and name_length fields of the returned Xauth structure will be copies of the
+name that was passed in, and the data and data_length fields will be set to
+the authorization data returned by the server. The caller should not assume
+that name and data are null-terminated strings. If no authorization data was
+returned by the server, the data and data_length fields will be set to NULL
+and zero repectively. The returned Xauth structure must be freed with
+<function>XSecurityFreeXauth</function>; the caller should not use any other
+means free the structure or any of its components. The auth_id_return
+argument will be filled in with the non-zero authorization id of the created
+authorization.
+</para>
+
+<para>
+The XSecurityAuthorizationRevokedEvent structure has the following fields:
+</para>
+
+<informaltable>
+  <tgroup cols="3">
+    <tbody>
+      <row rowsep="1">
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para>Type</para>
+        </entry>
+        <entry align="left">
+          <para>Field name</para>
+        </entry>
+        <entry align="left">
+          <para>Description</para>
+        </entry>
+
+      </row>
+      <row>
+        <entry align="left">
+          <para>int</para>
+        </entry>
+        <entry align="left">
+          <para>type</para>
+        </entry>
+        <entry align="left">
+          <para>event base + XSecurityAuthorizationRevoked</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>unsigned long</para>
+        </entry>
+        <entry align="left">
+          <para>serial</para>
+        </entry>
+        <entry align="left">
+          <para># of last request processed by server</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>Bool</para>
+        </entry>
+        <entry align="left">
+          <para>send_event</para>
+        </entry>
+        <entry align="left">
+          <para>true if this came from SendEvent</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para>Display*</para>
+        </entry>
+        <entry align="left">
+          <para>display</para>
+        </entry>
+        <entry align="left">
+          <para>Display the event was read from</para>
+        </entry>
+      </row>
+      <row rowsep="1">
+        <entry align="left">
+          <para>XSecurityAuthorization</para>
+        </entry>
+        <entry align="left">
+          <para>auth_id</para>
+        </entry>
+        <entry align="left">
+          <para>revoked authorization id</para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+      <row>
+        <entry align="left">
+          <para></para>
+        </entry>
+      </row>
+    </tbody>
+  </tgroup>
+</informaltable>
+</chapter>
+</book>
diff --git a/specs/sync.xml b/specs/sync.xml
new file mode 100644
index 0000000..a8064a9
--- /dev/null
+++ b/specs/sync.xml
@@ -0,0 +1,1062 @@
+<?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">
+
+<!--translated from sync.tex, on 2010-06-29 10:52:00,
+by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/) xhtml,docbook,html,refcaption -->
+
+
+<book id="sync">
+
+<bookinfo>
+   <title>X Synchronization Extention Protocol</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>X Version 11, Release 6.6.84</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>
+   <corpname>X Consortium Standard</corpname>
+
+   <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.8</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 &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>
+
+<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 Await 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>
+<sect1 id="types">
+<title>Types</title>
+<para>
+Please refer to the X11 Protocol specification as this document uses
+syntactic conventions established there and references types defined there.
+</para>
+
+<para>The following new types are used by the extension.</para>
+
+<literallayout class="monospaced">
+INT64:                 64-bit signed integer
+COUNTER:               XID
+VALUETYPE:             {Absolute,Relative};
+TESTTYPE:              {PositiveTransition,NegativeTransition,
+                        PositiveComparison,NegativeComparison}
+TRIGGER:               [
+                        counter:COUNTER,
+                        value-type:VALUETYPE,
+                        wait-value:INT64,
+                        test-type:TESTTYPE
+                       ]
+WAITCONDITION:         [
+                        trigger:TRIGGER,
+                        event-threshold:INT64
+                       ]
+SYSTEMCOUNTER:         [
+                        name:STRING8,
+                        counter:COUNTER,
+                        resolution:INT64
+                       ]
+ALARM:                 XID
+ALARMSTATE:            {Active,Inactive,Destroyed}
+</literallayout>
+
+<para>
+The COUNTER type defines the client-side handle on a server
+<function>Counter</function>. The value of a counter is an INT64.
+</para>
+
+<para>
+The TRIGGER type defines a test on a counter that is either TRUE or FALSE. The
+value of the test is determined by the combination of a test value, the value
+of the counter, and the specified test-type.
+</para>
+
+<para>
+The test value for a trigger is calculated using the value-type and
+wait-value fields when the trigger is initialized. If the value-type field
+is not one of the named VALUETYPE constants, the request that initialized the
+trigger will return a <function>Value</function> error. If the value-type
+field is <function>Absolute</function>, the test value is given by the
+wait-value field. If the value-type field is <function>Relative</function>,
+the test value is obtained by adding the wait-value field to the value of the
+counter. If the resulting test value would lie outside the range for an
+INT64, the request that initialized the trigger will return a
+<function>Value</function> error. If counter is <function>None</function>
+and the value-type is <function>Relative</function>, the request that
+initialized the trigger will return a <function>Match</function> error. If
+counter is not None and does not name a valid counter, a Counter error is
+generated.
+</para>
+
+<para>
+If the test-type is <function>PositiveTransition</function>, the trigger is
+initialized to FALSE, and it will become TRUE when the counter changes from
+a value less than the test value to a value greater than or equal to the
+test value. If the test-type is <function>NegativeTransition</function>,
+the trigger is initialize to FALSE, and it will become TRUE when the counter
+changes from a value greater than the test value to a value less than or
+equal to the test value. If the test-type is
+<function>PositiveComparison</function>, the trigger is TRUE if the
+counter is greater than or equal to the test value and FALSE otherwise. If the
+test-type is <function>NegativeComparison</function>, the trigger is TRUE
+if the counter is less than or equal to the test value and FALSE otherwise.
+If the test-type is not one of the named TESTTYPE constants, the request that
+initialized the trigger will return a Value error. A trigger with a counter
+value of <function>None</function> and a valid test-type is always TRUE.
+</para>
+
+<para>
+The WAITCONDITION type is simply a trigger with an associated event-threshold.
+The event threshold is used by the <function>Await</function> request to
+decide whether or not to generate an event to the client after the trigger has
+become TRUE. By setting the event-threshold to an appropriate value, it is
+possible to detect the situation where an <function>Await</function> request
+was processed after the TRIGGER became TRUE, which usually indicates that
+the server is not processing requests as fast as the client expects.
+</para>
+
+<para>
+The SYSTEMCOUNTER type provides the client with information about a
+<function>System</function>Counter. The name field is the textual name of
+the counter that identifies the counter to the client. The counter field
+is the client-side handle that should be used in requests that require a
+counter. The resolution field gives the approximate step size of the system
+counter. This is a hint to the client
+that the extension may not be able to resolve two wait conditions with test
+values that differ by less than this step size. A microsecond clock, for
+example, may advance in steps of 64 microseconds, so a counter based on this
+clock would have a resolution of 64.
+</para>
+
+<para>
+The only system counter that is guaranteed to be present is called SERVERTIME,
+which counts milliseconds from some arbitrary starting point. The least
+significant 32 bits of this counter track the value of Time used by the
+server in Events and Requests. Other system counters may be provided by
+different implementations of the extension. The X Consortium will maintain a
+registry of system counter names to avoid collisions in the name space.
+</para>
+
+<para>
+An ALARM is the client-side handle on an <function>Alarm</function> resource.
+</para>
+</sect1>
+
+<sect1 id="errors">
+<title>Errors</title>
+
+<variablelist>
+  <varlistentry>
+    <term>Counter</term>
+    <listitem>
+      <para>
+This error is generated if the value for a COUNTER argument in a request
+does not name a defined COUNTER.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>Alarm</term>
+    <listitem>
+      <para>
+This error is generated if the value for an ALARM argument in a request
+does not name a defined ALARM.
+      </para>
+    </listitem>
+  </varlistentry>
+</variablelist>
+
+</sect1>
+<sect1 id="requests">
+
+<title>Requests</title>
+
+<variablelist>
+  <varlistentry>
+    <term>Initialize</term>
+    <listitem>
+<literallayout class="monospaced">
+version-major,version-minor: CARD8
+=>
+version-major,version-minor: CARD8
+</literallayout>
+
+     <para>
+This request must be executed before any other requests for this extension. If a
+client violates this rule, the results of all SYNC requests that it issues are
+undefined. The request takes the version number of the extension that the
+client wishes to use and returns the actual version number being implemented
+by the extension for this client. The extension may return different
+version numbers to a client depending of the version number supplied by
+that client. This request should be executed only once for each client
+connection.
+     </para>
+     <para>
+Given two different versions of the SYNC protocol, v1 and v2, v1 is
+compatible with v2 if and only if v1.version_major = v2.version_major
+and v1.version_minor &lt;= v2.version_minor.  Compatible means that the
+functionality is fully supported in an identical fashion in the two versions.
+     </para>
+     <para>
+This document describes major version 3, minor version 0 of the SYNC protocol.
+     </para>
+   </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>ListSystemCounters</term>
+    <listitem>
+<literallayout class="monospaced">
+=>
+system-counters: LISTofSYSTEMCOUNTER
+Errors: Alloc
+</literallayout>
+      <para>
+This request returns a list of all the system counters that are available at
+the time the request is executed, which includes the system counters
+that are maintained by other extensions. The list returned by this
+request may change as counters are created and destroyed by other extensions.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+  <term>CreateCounter</term>
+  <listitem>
+<literallayout class="monospaced">
+id: COUNTER
+initial-value: INT64
+Errors: IDChoice,Alloc
+</literallayout>
+      <para>
+This request creates a counter and assigns the specified id to it. The counter
+value is initialized to the specified initial-value and there are no clients
+waiting on the counter.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>DestroyCounter</term>
+    <listitem>
+<literallayout class="monospaced">
+counter: COUNTER
+Errors: Counter,Access
+</literallayout>
+      <para>
+This request destroys the given counter and sets the counter fields for all
+triggers that specify this counter to <function>None</function>. All clients
+waiting on the counter are released and a <function>CounterNotify</function>
+event with the destroyed field set to TRUE is sent to each waiting client,
+regardless of the event-threshold. All alarms specifying the counter become
+<function>Inactive</function> and an <function>AlarmNotify</function>
+event with a state field of <function>Inactive</function> is generated. A
+counter is destroyed automatically when the connection to the creating client
+is closed down if the close-down mode is Destroy. An
+<function>Access</function> error is generated if counter is a system
+counter. A <function>Counter</function> error is generated if counter does
+not name a valid counter.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>QueryCounter</term>
+    <listitem>
+<literallayout class="monospaced">
+counter: COUNTER
+=>
+value: INT64
+Errors: <function>Counter</function>
+</literallayout>
+      <para>
+This request returns the current value of the given counter or a generates
+Counter error if counter does not name a valid counter.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>Await</term>
+    <listitem>
+<literallayout class="monospaced">
+wait-list: LISTofWAITCONDITION
+Errors: Counter,Alloc,Value
+</literallayout>
+      <para>
+When this request is executed, the triggers in the wait-list are initialized
+using the wait-value and value-type fields, as described in the definition of
+TRIGGER above. The processing of further requests for the client is blocked
+until one or more of the triggers becomes TRUE. This may happen immediately,
+as a result of the initialization, or at some later time, as a result of
+a subsequent <function>SetCounter</function>,
+<function>ChangeCounter</function> or
+<function>DestroyCounter</function> request.
+      </para>
+      <para>
+A Value error is generated if wait-list is empty.
+      </para>
+      <para>
+When the client becomes unblocked, each trigger is checked to determine
+whether a <function>CounterNotify</function> event should be generated.
+The difference between the counter and the test value is calculated by
+subtracting the test value from the value of the counter. If the test-type
+is <function>PositiveTransition</function> or
+<function>PositiveComparison</function>, a
+<function>CounterNotify</function> event is generated if the difference is
+at least event-threshold. If the test-type is
+<function>NegativeTransition</function> or
+<function>NegativeComparison</function>, a
+<function>CounterNotify</function> event is generated if the difference
+is at most event-threshold. If the difference lies outside the range for an
+INT64, an event is not generated.
+      </para>
+      <para>
+This threshold check is made for each trigger in the list and a
+<function>CounterNotify</function> event is generated for every trigger for
+which the check succeeds. The check for
+<function>CounterNotify</function> events is performed even if one of the
+triggers is TRUE when the request is first executed. Note that a
+<function>CounterNotify</function> event may be generated for a trigger
+that is FALSE if there are multiple triggers in the request. A
+<function>CounterNotify</function> event with the destroyed flag set to
+TRUE is always generated if the counter for one of the triggers is
+destroyed.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>ChangeCounter</term>
+    <listitem>
+<literallayout class="monospaced">
+counter: COUNTER
+amount: INT64
+Errors: <function>Counter,Access,Value</function>
+</literallayout>
+      <para>
+This request changes the given counter by adding amount to the current
+counter value. If the change to this counter satisfies a trigger for which a client
+is waiting, that client is unblocked and one or more
+<function>CounterNotify</function> events may be generated. If the change to
+the counter satisfies the trigger for an alarm, an
+<function>AlarmNotify</function> event is generated and the
+alarm is updated. An <function>Access</function> error is generated if
+counter is a system counter. A <function>Counter</function> error is
+generated if counter does not name a valid counter. If the resulting value
+for the counter would be outside the range for an INT64, a
+<function>Value</function> error is generated and the counter is not changed.
+      </para>
+      <para>
+It should be noted that all the clients whose triggers are satisfied by this
+change are unblocked, so this request cannot be used to implement mutual
+exclusion.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>SetCounter</term>
+    <listitem>
+<literallayout class="monospaced">
+counter: COUNTER
+value: INT64
+Errors: <function>Counter,Access</function>
+</literallayout>
+      <para>
+This request sets the value of the given counter to value. The effect is
+equivalent to executing the appropriate ChangeCounter request to change
+the counter value to value. An Access error is generated if counter names a
+system counter. A Counter error is generated if counter does not name a valid
+counter.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>CreateAlarm</term>
+    <listitem>
+<literallayout class="monospaced">
+id: ALARM
+values-mask: CARD32
+values-list: LISTofVALUE
+left">Errors: IDChoice,Counter,Match,Value,Alloc
+</literallayout>
+      <para>
+This request creates an alarm and assigns the identifier id to it. The
+values-mask and values-list specify the attributes that are to be explicitly
+initialized. The attributes for an Alarm and their defaults are:
+      </para>
+      <informaltable>
+        <tgroup cols="4">
+          <colspec colname="c1"/>
+          <colspec colname="c2"/>
+          <colspec colname="c3"/>
+          <colspec colname="c4"/>
+          <tbody>
+            <row>
+              <entry align="left">Attribute</entry>
+              <entry align="left">Type</entry>
+              <entry align="left">Default</entry>
+            </row>
+            <row role="hline">
+              <entry rowsep="1"></entry>
+              <entry rowsep="1"></entry>
+              <entry rowsep="1"></entry>
+              <entry rowsep="1"></entry>
+            </row>
+            <row>
+              <entry align="left">trigger</entry>
+              <entry align="left">TRIGGER</entry>
+              <entry align="left">counter</entry>
+              <entry align="left">None</entry>
+            </row>
+            <row>
+              <entry align="left"></entry>
+              <entry align="left"></entry>
+              <entry align="left">value-type</entry>
+              <entry align="left">Absolute</entry>
+            </row>
+            <row>
+              <entry align="left"></entry>
+              <entry align="left"></entry>
+              <entry align="left">value</entry>
+              <entry align="left">0</entry>
+            </row>
+            <row>
+              <entry align="left"></entry>
+              <entry align="left"></entry>
+              <entry align="left">test-type</entry>
+              <entry align="left">PositiveComparison</entry>
+            </row>
+            <row>
+              <entry align="left">delta</entry>
+              <entry align="left">INT64</entry>
+              <entry align="left">1</entry>
+            </row>
+            <row>
+              <entry align="left">events</entry>
+              <entry align="left">BOOL</entry>
+              <entry align="left">TRUE</entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </informaltable>
+      <para>
+The trigger is initialized as described in the definition of TRIGGER, with an
+error being generated if necessary.
+      </para>
+      <para>
+If the counter is <function>None</function>, the state of the alarm is set
+to <function>Inactive</function>, else it is set to Active.
+      </para>
+      <para>
+Whenever the trigger becomes TRUE, either as a result of this request or as the
+result of a <function>SetCounter</function>,
+<function>ChangeCounter</function>, <function>DestroyCounter</function>, or
+<function>ChangeAlarm</function> request, an
+<function>AlarmNotify</function> event is generated and the alarm is
+updated. The alarm is updated by repeatedly adding delta to the value of the
+trigger and reinitializing it until it becomes FALSE. If this update would
+cause value to fall outside the range for an INT64, or if the counter
+value is <function>None</function>, or if the delta is 0 and test-type
+is <function>PositiveComparison</function> or
+<function>NegativeComparison</function>, no change is made to value and
+the alarm state is changed to <function>Inactive</function> before the
+event is generated. No further events are generated by an
+<function>Inactive</function> alarm until a <function>ChangeAlarm</function>
+or <function>DestroyAlarm </function> request is executed.
+      </para>
+      <para>
+If the test-type is <function>PositiveComparison</function> or
+<function>PositiveTransition and</function> delta is less than zero, or
+if the test-type is <function>NegativeComparison</function> or
+<function>NegativeTransition</function> and delta is greater than zero,
+a <function>Match</function> error is generated.
+      </para>
+      <para>
+The events value enables or disables delivery of
+<function>AlarmNotify</function> events
+to the requesting client. The alarm keeps a separate event flag for
+each client so that other clients may select to receive events from this
+alarm.
+      </para>
+      <para>
+An <function>AlarmNotify</function> event is always generated at some time
+after the execution of a <function>CreateAlarm</function> request. This
+will happen immediately if the trigger is TRUE, or it will happen later
+when the trigger becomes TRUE or the Alarm is destroyed.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>ChangeAlarm</term>
+    <listitem>
+<literallayout class="monospaced">
+id: ALARM
+values-mask: CARD32
+values-list: LISTofVALUE
+Errors: Alarm,Counter,Value,Match
+</literallayout>
+      <para>
+This request changes the parameters of an Alarm. All of the parameters
+specified for the <function>CreateAlarm</function> request may be changed
+using this request.  The trigger is reinitialized and an
+<function>AlarmNotify</function> event is generated if appropriate, as
+explained in the description of the <function>CreateAlarm</function> request.
+      </para>
+      <para>
+Changes to the events flag affect the event delivery to the requesting
+client only and may be used by a client to select or deselect event delivery
+from an alarm created by another client.
+      </para>
+      <para>
+The order in which attributes are verified and altered is server-dependent.
+If an error is generated, a subset of the attributes may have been altered.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>DestroyAlarm</term>
+    <listitem>
+<literallayout class="monospaced">
+alarm: ALARM
+Errors: Alarm
+</literallayout>
+      <para>
+This request destroys an alarm. An alarm is automatically destroyed when the
+creating client is closed down if the close-down mode is
+<function>Destroy</function>. When an alarm is destroyed, an
+<function>AlarmNotify</function> event is generated with a state value of
+<function>Destroyed</function>.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>QueryAlarm</term>
+    <listitem>
+<literallayout class="monospaced">
+alarm: ALARM
+=>
+trigger: TRIGGER
+delta: INT64
+events: ALARMEVENTMASK
+state: ALARMSTATE
+Errors: <function>Alarm</function>
+</literallayout>
+      <para>This request retrieves the current parameters for an Alarm.</para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>SetPriority</term>
+    <listitem>
+<literallayout class="monospaced">
+client-resource: XID
+priority: INT32
+Errors: <function>Match</function>
+</literallayout>
+      <para>
+This request changes the scheduling priority of the client that created
+client-resource. If client-resource is <function>None</function>, then
+the priority for the client making the request is changed. A
+<function>Match</function> error is generated if client-resource is not
+<function>None</function> and does not name an existing resource in the
+server. For any two priority values, A and B, A is higher priority if
+and only if A is greater than B.
+      </para>
+      <para>
+The priority of a client is set to 0 when the initial client connection is
+ made.
+      </para>
+      <para>
+The effect of different client priorities depends on the particular
+implementation of the extension, and in some cases it may have no effect at
+all. However, the intention is that higher priority clients will have
+their requests executed before those of lower priority clients.
+      </para>
+      <para>
+For most animation applications, it is desirable that animation clients be
+given priority over nonrealtime clients. This improves the smoothness of the
+animation on a loaded server. Because a server is free to implement very strict
+priorities, processing requests for the highest priority client to the
+exclusion of all others, it is important that a client that may potentially
+monopolize the whole server, such as an animation that produces continuous
+output as fast as it can with no rate control, is run at low rather than high
+priority.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>GetPriority</term>
+    <listitem>
+<literallayout class="monospaced">
+client-resource: XID
+=>
+priority: INT32
+Errors: <function>Match</function>
+</literallayout>
+      <para>
+This request returns the scheduling priority of the client that created
+client-resource. If client-resource is <function>None</function>, then the
+priority for the client making the request is returned. A
+<function>Match</function> error is generated if client-resource is
+not <function>None</function> and does not name an existing resource in the
+server.
+      </para>
+    </listitem>
+  </varlistentry>
+</variablelist>
+</sect1>
+
+<sect1 id="events">
+<title>Events</title>
+
+<variablelist>
+  <varlistentry>
+    <term>CounterNotify</term>
+    <listitem>
+<literallayout class="monospaced">
+counter: COUNTER
+wait-value: INT64
+counter-value: INT64
+time: TIME
+count: CARD16
+destroyed: BOOL
+</literallayout>
+      <para>
+<function>CounterNotify</function> events may be generated when a client
+becomes unblocked after an <function>Await</function> request has been
+processed. The wait-value is the value being waited for, and counter-value
+is the actual value of the counter at the time the event was generated.
+The destroyed flag is TRUE if this request was generated as the result of
+the destruction of the counter and FALSE otherwise. The time is the server
+time at which the event was generated.
+      </para>
+      <para>
+When a client is unblocked, all the <function>CounterNotify</function>
+events for the Await request are generated contiguously. If count is 0,
+there are no more events to follow for this request. If count is n,
+there are at least n more events to follow.
+      </para>
+    </listitem>
+  </varlistentry>
+  <varlistentry>
+    <term>AlarmNotify</term>
+    <listitem>
+<literallayout class="monospaced">
+alarm: ALARM
+counter-value: INT64
+alarm-value: INT64
+state: ALARMSTATE
+time: TIME
+</literallayout>
+      <para>
+An <function>AlarmNotify</function> event is generated when an alarm is
+triggered. alarm-value is the test value of the trigger in the alarm when
+it was triggered, counter-value is the value of the counter that triggered
+the alarm, and time is the server time at which the event was generated.
+The state is the new state of the alarm. If state is
+<function>Inactive</function>, no more events will be generated by this
+alarm until a <function>ChangeAlarm</function> request is executed, the alarm
+is destroyed, or the counter for the alarm is destroyed.
+      </para>
+    </listitem>
+  </varlistentry>
+</variablelist>
+</sect1>
+</chapter>
+
+<chapter id="encoding">
+<title>Encoding</title>
+<para>
+Please refer to the X11 Protocol Encoding document as this section uses
+syntactic conventions established there and references types defined there.
+</para>
+<para>The name of this extension is "SYNC".</para>
+
+<sect1 id="encoding_new_types">
+<title>Encoding New Types</title>
+<para>
+The following new types are used by the extension.
+</para>
+
+<literallayout class="monospaced">
+ALARM: CARD32
+ALARMSTATE:
+       0         Active
+       1         Inactive
+       2         Destroyed
+COUNTER: CARD32
+INT64: 64-bit signed integer
+SYSTEMCOUNTER:
+       4         COUNTER                 counter
+       8         INT64                   resolution
+       2         n                       length of name in bytes
+       n         STRING8                 name
+       p                                 pad,p=pad(n+2)
+TESTTYPE:
+       0         PositiveTransition
+       1         NegativeTransition
+       2         PositiveComparison
+       3         NegativeComparison
+TRIGGER:
+       4         COUNTER                 counter
+       4         VALUETYPE               wait-type
+       8         INT64                   wait-value
+       4         TESTTYPE                test-type  VALUETYPE:
+       0         Absolute
+       1         Relative
+WAITCONDITION:
+       20        TRIGGER                 trigger
+       8         INT64                   event threshold
+</literallayout>
+
+<para>
+An INT64 is encoded in 8 bytes with the most significant 4 bytes
+first followed by the least significant 4 bytes. Within these 4-byte
+groups, the byte ordering determined during connection setup is used.
+</para>
+</sect1>
+
+<sect1 id="encoding_errors">
+<title>Encoding Errors</title>
+<literallayout class="monospaced">
+<function>Counter</function>
+        1    0            Error
+        1    Base + 0     code
+        2    CARD16       sequence number
+        4    CARD32       bad counter
+        2    CARD16       minor opcode
+        1    CARD8        major opcode
+        21                unused
+<function>Alarm</function>
+        1    0            Error
+        1    Base + 1     code
+        2    CARD16       sequence number
+        4    CARD32       bad alarm
+        2    CARD16       minor opcode
+        1    CARD8        major opcode
+        21                unused
+</literallayout>
+
+</sect1>
+
+<sect1 id="encoding_requests">
+<title>Encoding Requests</title>
+
+<literallayout class="monospaced">
+<function>Initialize</function>
+        1    CARD8        major opcode
+        1    0            minor opcode
+        2    2            request length
+        1    CARD8        major version
+        1    CARD8        minor version
+        2                 unused
+=>
+        1    1            Reply
+        1                 unused
+        2    CARD16       sequence number
+        4    0            reply length
+        1    CARD8        major version
+        1    CARD8        minor version
+        2                 unused
+        20                unused
+
+<function>ListSystemCounters</function>
+        1    CARD8                  major opcode
+        1    1                      minor opcode
+        2    1                      request length
+=>
+        1    1                      Reply
+        1                           unused
+        2    CARD16                 sequence number
+        4    0                      reply length
+        4    INT32                  list length
+        20                          unused
+        4n   list of SYSTEMCOUNTER  system counters
+
+<function>CreateCounter</function>
+        1    CARD8                  major opcode
+        1    2                      minor opcode
+        2    4                      request length
+        4    COUNTER                id
+        8    INT64                  initial value
+
+<function>DestroyCounter</function>
+        1    CARD8                  major opcode
+        1    6                      minor opcode<footnote><para>A previous version of this document gave an incorrect minor opcode</para></footnote>
+        2    2                      request length
+        4    COUNTER                counter
+=>
+        1    1                      Reply
+        1                           unused
+        2    CARD16                 sequence number
+        4    0                      reply length
+        8    INT64                  counter value
+        16                          unused
+
+Await
+        1    CARD8                  major opcode
+        1    7                      minor opcode<footnote><para>A previous version of this document gave an incorrect minor opcode.</para></footnote>
+        2    1 + 7*n                request length
+        28n  LISTofWAITCONDITION    wait conditions
+
+ChangeCounter
+        1    CARD8                  major opcode
+        1    4                      minor opcode<footnote><para>A previous version of this document gave an incorrect minor opcode.</para></footnote>
+        2    4                      request length
+        4    COUNTER                counter
+        8    INT64                  amount
+
+SetCounter
+        1    CARD8                  major opcode
+        1    3                      minor opcode<footnote><para>A previous version of this document gave an incorrect minor opcode.</para></footnote>
+        2    4                      request length
+        4    COUNTER                counter
+        8    INT64                  value
+
+CreateAlarm
+        1    CARD8                  major opcode
+        1    8                      minor opcode
+        2    3+n                    request length
+        4    ALARM                  id
+        4    BITMASK                values mask
+
+             #x00000001             counter
+             #x00000002             value-type
+             #x00000004             value
+             #x00000008             test-type
+             #x00000010             delta
+             #x00000020             events
+
+        4n   LISTofVALUE            values
+
+VALUES
+        4    COUNTER                counter
+        4    VALUETYPE              value-type
+        8    INT64                  value
+        4    TESTTYPE               test-type
+        8    INT64                  delta
+        4    BOOL                   events
+
+ChangeAlarm
+        1    CARD8                  major opcode
+        1    9                      minor opcode
+        2    3+n                    request length
+        4    ALARM                  id
+        4    BITMASK                values mask
+             encodings as for <function>CreateAlarm</function>
+        4n   LISTofVALUE            values
+             encodings as for <function>CreateAlarm</function>
+
+DestroyAlarm
+        1    CARD8        major opcode
+        1    11           minor opcode<footnote><para>A previous version of this document gave an incorrect minor opcode.</para></footnote>
+        2    2            request length
+        4    ALARM        alarm
+
+QueryAlarm
+        1    CARD8        major opcode
+        1    10           minor opcode<footnote><para>A previous version of this document gave an incorrect minor opcode.</para></footnote>
+        2    2            request length
+        4    ALARM        alarm
+=>
+        1    1            Reply
+        1                 unused
+        2    CARD16       sequence number
+        4    2            reply length
+        20   TRIGGER      trigger
+        8    INT64        delta
+        1    BOOL         events
+        1    ALARMSTATE   state
+        2                 unused
+
+SetPriority
+        1    CARD8        major opcode
+        1    12           minor opcode
+        2    3            request length
+        4    CARD32       id
+        4    INT32        priority
+
+GetPriority
+        1    CARD8        major opcode
+        1    13           minor opcode
+        2    1            request length
+        4    CARD32       id
+=>
+        1    1            Reply
+        1                 unused
+        2    CARD16       sequence number
+        4    0            reply length
+        4    INT32        priority
+        20                unused
+
+</literallayout>
+
+</sect1>
+
+<sect1 id="encoding_events">
+<title>Encoding Events</title>
+
+<literallayout class="monospaced">
+<function>CounterNotify</function>
+        1    Base + 0     code
+        1    0            kind
+        2    CARD16       sequence number
+        4    COUNTER      counter
+        8    INT64        wait value
+        8    INT64        counter value
+        4    TIME         timestamp
+        2    CARD16       count
+        1    BOOL         destroyed
+        1                 unused
+
+<function>AlarmNotify</function>
+        1    Base + 1     code
+        1    1            kind
+        2    CARD16       sequence number
+        4    ALARM        alarm
+        8    INT64        counter value
+        8    INT64        alarm value
+        4    TIME         timestamp
+        1    ALARMSTATE   state
+        3                 unused
+</literallayout>
+</sect1>
+</chapter>
+</book>