.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 <[email protected]> Date: Fri Oct 29 23:20:43 2010 -0700 RecordProto 1.14.1 Signed-off-by: Alan Coopersmith <[email protected]> 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 <[email protected]> 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 <[email protected]> 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> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
