Update to xextproto 7.2.0
This commit is contained in:
matthieu
parent
38a45bf16e
commit
60ad3b3855
@ -1,3 +1,197 @@
|
||||
commit c593fd1000ceb83f0933361c5e7496d799233f7e
|
||||
Author: Keith Packard <keithp@keithp.com>
|
||||
Date: Sat Feb 26 23:57:48 2011 -0800
|
||||
|
||||
Version 7.2.0
|
||||
|
||||
Signed-off-by: Keith Packard <keithp@keithp.com>
|
||||
|
||||
commit a6a542841e85344115bbb6a1ba35c4f3487995e4
|
||||
Author: Gaetan Nadon <memsize@videotron.ca>
|
||||
Date: Fri Feb 25 08:53:55 2011 -0500
|
||||
|
||||
Docbook: change the book id to match the xml file basename
|
||||
|
||||
This is required for the up-coming external references support.
|
||||
|
||||
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
|
||||
|
||||
commit d16788e87438015d3e121ffb046bc6a4ce01da89
|
||||
Author: Gaetan Nadon <memsize@videotron.ca>
|
||||
Date: Fri Feb 25 08:51:47 2011 -0500
|
||||
|
||||
Docbook: change the book id to match the xml file basename
|
||||
|
||||
This is required for the up-coming external references support.
|
||||
|
||||
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
|
||||
|
||||
commit 8c6cc9ddb5776a2b32d42a41d27b3df56e62c44f
|
||||
Author: Gaetan Nadon <memsize@videotron.ca>
|
||||
Date: Thu Feb 24 20:44:00 2011 -0500
|
||||
|
||||
Docbook: change the book id to match the xml file basename
|
||||
|
||||
Rename appgroup.xml as it conflicts with xorg-docs/specs/Xserver/appgroup.xml
|
||||
This is required for the up-coming external references support.
|
||||
|
||||
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
|
||||
|
||||
commit 9df8b77604b7ea7132d32f65f2280720b91249c1
|
||||
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
Date: Thu Dec 16 23:54:45 2010 -0800
|
||||
|
||||
specs: Fix section titles/nesting
|
||||
|
||||
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
|
||||
commit 6aa72ae8e629e065f09a6b6c05504363806d76a3
|
||||
Author: Paulo Zanoni <pzanoni@mandriva.com>
|
||||
Date: Tue Dec 14 16:23:56 2010 -0200
|
||||
|
||||
Use the same docbookx.dtd version (4.3) for all docs
|
||||
|
||||
This way we don't need to require 4.1.2 and 4.5
|
||||
The geproto xml was inconsistent, by the way.
|
||||
|
||||
Signed-off-by: Paulo Zanoni <pzanoni@mandriva.com>
|
||||
Reviewed-by: Matt Dew <matt@osource.org>
|
||||
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
|
||||
commit 77c2b72d8df53e918b0fbff5425af82ac7f5693a
|
||||
Author: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
Date: Thu Dec 9 17:43:29 2010 -0800
|
||||
|
||||
specs/sync.xml: Fix minor typos in document title section
|
||||
|
||||
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
|
||||
commit b4e8a6fb63715442b4927d18d9cdd7ee78e50d00
|
||||
Author: James Jones <jajones@nvidia.com>
|
||||
Date: Mon Nov 29 09:35:50 2010 -0800
|
||||
|
||||
Bump version to 7.1.99.0
|
||||
|
||||
Use version 7.1.99.0 to mark the inclusion of
|
||||
Fence Sync protocol support.
|
||||
|
||||
Signed-off-by: James Jones <jajones@nvidia.com>
|
||||
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
|
||||
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
|
||||
commit 6e696a0a4c9a115c7f080c2bdee3d8afc16b134f
|
||||
Author: James Jones <jajones@nvidia.com>
|
||||
Date: Wed Feb 24 15:57:29 2010 -0800
|
||||
|
||||
Add protocol for XSyncAwaitFence()
|
||||
|
||||
Add the fence sync object equivalent of
|
||||
XSyncAwait()
|
||||
|
||||
Signed-off-by: James Jones <jajones@nvidia.com>
|
||||
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
|
||||
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
|
||||
commit 220b824f20dc3dd0fd6eae6e2896fb63aefbf11a
|
||||
Author: James Jones <jajones@nvidia.com>
|
||||
Date: Mon Feb 22 17:01:16 2010 -0800
|
||||
|
||||
Add XSyncQueryFence()
|
||||
|
||||
Allows callers to query whether a given fence sync
|
||||
object is currently triggered or not.
|
||||
|
||||
Signed-off-by: James Jones <jajones@nvidia.com>
|
||||
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
|
||||
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
|
||||
commit d079ee210726d2407fa9c8cf99555daf2d96023a
|
||||
Author: James Jones <jajones@nvidia.com>
|
||||
Date: Fri Feb 12 16:38:08 2010 -0800
|
||||
|
||||
Initial Fence Sync support
|
||||
|
||||
Defines the protocol for creation and basic
|
||||
management of binary state sync objects.
|
||||
The following operations are defined:
|
||||
|
||||
-Creation
|
||||
-Destruction
|
||||
-Trigger
|
||||
-Reset
|
||||
|
||||
Signed-off-by: James Jones <jajones@nvidia.com>
|
||||
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
|
||||
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
|
||||
commit 9ba2065b63ea0e61a17b8221ad454c02a1755373
|
||||
Author: James Jones <jajones@nvidia.com>
|
||||
Date: Wed Aug 11 15:03:59 2010 -0700
|
||||
|
||||
Document changes in XSync version 3.1
|
||||
|
||||
Signed-off-by: James Jones <jajones@nvidia.com>
|
||||
Reviewed-by: Pierre-Loup Griffais <pgriffais@nvidia.com>
|
||||
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
|
||||
Reviewed-by: Robert Morell <rmorell@nvidia.com>
|
||||
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
|
||||
commit fd8a26edefc53b370c554a60c75ff32fc60b99c8
|
||||
Author: Gaetan Nadon <memsize@videotron.ca>
|
||||
Date: Tue Nov 30 09:05:07 2010 -0500
|
||||
|
||||
specs: add low bandwith spec from xorg-docs
|
||||
|
||||
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
|
||||
|
||||
commit 3102665110846af5c87792b221e1ef6a9dc1a0e2
|
||||
Author: Matt Dew <matt@osource.org>
|
||||
Date: Mon Nov 29 16:29:44 2010 -0500
|
||||
|
||||
specs: add appgroup specs in DocBook/XML format
|
||||
|
||||
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
|
||||
|
||||
commit f6ee80371c4bf9ebd99418a4328a351186ac0847
|
||||
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 6fbb74bfe75adc7cfd6d4bc642d7d4179a3db17d
|
||||
Author: Jesse Adkins <jesserayadkins@gmail.com>
|
||||
Date: Tue Sep 28 13:30:04 2010 -0700
|
||||
|
||||
Purge cvs tags.
|
||||
|
||||
Signed-off-by: Jesse Adkins <jesserayadkins@gmail.com>
|
||||
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
|
||||
|
||||
commit 5508eec058c0ffbb180f3d98f8a02083d6de428b
|
||||
Author: Gaetan Nadon <memsize@videotron.ca>
|
||||
Date: Thu Sep 9 16:41:21 2010 -0400
|
||||
|
||||
Remove the appgroup specs which is the one for the server side.
|
||||
|
||||
The spec for the protocol side is still in Framemaker format.
|
||||
See doc/xorg-docs/specs/Xext/AppGroup.mif
|
||||
|
||||
Signed-off-by: Gaetan Nadon <memsize@videotron.ca>
|
||||
|
||||
commit 5daf9cff36df7423f6247fc8174b8e6c9443ed07
|
||||
Author: Adam Jackson <ajax@redhat.com>
|
||||
Date: Tue Aug 10 10:24:51 2010 -0400
|
||||
|
||||
xextproto 7.1.2
|
||||
|
||||
Signed-off-by: Adam Jackson <ajax@redhat.com>
|
||||
|
||||
commit 35741d9dc745532dc4af37cc07e256392e3880da
|
||||
Author: Gaetan Nadon <memsize@videotron.ca>
|
||||
Date: Tue Aug 3 11:03:49 2010 -0400
|
||||
|
||||
291
proto/xextproto/INSTALL
Normal file
291
proto/xextproto/INSTALL
Normal file
@ -0,0 +1,291 @@
|
||||
Installation Instructions
|
||||
*************************
|
||||
|
||||
Copyright (C) 1994, 1995, 1996, 1999, 2000, 2001, 2002, 2004, 2005,
|
||||
2006, 2007, 2008 Free Software Foundation, Inc.
|
||||
|
||||
This file is free documentation; the Free Software Foundation gives
|
||||
unlimited permission to copy, distribute and modify it.
|
||||
|
||||
Basic Installation
|
||||
==================
|
||||
|
||||
Briefly, the shell commands `./configure; make; make install' should
|
||||
configure, build, and install this package. The following
|
||||
more-detailed instructions are generic; see the `README' file for
|
||||
instructions specific to this package.
|
||||
|
||||
The `configure' shell script attempts to guess correct values for
|
||||
various system-dependent variables used during compilation. It uses
|
||||
those values to create a `Makefile' in each directory of the package.
|
||||
It may also create one or more `.h' files containing system-dependent
|
||||
definitions. Finally, it creates a shell script `config.status' that
|
||||
you can run in the future to recreate the current configuration, and a
|
||||
file `config.log' containing compiler output (useful mainly for
|
||||
debugging `configure').
|
||||
|
||||
It can also use an optional file (typically called `config.cache'
|
||||
and enabled with `--cache-file=config.cache' or simply `-C') that saves
|
||||
the results of its tests to speed up reconfiguring. Caching is
|
||||
disabled by default to prevent problems with accidental use of stale
|
||||
cache files.
|
||||
|
||||
If you need to do unusual things to compile the package, please try
|
||||
to figure out how `configure' could check whether to do them, and mail
|
||||
diffs or instructions to the address given in the `README' so they can
|
||||
be considered for the next release. If you are using the cache, and at
|
||||
some point `config.cache' contains results you don't want to keep, you
|
||||
may remove or edit it.
|
||||
|
||||
The file `configure.ac' (or `configure.in') is used to create
|
||||
`configure' by a program called `autoconf'. You need `configure.ac' if
|
||||
you want to change it or regenerate `configure' using a newer version
|
||||
of `autoconf'.
|
||||
|
||||
The simplest way to compile this package is:
|
||||
|
||||
1. `cd' to the directory containing the package's source code and type
|
||||
`./configure' to configure the package for your system.
|
||||
|
||||
Running `configure' might take a while. While running, it prints
|
||||
some messages telling which features it is checking for.
|
||||
|
||||
2. Type `make' to compile the package.
|
||||
|
||||
3. Optionally, type `make check' to run any self-tests that come with
|
||||
the package.
|
||||
|
||||
4. Type `make install' to install the programs and any data files and
|
||||
documentation.
|
||||
|
||||
5. You can remove the program binaries and object files from the
|
||||
source code directory by typing `make clean'. To also remove the
|
||||
files that `configure' created (so you can compile the package for
|
||||
a different kind of computer), type `make distclean'. There is
|
||||
also a `make maintainer-clean' target, but that is intended mainly
|
||||
for the package's developers. If you use it, you may have to get
|
||||
all sorts of other programs in order to regenerate files that came
|
||||
with the distribution.
|
||||
|
||||
6. Often, you can also type `make uninstall' to remove the installed
|
||||
files again.
|
||||
|
||||
Compilers and Options
|
||||
=====================
|
||||
|
||||
Some systems require unusual options for compilation or linking that
|
||||
the `configure' script does not know about. Run `./configure --help'
|
||||
for details on some of the pertinent environment variables.
|
||||
|
||||
You can give `configure' initial values for configuration parameters
|
||||
by setting variables in the command line or in the environment. Here
|
||||
is an example:
|
||||
|
||||
./configure CC=c99 CFLAGS=-g LIBS=-lposix
|
||||
|
||||
*Note Defining Variables::, for more details.
|
||||
|
||||
Compiling For Multiple Architectures
|
||||
====================================
|
||||
|
||||
You can compile the package for more than one kind of computer at the
|
||||
same time, by placing the object files for each architecture in their
|
||||
own directory. To do this, you can use GNU `make'. `cd' to the
|
||||
directory where you want the object files and executables to go and run
|
||||
the `configure' script. `configure' automatically checks for the
|
||||
source code in the directory that `configure' is in and in `..'.
|
||||
|
||||
With a non-GNU `make', it is safer to compile the package for one
|
||||
architecture at a time in the source code directory. After you have
|
||||
installed the package for one architecture, use `make distclean' before
|
||||
reconfiguring for another architecture.
|
||||
|
||||
On MacOS X 10.5 and later systems, you can create libraries and
|
||||
executables that work on multiple system types--known as "fat" or
|
||||
"universal" binaries--by specifying multiple `-arch' options to the
|
||||
compiler but only a single `-arch' option to the preprocessor. Like
|
||||
this:
|
||||
|
||||
./configure CC="gcc -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
|
||||
CXX="g++ -arch i386 -arch x86_64 -arch ppc -arch ppc64" \
|
||||
CPP="gcc -E" CXXCPP="g++ -E"
|
||||
|
||||
This is not guaranteed to produce working output in all cases, you
|
||||
may have to build one architecture at a time and combine the results
|
||||
using the `lipo' tool if you have problems.
|
||||
|
||||
Installation Names
|
||||
==================
|
||||
|
||||
By default, `make install' installs the package's commands under
|
||||
`/usr/local/bin', include files under `/usr/local/include', etc. You
|
||||
can specify an installation prefix other than `/usr/local' by giving
|
||||
`configure' the option `--prefix=PREFIX'.
|
||||
|
||||
You can specify separate installation prefixes for
|
||||
architecture-specific files and architecture-independent files. If you
|
||||
pass the option `--exec-prefix=PREFIX' to `configure', the package uses
|
||||
PREFIX as the prefix for installing programs and libraries.
|
||||
Documentation and other data files still use the regular prefix.
|
||||
|
||||
In addition, if you use an unusual directory layout you can give
|
||||
options like `--bindir=DIR' to specify different values for particular
|
||||
kinds of files. Run `configure --help' for a list of the directories
|
||||
you can set and what kinds of files go in them.
|
||||
|
||||
If the package supports it, you can cause programs to be installed
|
||||
with an extra prefix or suffix on their names by giving `configure' the
|
||||
option `--program-prefix=PREFIX' or `--program-suffix=SUFFIX'.
|
||||
|
||||
Optional Features
|
||||
=================
|
||||
|
||||
Some packages pay attention to `--enable-FEATURE' options to
|
||||
`configure', where FEATURE indicates an optional part of the package.
|
||||
They may also pay attention to `--with-PACKAGE' options, where PACKAGE
|
||||
is something like `gnu-as' or `x' (for the X Window System). The
|
||||
`README' should mention any `--enable-' and `--with-' options that the
|
||||
package recognizes.
|
||||
|
||||
For packages that use the X Window System, `configure' can usually
|
||||
find the X include and library files automatically, but if it doesn't,
|
||||
you can use the `configure' options `--x-includes=DIR' and
|
||||
`--x-libraries=DIR' to specify their locations.
|
||||
|
||||
Particular systems
|
||||
==================
|
||||
|
||||
On HP-UX, the default C compiler is not ANSI C compatible. If GNU
|
||||
CC is not installed, it is recommended to use the following options in
|
||||
order to use an ANSI C compiler:
|
||||
|
||||
./configure CC="cc -Ae"
|
||||
|
||||
and if that doesn't work, install pre-built binaries of GCC for HP-UX.
|
||||
|
||||
On OSF/1 a.k.a. Tru64, some versions of the default C compiler cannot
|
||||
parse its `<wchar.h>' header file. The option `-nodtk' can be used as
|
||||
a workaround. If GNU CC is not installed, it is therefore recommended
|
||||
to try
|
||||
|
||||
./configure CC="cc"
|
||||
|
||||
and if that doesn't work, try
|
||||
|
||||
./configure CC="cc -nodtk"
|
||||
|
||||
Specifying the System Type
|
||||
==========================
|
||||
|
||||
There may be some features `configure' cannot figure out
|
||||
automatically, but needs to determine by the type of machine the package
|
||||
will run on. Usually, assuming the package is built to be run on the
|
||||
_same_ architectures, `configure' can figure that out, but if it prints
|
||||
a message saying it cannot guess the machine type, give it the
|
||||
`--build=TYPE' option. TYPE can either be a short name for the system
|
||||
type, such as `sun4', or a canonical name which has the form:
|
||||
|
||||
CPU-COMPANY-SYSTEM
|
||||
|
||||
where SYSTEM can have one of these forms:
|
||||
|
||||
OS KERNEL-OS
|
||||
|
||||
See the file `config.sub' for the possible values of each field. If
|
||||
`config.sub' isn't included in this package, then this package doesn't
|
||||
need to know the machine type.
|
||||
|
||||
If you are _building_ compiler tools for cross-compiling, you should
|
||||
use the option `--target=TYPE' to select the type of system they will
|
||||
produce code for.
|
||||
|
||||
If you want to _use_ a cross compiler, that generates code for a
|
||||
platform different from the build platform, you should specify the
|
||||
"host" platform (i.e., that on which the generated programs will
|
||||
eventually be run) with `--host=TYPE'.
|
||||
|
||||
Sharing Defaults
|
||||
================
|
||||
|
||||
If you want to set default values for `configure' scripts to share,
|
||||
you can create a site shell script called `config.site' that gives
|
||||
default values for variables like `CC', `cache_file', and `prefix'.
|
||||
`configure' looks for `PREFIX/share/config.site' if it exists, then
|
||||
`PREFIX/etc/config.site' if it exists. Or, you can set the
|
||||
`CONFIG_SITE' environment variable to the location of the site script.
|
||||
A warning: not all `configure' scripts look for a site script.
|
||||
|
||||
Defining Variables
|
||||
==================
|
||||
|
||||
Variables not defined in a site shell script can be set in the
|
||||
environment passed to `configure'. However, some packages may run
|
||||
configure again during the build, and the customized values of these
|
||||
variables may be lost. In order to avoid this problem, you should set
|
||||
them in the `configure' command line, using `VAR=value'. For example:
|
||||
|
||||
./configure CC=/usr/local2/bin/gcc
|
||||
|
||||
causes the specified `gcc' to be used as the C compiler (unless it is
|
||||
overridden in the site shell script).
|
||||
|
||||
Unfortunately, this technique does not work for `CONFIG_SHELL' due to
|
||||
an Autoconf bug. Until the bug is fixed you can use this workaround:
|
||||
|
||||
CONFIG_SHELL=/bin/bash /bin/bash ./configure CONFIG_SHELL=/bin/bash
|
||||
|
||||
`configure' Invocation
|
||||
======================
|
||||
|
||||
`configure' recognizes the following options to control how it
|
||||
operates.
|
||||
|
||||
`--help'
|
||||
`-h'
|
||||
Print a summary of all of the options to `configure', and exit.
|
||||
|
||||
`--help=short'
|
||||
`--help=recursive'
|
||||
Print a summary of the options unique to this package's
|
||||
`configure', and exit. The `short' variant lists options used
|
||||
only in the top level, while the `recursive' variant lists options
|
||||
also present in any nested packages.
|
||||
|
||||
`--version'
|
||||
`-V'
|
||||
Print the version of Autoconf used to generate the `configure'
|
||||
script, and exit.
|
||||
|
||||
`--cache-file=FILE'
|
||||
Enable the cache: use and save the results of the tests in FILE,
|
||||
traditionally `config.cache'. FILE defaults to `/dev/null' to
|
||||
disable caching.
|
||||
|
||||
`--config-cache'
|
||||
`-C'
|
||||
Alias for `--cache-file=config.cache'.
|
||||
|
||||
`--quiet'
|
||||
`--silent'
|
||||
`-q'
|
||||
Do not print messages saying which checks are being made. To
|
||||
suppress all normal output, redirect it to `/dev/null' (any error
|
||||
messages will still be shown).
|
||||
|
||||
`--srcdir=DIR'
|
||||
Look for the package's source code in directory DIR. Usually
|
||||
`configure' can determine that directory automatically.
|
||||
|
||||
`--prefix=DIR'
|
||||
Use DIR as the installation prefix. *Note Installation Names::
|
||||
for more details, including other options available for fine-tuning
|
||||
the installation locations.
|
||||
|
||||
`--no-create'
|
||||
`-n'
|
||||
Run the configure checks, but stop before creating any output
|
||||
files.
|
||||
|
||||
`configure' also accepts some other, not widely useful, options. Run
|
||||
`configure --help' for more details.
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
AC_PREREQ([2.60])
|
||||
AC_INIT([XExtProto], [7.1.2], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
|
||||
AC_INIT([XExtProto], [7.2.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
|
||||
AM_INIT_AUTOMAKE([foreign dist-bzip2])
|
||||
AM_MAINTAINER_MODE
|
||||
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
/* $XFree86: xc/include/extensions/shmstr.h,v 3.3 2001/12/14 19:53:29 dawes Exp $ */
|
||||
/************************************************************
|
||||
|
||||
Copyright 1989, 1998 The Open Group
|
||||
@ -30,8 +29,6 @@ in this Software without prior written authorization from The Open Group.
|
||||
#ifndef _SHMSTR_H_
|
||||
#define _SHMSTR_H_
|
||||
|
||||
/* $Xorg: shmstr.h,v 1.4 2001/02/09 02:03:24 xorgcvs Exp $ */
|
||||
|
||||
#include <X11/extensions/shmproto.h>
|
||||
|
||||
#ifdef _XSHM_SERVER_
|
||||
|
||||
@ -23,11 +23,12 @@
|
||||
|
||||
if ENABLE_SPECS
|
||||
doc_sources = \
|
||||
appgroup.xml \
|
||||
appgrp.xml \
|
||||
dbe.xml \
|
||||
dpms.xml \
|
||||
evi.xml \
|
||||
geproto.xml \
|
||||
lbx.xml \
|
||||
multibuf.xml \
|
||||
security.xml \
|
||||
shape.xml \
|
||||
@ -36,7 +37,7 @@ doc_sources = \
|
||||
tog-cup.xml \
|
||||
xtest.xml
|
||||
|
||||
dist_doc_DATA = $(doc_sources)
|
||||
dist_doc_DATA = $(doc_sources) appendix.xml
|
||||
|
||||
if HAVE_XMLTO
|
||||
doc_DATA = $(doc_sources:.xml=.html)
|
||||
@ -50,27 +51,24 @@ doc_DATA += $(doc_sources:.xml=.txt)
|
||||
endif
|
||||
|
||||
if HAVE_STYLESHEETS
|
||||
XMLTO_FLAGS = -m $(XSL_STYLESHEET)
|
||||
|
||||
doc_DATA += xorg.css
|
||||
xorg.css: $(STYLESHEET_SRCDIR)/xorg.css
|
||||
$(AM_V_GEN)cp -pf $(STYLESHEET_SRCDIR)/xorg.css $@
|
||||
XMLTO_FLAGS = -m $(XSL_STYLESHEET) \
|
||||
--stringparam html.stylesheet=$(STYLESHEET_SRCDIR)/xorg.css
|
||||
endif
|
||||
|
||||
CLEANFILES = $(doc_DATA)
|
||||
|
||||
SUFFIXES = .xml .ps .pdf .txt .html
|
||||
|
||||
.xml.txt:
|
||||
%.txt: %.xml $(dist_doc_DATA)
|
||||
$(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) txt $<
|
||||
|
||||
.xml.html:
|
||||
%.html: %.xml $(dist_doc_DATA)
|
||||
$(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) xhtml-nochunks $<
|
||||
|
||||
.xml.pdf:
|
||||
%.pdf: %.xml $(dist_doc_DATA)
|
||||
$(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop pdf $<
|
||||
|
||||
.xml.ps:
|
||||
%.ps: %.xml $(dist_doc_DATA)
|
||||
$(AM_V_GEN)$(XMLTO) $(XMLTO_FLAGS) --with-fop ps $<
|
||||
|
||||
endif HAVE_XMLTO
|
||||
|
||||
61
proto/xextproto/specs/appendix.xml
Normal file
61
proto/xextproto/specs/appendix.xml
Normal file
@ -0,0 +1,61 @@
|
||||
<?xml version="1.0" encoding="UTF-8" ?>
|
||||
<!DOCTYPE appendix
|
||||
PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
|
||||
<appendix id='system_window_encodings'>
|
||||
<title>System Window Encodings</title>
|
||||
|
||||
<para>
|
||||
The AppGroupCreateAssoc request has the following possible variations:
|
||||
</para>
|
||||
|
||||
<literallayout>
|
||||
<emphasis role='bold'>AppGroupCreateAssoc (X11)</emphasis>
|
||||
1 CARD8 opcode
|
||||
1 6 XC-APPGROUP opcode
|
||||
2 n length
|
||||
4 WINDOW window
|
||||
2 0 window_type
|
||||
2 4 system_window_len
|
||||
4 WINDOW Window
|
||||
</literallayout>
|
||||
|
||||
<literallayout>
|
||||
<emphasis role='bold'>AppGroupCreateAssoc (Macintosh)</emphasis>
|
||||
1 CARD8 opcode
|
||||
1 6 XC-APPGROUP opcode
|
||||
2 n length
|
||||
4 WINDOW window
|
||||
2 1 window_type
|
||||
2 12 system_window_len
|
||||
4 CARD32 WindowPtr
|
||||
2 INT16 Rect.top
|
||||
2 INT16 Rect.left
|
||||
2 INT16 Rect.bottom
|
||||
2 INT16 Rect.right
|
||||
</literallayout>
|
||||
|
||||
<literallayout>
|
||||
<emphasis role='bold'>AppGroupCreateAssoc (Win32)</emphasis>
|
||||
1 CARD8 opcode
|
||||
1 6 XC-APPGROUP opcode
|
||||
2 n length
|
||||
4 WINDOW window
|
||||
2 2 window_type
|
||||
2 4 system_window_len
|
||||
4 CARD32 HWND
|
||||
</literallayout>
|
||||
|
||||
<literallayout>
|
||||
<emphasis role='bold'>AppGroupCreateAssoc (Win16)</emphasis>
|
||||
1 CARD8 opcode
|
||||
1 6 XC-APPGROUP opcode
|
||||
2 n length
|
||||
4 WINDOW window
|
||||
2 3 window_type
|
||||
2 4 system_window_len
|
||||
2 CARD16 HWND offset
|
||||
2 CARD16 HWND segment
|
||||
</literallayout>
|
||||
|
||||
</appendix>
|
||||
@ -1,248 +0,0 @@
|
||||
<?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">
|
||||
|
||||
|
||||
<book id="appgroup">
|
||||
|
||||
<bookinfo>
|
||||
<title>Description of the Application Group Extension</title>
|
||||
<subtitle>Implementation for the X11 Sample Server</subtitle>
|
||||
<releaseinfo>Version 1.0</releaseinfo>
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Kaleb </firstname><surname>KEITHLEY</surname>
|
||||
<affiliation><orgname>FUJITSU Limited.</orgname></affiliation>
|
||||
<email>blah@blah.com</email>
|
||||
</author>
|
||||
</authorgroup>
|
||||
<corpname>X Consortium Standard</corpname>
|
||||
<copyright><year>1996</year><holder>X Consortium</holder></copyright>
|
||||
<affiliation><orgname>X Consortium</orgname></affiliation>
|
||||
<productnumber>X Version 11, Release 7</productnumber>
|
||||
|
||||
<abstract>
|
||||
<para>
|
||||
The following document explains the server side of the Application
|
||||
Group Extension.
|
||||
</para>
|
||||
</abstract>
|
||||
|
||||
<legalnotice>
|
||||
|
||||
|
||||
<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>
|
||||
The following document explains the server side of the Application
|
||||
Group Extension.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
WindowsNT is a trademark of Microsoft, Inc. Macintosh and Apple
|
||||
are trademarks of Apple Computer, Inc. X Window System is a
|
||||
trademark of X Consortium, Inc.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<chapter>
|
||||
<title>TITLE</title>
|
||||
<para>
|
||||
To understand this document and the accompanying source code, you
|
||||
should know the C language, should be familiar with X server
|
||||
internals, and should also have a general knowledge of the X
|
||||
Window System.
|
||||
</para>
|
||||
|
||||
<sect1 id="AppGroup_Server_Public_Functions">
|
||||
<title>AppGroup Server Public Functions</title>
|
||||
<para>
|
||||
The AppGroup extension adds seven new functions that are called
|
||||
from elsewhere in the server. They are: XagExtensionInit,
|
||||
XagDefaultColormap, XagRootVisual, XagLeader, XagIsControlledRoot,
|
||||
XagConnectionInfo, XagCallClientStateChange.
|
||||
</para>
|
||||
<para>
|
||||
XagExtensionInit is the extension initialization function called
|
||||
from InitExtension in mi/miinitext.c. Note that an new resource
|
||||
type, RT_APPGROUP, is created, specifying the destructor function
|
||||
XagAppGroupFree.
|
||||
</para>
|
||||
<para>
|
||||
XagDefaultColormap returns the colormap ID that was specified in
|
||||
the creation of the AppGroup. Any time CopyFromParent is specified
|
||||
for a top-level window's colormap, i.e. in a CreateWindow or
|
||||
ChangeWindowAttributes request, this function is called to see
|
||||
if there is an AppGroup specific colormap to use. If there is
|
||||
one, its ID is returned, otherwise None is returned.
|
||||
</para>
|
||||
<para>
|
||||
XagRootVisual returns the visual ID that was specified in the
|
||||
creation of the Appgroup. Like XagDefaultColormap, when CopyFromParent
|
||||
is specified for a top-level window's visual in a CreateWindow
|
||||
request, this function is called to see if there is an AppGroup
|
||||
specific visual to use. If there is one, its ID is returned,
|
||||
otherwise 0 (zero) is returned.
|
||||
</para>
|
||||
<para>
|
||||
XagLeader returns the ClientPtr of the client that is the AppGroup
|
||||
Leader. Normally when an application maps or configures a top-level
|
||||
window a MapRequest or ConfigureRequest event is delivered to the
|
||||
client, e.g. a window manager, that has selected SubstructureRedirect
|
||||
on the root window. However, when the application is part of an
|
||||
AppGroup, the MapRequest and ConfigureRequest events are delivered
|
||||
to the AppGroup Leader instead.
|
||||
</para>
|
||||
<para>
|
||||
XagIsControlledRoot returns a boolean: True if the window is a
|
||||
top-level window of a client in an AppGroup, False otherwise.
|
||||
In a combined server, i.e. one that provides both UI and printing,
|
||||
the application may create and map windows on the "printing"
|
||||
screens; thus it becomes necessary to discriminate between the
|
||||
AppGroup's root window and other root windows. If an AppGroup
|
||||
member creates and maps a [top-level] window then the window's
|
||||
parent [the root window] is tested to determine whether to send
|
||||
MapRequest or ConfigureRequest events to the AppGroup Leader to
|
||||
to some other client.
|
||||
</para>
|
||||
<para>
|
||||
In the trivial case XagIsControlledRoot returns True if the parent
|
||||
window has no parent itself, i.e. it is a root window. In the case
|
||||
where the application is embedded, indicated by the singleScreen
|
||||
attribute being True, the parent's drawable ID is compared to the
|
||||
AppGroup's root window ID, and if it is the same, True is returned.
|
||||
If neither case is true, then False is returned.
|
||||
</para>
|
||||
<para>
|
||||
XagConnectionInfo returns an abreviated version of the connection
|
||||
setup information. When an embedded AppGroup is created the server
|
||||
returns only the information about the [UI] screen that the
|
||||
application is embedded within in the connection setup in order to
|
||||
prevent the application from creating windows on other screens;
|
||||
thus attempting to guarantee that any window that should be embedded
|
||||
can be reparented into the AppGroup Leader's window hierarchy.
|
||||
</para>
|
||||
<para>
|
||||
XagCallClientStateChange is called to invoke the extension's client
|
||||
state change callback additional times as necessary -- currently
|
||||
only once, after the auth data becomes available between
|
||||
ClientStateInitial and ClientStateConnected. Client state change
|
||||
callbacks were introduced in the Record extension, which specifies
|
||||
when the callbacks are invoked. Unfortunately the points at which
|
||||
they are called are not necessarily the best as far as the AppGroup
|
||||
Extension is concerned. Adding an additional state and calling all
|
||||
the callbacks works too, however this seemed unnecessary overkill.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="AppGroup_Server_Private_APIs">
|
||||
<title>AppGroup Server Private APIs</title>
|
||||
<para>
|
||||
The AppGroup extension adds the following functions which are
|
||||
private to the extension: ProcXagDispatch and SProcXagDispatch,
|
||||
ProcXagQueryVersion and SProcXagQueryVersion, ProcXagCreate and
|
||||
SProcXagCreate, ProcXagDestroy and SProcXagDestroy,
|
||||
ProcGetAttr and SProcGetAttr, ProcXagQuery and SProcXagQuery,
|
||||
ProcXagCreateAssoc and SProcXagCreateAssoc, ProcXagDestroyAssoc
|
||||
and SProcXagDestroyAssoc, XagResetProc, and XagAppGroupFree.
|
||||
</para>
|
||||
<para>
|
||||
The ProcXagDispatch, SProcXagDispatch, and XagResetProc functions
|
||||
should be familiar to anyone familiar with X server internals and
|
||||
I won't elaborate on them here. Similarly the wrapper functions:
|
||||
SProcXagQueryVersion, SProcXagCreate, SProcXagDestroy, SProcXagGetAttr,
|
||||
SProcXagQuery, SProcXagCreateAssoc, and SProcXagDestroyAssoc, as
|
||||
wrappers which handle swapping integer data into the host's byte
|
||||
order will not be explained in any detail.
|
||||
</para>
|
||||
<para>
|
||||
ProcXagQueryVersion returns the major and minor versions of the
|
||||
AppGroup extension supported by the server.
|
||||
</para>
|
||||
<para>
|
||||
ProcXagCreate creates an AppGroup. A new record in a linked list
|
||||
of AppGroups is allocated and initialized. The attributes from the
|
||||
request are validated and copied to the AppGroup record. If necessary
|
||||
an abbreviated version of the connection setup information is compiled
|
||||
and also stored in the AppGroup record. The first time an AppGroup
|
||||
is created a client-state-change callback is registered and a
|
||||
reference count is incremented.
|
||||
</para>
|
||||
<para>
|
||||
ProcXagDestroy destroys an AppGroup an AppGroup by calling
|
||||
FreeResource specifying the AppGroup ID. This will result in
|
||||
the destructor function XagAppGroupFree being called. The
|
||||
reference count is decremented and when it reaches zero the
|
||||
client-state-change callback is deleted.
|
||||
</para>
|
||||
<para>
|
||||
ProcXagGetAttr returns the AppGroup Attributes to the requesting
|
||||
client.
|
||||
</para>
|
||||
<para>
|
||||
ProcXagQuery returns the AppGroup ID of an arbitrary resource to
|
||||
the requesting client.
|
||||
</para>
|
||||
<para>
|
||||
ProcXagCreateAssoc creates an association between an X window ID
|
||||
and system-specific data. In native X this functionality is
|
||||
unnecessary but for various personal computers, e.g. Macintosh,
|
||||
OS/2, and MS-Windows it is necessary to associate an X window ID
|
||||
with the system's native window identifier so that when the
|
||||
AppGroup Leader issues a ReparentWindow request the personal
|
||||
computer X server can lookup the system-specific window ID and
|
||||
make the necessary function call(s) with it.
|
||||
</para>
|
||||
<para>
|
||||
ProcXagDestroyAssoc destroys the association created with
|
||||
ProcXagCreateAssoc.
|
||||
</para>
|
||||
<para>
|
||||
XagResetProc removes the client-state-change callback, sets the
|
||||
reference count to zero, and frees all the AppGroup records in
|
||||
the linked list by calling XagAppGroupFree.
|
||||
</para>
|
||||
<para>
|
||||
XagAppGroupFree calls CloseDownClient for each client in an
|
||||
AppGroup if the AppGroup has a leader, unlinks the AppGroup
|
||||
record from the linked list, frees allocated memory referenced
|
||||
by the record, and finally frees the record itself.
|
||||
</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="Known_Problems_in_this_release_">
|
||||
<title>Known Problems in this release.</title>
|
||||
<para>
|
||||
In a combined UI/Print server the connection setup returned to an
|
||||
embedded application will not have information about the print
|
||||
screens.
|
||||
</para>
|
||||
<para>
|
||||
The LBX proxy caches connection setup information and will return
|
||||
incorrect connection setup information to an embedded client.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
</book>
|
||||
1018
proto/xextproto/specs/appgrp.xml
Normal file
1018
proto/xextproto/specs/appgrp.xml
Normal file
File diff suppressed because it is too large
Load Diff
@ -1,6 +1,6 @@
|
||||
<?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">
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
|
||||
|
||||
|
||||
<!--
|
||||
|
||||
@ -34,9 +34,7 @@ provided "as is" without express or implied warranty.
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<chapter>
|
||||
<title>TITLE</title>
|
||||
<sect1 id="Overview">
|
||||
<chapter id="Overview">
|
||||
<title>Overview</title>
|
||||
<para>
|
||||
This extension provides X Protocol control over the VESA Display
|
||||
@ -119,9 +117,9 @@ importance of power savings should supersede the screen saver. If the
|
||||
laptop user plugs the unit in and power is no longer a scarce commodity,
|
||||
it may be decided to make DPMS less aggressive, or disable it completely.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Requests">
|
||||
<chapter id="Requests">
|
||||
<title>Requests</title>
|
||||
<para>
|
||||
<function>DPMSGetVersion</function>
|
||||
@ -430,16 +428,16 @@ of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend or DPMSModeOff, otherwise
|
||||
it is undefined.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Events_and_Errors">
|
||||
<chapter id="Events_and_Errors">
|
||||
<title>Events and Errors</title>
|
||||
<para>
|
||||
No new events or errors are defined by this extension.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Encoding">
|
||||
<chapter id="Encoding">
|
||||
<title>Encoding</title>
|
||||
<para>
|
||||
Please refer to the X11 Protocol Encoding document as this document uses
|
||||
@ -558,6 +556,5 @@ The name of this extension is "DPMS".
|
||||
21 unused
|
||||
|
||||
</literallayout>
|
||||
</sect1>
|
||||
</chapter>
|
||||
</book>
|
||||
|
||||
@ -62,17 +62,15 @@ X Window System is a trademark of The Open Group.
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<chapter>
|
||||
<title>TITLE</title>
|
||||
<sect1 id="Introduction">
|
||||
<chapter id="Introduction">
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
EVI (Extended Visual Information extension) allows a client to determine
|
||||
information about core X visuals beyond what the core protocol provides.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Goals">
|
||||
<chapter id="Goals">
|
||||
<title>Goals</title>
|
||||
<para>
|
||||
As the X Window System has evolved, it has become clear that the information
|
||||
@ -90,9 +88,9 @@ their own mechanisms for delivering that information. For example, the Double
|
||||
Buffering Extension (DBE) provides its own mechanism for determining which
|
||||
visuals support double-buffering.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Requests">
|
||||
<chapter id="Requests">
|
||||
<title>Requests</title>
|
||||
<para>
|
||||
<function>GetVersion</function>
|
||||
@ -285,22 +283,22 @@ example, if a 12-bit colormap is overloaded to support 8-bit visuals, the
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect1>
|
||||
<sect1 id="Events_and_Errors">
|
||||
</chapter>
|
||||
<chapter id="Events_and_Errors">
|
||||
<title>Events and Errors</title>
|
||||
<para>
|
||||
No new events or errors are defined by this extension.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Changes_to_existing_protocol_">
|
||||
<chapter id="Changes_to_existing_protocol_">
|
||||
<title>Changes to existing protocol.</title>
|
||||
<para>
|
||||
None.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Encoding">
|
||||
<chapter id="Encoding">
|
||||
<title>Encoding</title>
|
||||
<para>
|
||||
The name of this extension is "Extended-Visual-Information".
|
||||
@ -358,9 +356,9 @@ VISUALINFO
|
||||
1 CARD8 max_hw_colormaps
|
||||
2 CARD16 num_colormap_conflicts
|
||||
</literallayout>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="C_Language_Binding">
|
||||
<chapter id="C_Language_Binding">
|
||||
<title>C Language Binding</title>
|
||||
<para>
|
||||
<!-- .LP -->
|
||||
@ -513,6 +511,5 @@ of hardware support for multiple colormaps. XeviGetVisualInfo returns Success
|
||||
if successful, or an X error otherwise.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
</book>
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
<?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.5/docbookx.dtd">
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
|
||||
<book>
|
||||
<bookinfo>
|
||||
<title>X Generic Event Extension</title>
|
||||
|
||||
6291
proto/xextproto/specs/lbx.xml
Normal file
6291
proto/xextproto/specs/lbx.xml
Normal file
File diff suppressed because it is too large
Load Diff
@ -4,7 +4,7 @@
|
||||
|
||||
|
||||
<!-- lifted from troff+ms+XMan by doclifter -->
|
||||
<book id="buffer">
|
||||
<book id="multibuf">
|
||||
|
||||
<bookinfo>
|
||||
<title>Extending X for Double-Buffering, Multi-Buffering, and Stereo</title>
|
||||
@ -70,16 +70,16 @@ in this Software without prior written authorization from the X Consortium.
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<chapter>
|
||||
<title>TITLE</title>
|
||||
<preface><title>Warning</title>
|
||||
<warning><para>
|
||||
The <emphasis remap='I'>Multi-Buffering</emphasis> extension described here
|
||||
was a draft standard of the X Consortium prior to Release 6.1. It has been
|
||||
superseded by the Double Buffer
|
||||
Extension (DBE). DBE is an X Consortium Standard as of Release 6.1.
|
||||
</para></warning>
|
||||
</preface>
|
||||
|
||||
<sect1 id="introduction">
|
||||
<chapter id="introduction">
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
@ -120,9 +120,9 @@ The authors of this proposal have tried to unify the above documents
|
||||
to yield a proposal that incorporates support for double-buffering,
|
||||
multi-buffering, and stereo in a way that is acceptable to all concerned.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="goals">
|
||||
<chapter id="goals">
|
||||
<title>Goals</title>
|
||||
|
||||
<para>
|
||||
@ -176,9 +176,9 @@ existing hardware features.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="image_buffers">
|
||||
<chapter id="image_buffers">
|
||||
<title>Image Buffers</title>
|
||||
|
||||
<para>
|
||||
@ -316,9 +316,9 @@ the screen contents are not altered and the contents of any
|
||||
undisplayed image buffers are undefined. If backing store was
|
||||
maintained for an image buffer, then no exposure events are generated.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="new_requests">
|
||||
<chapter id="new_requests">
|
||||
<title>New Requests</title>
|
||||
|
||||
<para>
|
||||
@ -671,9 +671,9 @@ display are de-allocated. If the window is not multi-buffered,
|
||||
the request is ignored.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="attributes">
|
||||
<chapter id="attributes">
|
||||
<title>Attributes</title>
|
||||
|
||||
<para>
|
||||
@ -860,9 +860,9 @@ increment for incompatible changes, and the minor version would
|
||||
increment for small upward compatible changes. Barring changes, the
|
||||
major version will be 1, and the minor version will be 1.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="events">
|
||||
<chapter id="events">
|
||||
<title>Events</title>
|
||||
|
||||
<para>
|
||||
@ -958,9 +958,9 @@ becomes <emphasis remap='I'>updated</emphasis>
|
||||
<function>DisplayImageBuffers</function>
|
||||
request), an <function>UpdateNotify</function> event is generated.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="errors">
|
||||
<chapter id="errors">
|
||||
<title>Errors</title>
|
||||
|
||||
<para>
|
||||
@ -968,14 +968,14 @@ The following error type has been added to support
|
||||
this extension:
|
||||
</para>
|
||||
|
||||
<sect2 id="buffer_2">
|
||||
<sect1 id="buffer_2">
|
||||
<title>Buffer</title>
|
||||
<para>
|
||||
A value for a BUFFER argument does not name a defined BUFFER.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="double_buffering_normal_windows">
|
||||
<sect1 id="double_buffering_normal_windows">
|
||||
<title>Double-Buffering Normal Windows</title>
|
||||
|
||||
<para>
|
||||
@ -1023,9 +1023,9 @@ while animating
|
||||
DestroyImageBuffers( W )
|
||||
</literallayout>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="multi_buffering_normal_windows">
|
||||
<sect1 id="multi_buffering_normal_windows">
|
||||
<title>Multi-Buffering Normal Windows</title>
|
||||
|
||||
<para>
|
||||
@ -1070,9 +1070,9 @@ while animating
|
||||
}
|
||||
</literallayout>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="stereo_windows">
|
||||
<sect1 id="stereo_windows">
|
||||
<title>Stereo Windows</title>
|
||||
<para>
|
||||
<emphasis remap='I'>How</emphasis> stereo windows are supported on a server
|
||||
@ -1175,9 +1175,9 @@ right eyes for normal windows should be the same
|
||||
(ie: have no stereo offset).
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="single_buffered_stereo_windows">
|
||||
<sect1 id="single_buffered_stereo_windows">
|
||||
<title>Single-Buffered Stereo Windows</title>
|
||||
|
||||
<para>
|
||||
@ -1195,9 +1195,9 @@ MapWindow( W )
|
||||
|
||||
<draw picture using L,R>
|
||||
</literallayout>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="double_buffering_stereo_windows">
|
||||
<sect1 id="double_buffering_stereo_windows">
|
||||
<title>Double-Buffering Stereo Windows</title>
|
||||
|
||||
<para>
|
||||
@ -1267,9 +1267,9 @@ while animating
|
||||
}
|
||||
</literallayout>
|
||||
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="multi_buffering_stereo_windows">
|
||||
<sect1 id="multi_buffering_stereo_windows">
|
||||
<title>Multi-Buffering Stereo Windows</title>
|
||||
|
||||
<para>
|
||||
@ -1310,9 +1310,9 @@ while animating
|
||||
DisplayImageBuffers( [L(i)], 100, 0 )
|
||||
}
|
||||
</literallayout>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="protocol_encoding">
|
||||
<sect1 id="protocol_encoding">
|
||||
<title>Protocol Encoding</title>
|
||||
|
||||
<para>
|
||||
@ -1356,10 +1356,10 @@ Specifies the code that will be returned when
|
||||
The following sections describe the protocol
|
||||
encoding for this extension.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="type">
|
||||
<chapter id="type">
|
||||
<title>TYPES</title>
|
||||
|
||||
<literallayout class="monospaced">
|
||||
@ -1379,9 +1379,9 @@ SETofBUFFER_EVENT
|
||||
#x04000000 UpdateNotify
|
||||
</literallayout>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="events_2">
|
||||
<chapter id="events_2">
|
||||
<title>EVENTS</title>
|
||||
|
||||
<literallayout class="monospaced">
|
||||
@ -1406,8 +1406,8 @@ SETofBUFFER_EVENT
|
||||
24 unused
|
||||
</literallayout>
|
||||
|
||||
</sect1>
|
||||
<sect1 id="errors_2">
|
||||
</chapter>
|
||||
<chapter id="errors_2">
|
||||
<title>ERRORS</title>
|
||||
|
||||
<literallayout class="monospaced">
|
||||
@ -1421,9 +1421,9 @@ SETofBUFFER_EVENT
|
||||
21 unused
|
||||
</literallayout>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="requests">
|
||||
<chapter id="requests">
|
||||
<title>REQUESTS</title>
|
||||
|
||||
<literallayout class="monospaced">
|
||||
@ -1623,6 +1623,5 @@ VALUEs
|
||||
|
||||
</literallayout>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
</book>
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
<?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">
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
|
||||
<!--translated from security.tex, on 2010-06-27 15:29:00,
|
||||
by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/)
|
||||
xhtml,docbook,html,refcaption -->
|
||||
|
||||
@ -60,8 +60,7 @@ copyright holders.
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<chapter><title>TITLE</title>
|
||||
<sect1 id="Overview">
|
||||
<chapter id="Overview">
|
||||
<title>Overview</title>
|
||||
<para>
|
||||
<!-- .LP -->
|
||||
@ -94,9 +93,9 @@ the window's geometry in the core protocol. An expected convention would be
|
||||
that client programs expand their shape to fill the area offered by the
|
||||
window manager.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Description">
|
||||
<chapter id="Description">
|
||||
<title>Description</title>
|
||||
<para>
|
||||
Each window (even with no shapes specified) is defined by three regions: the
|
||||
@ -264,9 +263,9 @@ the server is permitted to ignore requested changes to the bounding region
|
||||
of a root window. If the server accepts bounding region changes, the contents
|
||||
of the screen outside the bounding region are implementation dependent.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Types">
|
||||
<chapter id="Types">
|
||||
<title>Types</title>
|
||||
<para>
|
||||
<!-- .LP -->
|
||||
@ -307,9 +306,9 @@ produce the new destination region.
|
||||
indicates that the destination region is subtracted from the source region to
|
||||
produce the new destination region.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Requests">
|
||||
<chapter id="Requests">
|
||||
<title>Requests</title>
|
||||
<para>
|
||||
<function>ShapeQueryVersion</function>
|
||||
@ -802,9 +801,9 @@ values is the same as in the
|
||||
<function>ShapeRectangles</function>
|
||||
request.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Events">
|
||||
<chapter id="Events">
|
||||
<title>Events</title>
|
||||
<para>
|
||||
<function>ShapeNotify</function>
|
||||
@ -870,9 +869,9 @@ current shape. When shaped is
|
||||
these will indicate the extents of the default region. The timestamp
|
||||
indicates the server time when the shape was changed.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Encoding">
|
||||
<chapter id="Encoding">
|
||||
<title>Encoding</title>
|
||||
<para>
|
||||
Please refer to the X11 Protocol Encoding document as this document uses
|
||||
@ -883,7 +882,7 @@ conventions established there.
|
||||
The name of this extension is "SHAPE".
|
||||
</para>
|
||||
|
||||
<sect2 id="New_Types">
|
||||
<sect1 id="New_Types">
|
||||
<title>New Types</title>
|
||||
|
||||
<literallayout class="monospaced">
|
||||
@ -901,9 +900,9 @@ SHAPE_OP
|
||||
3 Subtract
|
||||
4 Invert
|
||||
</literallayout>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="Requests_2">
|
||||
<sect1 id="Requests_2">
|
||||
<title>Requests</title>
|
||||
<literallayout class="monospaced">
|
||||
<function>ShapeQueryVersion</function>
|
||||
@ -1055,9 +1054,9 @@ SHAPE_OP
|
||||
20 unused
|
||||
8n LISTofRECTANGLE rectangles
|
||||
</literallayout>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="Events_2">
|
||||
<sect1 id="Events_2">
|
||||
<title>Events</title>
|
||||
<literallayout class="monospaced">
|
||||
<function>ShapeNotify</function>
|
||||
@ -1073,7 +1072,6 @@ SHAPE_OP
|
||||
1 BOOL shaped
|
||||
11 unused
|
||||
</literallayout>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
|
||||
<!-- lifted from troff+ms+XMan by doclifter -->
|
||||
<book id="mit-shm">
|
||||
<book id="shm">
|
||||
|
||||
<bookinfo>
|
||||
<title>MIT-SHM(The MIT Shared Memory Extension)</title>
|
||||
@ -67,9 +67,7 @@ in this Software without prior written authorization from the X Consortium.
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<chapter>
|
||||
<title>TITLE</title>
|
||||
<sect1 id="REQUIREMENTS">
|
||||
<chapter id="REQUIREMENTS">
|
||||
<title>REQUIREMENTS</title>
|
||||
<para>
|
||||
The shared memory extension is provided only by some X servers. To find out
|
||||
@ -82,9 +80,9 @@ Additionally, the shared memeory maximum size will need to be increased on
|
||||
both Sun and Digital systems; the defaults are far too small for any useful
|
||||
work.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="WHAT_IS_PROVIDED">
|
||||
<chapter id="WHAT_IS_PROVIDED">
|
||||
<title>WHAT IS PROVIDED</title>
|
||||
|
||||
<para>
|
||||
@ -106,9 +104,9 @@ pixmap data; if the pixmaps are stored in some magic graphics hardware, your
|
||||
application will not be able to share them with the server. Xdpyinfo(1)
|
||||
doesn't print this particular nugget of information.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="HOW_TO_USE_THE_SHARED_MEMORY_EXTENSION">
|
||||
<chapter id="HOW_TO_USE_THE_SHARED_MEMORY_EXTENSION">
|
||||
<title>HOW TO USE THE SHARED MEMORY EXTENSION</title>
|
||||
<para>
|
||||
Code which uses the shared memory extension must include a number of header
|
||||
@ -165,9 +163,9 @@ conventional Xlib calls. When the extension is available,
|
||||
version numbers of the extension implementation, and "pixmaps" which is
|
||||
True iff shared memory pixmaps are supported.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="USE_OF_SHARED_MEMORY_XIMAGES">
|
||||
<chapter id="USE_OF_SHARED_MEMORY_XIMAGES">
|
||||
<title>USE OF SHARED MEMORY XIMAGES</title>
|
||||
<para>
|
||||
The basic sequence of operations for shared memory XImages is as follows:
|
||||
@ -408,9 +406,9 @@ shmdt (shminfo.shmaddr);
|
||||
shmctl (shminfo.shmid, IPC_RMID, 0);
|
||||
</literallayout>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="USE_OF_SHARED_MEMORY_PIXMAPS">
|
||||
<chapter id="USE_OF_SHARED_MEMORY_PIXMAPS">
|
||||
<title>USE OF SHARED MEMORY PIXMAPS</title>
|
||||
<para>
|
||||
Unlike X images, for which any image format is usable, the shared memory
|
||||
@ -469,6 +467,5 @@ contents directly through the shared memory segment. Shared memory pixmaps
|
||||
are destroyed in the usual manner with XFreePixmap, though you should detach
|
||||
and destroy the shared memory segment itself as shown above.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
</book>
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
<?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">
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
|
||||
|
||||
<!--translated from sync.tex, on 2010-06-29 10:52:00,
|
||||
by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/) xhtml,docbook,html,refcaption -->
|
||||
@ -9,7 +9,7 @@ by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/) xhtml,docbook,html,ref
|
||||
<book id="sync">
|
||||
|
||||
<bookinfo>
|
||||
<title>X Synchronization Extention Protocol</title>
|
||||
<title>X Synchronization Extension Protocol</title>
|
||||
<subtitle>X Consortium Standard</subtitle>
|
||||
<releaseinfo>X Version 11, Release 6.6.84</releaseinfo>
|
||||
<authorgroup>
|
||||
@ -20,18 +20,23 @@ by TeX4ht (http://www.cse.ohio-state.edu/~gurari/TeX4ht/) xhtml,docbook,html,ref
|
||||
<othercredit>
|
||||
<firstname>Dave</firstname>
|
||||
<surname>Carver</surname>
|
||||
<affiliation><orgname>Digital EquipmentCorporation, MIT/Project Athena</orgname></affiliation>
|
||||
<affiliation><orgname>Digital Equipment Corporation, MIT/Project Athena</orgname></affiliation>
|
||||
</othercredit>
|
||||
<othercredit>
|
||||
<firstname>Jim</firstname>
|
||||
<surname>Gettys</surname>
|
||||
<affiliation><orgname>Digital EquipmentCorporation, Cambridge Research Laboratory</orgname></affiliation>
|
||||
<affiliation><orgname>Digital Equipment Corporation, Cambridge Research Laboratory</orgname></affiliation>
|
||||
</othercredit>
|
||||
<othercredit>
|
||||
<firstname>David</firstname>
|
||||
<surname>Wiggins</surname>
|
||||
<affiliation><orgname>X Consortium, Inc.</orgname></affiliation>
|
||||
</othercredit>
|
||||
<othercredit>
|
||||
<firstname>James</firstname>
|
||||
<surname>Jones</surname>
|
||||
<affiliation><orgname>NVIDIA Corporation</orgname></affiliation>
|
||||
</othercredit>
|
||||
</authorgroup>
|
||||
<corpname>X Consortium Standard</corpname>
|
||||
|
||||
@ -43,8 +48,9 @@ Digital Equipment Corporation, Maynard, Massachusetts
|
||||
</holder>
|
||||
</copyright>
|
||||
<copyright><year>1991</year><holder>X Consortium</holder></copyright>
|
||||
<copyright><year>2010</year><holder>NVIDIA Corporation</holder></copyright>
|
||||
|
||||
<releaseinfo>Version 3.0</releaseinfo>
|
||||
<releaseinfo>Version 3.1</releaseinfo>
|
||||
<affiliation><orgname>X Consortium</orgname></affiliation>
|
||||
<productnumber>X Version 11, Release 6.8</productnumber>
|
||||
|
||||
@ -52,10 +58,10 @@ Digital Equipment Corporation, Maynard, Massachusetts
|
||||
<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 appear in all copies. Olivetti, Digital, MIT, and the
|
||||
X Consortium make 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.
|
||||
copyright notice appear in all copies. Olivetti, Digital, MIT, the
|
||||
X Consortium, and NVIDIA make 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>
|
||||
@ -133,12 +139,17 @@ frame marker.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The extension adds <function>Counter</function> and
|
||||
<function>Alarm</function> to the set of resources managed by the
|
||||
The extension adds <function>Counter</function>, <function>Alarm</function>,
|
||||
and <function>Fence</function> to the set of resources managed by the
|
||||
server. A counter has a 64-bit integer value that may be increased or
|
||||
decreased by client requests or by the server internally. A client can block
|
||||
by sending an Await request that waits until one of a set of synchronization
|
||||
conditions, called TRIGGERs, becomes TRUE.
|
||||
conditions, called TRIGGERs, becomes TRUE. Alarms generate events when
|
||||
counter values go through a specified transition. A fence has two possible
|
||||
states: triggered and not triggered. Client requests can put the fence in
|
||||
either of these states. A client can block until one of a set of fences
|
||||
becomes triggered by sending an AwaitFence request. Fences are bound to a
|
||||
particular screen at creation time.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
@ -168,6 +179,21 @@ clients to receive an event on a regular basis when a particular counter
|
||||
is changed.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The <function>CreateFence</function> request allows a client to create a
|
||||
<function>Fence</function> that can be triggered and reset using
|
||||
<function>TriggerFence</function> and <function>ResetFence</function>
|
||||
requests, respectively. <function>CreateFence</function> takes a drawable
|
||||
argument that implies which screen the fence should be created on. The
|
||||
<function>TriggerFence</function> request changes the fence's state only
|
||||
after all previous rendering commands affecting objects owned by the given
|
||||
fence's screen have completed. Note that while fence objects are bound
|
||||
to a screen and the simple trigger operation provided by this extension
|
||||
operates at screen granularity, other extensions may add more fine-grained
|
||||
trigger operations based on any number of events. The screen binding
|
||||
merely establishes an upper bound for the scope of fence operations.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
<sect1 id="types">
|
||||
<title>Types</title>
|
||||
@ -201,6 +227,7 @@ SYSTEMCOUNTER: [
|
||||
]
|
||||
ALARM: XID
|
||||
ALARMSTATE: {Active,Inactive,Destroyed}
|
||||
FENCE: XID
|
||||
</literallayout>
|
||||
|
||||
<para>
|
||||
@ -283,6 +310,14 @@ registry of system counter names to avoid collisions in the name space.
|
||||
<para>
|
||||
An ALARM is the client-side handle on an <function>Alarm</function> resource.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The FENCE type defines the client-side handle on a server
|
||||
<function>Fence</function>. A fence can only be in one of two states,
|
||||
represented by a BOOL. If the value is TRUE, the fence is in the triggered
|
||||
state. Otherwise, the fence is in the not triggered state.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
<sect1 id="errors">
|
||||
@ -307,6 +342,15 @@ does not name a defined ALARM.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>Fence</term>
|
||||
<listitem>
|
||||
<para>
|
||||
This error is generated if the value for a FENCE argument in a request
|
||||
does not name a defined FENCE.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
</sect1>
|
||||
@ -341,7 +385,7 @@ and v1.version_minor <= v2.version_minor. Compatible means that the
|
||||
functionality is fully supported in an identical fashion in the two versions.
|
||||
</para>
|
||||
<para>
|
||||
This document describes major version 3, minor version 0 of the SYNC protocol.
|
||||
This document describes major version 3, minor version 1 of the SYNC protocol.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
@ -740,6 +784,118 @@ server.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>CreateFence</term>
|
||||
<listitem>
|
||||
<literallayout class="monospaced">
|
||||
drawable: DRAWABLE
|
||||
id: FENCE
|
||||
initially-triggered: BOOL
|
||||
Errors: <function>IDChoice</function>,<function>Alloc</function>
|
||||
</literallayout>
|
||||
<para>
|
||||
This request creates a fence on the screen associated with drawable and
|
||||
assigns the specified id to it. The fence is in the triggered state iff
|
||||
initially-triggered is TRUE. There are no clients waiting on the fence.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>TriggerFence</term>
|
||||
<listitem>
|
||||
<literallayout class="monospaced">
|
||||
fence: FENCE
|
||||
Errors: <function>Fence</function>
|
||||
</literallayout>
|
||||
<para>
|
||||
This request puts the given fence in the triggered state after all rendering
|
||||
from previous requests that affects resources owned by the fence's screen has
|
||||
completed. This includes requests from other clients if those requests have
|
||||
been dispatched. This request has no visible effects if the fence was already
|
||||
in the triggered state. A <function>Fence</function> error is generated if
|
||||
fence does not name a valid fence.
|
||||
</para>
|
||||
<para>
|
||||
Note that the given fence's state is not necessarily directly modified by this
|
||||
request. The state change need only be queued to occur after the required
|
||||
rendering has completed. Clients should take care to not assume the fence will
|
||||
be in the triggered state in subsequent requests, such as those that operate
|
||||
on the given fence immediately. <function>AwaitFence</function> should first
|
||||
be issued if subsequent requests require the fence to be in the triggered
|
||||
state.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>ResetFence</term>
|
||||
<listitem>
|
||||
<literallayout class="monospaced">
|
||||
fence: FENCE
|
||||
Errors: <function>Fence</function>,<function>Match</function>
|
||||
</literallayout>
|
||||
<para>
|
||||
This request immediately puts the given fence in the not triggered state.
|
||||
A <function>Match</function> error is generated if the fence is not in the
|
||||
triggered state. A <function>Fence</function> error is generated if fence
|
||||
does not name a valid fence.
|
||||
</para>
|
||||
<para>
|
||||
See the warnings above regarding <function>TriggerFence</function>'s delayed
|
||||
effect. In particular, a <function>TriggerFence</function> request
|
||||
immediately followed by a <function>ResetFence</function> request is likely
|
||||
to result in a <function>Match</function> error. An
|
||||
<function>AwaitFence</function> request should be issued between the two.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>DestroyFence</term>
|
||||
<listitem>
|
||||
<literallayout class="monospaced">
|
||||
fence: FENCE
|
||||
Errors: <function>Fence</function>
|
||||
</literallayout>
|
||||
<para>
|
||||
This request destroys the given fence. All clients waiting on this fence are
|
||||
released. A fence is destroyed automatically when the connection to the client
|
||||
that created the fence is closed if the close-down mode is
|
||||
<function>DestroyAll</function>. A <function>Fence</function> error is
|
||||
generated if fence does not name a valid fence.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>QueryFence</term>
|
||||
<listitem>
|
||||
<literallayout class="monospaced">
|
||||
fence: FENCE
|
||||
=>
|
||||
triggered: BOOL
|
||||
Errors: <function>Fence</function>
|
||||
</literallayout>
|
||||
<para>
|
||||
This request returns TRUE if the given fence is triggered, or FALSE if it
|
||||
is not triggered. A <function>Fence</function> error is generated if
|
||||
fence does not name a valid fence.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term>AwaitFence</term>
|
||||
<listitem>
|
||||
<literallayout class="monospaced">
|
||||
fence-list: LISTofFENCE
|
||||
Errors: <function>Fence</function>,<function>Alloc</function>
|
||||
</literallayout>
|
||||
<para>
|
||||
When this request is executed, the processing of further requests for the
|
||||
client is blocked until one or more of the fences in fence-list reaches the
|
||||
triggered state. If any of the fences are already in the triggered state,
|
||||
request processing resumes immediately. A <function>Fence</function> error
|
||||
is generated if any member of fence-list does not name a valid fence.
|
||||
</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</sect1>
|
||||
|
||||
@ -844,6 +1000,7 @@ TRIGGER:
|
||||
WAITCONDITION:
|
||||
20 TRIGGER trigger
|
||||
8 INT64 event threshold
|
||||
FENCE: CARD32
|
||||
</literallayout>
|
||||
|
||||
<para>
|
||||
@ -872,6 +1029,14 @@ groups, the byte ordering determined during connection setup is used.
|
||||
2 CARD16 minor opcode
|
||||
1 CARD8 major opcode
|
||||
21 unused
|
||||
<function>Fence</function>
|
||||
1 0 Error
|
||||
1 Base + 2 code
|
||||
2 CARD16 sequence number
|
||||
4 CARD32 bad fence
|
||||
2 CARD16 minor opcode
|
||||
1 CARD8 major opcode
|
||||
21 unused
|
||||
</literallayout>
|
||||
|
||||
</sect1>
|
||||
@ -1026,6 +1191,52 @@ GetPriority
|
||||
4 INT32 priority
|
||||
20 unused
|
||||
|
||||
CreateFence
|
||||
1 CARD8 major opcode
|
||||
1 14 minor opcode
|
||||
2 4 request length
|
||||
4 DRAWABLE drawable
|
||||
4 FENCE id
|
||||
1 BOOL initially triggered
|
||||
3 unused
|
||||
|
||||
TriggerFence
|
||||
1 CARD8 major opcode
|
||||
1 15 minor opcode
|
||||
2 2 request length
|
||||
4 FENCE id
|
||||
|
||||
ResetFence
|
||||
1 CARD8 major opcode
|
||||
1 16 minor opcode
|
||||
2 2 request length
|
||||
4 FENCE id
|
||||
|
||||
DestroyFence
|
||||
1 CARD8 major opcode
|
||||
1 17 minor opcode
|
||||
2 2 request length
|
||||
4 FENCE id
|
||||
|
||||
QueryFence
|
||||
1 CARD8 major opcode
|
||||
1 18 minor opcode
|
||||
2 2 request length
|
||||
4 FENCE id
|
||||
=>
|
||||
1 1 Reply
|
||||
1 unused
|
||||
2 CARD16 sequence number
|
||||
4 0 reply length
|
||||
1 BOOL triggered
|
||||
23 unused
|
||||
|
||||
AwaitFence
|
||||
1 CARD8 major opcode
|
||||
1 19 minor opcode
|
||||
2 1 + n request length
|
||||
4*n LISTofFENCE wait conditions
|
||||
|
||||
</literallayout>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -64,9 +64,7 @@ X Window System is a trademark of The Open Group.
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<chapter>
|
||||
<title>TITLE</title>
|
||||
<sect1 id="Overview">
|
||||
<chapter id="Overview">
|
||||
<title>Overview</title>
|
||||
<para>
|
||||
This extension has three purposes: a) to provide mechanism for a special
|
||||
@ -101,9 +99,9 @@ already been allocated, the color will be allocated in the private colormap
|
||||
at the same locaton as in the default colormap (instead of in the first
|
||||
available location.)
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Requests">
|
||||
<chapter id="Requests">
|
||||
<title>Requests</title>
|
||||
<para>
|
||||
<function>QueryVersion</function>
|
||||
@ -246,23 +244,23 @@ BadMatch error is generated if if cmap does not belong to a GrayScale,
|
||||
PseudoColor, or DirectColor visual.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Events_and_Errors">
|
||||
<chapter id="Events_and_Errors">
|
||||
<title>Events and Errors</title>
|
||||
<para>
|
||||
No new events or errors are defined by this extension.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
<sect1 id="Changes_to_existing_protocol_">
|
||||
</chapter>
|
||||
<chapter id="Changes_to_existing_protocol_">
|
||||
<title>Changes to existing protocol.</title>
|
||||
<para>
|
||||
None.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Encoding">
|
||||
<chapter id="Encoding">
|
||||
<title>Encoding</title>
|
||||
<para>
|
||||
The name of this extension is "TOG-CUP".
|
||||
@ -338,9 +336,9 @@ additional alloc-ok member in the CUPStoreColors reply.)
|
||||
#xF0 unused
|
||||
1 unused
|
||||
</literallayout>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="C_Language_Binding">
|
||||
<chapter id="C_Language_Binding">
|
||||
<title>C Language Binding</title>
|
||||
|
||||
<para>
|
||||
@ -531,9 +529,9 @@ colors are read-only (shareable). XCupStoreColors returns the number of
|
||||
colors that were successfully allocated in the colormap.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Using_the_TOG_CUP_extension_and_Colormap_Utilization_Policy">
|
||||
<chapter id="Using_the_TOG_CUP_extension_and_Colormap_Utilization_Policy">
|
||||
<title>Using the TOG-CUP extension and Colormap Utilization Policy</title>
|
||||
<para>
|
||||
The X server preallocates any hardware or desktop special colors in the
|
||||
@ -557,6 +555,6 @@ using XCupStoreColors the colors will be allocated sharable (read-only) and
|
||||
any other application which allocates the same color will share that color
|
||||
cell.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
||||
@ -59,10 +59,7 @@ in this Software without prior written authorization from the X Consortium.
|
||||
</bookinfo>
|
||||
|
||||
|
||||
<chapter>
|
||||
<title>TITLE</title>
|
||||
|
||||
<sect1 id="Overview">
|
||||
<chapter id="Overview">
|
||||
<title>Overview</title>
|
||||
<para>
|
||||
This extension is a minimal set of client and server extensions
|
||||
@ -110,9 +107,9 @@ Minimize performance penalties on normal server operation.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Description">
|
||||
<chapter id="Description">
|
||||
<title>Description</title>
|
||||
<para>
|
||||
The functions provided by this extension fall into two groups:
|
||||
@ -167,9 +164,9 @@ or pressed a key or button.
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Types">
|
||||
<chapter id="Types">
|
||||
<title>Types</title>
|
||||
<para>
|
||||
The following types are used in the request and event definitions in
|
||||
@ -223,9 +220,9 @@ CURSOR { <function>CurrentCursor</function>, <function> None</function> }
|
||||
or a cursor as defined by the X11 Protocol.
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Client_Operations">
|
||||
<chapter id="Client_Operations">
|
||||
<title>Client Operations</title>
|
||||
|
||||
<para>
|
||||
@ -330,9 +327,9 @@ in the buffer and
|
||||
<function>False</function>
|
||||
otherwise.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Server_Requests">
|
||||
<chapter id="Server_Requests">
|
||||
<title>Server Requests</title>
|
||||
<para>
|
||||
<function>XTestGetVersion</function>
|
||||
@ -607,9 +604,9 @@ If impervious is
|
||||
then the executing client returns to the normal state of being
|
||||
susceptible to server grabs.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="Encoding">
|
||||
<chapter id="Encoding">
|
||||
<title>Encoding</title>
|
||||
<para>
|
||||
Please refer to the X11 Protocol Encoding document as this document uses
|
||||
@ -620,7 +617,7 @@ conventions established there.
|
||||
The name of this extension is "XTEST".
|
||||
</para>
|
||||
|
||||
<sect2 id="New_Types">
|
||||
<sect1 id="New_Types">
|
||||
<title>New Types</title>
|
||||
<literallayout class="monospaced">
|
||||
FAKE_EVENT_TYPE
|
||||
@ -635,9 +632,9 @@ FAKE_EVENT_TYPE
|
||||
NOTE that the above values are defined to be the same as those for
|
||||
the corresponding core protocol event types.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect2 id="Requests">
|
||||
<sect1 id="Requests">
|
||||
<title>Requests</title>
|
||||
|
||||
<literallayout class="monospaced">
|
||||
@ -700,10 +697,10 @@ the corresponding core protocol event types.
|
||||
1 BOOL impervious
|
||||
3 unused
|
||||
</literallayout>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
<sect1 id="References">
|
||||
<chapter id="References">
|
||||
<title>References</title>
|
||||
<para>
|
||||
Annicchiarico, D., et al.,
|
||||
@ -717,6 +714,6 @@ Drake, K. J.,
|
||||
Minimum X11 Testing Extension</emphasis>.
|
||||
UniSoft Ltd., June 1991.
|
||||
</para>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
||||
@ -54,7 +54,7 @@ PERFORMANCE OF THIS SOFTWARE.
|
||||
#define SYNC_NAME "SYNC"
|
||||
|
||||
#define SYNC_MAJOR_VERSION 3
|
||||
#define SYNC_MINOR_VERSION 0
|
||||
#define SYNC_MINOR_VERSION 1
|
||||
|
||||
|
||||
#define XSyncCounterNotify 0
|
||||
@ -65,7 +65,8 @@ PERFORMANCE OF THIS SOFTWARE.
|
||||
|
||||
#define XSyncBadCounter 0L
|
||||
#define XSyncBadAlarm 1L
|
||||
#define XSyncNumberErrors (XSyncBadAlarm + 1)
|
||||
#define XSyncBadFence 2L
|
||||
#define XSyncNumberErrors (XSyncBadFence + 1)
|
||||
|
||||
/*
|
||||
* Flags for Alarm Attributes
|
||||
@ -172,6 +173,7 @@ typedef enum {
|
||||
|
||||
typedef XID XSyncCounter;
|
||||
typedef XID XSyncAlarm;
|
||||
typedef XID XSyncFence;
|
||||
typedef struct _XSyncValue {
|
||||
int hi;
|
||||
unsigned int lo;
|
||||
|
||||
@ -67,6 +67,12 @@ PERFORMANCE OF THIS SOFTWARE.
|
||||
#define X_SyncDestroyAlarm 11
|
||||
#define X_SyncSetPriority 12
|
||||
#define X_SyncGetPriority 13
|
||||
#define X_SyncCreateFence 14
|
||||
#define X_SyncTriggerFence 15
|
||||
#define X_SyncResetFence 16
|
||||
#define X_SyncDestroyFence 17
|
||||
#define X_SyncQueryFence 18
|
||||
#define X_SyncAwaitFence 19
|
||||
|
||||
/* cover up types from sync.h to make sure they're the right size for
|
||||
* protocol packaging. These will be undef'ed after all the protocol
|
||||
@ -74,6 +80,8 @@ PERFORMANCE OF THIS SOFTWARE.
|
||||
*/
|
||||
#define XSyncCounter CARD32
|
||||
#define XSyncAlarm CARD32
|
||||
#define XSyncFence CARD32
|
||||
#define Drawable CARD32
|
||||
|
||||
/*
|
||||
* Initialize
|
||||
@ -336,6 +344,92 @@ typedef struct {
|
||||
} xSyncGetPriorityReply;
|
||||
#define sz_xSyncGetPriorityReply 32
|
||||
|
||||
/*
|
||||
* Create Fence
|
||||
*/
|
||||
typedef struct _xSyncCreateFenceReq {
|
||||
CARD8 reqType;
|
||||
CARD8 syncReqType;
|
||||
CARD16 length B16;
|
||||
Drawable d B32;
|
||||
XSyncFence fid B32;
|
||||
BOOL initially_triggered;
|
||||
CARD8 pad0;
|
||||
CARD16 pad1;
|
||||
} xSyncCreateFenceReq;
|
||||
#define sz_xSyncCreateFenceReq 16
|
||||
|
||||
/*
|
||||
* Put a fence object in the "triggered" state.
|
||||
*/
|
||||
typedef struct _xSyncTriggerFenceReq {
|
||||
CARD8 reqType;
|
||||
CARD8 syncReqType;
|
||||
CARD16 length B16;
|
||||
XSyncFence fid B32;
|
||||
} xSyncTriggerFenceReq;
|
||||
#define sz_xSyncTriggerFenceReq 8
|
||||
|
||||
/*
|
||||
* Put a fence in the "untriggered" state.
|
||||
*/
|
||||
typedef struct _xSyncResetFenceReq {
|
||||
CARD8 reqType;
|
||||
CARD8 syncReqType;
|
||||
CARD16 length B16;
|
||||
XSyncFence fid B32;
|
||||
} xSyncResetFenceReq;
|
||||
#define sz_xSyncResetFenceReq 8
|
||||
|
||||
/*
|
||||
* Destroy a fence object
|
||||
*/
|
||||
typedef struct _xSyncDestroyFenceReq {
|
||||
CARD8 reqType;
|
||||
CARD8 syncReqType;
|
||||
CARD16 length B16;
|
||||
XSyncFence fid B32;
|
||||
} xSyncDestroyFenceReq;
|
||||
#define sz_xSyncDestroyFenceReq 8
|
||||
|
||||
/*
|
||||
* Query a fence object
|
||||
*/
|
||||
typedef struct _xSyncQueryFenceReq {
|
||||
CARD8 reqType;
|
||||
CARD8 syncReqType;
|
||||
CARD16 length B16;
|
||||
XSyncFence fid B32;
|
||||
} xSyncQueryFenceReq;
|
||||
#define sz_xSyncQueryFenceReq 8
|
||||
|
||||
/*
|
||||
* Wait for any of a list of fence sync objects
|
||||
* to reach the "triggered" state.
|
||||
*/
|
||||
typedef struct _xSyncAwaitFenceReq {
|
||||
CARD8 reqType;
|
||||
CARD8 syncReqType;
|
||||
CARD16 length B16;
|
||||
} xSyncAwaitFenceReq;
|
||||
#define sz_xSyncAwaitFenceReq 4
|
||||
|
||||
typedef struct {
|
||||
BYTE type;
|
||||
CARD8 unused;
|
||||
CARD16 sequenceNumber B16;
|
||||
CARD32 length B32;
|
||||
BOOL triggered;
|
||||
BYTE pad0;
|
||||
CARD16 pad1 B16;
|
||||
CARD32 pad2 B32;
|
||||
CARD32 pad3 B32;
|
||||
CARD32 pad4 B32;
|
||||
CARD32 pad5 B32;
|
||||
CARD32 pad6 B32;
|
||||
} xSyncQueryFenceReply;
|
||||
#define sz_xSyncQueryFenceReply 32
|
||||
|
||||
/*
|
||||
* Events
|
||||
*/
|
||||
@ -373,6 +467,8 @@ typedef struct _xSyncAlarmNotifyEvent {
|
||||
|
||||
#undef XSyncCounter
|
||||
#undef XSyncAlarm
|
||||
#undef XSyncFence
|
||||
#undef Drawable
|
||||
|
||||
|
||||
#endif /* _SYNCPROTO_H_ */
|
||||
|
||||
@ -1,4 +1,3 @@
|
||||
/* $Xorg: syncstr.h,v 1.4 2001/02/09 02:03:24 xorgcvs Exp $ */
|
||||
/*
|
||||
|
||||
Copyright 1991, 1993, 1994, 1998 The Open Group
|
||||
@ -48,7 +47,6 @@ OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
|
||||
PERFORMANCE OF THIS SOFTWARE.
|
||||
|
||||
******************************************************************/
|
||||
/* $XFree86: xc/include/extensions/syncstr.h,v 1.3 2003/07/16 01:38:24 dawes Exp $ */
|
||||
|
||||
#ifndef _SYNCSTR_H_
|
||||
#define _SYNCSTR_H_
|
||||
|
||||
Loading…
Reference in New Issue
Block a user