x11proto-xext: Changes to 'upstream-experimental'
.gitignore | 78
Makefile.am | 22
README | 42
configure.ac | 20
ge.h | 4
geproto.txt | 83
shapestr.h | 8
shmstr.h | 63
specs/.gitignore | 4
specs/Makefile.am | 75
specs/appendix.xml | 61
specs/appgroup.xml | 1018 ++++++++
specs/dbe.xml | 1061 ++++++++
specs/dpms.xml | 563 ++++
specs/evi.xml | 518 ++++
specs/geproto.xml | 97
specs/lbx.xml | 6291 +++++++++++++++++++++++++++++++++++++++++++++++++++++
specs/multibuf.xml | 1628 +++++++++++++
specs/security.xml | 1532 ++++++++++++
specs/shape.xml | 1236 ++++++++++
specs/shm.xml | 474 +++
specs/sync.xml | 1273 ++++++++++
specs/tog-cup.xml | 562 ++++
specs/xtest.xml | 722 ++++++
syncconst.h | 6
syncproto.h | 96
syncstr.h | 182 +
27 files changed, 17612 insertions(+), 107 deletions(-)
New commits:
commit b4e8a6fb63715442b4927d18d9cdd7ee78e50d00
Author: James Jones <jajones@nvidia.com>
Date: Mon Nov 29 09:35:50 2010 -0800
Bump version to 7.1.99.0
Use version 7.1.99.0 to mark the inclusion of
Fence Sync protocol support.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/configure.ac b/configure.ac
index 599651b..41269a3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
AC_PREREQ([2.60])
-AC_INIT([XExtProto], [7.1.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([XExtProto], [7.1.99.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit 6e696a0a4c9a115c7f080c2bdee3d8afc16b134f
Author: James Jones <jajones@nvidia.com>
Date: Wed Feb 24 15:57:29 2010 -0800
Add protocol for XSyncAwaitFence()
Add the fence sync object equivalent of
XSyncAwait()
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/syncproto.h b/syncproto.h
index 7e0a568..1453e44 100644
--- a/syncproto.h
+++ b/syncproto.h
@@ -72,6 +72,7 @@ PERFORMANCE OF THIS SOFTWARE.
#define X_SyncResetFence 16
#define X_SyncDestroyFence 17
#define X_SyncQueryFence 18
+#define X_SyncAwaitFence 19
/* cover up types from sync.h to make sure they're the right size for
* protocol packaging. These will be undef'ed after all the protocol
@@ -402,6 +403,17 @@ typedef struct _xSyncQueryFenceReq {
} xSyncQueryFenceReq;
#define sz_xSyncQueryFenceReq 8
+/*
+ * Wait for any of a list of fence sync objects
+ * to reach the "triggered" state.
+ */
+typedef struct _xSyncAwaitFenceReq {
+ CARD8 reqType;
+ CARD8 syncReqType;
+ CARD16 length B16;
+} xSyncAwaitFenceReq;
+#define sz_xSyncAwaitFenceReq 4
+
typedef struct {
BYTE type;
CARD8 unused;
commit 220b824f20dc3dd0fd6eae6e2896fb63aefbf11a
Author: James Jones <jajones@nvidia.com>
Date: Mon Feb 22 17:01:16 2010 -0800
Add XSyncQueryFence()
Allows callers to query whether a given fence sync
object is currently triggered or not.
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/syncproto.h b/syncproto.h
index c38ea84..7e0a568 100644
--- a/syncproto.h
+++ b/syncproto.h
@@ -71,6 +71,7 @@ PERFORMANCE OF THIS SOFTWARE.
#define X_SyncTriggerFence 15
#define X_SyncResetFence 16
#define X_SyncDestroyFence 17
+#define X_SyncQueryFence 18
/* cover up types from sync.h to make sure they're the right size for
* protocol packaging. These will be undef'ed after all the protocol
@@ -391,6 +392,33 @@ typedef struct _xSyncDestroyFenceReq {
#define sz_xSyncDestroyFenceReq 8
/*
+ * Query a fence object
+ */
+typedef struct _xSyncQueryFenceReq {
+ CARD8 reqType;
+ CARD8 syncReqType;
+ CARD16 length B16;
+ XSyncFence fid B32;
+} xSyncQueryFenceReq;
+#define sz_xSyncQueryFenceReq 8
+
+typedef struct {
+ BYTE type;
+ CARD8 unused;
+ CARD16 sequenceNumber B16;
+ CARD32 length B32;
+ BOOL triggered;
+ BYTE pad0;
+ CARD16 pad1 B16;
+ CARD32 pad2 B32;
+ CARD32 pad3 B32;
+ CARD32 pad4 B32;
+ CARD32 pad5 B32;
+ CARD32 pad6 B32;
+} xSyncQueryFenceReply;
+#define sz_xSyncQueryFenceReply 32
+
+/*
* Events
*/
commit d079ee210726d2407fa9c8cf99555daf2d96023a
Author: James Jones <jajones@nvidia.com>
Date: Fri Feb 12 16:38:08 2010 -0800
Initial Fence Sync support
Defines the protocol for creation and basic
management of binary state sync objects.
The following operations are defined:
-Creation
-Destruction
-Trigger
-Reset
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/syncconst.h b/syncconst.h
index 926b60c..3acc387 100644
--- a/syncconst.h
+++ b/syncconst.h
@@ -54,7 +54,7 @@ PERFORMANCE OF THIS SOFTWARE.
#define SYNC_NAME "SYNC"
#define SYNC_MAJOR_VERSION 3
-#define SYNC_MINOR_VERSION 0
+#define SYNC_MINOR_VERSION 1
#define XSyncCounterNotify 0
@@ -65,7 +65,8 @@ PERFORMANCE OF THIS SOFTWARE.
#define XSyncBadCounter 0L
#define XSyncBadAlarm 1L
-#define XSyncNumberErrors (XSyncBadAlarm + 1)
+#define XSyncBadFence 2L
+#define XSyncNumberErrors (XSyncBadFence + 1)
/*
* Flags for Alarm Attributes
@@ -172,6 +173,7 @@ typedef enum {
typedef XID XSyncCounter;
typedef XID XSyncAlarm;
+typedef XID XSyncFence;
typedef struct _XSyncValue {
int hi;
unsigned int lo;
diff --git a/syncproto.h b/syncproto.h
index 13b53d5..c38ea84 100644
--- a/syncproto.h
+++ b/syncproto.h
@@ -67,6 +67,10 @@ PERFORMANCE OF THIS SOFTWARE.
#define X_SyncDestroyAlarm 11
#define X_SyncSetPriority 12
#define X_SyncGetPriority 13
+#define X_SyncCreateFence 14
+#define X_SyncTriggerFence 15
+#define X_SyncResetFence 16
+#define X_SyncDestroyFence 17
/* cover up types from sync.h to make sure they're the right size for
* protocol packaging. These will be undef'ed after all the protocol
@@ -74,6 +78,8 @@ PERFORMANCE OF THIS SOFTWARE.
*/
#define XSyncCounter CARD32
#define XSyncAlarm CARD32
+#define XSyncFence CARD32
+#define Drawable CARD32
/*
* Initialize
@@ -337,6 +343,54 @@ typedef struct {
#define sz_xSyncGetPriorityReply 32
/*
+ * Create Fence
+ */
+typedef struct _xSyncCreateFenceReq {
+ CARD8 reqType;
+ CARD8 syncReqType;
+ CARD16 length B16;
+ Drawable d B32;
+ XSyncFence fid B32;
+ BOOL initially_triggered;
+ CARD8 pad0;
+ CARD16 pad1;
+} xSyncCreateFenceReq;
+#define sz_xSyncCreateFenceReq 16
+
+/*
+ * Put a fence object in the "triggered" state.
+ */
+typedef struct _xSyncTriggerFenceReq {
+ CARD8 reqType;
+ CARD8 syncReqType;
+ CARD16 length B16;
+ XSyncFence fid B32;
+} xSyncTriggerFenceReq;
+#define sz_xSyncTriggerFenceReq 8
+
+/*
+ * Put a fence in the "untriggered" state.
+ */
+typedef struct _xSyncResetFenceReq {
+ CARD8 reqType;
+ CARD8 syncReqType;
+ CARD16 length B16;
+ XSyncFence fid B32;
+} xSyncResetFenceReq;
+#define sz_xSyncResetFenceReq 8
+
+/*
+ * Destroy a fence object
+ */
+typedef struct _xSyncDestroyFenceReq {
+ CARD8 reqType;
+ CARD8 syncReqType;
+ CARD16 length B16;
+ XSyncFence fid B32;
+} xSyncDestroyFenceReq;
+#define sz_xSyncDestroyFenceReq 8
+
+/*
* Events
*/
@@ -373,6 +427,8 @@ typedef struct _xSyncAlarmNotifyEvent {
#undef XSyncCounter
#undef XSyncAlarm
+#undef XSyncFence
+#undef Drawable
#endif /* _SYNCPROTO_H_ */
commit 9ba2065b63ea0e61a17b8221ad454c02a1755373
Author: James Jones <jajones@nvidia.com>
Date: Wed Aug 11 15:03:59 2010 -0700
Document changes in XSync version 3.1
Signed-off-by: James Jones <jajones@nvidia.com>
Reviewed-by: Pierre-Loup Griffais <pgriffais@nvidia.com>
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Robert Morell <rmorell@nvidia.com>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/specs/sync.xml b/specs/sync.xml
index a8064a9..e61dc17 100644
--- a/specs/sync.xml
+++ b/specs/sync.xml
@@ -32,6 +32,11 @@ by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/) xhtml,docbook,html,ref
<surname>Wiggins</surname>
<affiliation><orgname>X Consortium, Inc.</orgname></affiliation>
</othercredit>
+ <othercredit>
+ <firstname>James</firstname>
+ <surname>Jones</surname>
+ <affiliation><orgname>NVIDIA Corporation</orgname></affiliation>
+ </othercredit>
</authorgroup>
<corpname>X Consortium Standard</corpname>
@@ -43,8 +48,9 @@ Digital Equipment Corporation, Maynard, Massachusetts
</holder>
</copyright>
<copyright><year>1991</year><holder>X Consortium</holder></copyright>
+ <copyright><year>2010</year><holder>NVIDIA Corporation</holder></copyright>
- <releaseinfo>Version 3.0</releaseinfo>
+ <releaseinfo>Version 3.1</releaseinfo>
<affiliation><orgname>X Consortium</orgname></affiliation>
<productnumber>X Version 11, Release 6.8</productnumber>
@@ -52,10 +58,10 @@ Digital Equipment Corporation, Maynard, Massachusetts
<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.
+copyright notice appear in all copies. Olivetti, Digital, MIT, the
+X Consortium, and NVIDIA make no representations about the suitability for
+any purpose of the information in this document. This documentation is
+provided as is without express or implied warranty.
</para>
<para>
@@ -133,12 +139,17 @@ frame marker.
</para>
<para>
-The extension adds <function>Counter</function> and
-<function>Alarm</function> to the set of resources managed by the
+The extension adds <function>Counter</function>, <function>Alarm</function>,
+and <function>Fence</function> to the set of resources managed by the
server. A counter has a 64-bit integer value that may be increased or
decreased by client requests or by the server internally. A client can block
by sending an Await request that waits until one of a set of synchronization
-conditions, called TRIGGERs, becomes TRUE.
+conditions, called TRIGGERs, becomes TRUE. Alarms generate events when
+counter values go through a specified transition. A fence has two possible
+states: triggered and not triggered. Client requests can put the fence in
+either of these states. A client can block until one of a set of fences
+becomes triggered by sending an AwaitFence request. Fences are bound to a
+particular screen at creation time.
</para>
<para>
@@ -168,6 +179,21 @@ clients to receive an event on a regular basis when a particular counter
is changed.
</para>
+<para>
+The <function>CreateFence</function> request allows a client to create a
+<function>Fence</function> that can be triggered and reset using
+<function>TriggerFence</function> and <function>ResetFence</function>
+requests, respectively. <function>CreateFence</function> takes a drawable
+argument that implies which screen the fence should be created on. The
+<function>TriggerFence</function> request changes the fence's state only
+after all previous rendering commands affecting objects owned by the given
+fence's screen have completed. Note that while fence objects are bound
+to a screen and the simple trigger operation provided by this extension
+operates at screen granularity, other extensions may add more fine-grained
+trigger operations based on any number of events. The screen binding
+merely establishes an upper bound for the scope of fence operations.
+</para>
+
</sect1>
<sect1 id="types">
<title>Types</title>
@@ -201,6 +227,7 @@ SYSTEMCOUNTER: [
]
ALARM: XID
ALARMSTATE: {Active,Inactive,Destroyed}
+FENCE: XID
</literallayout>
<para>
@@ -283,6 +310,14 @@ registry of system counter names to avoid collisions in the name space.
<para>
An ALARM is the client-side handle on an <function>Alarm</function> resource.
</para>
+
+<para>
+The FENCE type defines the client-side handle on a server
+<function>Fence</function>. A fence can only be in one of two states,
+represented by a BOOL. If the value is TRUE, the fence is in the triggered
+state. Otherwise, the fence is in the not triggered state.
+</para>
+
</sect1>
<sect1 id="errors">
@@ -307,6 +342,15 @@ does not name a defined ALARM.
</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>Fence</term>
+ <listitem>
+ <para>
+This error is generated if the value for a FENCE argument in a request
+does not name a defined FENCE.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
</sect1>
@@ -341,7 +385,7 @@ and v1.version_minor <= v2.version_minor. Compatible means that the
functionality is fully supported in an identical fashion in the two versions.
</para>
<para>
-This document describes major version 3, minor version 0 of the SYNC protocol.
+This document describes major version 3, minor version 1 of the SYNC protocol.
</para>
</listitem>
</varlistentry>
@@ -740,6 +784,118 @@ server.
</para>
</listitem>
</varlistentry>
+ <varlistentry>
+ <term>CreateFence</term>
+ <listitem>
+<literallayout class="monospaced">
+drawable: DRAWABLE
+id: FENCE
+initially-triggered: BOOL
+Errors: <function>IDChoice</function>,<function>Alloc</function>
+</literallayout>
+ <para>
+This request creates a fence on the screen associated with drawable and
+assigns the specified id to it. The fence is in the triggered state iff
+initially-triggered is TRUE. There are no clients waiting on the fence.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>TriggerFence</term>
+ <listitem>
+<literallayout class="monospaced">
+fence: FENCE
+Errors: <function>Fence</function>
+</literallayout>
+ <para>
+This request puts the given fence in the triggered state after all rendering
+from previous requests that affects resources owned by the fence's screen has
+completed. This includes requests from other clients if those requests have
+been dispatched. This request has no visible effects if the fence was already
+in the triggered state. A <function>Fence</function> error is generated if
+fence does not name a valid fence.
+ </para>
+ <para>
+Note that the given fence's state is not necessarily directly modified by this
+request. The state change need only be queued to occur after the required
+rendering has completed. Clients should take care to not assume the fence will
+be in the triggered state in subsequent requests, such as those that operate
+on the given fence immediately. <function>AwaitFence</function> should first
+be issued if subsequent requests require the fence to be in the triggered
+state.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ResetFence</term>
+ <listitem>
+<literallayout class="monospaced">
+fence: FENCE
+Errors: <function>Fence</function>,<function>Match</function>
+</literallayout>
+ <para>
+This request immediately puts the given fence in the not triggered state.
+A <function>Match</function> error is generated if the fence is not in the
+triggered state. A <function>Fence</function> error is generated if fence
+does not name a valid fence.
+ </para>
+ <para>
+See the warnings above regarding <function>TriggerFence</function>'s delayed
+effect. In particular, a <function>TriggerFence</function> request
+immediately followed by a <function>ResetFence</function> request is likely
+to result in a <function>Match</function> error. An
+<function>AwaitFence</function> request should be issued between the two.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>DestroyFence</term>
+ <listitem>
+<literallayout class="monospaced">
+fence: FENCE
+Errors: <function>Fence</function>
+</literallayout>
+ <para>
+This request destroys the given fence. All clients waiting on this fence are
+released. A fence is destroyed automatically when the connection to the client
+that created the fence is closed if the close-down mode is
+<function>DestroyAll</function>. A <function>Fence</function> error is
+generated if fence does not name a valid fence.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>QueryFence</term>
+ <listitem>
+<literallayout class="monospaced">
+fence: FENCE
+=>
+triggered: BOOL
+Errors: <function>Fence</function>
+</literallayout>
+ <para>
+This request returns TRUE if the given fence is triggered, or FALSE if it
+is not triggered. A <function>Fence</function> error is generated if
+fence does not name a valid fence.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>AwaitFence</term>
+ <listitem>
+<literallayout class="monospaced">
+fence-list: LISTofFENCE
+Errors: <function>Fence</function>,<function>Alloc</function>
+</literallayout>
+ <para>
+When this request is executed, the processing of further requests for the
+client is blocked until one or more of the fences in fence-list reaches the
+triggered state. If any of the fences are already in the triggered state,
+request processing resumes immediately. A <function>Fence</function> error
+is generated if any member of fence-list does not name a valid fence.
+ </para>
+ </listitem>
+ </varlistentry>
</variablelist>
</sect1>
@@ -844,6 +1000,7 @@ TRIGGER:
WAITCONDITION:
20 TRIGGER trigger
8 INT64 event threshold
+FENCE: CARD32
</literallayout>
<para>
@@ -872,6 +1029,14 @@ groups, the byte ordering determined during connection setup is used.
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
+<function>Fence</function>
+ 1 0 Error
+ 1 Base + 2 code
+ 2 CARD16 sequence number
+ 4 CARD32 bad fence
+ 2 CARD16 minor opcode
+ 1 CARD8 major opcode
+ 21 unused
</literallayout>
</sect1>
@@ -1026,6 +1191,52 @@ GetPriority
4 INT32 priority
20 unused
+CreateFence
+ 1 CARD8 major opcode
+ 1 14 minor opcode
+ 2 4 request length
+ 4 DRAWABLE drawable
+ 4 FENCE id
+ 1 BOOL initially triggered
+ 3 unused
+
+TriggerFence
+ 1 CARD8 major opcode
+ 1 15 minor opcode
+ 2 2 request length
+ 4 FENCE id
+
+ResetFence
+ 1 CARD8 major opcode
+ 1 16 minor opcode
+ 2 2 request length
+ 4 FENCE id
+
+DestroyFence
+ 1 CARD8 major opcode
+ 1 17 minor opcode
+ 2 2 request length
+ 4 FENCE id
+
+QueryFence
+ 1 CARD8 major opcode
+ 1 18 minor opcode
+ 2 2 request length
+ 4 FENCE id
+=>
+ 1 1 Reply
+ 1 unused
+ 2 CARD16 sequence number
+ 4 0 reply length
+ 1 BOOL triggered
+ 23 unused
+
+AwaitFence
+ 1 CARD8 major opcode
+ 1 19 minor opcode
+ 2 1 + n request length
+ 4*n LISTofFENCE wait conditions
+
</literallayout>
</sect1>
commit fd8a26edefc53b370c554a60c75ff32fc60b99c8
Author: Gaetan Nadon <memsize@videotron.ca>
Date: Tue Nov 30 09:05:07 2010 -0500
specs: add low bandwith spec from xorg-docs
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/specs/Makefile.am b/specs/Makefile.am
index a5d34fd..3792353 100644
--- a/specs/Makefile.am
+++ b/specs/Makefile.am
@@ -28,6 +28,7 @@ doc_sources = \
dpms.xml \
evi.xml \
geproto.xml \
+ lbx.xml \
multibuf.xml \
security.xml \
shape.xml \
diff --git a/specs/lbx.xml b/specs/lbx.xml
new file mode 100644
index 0000000..f42f9f9
--- /dev/null
+++ b/specs/lbx.xml
@@ -0,0 +1,6291 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE article
+ PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
+ "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd";>
+
+<article id="lbx">
+
+<articleinfo>
+ <title>Low Bandwidth X Extension</title>
+ <subtitle>X Consortium Standard</subtitle>
+ <authorgroup>
+ <author>
+ <firstname>D.</firstname>
+ <surname>Converse</surname>
+ </author>
+ <author>
+ <firstname>J.</firstname>
+ <surname>Fulton</surname>
+ </author>
+ <author>
+ <firstname>D.</firstname>
+ <surname>Lemke</surname>
+ </author>
+ <author>
+ <firstname>R.</firstname>
+ <surname>Mor</surname>
+ </author>
+ <author>
+ <firstname>K.</firstname>
+ <surname>Packard</surname>
+ </author>
+ <author>
+ <firstname>R.</firstname>
+ <surname>Tice</surname>
+ </author>
+ <author>
+ <firstname>D.</firstname>
+ <surname>Tonogai</surname>
+ </author>
+ </authorgroup>
+ <releaseinfo>Protocol Version 1.0</releaseinfo>
+
+
+<legalnotice>
+<para>
+Copyright (c) 1996 X Consortium
+</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
+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>
+
+</articleinfo>
+
+<sect1 id='introduction'>
+<title>Introduction</title>
+
+<para>
+Low Bandwidth X (LBX) is a network-transparent protocol for running X Window
+System applications over transport channels whose bandwidth and latency are
+significantly worse than that used in local area networks. It combines a
+variety of caching and reencoding techniques to reduce the volume of data that
+must be sent over the wire. It can be used with existing clients by placing a
+proxy between the clients and server, so that the low bandwidth/high latency
+communication occurs between the proxy and server.
+</para>
+
+
+<para>
+This extension was designed and implemented by Jim Fulton, David Lemke, Keith
+Packard, and Dale Tonogai, all of Network Computing Devices (NCD). Chris Kent
+Kantarjiev (Xerox PARC) participated in early design discussions. Ralph Mor (X
+Consortium) designed and implemented additional sections. Donna Converse (X
+Consortium) authored the protocol description and encoding from design notes
+and the implementation. Ray Tice (X Consortium) resolved the open issues in the
+design and specification. Bob Scheifler (X Consortium) helped out in many areas.
+</para>
+
+
+<para>
+The extension name is "LBX".
+</para>
+
+
+</sect1>
+<sect1 id='description'>
+<title>Description</title>
+
+<para>
+The design center for LBX is to use a proxy as an intermediary between the
+client and server. The proxy reencodes and compresses requests, events, replies
+and errors, as well as the resulting data stream. Additionally, the proxy can
+cache information from the server to provide low-latency replies to clients.
+This reply generation by the proxy is known as short-circuiting. A proxy can
+handle multiple clients for a given server, but does not prevent clients from
+connecting directly to the server. The design allows the proxy to multiplex
+multiple clients into a single data stream to the server.
+</para>
+
+
+<para>
+Much of LBX is implemented as an extension. The compression and reencoding
+changes can be isolated to the transport and dispatch portions of the server,
+while short-circuiting requires minor changes to the server’s colormap and
+property code.
+</para>
+
+
+<para>
+LBX employs several different compression and short-circuiting methods. Use of
+these methods is negotiable, and in some cases, the algorithm used by a given
+method is negotiable as well. LBX also provides for negotiation of extensions
+to LBX.
+</para>
+
+
+<sect2 id='data_flow'>
+<title>Data Flow</title>
+
+<para>
+The LBX data stream goes through a number of layers:
+</para>
+
+
+<orderedlist>
+ <listitem>
+<para>Client requests</para>
+ </listitem>
+ <listitem>
+<para>Read by LBX and potential byte-swapping</para>
+ </listitem>
+ <listitem>
+<para>Request-specific compression</para>
+ </listitem>
+ <listitem>
+<para>Potential byte swapping</para>
+ </listitem>
+ <listitem>
+<para>Multiplexing of client request streams</para>
+ </listitem>
+ <listitem>
+<para>Delta replacement</para>
+ </listitem>
+ <listitem>
+<para>Stream compression</para>
+ </listitem>
+</orderedlist>
+
+<para>
+Transport
+</para>
+
+<!-- FIXME: descending -->
+<orderedlist>
+ <listitem>
+<para>Stream decompression</para>
+ </listitem>
+ <listitem>
+<para>Delta substitution</para>
+ </listitem>
+ <listitem>
+<para>Demultiplexing of client request streams</para>
+ </listitem>
+ <listitem>
+<para>Potential byte swapping</para>
+ </listitem>
+ <listitem>
+<para>Reencoding</para>
+ </listitem>
+ <listitem>
+<para>Request processing</para>
+ </listitem>
+</orderedlist>
+
+<para>
+The reverse process occurs with X server replies, events, and errors.
+</para>
+
+
+</sect2>
+<sect2 id='tags'>
+<title>Tags</title>
+
+<para>
+Tags are used to support caching of large data items that are expected to be
+queried multiple times. Such things as the keyboard map and font metrics are
+often requested by multiple clients. Rather than send the data each time, the
+first time the data is sent it includes a tag. The proxy saves this data, so
+that subsequent requests can send only the tag to refer to that same data. The
+different types of tags are used for connection information, keyboard maps,
+modifier maps, fonts information and properties.
+</para>
+
+
+<para>
+Tag usage is negotiated as a boolean in the <emphasis>
+LbxStartProxy</emphasis>
+ message. The proxy controls how many tags are stored in the proxy. The server
+may wish to observe the proxy’s InvalidateTag behavior to limit how many tags
+are cached at any one time. Tagged data is not shared across types of tags, but
+the number space used for the tag ids is. The tag ids are generated by the
+server.
+</para>
+
+
+<para>
+The X server keeps track of what tags are known to the proxy. The proxy can
+invalidate a tag if no tag bearing replies of that type are pending. The proxy
+sends an <emphasis>
+LbxInvalidateTag</emphasis>
+ message to release the tagged data. The proxy must not invalidate connection
+tags unless instructed to do so by the server.
+</para>
+
+
+<para>
+If the server wishes to discard tagged data, it must either have received an
+<emphasis>
+LbxInvalidateTag</emphasis>
+ request from the proxy or send an <emphasis>
+LbxInvalidateTag</emphasis>
+ event to the proxy for that tag.
+</para>
+
+
+<sect3 id='tag_substitution_in_requests'>
+<title>Tag Substitution in Requests</title>
+
+<para>
+Many substitution requests have a tag field, followed by fields marked
+optional. For these requests, if the optional fields are present, the
+data in them is stored in the indicated tag, unless the tag is 0. If
+the optional fields are absent, the tag field indicates the tag that
+contains the data for the "optional" fields.
+</para>
+
+
+</sect3>
+<sect3 id='property_tags'>
+<title>Property Tags</title>
+
+<para>
+Property data makes special use of tags. A common use of properties is for
+inter-client communication. If both clients use the proxy, it is wasteful to
+send the data to the server and then back, when the server may never need it.
+<emphasis>
+LbxChangeProperty</emphasis>
+ request does the same work as the core <emphasis>
+ChangeProperty</emphasis>
+ request, but it does not send the data. The reply to this request contains a
+tag id corresponding to the data. If the property information is used locally,
+the server responds to <emphasis>
+LbxGetProperty</emphasis>
+ with the tag, and the property data need never be sent to the server. If the
+server does require the data, it can issue an <emphasis>
+LbxQueryTag</emphasis>
+ message. The proxy can also send the data on at any time if it judges it
+appropriate (i.e., when the wire goes idle). Since the proxy owns the property
+data, it must not invalidate the tag before sending the data back to the server
+via an <emphasis>
+LbxTagData</emphasis>
+ request.
+</para>
+
+
+</sect3>
+</sect2>
+<sect2 id='short_circuiting'>
+<title>Short-circuiting</title>
+
+<para>
+Short-circuiting is used to handle constant data. This includes atoms, color
+name/RGB mappings, and <emphasis>
+AllocColor</emphasis>
+ calls. Atoms and color name/RGB mappings stay constant for the life of the
+server. <emphasis>
+AllocColor</emphasis>
+<emphasis>
+ </emphasis>
+replies are constant for each colormap. Short-circuiting replaces round-trip
+requests with one-way requests, and can sometimes use one in place of many.
+</para>
+
+
+<para>
+Atoms are used heavily for ICCCM communication. Once the proxy knows the string
+to atom mapping, it has no need to send subsequent requests for this atom to
+the server.
+</para>
+
+
+<para>
+Colorname/RGB mappings are constant, so once the proxy sees the response from
+<emphasis>
+LookupColor</emphasis>
+, it need not forward any subsequent requests.
+</para>
+
+
+<para>
+Clients often use the same color cells, so once a read-only color allocation
+has occurred, the proxy knows what RGB values should be returned to the client.
+The proxy doesn't need to forward any <emphasis>
+AllocColor</emphasis>
+ requests it can resolve, but it must tell the server to modify the color
+cell's reference count. <emphasis>
Reply to: