diff options
Diffstat (limited to 'proto')
| -rw-r--r-- | proto/recordproto/ChangeLog | 105 | ||||
| -rw-r--r-- | proto/recordproto/INSTALL | 291 | ||||
| -rw-r--r-- | proto/recordproto/Makefile.am | 13 | ||||
| -rw-r--r-- | proto/recordproto/README | 30 | ||||
| -rw-r--r-- | proto/recordproto/configure.ac | 19 | ||||
| -rw-r--r-- | proto/recordproto/specs/Makefile.am | 64 | ||||
| -rw-r--r-- | proto/recordproto/specs/record.xml | 1895 |
7 files changed, 2406 insertions, 11 deletions
diff --git a/proto/recordproto/ChangeLog b/proto/recordproto/ChangeLog index 81eec582e..ed8cf1245 100644 --- a/proto/recordproto/ChangeLog +++ b/proto/recordproto/ChangeLog @@ -1,3 +1,108 @@ +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> + +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> + +commit 1d5a3b11ff8810b0b0921337d85955150b67346a +Author: Gaetan Nadon <memsize@videotron.ca> +Date: Sun Mar 28 19:25:52 2010 -0400 + + config: update AC_PREREQ statement to 2.60 + + Unrelated to the previous patches, the new value simply reflects + the reality that the minimum level for autoconf to configure + all x.org modules is 2.60 dated June 2006. + + ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz + + Signed-off-by: Gaetan Nadon <memsize@videotron.ca> + +commit cf80c95d1826c7ec5b701b361d5d39d650c414f3 +Author: Gaetan Nadon <memsize@videotron.ca> +Date: Sun Mar 28 19:00:31 2010 -0400 + + config: remove the pkgconfig pc.in file from EXTRA_DIST + + Automake always includes it in the tarball. + + Signed-off-by: Gaetan Nadon <memsize@videotron.ca> + +commit 67bcebd15489d69705c563cd2b63366c59cb21aa +Author: Gaetan Nadon <memsize@videotron.ca> +Date: Sun Nov 22 19:24:48 2009 -0500 + + Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES + + Now that the INSTALL file is generated. + Allows running make maintainer-clean. + +commit 3030de0d0d3dbabda31c9cdeae025020253adfb6 +Author: Gaetan Nadon <memsize@videotron.ca> +Date: Mon Nov 16 11:13:30 2009 -0500 + + README: file created or updated #24206 + + Contains a set of URLs to freedesktop.org. + +commit 20e71f110a5aabd44ad1e9a2c127a8e76da8d5a4 +Author: Gaetan Nadon <memsize@videotron.ca> +Date: Sun Nov 15 19:45:27 2009 -0500 + + Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 + + ChangeLog filename is known to Automake and requires no further + coding in the makefile. + +commit 5ad105c41bc16d0ab149a8e77906af2b5498168e +Author: Gaetan Nadon <memsize@videotron.ca> +Date: Sun Nov 15 18:31:29 2009 -0500 + + Makefile.am: INSTALL file is missing or incorrect #24206 + + The standard GNU file on building/installing tarball is copied + using the XORG_INSTALL macro contained in XORG_DEFAULT_OPTIONS + Add INSTALL target + +commit 29df99549d157a0d96607cc55e9789d194356f08 +Author: Gaetan Nadon <memsize@videotron.ca> +Date: Sun Nov 15 18:11:36 2009 -0500 + + configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 + + This macro aggregate a number of existing macros that sets commmon + X.Org components configuration options. It shields the configuration file from + future changes. + +commit d9d22eeed75505c28b8e8934bec27960bc1407b7 +Author: Gaetan Nadon <memsize@videotron.ca> +Date: Sun Nov 15 13:55:25 2009 -0500 + + configure.ac: AM_MAINTAINER_MODE missing #24238 + + This turns off maintainer mode build rules in tarballs. + Works in conjunction with autogen.sh --enable-maintainer-mode + +commit aa0ab0118100ab6d6fb5628c6d2fabc1d750defc +Author: Gaetan Nadon <memsize@videotron.ca> +Date: Sat Nov 14 18:26:47 2009 -0500 + + .gitignore: use common defaults with custom section # 24239 + + Using common defaults will reduce errors and maintenance. + Only the very small or inexistent custom section need periodic maintenance + when the structure of the component changes. Do not edit defaults. + commit 38fd3772f3a5a107fa6e9d94e0be7bd276f771b6 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Thu Oct 1 19:38:36 2009 +1000 diff --git a/proto/recordproto/INSTALL b/proto/recordproto/INSTALL new file mode 100644 index 000000000..8b82ade08 --- /dev/null +++ b/proto/recordproto/INSTALL @@ -0,0 +1,291 @@ +Installation Instructions +************************* + +Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005, +2006, 2007, 2008 Free Software Foundation, Inc. + + This file is free documentation; the Free Software Foundation gives +unlimited permission to copy, distribute and modify it. + +Basic Installation +================== + + Briefly, the shell commands `./configure; make; make install' should +configure, build, and install this package. The following +more-detailed instructions are generic; see the `README' file for +instructions specific to this package. + + The `configure' shell script attempts to guess correct values for +various system-dependent variables used during compilation. It uses +those values to create a `Makefile' in each directory of the package. +It may also create one or more `.h' files containing system-dependent +definitions. Finally, it creates a shell script `config.status' that +you can run in the future to recreate the current configuration, and a +file `config.log' containing compiler output (useful mainly for +debugging `configure'). + + It can also use an optional file (typically called `config.cache' +and enabled with `--cache-file=config.cache' or simply `-C') that saves +the results of its tests to speed up reconfiguring. Caching is +disabled by default to prevent problems with accidental use of stale +cache files. + + If you need to do unusual things to compile the package, please try +to figure out how `configure' could check whether to do them, and mail +diffs or instructions to the address given in the `README' so they can +be considered for the next release. If you are using the cache, and at +some point `config.cache' contains results you don't want to keep, you +may remove or edit it. + + The file `configure.ac' (or `configure.in') is used to create +`configure' by a program called `autoconf'. You need `configure.ac' if +you want to change it or regenerate `configure' using a newer version +of `autoconf'. + +The simplest way to compile this package is: + + 1. `cd' to the directory containing the package's source code and type + `./configure' to configure the package for your system. + + Running `configure' might take a while. While running, it prints + some messages telling which features it is checking for. + + 2. Type `make' to compile the package. + + 3. Optionally, type `make check' to run any self-tests that come with + the package. + + 4. Type `make install' to install the programs and any data files and + documentation. + + 5. You can remove the program binaries and object files from the + source code directory by typing `make clean'. To also remove the + files that `configure' created (so you can compile the package for + a different kind of computer), type `make distclean'. There is + also a `make maintainer-clean' target, but that is intended mainly + for the package's developers. If you use it, you may have to get + all sorts of other programs in order to regenerate files that came + with the distribution. + + 6. Often, you can also type `make uninstall' to remove the installed + files again. + +Compilers and Options +===================== + + Some systems require unusual options for compilation or linking that +the `configure' script does not know about. Run `./configure --help' +for details on some of the pertinent environment variables. + + You can give `configure' initial values for configuration parameters +by setting variables in the command line or in the environment. Here +is an example: + + ./configure CC=c99 CFLAGS=-g LIBS=-lposix + + *Note Defining Variables::, for more details. + +Compiling For Multiple Architectures +==================================== + + You can compile the package for more than one kind of computer at the +same time, by placing the object files for each architecture in their +own directory. To do this, you can use GNU `make'. `cd' to the +directory where you want the object files and executables to go and run +the `configure' script. `configure' automatically checks for the +source code in the directory that `configure' is in and in `..'. + + With a non-GNU `make', it is safer to compile the package for one +architecture at a time in the source code directory. After you have +installed the package for one architecture, use `make distclean' before +reconfiguring for another architecture. + + On MacOS X 10.5 and later systems, you can create libraries and +executables that work on multiple system types--known as "fat" or +"universal" binaries--by specifying multiple `-arch' options to the +compiler but only a single `-arch' option to the preprocessor. Like +this: + + ./configure CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \ + CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \ + CPP="gcc -E" CXXCPP="g++ -E" + + This is not guaranteed to produce working output in all cases, you +may have to build one architecture at a time and combine the results +using the `lipo' tool if you have problems. + +Installation Names +================== + + By default, `make install' installs the package's commands under +`/usr/local/bin', include files under `/usr/local/include', etc. You +can specify an installation prefix other than `/usr/local' by giving +`configure' the option `--prefix=PREFIX'. + + You can specify separate installation prefixes for +architecture-specific files and architecture-independent files. If you +pass the option `--exec-prefix=PREFIX' to `configure', the package uses +PREFIX as the prefix for installing programs and libraries. +Documentation and other data files still use the regular prefix. + + In addition, if you use an unusual directory layout you can give +options like `--bindir=DIR' to specify different values for particular +kinds of files. Run `configure --help' for a list of the directories +you can set and what kinds of files go in them. + + If the package supports it, you can cause programs to be installed +with an extra prefix or suffix on their names by giving `configure' the +option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'. + +Optional Features +================= + + Some packages pay attention to `--enable-FEATURE' options to +`configure', where FEATURE indicates an optional part of the package. +They may also pay attention to `--with-PACKAGE' options, where PACKAGE +is something like `gnu-as' or `x' (for the X Window System). The +`README' should mention any `--enable-' and `--with-' options that the +package recognizes. + + For packages that use the X Window System, `configure' can usually +find the X include and library files automatically, but if it doesn't, +you can use the `configure' options `--x-includes=DIR' and +`--x-libraries=DIR' to specify their locations. + +Particular systems +================== + + On HP-UX, the default C compiler is not ANSI C compatible. If GNU +CC is not installed, it is recommended to use the following options in +order to use an ANSI C compiler: + + ./configure CC="cc -Ae" + +and if that doesn't work, install pre-built binaries of GCC for HP-UX. + + On OSF/1 a.k.a. Tru64, some versions of the default C compiler cannot +parse its `<wchar.h>' header file. The option `-nodtk' can be used as +a workaround. If GNU CC is not installed, it is therefore recommended +to try + + ./configure CC="cc" + +and if that doesn't work, try + + ./configure CC="cc -nodtk" + +Specifying the System Type +========================== + + There may be some features `configure' cannot figure out +automatically, but needs to determine by the type of machine the package +will run on. Usually, assuming the package is built to be run on the +_same_ architectures, `configure' can figure that out, but if it prints +a message saying it cannot guess the machine type, give it the +`--build=TYPE' option. TYPE can either be a short name for the system +type, such as `sun4', or a canonical name which has the form: + + CPU-COMPANY-SYSTEM + +where SYSTEM can have one of these forms: + + OS KERNEL-OS + + See the file `config.sub' for the possible values of each field. If +`config.sub' isn't included in this package, then this package doesn't +need to know the machine type. + + If you are _building_ compiler tools for cross-compiling, you should +use the option `--target=TYPE' to select the type of system they will +produce code for. + + If you want to _use_ a cross compiler, that generates code for a +platform different from the build platform, you should specify the +"host" platform (i.e., that on which the generated programs will +eventually be run) with `--host=TYPE'. + +Sharing Defaults +================ + + If you want to set default values for `configure' scripts to share, +you can create a site shell script called `config.site' that gives +default values for variables like `CC', `cache_file', and `prefix'. +`configure' looks for `PREFIX/share/config.site' if it exists, then +`PREFIX/etc/config.site' if it exists. Or, you can set the +`CONFIG_SITE' environment variable to the location of the site script. +A warning: not all `configure' scripts look for a site script. + +Defining Variables +================== + + Variables not defined in a site shell script can be set in the +environment passed to `configure'. However, some packages may run +configure again during the build, and the customized values of these +variables may be lost. In order to avoid this problem, you should set +them in the `configure' command line, using `VAR=value'. For example: + + ./configure CC=/usr/local2/bin/gcc + +causes the specified `gcc' to be used as the C compiler (unless it is +overridden in the site shell script). + +Unfortunately, this technique does not work for `CONFIG_SHELL' due to +an Autoconf bug. Until the bug is fixed you can use this workaround: + + CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash + +`configure' Invocation +====================== + + `configure' recognizes the following options to control how it +operates. + +`--help' +`-h' + Print a summary of all of the options to `configure', and exit. + +`--help=short' +`--help=recursive' + Print a summary of the options unique to this package's + `configure', and exit. The `short' variant lists options used + only in the top level, while the `recursive' variant lists options + also present in any nested packages. + +`--version' +`-V' + Print the version of Autoconf used to generate the `configure' + script, and exit. + +`--cache-file=FILE' + Enable the cache: use and save the results of the tests in FILE, + traditionally `config.cache'. FILE defaults to `/dev/null' to + disable caching. + +`--config-cache' +`-C' + Alias for `--cache-file=config.cache'. + +`--quiet' +`--silent' +`-q' + Do not print messages saying which checks are being made. To + suppress all normal output, redirect it to `/dev/null' (any error + messages will still be shown). + +`--srcdir=DIR' + Look for the package's source code in directory DIR. Usually + `configure' can determine that directory automatically. + +`--prefix=DIR' + Use DIR as the installation prefix. *Note Installation Names:: + for more details, including other options available for fine-tuning + the installation locations. + +`--no-create' +`-n' + Run the configure checks, but stop before creating any output + files. + +`configure' also accepts some other, not widely useful, options. Run +`configure --help' for more details. + diff --git a/proto/recordproto/Makefile.am b/proto/recordproto/Makefile.am index dd0b02884..dce76cf78 100644 --- a/proto/recordproto/Makefile.am +++ b/proto/recordproto/Makefile.am @@ -1,3 +1,5 @@ +SUBDIRS=specs + recorddir = $(includedir)/X11/extensions record_HEADERS = \ recordconst.h \ @@ -7,14 +9,15 @@ record_HEADERS = \ pkgconfigdir = $(libdir)/pkgconfig pkgconfig_DATA = recordproto.pc -EXTRA_DIST = recordproto.pc.in -EXTRA_DIST += ChangeLog -MAINTAINERCLEANFILES = ChangeLog +MAINTAINERCLEANFILES = ChangeLog INSTALL + +.PHONY: ChangeLog INSTALL -.PHONY: ChangeLog +INSTALL: + $(INSTALL_CMD) ChangeLog: $(CHANGELOG_CMD) -dist-hook: ChangeLog +dist-hook: ChangeLog INSTALL diff --git a/proto/recordproto/README b/proto/recordproto/README new file mode 100644 index 000000000..08009850c --- /dev/null +++ b/proto/recordproto/README @@ -0,0 +1,30 @@ + X Record Extension + +This extension defines a protocol for the recording and playback of user +actions in the X Window System. + +Extension name: RECORD + +All questions regarding this software should be directed at the +Xorg mailing list: + + http://lists.freedesktop.org/mailman/listinfo/xorg + +Please submit bug reports to the Xorg bugzilla: + + https://bugs.freedesktop.org/enter_bug.cgi?product=xorg + +The master development code repository can be found at: + + git://anongit.freedesktop.org/git/xorg/proto/recordproto + + http://cgit.freedesktop.org/xorg/proto/recordproto + +For patch submission instructions, see: + + http://www.x.org/wiki/Development/Documentation/SubmittingPatches + +For more information on the git code manager, see: + + http://wiki.x.org/wiki/GitPage + diff --git a/proto/recordproto/configure.ac b/proto/recordproto/configure.ac index 1709ce6fa..34dd4ce4a 100644 --- a/proto/recordproto/configure.ac +++ b/proto/recordproto/configure.ac @@ -1,12 +1,19 @@ -AC_PREREQ([2.57]) -AC_INIT([RecordProto], [1.14], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) +AC_PREREQ([2.60]) +AC_INIT([RecordProto], [1.14.1], + [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg]) AM_INIT_AUTOMAKE([foreign dist-bzip2]) +AM_MAINTAINER_MODE -# Require xorg-macros: XORG_DEFAULT_OPTIONS -m4_ifndef([XORG_MACROS_VERSION], [AC_FATAL([must install xorg-macros 1.3 or later before running autoconf/autogen])]) -XORG_MACROS_VERSION(1.3) - +# 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.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/proto/recordproto/specs/Makefile.am b/proto/recordproto/specs/Makefile.am new file mode 100644 index 000000000..6359c9830 --- /dev/null +++ b/proto/recordproto/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/proto/recordproto/specs/record.xml b/proto/recordproto/specs/record.xml new file mode 100644 index 000000000..f5d48aca1 --- /dev/null +++ b/proto/recordproto/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> +silently exclude the recording data connection. +It is an error to explicitly register the data connection. +</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>CLIENT_INFO:</entry> + <entry>[client-resource:</entry> + <entry>CLIENTSPEC</entry> + </row> + <row rowsep="0"> + <entry></entry> + <entry>intercepted-protocol:</entry> + <entry>LISTofRECORDRANGE]</entry> + </row> + </tbody> + </tgroup> +</informaltable> + +<para> +This structure specifies an intercepted client and the protocol to be +intercepted for the client. The <emphasis remap='I'>client-resource</emphasis> field is a +resource base that identifies the intercepted client. The +<emphasis remap='I'>intercepted-protocol</emphasis> field specifies the protocol to intercept +for the <emphasis remap='I'>client-resource</emphasis>. +</para> +</sect2> + +<sect2 id="Errors"> +<title>Errors</title> +<para> +<emphasis role="bold">RecordContext</emphasis> +</para> + +<itemizedlist> + <listitem> + <para> +<!-- .IN RecordContext --> +<!-- .br --> +This error is returned if the value for an RC argument +in a request does not name a defined record context. + </para> + </listitem> +</itemizedlist> +</sect2> +</sect1> + +<sect1 id="Protocol_Requests"> +<title>Protocol Requests</title> +<!-- .XS --> +<!-- (SN Protocol Requests --> +<!-- .XE --> +<!-- .sp --> +<para> +<function>RecordQueryVersion</function> +</para> + +<itemizedlist> + <listitem> + <para> +<emphasis remap='I'>major-version</emphasis>, +<emphasis remap='I'>minor-version</emphasis>: CARD16 + </para> + </listitem> +</itemizedlist> +<para> +-> +</para> +<itemizedlist> + <listitem> + <para> +<emphasis remap='I'>major-version</emphasis>, +<emphasis remap='I'>minor-version</emphasis>: CARD16 + </para> + </listitem> +</itemizedlist> + +<para> +This request specifies the RECORD extension protocol version the client +would like to use. When the specified protocol version is supported +by the extension, the protocol version the server expects from the +client is returned. Clients must use this request before other RECORD +extension requests. +</para> + +<para> +This request also determines whether or not the RECORD extension protocol +version specified by the client is supported by the extension. If the +extension supports the version specified by the client, this version number +should be returned. If the client has requested a higher version than is +supported by the server, the server's highest version should be returned. +Otherwise, if the client has requested a lower version than is supported +by the server, the server's lowest version should be returned. This document +defines major version one (1), +minor version thirteen (13). +</para> + +<para> +<function>RecordCreateContext</function> +</para> + +<informaltable frame="none"> + <tgroup cols='1' align='left'> + <colspec colname='c1' colsep="0" colwidth="1*"/> + <tbody> + <row rowsep="0"> + <entry> +<emphasis remap='I'>context</emphasis>: RC + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>element-header</emphasis>: ELEMENT_HEADER + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>client-specifiers</emphasis>: LISTofCLIENTSPEC + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>ranges</emphasis>: LISTofRECORDRANGE + </entry> + </row> + <row rowsep="0"> + <entry> +Errors: +<function>Match ,</function> +<function>Value ,</function> +<function>IDChoice ,</function> +<function>Alloc</function> + </entry> + </row> + </tbody> + </tgroup> +</informaltable> + +<para> +This request creates a new +record context +within the server and assigns the identifier <emphasis remap='I'>context</emphasis> to +it. After the <emphasis remap='I'>context</emphasis> is created, this request registers the +set of clients in <emphasis remap='I'>client-specifiers</emphasis> with the <emphasis remap='I'>context</emphasis> and +specifies the protocol to intercept for those clients. +The recorded protocol elements will be preceded by data as specified +by <emphasis remap='I'>element-header</emphasis>. +Typically, +this request is used by a recording client over the control +connection. Multiple RC +objects can exist simultaneously, containing overlapping sets of +protocol and clients to intercept. +</para> + +<para> +If any of the values in +<emphasis remap='I'>element-header</emphasis> or +<emphasis remap='I'>ranges</emphasis> is invalid, a +<function>"Value"</function> +error results. Duplicate items in the list of <emphasis remap='I'>client-specifiers</emphasis> are +ignored. If any item in the <emphasis remap='I'>client-specifiers</emphasis> list is not a valid +CLIENTSPEC, a +<function>"Match"</function> +error results. Otherwise, each item in the <emphasis remap='I'>client-specifiers</emphasis> list is +processed as follows: +</para> + +<itemizedlist> + <listitem> + <para> +If the item is an XIDBASE identifying a particular client, the +specified client is registered with the <emphasis remap='I'>context</emphasis> and the protocol +to intercept for the client is then set to <emphasis remap='I'>ranges</emphasis>. + </para> + </listitem> + <listitem> + <para> +If the item is +<function>CurrentClients ,</function> +all existing clients are registered with the +<emphasis remap='I'>context</emphasis> at this time. +The protocol to intercept for all clients registered +with the <emphasis remap='I'>context</emphasis> is then set to <emphasis remap='I'>ranges</emphasis>. + </para> + </listitem> + <listitem> + <para> +If the item is +<function>FutureClients ,</function> +all clients that connect to the server +after this request executes will be automatically registered with the +<emphasis remap='I'>context</emphasis>. The protocol to intercept for such clients will be set to +<emphasis remap='I'>ranges</emphasis> in the <emphasis remap='I'>context</emphasis>. + </para> + </listitem> + <listitem> + <para> +If the item is +<function>AllClients ,</function> +the effect is as if the actions described +for +<function>FutureClients</function> +are performed, followed by the actions for +<function>CurrentClients .</function> + </para> + </listitem> +</itemizedlist> + +<para> +The +<function>"Alloc"</function> +error results when the server is unable to allocate the necessary +resources. +</para> + +<para> +<function>RecordRegisterClients</function> +</para> + +<informaltable frame="none"> + <tgroup cols='1' align='left'> + <colspec colname='c1' colsep="0" colwidth="1*"/> + <tbody> + <row rowsep="0"> + <entry> +<emphasis remap='I'>context</emphasis>: RC + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>element-header</emphasis>: ELEMENT_HEADER + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>client-specifiers</emphasis>: LISTofCLIENTSPEC + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>ranges</emphasis>: LISTofRECORDRANGE + </entry> + </row> + <row rowsep="0"> + <entry> +Errors: +<function>Match ,</function> +<function>Value ,</function> +<function>RecordContext ,</function> +<function>Alloc</function> + </entry> + </row> + </tbody> + </tgroup> +</informaltable> + +<para> +This request registers the set of clients in <emphasis remap='I'>client-specifiers</emphasis> with +the given <emphasis remap='I'>context</emphasis> and specifies the protocol to intercept for those +clients. +The header preceding each recorded protocol element is set as specified +by <emphasis remap='I'>element-header</emphasis>. +These flags affect the entire +context; their effect is not limited to the clients registered by +this request. +Typically, this request is used by a recording client over +the control connection. +</para> + +<para> +If <emphasis remap='I'>context</emphasis> does not name a valid RC, a +<function>"RecordContext"</function> +error results. If any of the values in +<emphasis remap='I'>element-header</emphasis> or <emphasis remap='I'>ranges</emphasis> is invalid, a +<function>"Value"</function> +error results. Duplicate items in the list of <emphasis remap='I'>client-specifiers</emphasis> are +ignored. If any item in the list of <emphasis remap='I'>client-specifiers</emphasis> is not a +valid CLIENTSPEC, a +<function>"Match"</function> +error results. +If the <emphasis remap='I'>context</emphasis> is enabled and the XID of the enabling connection +is specified, a +<function>"Match"</function> +error results. +Otherwise, each item in the <emphasis remap='I'>client-specifiers</emphasis> list is +processed as follows: +</para> + +<itemizedlist> + <listitem> + <para> +If the item is an XIDBASE identifying a particular client, the +specified client is registered with the <emphasis remap='I'>context</emphasis> if it is not already +registered. The protocol to intercept for the client is then set to +<emphasis remap='I'>ranges</emphasis>. + </para> + </listitem> + <listitem> + <para> +If the item is +<function>CurrentClients ,</function> +all existing clients that are not +already registered with the specified <emphasis remap='I'>context</emphasis>, +except the enabling connection if the <emphasis remap='I'>context</emphasis> is enabled, +are registered at this +time. The protocol to intercept for all clients registered with the +<emphasis remap='I'>context</emphasis> is then set to <emphasis remap='I'>ranges</emphasis>. + </para> + </listitem> + <listitem> + <para> +If the item is +<function>FutureClients ,</function> +all clients that connect to the server +after this request executes will be automatically registered with the +<emphasis remap='I'>context</emphasis>. The protocol to intercept for such clients will be set to +<emphasis remap='I'>ranges</emphasis> in the <emphasis remap='I'>context</emphasis>. +The set of clients that are registered with the +<emphasis remap='I'>context</emphasis> and their corresponding sets +of protocol to intercept are left intact. + </para> + </listitem> + <listitem> + <para> +If the item is +<function>AllClients ,</function> +the effect is as if the actions described +for +<function>FutureClients</function> +are performed, followed by the actions for +<function>CurrentClients .</function> + </para> + </listitem> +</itemizedlist> +<para> +The +<function>"Alloc"</function> +error results when the server is unable to allocate the necessary +resources. +</para> + +<para> +<function>RecordUnregisterClients</function> +</para> + +<informaltable frame="none"> + <tgroup cols='1' align='left'> + <colspec colname='c1' colsep="0" colwidth="1*"/> + <tbody> + <row rowsep="0"> + <entry> +<emphasis remap='I'>context</emphasis>: RC + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>client-specifiers</emphasis>: LISTofCLIENTSPEC + </entry> + </row> + <row rowsep="0"> + <entry> +Errors: +<function>Match ,</function> +<function>RecordContext</function> + </entry> + </row> + </tbody> + </tgroup> +</informaltable> + + +<para> +This request removes the set of clients in <emphasis remap='I'>client-specifiers</emphasis> from the +given <emphasis remap='I'>context</emphasis>'s set of registered clients. Typically, this request is +used by a recording client over the control connection. +</para> + +<para> +If <emphasis remap='I'>context</emphasis> does not name a valid RC, a +<function>"RecordContext"</function> +error results. Duplicate items in the list of <emphasis remap='I'>client-specifiers</emphasis> are +ignored. If any item in the list is not a valid CLIENTSPEC, a +<function>"Match"</function> +error results. Otherwise, each item in the <emphasis remap='I'>client-specifiers</emphasis> list is +processed as follows: +</para> + +<itemizedlist> + <listitem> + <para> +If the item is an XIDBASE identifying a particular client, and the +specified client is currently registered with the <emphasis remap='I'>context</emphasis>, it is +unregistered, and the set of protocol to intercept for the client is +deleted from the <emphasis remap='I'>context</emphasis>. If the specified client is not registered +with the <emphasis remap='I'>context</emphasis>, the item has no effect. + </para> + </listitem> + <listitem> + <para> +If the item is +<function>CurrentClients ,</function> +all clients currently registered with +the <emphasis remap='I'>context</emphasis> are unregistered from it, and their corresponding sets of +protocol to intercept are deleted from the <emphasis remap='I'>context</emphasis>. + </para> + </listitem> + <listitem> + <para> +If the item is +<function>FutureClients ,</function> +clients that connect to the server after +this request executes will not automatically be registered with the +<emphasis remap='I'>context</emphasis>. The set of clients that are registered with this context +and their corresponding sets of protocol that will be +intercepted are left intact. + </para> + </listitem> + <listitem> + <para> +If the item is +<function>AllClients ,</function> +the effect is as if the actions described +for +<function>FutureClients</function> +are performed, followed by the actions for +<function>CurrentClients .</function> + </para> + </listitem> +</itemizedlist> + +<para> +A client is unregistered automatically when it disconnects. +</para> + +<para> +<function>RecordGetContext</function> +</para> + +<informaltable frame="none"> + <tgroup cols='1' align='left'> + <colspec colname='c1' colsep="0" colwidth="1*"/> + <tbody> + <row rowsep="0"> + <entry> +<emphasis remap='I'>context</emphasis>: RC + </entry> + </row> + <row rowsep="0"> + <entry> +-> + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>enabled</emphasis>: BOOL + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>element-header</emphasis>: ELEMENT_HEADER + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>intercepted-clients</emphasis>: LISTofCLIENT_INFO + </entry> + </row> + <row rowsep="0"> + <entry> +Errors: + </entry> + </row> + <row rowsep="0"> + <entry> +<function>RecordContext</function> + </entry> + </row> + </tbody> + </tgroup> +</informaltable> + +<para> +This request queries the current state of the specified <emphasis remap='I'>context</emphasis> +and is typically used by a recording client over the control connection. +The <emphasis remap='I'>enabled</emphasis> field +specifies the state of data transfer between the extension and the +recording client, and is either enabled +<function>( True )</function> +or disabled +<function>( False ).</function> +The initial state is disabled. +When enabled, all core X protocol and +extension protocol received from (requests) or sent to (replies, +errors, events) a particular client, and requested to be intercepted +by the recording client, is reported to the recording client over the +data connection. +The <emphasis remap='I'>element-header</emphasis> specifies the header that precedes each +recorded protocol element. +The +<emphasis remap='I'>intercepted-clients</emphasis> field specifies the list of clients currently +being recorded and the protocol associated with each client. +If future clients will be automatically registered with the context, +one of the returned CLIENT_INFO structures has a <emphasis remap='I'>client-resource</emphasis> value +of FutureClients and an <emphasis remap='I'>intercepted-protocol</emphasis> giving the protocol to +intercept for future clients. +Protocol ranges may be decomposed, coalesced, or otherwise modified +by the server from how they were specified by the client. +All CLIENTSPECs registered with the server are returned, even if the +RECORDRANGE(s) associated with them specify no protocol to record. +</para> + +<para> +When the <emphasis remap='I'>context</emphasis> argument is not valid, a +<function>RecordContext</function> +error results. +</para> + +<para> +<function>RecordEnableContext</function> +</para> + +<informaltable frame="none"> + <tgroup cols='1' align='left'> + <colspec colname='c1' colsep="0" colwidth="1*"/> + <tbody> + <row rowsep="0"> + <entry> +<emphasis remap='I'>context</emphasis>: RC + </entry> + </row> + <row rowsep="0"> + <entry> +->+ + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>category</emphasis>: +{<function>FromServer</function>, <function>FromClient</function>, +<function>ClientStarted</function>, <function>ClientDied</function>, +<function>StartOfData</function>, +<function>EndOfData</function>} + </entry> + </row> + + <row rowsep="0"> + <entry> +<emphasis remap='I'>element-header</emphasis>: ELEMENT_HEADER + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>client-swapped</emphasis>: BOOL + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>id-base</emphasis>: XIDBASE + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>server-time</emphasis>: TIMESTAMP + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>recorded-sequence-number</emphasis>: CARD32 + </entry> + </row> + <row rowsep="0"> + <entry> +<emphasis remap='I'>data</emphasis>: LISTofBYTE + </entry> + </row> + <row rowsep="0"> + <entry> +Errors: +<function>Match</function>, +<function>RecordContext</function> + </entry> + </row> + </tbody> + </tgroup> +</informaltable> + +<para> +This request enables data transfer between the recording client +and the extension and returns the protocol data the recording client +has previously expressed interest in. Typically, this request is +executed by the recording client over the data connection. +</para> + +<para> +If the client is registered on the <emphasis remap='I'>context</emphasis>, it is unregistered +before any recording begins. +</para> +<para> +<!-- .LP --> +Once the server receives this request, it begins intercepting +and reporting to the recording client all core and extension protocol +received from or sent to clients registered with the RC that the +recording client has expressed interest in. All intercepted protocol data +is returned in the byte-order of the recorded client. Therefore, +recording clients are responsible for all byte swapping, if required. +More than one recording client cannot enable data transfer on the +same RC at the same time. Multiple intercepted requests, replies, +events and errors might be packaged into a single reply before +being returned to the recording clients. +</para> +<para> +<!-- .LP --> +The +<emphasis remap='I'>category</emphasis> field determines the possible +types of the data. +When a context is enabled, the server will immediately send a reply of +category +<function>StartOfData</function> +to notify the client that recording is enabled. +A category of +<function>FromClient</function> +means the data are from the client +(requests); +<function>FromServer</function> +means data are from the server (replies, +errors, events, or device events). +For a new client, the category is +<function>ClientStarted</function> +and the data are the connection setup reply. +When +the recorded client connection is closed, <emphasis remap='I'>category</emphasis> is +set to the value +<function>ClientDied</function> +and no protocol is included in this reply. +When the disable request is made over the control connection, +a final reply is sent over the data connection with category +<function>EndOfData</function> +and no protocol. +</para> +<para> +<!-- .LP --> +The <emphasis remap='I'>element-header</emphasis> field returns the value currently set for the +context, which tells what header information precedes each recorded +protocol element in this reply. +</para> +<para> +<!-- .LP --> +The <emphasis remap='I'>client-swapped</emphasis> field is +<function>True</function> +if the byte order of +the protocol being recorded +is swapped +relative to the recording client; +otherwise, <emphasis remap='I'>client-swapped</emphasis> is +<function>False .</function> +The recorded protocol +is in the byte order of the client being +recorded; device events are in the byte order of the +recording client. +For replies of category +<function>StartOfData</function> +and +<function>EndOfData</function> +the +<emphasis remap='I'>client-swapped</emphasis> bit is set +according +to the byte order of the server relative to the recording client. +The <emphasis remap='I'>id-base</emphasis> field is the resource identifier base +sent to the client from the server in the +connection setup reply, and hence, identifies the client being +recorded. The <emphasis remap='I'>id-base</emphasis> field is 0 (zero) when the protocol +data being +returned are device events. +The <emphasis remap='I'>server-time</emphasis> field is set to the time of the +server when the first protocol element in this reply was intercepted. +The <emphasis remap='I'>server-time</emphasis> +of reply N+1 is greater than or equal to the <emphasis remap='I'>server-time</emphasis> of reply N, +and is greater than or equal to the time of the last protocol +element in reply N. +</para> +<para> +<!-- .LP --> +The <emphasis remap='I'>recorded-sequence-number</emphasis> field is set to the sequence number +of the recorded client's most recent request processed by the server. +</para> +<para> +<!-- .LP --> +The <emphasis remap='I'>data</emphasis> field +contains the raw protocol data being returned to the recording client. +If requested by the <emphasis remap='I'>element-header</emphasis> of this record context, each +protocol element may be preceded by a 32-bit timestamp and/or +a 32-bit sequence number. +If present, both the timestamp and sequence number are always in the +byte order of the recording client. +</para> +<para> +<!-- .LP --> +For the core X events +<function>KeyPress ,</function> +<function>KeyRelease ,</function> +<function>ButtonPress ,</function> +and +<function>ButtonRelease ,</function> +the fields of a device event that contain +valid information are <emphasis remap='I'>time</emphasis> and <emphasis remap='I'>detail</emphasis>. +For the core X event +<function>MotionNotify ,</function> +the fields of a device event that contain +valid information are <emphasis remap='I'>time</emphasis>, <emphasis remap='I'>root</emphasis>, +<emphasis remap='I'>root-x</emphasis> and <emphasis remap='I'>root-y</emphasis>. +The <emphasis remap='I'>time</emphasis> field refers to the time the event was generated by the +device. +</para> +<para> +<!-- .LP --> +For the extension input device events +<function>DeviceKeyPress ,</function> +<function>DeviceKeyRelease ,</function> +<function>DeviceButtonPress ,</function> +and +<function>DeviceButtonRelease ,</function> +the fields of a device event that contain valid information are +<emphasis remap='I'>device</emphasis>, <emphasis remap='I'>time</emphasis> and <emphasis remap='I'>detail</emphasis>. +For +<function>DeviceMotionNotify ,</function> +the valid device event fields are +<emphasis remap='I'>device</emphasis> and <emphasis remap='I'>time</emphasis>. +For the extension input device events +<function>ProximityIn</function> +and +<function>ProximityOut ,</function> +the fields of a device event that contain valid +information are <emphasis remap='I'>device</emphasis> and <emphasis remap='I'>time</emphasis>. +For the extension input device event +<function>DeviceValuator ,</function> +the fields of a device event that contain valid information are +<emphasis remap='I'>device</emphasis>, +<emphasis remap='I'>num_valuators</emphasis>, <emphasis remap='I'>first_valuator</emphasis>, and <emphasis remap='I'>valuators</emphasis>. +The <emphasis remap='I'>time</emphasis> field refers to the time the event was generated by the +device. +</para> +<para> +<!-- .LP --> +The error +<function>"Match"</function> +is returned when data transfer is already enabled. +When the <emphasis remap='I'>context</emphasis> argument is not valid, a +<function>RecordContext</function> +error results. +</para> + +<para> +<function>RecordDisableContext</function> +</para> + +<informaltable frame="none"> + <tgroup cols='1' align='left'> + <colspec colname='c1' colsep="0" colwidth="1*"/> + <tbody> + <row rowsep="0"> + <entry> +<emphasis remap='I'>context</emphasis>: RC + </entry> + </row> + <row rowsep="0"> + <entry> +Errors: +<function>RecordContext</function> + </entry> + </row> + </tbody> + </tgroup> +</informaltable> + +<para> +This request is typically executed by the recording client over the +control connection. This request directs the extension to immediately +send any complete protocol elements currently buffered, +to send a final reply with category +<function>EndOfData ,</function> +and to discontinue +data transfer between the extension and the recording client. +Protocol reporting is disabled +on the data connection that is currently enabled for the given +<emphasis remap='I'>context</emphasis>. Once the extension completes +processing this request, no additional recorded protocol will +be reported to the recording client. If a data connection is not +currently enabled when this request is executed, then this request has +no affect on the state of data transfer. +An RC is disabled automatically when the connection to the enabling +client is closed down. +</para> + +<para> +When the <emphasis remap='I'>context</emphasis> argument is not valid, a +<function>RecordContext</function> +error results. +</para> + +<para> +<function>RecordFreeContext</function> +</para> + +<itemizedlist> + <listitem> + <para> +<emphasis remap='I'>context</emphasis> RC +<!-- .br --> + </para> + </listitem> + <listitem> + <para> +Errors: +<function>RecordContext</function> + </para> + </listitem> +</itemizedlist> + +<para> +This request deletes the association between the resource ID and the +RC and destroys the RC. +If a client has enabled data transfer on this <emphasis remap='I'>context</emphasis>, the actions +described in +<function>RecordDisableContext</function> +are performed before the <emphasis remap='I'>context</emphasis> +is freed. +</para> + +<para> +An RC is destroyed automatically when the connection to the creating client +is closed down and the close-down mode is <function>DestroyAll</function>. When the +<emphasis remap='I'>context</emphasis> argument is not valid, a +<function>RecordContext</function> +error results. +</para> +</sect1> + +<sect1 id="Encoding"> +<title>Encoding</title> +<para> +Please refer to the X11 Protocol Encoding document as this document uses +conventions established there. +</para> + +<para> +The name of this extension is "RECORD". +</para> + +<sect2 id="Types_2"> +<title>Types</title> +<para> +RC: CARD32 +</para> + +<literallayout class="monospaced"> +RANGE8 + 1 CARD8 first + 1 CARD8 last +</literallayout> + +<literallayout class="monospaced"> +RANGE16 + 2 CARD16 first + 2 CARD16 last +</literallayout> + +<literallayout class="monospaced"> +EXTRANGE + 2 RANGE8 major + 4 RANGE16 minor +</literallayout> + +<literallayout class="monospaced"> +RECORDRANGE + 2 RANGE8 core-requests + 2 RANGE8 core-replies + 6 EXTRANGE ext-requests + 6 EXTRANGE ext-replies + 2 RANGE8 delivered-events + 2 RANGE8 device-events + 2 RANGE8 errors + 1 BOOL client-started + 1 BOOL client-died +</literallayout> + +<literallayout class="monospaced"> +ELEMENT_HEADER + 1 CARD8 + 0x01 from-server-time + 0x02 from-client-time + 0x04 from-client-sequence +</literallayout> + +<para> +XIDBASE: CARD32 +</para> + +<literallayout class="monospaced"> +CLIENTSPEC + 4 XIDBASE client-id-base + 1 CurrentClients + 2 FutureClients + 3 AllClients +</literallayout> + +<literallayout class="monospaced"> +CLIENT_INFO + 4 CLIENTSPEC client-resource + 4 CARD32 n, number of record ranges in + intercepted-protocol + 24n LISTofRECORDRANGE intercepted-protocol +</literallayout> + +</sect2> +<sect2 id="Errors_2"> +<title>Errors</title> + +<literallayout class="monospaced"> +<function>RecordContext</function> + 1 0 Error + 1 CARD8 extension's base error code + 0 + 2 CARD16 sequence number + 4 CARD32 invalid record context + 24 unused +</literallayout> +</sect2> + +<sect2 id="Requests"> +<title>Requests</title> + +<literallayout class="monospaced"> +<function>RecordQueryVersion</function> + 1 CARD8 major opcode + 1 0 minor opcode + 2 2 request length + 2 CARD16 major version + 2 CARD16 minor version + => + 1 1 Reply + 1 unused + 2 CARD16 sequence number + 4 0 reply length + 2 CARD16 major version + 2 CARD16 minor version + 20 unused +</literallayout> + +<literallayout class="monospaced"> +<function>RecordCreateContext</function> + 1 CARD8 major opcode + 1 1 minor opcode + 2 5+m+6n request length + 4 RC context + 1 ELEMENT_HEADER element-header + 3 unused + 4 CARD32 m, number of client-specifiers + 4 CARD32 n, number of ranges + 4m LISTofCLIENTSPEC client-specifiers + 24n LISTofRECORDRANGE ranges +</literallayout> + +<literallayout class="monospaced"> +<function>RecordRegisterClients</function> + 1 CARD8 major opcode + 1 2 minor opcode + 2 5+m+6n request length + 4 RC context + 1 ELEMENT_HEADER element-header + 3 unused + 4 CARD32 m, number of client-specifiers + 4 CARD32 n, number of ranges + 4m LISTofCLIENTSPEC client-specifiers + 24n LISTofRECORDRANGE ranges +</literallayout> + +<literallayout class="monospaced"> +<function>RecordUnregisterClients</function> + 1 CARD8 major opcode + 1 3 minor opcode + 2 3+m request length + 4 RC context + 4 CARD32 m, number of client-specifiers + 4m LISTofCLIENTSPEC client-specifiers +</literallayout> + +<literallayout class="monospaced"> +<function>RecordGetContext</function> + 1 CARD8 major opcode + 1 4 minor opcode + 2 2 request length + 4 RC context + => + 1 1 Reply + 1 BOOL enabled + 2 CARD16 sequence number + 4 j reply length + 1 ELEMENT_HEADER element-header + 3 unused + 4 CARD32 n, number of intercepted-clients + 16 unused + 4j LISTofCLIENT_INFO intercepted-clients +</literallayout> + +<literallayout class="monospaced"> +<function>RecordEnableContext</function> + 1 CARD8 major opcode + 1 5 minor opcode + 2 2 request length + 4 RC context + =>+ + 1 1 Reply + 1 category + 0 FromServer + 1 FromClient + 2 ClientStarted + 3 ClientDied + 4 StartOfData + 5 EndOfData + 2 CARD16 sequence number + 4 n reply length + 1 ELEMENT_HEADER element-header + 1 BOOL client-swapped + 2 unused + 4 XIDBASE id-base + 4 TIMESTAMP server-time + 4 CARD32 recorded-sequence-number + 8 unused + 4n BYTE data +</literallayout> + +<literallayout class="monospaced"> +<function>RecordDisableContext</function> + 1 CARD8 major opcode + 1 6 minor opcode + 2 2 request length + 4 RC context +</literallayout> + +<literallayout class="monospaced"> +<function>RecordFreeContext</function> + 1 CARD8 major opcode + 1 7 minor opcode + 2 2 request length + 4 RC context +</literallayout> + +</sect2> +</sect1> +</chapter> +</book> |