From bfb19bed915a30b5542fe8fee4e91151f25ec3b9 Mon Sep 17 00:00:00 2001
From: marha <marha@users.sourceforge.net>
Date: Fri, 9 Jul 2010 14:19:56 +0000
Subject: git update 9/7/2010

---
 libXext/specs/dbelib.tex | 621 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 621 insertions(+)
 create mode 100644 libXext/specs/dbelib.tex

(limited to 'libXext/specs/dbelib.tex')

diff --git a/libXext/specs/dbelib.tex b/libXext/specs/dbelib.tex
new file mode 100644
index 000000000..a1b526b6f
--- /dev/null
+++ b/libXext/specs/dbelib.tex
@@ -0,0 +1,621 @@
+% $Xorg: dbelib.tex,v 1.3 2000/08/17 19:42:31 cpqbld Exp $
+% edited for DP edits and code consistency w/ core protocol/xlib 3/30/96
+% split into separate library and protocol documentos 4/15/96
+\documentstyle{article}
+\pagestyle{myheadings}
+\markboth{Double Buffer Extension Specification}{Double Buffer Extension Specification}
+\setlength{\parindent}{0 pt}
+\setlength{\parskip}{6pt}
+\setlength{\topsep}{0 pt}
+
+% Request names are literal symbols; therefore, use the same font for both.
+\newcommand{\requestname}[1]{{\tt #1}}
+\newcommand{\literal}[1]{\mbox{\tt #1}}
+
+\newcommand{\encodingsection}[1]{{\bf #1}}
+\newcommand{\requestsection}[1]{{\bf #1}}
+
+% Font treatment of type names differs between protocol and library sections.
+\newcommand{\libtypename}[1]{\mbox{\tt #1}}
+\newcommand{\typename}[1]{\mbox{\rm #1}}  % default font
+\newcommand{\typeargname}[1]{\mbox{\rm #1}}  % default font
+\newcommand{\argname}[1]{\mbox{\it #1}}
+\newcommand{\argdecl}[2]{\argname{#1} & : \typename{#2}\\}
+\newcommand{\areplyargdecl}[2]{#1 & : \typename{#2}\\}
+
+\newenvironment{arequest}[1]{\requestsection{#1} \\ \begin{tabular}{ll}}{\end{tabular}}
+\newcommand{\areply}{$\Rightarrow$\\}
+
+\newcommand{\etabstops}{\hspace*{0cm}\=\hspace*{1cm}\=\hspace*{5cm}\=\kill}
+
+\newcommand{\eargdecl}[3]{\> #1 \> \typename{#2} \> #3 \\}
+
+\newenvironment{keeptogether}{\vbox \bgroup}{\egroup}
+
+\newenvironment{erequest}[3]{\pagebreak[3] \begin{keeptogether} \encodingsection{#1} \begin{tabbing} \etabstops \eargdecl{1}{CARD8}{major-opcode} \eargdecl{1}{#2}{minor-opcode} \eargdecl{2}{#3}{request length}}{\end{tabbing} \end{keeptogether}}
+
+\newenvironment{eerror}[1]{\begin{keeptogether} \encodingsection{#1} \begin{tabbing} \etabstops }{\end{tabbing} \end{keeptogether}}
+
+\newenvironment{etypedef}[1]{\begin{keeptogether} \typename{#1} \begin{tabbing} \etabstops }{\end{tabbing} \end{keeptogether}}
+
+\newcommand{\cfunctionname}[1]{\mbox{\tt #1}}
+\newcommand{\cfunctiondecl}[1]{\mbox{\rm #1}}
+\newcommand{\cargdecl}[2]{\penalty -1\typename{#1} \argname{#2}}
+\newenvironment{cfunction}[2]{\begin{sloppypar}\begin{keeptogether}\vspace{5mm}\typename{#1}\\ \cfunctiondecl{#2}\ (}{)\end{keeptogether}\end{sloppypar}{\hangafter=2 \hangindent=20pt \raggedright\par}}
+
+% make things easier with all the long names
+\spaceskip .3333em plus 5em
+\tolerance=2000
+
+\begin{document}
+
+\title{Double Buffer Extension Library\\Protocol Version 1.0\\X Consortium Standard}
+\author{Ian Elliott\\Hewlett-Packard Company \and David P. Wiggins\\X Consortium, Inc.}
+\maketitle
+\thispagestyle{empty}
+
+\eject
+
+Copyright \copyright 1989 X Consortium, Inc. and Digital Equipment Corporation.
+
+Copyright \copyright 1992 X Consortium, Inc. and Intergraph Corporation.
+
+Copyright \copyright 1993 X Consortium, Inc. and Silicon Graphics, Inc.
+
+Copyright \copyright 1994, 1995 X Consortium, Inc. and Hewlett-Packard Company.
+
+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.
+
+\eject
+
+\section{Introduction}
+
+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.
+
+\section{Goals}
+
+This extension should enable clients to:
+\begin{itemize}
+
+\item Allocate and deallocate double-buffering for a window.
+
+\item Draw to and read from the front and back buffers associated with
+a window.
+
+\item Swap the front and back buffers associated with a window.
+
+\item 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).
+
+\item Request that the front and back buffers associated with multiple
+double-buffered windows be swapped simultaneously.
+
+\end{itemize}
+
+In addition, the extension should:
+
+\begin{itemize}
+
+\item Allow multiple clients to use double-buffering on the same window.
+
+\item Support a range of implementation methods that can capitalize on
+existing hardware features.
+
+\item Add no new event types.
+
+\item Be reasonably easy to integrate with a variety of direct graphics
+hardware access (DGHA) architectures.
+\end{itemize}
+
+\section{Concepts}
+
+Normal windows are created using the core \requestname{CreateWindow}
+request, which allocates a set of window attributes and, for
+\literal{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.
+
+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 (\typename{XID}s) 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
+\typename{DRAWABLE} of type \typename{BACKBUFFER}.
+
+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.
+
+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.
+
+In general, both the front and back buffers are treated the same.  In
+particular, here are some important characteristics:
+
+\begin{itemize}
+
+\item Only one buffer per window can be visible at a time (the
+front buffer).
+
+\item Both buffers associated with a window have the same visual type,
+depth, width, height, and shape as the window.
+
+\item Both buffers associated with a window are ``visible'' (or
+``obscured'') in the same way.  When an \literal{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
+\literal{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.
+
+\item It is acceptable at any time to pass a \typename{BACKBUFFER} in
+any request, notably any core or extension drawing request, that
+expects a \typename{DRAWABLE}.  This enables an application to draw
+directly into \typename{BACKBUFFER}s in the same fashion as it would
+draw into any other \typename{DRAWABLE}.
+
+\item It is an error (\literal{Window}) to pass a \typename{BACKBUFFER} in a
+core request that expects a Window.
+
+\item A \typename{BACKBUFFER} will never be sent by core X in a reply,
+event, or error where a Window is specified.
+\item If core X11 backing-store and save-under applies to a
+double-buffered window, it applies to both buffers equally.
+
+\item If the core \requestname{ClearArea} request is executed on a
+double-buffered window, the same area in both the front and back
+buffers is cleared.
+
+\end{itemize}
+
+The effect of passing a window to a request that accepts a
+\typename{DRAWABLE} is unchanged by this extension.  The window and
+front buffer are synonomous with each other.  This includes obeying
+the \requestname{GetImage} semantics and the subwindow-mode semantics
+if a core graphics context is involved.  Regardless of whether the
+window was explicitly passed in a \requestname{GetImage} 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-na\"{\i}ve screen dump clients will always get the front buffer.
+\requestname{GetImage} on a back buffer returns undefined image
+contents for any obscured regions of the back buffer that fall within
+the image.
+
+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
+\literal{ClipByChildren}.  If an ancestor of a double-buffered window is drawn
+to with a core GC having a subwindow-mode of \literal{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 \literal{IncludeInferiors} drawing touched.
+
+DBE adds no new events.  DBE does not extend the semantics of any
+existing events with the exception of adding a new \typename{DRAWABLE}
+type called \typename{BACKBUFFER}.  If events, replies, or errors that
+contain a \typename{DRAWABLE} (for example, \literal{GraphicsExpose}) are
+generated in
+response to a request, the \typename{DRAWABLE} returned will be the
+one specified in the request.
+
+DBE advertises which visuals support double-buffering.
+
+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.
+
+\subsection{Window Management Operations}
+
+The basic philosophy of DBE is that both buffers are treated the same by
+core X window management operations.
+
+When the core \requestname{DestroyWindow} 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.
+
+If the core \requestname{ConfigureWindow} 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
+\requestname{ConfigureWindow} 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, \literal{Expose} events are generated for
+the region that is tiled with the window background.
+
+If the core \requestname{GetGeometry} request is executed on a
+\typename{BACKBUFFER}, the returned x, y, and border-width will be
+zero.
+
+If the Shape extension \requestname{ShapeRectangles},
+\requestname{ShapeMask}, \requestname{ShapeCombine}, or
+\requestname{ShapeOffset} request is executed on a double-buffered
+window, both buffers are reshaped to match the new window shape.  The
+region difference is the following:
+
+\[ D = new shape - old shape \]
+
+It is tiled with the window background in both buffers,
+and \literal{Expose} events are generated for D.
+
+\subsection{Complex Swap Actions}
+
+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.
+
+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: \requestname{DBEBeginIdiom} and
+\requestname{DBEEndIdiom}.  Unless this begin-end pair surrounds the
+idiom, it may not be recognized by a given implementation, and
+performance will suffer.
+
+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:
+
+\begin{itemize}
+\item \requestname{DBEBeginIdiom} request.
+\item \requestname{DBESwapBuffers} request with XIDs for two windows, each
+of which uses a swap action of \literal{Untouched}.
+\item Core X \requestname{PolyFillRectangle} request to the back buffer of one window.
+\item Core X \requestname{PolyFillRectangle} request to the back buffer of the other window.
+\item \requestname{DBEEndIdiom} request.
+\end{itemize}
+
+The \requestname{DBEBeginIdiom} and \requestname{DBEEndIdiom} 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.
+
+An idiom need not include a \requestname{DBESwapBuffers} request.  For
+example, if a swap action of \literal{Copied} is desired, but only some of the
+planes should be copied, a core X \requestname{CopyArea} request may
+be used instead of \requestname{DBESwapBuffers}.  If
+\requestname{DBESwapBuffers} is included in an idiom, it should
+immediately follow the \requestname{DBEBeginIdiom} request.  Also,
+when the \requestname{DBESwapBuffers} 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 \literal{Untouched}, and if a
+\requestname{PolyFillRectangle} using a client clip rectangle is done
+to the window's back buffer after the \requestname{DBESwapBuffers}
+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.
+
+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 \requestname{DBEBeginIdiom} request,
+the idiom requests, and \requestname{DBEEndIdiom} request.  Usage of
+these functions will ensure best possible performance across a wide
+variety of implementations.
+
+\section{C Language Binding}
+
+The header for this extension is \verb|<X11/extensions/Xdbe.h>|.  All
+identifier names provided by this header begin with Xdbe.
+
+\subsection{Types}
+
+The type \libtypename{XdbeBackBuffer} is a \libtypename{Drawable}.
+
+The type \libtypename{XdbeSwapAction} can be one of the constants
+\literal{XdbeUndefined}, \literal{XdbeBackground},
+\literal{XdbeUntouched}, or \literal{XdbeCopied}.
+
+\subsection{C Functions}
+
+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 \libtypename{Status} will return
+nonzero for success and zero for failure.
+
+% start marker
+\begin{keeptogether}
+\begin{cfunction}{Status}{XdbeQueryExtension}
+\cargdecl{Display *}{dpy},
+\cargdecl{int *}{major\_version\_return},
+\cargdecl{int *}{minor\_version\_return}
+\end{cfunction}
+% end marker
+
+\cfunctionname{XdbeQueryExtension} 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.
+\end{keeptogether}
+
+% start marker
+\begin{keeptogether}
+\begin{cfunction}{XdbeScreenVisualInfo *}{XdbeGetVisualInfo}
+\cargdecl{Display *}{dpy},
+\cargdecl{Drawable *}{screen\_specifiers},
+\cargdecl{int *}{num\_screens}
+\end{cfunction}
+% end marker
+
+\cfunctionname{XdbeGetVisualInfo}  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
+\libtypename{XdbeScreenVisualInfo} structures of length num\_screens.
+The {\it n}th element in the returned list corresponds to the {\it n}th
+drawable in the screen\_specifiers list, unless
+num\_screens was passed in with the value zero, in which
+case the {\it n}th element in the returned list corresponds to the
+{\it n}th screen of the server, starting with screen zero.
+
+The \libtypename{XdbeScreenVisualInfo} structure has the following
+fields:
+
+\begin{tabular}{lll}
+\typename{int} & \argname{count} & number of items in visinfo \\
+\typename{XdbeVisualInfo *} & \argname{visinfo} & list of visuals and depths for this screen \\
+\end{tabular}
+
+The \libtypename{XdbeVisualInfo} structure has the following fields:
+
+\begin{tabular}{lll}
+\typename{VisualID} & \argname{visual} & one visual ID that supports double-buffering\\
+\typename{int} & \argname{depth} & depth of visual in bits \\
+\typename{int} & \argname{perflevel} & performance level of visual \\
+\end{tabular}
+\end{keeptogether}
+
+% start marker
+\begin{keeptogether}
+\begin{cfunction}{void }{XdbeFreeVisualInfo}
+\cargdecl{XdbeScreenVisualInfo *}{visual\_info}
+\end{cfunction}
+% end marker
+
+\cfunctionname{XdbeFreeVisualInfo} frees the list of \libtypename{XdbeScreenVisualInfo}
+returned by \cfunctionname{XdbeGetVisualInfo}.
+\end{keeptogether}
+
+% start marker
+\begin{keeptogether}
+\begin{cfunction}{XdbeBackBuffer}{XdbeAllocateBackBufferName}
+\cargdecl{Display *}{dpy},
+\cargdecl{Window}{window},
+\cargdecl{XdbeSwapAction}{swap\_action}
+\end{cfunction}
+% end marker
+
+\cfunctionname{XdbeAllocateBackBufferName} 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
+\cfunctionname{XdbeSwapBuffers}. 
+The actual swap action used in calls to
+\cfunctionname{XdbeSwapBuffers} 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.
+\end{keeptogether}
+
+% start marker
+\begin{keeptogether}
+\begin{cfunction}{Status}{XdbeDeallocateBackBufferName}
+\cargdecl{Display *}{dpy},
+\cargdecl{XdbeBackBuffer}{buffer}
+\end{cfunction}
+% end marker
+
+\cfunctionname{XdbeDeallocateBackBufferName} frees the specified
+drawable ID, buffer,
+that was obtained via \cfunctionname{XdbeAllocateBackBufferName}.  The buffer
+must be a valid name for the back buffer of a window, or an
+\literal{XdbeBadBuffer}
+error results.
+\end{keeptogether}
+
+% start marker
+\begin{keeptogether}
+\begin{cfunction}{Status}{XdbeSwapBuffers}
+\cargdecl{Display *}{dpy},
+\cargdecl{XdbeSwapInfo *}{swap\_info},
+\cargdecl{int}{num\_windows}
+\end{cfunction}
+% end marker
+
+\cfunctionname{XdbeSwapBuffers} 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.
+
+The \libtypename{XdbeSwapInfo} structure has the following fields:
+
+\begin{tabular}{lll}
+\typename{Window} & \argname{swap\_window} & window for which to swap buffers \\
+\typename{XdbeSwapAction} & \argname{swap\_action} & swap action to use for this swap\_window \\
+\end{tabular}
+\end{keeptogether}
+
+% start marker
+\begin{keeptogether}
+\begin{cfunction}{Status}{XdbeBeginIdiom}
+\cargdecl{Display *}{dpy}
+\end{cfunction}
+% end marker
+
+\cfunctionname{XdbeBeginIdiom} marks the beginning of an idiom sequence.
+See section 3.2
+for a complete discussion of idioms.
+\end{keeptogether}
+
+% start marker
+\begin{keeptogether}
+\begin{cfunction}{Status}{XdbeEndIdiom}
+\cargdecl{Display *}{dpy}
+\end{cfunction}
+% end marker
+
+\cfunctionname{XdbeEndIdiom} marks the end of an idiom sequence.
+\end{keeptogether}
+
+% start marker
+\begin{keeptogether}
+\begin{cfunction}{XdbeBackBufferAttributes *}{XdbeGetBackBufferAttributes}
+\cargdecl{Display *}{dpy},
+\cargdecl{XdbeBackBuffer}{buffer}
+\end{cfunction}
+% end marker
+
+\cfunctionname{XdbeGetBackBufferAttributes} returns the attributes associated 
+with the specified buffer.
+
+The \libtypename{XdbeBackBufferAttributes} structure has the following fields:
+
+\begin{tabular}{lll}
+\typename{Window} & \argname{window} & window that buffer belongs to \\
+\end{tabular}
+
+If buffer is not a valid \libtypename{XdbeBackBuffer},
+window is set to \literal{None}.
+
+The returned \libtypename{XdbeBackBufferAttributes} structure can be
+freed with the Xlib function \cfunctionname{XFree}.
+\end{keeptogether}
+
+\begin{keeptogether}
+\subsection{Errors}
+
+The \libtypename{XdbeBufferError} structure has the following fields:
+
+\begin{tabular}{lll}
+\typename{int} & \argname{type} \\
+\typename{Display *} & \argname{display}& Display the event was read from\\
+\typename{XdbeBackBuffer} &  \argname{buffer}& resource id \\
+\typename{unsigned long} & \argname{serial}& serial number of failed request\\
+\typename{unsigned char} & \argname{error\_code}& error base + \literal{XdbeBadBuffer}\\
+\typename{unsigned char} & \argname{request\_code}& Major op-code of failed request\\
+\typename{unsigned char} & \argname{minor\_code}& Minor op-code of failed request\\
+\end{tabular}
+\end{keeptogether}
+
+\pagebreak[4]
+\section{Acknowledgements}
+
+We wish to thank the following individuals who have contributed their
+time and talent toward shaping the DBE specification:
+
+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.
+
+Mark provided the impetus to start the DBE project.  Ian wrote the
+first draft of the specification.  David served as architect.
+
+\section{References}
+
+Jeffrey Friedberg, Larry Seiler, and Jeff Vroom, ``Multi-buffering Extension
+Specification Version 3.3.''
+
+Tim Glauert, Dave Carver, Jim Gettys, and David P. Wiggins,
+``X Synchronization Extension Version 3.0.'' 
+
+\end{document}
-- 
cgit v1.2.3

