--- /dev/null
+commit 32236c56b7015a98d845bb1836817328a307edce
+Author: Alan Coopersmith <alan.coopersmith@oracle.com>
+Date: Thu Mar 22 20:46:36 2012 -0700
+
+ recordproto 1.14.2
+
+ Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
+
+commit 10028272314500dd2e17e5ae7efa0a2d4d118c13
+Author: Matt Dew <marcoz@osource.org>
+Date: Fri Jan 13 23:20:09 2012 -0700
+
+ informaltable cleanup
+
+ On certain tables, add top and bottom borders to table
+ header and a bottom border to the table. This matches
+ what those tables in the old pdfs looked like.
+
+ the <?dbfo keep-together='always'> prevents tables from
+ splitting across pages. Useful for tiny tables.
+
+ Converting the colwidth to a floating point,
+ IE, 1* -> 1.0* cleans up these build errors:
+ WARNING: table-layout="fixed" and column-width unspecified
+ => falling back to proportional-column-width(1)
+
+ Signed-off-by: Matt Dew <marcoz@osource.org>
+
+commit 5a7a2820665a495df32694d90b6f5192dd53547e
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Tue Sep 20 20:12:54 2011 -0400
+
+ specs: refactor copyright license text for multi licening
+
+ Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
+
+commit 233ed0eef7526ae02223359851be51e43240652b
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Mon Sep 12 16:54:45 2011 -0400
+
+ docs: use the &fullrelvers; entity to set X11 release information
+
+ Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
+
+commit 9ecf07de57da54009c5bb4567655996f69ba8deb
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Sun Sep 11 19:49:54 2011 -0400
+
+ docs: remove <productnumber> which is not used by default
+
+ This element is not rendered by default on the title. A template
+ customization is required to display it.
+ X Window System does not have a product number.
+
+ Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
+
+commit c8d4e3eddc07889f0bc493884f120e741226c28b
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Sun Sep 11 08:51:02 2011 -0400
+
+ specs: use more appropriate docbook element to get "Edited by"
+
+ The proper element to use is <editor>.
+ The <contrib> was a hack to insert text and showed up in the wrong location
+
+ Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
+
+commit 1950143424ea47973613bc1dbec805e8a32aa97b
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Thu Sep 8 20:00:00 2011 -0400
+
+ docbook.am: embed css styles inside the HTML HEAD element
+
+ Rather than referring to the external xorg.css stylesheet, embed the content
+ of the file in the html output produced. This is accomplished by using
+ version 1.10 of xorg-xhtml.xsl.
+
+ This makes the whole html docs tree much more relocatable.
+ In addition, it eliminates xorg.css as a runtime file which makes
+ xorg-sgml-doctools a build time only package.
+
+ Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
+
+commit d1011e878c92be804fe896f9adf2b686c01f2172
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Wed Sep 7 10:31:04 2011 -0400
+
+ docbook.am: global maintenance update - entities, images and olinking
+
+ Adding support in libX11 for html chunking caused a reorg of docbook.am
+ as well as the xorg-sgml-doctools masterdb for olinking.
+ The parameter img.src.path is added for pdf images.
+ A searchpath to the root builddir is added for local entities, if present.
+
+ The docbook.am makefile hides all the details and is identical for
+ all 22 modules having DocBook documentation. It is included by a thin
+ Makefile.am which requires no docbook knowledge.
+
+ Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
+
+commit cbba0d1e4665b585804b5de33c5ed1a4c3b19727
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Sun Jun 12 17:54:50 2011 -0400
+
+ Install xml versions of specs even if HAVE_XMLTO is false
+
+ DocBook/XML input source is also a usefull output format that can be viewed
+ with an XML viewer or editor and by some O/S help system.
+
+ Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
+
+commit b045d4c13967bd061f6a104136152e841bc432b5
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Sun Jun 5 16:27:37 2011 -0400
+
+ Install target dbs alongside generated documents
+
+ This matches a change in xorg-sgml-docs whereby the masterdb will look for
+ the target dbs into the same location as the generated documents.
+
+ The target dbs are now installed alongside the generated documents.
+ Previously they are installed in $prefix/sgml/X11/dbs alongside masterdb which
+ has the potential of installing outside the package prefix and cause
+ distcheck to fail when user does not have write permission in this package.
+
+ Requires XORG_CHECK_SGML_DOCTOOLS(1.8) which was released 2011-06-11
+
+commit dcc64434a3e79931b05fc807906189dfa3a9ddd0
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Sun Feb 27 15:06:18 2011 -0500
+
+ Documentation: add Docbook external references support
+
+ When writing technical documentation, it is often necessary to cross
+ reference to other information. When that other information is not in the
+ current document, additional support is needed, namely <olink>.
+
+ A new feature with version 1.7 of xorg-sgml-doctools adds references to
+ other documents within or outside this package.
+
+ This patch adds technical support for this feature but does not change
+ the content of the documentation as seen by the end user.
+
+ Each book or article must generate a database containing the href
+ of sections that can be referred to from another document. This database
+ is installed in DATAROOTDIR/sgml/X11/dbs. There is a requirement that
+ the value of DATAROOTDIR for xorg-sgml-doctools and for the package
+ documentation is the same. This forms a virtual document tree.
+
+ This database is consulted by other documents while they are being generated
+ in order to fulfill the missing information for linking.
+ Refer to the xorg-sgml-doctools for further technical information.
+
+ Co-authored-by: Matt Dew <marcoz@osource.org>
+
+ Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
+
+commit f5813bffb2b642d8b515306caff555eac32b9b43
+Author: Alan Coopersmith <alan.coopersmith@oracle.com>
+Date: Thu Dec 16 23:12:58 2010 -0800
+
+ specs/record.xml: Pair copyright notices with matching license notices
+
+ Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
+
+commit 3011b8527ba7370e7e29758ecba0231e7e25bda8
+Author: Alan Coopersmith <alan.coopersmith@oracle.com>
+Date: Thu Dec 16 23:10:06 2010 -0800
+
+ specs/record.xml: Fix section titles/nesting
+
+ Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
+
+commit 2c1cabffad2903867fd352c19f0157d07adde232
+Author: Gaetan Nadon <memsize@videotron.ca>
+Date: Tue Nov 9 15:19:09 2010 -0500
+
+ config: HTML file generation: use the installed copy of xorg.css
+
+ Currenlty the xorg.css file is copied in each location
+ where a DocBook/XML file resides. This produces about
+ 70 copies in the $(docdir) install tree.
+
+ Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
+
+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
+
+ recordproto 1.14
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit fd428befaa8a76b216d5e42e63b688d4d55fdbc5
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Thu Oct 1 19:38:12 2009 +1000
+
+ Require macros 1.3 for XORG_DEFAULT_OPTIONS
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 379a691a45f4a637b8b7bbea9d3c7c2454f5cde6
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Sat Aug 15 21:47:26 2009 +1000
+
+ Bump to 1.13.99.1
+
+commit a7419fc173ccb949e6b20e1608bdcb816157a17f
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Tue Aug 18 11:08:27 2009 +1000
+
+ Rename recordstr.h to recordproto.h, provide a stub instead.
+
+ Renaming for consistency with other protocol packages. recordstr.h is a
+ simple stub warning against the use of this header.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 5e35e18e81da8a6a891bc73ac828d45eae91c53c
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Aug 14 13:34:52 2009 +1000
+
+ Remove xlib headers, rename record.h to recordconst.h.
+
+ Xlib headers moved to libXtst.
+
+ This patch also moves some defines from recordstr.h into recordconst.h.
+ These defines are the ones possibly used by clients (e.g. RECORD_NAME).
+ Clients should never need to include recordstr.h.
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit 59c7795cb8cf932c5c5942bb07278854c89a6a67
+Author: Peter Hutterer <peter.hutterer@who-t.net>
+Date: Fri Aug 14 13:29:13 2009 +1000
+
+ remove RCS tags
+
+ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
+
+commit eb14a315478af94dc588e1ed29628830deef90e4
+Author: Paulo Cesar Pereira de Andrade <pcpa@mandriva.com.br>
+Date: Tue Jan 27 20:06:28 2009 -0200
+
+ Janitor: Correct make distcheck and dont distribute autogen.sh
+
+commit b38fe6228b369c7bf32e4003658395dd45352257
+Author: James Cloos <cloos@jhcloos.com>
+Date: Thu Dec 6 16:39:05 2007 -0500
+
+ Replace static ChangeLog with dist-hook to generate from git log
+
+commit ecaf1d1c89a1ce914c387c8d9722d6cdaa82a9e6
+Author: James Cloos <cloos@jhcloos.com>
+Date: Mon Sep 3 05:54:13 2007 -0400
+
+ Add *~ to .gitignore to skip patch/emacs droppings
+
+commit 400d7a5db8cb56464a2ff48b21a1b53e7cc5b295
+Author: Alan Coopersmith <alan.coopersmith@sun.com>
+Date: Fri Jul 14 18:56:28 2006 -0700
+
+ renamed: .cvsignore -> .gitignore
+
+commit 18c27afa9a8a96bd8ba05ba6cd1e3bf0922601cb
+Author: Kevin E Martin <kem@kem.org>
+Date: Thu Dec 15 00:24:38 2005 +0000
+
+ Update package version number for final X11R7 release candidate.
+
+commit 6f8dbc14edcff010da66a1bf2d0f5e570f2d0812
+Author: Kevin E Martin <kem@kem.org>
+Date: Wed Oct 19 02:48:14 2005 +0000
+
+ Update package version number for RC1 release.
+
+commit b298e441128e479b12615acab77df63a1ce516b1
+Author: Eric Anholt <anholt@freebsd.org>
+Date: Tue Aug 2 19:19:39 2005 +0000
+
+ Add basic .cvsignore files for proto modules.
+
+commit b9e116fe4b9970696029d79c63bb36a0960a7861
+Author: Kevin E Martin <kem@kem.org>
+Date: Fri Jul 29 21:22:56 2005 +0000
+
+ Various changes preparing packages for RC0:
+ - Verify and update package version numbers as needed
+ - Implement versioning scheme
+ - Change bug address to point to bugzilla bug entry form
+ - Disable loadable i18n in libX11 by default (use --enable-loadable-i18n to
+ reenable it)
+ - Fix makedepend to use pkgconfig and pass distcheck
+ - Update build script to build macros first
+ - Update modular Xorg version
+
+commit a895a7e1f18706d4a91a390f1266bbd4a46f8231
+Author: Daniel Stone <daniel@fooishbar.org>
+Date: Sat May 21 04:15:05 2005 +0000
+
+ Set version to 1.13.
+
+commit 3e7909df321b6969bc020d84a54bea6af31fc80c
+Author: Adam Jackson <ajax@nwnk.net>
+Date: Thu May 19 00:22:40 2005 +0000
+
+ revert last change, didn't do right thing at all, sorry for the noise
+
+commit 8f287f8cfaeac5c28560fa94ca215244c1bb7776
+Author: Adam Jackson <ajax@nwnk.net>
+Date: Thu May 19 00:10:19 2005 +0000
+
+ Require automake 1.7 in AM_INIT_AUTOMAKE
+
+commit 3cb43fd0e261894865a8a86d598adb41eec0cc0e
+Author: Josh Triplett <josh@speakeasy.net>
+Date: Tue May 17 07:08:40 2005 +0000
+
+ Add COPYING file for Record.
+
+commit 7bb7d5ca1396f83d81cc4164b975e5dc2597e678
+Author: Søren Sandmann Pedersen <sandmann@daimi.au.dk>
+Date: Mon May 9 18:20:06 2005 +0000
+
+ Change all the protonames from <extension>Ext to <extension>Proto.
+
+commit 81198a3b1bbff8109801c64c44f732bb26abcb89
+Author: Kevin E Martin <kem@kem.org>
+Date: Fri May 6 01:46:31 2005 +0000
+
+ Initial build system files for proto module.
+
+commit c7dc29e5d64a7fc308874512321f43c194ac11e2
+Author: Egbert Eich <eich@suse.de>
+Date: Fri Apr 23 18:43:06 2004 +0000
+
+ Merging XORG-CURRENT into trunk
+
+commit b62b2b4b4cd80f05e48c634d16e05bed76f80607
+Author: Egbert Eich <eich@suse.de>
+Date: Sun Mar 14 08:31:36 2004 +0000
+
+ Importing vendor version xf86-4_4_99_1 on Sun Mar 14 00:26:39 PST 2004
+
+commit f6c0db4c6e249901109722da6d5bd7be3bde377c
+Author: Egbert Eich <eich@suse.de>
+Date: Wed Mar 3 12:10:54 2004 +0000
+
+ Importing vendor version xf86-4_4_0 on Wed Mar 3 04:09:24 PST 2004
+
+commit 28f7d2358c7b2a07f08ea9b872aab5ee42440b56
+Author: Egbert Eich <eich@suse.de>
+Date: Thu Feb 26 13:35:14 2004 +0000
+
+ readding XFree86's cvs IDs
+
+commit c435e3cc568e9d690f7b1291084e676ae3376d54
+Author: Egbert Eich <eich@suse.de>
+Date: Thu Feb 26 09:22:28 2004 +0000
+
+ Importing vendor version xf86-4_3_99_903 on Wed Feb 26 01:21:00 PST 2004
+
+commit 45626afe8e328c1c1deb32cb6e96914ba8923101
+Author: Kaleb Keithley <kaleb@freedesktop.org>
+Date: Tue Nov 25 19:28:02 2003 +0000
+
+ XFree86 4.3.99.16 Bring the tree up to date for the Cygwin folks
+
+commit 3b9115eb4dd86b813ac3423f2d508535a2fcaf09
+Author: Kaleb Keithley <kaleb@freedesktop.org>
+Date: Fri Nov 14 16:48:43 2003 +0000
+
+ XFree86 4.3.0.1
+
+commit 5891b79405209d51d5fcf20ff562cf7120c3017f
+Author: Kaleb Keithley <kaleb@freedesktop.org>
+Date: Fri Nov 14 15:54:35 2003 +0000
+
+ R6.6 is the Xorg base-line
--- /dev/null
+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.
+
--- /dev/null
+<?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"
+[
+<!ENTITY % defs SYSTEM "defs.ent"> %defs;
+]>
+
+
+<!-- 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>
+ <editor>
+ <firstname>Stephen</firstname><surname>Gildea</surname>
+ <affiliation><orgname>X Consortium</orgname></affiliation>
+ </editor>
+ </authorgroup>
+ <releaseinfo>X Version 11, Release &fullrelvers;</releaseinfo>
+ <copyright><year>1994</year><holder>Network Computing Devices, Inc.</holder>
+ </copyright>
+
+<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>
+</legalnotice>
+
+<legalnotice>
+<para role="multiLicensing">Copyright © 1994, 1995 X Consortium</para>
+<para>
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/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>
+<para>X Window System is a trademark of The Open Group.</para>
+</legalnotice>
+</bookinfo>
+
+<chapter 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>
+
+<sect1 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>
+</sect1>
+
+<sect1 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>
+</sect1>
+
+<sect1 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>
+</sect1>
+</chapter>
+
+<chapter id="Design">
+<title>Design</title>
+<para>
+This section gives an overview of the RECORD extension and discusses
+its overall operation and data types.
+</para>
+
+<sect1 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>
+<sect2 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>
+</sect2>
+<sect2 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>
+</sect2>
+
+<sect2 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>
+</sect2>
+<sect2 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>
+</sect2>
+
+<sect2 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>
+</sect2>
+</sect1>
+
+<sect1 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">
+ <?dbfo keep-together="always" ?>
+ <tgroup cols='3' align='left' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.0*"/>
+ <colspec colname='c2' colwidth="1.0*"/>
+ <colspec colname='c3' colwidth="4.0*"/>
+ <tbody>
+ <row>
+ <entry>RANGE8:</entry>
+ <entry>[first, last:</entry>
+ <entry>CARD8]</entry>
+ </row>
+ <row>
+ <entry>RANGE16:</entry>
+ <entry>[first, last:</entry>
+ <entry>CARD16]</entry>
+ </row>
+ <row>
+ <entry>EXTRANGE:</entry>
+ <entry>[major:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>minor:</entry>
+ <entry>RANGE16]</entry>
+ </row>
+ </tbody>
+ </tgroup>
+</informaltable>
+
+<informaltable frame="none">
+ <?dbfo keep-together="always" ?>
+ <tgroup cols='3' align='left' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.5*"/>
+ <colspec colname='c2' colwidth="1.0*"/>
+ <colspec colname='c3' colwidth="4.0*"/>
+ <tbody>
+ <row>
+ <entry>RECORDRANGE:</entry>
+ <entry>[core-requests:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>core-replies:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>ext-requests:</entry>
+ <entry>EXTRANGE</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>ext-replies:</entry>
+ <entry>EXTRANGE</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>delivered-events:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>device-events:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>errors:</entry>
+ <entry>RANGE8</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>client-started:</entry>
+ <entry>BOOL</entry>
+ </row>
+ <row>
+ <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">
+ <?dbfo keep-together="always" ?>
+ <tgroup cols='3' align='left' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.0*"/>
+ <colspec colname='c2' colwidth="1.0*"/>
+ <colspec colname='c3' colwidth="2.0*"/>
+ <tbody>
+ <row>
+ <entry>ELEMENT_HEADER:</entry>
+ <entry>[from-server-time:</entry>
+ <entry>BOOL</entry>
+ </row>
+ <row>
+ <entry></entry>
+ <entry>from-client-time:</entry>
+ <entry>BOOL</entry>
+ </row>
+ <row>
+ <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">
+ <?dbfo keep-together="always" ?>
+ <tgroup cols='3' align='left' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.0*"/>
+ <colspec colname='c2' colwidth="1.0*"/>
+ <colspec colname='c3' colwidth="3.0*"/>
+ <tbody>
+ <row>
+ <entry>CLIENT_INFO:</entry>
+ <entry>[client-resource:</entry>
+ <entry>CLIENTSPEC</entry>
+ </row>
+ <row>
+ <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>
+</sect1>
+
+<sect1 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>
+</sect1>
+</chapter>
+
+<chapter 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">
+ <?dbfo keep-together="always" ?>
+ <tgroup cols='1' align='left' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.0*"/>
+ <tbody>
+ <row>
+ <entry>
+<emphasis remap='I'>context</emphasis>: RC
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>element-header</emphasis>: ELEMENT_HEADER
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>client-specifiers</emphasis>: LISTofCLIENTSPEC
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>ranges</emphasis>: LISTofRECORDRANGE
+ </entry>
+ </row>
+ <row>
+ <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">
+ <?dbfo keep-together="always" ?>
+ <tgroup cols='1' align='left' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.0*"/>
+ <tbody>
+ <row>
+ <entry>
+<emphasis remap='I'>context</emphasis>: RC
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>element-header</emphasis>: ELEMENT_HEADER
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>client-specifiers</emphasis>: LISTofCLIENTSPEC
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>ranges</emphasis>: LISTofRECORDRANGE
+ </entry>
+ </row>
+ <row>
+ <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">
+ <?dbfo keep-together="always" ?>
+ <tgroup cols='1' align='left' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.0*"/>
+ <tbody>
+ <row>
+ <entry>
+<emphasis remap='I'>context</emphasis>: RC
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>client-specifiers</emphasis>: LISTofCLIENTSPEC
+ </entry>
+ </row>
+ <row>
+ <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">
+ <?dbfo keep-together="always" ?>
+ <tgroup cols='1' align='left' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.0*"/>
+ <tbody>
+ <row>
+ <entry>
+<emphasis remap='I'>context</emphasis>: RC
+ </entry>
+ </row>
+ <row>
+ <entry>
+->
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>enabled</emphasis>: BOOL
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>element-header</emphasis>: ELEMENT_HEADER
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>intercepted-clients</emphasis>: LISTofCLIENT_INFO
+ </entry>
+ </row>
+ <row>
+ <entry>
+Errors:
+ </entry>
+ </row>
+ <row>
+ <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' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.0*"/>
+ <tbody>
+ <row>
+ <entry>
+<emphasis remap='I'>context</emphasis>: RC
+ </entry>
+ </row>
+ <row>
+ <entry>
+->+
+ </entry>
+ </row>
+ <row>
+ <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>
+ <entry>
+<emphasis remap='I'>element-header</emphasis>: ELEMENT_HEADER
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>client-swapped</emphasis>: BOOL
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>id-base</emphasis>: XIDBASE
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>server-time</emphasis>: TIMESTAMP
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>recorded-sequence-number</emphasis>: CARD32
+ </entry>
+ </row>
+ <row>
+ <entry>
+<emphasis remap='I'>data</emphasis>: LISTofBYTE
+ </entry>
+ </row>
+ <row>
+ <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">
+ <?dbfo keep-together="always" ?>
+ <tgroup cols='1' align='left' colsep='0' rowsep='0'>
+ <colspec colname='c1' colwidth="1.0*"/>
+ <tbody>
+ <row>
+ <entry>
+<emphasis remap='I'>context</emphasis>: RC
+ </entry>
+ </row>
+ <row>
+ <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>
+</chapter>
+
+<chapter 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>
+
+<sect1 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>
+
+</sect1>
+<sect1 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>
+</sect1>
+
+<sect1 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>
+
+</sect1>
+</chapter>
+</book>
projects / framework / uifw / xorg / proto / x11proto-record.git / commitdiff