Merge remote-tracking branch 'origin/released'

Conflicts:
	libX11/specs/i18n/trans/trans.xml
	mesalib/src/glsl/glsl_parser_extras.cpp
	mesalib/src/glsl/ir_print_visitor.cpp
	xorg-server/xkeyboard-config/rules/base.xml.in
	xorg-server/xkeyboard-config/rules/xkb.dtd
	xorg-server/xkeyboard-config/symbols/de

4 files changed, 2537 insertions, 2537 deletions

diff --git a/libXext/specs/dbelib.xml b/libXext/specs/dbelib.xml
index c786cae81..5a969a287 100644
--- a/libXext/specs/dbelib.xml
+++ b/libXext/specs/dbelib.xml
@@ -1,728 +1,728 @@
-<?xml version="1.0" encoding="UTF-8" ?>

-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"

-                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">

-

-

-<!-- lifted from troff+ms+XMan by doclifter -->

-<book id="dbelib">

-

-<bookinfo>

-   <title>Double Buffer Extension Library</title>

-   <subtitle>X Consortium Standard</subtitle>

-   <!-- <releaseinfo>X Version 11, Release 6.4</releaseinfo> -->

-   <authorgroup>

-      <author>

-         <firstname>Ian</firstname><surname>Elliot</surname>

-      </author>

-   </authorgroup>

-   <othercredit>

-      <firstname>Davide</firstname><surname>Wiggins</surname>

-   </othercredit>

-   <corpname>Hewlett-Packard Company</corpname>

-   <copyright><year>1989</year><holder>X Consortium, Inc and Digital Equipment Corporation</holder></copyright>

-   <copyright><year>1992</year><holder>X Consortium, Inc and Intergraph Corporation</holder></copyright>

-   <copyright><year>1993</year><holder>X Consortium, Inc and Silicon Graphics, Inc.</holder></copyright>

-   <copyright><year>1994</year><holder>X Consortium, Inc and Hewlett-Packard Company</holder></copyright>

-   <copyright><year>1995</year><holder>X Consortium, Inc and Hewlett-Packard Company</holder></copyright>

-   <releaseinfo>Version 1.0</releaseinfo>

-   <affiliation><orgname>X Consortium</orgname></affiliation>

-   <productnumber>X Version 11, Release 7</productnumber>

-

-<legalnotice>

-<para>

-Permission to use, copy, modify, and distribute this documentation for any

-purpose and without fee is hereby granted, provided that the above copyright

-notice and this permission notice appear in all copies. Digital Equipment

-Corporation, Intergraph Corporation, Silicon Graphics, Hewlett-Packard, and

-the X Consortium make no representations about the suitability for any

-purpose of the information in this document. This documentation is provided

-"as is" without express or implied warranty.

-</para>

-

-</legalnotice>

-

-</bookinfo>

-

-<chapter id="introduction">

-<title>Introduction</title>

-<para>

-The Double Buffer Extension (DBE) provides a standard way to utilize

-double-buffering within the framework of the X Window System.

-Double-buffering uses two buffers, called front and back, which hold images.

-The front buffer is visible to the user; the back buffer is not. Successive

-frames of an animation are rendered into the back buffer while the previously

-rendered frame is displayed in the front buffer. When a new frame is ready,

-the back and front buffers swap roles, making the new frame visible. Ideally,

-this exchange appears to happen instantaneously to the user and with no

-visual artifacts. Thus, only completely rendered images are presented to the

-user, and they remain visible during the entire time it takes to render a new

-frame. The result is a flicker-free animation.

-</para>

-

-</chapter>

-

-<chapter id="goals">

-<title>Goals</title>

-

-<para>

-This extension should enable clients to:

-</para>

-<itemizedlist>

-  <listitem>

-    <para>

-Allocate and deallocate double-buffering for a window.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Draw to and read from the front and back buffers associated with a window.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Swap the front and back buffers associated with a window.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Specify a wide range of actions to be taken when a window is swapped.

-This includes explicit, simple swap actions (defined below), and more

-complex actions (for example, clearing ancillary buffers) that can be put

-together within explicit "begin" and "end" requests (defined below).

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Request that the front and back buffers associated with multiple

-double-buffered windows be swapped simultaneously.

-    </para>

-  </listitem>

-</itemizedlist>

-

-<para>

-In addition, the extension should:

-</para>

-<itemizedlist>

-  <listitem>

-    <para>

-Allow multiple clients to use double-buffering on the same window.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Support a range of implementation methods that can capitalize on

-existing hardware features.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Add no new event types.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Be reasonably easy to integrate with a variety of direct graphics

-hardware access (DGHA) architectures.

-    </para>

-  </listitem>

-</itemizedlist>

-

-</chapter>

-

-<chapter id="concepts">

-<title>Concepts</title>

-<para>

-Normal windows are created using the core CreateWindow request, which

-allocates a set of window attributes and, for InputOutput windows, a front

-buffer, into which an image can be drawn. The contents of this buffer will be

-displayed when the window is visible.

-</para>

-<para>

-This extension enables applications to use double-buffering with a window.

-This involves creating a second buffer, called a back buffer, and associating

-one or more back buffer names (XIDs) with the window for use when referring

-to (that is, drawing to or reading from) the window’s back buffer. The back

-buffer name is a DRAWABLE of type BACKBUFFER.

-</para>

-<para>

-DBE provides a relative double-buffering model. One XID, the window,

-always refers to the front buffer. One or more other XIDs, the back buffer

-names, always refer to the back buffer. After a buffer swap, the window

-continues to refer to the (new) front buffer, and the back buffer name

-continues to refer to the (new) back buffer. Thus, applications and toolkits

-that want to just render to the back buffer always use the back buffer name

-for all drawing requests to the window. Portions of an application that want

-to render to the front buffer always use the window XID for all drawing

-requests to the window.

-</para>

-<para>

-Multiple clients and toolkits can all use double-buffering on the same window.

-DBE does not provide a request for querying whether a window has

-double-buffering support, and if so, what the back buffer name is. Given the

-asynchronous nature of the X Window System, this would cause race

-conditions. Instead, DBE allows multiple back buffer names to exist for the

-same window; they all refer to the same physical back buffer. The first time a

-back buffer name is allocated for a window, the window becomes

-double-buffered and the back buffer name is associated with the window.

-Subsequently, the window already is a double-buffered window, and nothing

-about the window changes when a new back buffer name is allocated, except

-that the new back buffer name is associated with the window. The window

-remains double-buffered until either the window is destroyed or until all of the

-back buffer names for the window are deallocated.

-</para>

-<para>

-In general, both the front and back buffers are treated the same.

-particular, here are some important characteristics:

-</para>

-<itemizedlist>

-  <listitem>

-    <para>

-Only one buffer per window can be visible at a time (the front buffer).

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Both buffers associated with a window have the same visual type, depth,

-width, height, and shape as the window.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Both buffers associated with a window are "visible" (or "obscured") in

-the same way. When an Expose event is generated for a window, both

-buffers should be considered to be damaged in the exposed area.

-Damage that occurs to either buffer will result in an Expose event on

-the window. When a double-buffered window is exposed, both buffers

-are tiled with the window background, exactly as stated by the core

-protocol. Even though the back buffer is not visible, terms such as

-obscure apply to the back buffer as well as to the front buffer.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-It is acceptable at any time to pass a BACKBUFFER in any request,

-notably any core or extension drawing request, that expects a

-DRAWABLE.  This enables an application to draw directly into

-BACKBUFFERs in the same fashion as it would draw into any other

-DRAWABLE.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-It is an error (Window) to pass a BACKBUFFER in a core request that

-expects a Window.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-A BACKBUFFER will never be sent by core X in a reply, event, or

-error where a Window is specified.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-If core X11 backing-store and save-under applies to a double-buffered

-window, it applies to both buffers equally.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-If the core ClearArea request is executed on a double-buffered window,

-the same area in both the front and back buffers is cleared.

-    </para>

-  </listitem>

-</itemizedlist>

-

-<para>

-The effect of passing a window to a request that accepts a

-<function>DRAWABLE</function> is

-unchanged by this extension. The window and front buffer are synonomous

-with each other. This includes obeying the <function>GetImage</function>

-semantics and the

-subwindow-mode semantics if a core graphics context is involved. Regardless

-of whether the window was explicitly passed in a

-<function>GetImage</function> request, or

-implicitly referenced (that is, one of the window’s ancestors was passed in the

-request), the front (that is, visible) buffer is always referenced. Thus,

-DBE-naive screen dump clients will always get the front buffer.

-<function>GetImage</function> on

-a back buffer returns undefined image contents for any obscured regions of the

-back buffer that fall within the image.

-</para>

-<para>

-Drawing to a back buffer always uses the clip region that would be used to

-draw to the front buffer with a GC subwindow-mode of

-<function>ClipByChildren</function>. If

-an ancestor of a double-buffered window is drawn to with a core GC having a

-subwindow-mode of IncludeInferiors, the effect on the double-buffered

-window’s back buffer depends on the depth of the double-buffered window

-and the ancestor. If the depths are the same, the contents of the back buffer

-of the double-buffered window are not changed. If the depths are different,

-the contents of the back buffer of the double-buffered window are undefined

-for the pixels that the <function>IncludeInferiors</function> drawing touched.

-</para>

-

-

-<para>

-DBE adds no new events. DBE does not extend the semantics of any existing

-events with the exception of adding a new DRAWABLE type called

-BACKBUFFER. If events, replies, or errors that contain a DRAWABLE (for

-example, <function>GraphicsExpose</function>) are generated in response to

-a request, the

-DRAWABLE returned will be the one specified in the request.

-</para>

-<para>

-DBE advertises which visuals support double-buffering.

-</para>

-<para>

-DBE does not include any timing or synchronization facilities. Applications

-that need such facilities (for example, to maintain a constant frame rate)

-should investigate the Synchronization Extension, an X Consortium standard.

-</para>

-

-<sect1 id="window_management_operations">

-<title>Window Management Operations</title>

-

-<para>

-The basic philosophy of DBE is that both buffers are treated the same by core

-X window management operations.

-</para>

-<para>

-When the core <function>DestroyWindow</function> is executed on a

-double-buffered window, both buffers associated with the window are

-destroyed, and all back buffer names associated with the window are freed.

-</para>

-<para>

-If the core <function>ConfigureWindow</function> request changes the size

-of a window, both buffers assume the new size. If the window’s size

-increases, the effect on the buffers depends on whether the implementation

-honors bit gravity for buffers.

-If bit gravity is implemented, then the contents of both buffers are moved in

-accordance with the window’s bit gravity (see the core

-<function>ConfigureWindow</function>

-request), and the remaining areas are tiled with the window background. If

-bit gravity is not implemented, then the entire unobscured region of both

-buffers is tiled with the window background. In either case,

-<function>Expose</function> events are

-generated for the region that is tiled with the window background.

-If the core GetGeometry request is executed on a BACKBUFFER, the

-returned x, y, and border-width will be zero.

-</para>

-<para>

-If the Shape extension

-<function>ShapeRectangles</function>,

-<function>ShapeMask</function>,

-<function>ShapeCombine</function>, or

-<function>ShapeOffset</function>

-request is executed on a double-buffered window, both buffers

-are reshaped to match the new window shape. The region difference is the

-following:

-</para>

-

-<literallayout remap='Ds'>

-        D = newshape − oldshape

-</literallayout>

-

-<para>

-It is tiled with the window background in both buffers, and

-<function>Expose</function>

-events are generated for D.

-</para>

-

-</sect1>

-

-<sect1 id="complex_swap_actions">

-<title>Complex Swap Actions</title>

-<para>

-DBE has no explicit knowledge of ancillary buffers (for example, depth buffers

-or alpha buffers), and only has a limited set of defined swap actions. Some

-applications may need a richer set of swap actions than DBE provides. Some

-DBE implementations have knowledge of ancillary buffers, and/or can provide

-a rich set of swap actions. Instead of continually extending DBE to increase

-its set of swap actions, DBE provides a flexible "idiom" mechanism. If an

-application’s needs are served by the defined swap actions, it should use them;

-otherwise, it should use the following method of expressing a complex swap

-action as an idiom. Following this policy will ensure the best possible

-performance across a wide variety of implementations.

-</para>

-<para>

-As suggested by the term "idiom," a complex swap action should be expressed

-as a group/series of requests. Taken together, this group of requests may be

-combined into an atomic operation by the implementation, in order to

-maximize performance. The set of idioms actually recognized for optimization

-is implementation dependent.

-To help with idiom expression and

-interpretation, an idiom must be surrounded by two protocol requests:

-<function>DBEBeginIdiom</function> and <function>DBEEndIdiom</function>.

-Unless this begin-end pair surrounds the idiom, it may not be recognized

-by a given implementation, and performance will suffer.

-</para>

-<para>

-For example, if an application wants to swap buffers for two windows, and use

-core X to clear only certain planes of the back buffers, the application would

-issue the following protocol requests as a group, and in the following order:

-</para>

-

-<itemizedlist>

-  <listitem>

-    <para>

-<function>DBEBeginIdiom</function> request.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-<function>DBESwapBuffers</function> request with XIDs for two windows, each of which uses

-a swap action of Untouched.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Core X <function>PolyFillRectangle</function> request to the back buffer of one window.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-Core X <function>PolyFillRectangle</function> request to the back buffer of the other

-window.

-    </para>

-  </listitem>

-  <listitem>

-    <para>

-<function>DBEEndIdiom</function> request.

-    </para>

-  </listitem>

-</itemizedlist>

-

-<para>

-The <function>DBEBeginIdiom</function> and <function>DBEEndIdiom</function>

-requests do not perform any actions

-themselves. They are treated as markers by implementations that can

-combine certain groups/series of requests as idioms, and are ignored by other

-implementations or for nonrecognized groups/series of requests. If these

-requests are sent out of order, or are mismatched, no errors are sent, and the

-requests are executed as usual, though performance may suffer.

-</para>

-

-<para>

-

-An idiom need not include a <function>DBESwapBuffers</function> request.

-For example, if a swap action of <function>Copied</function> is desired,

-but only some of the planes should be copied, a core X

-<function>CopyArea</function> request may be used instead of

-<function>DBESwapBuffers</function>. If

-<function>DBESwapBuffers</function> is included in an idiom, it should

-immediately follow the

-<function>DBEBeginIdiom</function> request. Also, when the

-<function>DBESwapBuffers</function> is included in an idiom, that

-request’s swap action will still be valid, and if the swap action

-might overlap with another request, then the final result of the idiom must be

-as if the separate requests were executed serially. For example, if the

-specified swap action is <function>Untouched</function>, and if a

-<function>PolyFillRectangle</function> using a client clip

-rectangle is done to the window’s back buffer after the

-<function>DBESwapBuffers</function> request, then the contents of the new

-back buffer (after the idiom) will be the

-same as if the idiom was not recognized by the implementation.

-</para>

-<para>

-It is highly recommended that Application Programming Interface (API)

-providers define, and application developers use, "convenience" functions that

-allow client applications to call one procedure that encapsulates common

-idioms. These functions will generate the

-<function>DBEBeginIdiom</function> request, the idiom

-requests, and <function>DBEEndIdiom</function> request. Usage of these

-functions will ensure best possible performance across a wide

-variety of implementations.

-</para>

-

-</sect1>

-</chapter>

-

-<chapter id="c_language_bindings">

-<title>C Language Binding</title>

-<para>

-All identifier The header for this extension is &lt;X11/extensions/Xdbe.h&gt;.

-names provided by this header begin with Xdbe.

-</para>

-

-<sect1 id="types">

-<title>Types</title>

-

-<para>

-The type <function>XdbeBackBuffer</function> is a <function>Drawable</function>.

-</para>

-

-<para>

-The type <function>XdbeSwapAction</function> can be one of the constants

-<function>XdbeUndefined</function>,

-<function>XdbeBackground</function>,

-<function>XdbeUntouched</function>, or

-<function>XdbeCopied</function>.

-</para>

-

-</sect1>

-

-<sect1 id="c_functions">

-<title>C Functions</title>

-<para>

-The C functions provide direct access to the protocol and add no additional

-semantics. For complete details on the effects of these functions, refer to the

-appropriate protocol request, which can be derived by replacing Xdbe at the

-start of the function name with DBE. All functions that have return type

-<function>Status</function> will return nonzero for success and

-zero for failure.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XdbeQueryExtension</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-    <paramdef>int <parameter> *major_version_return</parameter></paramdef>

-    <paramdef>int <parameter> *minor_version_return</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XdbeQueryExtension</function> sets major version return and minor

-version return to the major and minor DBE protocol version supported by

-the server. If the DBE library is compatible with the version returned by

-the server, it returns nonzero. If dpy does not support the DBE extension,

-or if there was an error during communication with the server, or if the

-server and library protocol versions are incompatible, it returns zero.

-No other Xdbe functions may be called before this function. If a client

-violates this rule, the effects of all subsequent Xdbe calls that it makes

-are undefined.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>XdbeScreenVisualInfo *<function>XdbeGetVisualInfo</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-    <paramdef>Drawable <parameter> *screen_specifiers</parameter></paramdef>

-    <paramdef>int <parameter> *num_screens</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-

-<function>XdbeGetVisualInfo</function> returns information about which

-visuals support double buffering. The argument num_screens specifies how

-many elements there are in the screen_specifiers list. Each drawable in

-screen_specifiers designates a screen for which the supported visuals are

-being requested. If num_screens is zero, information for all screens is

-requested. In this case, upon return from this function, num_screens will

-be set to the number of screens that were found. If an error occurs,

-this function returns NULL; otherwise, it returns a pointer to a list of

-<function>XdbeScreenVisualInfo</function>

-structures of length num_screens.  The nth element in the returned list

-corresponds to the nth drawable in the screen_specifiers list, unless

-

-element in the returned list corresponds to the nth screen of the server,

-starting with screen zero.

-</para>

-

-

-<para>

-The XdbeScreenVisualInfo structure has the following fields:

-</para>

-<literallayout remap='Ds'>

-int                     count      number of items in visinfo

-XdbeVisualInfo*    visinfo     list of visuals and depths for this screen

-</literallayout>

-

-<para>

-The <function>XdbeVisualInfo</function> structure has the following fields:

-</para>

-

-<literallayout remap='Ds'>

-VisualID         visual    one visual ID that supports double-buffering

-int              depth     depth of visual in bits

-int              perflevel  performance level of visual

-</literallayout>

-

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>void XdbeFreeVisualInfo <function>XdbeGetVisualInfo</function></funcdef>

-    <paramdef>XdbeScreenVisualInfo <parameter> *visual_info</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XdbeFreeVisualInfo</function> frees the list of

-<function>XdbeScreenVisualInfo</function> returned by

-<function>XdbeGetVisualInfo</function>.

-</para>

-

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>XdbeBackBuffer <function>XdbeAllocateBackBufferName</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-    <paramdef>Window <parameter> *window</parameter></paramdef>

-    <paramdef>XdbeSwapAction <parameter> swap_action</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-

-<para>

-<function>XdbeAllocateBackBufferName</function> returns a drawable ID used

-to refer to the back buffer of the specified window. The swap_action is a

-hint to indicate the swap_action that will likely be used in subsequent

-calls to <function>XdbeSwapBuffers</function>.  The actual swap_action

-used in calls to <function>XdbeSwapBuffers</function> does not have to be

-the same as the swap_action passed to this function, though clients are

-encouraged to provide accurate information whenever possible.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XdbeDeallocateBackBufferName</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-    <paramdef>XdbeBackBuffer <parameter> buffer</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XdbeDeallocateBackBufferName</function> frees the specified

-drawable ID, buffer, that was obtained via

-<function>XdbeAllocateBackBufferName</function>. The buffer must be a valid

-name for the back buffer of a window, or an

-<function>XdbeBadBuffer</function> error results.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XdbeSwapBuffers</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-    <paramdef>XdbeSwapInfo <parameter> *swap_info</parameter></paramdef>

-    <paramdef>int <parameter> num_windows</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XdbeSwapBuffers</function> swaps the front and back buffers

-for a list of windows. The argument num_windows specifies how many windows

-are to have their buffers swapped; it is the number of elements in the

-swap_info array. The argument swap_info specifies the information needed

-per window to do the swap.

-</para>

-<para>

-The XdbeSwapInfo structure has the following fields:

-</para>

-

-<literallayout remap='Ds'>

-Window              swap_window    window for which to swap buffers

-XdbeSwapAction      swap_action    swap action to use for this swap window

-</literallayout>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XdbeBeginIdiom</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XdbeBeginIdiom</function> marks the beginning of an idiom

-sequence. See

-<link linkend="complex_swap_actions">

-<xref linkend="complex_swap_actions"></xref></link>

-for a complete discussion of idioms.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XdbeEndIdiom</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XdbeEndIdiom</function> marks the end of an idiom sequence.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>XdbeBackBufferAttributes *<function>XdbeGetBackBufferAttributes</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-    <paramdef>XdbeBackBuffer <parameter> buffer</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XdbeGetBackBufferAttributes</function> returns the attributes associated with

-the specified buffer.

-</para>

-<para>

-The XdbeBackBufferAttributes structure has the following fields:

-</para>

-

-<literallayout remap='Ds'>

-Window           window           window that buffer belongs to

-</literallayout>

-

-<para>

-If buffer is not a valid <function>XdbeBackBuffer</function>, window is

-set to None.

-</para>

-<para>

-The returned <function>XdbeBackBufferAttributes</function> structure

-can be freed with the Xlib function <function>XFree</function>.

-</para>

-</sect1>

-

-<sect1 id="errors">

-<title>Errors</title>

-<para>

-The <function>XdbeBufferError</function> structure has the following fields:

-</para>

-<literallayout remap='Ds'>

-int                 type

-Display *           display       Display the event was read from

-XdbeBackBuffer      buffer        resource id

-unsigned long       serial        serial number of failed request

-unsigned char       error code    error base + <function>XdbeBadBuffer</function>

-unsigned char       request code  Major op-code of failed request

-unsigned char       minor code    Minor op-code of failed request

-</literallayout>

-</sect1>

-</chapter>

-

-<chapter id="acknowledgements">

-<title>Acknowledgements</title>

-

-<para>

-We wish to thank the following individuals who have contributed their time

-and talent toward shaping the DBE specification:

-</para>

-<para>

-T. Alex Chen, IBM; Peter Daifuku, Silicon Graphics, Inc.; Ian Elliott,

-Hewlett-Packard Company; Stephen Gildea, X Consortium, Inc.; Jim Graham,

-Sun; Larry Hare, AGE Logic; Jay Hersh, X Consortium, Inc.; Daryl Huff,

-Sun; Deron Dann Johnson, Sun; Louis Khouw, Sun; Mark Kilgard, Silicon

-Graphics, Inc.; Rob Lembree, Digital Equipment Corporation; Alan Ricker,

-Metheus; Michael Rosenblum, Digital Equipment Corporation; Bob Scheifler,

-X Consortium, Inc.; Larry Seiler, Digital Equipment Corporation; Jeanne

-Sparlin Smith, IBM; Jeff Stevenson, Hewlett-Packard Company; Walter

-Strand, Metheus; Ken Tidwell, Hewlett-Packard Company; and David P.

-Wiggins, X Consortium, Inc.

-</para>

-<para>

-Mark provided the impetus to start the DBE project. Ian wrote the first draft

-of the specification. David served as architect.

-</para>

-

-</chapter>

-<chapter id="references">

-<title>References</title>

-<para>

-Jeffrey Friedberg, Larry Seiler, and Jeff Vroom, "Multi-buffering Extension

-Specification Version 3.3."

-</para>

-<para>

-Tim Glauert, Dave Carver, Jim Gettys, and David P. Wiggins, "X

-Synchronization Extension Version 3.0."

-</para>

-</chapter>

-</book>

+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="dbelib">
+
+<bookinfo>
+   <title>Double Buffer Extension Library</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <!-- <releaseinfo>X Version 11, Release 6.4</releaseinfo> -->
+   <authorgroup>
+      <author>
+         <firstname>Ian</firstname><surname>Elliot</surname>
+      </author>
+   </authorgroup>
+   <othercredit>
+      <firstname>Davide</firstname><surname>Wiggins</surname>
+   </othercredit>
+   <corpname>Hewlett-Packard Company</corpname>
+   <copyright><year>1989</year><holder>X Consortium, Inc and Digital Equipment Corporation</holder></copyright>
+   <copyright><year>1992</year><holder>X Consortium, Inc and Intergraph Corporation</holder></copyright>
+   <copyright><year>1993</year><holder>X Consortium, Inc and Silicon Graphics, Inc.</holder></copyright>
+   <copyright><year>1994</year><holder>X Consortium, Inc and Hewlett-Packard Company</holder></copyright>
+   <copyright><year>1995</year><holder>X Consortium, Inc and Hewlett-Packard Company</holder></copyright>
+   <releaseinfo>Version 1.0</releaseinfo>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 7</productnumber>
+
+<legalnotice>
+<para>
+Permission to use, copy, modify, and distribute this documentation for any
+purpose and without fee is hereby granted, provided that the above copyright
+notice and this permission notice appear in all copies. Digital Equipment
+Corporation, Intergraph Corporation, Silicon Graphics, Hewlett-Packard, and
+the X Consortium make no representations about the suitability for any
+purpose of the information in this document. This documentation is provided
+"as is" without express or implied warranty.
+</para>
+
+</legalnotice>
+
+</bookinfo>
+
+<chapter id="introduction">
+<title>Introduction</title>
+<para>
+The Double Buffer Extension (DBE) provides a standard way to utilize
+double-buffering within the framework of the X Window System.
+Double-buffering uses two buffers, called front and back, which hold images.
+The front buffer is visible to the user; the back buffer is not. Successive
+frames of an animation are rendered into the back buffer while the previously
+rendered frame is displayed in the front buffer. When a new frame is ready,
+the back and front buffers swap roles, making the new frame visible. Ideally,
+this exchange appears to happen instantaneously to the user and with no
+visual artifacts. Thus, only completely rendered images are presented to the
+user, and they remain visible during the entire time it takes to render a new
+frame. The result is a flicker-free animation.
+</para>
+
+</chapter>
+
+<chapter id="goals">
+<title>Goals</title>
+
+<para>
+This extension should enable clients to:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Allocate and deallocate double-buffering for a window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Draw to and read from the front and back buffers associated with a window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Swap the front and back buffers associated with a window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Specify a wide range of actions to be taken when a window is swapped.
+This includes explicit, simple swap actions (defined below), and more
+complex actions (for example, clearing ancillary buffers) that can be put
+together within explicit "begin" and "end" requests (defined below).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Request that the front and back buffers associated with multiple
+double-buffered windows be swapped simultaneously.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+In addition, the extension should:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Allow multiple clients to use double-buffering on the same window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Support a range of implementation methods that can capitalize on
+existing hardware features.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Add no new event types.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Be reasonably easy to integrate with a variety of direct graphics
+hardware access (DGHA) architectures.
+    </para>
+  </listitem>
+</itemizedlist>
+
+</chapter>
+
+<chapter id="concepts">
+<title>Concepts</title>
+<para>
+Normal windows are created using the core CreateWindow request, which
+allocates a set of window attributes and, for InputOutput windows, a front
+buffer, into which an image can be drawn. The contents of this buffer will be
+displayed when the window is visible.
+</para>
+<para>
+This extension enables applications to use double-buffering with a window.
+This involves creating a second buffer, called a back buffer, and associating
+one or more back buffer names (XIDs) with the window for use when referring
+to (that is, drawing to or reading from) the window’s back buffer. The back
+buffer name is a DRAWABLE of type BACKBUFFER.
+</para>
+<para>
+DBE provides a relative double-buffering model. One XID, the window,
+always refers to the front buffer. One or more other XIDs, the back buffer
+names, always refer to the back buffer. After a buffer swap, the window
+continues to refer to the (new) front buffer, and the back buffer name
+continues to refer to the (new) back buffer. Thus, applications and toolkits
+that want to just render to the back buffer always use the back buffer name
+for all drawing requests to the window. Portions of an application that want
+to render to the front buffer always use the window XID for all drawing
+requests to the window.
+</para>
+<para>
+Multiple clients and toolkits can all use double-buffering on the same window.
+DBE does not provide a request for querying whether a window has
+double-buffering support, and if so, what the back buffer name is. Given the
+asynchronous nature of the X Window System, this would cause race
+conditions. Instead, DBE allows multiple back buffer names to exist for the
+same window; they all refer to the same physical back buffer. The first time a
+back buffer name is allocated for a window, the window becomes
+double-buffered and the back buffer name is associated with the window.
+Subsequently, the window already is a double-buffered window, and nothing
+about the window changes when a new back buffer name is allocated, except
+that the new back buffer name is associated with the window. The window
+remains double-buffered until either the window is destroyed or until all of the
+back buffer names for the window are deallocated.
+</para>
+<para>
+In general, both the front and back buffers are treated the same.
+particular, here are some important characteristics:
+</para>
+<itemizedlist>
+  <listitem>
+    <para>
+Only one buffer per window can be visible at a time (the front buffer).
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Both buffers associated with a window have the same visual type, depth,
+width, height, and shape as the window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Both buffers associated with a window are "visible" (or "obscured") in
+the same way. When an Expose event is generated for a window, both
+buffers should be considered to be damaged in the exposed area.
+Damage that occurs to either buffer will result in an Expose event on
+the window. When a double-buffered window is exposed, both buffers
+are tiled with the window background, exactly as stated by the core
+protocol. Even though the back buffer is not visible, terms such as
+obscure apply to the back buffer as well as to the front buffer.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+It is acceptable at any time to pass a BACKBUFFER in any request,
+notably any core or extension drawing request, that expects a
+DRAWABLE.  This enables an application to draw directly into
+BACKBUFFERs in the same fashion as it would draw into any other
+DRAWABLE.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+It is an error (Window) to pass a BACKBUFFER in a core request that
+expects a Window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+A BACKBUFFER will never be sent by core X in a reply, event, or
+error where a Window is specified.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If core X11 backing-store and save-under applies to a double-buffered
+window, it applies to both buffers equally.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+If the core ClearArea request is executed on a double-buffered window,
+the same area in both the front and back buffers is cleared.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The effect of passing a window to a request that accepts a
+<function>DRAWABLE</function> is
+unchanged by this extension. The window and front buffer are synonomous
+with each other. This includes obeying the <function>GetImage</function>
+semantics and the
+subwindow-mode semantics if a core graphics context is involved. Regardless
+of whether the window was explicitly passed in a
+<function>GetImage</function> request, or
+implicitly referenced (that is, one of the window’s ancestors was passed in the
+request), the front (that is, visible) buffer is always referenced. Thus,
+DBE-naive screen dump clients will always get the front buffer.
+<function>GetImage</function> on
+a back buffer returns undefined image contents for any obscured regions of the
+back buffer that fall within the image.
+</para>
+<para>
+Drawing to a back buffer always uses the clip region that would be used to
+draw to the front buffer with a GC subwindow-mode of
+<function>ClipByChildren</function>. If
+an ancestor of a double-buffered window is drawn to with a core GC having a
+subwindow-mode of IncludeInferiors, the effect on the double-buffered
+window’s back buffer depends on the depth of the double-buffered window
+and the ancestor. If the depths are the same, the contents of the back buffer
+of the double-buffered window are not changed. If the depths are different,
+the contents of the back buffer of the double-buffered window are undefined
+for the pixels that the <function>IncludeInferiors</function> drawing touched.
+</para>
+
+
+<para>
+DBE adds no new events. DBE does not extend the semantics of any existing
+events with the exception of adding a new DRAWABLE type called
+BACKBUFFER. If events, replies, or errors that contain a DRAWABLE (for
+example, <function>GraphicsExpose</function>) are generated in response to
+a request, the
+DRAWABLE returned will be the one specified in the request.
+</para>
+<para>
+DBE advertises which visuals support double-buffering.
+</para>
+<para>
+DBE does not include any timing or synchronization facilities. Applications
+that need such facilities (for example, to maintain a constant frame rate)
+should investigate the Synchronization Extension, an X Consortium standard.
+</para>
+
+<sect1 id="window_management_operations">
+<title>Window Management Operations</title>
+
+<para>
+The basic philosophy of DBE is that both buffers are treated the same by core
+X window management operations.
+</para>
+<para>
+When the core <function>DestroyWindow</function> is executed on a
+double-buffered window, both buffers associated with the window are
+destroyed, and all back buffer names associated with the window are freed.
+</para>
+<para>
+If the core <function>ConfigureWindow</function> request changes the size
+of a window, both buffers assume the new size. If the window’s size
+increases, the effect on the buffers depends on whether the implementation
+honors bit gravity for buffers.
+If bit gravity is implemented, then the contents of both buffers are moved in
+accordance with the window’s bit gravity (see the core
+<function>ConfigureWindow</function>
+request), and the remaining areas are tiled with the window background. If
+bit gravity is not implemented, then the entire unobscured region of both
+buffers is tiled with the window background. In either case,
+<function>Expose</function> events are
+generated for the region that is tiled with the window background.
+If the core GetGeometry request is executed on a BACKBUFFER, the
+returned x, y, and border-width will be zero.
+</para>
+<para>
+If the Shape extension
+<function>ShapeRectangles</function>,
+<function>ShapeMask</function>,
+<function>ShapeCombine</function>, or
+<function>ShapeOffset</function>
+request is executed on a double-buffered window, both buffers
+are reshaped to match the new window shape. The region difference is the
+following:
+</para>
+
+<literallayout remap='Ds'>
+        D = newshape − oldshape
+</literallayout>
+
+<para>
+It is tiled with the window background in both buffers, and
+<function>Expose</function>
+events are generated for D.
+</para>
+
+</sect1>
+
+<sect1 id="complex_swap_actions">
+<title>Complex Swap Actions</title>
+<para>
+DBE has no explicit knowledge of ancillary buffers (for example, depth buffers
+or alpha buffers), and only has a limited set of defined swap actions. Some
+applications may need a richer set of swap actions than DBE provides. Some
+DBE implementations have knowledge of ancillary buffers, and/or can provide
+a rich set of swap actions. Instead of continually extending DBE to increase
+its set of swap actions, DBE provides a flexible "idiom" mechanism. If an
+application’s needs are served by the defined swap actions, it should use them;
+otherwise, it should use the following method of expressing a complex swap
+action as an idiom. Following this policy will ensure the best possible
+performance across a wide variety of implementations.
+</para>
+<para>
+As suggested by the term "idiom," a complex swap action should be expressed
+as a group/series of requests. Taken together, this group of requests may be
+combined into an atomic operation by the implementation, in order to
+maximize performance. The set of idioms actually recognized for optimization
+is implementation dependent.
+To help with idiom expression and
+interpretation, an idiom must be surrounded by two protocol requests:
+<function>DBEBeginIdiom</function> and <function>DBEEndIdiom</function>.
+Unless this begin-end pair surrounds the idiom, it may not be recognized
+by a given implementation, and performance will suffer.
+</para>
+<para>
+For example, if an application wants to swap buffers for two windows, and use
+core X to clear only certain planes of the back buffers, the application would
+issue the following protocol requests as a group, and in the following order:
+</para>
+
+<itemizedlist>
+  <listitem>
+    <para>
+<function>DBEBeginIdiom</function> request.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>DBESwapBuffers</function> request with XIDs for two windows, each of which uses
+a swap action of Untouched.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Core X <function>PolyFillRectangle</function> request to the back buffer of one window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+Core X <function>PolyFillRectangle</function> request to the back buffer of the other
+window.
+    </para>
+  </listitem>
+  <listitem>
+    <para>
+<function>DBEEndIdiom</function> request.
+    </para>
+  </listitem>
+</itemizedlist>
+
+<para>
+The <function>DBEBeginIdiom</function> and <function>DBEEndIdiom</function>
+requests do not perform any actions
+themselves. They are treated as markers by implementations that can
+combine certain groups/series of requests as idioms, and are ignored by other
+implementations or for nonrecognized groups/series of requests. If these
+requests are sent out of order, or are mismatched, no errors are sent, and the
+requests are executed as usual, though performance may suffer.
+</para>
+
+<para>
+
+An idiom need not include a <function>DBESwapBuffers</function> request.
+For example, if a swap action of <function>Copied</function> is desired,
+but only some of the planes should be copied, a core X
+<function>CopyArea</function> request may be used instead of
+<function>DBESwapBuffers</function>. If
+<function>DBESwapBuffers</function> is included in an idiom, it should
+immediately follow the
+<function>DBEBeginIdiom</function> request. Also, when the
+<function>DBESwapBuffers</function> is included in an idiom, that
+request’s swap action will still be valid, and if the swap action
+might overlap with another request, then the final result of the idiom must be
+as if the separate requests were executed serially. For example, if the
+specified swap action is <function>Untouched</function>, and if a
+<function>PolyFillRectangle</function> using a client clip
+rectangle is done to the window’s back buffer after the
+<function>DBESwapBuffers</function> request, then the contents of the new
+back buffer (after the idiom) will be the
+same as if the idiom was not recognized by the implementation.
+</para>
+<para>
+It is highly recommended that Application Programming Interface (API)
+providers define, and application developers use, "convenience" functions that
+allow client applications to call one procedure that encapsulates common
+idioms. These functions will generate the
+<function>DBEBeginIdiom</function> request, the idiom
+requests, and <function>DBEEndIdiom</function> request. Usage of these
+functions will ensure best possible performance across a wide
+variety of implementations.
+</para>
+
+</sect1>
+</chapter>
+
+<chapter id="c_language_bindings">
+<title>C Language Binding</title>
+<para>
+All identifier The header for this extension is &lt;X11/extensions/Xdbe.h&gt;.
+names provided by this header begin with Xdbe.
+</para>
+
+<sect1 id="types">
+<title>Types</title>
+
+<para>
+The type <function>XdbeBackBuffer</function> is a <function>Drawable</function>.
+</para>
+
+<para>
+The type <function>XdbeSwapAction</function> can be one of the constants
+<function>XdbeUndefined</function>,
+<function>XdbeBackground</function>,
+<function>XdbeUntouched</function>, or
+<function>XdbeCopied</function>.
+</para>
+
+</sect1>
+
+<sect1 id="c_functions">
+<title>C Functions</title>
+<para>
+The C functions provide direct access to the protocol and add no additional
+semantics. For complete details on the effects of these functions, refer to the
+appropriate protocol request, which can be derived by replacing Xdbe at the
+start of the function name with DBE. All functions that have return type
+<function>Status</function> will return nonzero for success and
+zero for failure.
+</para>
+
+<funcsynopsis id='xdbequeryextension'>
+<funcprototype>
+  <funcdef>Status <function>XdbeQueryExtension</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>int <parameter> *major_version_return</parameter></paramdef>
+    <paramdef>int <parameter> *minor_version_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeQueryExtension</function> sets major version return and minor
+version return to the major and minor DBE protocol version supported by
+the server. If the DBE library is compatible with the version returned by
+the server, it returns nonzero. If dpy does not support the DBE extension,
+or if there was an error during communication with the server, or if the
+server and library protocol versions are incompatible, it returns zero.
+No other Xdbe functions may be called before this function. If a client
+violates this rule, the effects of all subsequent Xdbe calls that it makes
+are undefined.
+</para>
+
+<funcsynopsis id='xdbegetvisualinfo'>
+<funcprototype>
+  <funcdef>XdbeScreenVisualInfo *<function>XdbeGetVisualInfo</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>Drawable <parameter> *screen_specifiers</parameter></paramdef>
+    <paramdef>int <parameter> *num_screens</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+
+<function>XdbeGetVisualInfo</function> returns information about which
+visuals support double buffering. The argument num_screens specifies how
+many elements there are in the screen_specifiers list. Each drawable in
+screen_specifiers designates a screen for which the supported visuals are
+being requested. If num_screens is zero, information for all screens is
+requested. In this case, upon return from this function, num_screens will
+be set to the number of screens that were found. If an error occurs,
+this function returns NULL; otherwise, it returns a pointer to a list of
+<function>XdbeScreenVisualInfo</function>
+structures of length num_screens.  The nth element in the returned list
+corresponds to the nth drawable in the screen_specifiers list, unless
+
+element in the returned list corresponds to the nth screen of the server,
+starting with screen zero.
+</para>
+
+
+<para>
+The XdbeScreenVisualInfo structure has the following fields:
+</para>
+<literallayout remap='Ds'>
+int                     count      number of items in visinfo
+XdbeVisualInfo*    visinfo     list of visuals and depths for this screen
+</literallayout>
+
+<para>
+The <function>XdbeVisualInfo</function> structure has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+VisualID         visual    one visual ID that supports double-buffering
+int              depth     depth of visual in bits
+int              perflevel  performance level of visual
+</literallayout>
+
+
+<funcsynopsis>
+<funcprototype>
+  <funcdef>void XdbeFreeVisualInfo <function>XdbeGetVisualInfo</function></funcdef>
+    <paramdef>XdbeScreenVisualInfo <parameter> *visual_info</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeFreeVisualInfo</function> frees the list of
+<function>XdbeScreenVisualInfo</function> returned by
+<function>XdbeGetVisualInfo</function>.
+</para>
+
+
+<funcsynopsis id='xdbeallocatebackbuffername'>
+<funcprototype>
+  <funcdef>XdbeBackBuffer <function>XdbeAllocateBackBufferName</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>Window <parameter> *window</parameter></paramdef>
+    <paramdef>XdbeSwapAction <parameter> swap_action</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+
+<para>
+<function>XdbeAllocateBackBufferName</function> returns a drawable ID used
+to refer to the back buffer of the specified window. The swap_action is a
+hint to indicate the swap_action that will likely be used in subsequent
+calls to <function>XdbeSwapBuffers</function>.  The actual swap_action
+used in calls to <function>XdbeSwapBuffers</function> does not have to be
+the same as the swap_action passed to this function, though clients are
+encouraged to provide accurate information whenever possible.
+</para>
+
+<funcsynopsis id='xdbedeallocatebackbuffername'>
+<funcprototype>
+  <funcdef>Status <function>XdbeDeallocateBackBufferName</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>XdbeBackBuffer <parameter> buffer</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeDeallocateBackBufferName</function> frees the specified
+drawable ID, buffer, that was obtained via
+<function>XdbeAllocateBackBufferName</function>. The buffer must be a valid
+name for the back buffer of a window, or an
+<function>XdbeBadBuffer</function> error results.
+</para>
+
+<funcsynopsis id='xdbeswapbuffers'>
+<funcprototype>
+  <funcdef>Status <function>XdbeSwapBuffers</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>XdbeSwapInfo <parameter> *swap_info</parameter></paramdef>
+    <paramdef>int <parameter> num_windows</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeSwapBuffers</function> swaps the front and back buffers
+for a list of windows. The argument num_windows specifies how many windows
+are to have their buffers swapped; it is the number of elements in the
+swap_info array. The argument swap_info specifies the information needed
+per window to do the swap.
+</para>
+<para>
+The XdbeSwapInfo structure has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+Window              swap_window    window for which to swap buffers
+XdbeSwapAction      swap_action    swap action to use for this swap window
+</literallayout>
+
+<funcsynopsis id='xdbebeginidiom'>
+<funcprototype>
+  <funcdef>Status <function>XdbeBeginIdiom</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeBeginIdiom</function> marks the beginning of an idiom
+sequence. See
+<link linkend="complex_swap_actions">
+<xref linkend="complex_swap_actions"></xref></link>
+for a complete discussion of idioms.
+</para>
+
+<funcsynopsis id='xdbeendidiom'>
+<funcprototype>
+  <funcdef>Status <function>XdbeEndIdiom</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeEndIdiom</function> marks the end of an idiom sequence.
+</para>
+
+<funcsynopsis id='xdbegetbackbufferattributes'>
+<funcprototype>
+  <funcdef>XdbeBackBufferAttributes *<function>XdbeGetBackBufferAttributes</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>XdbeBackBuffer <parameter> buffer</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XdbeGetBackBufferAttributes</function> returns the attributes associated with
+the specified buffer.
+</para>
+<para>
+The XdbeBackBufferAttributes structure has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+Window           window           window that buffer belongs to
+</literallayout>
+
+<para>
+If buffer is not a valid <function>XdbeBackBuffer</function>, window is
+set to None.
+</para>
+<para>
+The returned <function>XdbeBackBufferAttributes</function> structure
+can be freed with the Xlib function <function>XFree</function>.
+</para>
+</sect1>
+
+<sect1 id="errors">
+<title>Errors</title>
+<para>
+The <function>XdbeBufferError</function> structure has the following fields:
+</para>
+<literallayout remap='Ds'>
+int                 type
+Display *           display       Display the event was read from
+XdbeBackBuffer      buffer        resource id
+unsigned long       serial        serial number of failed request
+unsigned char       error code    error base + <function>XdbeBadBuffer</function>
+unsigned char       request code  Major op-code of failed request
+unsigned char       minor code    Minor op-code of failed request
+</literallayout>
+</sect1>
+</chapter>
+
+<chapter id="acknowledgements">
+<title>Acknowledgements</title>
+
+<para>
+We wish to thank the following individuals who have contributed their time
+and talent toward shaping the DBE specification:
+</para>
+<para>
+T. Alex Chen, IBM; Peter Daifuku, Silicon Graphics, Inc.; Ian Elliott,
+Hewlett-Packard Company; Stephen Gildea, X Consortium, Inc.; Jim Graham,
+Sun; Larry Hare, AGE Logic; Jay Hersh, X Consortium, Inc.; Daryl Huff,
+Sun; Deron Dann Johnson, Sun; Louis Khouw, Sun; Mark Kilgard, Silicon
+Graphics, Inc.; Rob Lembree, Digital Equipment Corporation; Alan Ricker,
+Metheus; Michael Rosenblum, Digital Equipment Corporation; Bob Scheifler,
+X Consortium, Inc.; Larry Seiler, Digital Equipment Corporation; Jeanne
+Sparlin Smith, IBM; Jeff Stevenson, Hewlett-Packard Company; Walter
+Strand, Metheus; Ken Tidwell, Hewlett-Packard Company; and David P.
+Wiggins, X Consortium, Inc.
+</para>
+<para>
+Mark provided the impetus to start the DBE project. Ian wrote the first draft
+of the specification. David served as architect.
+</para>
+
+</chapter>
+<chapter id="references">
+<title>References</title>
+<para>
+Jeffrey Friedberg, Larry Seiler, and Jeff Vroom, "Multi-buffering Extension
+Specification Version 3.3."
+</para>
+<para>
+Tim Glauert, Dave Carver, Jim Gettys, and David P. Wiggins, "X
+Synchronization Extension Version 3.0."
+</para>
+</chapter>
+</book>
diff --git a/libXext/specs/dpmslib.xml b/libXext/specs/dpmslib.xml
index 809f3b77b..1fe81d2af 100644
--- a/libXext/specs/dpmslib.xml
+++ b/libXext/specs/dpmslib.xml
@@ -1,419 +1,419 @@
-<?xml version="1.0" encoding="UTF-8" ?>

-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"

-                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">

-

-<!-- lifted from troff+ms+XMan by doclifter -->

-<book id="dpmslib">

-

-<bookinfo>

-   <title>X Display Power Management Signaling (DPMS) Extension</title>

-   <subtitle>X Consortium Standard</subtitle>

-   <releaseinfo>X Version 11, Release 6.8</releaseinfo>

-   <authorgroup>

-      <author>

-         <firstname>Rob</firstname><surname>Lembree</surname>

-      </author>

-   </authorgroup>

-   <corpname>Digital Equipment Corporation</corpname>

-   <copyright><year>1996</year><holder>X Consortium</holder></copyright>

-   <releaseinfo>Version 1.0</releaseinfo>

-   <affiliation><orgname>X Consortium</orgname></affiliation>

-   <productnumber>X Version 11, Release 6.8</productnumber>

-

-<legalnotice>

-<para>

-Permission to use, copy, modify, distribute, and sell this

-documentation for any purpose is hereby granted without fee,

-provided that the above copyright notice and this permission

-notice appear in all copies.  Digital Equipment Corporation

-makes 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>

-<emphasis remap='I'>X Window System</emphasis> is a trademark of The Open Group.

-</para>

-</legalnotice>

-

-</bookinfo>

-

-<chapter id='overview'>

-<title>Overview</title>

-

-<para>This extension provides X Protocol control over the VESA Display

-Power Management Signaling (DPMS) characteristics of video boards

-under control of the X Window System.

-</para>

-

-<para>

-Traditionally, the X Window System has provided for both blanking and

-non-blanking screen savers.  Timeouts associated with these built-in

-screen saver mechanisms are limited to idle (dwell) time, and a change

-timeout that specifies the change interval for non-blanking screen savers.

-</para>

-

-<para>

-The United States' Environmental Protection Agency (EPA) Energy Star program

-requires that monitors power down after some idle time by default.

-While it is possible to simply overload the existing screen saver timeouts,

-this solution leaves the non-privileged user little to no control over

-the DPMS characteristics of his or her system.  For example, disabling

-DPMS would require some unintended side effect in the core screen saver,

-such as disabling the changing of a non-blanking screen saver.  Providing

-clients with this control requires an extension to the core X Window System

-Protocol, and this extension seeks to fill this gap.

-</para>

-

-<para>

-There are four power levels specified by the Video Electronics Standards

-Association (VESA) Display Power Management Signaling (DPMS) standard.

-These are mapped onto the X DPMS Extension like this:

-</para>

-

-<literallayout remap='Ds'>

-<function>DPMS Extension Power Levels</function>

-     0     DPMSModeOn               In use

-     1     DPMSModeStandby          Blanked, low power

-     2     DPMSModeSuspend          Blanked, lower power

-     3     DPMSModeOff               Shut off, awaiting activity

-</literallayout> <!-- remap='De' -->

-

-</chapter>

-

-<chapter id='dpms_functions'>

-<title>DPMS Functions</title>

-

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>DPMSQueryExtention</function></funcdef>

-    <paramdef>Display <parameter>*display</parameter></paramdef>

-    <paramdef>int <parameter>event_base</parameter></paramdef>

-    <paramdef>int <parameter>error_base</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<variablelist remap='IP'>

-  <varlistentry>

-    <term><emphasis remap='I'>*display</emphasis></term>

-    <listitem><para>Specifies the connection to the X server.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>event_base</emphasis></term>

-    <listitem><para>Specifies the return location for the assigned base event</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>error_base</emphasis></term>

-    <listitem><para>Specifies the return location for the assigned base error</para></listitem>

-  </varlistentry>

-</variablelist>

-

-<para>

-The DPMSQueryExtension function queries the X server to determine the

-availability of the DPMS Extension.  If the extension is available, the

-return value is TRUE, and <emphasis remap='I'>event_base</emphasis> and

-<emphasis remap='I'>error_base</emphasis> are set to the base event number

-and base error number for the extension, respectively.  Otherwise, the

-return value is FALSE, and the values of

-<emphasis remap='I'>event_base</emphasis> and

-<emphasis remap='I'>error_base</emphasis> are undefined.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>DPMSGetVersion</function></funcdef>

-    <paramdef>Display <parameter>*display</parameter></paramdef>

-    <paramdef>int <parameter>*major_version</parameter></paramdef>

-    <paramdef>int <parameter>*minor_version</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<variablelist remap='IP'>

-  <varlistentry>

-    <term><emphasis remap='I'>display</emphasis></term>

-    <listitem><para>Specifies the connection to the X server.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>major_version</emphasis></term>

-    <listitem><para>Specifies the return location for the extension major version.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>minor_version</emphasis></term>

-    <listitem><para>Specifies the return location for the extension minor version.</para></listitem>

-  </varlistentry>

-</variablelist>

-

-

-<para>

-The DPMSGetVersion function returns the version of the DPMS extension

-implemented by the X server.  The version is returned in

-<emphasis remap='I'>major_version</emphasis> and

-<emphasis remap='I'>minor_version</emphasis>.

-The major version and minor version for this specification are '1' and '1',

-respectively.  The major version will be incremented for protocol

-incompatible changes, and the minor version will be incremented for small,

-upwardly compatible changes.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>DPMSCapable</function></funcdef>

-    <paramdef>Display <parameter>*display</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<variablelist remap='IP'>

-  <varlistentry>

-    <term><emphasis remap='I'>display</emphasis></term>

-    <listitem><para>Specifies the connection to the X server.</para></listitem>

-  </varlistentry>

-</variablelist>

-

-

-<para>

-The DPMSCapable function returns the DPMS capability of the X server, either

-TRUE (capable of DPMS) or FALSE (incapable of DPMS).  The capability of an

-X server is implementation defined.  For example, if a multi-headed  X server

-is capable of DPMS on one head, and incapable on another, the truth value of

-this function is defined by the X server implementation.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>DPMSSetTimeouts</function></funcdef>

-    <paramdef>Display <parameter>*display</parameter></paramdef>

-    <paramdef>CARD16 <parameter>standby</parameter></paramdef>

-    <paramdef>CARD16 <parameter>suspend</parameter></paramdef>

-    <paramdef>CARD16 <parameter>off</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<variablelist remap='IP'>

-  <varlistentry>

-    <term><emphasis remap='I'>display</emphasis></term>

-    <listitem><para>Specifies the connection to the X server.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>standby</emphasis></term>

-    <listitem><para>Specifies the new standby timeout in seconds.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>suspend</emphasis></term>

-    <listitem><para>Specifies the new suspend timeout in seconds.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>off</emphasis></term>

-    <listitem><para>Specifies the new off timeout in seconds.</para></listitem>

-  </varlistentry>

-</variablelist>

-

-<para>

-The DPMSSetTimeouts function permits applications to set the timeout values

-used by the X server for DPMS timings.

-</para>

-

-<para>

-The value <emphasis remap='I'>standby</emphasis> is the amount of time of

-inactivity in seconds before standby mode is invoked. The actual effects of

-this mode are implementation defined, but in the case of DPMS compliant

-hardware, it is implemented by shutting off the horizontal sync signal,

-and pulsing the vertical sync signal.

-Standby mode provides the quickest monitor recovery time.  Note also that

-many monitors implement this mode identically to suspend mode.  A value

-of zero disables this mode.

-</para>

-

-<para>

-The value <emphasis remap='I'>suspend</emphasis> is the amount of time of

-inactivity in seconds before the second level of power savings is invoked.

-Suspend mode's physical and electrical characteristics are implementation

-defined, but in DPMS compliant hardware, results in the pulsing of the

-horizontal sync signal, and shutting off of the vertical sync signal.

-Suspend mode recovery is considered to be slower than standby mode, but

-faster than off mode, however this is monitor dependent.  As noted above,

-many monitors implement this mode identically to standby mode.  A value of

-zero disables this mode.

-</para>

-

-<para>

-The value <emphasis remap='I'>off</emphasis> is the amount of time of

-inactivity in seconds before the third and final level of power savings is

-invoked. Off mode's physical and electrical characteristics are

-implementation defined, but in DPMS compliant hardware, is implemented by

-shutting off both horizontal and vertical sync signals, resulting in

-the power-down of the monitor.  Recovery time is implementation dependant,

-but frequently is similar to the power-up time of the monitor.  A value

-of zero disables this mode.

-</para>

-

-<para>

-Chronologically, standby mode occurs before or simultaneously with

-suspend mode, and suspend mode must occur before or simultaneously with

-off mode.  Therefore, non-zero mode timeout values must be greater than

-or equal to the timeout values of earlier modes.  If inconsistent values

-are supplied, a BadValue error will result.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>DPMSGetTimeouts</function></funcdef>

-    <paramdef>Display <parameter>*display</parameter></paramdef>

-    <paramdef>CARD16 <parameter>*standby</parameter></paramdef>

-    <paramdef>CARD16 <parameter>*suspend</parameter></paramdef>

-    <paramdef>CARD16 <parameter>*off</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<variablelist remap='IP'>

-  <varlistentry>

-    <term><emphasis remap='I'>display</emphasis></term>

-    <listitem><para>Specifies the connection to the X server.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>standby</emphasis></term>

-    <listitem><para>Specifies the new standby timeout in seconds.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>suspend</emphasis></term>

-    <listitem><para>Specifies the new suspend timeout in seconds.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>off</emphasis></term>

-    <listitem><para>Specifies the new off timeout in seconds.</para></listitem>

-  </varlistentry>

-</variablelist>

-

-<para>

-The DPMSGetTimeouts function retrieves the timeout values used by the X

-server for DPMS timings.

-</para>

-

-<para>

-The value <emphasis remap='I'>standby</emphasis> is the amount of time of

-inactivity in seconds before standby mode is invoked. A value of zero

-indicates that this mode has been disabled.

-</para>

-

-<para>

-The value <emphasis remap='I'>suspend</emphasis> is the amount of time of

-inactivity in seconds before the second level of power savings is invoked.

-A value of zero indicates that this mode has been disabled.

-</para>

-

-<para>

-The value <emphasis remap='I'>off</emphasis> is the amount of time of

-inactivity in seconds before the third and final level of power savings is

-invoked. A value of zero indicates that this mode has been disabled.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>DPMSEnable</function></funcdef>

-    <paramdef>Display <parameter>*display</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<variablelist remap='IP'>

-  <varlistentry>

-    <term><emphasis remap='I'>display</emphasis></term>

-    <listitem><para>Specifies the connection to the X server.</para></listitem>

-  </varlistentry>

-</variablelist>

-

-<para>

-The DPMSEnable function enables DPMS on the specified display.  When

-enabled, DPMS will use the currently saved timeout values, and will

-invoke the DPMS power mode appropriate for the amount of time that

-the workstation input devices have been idle.  If DPMSEnable is invoked

-on a display with DPMS already enabled, no change is made, and no

-error is returned.  If DPMSEnable is invoked on a display without

-support for DPMS, no change is made and no error is returned.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>DPMSDisable</function></funcdef>

-    <paramdef>Display <parameter>*display</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<variablelist remap='IP'>

-  <varlistentry>

-    <term><emphasis remap='I'>display</emphasis></term>

-    <listitem><para>Specifies the connection to the X server.</para></listitem>

-  </varlistentry>

-</variablelist>

-

-<para>

-The DPMSDisable function disables DPMS on the specified display.  When

-disabled, DPMS returns the display to DPMSModeOn.  If DPMSDisable is

-invoked on a display with DPMS already disabled, no change is made,

-and no error is returned.  If DPMSDisable is invoked on a display

-without support for DPMS, no change is made and no error is returned.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>DPMSForceLevel</function></funcdef>

-    <paramdef>Display <parameter>*display</parameter></paramdef>

-    <paramdef>CARD16 <parameter>level</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<variablelist remap='IP'>

-  <varlistentry>

-    <term><emphasis remap='I'>display</emphasis></term>

-    <listitem><para>Specifies the connection to the X server.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>level</emphasis></term>

-    <listitem><para>Specifies the level to force power to.</para></listitem>

-  </varlistentry>

