x11proto-record: Changes to 'upstream-unstable'
.gitignore | 78 ++
Makefile.am | 13
README | 30
configure.ac | 19
specs/.gitignore | 5
specs/Makefile.am | 64 +
specs/record.xml | 1895 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
7 files changed, 2086 insertions(+), 18 deletions(-)
New commits:
commit 396cdde0242256976fbacec64839e48dfc56d639
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
Date: Fri Oct 29 23:20:43 2010 -0700
RecordProto 1.14.1
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
diff --git a/configure.ac b/configure.ac
index 509a54e..34dd4ce 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,6 @@
AC_PREREQ([2.60])
-AC_INIT([RecordProto], [1.14], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
+AC_INIT([RecordProto], [1.14.1],
+ [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit 62124c428346c5e92d785f4ebc54218368ef800a
Author: Matt Dew <matt@osource.org>
Date: Tue Aug 3 17:44:01 2010 -0400
specs: convert protocol record.ms from xorg-docs to DocBook XML
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
diff --git a/Makefile.am b/Makefile.am
index f9cc316..dce76cf 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1,3 +1,5 @@
+SUBDIRS=specs
+
recorddir = $(includedir)/X11/extensions
record_HEADERS = \
recordconst.h \
diff --git a/configure.ac b/configure.ac
index 7993f59..509a54e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,11 +3,16 @@ AC_INIT([RecordProto], [1.14], [https://bugs.freedesktop.org/enter_bug.cgi?produ
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
-# Require xorg-macros: XORG_DEFAULT_OPTIONS
+# Require xorg-macros minimum of 1.10 for HAVE_STYLESHEETS in XORG_CHECK_SGML_DOCTOOLS
m4_ifndef([XORG_MACROS_VERSION],
- [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])])
-XORG_MACROS_VERSION(1.3)
+ [m4_fatal([must install xorg-macros 1.10 or later before running autoconf/autogen])])
+XORG_MACROS_VERSION(1.10)
XORG_DEFAULT_OPTIONS
+XORG_ENABLE_SPECS
+XORG_WITH_XMLTO(0.0.20)
+XORG_WITH_FOP
+XORG_CHECK_SGML_DOCTOOLS(1.5)
AC_OUTPUT([Makefile
+ specs/Makefile
recordproto.pc])
diff --git a/specs/.gitignore b/specs/.gitignore
new file mode 100644
index 0000000..09b6a89
--- /dev/null
+++ b/specs/.gitignore
@@ -0,0 +1,5 @@
+*.html
+*.ps
+*.pdf
+*.txt
+*.css
diff --git a/specs/Makefile.am b/specs/Makefile.am
new file mode 100644
index 0000000..6359c98
--- /dev/null
+++ b/specs/Makefile.am
@@ -0,0 +1,64 @@
+#
+# Copyright (c) 2010, Oracle and/or its affiliates. All rights reserved.
+#
+# Permission is hereby granted, free of charge, to any person obtaining a
+# copy of this software and associated documentation files (the "Software"),
+# to deal in the Software without restriction, including without limitation
+# the rights to use, copy, modify, merge, publish, distribute, sublicense,
+# and/or sell copies of the Software, and to permit persons to whom the
+# Software is furnished to do so, subject to the following conditions:
+#
+# The above copyright notice and this permission notice (including the next
+# paragraph) shall be included in all copies or substantial portions of the
+# Software.
+#
+# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+# DEALINGS IN THE SOFTWARE.
+#
+
+if ENABLE_SPECS
+doc_sources = record.xml
+dist_doc_DATA = $(doc_sources)
+
+if HAVE_XMLTO
+doc_DATA = $(doc_sources:.xml=.html)
+
+if HAVE_FOP
+doc_DATA += $(doc_sources:.xml=.ps) $(doc_sources:.xml=.pdf)
+endif
+
+if HAVE_XMLTO_TEXT
+doc_DATA += $(doc_sources:.xml=.txt)
+endif
+
+if HAVE_STYLESHEETS
+XMLTO_FLAGS = -m $(XSL_STYLESHEET)
+
+doc_DATA += xorg.css
+xorg.css: $(STYLESHEET_SRCDIR)/xorg.css
+ $(AM_V_GEN)cp -pf $(STYLESHEET_SRCDIR)/xorg.css $@
+endif
+
+CLEANFILES = $(doc_DATA)
+
+SUFFIXES = .xml .ps .pdf .txt .html
+
+.xml.txt:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) txt $<
+
+.xml.html:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) xhtml-nochunks $<
+
+.xml.pdf:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop pdf $<
+
+.xml.ps:
+ $(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop ps $<
+
+endif HAVE_XMLTO
+endif ENABLE_SPECS
diff --git a/specs/record.xml b/specs/record.xml
new file mode 100644
index 0000000..f5d48ac
--- /dev/null
+++ b/specs/record.xml
@@ -0,0 +1,1895 @@
+<?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="record">
+
+<bookinfo>
+ <title>Record Extension Protocol Specification</title>
+ <subtitle>X Consortium Standard</subtitle>
+ <authorgroup>
+ <author>
+ <firstname>Martha</firstname><surname>Zimet</surname>
+ <affiliation><orgname>Network Computing Devices, Inc.</orgname></affiliation>
+ </author>
+ <othercredit>
+ <contrib>edited by</contrib>
+ <firstname>Stephen</firstname><surname>Gildea</surname>
+ <affiliation><orgname>X Consortium</orgname></affiliation>
+ </othercredit>
+ </authorgroup>
+ <corpname>X Consortium Standard</corpname>
+ <copyright><year>1994</year><holder>Network Computing Devices, Inc.</holder></copyright>
+ <copyright><year>1994</year><holder>X Consortium</holder></copyright>
+ <copyright><year>1995</year><holder>X Consortium</holder></copyright>
+ <affiliation><orgname>X Consortium</orgname></affiliation>
+ <productnumber>Version 1.13</productnumber>
+ <releaseinfo>X Version 11, Release 6.7</releaseinfo>
+
+<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. Network Computing Devices, Inc.
+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>
+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 and
+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>
+<title>TITLE</title>
+<sect1 id="Introduction">
+<title>Introduction</title>
+<para>
+Several proposals have been written over the past few years that address some
+of the issues surrounding the recording and playback of user actions
+in the X Window System<footnote><para>
+<emphasis remap='I'>X Window System</emphasis> is a trademark of The Open Group.
+</para></footnote>
+:
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+<emphasis remap='I'>Some Proposals for a Minimal X11 Testing Extension</emphasis>,
+Kieron Drake, UniSoft Ltd., April 1991
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<emphasis remap='I'>X11 Input Synthesis Extension Proposal</emphasis>, Larry Woestman,
+Hewlett Packard, November 1991
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<emphasis remap='I'>XTrap Architecture</emphasis>, Dick Annicchiario, et al, Digital Equipment Corporation,
+July 1991
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<emphasis remap='I'>XTest Extension Recording Specification</emphasis>, Yochanan Slonim,
+Mercury Interactive, December 1992
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+This document both unifies and extends the previous diverse approaches
+to generate a proposal for an X extension that provides support for
+the recording of all core X protocol and arbitrary extension protocol.
+Input synthesis, or playback, has already been implemented in the
+XTest extension, an X Consortium standard. Therefore, this extension
+is limited to recording.
+</para>
+
+<para>
+In order to provide both record and playback functionality, a
+hypothetical record application could use this extension to capture
+both user actions and their consequences. For example, a button press
+(a user action) may cause a window to be mapped and a corresponding
+<function>MapNotify</function>
+event to be sent (a consequence). This information could be
+stored for later use by a playback application.
+</para>
+
+<para>
+The playback application could use the recorded actions as input for
+the XTest extension's
+<function>XTestFakeInput</function>
+operation to synthesize the
+appropriate input events. The "consequence" or synchronization
+information is then used as a synchronization point during playback.
+That is, the playback application does not generate specific
+synthesized events until their matching synchronization condition
+occurs. When the condition occurs the processing of synthesized
+events continues. Determination that the condition has occurred may be
+made by capturing the consequences of the synthesized events and
+comparing them to the previously recorded synchronization information.
+For example, if a button press was followed by a
+<function>MapNotify</function>
+event on a
+particular window in the recorded data, the playback application might
+synthesize the button press then wait for the
+<function>MapNotify</function>
+event on the
+appropriate window before proceeding with subsequent synthesized
+input.
+</para>
+
+<para>
+Because
+it is impossible to predict what synchronization information will be
+required by a particular application, the extension provides
+facilities to record any subset of core X protocol and arbitrary
+extension protocol.
+As such, this extension does not enforce a specific
+synchronization methodology; any method based on information in the X
+protocol stream (e.g., watching for window mapping/unmapping, cursor
+changes, drawing of certain text strings, etc.) can capture the
+information it needs using RECORD facilities.
+</para>
+
+<sect2 id="Acknowledgements">
+<title>Acknowledgements</title>
+<para>
+The document represents the culmination of two years of debate and
+experiments done under the auspices of the X Consortium xtest working
+group. Although this was a group effort, the author remains
+responsible for any errors or omissions.
+Two years ago, Robert Chesler of Absol-puter, Kieron Drake of UniSoft
+Ltd., Marc Evans of Synergytics and Ken Miller of Digitial shared the
+vision of a standard extension for recording and were all instrumental
+in the early protocol development. During the last two years, Bob
+Scheifler of the X Consortium and Jim Fulton of NCD continuously
+provided input to the protocol design, as well as encouragement to the
+author. In the last few months, Stephen Gildea and Dave Wiggins,
+both X Consortium staff, have spent considerable time fine tuning the
+protocol design and reviewing the protocol specifications. Most
+recently, Amnon Cohen of Mercury Interactive has assisted in
+clarification of the recorded event policy, and Kent Siefkes of
+Performance Awareness has assisted in clarification of the timestamp
+policy.
+</para>
+</sect2>
+
+<sect2 id="Goals">
+<title>Goals</title>
+<itemizedlist>
+ <listitem>
+ <para>
+To provide a standard for recording,
+whereby both device events and synchronization information in the
+form of device event consequences are recorded.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+To record contextual information used in synchronized playback
+without prior knowledge of the application
+that
+is being recorded.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+To provide the ability to record arbitrary X protocol extensions.
+<!-- .RE -->
+ </para>
+ </listitem>
+</itemizedlist>
+</sect2>
+
+<sect2 id="Requirements">
+<title>Requirements</title>
+<para>
+The extension should function as follows:
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+It should
+not be dependent on other clients or extensions for its operation.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+It should
+not significantly impact performance.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+It should
+support the recording of all device input (core devices and XInput devices).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+It should
+be extendible.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+It should
+support the recording of synchronization information for user events.
+ </para>
+ </listitem>
+</itemizedlist>
+</sect2>
+</sect1>
+
+<sect1 id="Design">
+<title>Design</title>
+<para>
+This section gives an overview of the RECORD extension and discusses
+its overall operation and data types.
+</para>
+
+<sect2 id="Overview">
+<title>Overview</title>
+<para>
+The mechanism used by this extension for recording is to intercept
+core X protocol and arbitrary X extension protocol entirely within the X server
+itself. When the extension has been requested to intercept specific
+protocol by one or more clients, the protocol data are formatted and
+returned to the recording clients.
+</para>
+<para>
+<!-- .LP -->
+The extension provides a mechanism for capturing all events, including
+input device events that go to no clients, that is analogous to a client
+expressing "interest" in all events in all windows, including the root
+window. Event filtering in the extension provides a mechanism for feeding
+device events to recording clients; it does not provide a mechanism for
+in-place, synchronous event substitution, modification, or withholding.
+In addition, the
+extension does not provide data compression before intercepted protocol
+is returned to the recording clients.
+</para>
+<sect3 id="Data_Delivery">
+<title>Data Delivery</title>
+<!-- .XS -->
+<!-- (SN Data Delivery -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+Because
+events are limited in size to
+32 bytes, using events to return intercepted protocol data to recording
+clients is prohibitive in terms of performance. Therefore, intercepted
+protocol data are returned to recording clients through multiple replies
+to the extension request to begin protocol interception and reporting.
+This utilization is consistent with
+<function>ListFontsWithInfo ,</function>
+for example, where a
+single request has multiple replies.
+</para>
+<para>
+<!-- .LP -->
+Individual requests, replies, events or errors intercepted by the extension
+on behalf of recording clients cannot be split across reply packets. In order
+to reduce overhead, multiple intercepted requests, replies, events and errors
+might be collected
+into a single reply.
+Nevertheless, all data are returned to the client in a timely manner.
+</para>
+</sect3>
+<sect3 id="Record_Context">
+<title>Record Context</title>
+<!-- .XS -->
+<!-- (SN Record Context -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The extension adds a record context resource (RC)
+to the set of resources managed by the server. All the
+extension operations take an RC as an argument. Although the protocol
+permits sharing of RCs between clients, it is expected that clients will
+use their own RCs. The attributes used in extension operations are stored
+in the RCs, and these attributes include the protocol and clients to
+intercept.
+</para>
+<para>
+<!-- .LP -->
+The terms "register" and "unregister" are used to describe the
+relationship between clients to intercept and the RC. To register
+a client with an RC means the client is added to the list
+of clients to intercept; to unregister a client means the client
+is deleted from the list of clients to intercept. When the
+server is requested to register or unregister clients from an RC,
+it is required to do so immediately. That is, it is not permissible for
+the server to wait until recording is enabled to register clients
+or recording is disabled to unregister clients.
+</para>
+</sect3>
+
+<sect3 id="Record_Client_Connections">
+<title>Record Client Connections</title>
+<!-- .XS -->
+<!-- (SN Record Client Connections -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The typical communication model for a recording client is to open
+two connections to the server and use one for RC control and
+the other for reading protocol data.
+</para>
+<para>
+<!-- .LP -->
+The "control" connection can execute requests to obtain information about
+the supported protocol version, create and destroy RCs, specify protocol
+types to intercept and clients to be recorded, query the current state
+of an RC, and to stop interception and reporting of protocol data. The
+"data" connection can execute a request to
+enable interception
+and reporting of specified protocol for a particular RC. When the
+"enable" request is issued, intercepted protocol is sent back on the
+same connection, generally in more than one reply packet. Until the last
+reply to the "enable" request is sent by the server, signifying that
+the request execution is complete, no other requests will be executed by
+the server on that connection. That is, the connection that data are being
+reported on cannot issue the "disable" request until the last reply
+to the "enable" request is sent by the server. Therefore, unless a
+recording client never has the need to disable the interception and reporting
+of protocol data, two client connections are necessary.
+</para>
+</sect3>
+<sect3 id="Events">
+<title>Events</title>
+<!-- .XS -->
+<!-- (SN Events -->
+<!-- .XE -->
+<para>
+<!-- .LP -->
+The terms "delivered events" and "device events" are used
+to describe the two event classes recording clients may
+select for interception. These event classes are handled differently
+by the extension. Delivered events are core X events or X extension events
+the server actually delivers to one or more clients. Device events are
+events generated by core X devices or extension input devices that the
+server may or may not deliver to any clients. When device events
+are selected for interception by a recording client, the extension
+guarantees each device event is recorded and will be forwarded
+to the recording client in the same order it is generated by the
+device.
+</para>
+<para>
+<!-- .LP -->
+The recording of selected device events is not affected
+by server grabs. Delivered events, on the other hand, can be affected
+by server grabs.
+If a recording client selects both
+a device event and delivered events that result from that device
+event, the delivered events are recorded after the device event.
+In the absence of grabs, the delivered events for a
+device event precede later device events.
+</para>
+<para>
+<!-- .LP -->
+Requests that have side effects on
+devices, such as
+<function>WarpPointer</function>
+and
+<function>GrabPointer</function>
+with a confine-to window,
+will cause RECORD to record an associated device event.
+The XTEST extension request
+<function>XTestFakeInput</function>
+causes a device event to be recorded; the
+device events are recorded in the same order that the
+<function>XTestFakeInput</function>
+requests are received by the server.
+</para>
+<para>
+<!-- .LP -->
+If a key autorepeats, multiple
+<function>KeyPress</function>
+and
+<function>KeyRelease</function>
+device events are reported.
+</para>
+</sect3>
+
+<sect3 id="Timing">
+<title>Timing</title>
+<!-- .XS -->
+<!-- (SN Timing -->
+<!-- .XE -->
+<para>
+Requests are recorded just before
+they are executed; the time associated with a request is the server
+time when it is recorded.
+</para>
+</sect3>
+</sect2>
+
+<sect2 id="Types">
+<title>Types</title>
+<para>
+The following new types are used in the request definitions that appear
+in section 3. <!-- xref -->
+</para>
+
+<para>RC: CARD32</para>
+
+<para>
+The
+<function>"RC"</function>
+type is a resource identifier for a server record context.
+</para>
+
+<informaltable frame="none">
+ <tgroup cols='3' align='left'>
+ <colspec colname='c1' colsep="0" colwidth="1*"/>
+ <colspec colname='c2' colsep="0" colwidth="1*"/>
+ <colspec colname='c3' colsep="0" colwidth="1*"/>
+ <tbody>
+ <row rowsep="0">
+ <entry>RANGE8:</entry>
+ <entry>[first, last:</entry>
+ <entry>CARD8]</entry>
+ </row>
+ <row rowsep="0">
+ <entry>RANGE16:</entry>
+ <entry>[first, last:</entry>
+ <entry>CARD16]</entry>
+ </row>
+ <row rowsep="0">
+ <entry>EXTRANGE:</entry>
+ <entry>[major:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>minor:</entry>
+ <entry>RANGE16]</entry>
+ </row>
+ </tbody>
+ </tgroup>
+</informaltable>
+
+<informaltable frame="none">
+ <tgroup cols='3' align='left'>
+ <colspec colname='c1' colsep="0" colwidth="1*"/>
+ <colspec colname='c2' colsep="0" colwidth="1*"/>
+ <colspec colname='c3' colsep="0" colwidth="1*"/>
+ <tbody>
+ <row rowsep="0">
+ <entry>RECORDRANGE:</entry>
+ <entry>[core-requests:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>core-replies:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>ext-requests:</entry>
+ <entry>EXTRANGE</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>ext-replies:</entry>
+ <entry>EXTRANGE</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>delivered-events:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>device-events:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>errors:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>client-started:</entry>
+ <entry>BOOL</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>client-died:</entry>
+ <entry>BOOL]</entry>
+ </row>
+ </tbody>
+ </tgroup>
+</informaltable>
+
+<para>
+The
+<function>"RECORDRANGE"</function>
+structure contains the protocol values to intercept. Typically,
+this structure is sent by recording clients over the control connection
+when creating or modifying an RC.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+<!-- .IN "core-requests" -->
+<!-- .br -->
+Specifies core X protocol requests with an opcode field between <emphasis remap='I'>first</emphasis>
+and <emphasis remap='I'>last</emphasis> inclusive. If <emphasis remap='I'>first</emphasis> is equal to 0 and <emphasis remap='I'>last</emphasis> is equal to 0, no
+core requests are specified by this RECORDRANGE. If <emphasis remap='I'>first</emphasis> is greater
+than <emphasis remap='I'>last</emphasis>, a
+<function>"Value"</function>
+error results.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IN "core-replies" -->
+<!-- .br -->
+Specifies replies resulting from core X protocol requests with an opcode
+field between <emphasis remap='I'>first</emphasis> and <emphasis remap='I'>last</emphasis> inclusive. If <emphasis remap='I'>first</emphasis> is equal to 0 and <emphasis remap='I'>last</emphasis>
+is equal to 0, no core replies are specified by this RECORDRANGE. If
+<emphasis remap='I'>first</emphasis> is greater than <emphasis remap='I'>last</emphasis>, a
+<function>"Value"</function>
+error results.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IN "ext-requests" -->
+<!-- .br -->
+Specifies extension protocol requests with a major opcode field between
+<emphasis remap='I'>major.first</emphasis> and <emphasis remap='I'>major.last</emphasis> and a minor opcode field between <emphasis remap='I'>minor.first</emphasis>
+and <emphasis remap='I'>minor.last</emphasis> inclusive.
+If <emphasis remap='I'>major.first</emphasis> and <emphasis remap='I'>major.last</emphasis> are equal to 0, no
+extension protocol requests are specified by this RECORDRANGE. If
+<emphasis remap='I'>major.first</emphasis> or <emphasis remap='I'>major.last</emphasis> is less than 128 and greater than 0,
+if <emphasis remap='I'>major.first</emphasis> is greater than <emphasis remap='I'>major.last</emphasis>,
+or if <emphasis remap='I'>minor.first</emphasis>
+is greater than <emphasis remap='I'>minor.last</emphasis>, a
+<function>"Value"</function>
+error results.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IN "ext-replies" -->
+<!-- .br -->
+Specifies replies resulting from extension protocol requests with a
+major opcode field between <emphasis remap='I'>major.first</emphasis> and <emphasis remap='I'>major.last</emphasis> and
+a minor opcode field between <emphasis remap='I'>minor.first</emphasis> and <emphasis remap='I'>minor.last</emphasis>
+inclusive. If <emphasis remap='I'>major.first</emphasis> and <emphasis remap='I'>major.last</emphasis> are equal to 0,
+no extension protocol replies are specified by this RECORDRANGE. If
+<emphasis remap='I'>major.first</emphasis> or <emphasis remap='I'>major.last</emphasis> is less than 128 and greater
+than 0,
+if <emphasis remap='I'>major.first</emphasis> is greater than <emphasis remap='I'>major.last</emphasis>,
+or if <emphasis remap='I'>minor.first</emphasis> is greater than <emphasis remap='I'>minor.last</emphasis>, a
+<function>"Value"</function>
+error results.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IN "delivered-events" -->
+<!-- .br -->
+This is used for both core X protocol events and arbitrary extension
+events. Specifies events that are delivered to at least one client
+that have a code field between <emphasis remap='I'>first</emphasis> and <emphasis remap='I'>last</emphasis>
+inclusive. If <emphasis remap='I'>first</emphasis> is equal to 0 and <emphasis remap='I'>last</emphasis> is equal to 0,
+no events are specified by this RECORDRANGE.
+Otherwise, if <emphasis remap='I'>first</emphasis> is less than 2
+or <emphasis remap='I'>last</emphasis> is less than 2, or if
+<emphasis remap='I'>first</emphasis> is greater than <emphasis remap='I'>last</emphasis>, a
+<function>"Value"</function>
+error results.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IN "device-events" -->
+<!-- .br -->
+This is used for both core X device events and X extension device
+events that may or may not be delivered to a client.
+Specifies device events that have a code field between <emphasis remap='I'>first</emphasis> and
+<emphasis remap='I'>last</emphasis> inclusive. If <emphasis remap='I'>first</emphasis> is equal to 0 and <emphasis remap='I'>last</emphasis>
+is equal to 0, no device events are specified by this RECORDRANGE.
+Otherwise,
+if <emphasis remap='I'>first</emphasis> is less than 2 or <emphasis remap='I'>last</emphasis> is less
+than 2, or if <emphasis remap='I'>first</emphasis> is greater than <emphasis remap='I'>last</emphasis>, a
+<function>"Value"</function>
+error results.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Because
+the generated device event may or may not be associated with a
+client, unlike other RECORDRANGE components, which select protocol for a
+specific client, selecting for device events in any RECORDRANGE in an RC
+causes the recording client to receive one instance for each device event
+generated that is in the range specified.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IN "errors" -->
+<!-- .br -->
+This is used for both core X protocol errors and arbitrary extension
+errors. Specifies errors that have a code field between <emphasis remap='I'>first</emphasis> and
+<emphasis remap='I'>last</emphasis> inclusive. If <emphasis remap='I'>first</emphasis> is equal to 0 and <emphasis remap='I'>last</emphasis> is equal to 0, no
+errors are specified by this RECORDRANGE. If <emphasis remap='I'>first</emphasis> is greater
+than <emphasis remap='I'>last</emphasis>, a
+<function>"Value"</function>
+error results.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IN "client-started" -->
+<!-- .br -->
+Specifies the connection setup reply.
+If
+<function>False ,</function>
+the connection setup reply is not specified by
+this RECORDRANGE.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<!-- .IN "client-died" -->
+<!-- .br -->
+Specifies notification when a client disconnects.
+If
+<function>False ,</function>
+notification when a client disconnects is not specified by
+this RECORDRANGE.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<informaltable frame="none">
+ <tgroup cols='3' align='left'>
+ <colspec colname='c1' colsep="0" colwidth="1*"/>
+ <colspec colname='c2' colsep="0" colwidth="1*"/>
+ <colspec colname='c3' colsep="0" colwidth="1*"/>
+ <tbody>
+ <row rowsep="0">
+ <entry>ELEMENT_HEADER:</entry>
+ <entry>[from-server-time:</entry>
+ <entry>BOOL</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>from-client-time:</entry>
+ <entry>BOOL</entry>
+ </row>
+ <row rowsep="0">
+ <entry></entry>
+ <entry>from-client-sequence:</entry>
+ <entry>BOOL]</entry>
+ </row>
+ </tbody>
+ </tgroup>
+</informaltable>
+
+<para>
+The
+<function>ELEMENT_HEADER</function>
+structure specifies additional data that precedes each protocol
+element in the <emphasis remap='I'>data</emphasis> field of a
+<function>RecordEnableContext</function>
+reply.
+</para>
+
+<itemizedlist>
+ <listitem>
+ <para>
+If <emphasis remap='I'>from-server-time</emphasis> is
+<function>True ,</function>
+each intercepted protocol element
+with category
+<function>FromServer</function>
+is preceded by the server time when the protocol was recorded.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+If <emphasis remap='I'>from-client-time</emphasis> is
+<function>True ,</function>
+each intercepted protocol element
+with category
+<function>FromClient</function>
+is preceded by the server time when the protocol was recorded.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+If <emphasis remap='I'>from-client-sequence</emphasis> is
+<function>True ,</function>
+each intercepted protocol
+element with category
+<function>FromClient</function>
+or
+<function>ClientDied</function>
+is preceded by the
+32-bit sequence number of the recorded client's most recent request
+processed by the server at that time.
+For
+<function>FromClient ,</function>
+this will be one less than the sequence number of the
+following request.
+For
+<function>ClientDied ,</function>
+the sequence number will be the only data, because no
+protocol is recorded.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+Note that a reply containing device events is treated the same as
+other replies with category
+<function>FromServer</function>
+for purposes of these flags.
+Protocol with category
+<function>FromServer</function>
+is never preceded by a sequence
+number because almost all such protocol has a sequence number in it anyway.
+</para>
+
+<para>
+<!-- .LP -->
+If both a server time and a sequence number have been requested for a
+reply, each protocol request is
+preceded first by the time and second by the sequence number.
+</para>
+
+<para>XIDBASE: CARD32</para>
+
+<para>
+<!-- .LP -->
+The XIDBASE type is used to identify a particular client. Valid
+values are any existing resource identifier
+of any connected client,
+in which case the client
+that created the resource is specified, or the resource identifier
+base sent to the target client from the server in the connection setup
+reply. A value of 0 (zero) is valid when the XIDBASE is associated
+with device events that may not have been delivered to a client.
+</para>
+
+<para>
+CLIENTSPEC: XIDBASE or {<emphasis>CurrentClients</emphasis>,
+<emphasis>FutureClients</emphasis>, <emphasis>AllClients</emphasis>}
+</para>
+
+<para>
+The CLIENTSPEC type defines the set of clients the RC attributes are
+associated with. This type is used by recording clients when creating
+an RC or when changing RC attributes. XIDBASE specifies that the RC
+attributes apply to a single client only.
+<function>CurrentClients</function>
+specifies
+that the RC attributes apply to current client connections;
+<function>FutureClients</function>
+specifies future client connections;
+<function>AllClients</function>
+specifies all client connections, which includes current and future.
+</para>
+
+<para>
+The numeric values for
+<function>CurrentClients ,</function>
+<function>FutureClients</function>
+and
+<function>AllClients</function>
+are
+defined such that there will be no intersection with valid XIDBASEs.
+</para>
+
+<para>
+<!-- .LP -->
+When the context is enabled, the data connection is unregistered if it
+was registered.
+If the context is enabled,
+<function>CurrentClients</function>
+and
+<function>AllClients</function>
Reply to: