.gitignore | 75 +-
Makefile.am | 12
README | 9
configure.ac | 37 -
include/X11/extensions/XTest.h | 2
man/.gitignore | 3
man/Makefile.am | 68 -
man/XTest.xml | 1
specs/.gitignore | 6
specs/Makefile.am | 64 +
specs/recordlib.xml | 1516 +++++++++++++++++++++++++++++++++++++++++
specs/xtestlib.xml | 467 ++++++++++++
src/Makefile.am | 9
src/XRecord.c | 5
src/XTest.c | 9
15 files changed, 2184 insertions(+), 99 deletions(-)
New commits:
commit 5c6834bc9e0ab78c78733c59046510a2f48b2d42
Author: Alan Coopersmith <alan.coopersm...@oracle.com>
Date: Fri Oct 29 17:38:10 2010 -0700
libXtst 1.2.0
Signed-off-by: Alan Coopersmith <alan.coopersm...@oracle.com>
diff --git a/configure.ac b/configure.ac
index a747151..98cb39a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,7 +23,8 @@ dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT(libXtst, 1.1.0,
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], libXtst)
+AC_INIT([libXtst], [1.2.0],
+ [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], [libXtst])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
AM_MAINTAINER_MODE
commit 109ec12489f050e537d26eed2e60c6d97eb7439f
Author: Tobias Koch <tobias.k...@nokia.com>
Date: Wed Sep 29 18:03:30 2010 +0300
Allow more than 6 axes to be sent.
From: Tobias Koch <tobias.k...@nokia.com>
If the number of axes exceeds 6, X server will return BadValue for
XTestFakeInput because the number of axes in a single DeviceValuator
event is incorrectly set to the total number of axes.
Signed-off-by: Tobias Koch <tobias.k...@nokia.com>
Reviewed-by: Rami Ylimäki <rami.ylim...@vincit.fi>
Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net>
diff --git a/src/XTest.c b/src/XTest.c
index 6a44e60..76193a1 100644
--- a/src/XTest.c
+++ b/src/XTest.c
@@ -265,12 +265,10 @@ send_axes(
req->length += ((n_axes + 5) / 6) * (SIZEOF(xEvent) >> 2);
ev.type = XI_DeviceValuator + (long)info->data;
ev.deviceid = dev->device_id;
- ev.num_valuators = n_axes;
ev.first_valuator = first_axis;
while (n_axes > 0) {
- n = n_axes;
- if (n > 6)
- n = 6;
+ n = n_axes > 6 ? 6 : n_axes;
+ ev.num_valuators = n;
switch (n) {
case 6:
ev.valuator5 = *(axes+5);
commit 809ceed85bb577d4bbf80f2d84382375c65b9fbe
Author: Jesse Adkins <jesserayadk...@gmail.com>
Date: Tue Sep 28 13:30:04 2010 -0700
Purge cvs tags.
Signed-off-by: Jesse Adkins <jesserayadk...@gmail.com>
Signed-off-by: Alan Coopersmith <alan.coopersm...@oracle.com>
diff --git a/include/X11/extensions/XTest.h b/include/X11/extensions/XTest.h
index aad9420..f973aeb 100644
--- a/include/X11/extensions/XTest.h
+++ b/include/X11/extensions/XTest.h
@@ -1,4 +1,3 @@
-/* $Xorg: XTest.h,v 1.5 2001/02/09 02:03:24 xorgcvs Exp $ */
/*
Copyright 1992, 1998 The Open Group
@@ -24,7 +23,6 @@ used in advertising or otherwise to promote the sale, use or
other dealings
in this Software without prior written authorization from The Open Group.
*/
-/* $XFree86: xc/include/extensions/XTest.h,v 3.3 2001/12/14 19:53:28 dawes Exp
$ */
#ifndef _XTEST_H_
#define _XTEST_H_
diff --git a/man/XTest.xml b/man/XTest.xml
index bc61337..0c33ed8 100644
--- a/man/XTest.xml
+++ b/man/XTest.xml
@@ -40,7 +40,6 @@ X Consortium.
<!-- edited for DP edits and code consistency w/ core protocol/xlib 4/2/96 -->
<!-- Converted from xorg-docs/specs/Xext/xtestlib.ms 6/6/07 -->
-<!-- $Xorg: xtestlib.ms,v 1.3 2000/08/17 19:42:37 cpqbld Exp $ -->
<refentryinfo>
<productname>__vendorversion__</productname>
<pubdate>6 June 2007</pubdate>
diff --git a/src/XRecord.c b/src/XRecord.c
index 40fbcc5..45c8b43 100644
--- a/src/XRecord.c
+++ b/src/XRecord.c
@@ -1,6 +1,4 @@
/*
-$Xorg: XRecord.c,v 1.4 2001/02/09 02:04:00 xorgcvs Exp $
-
XRecord.c - client-side library for RECORD extension
Copyright 1995, 1998 The Open Group
@@ -50,7 +48,6 @@ from The Open Group.
/*
* By Stephen Gildea, X Consortium, and Martha Zimet, NCD.
*/
-/* $XFree86: xc/lib/Xtst/XRecord.c,v 1.6 2002/10/16 00:37:33 dawes Exp $ */
#include <stdio.h>
#include <assert.h>
diff --git a/src/XTest.c b/src/XTest.c
index c04cc09..6a44e60 100644
--- a/src/XTest.c
+++ b/src/XTest.c
@@ -1,4 +1,3 @@
-/* $Xorg: XTest.c,v 1.5 2001/02/09 02:04:00 xorgcvs Exp $ */
/*
Copyright 1990, 1991 by UniSoft Group Limited
*/
@@ -30,7 +29,6 @@ other dealings in this Software without prior written
authorization
from The Open Group.
*/
-/* $XFree86: xc/lib/Xtst/XTest.c,v 1.5 2001/12/14 19:56:40 dawes Exp $ */
#include <X11/Xlibint.h>
#include <X11/extensions/XTest.h>
commit 785d8cde2d3beecfb23a9dd9b87bb0d96cf352b8
Author: Gaetan Nadon <mems...@videotron.ca>
Date: Mon Aug 16 11:40:14 2010 -0400
man: remove unused $(BUILT_SOURCES) variable
Signed-off-by: Gaetan Nadon <mems...@videotron.ca>
diff --git a/man/Makefile.am b/man/Makefile.am
index 086eac9..2597d07 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -40,7 +40,7 @@ libman_PRE = \
EXTRA_DIST = $(libman_PRE) $(libman_xml) x.stamp
-CLEANFILES = $(libman_DATA) $(BUILT_SOURCES)
+CLEANFILES = $(libman_DATA)
MAINTAINERCLEANFILES = $(libman_PRE)
commit 1dba184f586cc689a79b21b60267c72c2c0172b9
Author: Gaetan Nadon <mems...@videotron.ca>
Date: Mon Aug 16 11:30:23 2010 -0400
man: remove unused LIB_MAN_DIR_SUFFIX (part of an unrequired broken fix)
Local fix in CVS for bug 5628 is not required
as the problem has been fixed in
util-macros d9062e4077ebfd0985baf8418f3d0f111b9ddbba
Signed-off-by: Gaetan Nadon <mems...@videotron.ca>
diff --git a/man/Makefile.am b/man/Makefile.am
index e1f9a7e..086eac9 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -23,8 +23,6 @@
libmandir = $(LIB_MAN_DIR)
-LIB_MAN_DIR_SUFFIX = $(LIB_MAN_DIR:@mandir@/man%=%)
-
libman_xml = XTest.xml
libman_PRE = \
commit 601ea1309d80ba19b4e03207d6fb0f54b2f12730
Author: Alan Coopersmith <alan.coopersm...@oracle.com>
Date: Thu Jul 8 15:10:27 2010 -0700
config: Use additional man page support from util-macros 1.8
Use MAN_SUBST now supplied in XORG_MANPAGE_SECTIONS
The value of MAN_SUBST is the same for all X.Org packages.
Use AC_PROG_SED now supplied by XORG_DEFAULT_OPTIONS
The existing statement can now be removed from the configuration file.
Use automake provided $(AM_V_GEN) and XORG_DEFAULT_OPTIONS provided $(SED)
Enables silent rule and use platform appropriate version of sed.
Signed-off-by: Alan Coopersmith <alan.coopersm...@oracle.com>
diff --git a/man/Makefile.am b/man/Makefile.am
index f385bf9..e1f9a7e 100644
--- a/man/Makefile.am
+++ b/man/Makefile.am
@@ -50,24 +50,11 @@ if INSTALL_MANPAGES
libman_DATA = $(libman_PRE:m...@lib_man_suffix@)
endif
-SED = sed
-
-# Strings to replace in man pages
-XORGRELSTRING = @PACKAGE_STRING@
- XORGMANNAME = X Version 11
-
-MAN_SUBSTS = \
- -e 's/__xorgversion__/"$(XORGRELSTRING)" "$(XORGMANNAME)"/' \
- -e 's/__xservername__/Xorg/g' \
- -e 's/__xconfigfile__/xorg.conf/g' \
- -e 's/__appmansuffix__/$(APP_MAN_SUFFIX)/g' \
- -e 's/__libmansuffix__/$(LIB_MAN_SUFFIX)/g' \
- -e 's/__filemansuffix__/$(FILE_MAN_SUFFIX)/g'
-
+# String replacements in MAN_SUBSTS now come from xorg-macros.m4 via configure
SUFFIXES = .$(LIB_MAN_SUFFIX) .man
.man.$(LIB_MAN_SUFFIX):
- sed $(MAN_SUBSTS) < $< > $@
+ $(AM_V_GEN)$(SED) $(MAN_SUBSTS) < $< > $@
# This is ugly, but handling of tools with multiple outputs in make is a
# huge PITA. The commands below are taken from the automake manual:
commit 672f3ea3431c37ce8f4c33da224287861f64c2a4
Author: Fernando Carrijo <fcarr...@yahoo.com.br>
Date: Thu Jul 1 07:05:16 2010 -0300
Purge macros NEED_EVENTS and NEED_REPLIES
Signed-off-by: Fernando Carrijo <fcarr...@yahoo.com.br>
Acked-by: Tiago Vignatti <tiago.vigna...@nokia.com>
Reviewed-by: Alan Coopersmith <alan.coopersm...@oracle.com>
diff --git a/src/XRecord.c b/src/XRecord.c
index a0f7c52..40fbcc5 100644
--- a/src/XRecord.c
+++ b/src/XRecord.c
@@ -54,8 +54,6 @@ from The Open Group.
#include <stdio.h>
#include <assert.h>
-#define NEED_EVENTS
-#define NEED_REPLIES
#include <X11/Xlibint.h>
#include <X11/extensions/Xext.h>
#include <X11/extensions/extutil.h>
diff --git a/src/XTest.c b/src/XTest.c
index ed45e41..c04cc09 100644
--- a/src/XTest.c
+++ b/src/XTest.c
@@ -32,7 +32,6 @@ from The Open Group.
*/
/* $XFree86: xc/lib/Xtst/XTest.c,v 1.5 2001/12/14 19:56:40 dawes Exp $ */
-#define NEED_REPLIES
#include <X11/Xlibint.h>
#include <X11/extensions/XTest.h>
#include <X11/extensions/xtestproto.h>
commit 1676c80db40bffec416da6e3d0002ff9d37093b3
Author: Gaetan Nadon <mems...@videotron.ca>
Date: Sun Jun 27 20:45:38 2010 -0400
specs: remove trailing spaces in DocBook XML docs
Signed-off-by: Gaetan Nadon <mems...@videotron.ca>
diff --git a/specs/xtestlib.xml b/specs/xtestlib.xml
index ab41656..e177345 100644
--- a/specs/xtestlib.xml
+++ b/specs/xtestlib.xml
@@ -26,42 +26,42 @@
<legalnotice>
<para>
-Permission to use, copy, modify, and distribute this documentation for
-any purpose and without fee is hereby granted, provided that the above
-copyright notice and this permission notice appear in all copies. UniSoft
-makes no representations about the suitability for any purpose of the
-information in this document. This documentation is provided
+Permission to use, copy, modify, and distribute this documentation for
+any purpose and without fee is hereby granted, provided that the above
+copyright notice and this permission notice appear in all copies. UniSoft
+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
+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
+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 IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN
+NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
</para>
<para>
-Except as contained in this notice, the name of the X Consortium shall not
-be used in advertising or otherwise to promote the sale, use or other dealings
+Except as contained in this notice, the name of the X Consortium shall not
+be used in advertising or otherwise to promote the sale, use or other dealings
in this Software without prior written authorization from the X Consortium.
</para>
@@ -103,10 +103,10 @@ itself needs testing, where possible, and so should be as
simple as possible.
<itemizedlist mark='bullet'>
<listitem>
<para>
-Confine the extension to an appropriate high level
-within the server to minimize portability problems. In practice this
-means that the extension should be at the DIX level or use the
-DIX/DDX interface, or both. This has effects, in particular, on the
+Confine the extension to an appropriate high level
+within the server to minimize portability problems. In practice this
+means that the extension should be at the DIX level or use the
+DIX/DDX interface, or both. This has effects, in particular, on the
level at which "input synthesis" can occur.
</para>
</listitem>
@@ -132,7 +132,7 @@ Minimize performance penalties on normal server operation.
<listitem>
<para>Client Operations</para>
<para>
-These routines manipulate otherwise hidden client-side behavior.
+These routines manipulate otherwise hidden client-side behavior.
The actual implementation will depend on the details of the actual language
binding and what degree of request buffering, GContext caching, and so on, is
provided. In the C binding, defined in section 7, routines are provided
@@ -157,13 +157,13 @@ versions of its own. The remaining two requests allow
the following:
<itemizedlist>
<listitem>
<para>
-Access to an otherwise "write-only" server resource: the
+Access to an otherwise "write-only" server resource: the
cursor associated with a given window
</para>
</listitem>
<listitem>
<para>
-Perhaps most importantly, limited synthesis of input
+Perhaps most importantly, limited synthesis of input
device events, almost as if a cooperative user had moved the pointing device
or pressed a key or button.
</para>
@@ -177,14 +177,14 @@ or pressed a key or button.
<title>C Language Binding</title>
<para>
-The C functions either provide direct access to the protocol and add no
-additional semantics to those defined in section 5 or they correspond
+The C functions either provide direct access to the protocol and add no
+additional semantics to those defined in section 5 or they correspond
directly to the abstract descriptions of client operations in section 4.
</para>
<para>
-All XTEST extension functions and procedures, and all manifest constants
-and macros, will start with the string "XTest". All operations are
+All XTEST extension functions and procedures, and all manifest constants
+and macros, will start with the string "XTest". All operations are
classified as server/client (Server) or client-only (Client).
All routines that have return type Status will return nonzero for
"success" and zero for "failure." Even if the XTEST extension is
@@ -214,13 +214,13 @@ returns
<function>True</function>
if the specified display supports the XTEST extension, else
<function>False</function>
-If the extension is supported, *event_base would be set to the event number
-for the first event for this extension and *error_base would be set to the
-error number for the first error for this extension. As no errors or
-events are defined for this version of the extension, the values returned
-here are not defined (nor useful). If the extension is supported,
-*major_version and *minor_version are set to the major and minor version
-numbers of the extension supported by the display. Otherwise, none of
+If the extension is supported, *event_base would be set to the event number
+for the first event for this extension and *error_base would be set to the
+error number for the first error for this extension. As no errors or
+events are defined for this version of the extension, the values returned
+here are not defined (nor useful). If the extension is supported,
+*major_version and *minor_version are set to the major and minor version
+numbers of the extension supported by the display. Otherwise, none of
the arguments are set.
</para>
@@ -235,7 +235,7 @@ the arguments are set.
<para>If the extension is supported,
<function>XTestCompareCursorWithWindow</function>
-performs a comparison of the cursor whose ID is specified by cursor (which
+performs a comparison of the cursor whose ID is specified by cursor (which
may be
<function>None</function>
with the cursor of the window specified by window returning
@@ -254,9 +254,9 @@ zero is returned.
</funcprototype>
</funcsynopsis>
-<para>If the extension is supported,
+<para>If the extension is supported,
<function>XTestCompareCurrentCursorWithWindow</function>
-performs a comparison of the current cursor with the cursor of the specified
+performs a comparison of the current cursor with the cursor of the specified
window returning
<function>True</function>
if they are the same and
@@ -289,7 +289,7 @@ of the key with the specified keycode; otherwise, the
request is ignored.
</para>
<para>
-If the extension is supported, the simulated event will not be processed
+If the extension is supported, the simulated event will not be processed
until delay milliseconds after the request is received (if delay is
<function>CurrentTime</function>
then this is interpreted as no delay at all). No other requests from
@@ -317,7 +317,7 @@ or a
<function>ButtonRelease</function>
(if is_press is
<function>False</function>
-of the logical button numbered by the specified button; otherwise, the
+of the logical button numbered by the specified button; otherwise, the
request is ignored.
</para>
@@ -343,14 +343,14 @@ and subsequent processing of the simulated event has been
completed.
<para>If the extension is supported,
<function>XTestFakeMotionEvent</function>
-requests the server to simulate a movement of the pointer to the specified
-position (x, y) on the root window of screen_number; otherwise, the request
-is ignored. If screen_number is -1, the current screen (that the pointer
+requests the server to simulate a movement of the pointer to the specified
+position (x, y) on the root window of screen_number; otherwise, the request
+is ignored. If screen_number is -1, the current screen (that the pointer
is on) is used.
</para>
<para>
-If the extension is supported, the simulated event will not be processed
+If the extension is supported, the simulated event will not be processed
until delay milliseconds after the request is received (if delay is
<function>CurrentTime</function>
then this is interpreted as no delay at all). No other requests from
@@ -372,14 +372,14 @@ and subsequent processing of the simulated event has been
completed.
<para>
If the extension is supported,
<function>XTestFakeRelativeMotionEvent</function>
-requests the server to simulate a movement of the pointer by the specified
+requests the server to simulate a movement of the pointer by the specified
offsets (x, y) relative to the current pointer position on screen_number;
otherwise, the request is ignored. If screen_number is -1, the
current screen (that the pointer is on) is used.
</para>
<para>
-If the extension is supported, the simulated event will not be processed
+If the extension is supported, the simulated event will not be processed
until delay milliseconds after the request is received (if delay is
<function>CurrentTime</function>
then this is interpreted as no delay at all). No other requests from
@@ -399,7 +399,7 @@ and subsequent processing of the simulated event has been
completed.
<function>True</function>
then the executing client becomes impervious to server grabs. If impervious is
<function>False</function>
-then the executing client returns to the normal state of being susceptible
+then the executing client returns to the normal state of being susceptible
to server grabs.
</para>
@@ -452,17 +452,16 @@ if any requests were discarded; otherwise, it returns
<title>References</title>
<para>
-Annicchiarico, D., et al., <emphasis remap='I'>XTrap: The XTrap
+Annicchiarico, D., et al., <emphasis remap='I'>XTrap: The XTrap
Architecture</emphasis>.
Digital Equipment Corporation, July 1991.
</para>
<para>
-Drake, K. J., <emphasis remap='I'>Some Proposals for a Minimum X11
+Drake, K. J., <emphasis remap='I'>Some Proposals for a Minimum X11
Testing Extension</emphasis>.
UniSoft Ltd., June 1991.
</para>
</chapter>
</book>
-
commit 96f104f32aef56dd408afbc0d5a073f51e8f0a69
Author: Gaetan Nadon <mems...@videotron.ca>
Date: Sun Jun 27 09:29:26 2010 -0400
doc: add recordlib converted docbook xml
Signed-off-by: Gaetan Nadon <mems...@videotron.ca>
diff --git a/specs/Makefile.am b/specs/Makefile.am
index 8ba5590..fdaba22 100644
--- a/specs/Makefile.am
+++ b/specs/Makefile.am
@@ -22,7 +22,7 @@
#
if ENABLE_SPECS
-doc_sources = xtestlib.xml
+doc_sources = xtestlib.xml recordlib.xml
dist_doc_DATA = $(doc_sources)
if HAVE_XMLTO
diff --git a/specs/recordlib.xml b/specs/recordlib.xml
new file mode 100644
index 0000000..903f02a
--- /dev/null
+++ b/specs/recordlib.xml
@@ -0,0 +1,1516 @@
+<?xml version="1.0" encoding="UTF-8" ?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+ "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd";>
+
+
+<!-- lifted from troff+ms+XMan by doclifter -->
+<book id="recordlib">
+
+<bookinfo>
+ <title>X Record Extension Library</title>
+ <subtitle>X Consortium Standard</subtitle>
+ <releaseinfo>X Version 11, Release 6.7</releaseinfo>
+ <authorgroup>
+ <author>
+ <firstname>Martha</firstname><surname>Zimet</surname>
+ </author>
+ </authorgroup>
+ <corpname>Network Computing Devices, Inc.</corpname>
+ <copyright><year>1994</year><holder>Network Computing Devices,
Inc.</holder></copyright>
+ <copyright><year>1995</year><holder>X Consortium</holder></copyright>
+ <releaseinfo>Version 1.13</releaseinfo>
+ <affiliation><orgname>X Consortium</orgname></affiliation>
+ <productnumber>X Version 11, Release 6.7</productnumber>
+ <editor>
+ <firstname>Stephen</firstname><surname>Gildea</surname>
+ <affiliation><orgname>X Consortium</orgname></affiliation>
+ </editor>
+
+<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 SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR
+OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+OTHER DEALINGS IN THE SOFTWARE.
+</para>
+
+<para>
+Except as contained in this notice, the name of the X Consortium shall
+not be used in advertising or otherwise to promote the sale, use or other
+dealings in this Software without prior written authorization from the
+X Consortium.
+</para>
+
+<para>X Window System is a trademark of The Open Group.</para>
+</legalnotice>
+</bookinfo>
+
+<chapter id="record_extension_overview">
+<title>Record Extension Overview</title>
+<para>
+The purpose of this extension is to support the recording and reporting of
+all core X protocol and arbitrary X extension protocol. This first section
+gives an overview of the Record extension. The following sections describe
+how to use the Record extension library.
+</para>
+
+<sect1 id="synchronous_playback">
+<title>Synchronous Playback</title>
+<para>
+Environment information is generally provided to an X-based playback
+mechanism, which might use the XTest extension to synthesize input
+events. This synchronization information defines the X state prior to
+event synthesis (for example, location of the cursor, window locations
+and sizes, installed colormap, window manager running, and so on) and
+the consequences that occur after the playback mechanism synthesizes
+the event. If the user moves the mouse into the icon window and presses
+and releases a mouse button, the device events
+<function>MotionNotify</function>, <function>ButtonPress</function>,
+and <function>ButtonRelease</function> are generated by the X server.
+Because X follows an
+event-driven model, there are consequences that follow from the user
+actions, or device events, that are in the form of X protocol. As a result
+of the previous user actions, the client could generate requests such as
+<function>ImageText8</function> and <function>PolyLine</function> to the
+X server, or the X server could send non-device events such as
+<function>Expose</function> and <function>MapNotify</function> to the
+client window. Both the
+requests and non-device events that result from user actions are known
+as consequences, which can be used as a synchronization, or control point,
+during playback. That is, the playback mechanism does not generate a specific
+synthesized event until its matching synchronization condition occurs
+(for example, the window is mapped or unmapped, the cursor changes, a text
+string displays, and so on)
+</para>
+<para>
+Because it cannot be predicted what synchronization information is required
+during playback, the Record extension makes no assumptions about the intended
+use of the recorded data. Facilities exist to record any core X protocol or
+X extension protocol. Therefore, Record does not enforce a specific
+synchronization methodology.
+</para>
+</sect1>
+
+<sect1 id="design_approach">
+<title>Design Approach</title>
+<para>
+The design approach of the extension is to record core X protocol and
+arbitrary X extension protocol entirely within the X server itself. When
+the extension has been requested to record specific protocol by one or more
+recording clients, the protocol data is formatted and returned to the
+recording clients. The extension provides a mechanism for capturing all
+events, including input device events that do not go to any clients.
+</para>
+</sect1>
+
+<sect1 id="record_clients">
+<title>Record Clients</title>
+<para>
+The recommended communication model for a Record application is to open two
+connections to the server—one connection for recording control and one
+connection for reading recorded protocol data.
+</para>
+<para>
+Information about recording (for example, what clients to record, what
+protocol to record for each client, and so on) is stored in resources
+called record contexts (type <function>XRecordContext</function>). Most
+Record extension functions take a record context as an argument. Although
+in theory it is possible to share record contexts between applications,
+it is expected that applications will use their own context when performing
+recording operations.
+</para>
+<para>
+A client that wishes to record X protocol does so through the library
+functions defined in
+<link linkend="library_extension_requests">
+<xref linkend="library_extension_requests"></xref></link>
+A typical sequence of requests that a client would make is as follows:
+</para>
+<itemizedlist>
+ <listitem>
+ <para>
+<function>XRecordQueryVersion</function>
+ </para>
+ <para>
+query the extension protocol version.
+ </para>
+</listitem>
+<listitem>
+ <para>
+<function>XRecordCreateContext</function>
+ </para>
+ <para>
+request that the server create a record context for access by this client,
+and express interest in clients and protocol to be recorded. This request
+returns an <function>XRecord-Context</function>, which is an XID that is
+used by most other extension requests to identify the specified context.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<function>XRecordEnableContext</function>
+ </para>
+ <para>
+begin the recording and reporting of protocol data.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<function>XRecordDisableContext</function>
+ </para>
+ <para>
+end the recording and reporting of protocol data.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+<function>XRecordFreeContext</function>
+ </para>
+ <para>
+free the record context.
+ </para>
+ </listitem>
+</itemizedlist>
+
+<para>
+The header for this library is
+<<function>X11/extensions/record.h</function>>. All identifiers defined
+in the interface are supplied by this header and are prefixed with "XRecord".
+The <function>Xtst</function> library contains the
+<function>XRecord</function> functions.
+</para>
+
+</sect1>
+</chapter>
+
+<chapter id="common_arguments">
+<title>Common Arguments</title>
+<para>
+The Record extension functions <function>XRecordCreateContext</function>
+ and <function>XRecordRegisterClients</function> allow applications to
+specify the following:
+</para>
+<itemizedlist>
+ <listitem>
+ <para>
+Individual clients or sets of clients to record
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+Ranges of core X protocol and X extension protocol to record for each client
+ </para>
+ </listitem>
+</itemizedlist>
+<para>
+Protocol in the ranges specified by the recording client will be recorded
+by the server. The device_events protocol type can be specified by a
+recording client although it may not be sent to a recorded client. The
+device_events type differs from delivered_events, which also can be
+specified by a recording client; delivered_events are actually delivered to
+one or more clients. These event types are discussed in
+<link linkend="protocol_ranges">
+<xref linkend="protocol_ranges"></xref></link>
+</para>
+
+
+<para>
+The Record extension functions <function>XRecordCreateContext</function>
+ and <function>XRecordRegisterClients</function> have the common arguments
+datum_flags, clients, and ranges, which specify whether server time
+and/or client sequence number should precede protocol elements, the
+clients or client set to record, and the protocol ranges to record,
+respectively. These are discussed in the following sections.
+</para>
+
+<sect1 id="datum_flags">
+<title>Datum Flags</title>
+<para>
+The datum_flags argument is a set of flags OR’ed together to specify options
+for the record context. Specify zero to disable all the options.
+</para>
+
+<para>
+The <function>XRecordFromServerTime</function> flag specifies that
+<function>XRecordInterceptData</function> structures with a category of
+<function>XRecordFromServer</function> will have a server_time field specific
to each
+protocol element.
+</para>
+
+<para>
+The <function>XRecordFromClientTime</function> flag specifies that
+<function>XRecordInterceptData</function> structures with a category of
+<function>XRecordFromClient</function> will have a server_time field specific
+to each protocol element.
+</para>
+
+<para>
+The <function>XRecordFromClientSequence</function> flag specifies that
+<function>XRecordInterceptData</function> structures with a category of
+<function>XRecordFromClient</function> or
+<function>XRecordClientDied</function> will have a valid client_seq field.
+</para>
+</sect1>
+
+<sect1 id="selecting_clients">
+<title>Selecting Clients</title>
+
+<para>
+The clients argument is a pointer to an array of
+<function>XRecordClientSpec</function>.
+<function>XRecordClientSpec</function> is an integral type that holds a
+resource ID, a client resource ID base, or one of the client set constants
+defined below.
+</para>
+<para>
+Duplicate elements in the array are ignored by the functions, and if any
+element in the array is not valid, a
+<function>BadMatch</function>
+error results. A resource ID references the client that created that
+resource. The client set may be one of the following constants:
+<function>XRecordCurrentClients</function>,
+<function>XRecordFutureClients</function>, or
+<function>XRecordAllClients</function>.
+</para>
+<para>
+If the element in the array identifies a particular client, protocol
+specified by the ranges argument will be recorded by the server. The
+recorded protocol data will not be returned to the recording client until
+the record context has been enabled. This is described in
+<link linkend="data_transfer">
+<xref linkend="data_transfer"></xref></link>
+</para>
+<para>
+If the element is <function>XRecordCurrentClients</function>, the protocol
+ranges specified by the ranges argument, except for device_events, are
+associated with each current client connection. If the element is
+<function>XRecordFutureClients</function>, the
+protocol ranges specified by the ranges argument are associated with each new
+client connection. If the element is
+<function>XRecordAllClients</function>,
+the protocol ranges specified by the ranges argument are associated with
+each current client connection and with each new client connection.
+When the context is enabled, the data connection is unregistered if it
+was registered. If the context is enabled,
+<function>XRecordCurrentClients</function> and
+<function>XRecordAllClients</function>
+silently exclude the recording data connection. It is an error to explicitly
+register the data connection.
+</para>
+</sect1>
+<sect1 id="protocol_ranges">
+<title>Protocol Ranges</title>
+
+<para>
+The functions <function>XRecordCreateContext</function> and
+<function>XRecordRegisterClients</function> have another common argument,
+ranges, which is an array of pointers to <function>XRecordRange</function>
+structures. Each structure contains ranges of numeric values for each of
+the protocol types that can be specified and recorded individually by the
+Record extension. An <function>XRecordRange</function> structure must be
+allocated by the Record library using the
+<function>XRecordAllocRange</function> function.
+</para>
+<para>
+The <function>XRecordRange</function> typedef is a structure with the
+following members:
+</para>
+
+<literallayout remap='Ds'>
+XRecordRange:
+ XRecordRange8 core_requests /* core X requests */
+ XRecordRange8 core_replies /* core X replies */
+ XRecordExtRange ext_requests /* extension requests */
+ XRecordExtRange ext_replies /* extension replies */
+ XRecordRange8 delivered_events /* delivered core and ext events */
+ XRecordRange8 device_events /* all core and ext device events */
+ XRecordRange8 errors /* core X and X ext errors */
+ Bool client_started /* connection setup reply from server */
+ Bool client_died /* notification of client disconnect */
+</literallayout>
+
+<para>
+The types used in
+<function>XRecordRange</function>
+members are defined as follows. The
+<function>XRecordRange8</function>
+typedef is a structure with the following members:
+</para>
+
+<literallayout remap='Ds'>
+XRecordRange8:
+ unsigned char first
+ unsigned char last
+</literallayout>
+
+<para>
+The
+<function>XRecordRange16</function>
+typedef is a structure with the following members:
+</para>
+
+<literallayout remap='Ds'>
+XRecordRange16:
+ unsigned short first
+ unsigned short last
+</literallayout>
+
+<para>
+The
+<function>XRecordExtRange</function>
+typedef is a structure with the following members:
+</para>
+
+<literallayout remap='Ds'>
+XRecordExtRange:
+ XRecordRange8 ext_major
+ XRecordRange16 ext_minor
+</literallayout>
+
+<para>
+If any of the values specified in
+<function>XRecordRange</function>
+is invalid, a
+<function>BadValue</function>
+error results.
+</para>
+
+<para>
+The core_requests member specifies the range of core X protocol
+requests to record. Core X protocol requests with a major opcode
+that is between first and last, inclusive, will be
+recorded. A
+<function>BadValue</function>
+error results if the value of first is greater than the value of last.
+If the values of both first and last are zero, no core
+X protocol requests will be recorded.
+</para>
+
+<para>
+The core_replies member specifies the range of replies resulting
+from core X protocol requests to record. Replies that result from
+core X protocol requests with a major opcode between first
+and last, inclusive, will be recorded. A
+<function>BadValue</function>
+error results if the value of first is greater than the value of last.
+If the values of both first and last are zero, no core X protocol
+replies will be recorded.
+</para>
+
+<para>
+The ext_requests member specifies the range of X extension
+requests to record. X extension requests with a major opcode
+between ext_major.first and ext_major.last, and with a
+minor opcode
+between ext_minor.first and ext_minor.last, inclusive, will be
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1pjro6-0005ww...@alioth.debian.org