-</variablelist>

-

-<para>

-The DPMSForceLevel function forces a DPMS capable display into the

-specified power level.  The <emphasis remap='I'>level</emphasis> must be one of

-DPMSModeOn, DPMSModeStandby, DPMSModeSuspend, or DPMSModeOff.

-Values other than these will result in a BadValue error.  If DPMS

-is disabled on the display, a BadMatch protocol error will result.

-</para>

-

-<para>Status DPMSInfo(<emphasis remap='I'>display, power_level, state</emphasis>)</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>DPMSInfo</function></funcdef>

-    <paramdef>Display <parameter>*display</parameter></paramdef>

-    <paramdef>CARD16 <parameter>power_level</parameter></paramdef>

-    <paramdef>BOOL <parameter>*state</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<variablelist remap='IP'>

-  <varlistentry>

-    <term><emphasis remap='I'>display</emphasis></term>

-    <listitem><para>Specifies the connection to the X server.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>power_level</emphasis></term>

-    <listitem><para>Specifies the current power level.</para></listitem>

-  </varlistentry>

-  <varlistentry>

-    <term><emphasis remap='I'>state</emphasis></term>

-    <listitem><para>Specifies the current DPMS state.</para></listitem>

-  </varlistentry>

-</variablelist>

-

-<para>

-The DPMSInfo function returns information about the current DPMS state.

-The <emphasis remap='I'>state</emphasis> return parameter indicates whether

-or not DPMS is enabled (TRUE) or disabled (FALSE).  The

-<emphasis remap='I'>power_level</emphasis> return parameter indicates the

-current power level (one of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend,

-or DPMSModeOff.)

-</para>

-

-</chapter>

-</book>

+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="dpmslib">
+
+<bookinfo>
+   <title>X Display Power Management Signaling (DPMS) Extension</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>X Version 11, Release 6.8</releaseinfo>
+   <authorgroup>
+      <author>
+         <firstname>Rob</firstname><surname>Lembree</surname>
+      </author>
+   </authorgroup>
+   <corpname>Digital Equipment Corporation</corpname>
+   <copyright><year>1996</year><holder>X Consortium</holder></copyright>
+   <releaseinfo>Version 1.0</releaseinfo>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 6.8</productnumber>
+
+<legalnotice>
+<para>
+Permission to use, copy, modify, distribute, and sell this
+documentation for any purpose is hereby granted without fee,
+provided that the above copyright notice and this permission
+notice appear in all copies.  Digital Equipment Corporation
+makes 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>
+<emphasis remap='I'>X Window System</emphasis> is a trademark of The Open Group.
+</para>
+</legalnotice>
+
+</bookinfo>
+
+<chapter id='overview'>
+<title>Overview</title>
+
+<para>This extension provides X Protocol control over the VESA Display
+Power Management Signaling (DPMS) characteristics of video boards
+under control of the X Window System.
+</para>
+
+<para>
+Traditionally, the X Window System has provided for both blanking and
+non-blanking screen savers.  Timeouts associated with these built-in
+screen saver mechanisms are limited to idle (dwell) time, and a change
+timeout that specifies the change interval for non-blanking screen savers.
+</para>
+
+<para>
+The United States' Environmental Protection Agency (EPA) Energy Star program
+requires that monitors power down after some idle time by default.
+While it is possible to simply overload the existing screen saver timeouts,
+this solution leaves the non-privileged user little to no control over
+the DPMS characteristics of his or her system.  For example, disabling
+DPMS would require some unintended side effect in the core screen saver,
+such as disabling the changing of a non-blanking screen saver.  Providing
+clients with this control requires an extension to the core X Window System
+Protocol, and this extension seeks to fill this gap.
+</para>
+
+<para>
+There are four power levels specified by the Video Electronics Standards
+Association (VESA) Display Power Management Signaling (DPMS) standard.
+These are mapped onto the X DPMS Extension like this:
+</para>
+
+<literallayout remap='Ds'>
+<function>DPMS Extension Power Levels</function>
+     0     DPMSModeOn               In use
+     1     DPMSModeStandby          Blanked, low power
+     2     DPMSModeSuspend          Blanked, lower power
+     3     DPMSModeOff               Shut off, awaiting activity
+</literallayout> <!-- remap='De' -->
+
+</chapter>
+
+<chapter id='dpms_functions'>
+<title>DPMS Functions</title>
+
+
+<funcsynopsis id='dpmsqueryextention'>
+<funcprototype>
+  <funcdef>Bool <function>DPMSQueryExtention</function></funcdef>
+    <paramdef>Display <parameter>*display</parameter></paramdef>
+    <paramdef>int <parameter>event_base</parameter></paramdef>
+    <paramdef>int <parameter>error_base</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<variablelist remap='IP'>
+  <varlistentry>
+    <term><emphasis remap='I'>*display</emphasis></term>
+    <listitem><para>Specifies the connection to the X server.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>event_base</emphasis></term>
+    <listitem><para>Specifies the return location for the assigned base event</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>error_base</emphasis></term>
+    <listitem><para>Specifies the return location for the assigned base error</para></listitem>
+  </varlistentry>
+</variablelist>
+
+<para>
+The DPMSQueryExtension function queries the X server to determine the
+availability of the DPMS Extension.  If the extension is available, the
+return value is TRUE, and <emphasis remap='I'>event_base</emphasis> and
+<emphasis remap='I'>error_base</emphasis> are set to the base event number
+and base error number for the extension, respectively.  Otherwise, the
+return value is FALSE, and the values of
+<emphasis remap='I'>event_base</emphasis> and
+<emphasis remap='I'>error_base</emphasis> are undefined.
+</para>
+
+<funcsynopsis id='dpmsgetversion'>
+<funcprototype>
+  <funcdef>Status <function>DPMSGetVersion</function></funcdef>
+    <paramdef>Display <parameter>*display</parameter></paramdef>
+    <paramdef>int <parameter>*major_version</parameter></paramdef>
+    <paramdef>int <parameter>*minor_version</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<variablelist remap='IP'>
+  <varlistentry>
+    <term><emphasis remap='I'>display</emphasis></term>
+    <listitem><para>Specifies the connection to the X server.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>major_version</emphasis></term>
+    <listitem><para>Specifies the return location for the extension major version.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>minor_version</emphasis></term>
+    <listitem><para>Specifies the return location for the extension minor version.</para></listitem>
+  </varlistentry>
+</variablelist>
+
+
+<para>
+The DPMSGetVersion function returns the version of the DPMS extension
+implemented by the X server.  The version is returned in
+<emphasis remap='I'>major_version</emphasis> and
+<emphasis remap='I'>minor_version</emphasis>.
+The major version and minor version for this specification are '1' and '1',
+respectively.  The major version will be incremented for protocol
+incompatible changes, and the minor version will be incremented for small,
+upwardly compatible changes.
+</para>
+
+<funcsynopsis id='dpmscapable'>
+<funcprototype>
+  <funcdef>Bool <function>DPMSCapable</function></funcdef>
+    <paramdef>Display <parameter>*display</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<variablelist remap='IP'>
+  <varlistentry>
+    <term><emphasis remap='I'>display</emphasis></term>
+    <listitem><para>Specifies the connection to the X server.</para></listitem>
+  </varlistentry>
+</variablelist>
+
+
+<para>
+The DPMSCapable function returns the DPMS capability of the X server, either
+TRUE (capable of DPMS) or FALSE (incapable of DPMS).  The capability of an
+X server is implementation defined.  For example, if a multi-headed  X server
+is capable of DPMS on one head, and incapable on another, the truth value of
+this function is defined by the X server implementation.
+</para>
+
+<funcsynopsis id='dpmssettimeouts'>
+<funcprototype>
+  <funcdef>Status <function>DPMSSetTimeouts</function></funcdef>
+    <paramdef>Display <parameter>*display</parameter></paramdef>
+    <paramdef>CARD16 <parameter>standby</parameter></paramdef>
+    <paramdef>CARD16 <parameter>suspend</parameter></paramdef>
+    <paramdef>CARD16 <parameter>off</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<variablelist remap='IP'>
+  <varlistentry>
+    <term><emphasis remap='I'>display</emphasis></term>
+    <listitem><para>Specifies the connection to the X server.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>standby</emphasis></term>
+    <listitem><para>Specifies the new standby timeout in seconds.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>suspend</emphasis></term>
+    <listitem><para>Specifies the new suspend timeout in seconds.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>off</emphasis></term>
+    <listitem><para>Specifies the new off timeout in seconds.</para></listitem>
+  </varlistentry>
+</variablelist>
+
+<para>
+The DPMSSetTimeouts function permits applications to set the timeout values
+used by the X server for DPMS timings.
+</para>
+
+<para>
+The value <emphasis remap='I'>standby</emphasis> is the amount of time of
+inactivity in seconds before standby mode is invoked. The actual effects of
+this mode are implementation defined, but in the case of DPMS compliant
+hardware, it is implemented by shutting off the horizontal sync signal,
+and pulsing the vertical sync signal.
+Standby mode provides the quickest monitor recovery time.  Note also that
+many monitors implement this mode identically to suspend mode.  A value
+of zero disables this mode.
+</para>
+
+<para>
+The value <emphasis remap='I'>suspend</emphasis> is the amount of time of
+inactivity in seconds before the second level of power savings is invoked.
+Suspend mode's physical and electrical characteristics are implementation
+defined, but in DPMS compliant hardware, results in the pulsing of the
+horizontal sync signal, and shutting off of the vertical sync signal.
+Suspend mode recovery is considered to be slower than standby mode, but
+faster than off mode, however this is monitor dependent.  As noted above,
+many monitors implement this mode identically to standby mode.  A value of
+zero disables this mode.
+</para>
+
+<para>
+The value <emphasis remap='I'>off</emphasis> is the amount of time of
+inactivity in seconds before the third and final level of power savings is
+invoked. Off mode's physical and electrical characteristics are
+implementation defined, but in DPMS compliant hardware, is implemented by
+shutting off both horizontal and vertical sync signals, resulting in
+the power-down of the monitor.  Recovery time is implementation dependant,
+but frequently is similar to the power-up time of the monitor.  A value
+of zero disables this mode.
+</para>
+
+<para>
+Chronologically, standby mode occurs before or simultaneously with
+suspend mode, and suspend mode must occur before or simultaneously with
+off mode.  Therefore, non-zero mode timeout values must be greater than
+or equal to the timeout values of earlier modes.  If inconsistent values
+are supplied, a BadValue error will result.
+</para>
+
+<funcsynopsis id='dpmsgettimeouts'>
+<funcprototype>
+  <funcdef>Status <function>DPMSGetTimeouts</function></funcdef>
+    <paramdef>Display <parameter>*display</parameter></paramdef>
+    <paramdef>CARD16 <parameter>*standby</parameter></paramdef>
+    <paramdef>CARD16 <parameter>*suspend</parameter></paramdef>
+    <paramdef>CARD16 <parameter>*off</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<variablelist remap='IP'>
+  <varlistentry>
+    <term><emphasis remap='I'>display</emphasis></term>
+    <listitem><para>Specifies the connection to the X server.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>standby</emphasis></term>
+    <listitem><para>Specifies the new standby timeout in seconds.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>suspend</emphasis></term>
+    <listitem><para>Specifies the new suspend timeout in seconds.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>off</emphasis></term>
+    <listitem><para>Specifies the new off timeout in seconds.</para></listitem>
+  </varlistentry>
+</variablelist>
+
+<para>
+The DPMSGetTimeouts function retrieves the timeout values used by the X
+server for DPMS timings.
+</para>
+
+<para>
+The value <emphasis remap='I'>standby</emphasis> is the amount of time of
+inactivity in seconds before standby mode is invoked. A value of zero
+indicates that this mode has been disabled.
+</para>
+
+<para>
+The value <emphasis remap='I'>suspend</emphasis> is the amount of time of
+inactivity in seconds before the second level of power savings is invoked.
+A value of zero indicates that this mode has been disabled.
+</para>
+
+<para>
+The value <emphasis remap='I'>off</emphasis> is the amount of time of
+inactivity in seconds before the third and final level of power savings is
+invoked. A value of zero indicates that this mode has been disabled.
+</para>
+
+<funcsynopsis id='dpmsenable'>
+<funcprototype>
+  <funcdef>Status <function>DPMSEnable</function></funcdef>
+    <paramdef>Display <parameter>*display</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<variablelist remap='IP'>
+  <varlistentry>
+    <term><emphasis remap='I'>display</emphasis></term>
+    <listitem><para>Specifies the connection to the X server.</para></listitem>
+  </varlistentry>
+</variablelist>
+
+<para>
+The DPMSEnable function enables DPMS on the specified display.  When
+enabled, DPMS will use the currently saved timeout values, and will
+invoke the DPMS power mode appropriate for the amount of time that
+the workstation input devices have been idle.  If DPMSEnable is invoked
+on a display with DPMS already enabled, no change is made, and no
+error is returned.  If DPMSEnable is invoked on a display without
+support for DPMS, no change is made and no error is returned.
+</para>
+
+<funcsynopsis id='dpmsdisable'>
+<funcprototype>
+  <funcdef>Status <function>DPMSDisable</function></funcdef>
+    <paramdef>Display <parameter>*display</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<variablelist remap='IP'>
+  <varlistentry>
+    <term><emphasis remap='I'>display</emphasis></term>
+    <listitem><para>Specifies the connection to the X server.</para></listitem>
+  </varlistentry>
+</variablelist>
+
+<para>
+The DPMSDisable function disables DPMS on the specified display.  When
+disabled, DPMS returns the display to DPMSModeOn.  If DPMSDisable is
+invoked on a display with DPMS already disabled, no change is made,
+and no error is returned.  If DPMSDisable is invoked on a display
+without support for DPMS, no change is made and no error is returned.
+</para>
+
+<funcsynopsis id='dpmsforcelevel'>
+<funcprototype>
+  <funcdef>Status <function>DPMSForceLevel</function></funcdef>
+    <paramdef>Display <parameter>*display</parameter></paramdef>
+    <paramdef>CARD16 <parameter>level</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<variablelist remap='IP'>
+  <varlistentry>
+    <term><emphasis remap='I'>display</emphasis></term>
+    <listitem><para>Specifies the connection to the X server.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>level</emphasis></term>
+    <listitem><para>Specifies the level to force power to.</para></listitem>
+  </varlistentry>
+</variablelist>
+
+<para>
+The DPMSForceLevel function forces a DPMS capable display into the
+specified power level.  The <emphasis remap='I'>level</emphasis> must be one of
+DPMSModeOn, DPMSModeStandby, DPMSModeSuspend, or DPMSModeOff.
+Values other than these will result in a BadValue error.  If DPMS
+is disabled on the display, a BadMatch protocol error will result.
+</para>
+
+<para>Status DPMSInfo(<emphasis remap='I'>display, power_level, state</emphasis>)</para>
+
+<funcsynopsis id='dpmsinfo'>
+<funcprototype>
+  <funcdef>Status <function>DPMSInfo</function></funcdef>
+    <paramdef>Display <parameter>*display</parameter></paramdef>
+    <paramdef>CARD16 <parameter>power_level</parameter></paramdef>
+    <paramdef>BOOL <parameter>*state</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<variablelist remap='IP'>
+  <varlistentry>
+    <term><emphasis remap='I'>display</emphasis></term>
+    <listitem><para>Specifies the connection to the X server.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>power_level</emphasis></term>
+    <listitem><para>Specifies the current power level.</para></listitem>
+  </varlistentry>
+  <varlistentry>
+    <term><emphasis remap='I'>state</emphasis></term>
+    <listitem><para>Specifies the current DPMS state.</para></listitem>
+  </varlistentry>
+</variablelist>
+
+<para>
+The DPMSInfo function returns information about the current DPMS state.
+The <emphasis remap='I'>state</emphasis> return parameter indicates whether
+or not DPMS is enabled (TRUE) or disabled (FALSE).  The
+<emphasis remap='I'>power_level</emphasis> return parameter indicates the
+current power level (one of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend,
+or DPMSModeOff.)
+</para>
+
+</chapter>
+</book>
diff --git a/libXext/specs/shapelib.xml b/libXext/specs/shapelib.xml
index 1d89cf1e1..a357da40b 100644
--- a/libXext/specs/shapelib.xml
+++ b/libXext/specs/shapelib.xml
@@ -1,577 +1,577 @@
-<?xml version="1.0" encoding="UTF-8" ?>

-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"

-                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">

-

-<!-- lifted from troff+ms+XMan by doclifter -->

-<book id="shapelib">

-

-<bookinfo>

-   <title>X Nonrectangular Window Shape Extension Library</title>

-   <subtitle>X Consortium Standard</subtitle>

-   <releaseinfo>X Version 11, Release 6.4</releaseinfo>

-   <authorgroup>

-      <author>

-         <firstname>Keith</firstname><surname>Packard</surname>

-      </author>

-   </authorgroup>

-   <corpname>MIT X Consortium</corpname>

-   <copyright><year>1989</year><holder>X Consortium</holder></copyright>

-   <releaseinfo>Version 1.0</releaseinfo>

-   <affiliation><orgname>MIT X Consortium</orgname></affiliation>

-   <productnumber>X Version 11, Release 6.4</productnumber>

-

-<legalnotice>

-

-<para>

-Permission is hereby granted, free of charge, to any person obtaining a copy

-of this software and associated documentation files

-(the &ldquo;Software&rdquo;), to deal in the Software without restriction,

-including without limitation the rights to use, copy, modify, merge,

-publish, distribute, sublicense, and/or sell copies of the Software, and

-to permit persons to whom the Software is furnished to do so, subject to

-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='overview'>

-<title>Overview</title>

-

-<para>This extension provides arbitrary window and border shapes within

-the X11 protocol.

-</para>

-

-<para>

-The restriction of rectangular windows within the X protocol is a significant

-limitation in the implementation of many styles of user interface.  For

-example, many transient windows would like to display a

-&ldquo;drop shadow&rdquo; to give the illusion of 3 dimensions.  As

-another example, some user interface style guides call for buttons with

-rounded corners; the full simulation of a nonrectangular shape,

-particularly with respect to event distribution and cursor shape, is not

-possible within the core X protocol.  As a final example, round clocks

-and nonrectangular icons are desirable visual addition to the desktop.

-</para>

-

-<para>

-This extension provides mechanisms for changing the visible shape of a

-window to an arbitrary, possibly disjoint, nonrectangular form.  The intent

-of the extension is to supplement the existing semantics, not replace them.

-In particular, it is desirable for clients that are unaware of the

-extension to still be able to cope reasonably with shaped windows.  For

-example, window managers should still be able to negotiate screen

-real estate in rectangular pieces.  Toward this end, any shape specified for

-a window is clipped by the bounding rectangle for the window as specified by

-the window's geometry in the core protocol.  An expected convention would be

-that client programs expand their shape to fill the area offered by the

-window manager.

-</para>

-</chapter>

-

-<chapter id='description'>

-<title>Description</title>

-

-<para>

-Each window (even with no shapes specified) is defined by two regions:  the

-<emphasis remap='I'>bounding region</emphasis> and the

-<emphasis remap='I'>clip region</emphasis>.  The bounding region is the

-area of the parent window that the window will occupy (including border).

-The clip region is the subset of the bounding region that is available for

-subwindows and graphics.  The area between the bounding region and the

-clip region is defined to be the border of the window.

-</para>

-

-<para>

-A nonshaped window will have a bounding region that is a rectangle spanning

-the window, including its border; the clip region will be a rectangle

-filling the inside dimensions (not including the border).  In this document,

-these areas are referred to as the

-<emphasis remap='I'>default bounding region</emphasis> and the

-<emphasis remap='I'>default clip region</emphasis>.  For a window with

-inside size of <emphasis remap='I'>width</emphasis> by

-<emphasis remap='I'>height</emphasis> and border width

-<emphasis remap='I'>bwidth</emphasis>, the default bounding and clip

-regions are the rectangles (relative to the window origin):

-</para>

-

-<literallayout remap='Ds'>

-bounding.x = -<emphasis remap='I'>bwidth</emphasis>

-bounding.y = -<emphasis remap='I'>bwidth</emphasis>

-bounding.width = <emphasis remap='I'>width</emphasis> + 2 * <emphasis remap='I'>bwidth</emphasis>

-bounding.height = <emphasis remap='I'>height</emphasis> + 2 * <emphasis remap='I'>bwidth</emphasis>

-

-clip.x = 0

-clip.y = 0

-clip.width = <emphasis remap='I'>width</emphasis>

-clip.height = <emphasis remap='I'>height</emphasis>

-</literallayout>

-

-<para>

-This extension allows a client to modify either or both of the bounding or

-clip regions by specifying new regions that combine with the default

-regions.  These new regions are called the

-<emphasis remap='I'>client bounding region</emphasis> and the

-<emphasis remap='I'>client clip region</emphasis>.  They are specified

-relative to the origin of the window and are always defined by offsets

-relative to the window origin (that is, region adjustments are not

-required when the window is moved).  Three mechanisms for specifying

-regions are provided:  a list of rectangles, a bitmap, and an existing

-bounding or clip region from a window.  This is modeled on the specification

-of regions in graphics contexts in the core protocol and allows a variety

-of different uses of the extension.

-</para>

-

-<para>

-When using an existing window shape as an operand in specifying a new shape,

-the client region is used, unless none has been set, in which case the

-default region is used instead.

-</para>

-

-<para>

-The <emphasis remap='I'>effective bounding region</emphasis> of a window is

-defined to be the intersection of the client bounding region with the default

-bounding region.  Any portion of the client bounding region that is not

-included in the default bounding region will not be included in the

-effective bounding region on the screen.  This means that window managers

-(or other geometry managers) used to dealing with rectangular client windows

-will be able to constrain the client to a rectangular area of the screen.

-</para>

-

-<para>

-Construction of the effective bounding region is dynamic; the client bounding

-region is not mutated to obtain the effective bounding region.  If a client

-bounding region is specified that extends beyond the current default bounding

-region, and the window is later enlarged, the effective bounding region will

-be enlarged to include more of the client bounding region.

-</para>

-

-<para>

-The <emphasis remap='I'>effective clip region</emphasis> of a window is

-defined to be the intersection of the client clip region with both the

-default clip region and the client bounding region.  Any portion of the

-client clip region that is not included in both the default clip region

-and the client bounding region will not be included in the effective clip

-region on the screen.

-</para>

-

-<para>

-Construction of the effective clip region is dynamic; the client clip region is

-not mutated to obtain the effective clip region.  If a client clip region is

-specified that extends beyond the current default clip region and the

-window or its bounding region is later enlarged, the effective clip region will

-be enlarged to include more of the client clip region if it is included in

-the effective bounding region.

-</para>

-

-<para>

-The border of a window is defined to be the difference between the effective

-bounding region and the effective clip region.  If this region is empty, no

-border is displayed.  If this region is nonempty, the border is filled

-using the border-tile or border-pixel of the window as specified in the core

-protocol.  Note that a window with a nonzero border width will never be able

-to draw beyond the default clip region of the window.  Also note that a zero

-border width does not prevent a window from having a border, since the clip

-shape can still be made smaller than the bounding shape.

-</para>

-

-<para>

-All output to the window and visible regions of any subwindows will be

-clipped to the effective clip region.  The server must not retain window

-contents beyond the effective bounding region with backing store.  The window's

-origin (for graphics operations, background tiling, and subwindow placement)

-is not affected by the existence of a bounding region or clip region.

-</para>

-

-<para>

-Areas that are inside the default bounding region but outside the effective

-bounding region are not part of the window; these areas of the screen will

-be occupied by other windows.  Input events that occur within the default

-bounding region but outside the effective bounding region will be delivered as

-if the window was not occluding the event position.  Events that occur in

-a nonrectangular border of a window will be delivered to that window, just

-as for events that occur in a normal rectangular border.

-</para>

-

-<para>An

-<function>InputOnly</function>

-window can have its bounding region set, but it is a

-<function>Match</function>

-error to attempt to set a clip region on an

-<function>InputOnly</function>

-window or to specify its clip region as a source to a request

-in this extension.

-</para>

-

-<para>

-The server must accept changes to the clip region of a root window, but

-the server is permitted to ignore requested changes to the bounding region

-of a root window.  If the server accepts bounding region changes, the contents

-of the screen outside the bounding region are implementation dependent.

-</para>

-</chapter>

-

-<chapter id='c_language_binding'>

-<title>C Language Binding</title>

-

-<para>

-The C functions provide direct access to the protocol and add no additional

-semantics.

-</para>

-

-<para>The include file for this extension is

-&lt;<symbol role='Pn'>X11/extensions/shape.h</symbol>&gt;.

-The defined shape kinds are

-<function>ShapeBounding</function>

-and

-<function>ShapeClip</function>

-The defined region operations are

-<function>ShapeSet</function>

-<function>ShapeUnion</function>

-<function>ShapeIntersect</function>

-<function>ShapeSubtract</function>

-and

-<function>ShapeInvert</function>.</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef>Bool<function> XShapeQueryExtension</function></funcdef>

-<paramdef>Display <parameter>*display</parameter></paramdef>

-<paramdef>int <parameter>*event_base</parameter></paramdef>

-<paramdef>int <parameter>*error_base</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XShapeQueryExtension</function>

-returns

-<function>True</function>

-if the specified display supports the SHAPE extension else

-<function>False</function>

-If the extension is supported, *event_base is set to the event number for

-<function>ShapeNotify</function>

-events and *error_base would be set to the error number for the first error for

-this extension.  Because no errors are defined for this version of

-the extension, the value returned here is not defined (nor useful).

-</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef>Status<function> XShapeQueryVersion</function></funcdef>

-<paramdef>Display<parameter> *display</parameter></paramdef>

-<paramdef>int<parameter> *major_version</parameter></paramdef>

-<paramdef>int<parameter> *minor_version</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-If the extension is supported,

-<function>XShapeQueryVersion</function>

-sets the major and minor version numbers of the

-extension supported by the display and returns a nonzero value.

-Otherwise, the arguments are not set and zero is returned.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef><function>XShapeCombineRegion</function></funcdef>

-<paramdef>Display<parameter> *display</parameter></paramdef>

-<paramdef>Window<parameter> dest</parameter></paramdef>

-<paramdef>int<parameter> dest_kind</parameter></paramdef>

-<paramdef>int<parameter> x_off</parameter></paramdef>

-<paramdef>int<parameter> y_off</parameter></paramdef>

-<paramdef>int<parameter> region</parameter></paramdef>

-<paramdef>int<parameter> op</parameter></paramdef>

-<paramdef>REGION<parameter> *region</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XShapeCombineRegion</function>

-converts the specified region into a list of rectangles and calls

-<function>XShapeCombineRectangles</function>

-</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef><function>XShapeCombineRectangles</function></funcdef>

-<paramdef>Display<parameter> *display</parameter></paramdef>

-<paramdef>Window<parameter> dest</parameter></paramdef>

-<paramdef>int<parameter> dest_kind</parameter></paramdef>

-<paramdef>int<parameter> x_off</parameter></paramdef>

-<paramdef>int<parameter> y_off</parameter></paramdef>

-<paramdef>XRectangle<parameter> *rectangles</parameter></paramdef>

-<paramdef>int<parameter> n_rects</parameter></paramdef>

-<paramdef>int<parameter> op</parameter></paramdef>

-<paramdef>int<parameter> ordering</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-If the extension is supported,

-<function>XShapeCombineRectangles</function>

-performs a

-<function>ShapeRectangles</function>

-operation; otherwise, the request is ignored.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef><function>XShapeCombineMask</function></funcdef>

-<paramdef>Display<parameter> *display</parameter></paramdef>

-<paramdef>int<parameter> dest</parameter></paramdef>

-<paramdef>int<parameter> dest_kind</parameter></paramdef>

-<paramdef>int<parameter> x_off</parameter></paramdef>

-<paramdef>int<parameter> y_off</parameter></paramdef>

-<paramdef>Pixmap<parameter> src</parameter></paramdef>

-<paramdef>int<parameter> op</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-If the extension is supported,

-<function>XShapeCombineMask</function>

-performs a

-<function>ShapeMask</function>

-operation; otherwise, the request is ignored.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef><function>XShapeCombineShape</function></funcdef>

-<paramdef>Display<parameter> *display</parameter></paramdef>

-<paramdef>Window<parameter> dest</parameter></paramdef>

-<paramdef>int<parameter> dest_kind</parameter></paramdef>

-<paramdef>int<parameter> x_off</parameter></paramdef>

-<paramdef>int<parameter> y_off</parameter></paramdef>

-<paramdef>Window<parameter> src</parameter></paramdef>

-<paramdef>int<parameter> src_kind</parameter></paramdef>

-<paramdef>int<parameter> op</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-If the extension is supported,

-<function>XShapeCombineShape</function>

-performs a

-<function>ShapeCombine</function>

-operation; otherwise, the request is ignored.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef><function>XShapeOffsetShape</function></funcdef>

-<paramdef><parameter>display</parameter></paramdef>

-<paramdef><parameter>dest</parameter></paramdef>

-<paramdef><parameter>dest_kind</parameter></paramdef>

-<paramdef><parameter>x_off</parameter></paramdef>

-<paramdef><parameter>y_off</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-If the extension is supported,

-<function>XShapeOffsetShape</function>

-performs a

-<function>ShapeOffset</function>

-operation; otherwise, the request is ignored.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef>Status <function>XShapeQueryExtents</function></funcdef>

-<paramdef>Display<parameter> *display</parameter></paramdef>

-<paramdef>Window<parameter> window</parameter></paramdef>

-<paramdef>Bool<parameter> *bounding_shaped</parameter></paramdef>

-<paramdef>int<parameter> *x_bounding</parameter></paramdef>

-<paramdef>int<parameter> *y_bounding</parameter></paramdef>

-<paramdef>unsigned int<parameter> *w_bounding</parameter></paramdef>

-<paramdef>unsigned int<parameter> *h_bounding</parameter></paramdef>

-<paramdef>Bool<parameter> *clip_shaped</parameter></paramdef>

-<paramdef>int<parameter> *x_clip</parameter></paramdef>

-<paramdef>int<parameter> *y_clip</parameter></paramdef>

-<paramdef>unsigned int<parameter> *w_clip</parameter></paramdef>

-<paramdef>unsigned int<parameter> *h_clip</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-If the extension is supported,

-<function>XShapeQueryExtents</function>

-sets x_bounding, y_bounding, w_bounding, h_bounding to the extents of the

-bounding shape and sets x_clip, y_clip, w_clip, h_clip to the extents of

-the clip shape.  For unspecified client regions, the extents of the

-corresponding default region are used.

-</para>

-

-<para>

-If the extension is supported, a nonzero value is returned; otherwise,

-zero is returned.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef><function>XShapeSelectInput</function></funcdef>

-<paramdef>Display<parameter> *display</parameter></paramdef>

-<paramdef>Window<parameter> window</parameter></paramdef>

-<paramdef>unsigned long<parameter> mask</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-To make this extension more compatible with other interfaces, although

-only one event type can be selected via the extension,

-<function>XShapeSelectInput</function>

-provides a general mechanism similar to the standard Xlib binding for

-window events.  A mask value has been defined,

-<function>ShapeNotifyMask</function>

-that is the only valid bit in mask that may be specified.

-The structure for this event is defined as follows:

-</para>

-

-<literallayout remap='Ds'>

-typedef struct {

-    int type;     /* of event */

-    unsigned long serial;     /* # of last request processed by server */

-    Bool send_event;     /* true if this came frome a SendEvent request */

-    Display *display;     /* Display the event was read from */

-    Window window;     /* window of event */

-    int kind;     /* ShapeBounding or ShapeClip */

-    int x, y;     /* extents of new region */

-    unsigned width, height;

-    Time time;     /* server timestamp when region changed */

-    Bool shaped;     /* true if the region exists */

-} XShapeEvent;

-</literallayout>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef>unsigned long <function>XShapeInputSelected</function></funcdef>

-<paramdef>Display<parameter> *display</parameter></paramdef>

-<paramdef>Window<parameter> window</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XShapeInputSelected</function>

-returns the current input mask for extension events on the specified

-window; the value returned if

-<function>ShapeNotify</function>

-is selected for is

-<function>ShapeNotifyMask</function>

-otherwise, it returns zero.

-If the extension is not supported, it returns zero.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-<funcdef>XRectangle<function> *XShapeGetRectangles</function></funcdef>

-<paramdef>Display<parameter> *display</parameter></paramdef>

-<paramdef>Window<parameter> window</parameter></paramdef>

-<paramdef>int<parameter> kind</parameter></paramdef>

-<paramdef>int<parameter> *count</parameter></paramdef>

-<paramdef>int<parameter> *ordering</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-If the extension is not supported,

-<function>XShapeGetRectangles</function>

-returns NULL.  Otherwise, it returns a list of rectangles that describe the

-region specified by kind.

-</para>

-</chapter>

-

-<glossary id='glossary'>

-

-<glossentry id='bounding_region'>

-  <glossterm>bounding region</glossterm>

-  <glossdef><para>The area of the parent window that this window will occupy.

-This area is divided into two parts:  the border and the interior.</para>

-  </glossdef>

-</glossentry>

-

-<glossentry id='clip_region'>

-  <glossterm>clip region</glossterm>

-  <glossdef><para>The interior of the window, as a subset of the bounding

-region.  This region describes the area that will be painted with the

-window background when the window is cleared, will contain all graphics

-output to the window, and will clip any subwindows.</para></glossdef>

-</glossentry>

-

-<glossentry id='default_bounding_region'>

-  <glossterm>default bounding region</glossterm>

-  <glossdef><para>The rectangular area, as described by the core protocol

-window size, that covers the interior of the window and its border.</para>

-  </glossdef>

-</glossentry>

-

-<glossentry id='default_clip_region'>

-  <glossterm>default clip region</glossterm>

-  <glossdef><para>The rectangular area, as described by the core protocol

-window size, that covers the interior of the window and excludes the border.

-  </para></glossdef>

-</glossentry>

-

-<glossentry id='client_bounding_region'>

-  <glossterm>client bounding region</glossterm>

-  <glossdef><para>The region associated with a window that is directly

-modified via this extension when specified by

-<function>ShapeBounding</function>

-This region is used in conjunction with the default bounding region

-to produce the effective bounding region.</para></glossdef>

-</glossentry>

-

-<glossentry id='client_clip_region'>

-  <glossterm>client clip region</glossterm>

-  <glossdef><para>The region associated with a window that is directly

-modified via this extension when specified by

-<function>ShapeClip</function>

-This region is used in conjunction with the default clip region

-and the client bounding region to produce the effective clip region.</para>

-  </glossdef>

-</glossentry>

-

-<glossentry id='effective_bounding_region'>

-  <glossterm>effective bounding region</glossterm>

-  <glossdef><para>The actual shape of the window on the screen, including

-border and interior (but excluding the effects of overlapping windows).

-When a window has a client bounding region, the effective bounding region

-is the intersection of the default bounding region and the client bounding

-region.  Otherwise, the effective bounding region is the same as the

-default bounding region.</para>

-  </glossdef>

-</glossentry>

-

-<glossentry id='effective_clip_region'>

-  <glossterm>effective clip region</glossterm>

-  <glossdef><para>The actual shape of the interior of the window on the

-screen (excluding the effects of overlapping windows).  When a window

-has a client clip region or a client bounding region, the effective

-clip region is the intersection of the default clip region, the client

-clip region (if any) and the client bounding region (if any).  Otherwise,

-the effective clip region is the same as the default clip region.</para>

-  </glossdef>

-</glossentry>

-</glossary>

-</book>

+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="shapelib">
+
+<bookinfo>
+   <title>X Nonrectangular Window Shape Extension Library</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>X Version 11, Release 6.4</releaseinfo>
+   <authorgroup>
+      <author>
+         <firstname>Keith</firstname><surname>Packard</surname>
+      </author>
+   </authorgroup>
+   <corpname>MIT X Consortium</corpname>
+   <copyright><year>1989</year><holder>X Consortium</holder></copyright>
+   <releaseinfo>Version 1.0</releaseinfo>
+   <affiliation><orgname>MIT X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 6.4</productnumber>
+
+<legalnotice>
+
+<para>
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files
+(the &ldquo;Software&rdquo;), to deal in the Software without restriction,
+including without limitation the rights to use, copy, modify, merge,
+publish, distribute, sublicense, and/or sell copies of the Software, and
+to permit persons to whom the Software is furnished to do so, subject to
+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='overview'>
+<title>Overview</title>
+
+<para>This extension provides arbitrary window and border shapes within
+the X11 protocol.
+</para>
+
+<para>
+The restriction of rectangular windows within the X protocol is a significant
+limitation in the implementation of many styles of user interface.  For
+example, many transient windows would like to display a
+&ldquo;drop shadow&rdquo; to give the illusion of 3 dimensions.  As
+another example, some user interface style guides call for buttons with
+rounded corners; the full simulation of a nonrectangular shape,
+particularly with respect to event distribution and cursor shape, is not
+possible within the core X protocol.  As a final example, round clocks
+and nonrectangular icons are desirable visual addition to the desktop.
+</para>
+
+<para>
+This extension provides mechanisms for changing the visible shape of a
+window to an arbitrary, possibly disjoint, nonrectangular form.  The intent
+of the extension is to supplement the existing semantics, not replace them.
+In particular, it is desirable for clients that are unaware of the
+extension to still be able to cope reasonably with shaped windows.  For
+example, window managers should still be able to negotiate screen
+real estate in rectangular pieces.  Toward this end, any shape specified for
+a window is clipped by the bounding rectangle for the window as specified by
+the window's geometry in the core protocol.  An expected convention would be
+that client programs expand their shape to fill the area offered by the
+window manager.
+</para>
+</chapter>
+
+<chapter id='description'>
+<title>Description</title>
+
+<para>
+Each window (even with no shapes specified) is defined by two regions:  the
+<emphasis remap='I'>bounding region</emphasis> and the
+<emphasis remap='I'>clip region</emphasis>.  The bounding region is the
+area of the parent window that the window will occupy (including border).
+The clip region is the subset of the bounding region that is available for
+subwindows and graphics.  The area between the bounding region and the
+clip region is defined to be the border of the window.
+</para>
+
+<para>
+A nonshaped window will have a bounding region that is a rectangle spanning
+the window, including its border; the clip region will be a rectangle
+filling the inside dimensions (not including the border).  In this document,
+these areas are referred to as the
+<emphasis remap='I'>default bounding region</emphasis> and the
+<emphasis remap='I'>default clip region</emphasis>.  For a window with
+inside size of <emphasis remap='I'>width</emphasis> by
+<emphasis remap='I'>height</emphasis> and border width
+<emphasis remap='I'>bwidth</emphasis>, the default bounding and clip
+regions are the rectangles (relative to the window origin):
+</para>
+
+<literallayout remap='Ds'>
+bounding.x = -<emphasis remap='I'>bwidth</emphasis>
+bounding.y = -<emphasis remap='I'>bwidth</emphasis>
+bounding.width = <emphasis remap='I'>width</emphasis> + 2 * <emphasis remap='I'>bwidth</emphasis>
+bounding.height = <emphasis remap='I'>height</emphasis> + 2 * <emphasis remap='I'>bwidth</emphasis>
+
+clip.x = 0
+clip.y = 0
+clip.width = <emphasis remap='I'>width</emphasis>
+clip.height = <emphasis remap='I'>height</emphasis>
+</literallayout>
+
+<para>
+This extension allows a client to modify either or both of the bounding or
+clip regions by specifying new regions that combine with the default
+regions.  These new regions are called the
+<emphasis remap='I'>client bounding region</emphasis> and the
+<emphasis remap='I'>client clip region</emphasis>.  They are specified
+relative to the origin of the window and are always defined by offsets
+relative to the window origin (that is, region adjustments are not
+required when the window is moved).  Three mechanisms for specifying
+regions are provided:  a list of rectangles, a bitmap, and an existing
+bounding or clip region from a window.  This is modeled on the specification
+of regions in graphics contexts in the core protocol and allows a variety
+of different uses of the extension.
+</para>
+
+<para>
+When using an existing window shape as an operand in specifying a new shape,
+the client region is used, unless none has been set, in which case the
+default region is used instead.
+</para>
+
+<para>
+The <emphasis remap='I'>effective bounding region</emphasis> of a window is
+defined to be the intersection of the client bounding region with the default
+bounding region.  Any portion of the client bounding region that is not
+included in the default bounding region will not be included in the
+effective bounding region on the screen.  This means that window managers
+(or other geometry managers) used to dealing with rectangular client windows
+will be able to constrain the client to a rectangular area of the screen.
+</para>
+
+<para>
+Construction of the effective bounding region is dynamic; the client bounding
+region is not mutated to obtain the effective bounding region.  If a client
+bounding region is specified that extends beyond the current default bounding
+region, and the window is later enlarged, the effective bounding region will
+be enlarged to include more of the client bounding region.
+</para>
+
+<para>
+The <emphasis remap='I'>effective clip region</emphasis> of a window is
+defined to be the intersection of the client clip region with both the
+default clip region and the client bounding region.  Any portion of the
+client clip region that is not included in both the default clip region
+and the client bounding region will not be included in the effective clip
+region on the screen.
+</para>
+
+<para>
+Construction of the effective clip region is dynamic; the client clip region is
+not mutated to obtain the effective clip region.  If a client clip region is
+specified that extends beyond the current default clip region and the
+window or its bounding region is later enlarged, the effective clip region will
+be enlarged to include more of the client clip region if it is included in
+the effective bounding region.
+</para>
+
+<para>
+The border of a window is defined to be the difference between the effective
+bounding region and the effective clip region.  If this region is empty, no
+border is displayed.  If this region is nonempty, the border is filled
+using the border-tile or border-pixel of the window as specified in the core
+protocol.  Note that a window with a nonzero border width will never be able
+to draw beyond the default clip region of the window.  Also note that a zero
+border width does not prevent a window from having a border, since the clip
+shape can still be made smaller than the bounding shape.
+</para>
+
+<para>
+All output to the window and visible regions of any subwindows will be
+clipped to the effective clip region.  The server must not retain window
+contents beyond the effective bounding region with backing store.  The window's
+origin (for graphics operations, background tiling, and subwindow placement)
+is not affected by the existence of a bounding region or clip region.
+</para>
+
+<para>
+Areas that are inside the default bounding region but outside the effective
+bounding region are not part of the window; these areas of the screen will
+be occupied by other windows.  Input events that occur within the default
+bounding region but outside the effective bounding region will be delivered as
+if the window was not occluding the event position.  Events that occur in
+a nonrectangular border of a window will be delivered to that window, just
+as for events that occur in a normal rectangular border.
+</para>
+
+<para>An
+<function>InputOnly</function>
+window can have its bounding region set, but it is a
+<function>Match</function>
+error to attempt to set a clip region on an
+<function>InputOnly</function>
+window or to specify its clip region as a source to a request
+in this extension.
+</para>
+
+<para>
+The server must accept changes to the clip region of a root window, but
+the server is permitted to ignore requested changes to the bounding region
+of a root window.  If the server accepts bounding region changes, the contents
+of the screen outside the bounding region are implementation dependent.
+</para>
+</chapter>
+
+<chapter id='c_language_binding'>
+<title>C Language Binding</title>
+
+<para>
+The C functions provide direct access to the protocol and add no additional
+semantics.
+</para>
+
+<para>The include file for this extension is
+&lt;<symbol role='Pn'>X11/extensions/shape.h</symbol>&gt;.
+The defined shape kinds are
+<function>ShapeBounding</function>
+and
+<function>ShapeClip</function>
+The defined region operations are
+<function>ShapeSet</function>
+<function>ShapeUnion</function>
+<function>ShapeIntersect</function>
+<function>ShapeSubtract</function>
+and
+<function>ShapeInvert</function>.</para>
+
+<funcsynopsis id='xshapequeryextension'>
+<funcprototype>
+<funcdef>Bool<function> XShapeQueryExtension</function></funcdef>
+<paramdef>Display <parameter>*display</parameter></paramdef>
+<paramdef>int <parameter>*event_base</parameter></paramdef>
+<paramdef>int <parameter>*error_base</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XShapeQueryExtension</function>
+returns
+<function>True</function>
+if the specified display supports the SHAPE extension else
+<function>False</function>
+If the extension is supported, *event_base is set to the event number for
+<function>ShapeNotify</function>
+events and *error_base would be set to the error number for the first error for
+this extension.  Because no errors are defined for this version of
+the extension, the value returned here is not defined (nor useful).
+</para>
+
+<funcsynopsis id='xshapequeryversion'>
+<funcprototype>
+<funcdef>Status<function> XShapeQueryVersion</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>int<parameter> *major_version</parameter></paramdef>
+<paramdef>int<parameter> *minor_version</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeQueryVersion</function>
+sets the major and minor version numbers of the
+extension supported by the display and returns a nonzero value.
+Otherwise, the arguments are not set and zero is returned.
+</para>
+
+<funcsynopsis id='xshapecombineregion'>
+<funcprototype>
+<funcdef><function>XShapeCombineRegion</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> dest</parameter></paramdef>
+<paramdef>int<parameter> dest_kind</parameter></paramdef>
+<paramdef>int<parameter> x_off</parameter></paramdef>
+<paramdef>int<parameter> y_off</parameter></paramdef>
+<paramdef>int<parameter> region</parameter></paramdef>
+<paramdef>int<parameter> op</parameter></paramdef>
+<paramdef>REGION<parameter> *region</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XShapeCombineRegion</function>
+converts the specified region into a list of rectangles and calls
+<function>XShapeCombineRectangles</function>
+</para>
+
+<funcsynopsis id='xshapecombinerectangles'>
+<funcprototype>
+<funcdef><function>XShapeCombineRectangles</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> dest</parameter></paramdef>
+<paramdef>int<parameter> dest_kind</parameter></paramdef>
+<paramdef>int<parameter> x_off</parameter></paramdef>
+<paramdef>int<parameter> y_off</parameter></paramdef>
+<paramdef>XRectangle<parameter> *rectangles</parameter></paramdef>
+<paramdef>int<parameter> n_rects</parameter></paramdef>
+<paramdef>int<parameter> op</parameter></paramdef>
+<paramdef>int<parameter> ordering</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeCombineRectangles</function>
+performs a
+<function>ShapeRectangles</function>
+operation; otherwise, the request is ignored.
+</para>
+
+<funcsynopsis id='xshapecombinemask'>
+<funcprototype>
+<funcdef><function>XShapeCombineMask</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>int<parameter> dest</parameter></paramdef>
+<paramdef>int<parameter> dest_kind</parameter></paramdef>
+<paramdef>int<parameter> x_off</parameter></paramdef>
+<paramdef>int<parameter> y_off</parameter></paramdef>
+<paramdef>Pixmap<parameter> src</parameter></paramdef>
+<paramdef>int<parameter> op</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeCombineMask</function>
+performs a
+<function>ShapeMask</function>
+operation; otherwise, the request is ignored.
+</para>
+
+<funcsynopsis id='xshapecombineshape'>
+<funcprototype>
+<funcdef><function>XShapeCombineShape</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> dest</parameter></paramdef>
+<paramdef>int<parameter> dest_kind</parameter></paramdef>
+<paramdef>int<parameter> x_off</parameter></paramdef>
+<paramdef>int<parameter> y_off</parameter></paramdef>
+<paramdef>Window<parameter> src</parameter></paramdef>
+<paramdef>int<parameter> src_kind</parameter></paramdef>
+<paramdef>int<parameter> op</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeCombineShape</function>
+performs a
+<function>ShapeCombine</function>
+operation; otherwise, the request is ignored.
+</para>
+
+<funcsynopsis id='xshapeoffsetshape'>
+<funcprototype>
+<funcdef><function>XShapeOffsetShape</function></funcdef>
+<paramdef><parameter>display</parameter></paramdef>
+<paramdef><parameter>dest</parameter></paramdef>
+<paramdef><parameter>dest_kind</parameter></paramdef>
+<paramdef><parameter>x_off</parameter></paramdef>
+<paramdef><parameter>y_off</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeOffsetShape</function>
+performs a
+<function>ShapeOffset</function>
+operation; otherwise, the request is ignored.
+</para>
+
+<funcsynopsis id='xshapequeryextents'>
+<funcprototype>
+<funcdef>Status <function>XShapeQueryExtents</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> window</parameter></paramdef>
+<paramdef>Bool<parameter> *bounding_shaped</parameter></paramdef>
+<paramdef>int<parameter> *x_bounding</parameter></paramdef>
+<paramdef>int<parameter> *y_bounding</parameter></paramdef>
+<paramdef>unsigned int<parameter> *w_bounding</parameter></paramdef>
+<paramdef>unsigned int<parameter> *h_bounding</parameter></paramdef>
+<paramdef>Bool<parameter> *clip_shaped</parameter></paramdef>
+<paramdef>int<parameter> *x_clip</parameter></paramdef>
+<paramdef>int<parameter> *y_clip</parameter></paramdef>
+<paramdef>unsigned int<parameter> *w_clip</parameter></paramdef>
+<paramdef>unsigned int<parameter> *h_clip</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is supported,
+<function>XShapeQueryExtents</function>
+sets x_bounding, y_bounding, w_bounding, h_bounding to the extents of the
+bounding shape and sets x_clip, y_clip, w_clip, h_clip to the extents of
+the clip shape.  For unspecified client regions, the extents of the
+corresponding default region are used.
+</para>
+
+<para>
+If the extension is supported, a nonzero value is returned; otherwise,
+zero is returned.
+</para>
+
+<funcsynopsis id='xshapeselectinput'>
+<funcprototype>
+<funcdef><function>XShapeSelectInput</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> window</parameter></paramdef>
+<paramdef>unsigned long<parameter> mask</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+To make this extension more compatible with other interfaces, although
+only one event type can be selected via the extension,
+<function>XShapeSelectInput</function>
+provides a general mechanism similar to the standard Xlib binding for
+window events.  A mask value has been defined,
+<function>ShapeNotifyMask</function>
+that is the only valid bit in mask that may be specified.
+The structure for this event is defined as follows:
+</para>
+
+<literallayout remap='Ds'>
+typedef struct {
+    int type;     /* of event */
+    unsigned long serial;     /* # of last request processed by server */
+    Bool send_event;     /* true if this came frome a SendEvent request */
+    Display *display;     /* Display the event was read from */
+    Window window;     /* window of event */
+    int kind;     /* ShapeBounding or ShapeClip */
+    int x, y;     /* extents of new region */
+    unsigned width, height;
+    Time time;     /* server timestamp when region changed */
+    Bool shaped;     /* true if the region exists */
+} XShapeEvent;
+</literallayout>
+
+<funcsynopsis id='xshapeinputselected'>
+<funcprototype>
+<funcdef>unsigned long <function>XShapeInputSelected</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> window</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XShapeInputSelected</function>
+returns the current input mask for extension events on the specified
+window; the value returned if
+<function>ShapeNotify</function>
+is selected for is
+<function>ShapeNotifyMask</function>
+otherwise, it returns zero.
+If the extension is not supported, it returns zero.
+</para>
+
+<funcsynopsis id='xshapegetrectangles'>
+<funcprototype>
+<funcdef>XRectangle<function> *XShapeGetRectangles</function></funcdef>
+<paramdef>Display<parameter> *display</parameter></paramdef>
+<paramdef>Window<parameter> window</parameter></paramdef>
+<paramdef>int<parameter> kind</parameter></paramdef>
+<paramdef>int<parameter> *count</parameter></paramdef>
+<paramdef>int<parameter> *ordering</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If the extension is not supported,
+<function>XShapeGetRectangles</function>
+returns NULL.  Otherwise, it returns a list of rectangles that describe the
+region specified by kind.
+</para>
+</chapter>
+
+<glossary id='glossary'>
+
+<glossentry id='bounding_region'>
+  <glossterm>bounding region</glossterm>
+  <glossdef><para>The area of the parent window that this window will occupy.
+This area is divided into two parts:  the border and the interior.</para>
+  </glossdef>
+</glossentry>
+
+<glossentry id='clip_region'>
+  <glossterm>clip region</glossterm>
+  <glossdef><para>The interior of the window, as a subset of the bounding
+region.  This region describes the area that will be painted with the
+window background when the window is cleared, will contain all graphics
+output to the window, and will clip any subwindows.</para></glossdef>
+</glossentry>
+
+<glossentry id='default_bounding_region'>
+  <glossterm>default bounding region</glossterm>
+  <glossdef><para>The rectangular area, as described by the core protocol
+window size, that covers the interior of the window and its border.</para>
+  </glossdef>
+</glossentry>
+
+<glossentry id='default_clip_region'>
+  <glossterm>default clip region</glossterm>
+  <glossdef><para>The rectangular area, as described by the core protocol
+window size, that covers the interior of the window and excludes the border.
+  </para></glossdef>
+</glossentry>
+
+<glossentry id='client_bounding_region'>
+  <glossterm>client bounding region</glossterm>
+  <glossdef><para>The region associated with a window that is directly
+modified via this extension when specified by
+<function>ShapeBounding</function>
+This region is used in conjunction with the default bounding region
+to produce the effective bounding region.</para></glossdef>
+</glossentry>
+
+<glossentry id='client_clip_region'>
+  <glossterm>client clip region</glossterm>
+  <glossdef><para>The region associated with a window that is directly
+modified via this extension when specified by
+<function>ShapeClip</function>
+This region is used in conjunction with the default clip region
+and the client bounding region to produce the effective clip region.</para>
+  </glossdef>
+</glossentry>
+
+<glossentry id='effective_bounding_region'>
+  <glossterm>effective bounding region</glossterm>
+  <glossdef><para>The actual shape of the window on the screen, including
+border and interior (but excluding the effects of overlapping windows).
+When a window has a client bounding region, the effective bounding region
+is the intersection of the default bounding region and the client bounding
+region.  Otherwise, the effective bounding region is the same as the
+default bounding region.</para>
+  </glossdef>
+</glossentry>
+
+<glossentry id='effective_clip_region'>
+  <glossterm>effective clip region</glossterm>
+  <glossdef><para>The actual shape of the interior of the window on the
+screen (excluding the effects of overlapping windows).  When a window
+has a client clip region or a client bounding region, the effective
+clip region is the intersection of the default clip region, the client
+clip region (if any) and the client bounding region (if any).  Otherwise,
+the effective clip region is the same as the default clip region.</para>
+  </glossdef>
+</glossentry>
+</glossary>
+</book>
diff --git a/libXext/specs/synclib.xml b/libXext/specs/synclib.xml
index 3edeaaaa7..36c716297 100644
--- a/libXext/specs/synclib.xml
+++ b/libXext/specs/synclib.xml
@@ -1,813 +1,813 @@
-<?xml version="1.0" encoding="UTF-8" ?>

-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"

-                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">

-

-

-<!-- lifted from troff+ms+XMan by doclifter -->

-<book id="synclib">

-

-<bookinfo>

-   <title>X Synchronization Extension Library</title>

-   <subtitle>X Consortium Standard</subtitle>

-   <releaseinfo>X Version 11, Release 6.4</releaseinfo>

-   <authorgroup>

-      <author>

-        <firstname>Tim</firstname><surname>Glauert</surname>

-        <affiliation><orgname>Olivetti Research/MultiWorks</orgname></affiliation>

-      </author>

-      <author>

-          <firstname>Dave</firstname>

-          <surname>Carver</surname>

-          <affiliation><orgname>Digital Equipment Corporation, MIT/Project Athena</orgname></affiliation>

-      </author>

-      <author>

-        <firstname>Jim</firstname>

-        <surname>Gettys</surname>

-        <affiliation><orgname>Digital Equipment Corporation, Cambridge Research Laboratory</orgname></affiliation>

-      </author>

-      <author>

-        <firstname>David</firstname>

-        <surname>Wiggins</surname>

-        <affiliation><orgname>X Consortium, Inc.</orgname></affiliation>

-      </author>

-   </authorgroup>

-   <releaseinfo>Version 3.0</releaseinfo>

-   <affiliation><orgname>X Consortium</orgname></affiliation>

-   <productnumber>X Version 11, Release 6.4</productnumber>

-<legalnotice>

-

-<para>

-Copyright 1991 by Olivetti Research Limited, Cambridge England and Digital Equipment Corporation, Maynard, Massachusetts

-</para>

-

-<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>

-</legalnotice>

-

-<legalnotice>

-

-<para>

-Copyright &copy; 1991 X Consortium, Inc.

-</para>

-

-<para>

-Permission is hereby granted, free of charge, to any person obtaining

-a copy of this software and associated documentation files

-(the "Software"), to deal in the Software without

-restriction, including without limitation the rights to use, copy,

-modify, merge, publish, distribute, sublicense, and/or sell copies of

-the Software, and to permit persons to whom the Software is furnished

-to do so, subject to the following conditions:

-</para>

-

-<para>

-The above copyright notice and this permission notice shall be included in

-all copies or substantial portions of the Software.

-</para>

-

-<para>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,

-EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF

-MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

-IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR

-OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,

-ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR

-OTHER DEALINGS IN THE SOFTWARE.

-</para>

-

-<para>

-Except as contained in this notice, the name of the X Consortium shall

-not be used in advertising or otherwise to promote the sale, use or other

-dealings in this Software without prior written authorization from the

-X Consortium.

-</para>

-

-</legalnotice>

-</bookinfo>

-

-<chapter id="synchronization_protocol">

-<title>Synchronization Protocol</title>

-

-<para>

-The core X protocol makes no guarantees about the relative order of

-execution of requests for different clients.  This means that any

-synchronization between clients must be done at the client level in an

-operating system-dependent and network-dependent manner. Even if there

-was an accepted standard for such synchronization, the use of a network

-introduces unpredictable delays between the synchronization of the clients and

-the delivery of the resulting requests to the X server.

-</para>

-<para>

-The core X protocol also makes no guarantees about the time at which

-requests are executed, which means that all clients with real-time constraints

-must implement their timing on the host computer. Any such timings are

-subject to error introduced by delays within the operating system and

-network and are inefficient because of the need for round-trip requests that

-keep the client and server synchronized.

-</para>

-<para>

-The synchronization extension provides primitives that allow synchronization

-between clients to take place entirely within the X server. This removes any

-error introduced by the network and makes it possible to synchronize clients

-on different hosts running different operating systems. This is important for

-multimedia applications, where audio, video, and graphics data streams are

-being synchronized. The extension also provides internal timers within the X

-server to which client requests can be synchronized. This allows simple

-animation applications to be implemented without any round-trip requests

-and makes best use of buffering within the client, network, and server.

-</para>

-

-<sect1 id="description">

-<title>Description</title>

-<para>

-The mechanism used by this extension for synchronization within the X server

-is to block the processing of requests from a client until a specific

-synchronization condition occurs. When the condition occurs, the client is

-released and processing of requests continues. Multiple clients may block on

-the same condition to give inter-client synchronization. Alternatively, a single

-client may block on a condition such as an animation frame marker.

-</para>

-<para>

-The extension adds <function>Counter</function> and

-<function>Alarm</function> to the set of resources managed by

-the server. A counter has a 64-bit integer value that may be increased or

-decreased by client requests or by the server internally. A client can

-block by sending an <function>Await</function> request that waits until

-one of a set of synchronization conditions, called TRIGGERs, becomes TRUE.

-</para>

-<para>

-The <function>CreateCounter</function> request allows a client to create

-a <function>Counter</function> that can be changed by explicit

-<function>SetCounter</function> and <function>ChangeCounter</function>

-requests. These can be used to implement synchronization between

-different clients.

-</para>

-<para>

-There are some counters, called <function>System Counters</function>,

-that are changed by the server internally rather than by client

-requests. The effect of any change to a system counter is not visible

-until the server has finished processing the current request. In other

-words, system counters are apparently updated in the gaps between the

-execution of requests rather than during the actual execution of a

-request. The extension provides a system counter that advances with the

-server time as defined by the core protocol, and it may also provide

-counters that advance with the real-world time or that change each

-time the CRT screen is refreshed. Other extensions may provide their own

-extension-specific system counters.

-</para>

-<para>

-The extension provides an <function>Alarm</function> mechanism that allows clients to receive an

-event on a regular basis when a particular counter is changed.

-</para>

-</sect1>

-</chapter>

-

-<chapter id="c_language_binding">

-<title>C Language Binding</title>

-

-<para>

-The C routines provide direct access to the protocol and add no additional

-semantics.

-</para>

-<para>

-The include file for this extension is &lt;X11/extensions/sync.h&gt;.

-Most of the names in the language binding are derived from the protocol

-names by prepending XSync to the protocol name and changing the

-capitalization.

-</para>

-

-<sect1 id="c_functions">

-<title>C Functions</title>

-

-<para>

-Most of the following functions generate SYNC protocol requests.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncQueryExtension</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-    <paramdef>int <parameter> *event_base_return</parameter></paramdef>

-    <paramdef>int <parameter> *error_base_return</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-If dpy supports the SYNC extension,

-<function>XSyncQueryExtension</function> returns True,

-sets *event_base_return to the event number for the first SYNC event, and

-sets *error_base_return to the error number for the first SYNC error. If dpy

-does not support the SYNC extension, it returns False.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncInitialize</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-    <paramdef>int <parameter> *major_version_return</parameter></paramdef>

-    <paramdef>int <parameter> *minor_version_return</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncInitialize</function> sets *major_version_return and

-*minor version return to the major/minor SYNC protocol version supported

-by the server. If the XSync library is compatible with the version

-returned by the server, this function returns <function>True</function>.

-If dpy does not support the SYNC extension, or if there was an error

-during communication with the server, or if the server and library protocol

-versions are incompatible, this function returns <function>False</function>.

-The only XSync function that may be called before this function is

-XSyncQueryExtension. If a client violates this rule, the effects of all XSync

-calls that it makes are undefined.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>XSyncSystemCounter *<function>XSyncListSystemCounters</function></funcdef>

-    <paramdef>Display <parameter> *dpy</parameter></paramdef>

-    <paramdef>int <parameter> *n_counters_return</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncListSystemCounters</function> returns a pointer to an array

-of system counters supported by the display and sets *n_counters_return

-to the number of counters in the array.  The array should be freed with

-<function>XSyncFreeSystemCounterList</function>. If dpy does not support

-the SYNC extension, or if there was an error during communication with

-the server, or if the server does not support any system counters,

-this function returns NULL.

-</para>

-

-<para>

-XSyncSystemCounter has the following fields:

-</para>

-

-<literallayout remap='Ds'>

-char *              name;        /* null-terminated name of system counter */

-XSyncCounter        counter;     /* counter id of this system counter */

-XSyncValue          resolution;  /* resolution of this system counter */

-</literallayout>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>void <function>XSyncFreeSystemCounterList</function></funcdef>

-    <paramdef>XSyncSystemCounter <parameter> *list</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncFreeSystemCounterList</function> frees the memory

-associated with the system counter list returned by

-<function>XSyncListSystemCounters</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>XSyncCounter <function>XSyncCreateCounter</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> initial_value</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncCreateCounter</function> creates a counter on the dpy

-with the given initial value and returns the counter ID. It returns

-<function>None</function> if dpy does not support the SYNC extension.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncSetCounter</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> value</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-

-<para>

-<function>XSyncSetCounter</function> sets counter to value. It returns

-<function>False </function> if dpy does not

-support the SYNC extension; otherwise, it returns <function>True</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncChangeCounter</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> value</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncChangeCounter</function> adds value to counter. It returns

-<function>False</function> if dpy does not support the SYNC extension;

-otherwise, it returns

-<function>True</function>.

-</para>

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncDestroyCounter</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncDestroyCounter</function> destroys counter. It returns

-<function>False</function> if dpy does not support the SYNC extension;

-otherwise, it returns <function>True</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncQueryCounter</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> *value_return</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncQueryCounter</function> sets *value_return to the current

-value of counter. It returns <function>False</function> if there was an

-error during communication with the server or if dpy does not support the

-SYNC extension; otherwise, it returns <function>True</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncAwait</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XSyncWaitCondition<parameter> *wait_list</parameter></paramdef>

-    <paramdef>int<parameter> n_conditions</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncAwait</function> awaits on the conditions in wait_list.

-The n_conditions is the number of wait conditions in wait_list. It

-returns <function>False</function> if dpy does not support the SYNC

-extension; otherwise, it returns <function>True</function>. The await is

-processed asynchronously by the server; this function always returns

-immediately after issuing the request.

-</para>

-<para>

-XSyncWaitCondition has the following fields:

-</para>

-

-<literallayout remap='Ds'>

-XSyncCounter     trigger.counter;    /*counter to trigger on */

-XSyncValueType   trigger.value_type; /*absolute/relative */

-XSyncValue       trigger.wait_value; /*value to compare counter to */

-XSyncTestType    trigger.test_type;  /*pos/neg comparison/transtion */

-XSyncValue       event_threshold;    /*send event if past threshold */

-</literallayout>

-

-<para>

-<function>XSyncValueType</function> can be either

-<function>XSyncAbsolute</function> or <function>XSyncRelative</function>.

-</para>

-

-<para>

-<function>XSyncTestType</function> can be one of

-<function>XSyncPositiveTransition</function>,

-<function>XSyncNegativeTransition</function>,

-<function>XSyncPositiveComparison</function>, or

-<function>XSyncNegativeComparison</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>XSyncAlarm <function>XSyncCreateAlarm</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>unsigned long<parameter> values_mask</parameter></paramdef>

-    <paramdef>XSyncAlarmAttributes<parameter> *values`</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncCreateAlarm</function> creates an alarm and returns the

-alarm ID. It returns None if the display does not support the SYNC

-extension. The values_mask and values specify the alarm attributes.

-</para>

-

-<para>

-<function>XSyncAlarmAttributes</function> has the following fields. The

-attribute_mask column specifies the symbol that the caller should OR

-into values_mask to indicate that the value for the corresponding

-attribute was actually supplied. Default values are used for all

-attributes that do not have their attribute_mask OR’ed into values_mask.

-See the protocol description for <function>CreateAlarm</function> for the

-defaults.

-</para>

-

-<literallayout remap='Ds'>

-type                 field name           attribute_mask

-XSyncCounter       trigger.counter;     XSyncCACounter

-XSyncValueType     trigger.value_type;  XSyncCAValueType

-XSyncValue         trigger.wait_value;  XSyncCAValue

-XSyncTestType      trigger.test_type;   XSyncCATestType

-XSyncValue         delta;               XSyncCADelta

-Bool               events;              XSyncCAEvents

-XSyncAlarmState    state;               client cannot set this

-</literallayout>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncDestroyAlarm</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XSyncAlarm<parameter> alarm</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncDestroyAlarm</function> destroys alarm. It returns

-<function>False</function> if dpy does not support

-the SYNC extension; otherwise, it returns <function>True</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncQueryAlarm</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XSyncAlarm<parameter> alarm</parameter></paramdef>

-    <paramdef>XSyncAlarmAttributes<parameter> *values_return</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-

-<para>

-<function>XSyncQueryAlarm</function> sets *values_return to the alarm’s

-attributes. It returns <function>False</function> if there was an error

-during communication with the server or if dpy does not support the

-SYNC extension; otherwise, it returns <function>True</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncChangeAlarm</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XSyncAlarm<parameter> alarm</parameter></paramdef>

-    <paramdef>unsigned long<parameter> values_mask</parameter></paramdef>

-    <paramdef>XSyncAlarmAttributes<parameter> *values</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncChangeAlarm</function> changes alarm’s attributes. The

-attributes to change are specified as in

-<function>XSyncCreateAlarm</function>. It returns

-<function>False</function> if dpy does not support

-the SYNC extension; otherwise, it returns <function>True</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncSetPriority</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XID<parameter> client_resource_id</parameter></paramdef>

-    <paramdef>int<parameter> priority</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncSetPriority</function> sets the priority of the client

-owning client_resource_id to priority. If client_resource_id is None, it

-sets the caller’s priority. It returns

-<function>False</function> if dpy does not support the SYNC extension;

-otherwise, it returns <function>True</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Status <function>XSyncGetPriority</function></funcdef>

-    <paramdef>Display<parameter> *dpy</parameter></paramdef>

-    <paramdef>XID<parameter> client_resource_id</parameter></paramdef>

-    <paramdef>int<parameter> *return_priority</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-<function>XSyncGetPriority</function> sets *return_priority to the

-priority of the client owning client_resource_id. If client_resource_id

-is None, it sets *return_priority to the caller’s priority. It returns

-<function>False</function> if there was an error during communication

-with the server or if dpy does not support the SYNC extension; otherwise, it

-returns <function>True</function>.

-</para>

-

-</sect1>

-

-<sect1 id="c_macros_functions">

-<title>C Macros/Functions</title>

-

-<para>

-The following procedures manipulate 64-bit values. They are defined both as

-macros and as functions. By default, the macro form is used. To use the

-function form, #undef the macro name to uncover the function.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>void <function>XSyncIntToValue</function></funcdef>

-    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>

-    <paramdef>int<parameter> i</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Converts i to an <function>XSyncValue</function> and stores it in *pv.

-Performs sign extension (*pv will have the same sign as i.)

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>void <function>XSyncIntsToValue</function></funcdef>

-    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>

-    <paramdef>unsigned int<parameter> low</parameter></paramdef>

-    <paramdef>int<parameter> high</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Stores low in the low 32 bits of *pv and high in the high 32 bits of *pv.

-</para>

-

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>XSyncValueGreaterThan</function></funcdef>

-    <paramdef>XSyncValue<parameter> a</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> b</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns <function>True</function> if a is greater than b, else returns

-<function>False</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>XSyncValueLessThan</function></funcdef>

-    <paramdef>XSyncValue<parameter> a</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> b</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns <function>True</function> if a is less than b, else returns

-<function>False</function>.

-</para>

-

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>XSyncValueGreaterOrEqual</function></funcdef>

-    <paramdef>XSyncValue<parameter> a</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> b</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns <function>True</function> if a is greater than or equal to b,

-else returns <function>False</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>XSyncValueLessOrEqual</function></funcdef>

-    <paramdef>XSyncValue<parameter> a</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> b</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns <function>True</function> if a is less than or equal to b,

-else returns <function>False</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>XSyncValueEqual</function></funcdef>

-    <paramdef>XSyncValue<parameter> a</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> b</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns <function>True</function> if a is equal to b,

-else returns <function>False</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>XSyncValueIsNegative</function></funcdef>

-    <paramdef>XSyncValue<parameter> v</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns <function>True</function> if v is negative,

-else returns <function>False</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>XSyncValueIsZero</function></funcdef>

-    <paramdef>XSyncValue<parameter> v</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns <function>True</function> if v is zero,

-else returns <function>False</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>Bool <function>XSyncValueIsPositive</function></funcdef>

-    <paramdef>XSyncValue<parameter> v</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns <function>True</function> if v is positive,

-else returns <function>False</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>unsigned int <function>XSyncValueLow32</function></funcdef>

-    <paramdef>XSyncValue<parameter> v</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns the low 32 bits of v.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>unsigned int <function>XSyncValueHigh32</function></funcdef>

-    <paramdef>XSyncValue<parameter> v</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Returns the high 32 bits of v.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>void <function>XSyncValueAdd</function></funcdef>

-    <paramdef>XSyncValue<parameter> *presult</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> a</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> b</parameter></paramdef>

-    <paramdef>Bool<parameter> *poverflow</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Adds a to b and stores the result in *presult. If the result could not

-fit in 64 bits, *poverflow is set to <function>True</function>, else it is

-set to <function>False</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>void <function>XSyncValueSubtract</function></funcdef>

-    <paramdef>XSyncValue<parameter> *presult</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> a</parameter></paramdef>

-    <paramdef>XSyncValue<parameter> b</parameter></paramdef>

-    <paramdef>Bool<parameter> *poverflow</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Subtracts b from a and stores the result in *presult. If the result could not

-fit in 64 bits, *poverflow is set to <function>True</function>, else it is

-set to <function>False</function>.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>void <function>XSyncMaxValue</function></funcdef>

-    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Sets *pv to the maximum value expressible in 64 bits.

-</para>

-

-<funcsynopsis>

-<funcprototype>

-  <funcdef>void <function>XSyncMinValue</function></funcdef>

-    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>

-</funcprototype>

-</funcsynopsis>

-

-<para>

-Sets *pv to the minimum value expressible in 64 bits.

-</para>

-

-</sect1>

-

-<sect1 id="events">

-<title>Events</title>

-

-<para>

-Let <emphasis remap='I'>event_base</emphasis> be the value event base return as defined in the function

-<function>XSyncQueryExtension</function>.

-</para>

-

-<para>

-An <function>XSyncCounterNotifyEvent</function>’s type field has the value

-event_base + <function>XSyncCounterNotify</function>. The fields of this

-structure are:

-</para>

-

-<literallayout remap='Ds'>

-int              type;          /* event base + XSyncCounterNotify */

-unsigned long    serial;        /* number of last request processed by server */

-Bool             send event;    /* true if this came from a SendEvent request */

-Display *        display;       /* Display the event was read from */

-XSyncCounter     counter;       /* counter involved in await */

-XSyncValue       wait_value;    /* value being waited for */

-XSyncValue       counter_value; /* counter value when this event was sent */

-Time             time;          /* milliseconds */

-int              count;         /* how many more events to come */

-Bool             destroyed;     /* True if counter was destroyed */

-</literallayout>

-

-<para>

-An <function>XSyncAlarmNotifyEvent</function>’s type field has the value

-event_base + <function>XSyncAlarmNotify</function>. The fields of

-this structure are:

-</para>

-

-<literallayout remap='Ds'>

-int             type;         /* event_base + XSyncAlarmNotify */

-unsigned long   serial;       /* number of last request processed by server */

-Bool            send_event;   /* true if this came from a SendEvent request */

-Display *       display;      /*Display the event was read from */

-XSyncAlarm      alarm;        /* alarm that triggered */

-XSyncValue      counter_value /* value that triggered the alarm */

-XSyncValue      alarm_value   /* test value of trigger in alarm */

-Time            time;         /* milliseconds */

-XSyncAlarmState state;        /* new state of alarm */

-</literallayout>

-

-</sect1>

-

-<sect1 id="errors">

-<title>Errors</title>

-<para>

-Let <emphasis remap='I'>error_base</emphasis> be the value

-<emphasis remap='I'>error_base_return</emphasis> as defined in the function

-<function>XSyncQueryExtension</function>.

-</para>

-

-<para>

-An <function>XSyncAlarmError</function>’s error_code field has

-<function>XSyncBadAlarm</function>. The fields of this structure are:

-</para>

-

-<literallayout remap='Ds'>

-int                type

-Display *          display;      /* Display the event was read from */

-XSyncCounter       counter;      /* resource id */

-unsigned long      serial;       /* serial number of failed request */

-unsigned char      error_code;   /* error_base + XSyncBadAlarm */

-unsigned char      request_code; /* Major op-code of failed request */

-unsigned char      minor_code;   /* Minor op-code of failed request */

-</literallayout>

-

-<para>

-An <function>XSyncCounterError</function>’s error code field has the value

-error_base + <function>XSyncBadCounter</function>. The fields of this

-structure are:

-</para>

-<literallayout remap='Ds'>

-int                type

-Display *          display;      /* Display the event was read from */

-XSyncCounter       counter;      /* resource id */

-unsigned long      serial;       /* serial number of failed request */

-unsigned char      error_code;   /* error_base + XSyncBadCounter */

-unsigned char      request_code; /* Major op-code of failed request */

-unsigned char      minor_code;   /* Minor op-code of failed request */

-</literallayout>

-

-</sect1>

-</chapter>

-</book>

+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+                   "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="synclib">
+
+<bookinfo>
+   <title>X Synchronization Extension Library</title>
+   <subtitle>X Consortium Standard</subtitle>
+   <releaseinfo>X Version 11, Release 6.4</releaseinfo>
+   <authorgroup>
+      <author>
+        <firstname>Tim</firstname><surname>Glauert</surname>
+        <affiliation><orgname>Olivetti Research/MultiWorks</orgname></affiliation>
+      </author>
+      <author>
+          <firstname>Dave</firstname>
+          <surname>Carver</surname>
+          <affiliation><orgname>Digital Equipment Corporation, MIT/Project Athena</orgname></affiliation>
+      </author>
+      <author>
+        <firstname>Jim</firstname>
+        <surname>Gettys</surname>
+        <affiliation><orgname>Digital Equipment Corporation, Cambridge Research Laboratory</orgname></affiliation>
+      </author>
+      <author>
+        <firstname>David</firstname>
+        <surname>Wiggins</surname>
+        <affiliation><orgname>X Consortium, Inc.</orgname></affiliation>
+      </author>
+   </authorgroup>
+   <releaseinfo>Version 3.0</releaseinfo>
+   <affiliation><orgname>X Consortium</orgname></affiliation>
+   <productnumber>X Version 11, Release 6.4</productnumber>
+<legalnotice>
+
+<para>
+Copyright 1991 by Olivetti Research Limited, Cambridge England and Digital Equipment Corporation, Maynard, Massachusetts
+</para>
+
+<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>
+</legalnotice>
+
+<legalnotice>
+
+<para>
+Copyright &copy; 1991 X Consortium, Inc.
+</para>
+
+<para>
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files
+(the "Software"), to deal in the Software without
+restriction, including without limitation the rights to use, copy,
+modify, merge, publish, distribute, sublicense, and/or sell copies of
+the Software, and to permit persons to whom the Software is furnished
+to do so, subject to the following conditions:
+</para>
+
+<para>
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+</para>
+
+<para>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR
+OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+OTHER DEALINGS IN THE SOFTWARE.
+</para>
+
+<para>
+Except as contained in this notice, the name of the X Consortium shall
+not be used in advertising or otherwise to promote the sale, use or other
+dealings in this Software without prior written authorization from the
+X Consortium.
+</para>
+
+</legalnotice>
+</bookinfo>
+
+<chapter id="synchronization_protocol">
+<title>Synchronization Protocol</title>
+
+<para>
+The core X protocol makes no guarantees about the relative order of
+execution of requests for different clients.  This means that any
+synchronization between clients must be done at the client level in an
+operating system-dependent and network-dependent manner. Even if there
+was an accepted standard for such synchronization, the use of a network
+introduces unpredictable delays between the synchronization of the clients and
+the delivery of the resulting requests to the X server.
+</para>
+<para>
+The core X protocol also makes no guarantees about the time at which
+requests are executed, which means that all clients with real-time constraints
+must implement their timing on the host computer. Any such timings are
+subject to error introduced by delays within the operating system and
+network and are inefficient because of the need for round-trip requests that
+keep the client and server synchronized.
+</para>
+<para>
+The synchronization extension provides primitives that allow synchronization
+between clients to take place entirely within the X server. This removes any
+error introduced by the network and makes it possible to synchronize clients
+on different hosts running different operating systems. This is important for
+multimedia applications, where audio, video, and graphics data streams are
+being synchronized. The extension also provides internal timers within the X
+server to which client requests can be synchronized. This allows simple
+animation applications to be implemented without any round-trip requests
+and makes best use of buffering within the client, network, and server.
+</para>
+
+<sect1 id="description">
+<title>Description</title>
+<para>
+The mechanism used by this extension for synchronization within the X server
+is to block the processing of requests from a client until a specific
+synchronization condition occurs. When the condition occurs, the client is
+released and processing of requests continues. Multiple clients may block on
+the same condition to give inter-client synchronization. Alternatively, a single
+client may block on a condition such as an animation frame marker.
+</para>
+<para>
+The extension adds <function>Counter</function> and
+<function>Alarm</function> to the set of resources managed by
+the server. A counter has a 64-bit integer value that may be increased or
+decreased by client requests or by the server internally. A client can
+block by sending an <function>Await</function> request that waits until
+one of a set of synchronization conditions, called TRIGGERs, becomes TRUE.
+</para>
+<para>
+The <function>CreateCounter</function> request allows a client to create
+a <function>Counter</function> that can be changed by explicit
+<function>SetCounter</function> and <function>ChangeCounter</function>
+requests. These can be used to implement synchronization between
+different clients.
+</para>
+<para>
+There are some counters, called <function>System Counters</function>,
+that are changed by the server internally rather than by client
+requests. The effect of any change to a system counter is not visible
+until the server has finished processing the current request. In other
+words, system counters are apparently updated in the gaps between the
+execution of requests rather than during the actual execution of a
+request. The extension provides a system counter that advances with the
+server time as defined by the core protocol, and it may also provide
+counters that advance with the real-world time or that change each
+time the CRT screen is refreshed. Other extensions may provide their own
+extension-specific system counters.
+</para>
+<para>
+The extension provides an <function>Alarm</function> mechanism that allows clients to receive an
+event on a regular basis when a particular counter is changed.
+</para>
+</sect1>
+</chapter>
+
+<chapter id="c_language_binding">
+<title>C Language Binding</title>
+
+<para>
+The C routines provide direct access to the protocol and add no additional
+semantics.
+</para>
+<para>
+The include file for this extension is &lt;X11/extensions/sync.h&gt;.
+Most of the names in the language binding are derived from the protocol
+names by prepending XSync to the protocol name and changing the
+capitalization.
+</para>
+
+<sect1 id="c_functions">
+<title>C Functions</title>
+
+<para>
+Most of the following functions generate SYNC protocol requests.
+</para>
+
+<funcsynopsis id='xsyncqueryextension'>
+<funcprototype>
+  <funcdef>Status <function>XSyncQueryExtension</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>int <parameter> *event_base_return</parameter></paramdef>
+    <paramdef>int <parameter> *error_base_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+If dpy supports the SYNC extension,
+<function>XSyncQueryExtension</function> returns True,
+sets *event_base_return to the event number for the first SYNC event, and
+sets *error_base_return to the error number for the first SYNC error. If dpy
+does not support the SYNC extension, it returns False.
+</para>
+
+<funcsynopsis id='xsyncinitialize'>
+<funcprototype>
+  <funcdef>Status <function>XSyncInitialize</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>int <parameter> *major_version_return</parameter></paramdef>
+    <paramdef>int <parameter> *minor_version_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncInitialize</function> sets *major_version_return and
+*minor version return to the major/minor SYNC protocol version supported
+by the server. If the XSync library is compatible with the version
+returned by the server, this function returns <function>True</function>.
+If dpy does not support the SYNC extension, or if there was an error
+during communication with the server, or if the server and library protocol
+versions are incompatible, this function returns <function>False</function>.
+The only XSync function that may be called before this function is
+XSyncQueryExtension. If a client violates this rule, the effects of all XSync
+calls that it makes are undefined.
+</para>
+
+<funcsynopsis id='xsynclistsystemcounters'>
+<funcprototype>
+  <funcdef>XSyncSystemCounter *<function>XSyncListSystemCounters</function></funcdef>
+    <paramdef>Display <parameter> *dpy</parameter></paramdef>
+    <paramdef>int <parameter> *n_counters_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncListSystemCounters</function> returns a pointer to an array
+of system counters supported by the display and sets *n_counters_return
+to the number of counters in the array.  The array should be freed with
+<function>XSyncFreeSystemCounterList</function>. If dpy does not support
+the SYNC extension, or if there was an error during communication with
+the server, or if the server does not support any system counters,
+this function returns NULL.
+</para>
+
+<para>
+XSyncSystemCounter has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+char *              name;        /* null-terminated name of system counter */
+XSyncCounter        counter;     /* counter id of this system counter */
+XSyncValue          resolution;  /* resolution of this system counter */
+</literallayout>
+
+<funcsynopsis id='xsyncfreesystemcounterlist'>
+<funcprototype>
+  <funcdef>void <function>XSyncFreeSystemCounterList</function></funcdef>
+    <paramdef>XSyncSystemCounter <parameter> *list</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncFreeSystemCounterList</function> frees the memory
+associated with the system counter list returned by
+<function>XSyncListSystemCounters</function>.
+</para>
+
+<funcsynopsis id='xsynccreatecounter'>
+<funcprototype>
+  <funcdef>XSyncCounter <function>XSyncCreateCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> initial_value</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncCreateCounter</function> creates a counter on the dpy
+with the given initial value and returns the counter ID. It returns
+<function>None</function> if dpy does not support the SYNC extension.
+</para>
+
+<funcsynopsis id='xsyncsetcounter'>
+<funcprototype>
+  <funcdef>Status <function>XSyncSetCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> value</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+
+<para>
+<function>XSyncSetCounter</function> sets counter to value. It returns
+<function>False </function> if dpy does not
+support the SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis id='xsyncchangecounter'>
+<funcprototype>
+  <funcdef>Status <function>XSyncChangeCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> value</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncChangeCounter</function> adds value to counter. It returns
+<function>False</function> if dpy does not support the SYNC extension;
+otherwise, it returns
+<function>True</function>.
+</para>
+<funcsynopsis id='xsyncdestroycounter'>
+<funcprototype>
+  <funcdef>Status <function>XSyncDestroyCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncDestroyCounter</function> destroys counter. It returns
+<function>False</function> if dpy does not support the SYNC extension;
+otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis id='xsyncquerycounter'>
+<funcprototype>
+  <funcdef>Status <function>XSyncQueryCounter</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncCounter<parameter> counter</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> *value_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncQueryCounter</function> sets *value_return to the current
+value of counter. It returns <function>False</function> if there was an
+error during communication with the server or if dpy does not support the
+SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis id='xsyncawait'>
+<funcprototype>
+  <funcdef>Status <function>XSyncAwait</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncWaitCondition<parameter> *wait_list</parameter></paramdef>
+    <paramdef>int<parameter> n_conditions</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncAwait</function> awaits on the conditions in wait_list.
+The n_conditions is the number of wait conditions in wait_list. It
+returns <function>False</function> if dpy does not support the SYNC
+extension; otherwise, it returns <function>True</function>. The await is
+processed asynchronously by the server; this function always returns
+immediately after issuing the request.
+</para>
+<para>
+XSyncWaitCondition has the following fields:
+</para>
+
+<literallayout remap='Ds'>
+XSyncCounter     trigger.counter;    /*counter to trigger on */
+XSyncValueType   trigger.value_type; /*absolute/relative */
+XSyncValue       trigger.wait_value; /*value to compare counter to */
+XSyncTestType    trigger.test_type;  /*pos/neg comparison/transtion */
+XSyncValue       event_threshold;    /*send event if past threshold */
+</literallayout>
+
+<para>
+<function>XSyncValueType</function> can be either
+<function>XSyncAbsolute</function> or <function>XSyncRelative</function>.
+</para>
+
+<para>
+<function>XSyncTestType</function> can be one of
+<function>XSyncPositiveTransition</function>,
+<function>XSyncNegativeTransition</function>,
+<function>XSyncPositiveComparison</function>, or
+<function>XSyncNegativeComparison</function>.
+</para>
+
+<funcsynopsis id='xsynccreatealarm'>
+<funcprototype>
+  <funcdef>XSyncAlarm <function>XSyncCreateAlarm</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>unsigned long<parameter> values_mask</parameter></paramdef>
+    <paramdef>XSyncAlarmAttributes<parameter> *values`</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncCreateAlarm</function> creates an alarm and returns the
+alarm ID. It returns None if the display does not support the SYNC
+extension. The values_mask and values specify the alarm attributes.
+</para>
+
+<para>
+<function>XSyncAlarmAttributes</function> has the following fields. The
+attribute_mask column specifies the symbol that the caller should OR
+into values_mask to indicate that the value for the corresponding
+attribute was actually supplied. Default values are used for all
+attributes that do not have their attribute_mask OR’ed into values_mask.
+See the protocol description for <function>CreateAlarm</function> for the
+defaults.
+</para>
+
+<literallayout remap='Ds'>
+type                 field name           attribute_mask
+XSyncCounter       trigger.counter;     XSyncCACounter
+XSyncValueType     trigger.value_type;  XSyncCAValueType
+XSyncValue         trigger.wait_value;  XSyncCAValue
+XSyncTestType      trigger.test_type;   XSyncCATestType
+XSyncValue         delta;               XSyncCADelta
+Bool               events;              XSyncCAEvents
+XSyncAlarmState    state;               client cannot set this
+</literallayout>
+
+<funcsynopsis id='xsyncdestroyalarm'>
+<funcprototype>
+  <funcdef>Status <function>XSyncDestroyAlarm</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncAlarm<parameter> alarm</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncDestroyAlarm</function> destroys alarm. It returns
+<function>False</function> if dpy does not support
+the SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis id='xsyncqueryalarm'>
+<funcprototype>
+  <funcdef>Status <function>XSyncQueryAlarm</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncAlarm<parameter> alarm</parameter></paramdef>
+    <paramdef>XSyncAlarmAttributes<parameter> *values_return</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+
+<para>
+<function>XSyncQueryAlarm</function> sets *values_return to the alarm’s
+attributes. It returns <function>False</function> if there was an error
+during communication with the server or if dpy does not support the
+SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis id='xsyncchangealarm'>
+<funcprototype>
+  <funcdef>Status <function>XSyncChangeAlarm</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XSyncAlarm<parameter> alarm</parameter></paramdef>
+    <paramdef>unsigned long<parameter> values_mask</parameter></paramdef>
+    <paramdef>XSyncAlarmAttributes<parameter> *values</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncChangeAlarm</function> changes alarm’s attributes. The
+attributes to change are specified as in
+<function>XSyncCreateAlarm</function>. It returns
+<function>False</function> if dpy does not support
+the SYNC extension; otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis id='xsyncsetpriority'>
+<funcprototype>
+  <funcdef>Status <function>XSyncSetPriority</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XID<parameter> client_resource_id</parameter></paramdef>
+    <paramdef>int<parameter> priority</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncSetPriority</function> sets the priority of the client
+owning client_resource_id to priority. If client_resource_id is None, it
+sets the caller’s priority. It returns
+<function>False</function> if dpy does not support the SYNC extension;
+otherwise, it returns <function>True</function>.
+</para>
+
+<funcsynopsis id='xsyncgetpriority'>
+<funcprototype>
+  <funcdef>Status <function>XSyncGetPriority</function></funcdef>
+    <paramdef>Display<parameter> *dpy</parameter></paramdef>
+    <paramdef>XID<parameter> client_resource_id</parameter></paramdef>
+    <paramdef>int<parameter> *return_priority</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+<function>XSyncGetPriority</function> sets *return_priority to the
+priority of the client owning client_resource_id. If client_resource_id
+is None, it sets *return_priority to the caller’s priority. It returns
+<function>False</function> if there was an error during communication
+with the server or if dpy does not support the SYNC extension; otherwise, it
+returns <function>True</function>.
+</para>
+
+</sect1>
+
+<sect1 id="c_macros_functions">
+<title>C Macros/Functions</title>
+
+<para>
+The following procedures manipulate 64-bit values. They are defined both as
+macros and as functions. By default, the macro form is used. To use the
+function form, #undef the macro name to uncover the function.
+</para>
+
+<funcsynopsis id='xsyncinttovalue'>
+<funcprototype>
+  <funcdef>void <function>XSyncIntToValue</function></funcdef>
+    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>
+    <paramdef>int<parameter> i</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Converts i to an <function>XSyncValue</function> and stores it in *pv.
+Performs sign extension (*pv will have the same sign as i.)
+</para>
+
+<funcsynopsis id='xsyncintstovalue'>
+<funcprototype>
+  <funcdef>void <function>XSyncIntsToValue</function></funcdef>
+    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>
+    <paramdef>unsigned int<parameter> low</parameter></paramdef>
+    <paramdef>int<parameter> high</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Stores low in the low 32 bits of *pv and high in the high 32 bits of *pv.
+</para>
+
+
+<funcsynopsis id='xsyncvaluegreaterthan'>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueGreaterThan</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is greater than b, else returns
+<function>False</function>.
+</para>
+
+<funcsynopsis id='xsyncvaluelessthan'>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueLessThan</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is less than b, else returns
+<function>False</function>.
+</para>
+
+
+<funcsynopsis id='xsyncvaluegreaterorequal'>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueGreaterOrEqual</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is greater than or equal to b,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis id='xsyncvaluelessorequal'>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueLessOrEqual</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is less than or equal to b,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis id='xsyncvalueequal'>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueEqual</function></funcdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if a is equal to b,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis id='xsyncvalueisnegative'>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueIsNegative</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if v is negative,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis id='xsyncvalueiszero'>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueIsZero</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if v is zero,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis id='xsyncvalueispositive'>
+<funcprototype>
+  <funcdef>Bool <function>XSyncValueIsPositive</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns <function>True</function> if v is positive,
+else returns <function>False</function>.
+</para>
+
+<funcsynopsis id='xsyncvaluelow32'>
+<funcprototype>
+  <funcdef>unsigned int <function>XSyncValueLow32</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns the low 32 bits of v.
+</para>
+
+<funcsynopsis id='xsyncvaluehigh32'>
+<funcprototype>
+  <funcdef>unsigned int <function>XSyncValueHigh32</function></funcdef>
+    <paramdef>XSyncValue<parameter> v</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Returns the high 32 bits of v.
+</para>
+
+<funcsynopsis id='xsyncvalueadd'>
+<funcprototype>
+  <funcdef>void <function>XSyncValueAdd</function></funcdef>
+    <paramdef>XSyncValue<parameter> *presult</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+    <paramdef>Bool<parameter> *poverflow</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Adds a to b and stores the result in *presult. If the result could not
+fit in 64 bits, *poverflow is set to <function>True</function>, else it is
+set to <function>False</function>.
+</para>
+
+<funcsynopsis id='xsyncvaluesubtract'>
+<funcprototype>
+  <funcdef>void <function>XSyncValueSubtract</function></funcdef>
+    <paramdef>XSyncValue<parameter> *presult</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> a</parameter></paramdef>
+    <paramdef>XSyncValue<parameter> b</parameter></paramdef>
+    <paramdef>Bool<parameter> *poverflow</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Subtracts b from a and stores the result in *presult. If the result could not
+fit in 64 bits, *poverflow is set to <function>True</function>, else it is
+set to <function>False</function>.
+</para>
+
+<funcsynopsis id='xsyncmaxvalue'>
+<funcprototype>
+  <funcdef>void <function>XSyncMaxValue</function></funcdef>
+    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Sets *pv to the maximum value expressible in 64 bits.
+</para>
+
+<funcsynopsis id='xsyncminvalue'>
+<funcprototype>
+  <funcdef>void <function>XSyncMinValue</function></funcdef>
+    <paramdef>XSyncValue<parameter> *pv</parameter></paramdef>
+</funcprototype>
+</funcsynopsis>
+
+<para>
+Sets *pv to the minimum value expressible in 64 bits.
+</para>
+
+</sect1>
+
+<sect1 id="events">
+<title>Events</title>
+
+<para>
+Let <emphasis remap='I'>event_base</emphasis> be the value event base return as defined in the function
+<function>XSyncQueryExtension</function>.
+</para>
+
+<para>
+An <function>XSyncCounterNotifyEvent</function>’s type field has the value
+event_base + <function>XSyncCounterNotify</function>. The fields of this
+structure are:
+</para>
+
+<literallayout remap='Ds'>
+int              type;          /* event base + XSyncCounterNotify */
+unsigned long    serial;        /* number of last request processed by server */
+Bool             send event;    /* true if this came from a SendEvent request */
+Display *        display;       /* Display the event was read from */
+XSyncCounter     counter;       /* counter involved in await */
+XSyncValue       wait_value;    /* value being waited for */
+XSyncValue       counter_value; /* counter value when this event was sent */
+Time             time;          /* milliseconds */
+int              count;         /* how many more events to come */
+Bool             destroyed;     /* True if counter was destroyed */
+</literallayout>
+
+<para>
+An <function>XSyncAlarmNotifyEvent</function>’s type field has the value
+event_base + <function>XSyncAlarmNotify</function>. The fields of
+this structure are:
+</para>
+
+<literallayout remap='Ds'>
+int             type;         /* event_base + XSyncAlarmNotify */
+unsigned long   serial;       /* number of last request processed by server */
+Bool            send_event;   /* true if this came from a SendEvent request */
+Display *       display;      /*Display the event was read from */
+XSyncAlarm      alarm;        /* alarm that triggered */
+XSyncValue      counter_value /* value that triggered the alarm */
+XSyncValue      alarm_value   /* test value of trigger in alarm */
+Time            time;         /* milliseconds */
+XSyncAlarmState state;        /* new state of alarm */
+</literallayout>
+
+</sect1>
+
+<sect1 id="errors">
+<title>Errors</title>
+<para>
+Let <emphasis remap='I'>error_base</emphasis> be the value
+<emphasis remap='I'>error_base_return</emphasis> as defined in the function
+<function>XSyncQueryExtension</function>.
+</para>
+
+<para>
+An <function>XSyncAlarmError</function>’s error_code field has
+<function>XSyncBadAlarm</function>. The fields of this structure are:
+</para>
+
+<literallayout remap='Ds'>
+int                type
+Display *          display;      /* Display the event was read from */
+XSyncCounter       counter;      /* resource id */
+unsigned long      serial;       /* serial number of failed request */
+unsigned char      error_code;   /* error_base + XSyncBadAlarm */
+unsigned char      request_code; /* Major op-code of failed request */
+unsigned char      minor_code;   /* Minor op-code of failed request */
+</literallayout>
+
+<para>
+An <function>XSyncCounterError</function>’s error code field has the value
+error_base + <function>XSyncBadCounter</function>. The fields of this
+structure are:
+</para>
+<literallayout remap='Ds'>
+int                type
+Display *          display;      /* Display the event was read from */
+XSyncCounter       counter;      /* resource id */
+unsigned long      serial;       /* serial number of failed request */
+unsigned char      error_code;   /* error_base + XSyncBadCounter */
+unsigned char      request_code; /* Major op-code of failed request */
+unsigned char      minor_code;   /* Minor op-code of failed request */
+</literallayout>
+
+</sect1>
+</chapter>
+</book>