xorgproto-2023.2/ 0000755 0001750 0001750 00000000000 14443010036 010641 5 0000000 0000000 xorgproto-2023.2/fontcacheproto.pc.in 0000644 0001750 0001750 00000000217 14443010026 014527 0000000 0000000 prefix=@prefix@
includedir=@includedir@
Name: FontcacheProto
Description: Fontcache extension headers
Version: 0.1.3
Cflags: -I${includedir}
xorgproto-2023.2/randrproto.pc.in 0000644 0001750 0001750 00000000207 14443010026 013702 0000000 0000000 prefix=@prefix@
includedir=@includedir@
Name: RandrProto
Description: Randr extension headers
Version: 1.6.0
Cflags: -I${includedir}
xorgproto-2023.2/config.guess 0000755 0001750 0001750 00000141205 14443010030 013076 0000000 0000000 #!/usr/bin/sh
# Attempt to guess a canonical system name.
# Copyright 1992-2022 Free Software Foundation, Inc.
# shellcheck disable=SC2006,SC2268 # see below for rationale
timestamp='2022-05-25'
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, see .
# The "shellcheck disable" line above the timestamp inhibits complaints
# about features and limitations of the classic Bourne shell that were
# superseded or lifted in POSIX. However, this script identifies a wide
# variety of pre-POSIX systems that do not have POSIX shells at all, and
# even some reasonably current systems (Solaris 10 as case-in-point) still
# have a pre-POSIX /bin/sh.
me=`echo "$0" | sed -e 's,.*/,,'`
usage="\
Usage: $0 [OPTION]
Output the configuration name of the system \`$me' is run on.
Options:
-h, --help print this help, then exit
-t, --time-stamp print date of last modification, then exit
-v, --version print version number, then exit
Report bugs and patches to ."
version="\
GNU config.guess ($timestamp)
Originally written by Per Bothner.
Copyright 1992-2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
help="
Try \`$me --help' for more information."
# Parse command line
while test $# -gt 0 ; do
case $1 in
--time-stamp | --time* | -t )
echo "$timestamp" ; exit ;;
--version | -v )
echo "$version" ; exit ;;
--help | --h* | -h )
echo "$usage"; exit ;;
-- ) # Stop option processing
shift; break ;;
- ) # Use stdin as input.
break ;;
-* )
echo "$me: invalid option $1$help" >&2
exit 1 ;;
* )
break ;;
esac
done
if test $# != 0; then
echo "$me: too many arguments$help" >&2
exit 1
fi
# Just in case it came from the environment.
GUESS=
# CC_FOR_BUILD -- compiler used by this script. Note that the use of a
# compiler to aid in system detection is discouraged as it requires
# temporary files to be created and, as you can see below, it is a
# headache to deal with in a portable fashion.
# Historically, `CC_FOR_BUILD' used to be named `HOST_CC'. We still
# use `HOST_CC' if defined, but it is deprecated.
# Portable tmp directory creation inspired by the Autoconf team.
tmp=
# shellcheck disable=SC2172
trap 'test -z "$tmp" || rm -fr "$tmp"' 0 1 2 13 15
set_cc_for_build() {
# prevent multiple calls if $tmp is already set
test "$tmp" && return 0
: "${TMPDIR=/tmp}"
# shellcheck disable=SC2039,SC3028
{ tmp=`(umask 077 && mktemp -d "$TMPDIR/cgXXXXXX") 2>/dev/null` && test -n "$tmp" && test -d "$tmp" ; } ||
{ test -n "$RANDOM" && tmp=$TMPDIR/cg$$-$RANDOM && (umask 077 && mkdir "$tmp" 2>/dev/null) ; } ||
{ tmp=$TMPDIR/cg-$$ && (umask 077 && mkdir "$tmp" 2>/dev/null) && echo "Warning: creating insecure temp directory" >&2 ; } ||
{ echo "$me: cannot create a temporary directory in $TMPDIR" >&2 ; exit 1 ; }
dummy=$tmp/dummy
case ${CC_FOR_BUILD-},${HOST_CC-},${CC-} in
,,) echo "int x;" > "$dummy.c"
for driver in cc gcc c89 c99 ; do
if ($driver -c -o "$dummy.o" "$dummy.c") >/dev/null 2>&1 ; then
CC_FOR_BUILD=$driver
break
fi
done
if test x"$CC_FOR_BUILD" = x ; then
CC_FOR_BUILD=no_compiler_found
fi
;;
,,*) CC_FOR_BUILD=$CC ;;
,*,*) CC_FOR_BUILD=$HOST_CC ;;
esac
}
# This is needed to find uname on a Pyramid OSx when run in the BSD universe.
# (ghazi@noc.rutgers.edu 1994-08-24)
if test -f /.attbin/uname ; then
PATH=$PATH:/.attbin ; export PATH
fi
UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown
UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown
UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown
UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
case $UNAME_SYSTEM in
Linux|GNU|GNU/*)
LIBC=unknown
set_cc_for_build
cat <<-EOF > "$dummy.c"
#include
#if defined(__UCLIBC__)
LIBC=uclibc
#elif defined(__dietlibc__)
LIBC=dietlibc
#elif defined(__GLIBC__)
LIBC=gnu
#else
#include
/* First heuristic to detect musl libc. */
#ifdef __DEFINED_va_list
LIBC=musl
#endif
#endif
EOF
cc_set_libc=`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^LIBC' | sed 's, ,,g'`
eval "$cc_set_libc"
# Second heuristic to detect musl libc.
if [ "$LIBC" = unknown ] &&
command -v ldd >/dev/null &&
ldd --version 2>&1 | grep -q ^musl; then
LIBC=musl
fi
# If the system lacks a compiler, then just pick glibc.
# We could probably try harder.
if [ "$LIBC" = unknown ]; then
LIBC=gnu
fi
;;
esac
# Note: order is significant - the case branches are not exclusive.
case $UNAME_MACHINE:$UNAME_SYSTEM:$UNAME_RELEASE:$UNAME_VERSION in
*:NetBSD:*:*)
# NetBSD (nbsd) targets should (where applicable) match one or
# more of the tuples: *-*-netbsdelf*, *-*-netbsdaout*,
# *-*-netbsdecoff* and *-*-netbsd*. For targets that recently
# switched to ELF, *-*-netbsd* would select the old
# object file format. This provides both forward
# compatibility and a consistent mechanism for selecting the
# object file format.
#
# Note: NetBSD doesn't particularly care about the vendor
# portion of the name. We always set it to "unknown".
UNAME_MACHINE_ARCH=`(uname -p 2>/dev/null || \
/sbin/sysctl -n hw.machine_arch 2>/dev/null || \
/usr/sbin/sysctl -n hw.machine_arch 2>/dev/null || \
echo unknown)`
case $UNAME_MACHINE_ARCH in
aarch64eb) machine=aarch64_be-unknown ;;
armeb) machine=armeb-unknown ;;
arm*) machine=arm-unknown ;;
sh3el) machine=shl-unknown ;;
sh3eb) machine=sh-unknown ;;
sh5el) machine=sh5le-unknown ;;
earmv*)
arch=`echo "$UNAME_MACHINE_ARCH" | sed -e 's,^e\(armv[0-9]\).*$,\1,'`
endian=`echo "$UNAME_MACHINE_ARCH" | sed -ne 's,^.*\(eb\)$,\1,p'`
machine=${arch}${endian}-unknown
;;
*) machine=$UNAME_MACHINE_ARCH-unknown ;;
esac
# The Operating System including object format, if it has switched
# to ELF recently (or will in the future) and ABI.
case $UNAME_MACHINE_ARCH in
earm*)
os=netbsdelf
;;
arm*|i386|m68k|ns32k|sh3*|sparc|vax)
set_cc_for_build
if echo __ELF__ | $CC_FOR_BUILD -E - 2>/dev/null \
| grep -q __ELF__
then
# Once all utilities can be ECOFF (netbsdecoff) or a.out (netbsdaout).
# Return netbsd for either. FIX?
os=netbsd
else
os=netbsdelf
fi
;;
*)
os=netbsd
;;
esac
# Determine ABI tags.
case $UNAME_MACHINE_ARCH in
earm*)
expr='s/^earmv[0-9]/-eabi/;s/eb$//'
abi=`echo "$UNAME_MACHINE_ARCH" | sed -e "$expr"`
;;
esac
# The OS release
# Debian GNU/NetBSD machines have a different userland, and
# thus, need a distinct triplet. However, they do not need
# kernel version information, so it can be replaced with a
# suitable tag, in the style of linux-gnu.
case $UNAME_VERSION in
Debian*)
release='-gnu'
;;
*)
release=`echo "$UNAME_RELEASE" | sed -e 's/[-_].*//' | cut -d. -f1,2`
;;
esac
# Since CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM:
# contains redundant information, the shorter form:
# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used.
GUESS=$machine-${os}${release}${abi-}
;;
*:Bitrig:*:*)
UNAME_MACHINE_ARCH=`arch | sed 's/Bitrig.//'`
GUESS=$UNAME_MACHINE_ARCH-unknown-bitrig$UNAME_RELEASE
;;
*:OpenBSD:*:*)
UNAME_MACHINE_ARCH=`arch | sed 's/OpenBSD.//'`
GUESS=$UNAME_MACHINE_ARCH-unknown-openbsd$UNAME_RELEASE
;;
*:SecBSD:*:*)
UNAME_MACHINE_ARCH=`arch | sed 's/SecBSD.//'`
GUESS=$UNAME_MACHINE_ARCH-unknown-secbsd$UNAME_RELEASE
;;
*:LibertyBSD:*:*)
UNAME_MACHINE_ARCH=`arch | sed 's/^.*BSD\.//'`
GUESS=$UNAME_MACHINE_ARCH-unknown-libertybsd$UNAME_RELEASE
;;
*:MidnightBSD:*:*)
GUESS=$UNAME_MACHINE-unknown-midnightbsd$UNAME_RELEASE
;;
*:ekkoBSD:*:*)
GUESS=$UNAME_MACHINE-unknown-ekkobsd$UNAME_RELEASE
;;
*:SolidBSD:*:*)
GUESS=$UNAME_MACHINE-unknown-solidbsd$UNAME_RELEASE
;;
*:OS108:*:*)
GUESS=$UNAME_MACHINE-unknown-os108_$UNAME_RELEASE
;;
macppc:MirBSD:*:*)
GUESS=powerpc-unknown-mirbsd$UNAME_RELEASE
;;
*:MirBSD:*:*)
GUESS=$UNAME_MACHINE-unknown-mirbsd$UNAME_RELEASE
;;
*:Sortix:*:*)
GUESS=$UNAME_MACHINE-unknown-sortix
;;
*:Twizzler:*:*)
GUESS=$UNAME_MACHINE-unknown-twizzler
;;
*:Redox:*:*)
GUESS=$UNAME_MACHINE-unknown-redox
;;
mips:OSF1:*.*)
GUESS=mips-dec-osf1
;;
alpha:OSF1:*:*)
# Reset EXIT trap before exiting to avoid spurious non-zero exit code.
trap '' 0
case $UNAME_RELEASE in
*4.0)
UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'`
;;
*5.*)
UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $4}'`
;;
esac
# According to Compaq, /usr/sbin/psrinfo has been available on
# OSF/1 and Tru64 systems produced since 1995. I hope that
# covers most systems running today. This code pipes the CPU
# types through head -n 1, so we only detect the type of CPU 0.
ALPHA_CPU_TYPE=`/usr/sbin/psrinfo -v | sed -n -e 's/^ The alpha \(.*\) processor.*$/\1/p' | head -n 1`
case $ALPHA_CPU_TYPE in
"EV4 (21064)")
UNAME_MACHINE=alpha ;;
"EV4.5 (21064)")
UNAME_MACHINE=alpha ;;
"LCA4 (21066/21068)")
UNAME_MACHINE=alpha ;;
"EV5 (21164)")
UNAME_MACHINE=alphaev5 ;;
"EV5.6 (21164A)")
UNAME_MACHINE=alphaev56 ;;
"EV5.6 (21164PC)")
UNAME_MACHINE=alphapca56 ;;
"EV5.7 (21164PC)")
UNAME_MACHINE=alphapca57 ;;
"EV6 (21264)")
UNAME_MACHINE=alphaev6 ;;
"EV6.7 (21264A)")
UNAME_MACHINE=alphaev67 ;;
"EV6.8CB (21264C)")
UNAME_MACHINE=alphaev68 ;;
"EV6.8AL (21264B)")
UNAME_MACHINE=alphaev68 ;;
"EV6.8CX (21264D)")
UNAME_MACHINE=alphaev68 ;;
"EV6.9A (21264/EV69A)")
UNAME_MACHINE=alphaev69 ;;
"EV7 (21364)")
UNAME_MACHINE=alphaev7 ;;
"EV7.9 (21364A)")
UNAME_MACHINE=alphaev79 ;;
esac
# A Pn.n version is a patched version.
# A Vn.n version is a released version.
# A Tn.n version is a released field test version.
# A Xn.n version is an unreleased experimental baselevel.
# 1.2 uses "1.2" for uname -r.
OSF_REL=`echo "$UNAME_RELEASE" | sed -e 's/^[PVTX]//' | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz`
GUESS=$UNAME_MACHINE-dec-osf$OSF_REL
;;
Amiga*:UNIX_System_V:4.0:*)
GUESS=m68k-unknown-sysv4
;;
*:[Aa]miga[Oo][Ss]:*:*)
GUESS=$UNAME_MACHINE-unknown-amigaos
;;
*:[Mm]orph[Oo][Ss]:*:*)
GUESS=$UNAME_MACHINE-unknown-morphos
;;
*:OS/390:*:*)
GUESS=i370-ibm-openedition
;;
*:z/VM:*:*)
GUESS=s390-ibm-zvmoe
;;
*:OS400:*:*)
GUESS=powerpc-ibm-os400
;;
arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*)
GUESS=arm-acorn-riscix$UNAME_RELEASE
;;
arm*:riscos:*:*|arm*:RISCOS:*:*)
GUESS=arm-unknown-riscos
;;
SR2?01:HI-UX/MPP:*:* | SR8000:HI-UX/MPP:*:*)
GUESS=hppa1.1-hitachi-hiuxmpp
;;
Pyramid*:OSx*:*:* | MIS*:OSx*:*:* | MIS*:SMP_DC-OSx*:*:*)
# akee@wpdis03.wpafb.af.mil (Earle F. Ake) contributed MIS and NILE.
case `(/bin/universe) 2>/dev/null` in
att) GUESS=pyramid-pyramid-sysv3 ;;
*) GUESS=pyramid-pyramid-bsd ;;
esac
;;
NILE*:*:*:dcosx)
GUESS=pyramid-pyramid-svr4
;;
DRS?6000:unix:4.0:6*)
GUESS=sparc-icl-nx6
;;
DRS?6000:UNIX_SV:4.2*:7* | DRS?6000:isis:4.2*:7*)
case `/usr/bin/uname -p` in
sparc) GUESS=sparc-icl-nx7 ;;
esac
;;
s390x:SunOS:*:*)
SUN_REL=`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`
GUESS=$UNAME_MACHINE-ibm-solaris2$SUN_REL
;;
sun4H:SunOS:5.*:*)
SUN_REL=`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`
GUESS=sparc-hal-solaris2$SUN_REL
;;
sun4*:SunOS:5.*:* | tadpole*:SunOS:5.*:*)
SUN_REL=`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`
GUESS=sparc-sun-solaris2$SUN_REL
;;
i86pc:AuroraUX:5.*:* | i86xen:AuroraUX:5.*:*)
GUESS=i386-pc-auroraux$UNAME_RELEASE
;;
i86pc:SunOS:5.*:* | i86xen:SunOS:5.*:*)
set_cc_for_build
SUN_ARCH=i386
# If there is a compiler, see if it is configured for 64-bit objects.
# Note that the Sun cc does not turn __LP64__ into 1 like gcc does.
# This test works for both compilers.
if test "$CC_FOR_BUILD" != no_compiler_found; then
if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \
(CCOPTS="" $CC_FOR_BUILD -m64 -E - 2>/dev/null) | \
grep IS_64BIT_ARCH >/dev/null
then
SUN_ARCH=x86_64
fi
fi
SUN_REL=`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`
GUESS=$SUN_ARCH-pc-solaris2$SUN_REL
;;
sun4*:SunOS:6*:*)
# According to config.sub, this is the proper way to canonicalize
# SunOS6. Hard to guess exactly what SunOS6 will be like, but
# it's likely to be more like Solaris than SunOS4.
SUN_REL=`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`
GUESS=sparc-sun-solaris3$SUN_REL
;;
sun4*:SunOS:*:*)
case `/usr/bin/arch -k` in
Series*|S4*)
UNAME_RELEASE=`uname -v`
;;
esac
# Japanese Language versions have a version number like `4.1.3-JL'.
SUN_REL=`echo "$UNAME_RELEASE" | sed -e 's/-/_/'`
GUESS=sparc-sun-sunos$SUN_REL
;;
sun3*:SunOS:*:*)
GUESS=m68k-sun-sunos$UNAME_RELEASE
;;
sun*:*:4.2BSD:*)
UNAME_RELEASE=`(sed 1q /etc/motd | awk '{print substr($5,1,3)}') 2>/dev/null`
test "x$UNAME_RELEASE" = x && UNAME_RELEASE=3
case `/bin/arch` in
sun3)
GUESS=m68k-sun-sunos$UNAME_RELEASE
;;
sun4)
GUESS=sparc-sun-sunos$UNAME_RELEASE
;;
esac
;;
aushp:SunOS:*:*)
GUESS=sparc-auspex-sunos$UNAME_RELEASE
;;
# The situation for MiNT is a little confusing. The machine name
# can be virtually everything (everything which is not
# "atarist" or "atariste" at least should have a processor
# > m68000). The system name ranges from "MiNT" over "FreeMiNT"
# to the lowercase version "mint" (or "freemint"). Finally
# the system name "TOS" denotes a system which is actually not
# MiNT. But MiNT is downward compatible to TOS, so this should
# be no problem.
atarist[e]:*MiNT:*:* | atarist[e]:*mint:*:* | atarist[e]:*TOS:*:*)
GUESS=m68k-atari-mint$UNAME_RELEASE
;;
atari*:*MiNT:*:* | atari*:*mint:*:* | atarist[e]:*TOS:*:*)
GUESS=m68k-atari-mint$UNAME_RELEASE
;;
*falcon*:*MiNT:*:* | *falcon*:*mint:*:* | *falcon*:*TOS:*:*)
GUESS=m68k-atari-mint$UNAME_RELEASE
;;
milan*:*MiNT:*:* | milan*:*mint:*:* | *milan*:*TOS:*:*)
GUESS=m68k-milan-mint$UNAME_RELEASE
;;
hades*:*MiNT:*:* | hades*:*mint:*:* | *hades*:*TOS:*:*)
GUESS=m68k-hades-mint$UNAME_RELEASE
;;
*:*MiNT:*:* | *:*mint:*:* | *:*TOS:*:*)
GUESS=m68k-unknown-mint$UNAME_RELEASE
;;
m68k:machten:*:*)
GUESS=m68k-apple-machten$UNAME_RELEASE
;;
powerpc:machten:*:*)
GUESS=powerpc-apple-machten$UNAME_RELEASE
;;
RISC*:Mach:*:*)
GUESS=mips-dec-mach_bsd4.3
;;
RISC*:ULTRIX:*:*)
GUESS=mips-dec-ultrix$UNAME_RELEASE
;;
VAX*:ULTRIX*:*:*)
GUESS=vax-dec-ultrix$UNAME_RELEASE
;;
2020:CLIX:*:* | 2430:CLIX:*:*)
GUESS=clipper-intergraph-clix$UNAME_RELEASE
;;
mips:*:*:UMIPS | mips:*:*:RISCos)
set_cc_for_build
sed 's/^ //' << EOF > "$dummy.c"
#ifdef __cplusplus
#include /* for printf() prototype */
int main (int argc, char *argv[]) {
#else
int main (argc, argv) int argc; char *argv[]; {
#endif
#if defined (host_mips) && defined (MIPSEB)
#if defined (SYSTYPE_SYSV)
printf ("mips-mips-riscos%ssysv\\n", argv[1]); exit (0);
#endif
#if defined (SYSTYPE_SVR4)
printf ("mips-mips-riscos%ssvr4\\n", argv[1]); exit (0);
#endif
#if defined (SYSTYPE_BSD43) || defined(SYSTYPE_BSD)
printf ("mips-mips-riscos%sbsd\\n", argv[1]); exit (0);
#endif
#endif
exit (-1);
}
EOF
$CC_FOR_BUILD -o "$dummy" "$dummy.c" &&
dummyarg=`echo "$UNAME_RELEASE" | sed -n 's/\([0-9]*\).*/\1/p'` &&
SYSTEM_NAME=`"$dummy" "$dummyarg"` &&
{ echo "$SYSTEM_NAME"; exit; }
GUESS=mips-mips-riscos$UNAME_RELEASE
;;
Motorola:PowerMAX_OS:*:*)
GUESS=powerpc-motorola-powermax
;;
Motorola:*:4.3:PL8-*)
GUESS=powerpc-harris-powermax
;;
Night_Hawk:*:*:PowerMAX_OS | Synergy:PowerMAX_OS:*:*)
GUESS=powerpc-harris-powermax
;;
Night_Hawk:Power_UNIX:*:*)
GUESS=powerpc-harris-powerunix
;;
m88k:CX/UX:7*:*)
GUESS=m88k-harris-cxux7
;;
m88k:*:4*:R4*)
GUESS=m88k-motorola-sysv4
;;
m88k:*:3*:R3*)
GUESS=m88k-motorola-sysv3
;;
AViiON:dgux:*:*)
# DG/UX returns AViiON for all architectures
UNAME_PROCESSOR=`/usr/bin/uname -p`
if test "$UNAME_PROCESSOR" = mc88100 || test "$UNAME_PROCESSOR" = mc88110
then
if test "$TARGET_BINARY_INTERFACE"x = m88kdguxelfx || \
test "$TARGET_BINARY_INTERFACE"x = x
then
GUESS=m88k-dg-dgux$UNAME_RELEASE
else
GUESS=m88k-dg-dguxbcs$UNAME_RELEASE
fi
else
GUESS=i586-dg-dgux$UNAME_RELEASE
fi
;;
M88*:DolphinOS:*:*) # DolphinOS (SVR3)
GUESS=m88k-dolphin-sysv3
;;
M88*:*:R3*:*)
# Delta 88k system running SVR3
GUESS=m88k-motorola-sysv3
;;
XD88*:*:*:*) # Tektronix XD88 system running UTekV (SVR3)
GUESS=m88k-tektronix-sysv3
;;
Tek43[0-9][0-9]:UTek:*:*) # Tektronix 4300 system running UTek (BSD)
GUESS=m68k-tektronix-bsd
;;
*:IRIX*:*:*)
IRIX_REL=`echo "$UNAME_RELEASE" | sed -e 's/-/_/g'`
GUESS=mips-sgi-irix$IRIX_REL
;;
????????:AIX?:[12].1:2) # AIX 2.2.1 or AIX 2.1.1 is RT/PC AIX.
GUESS=romp-ibm-aix # uname -m gives an 8 hex-code CPU id
;; # Note that: echo "'`uname -s`'" gives 'AIX '
i*86:AIX:*:*)
GUESS=i386-ibm-aix
;;
ia64:AIX:*:*)
if test -x /usr/bin/oslevel ; then
IBM_REV=`/usr/bin/oslevel`
else
IBM_REV=$UNAME_VERSION.$UNAME_RELEASE
fi
GUESS=$UNAME_MACHINE-ibm-aix$IBM_REV
;;
*:AIX:2:3)
if grep bos325 /usr/include/stdio.h >/dev/null 2>&1; then
set_cc_for_build
sed 's/^ //' << EOF > "$dummy.c"
#include
main()
{
if (!__power_pc())
exit(1);
puts("powerpc-ibm-aix3.2.5");
exit(0);
}
EOF
if $CC_FOR_BUILD -o "$dummy" "$dummy.c" && SYSTEM_NAME=`"$dummy"`
then
GUESS=$SYSTEM_NAME
else
GUESS=rs6000-ibm-aix3.2.5
fi
elif grep bos324 /usr/include/stdio.h >/dev/null 2>&1; then
GUESS=rs6000-ibm-aix3.2.4
else
GUESS=rs6000-ibm-aix3.2
fi
;;
*:AIX:*:[4567])
IBM_CPU_ID=`/usr/sbin/lsdev -C -c processor -S available | sed 1q | awk '{ print $1 }'`
if /usr/sbin/lsattr -El "$IBM_CPU_ID" | grep ' POWER' >/dev/null 2>&1; then
IBM_ARCH=rs6000
else
IBM_ARCH=powerpc
fi
if test -x /usr/bin/lslpp ; then
IBM_REV=`/usr/bin/lslpp -Lqc bos.rte.libc | \
awk -F: '{ print $3 }' | sed s/[0-9]*$/0/`
else
IBM_REV=$UNAME_VERSION.$UNAME_RELEASE
fi
GUESS=$IBM_ARCH-ibm-aix$IBM_REV
;;
*:AIX:*:*)
GUESS=rs6000-ibm-aix
;;
ibmrt:4.4BSD:*|romp-ibm:4.4BSD:*)
GUESS=romp-ibm-bsd4.4
;;
ibmrt:*BSD:*|romp-ibm:BSD:*) # covers RT/PC BSD and
GUESS=romp-ibm-bsd$UNAME_RELEASE # 4.3 with uname added to
;; # report: romp-ibm BSD 4.3
*:BOSX:*:*)
GUESS=rs6000-bull-bosx
;;
DPX/2?00:B.O.S.:*:*)
GUESS=m68k-bull-sysv3
;;
9000/[34]??:4.3bsd:1.*:*)
GUESS=m68k-hp-bsd
;;
hp300:4.4BSD:*:* | 9000/[34]??:4.3bsd:2.*:*)
GUESS=m68k-hp-bsd4.4
;;
9000/[34678]??:HP-UX:*:*)
HPUX_REV=`echo "$UNAME_RELEASE" | sed -e 's/[^.]*.[0B]*//'`
case $UNAME_MACHINE in
9000/31?) HP_ARCH=m68000 ;;
9000/[34]??) HP_ARCH=m68k ;;
9000/[678][0-9][0-9])
if test -x /usr/bin/getconf; then
sc_cpu_version=`/usr/bin/getconf SC_CPU_VERSION 2>/dev/null`
sc_kernel_bits=`/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null`
case $sc_cpu_version in
523) HP_ARCH=hppa1.0 ;; # CPU_PA_RISC1_0
528) HP_ARCH=hppa1.1 ;; # CPU_PA_RISC1_1
532) # CPU_PA_RISC2_0
case $sc_kernel_bits in
32) HP_ARCH=hppa2.0n ;;
64) HP_ARCH=hppa2.0w ;;
'') HP_ARCH=hppa2.0 ;; # HP-UX 10.20
esac ;;
esac
fi
if test "$HP_ARCH" = ""; then
set_cc_for_build
sed 's/^ //' << EOF > "$dummy.c"
#define _HPUX_SOURCE
#include
#include
int main ()
{
#if defined(_SC_KERNEL_BITS)
long bits = sysconf(_SC_KERNEL_BITS);
#endif
long cpu = sysconf (_SC_CPU_VERSION);
switch (cpu)
{
case CPU_PA_RISC1_0: puts ("hppa1.0"); break;
case CPU_PA_RISC1_1: puts ("hppa1.1"); break;
case CPU_PA_RISC2_0:
#if defined(_SC_KERNEL_BITS)
switch (bits)
{
case 64: puts ("hppa2.0w"); break;
case 32: puts ("hppa2.0n"); break;
default: puts ("hppa2.0"); break;
} break;
#else /* !defined(_SC_KERNEL_BITS) */
puts ("hppa2.0"); break;
#endif
default: puts ("hppa1.0"); break;
}
exit (0);
}
EOF
(CCOPTS="" $CC_FOR_BUILD -o "$dummy" "$dummy.c" 2>/dev/null) && HP_ARCH=`"$dummy"`
test -z "$HP_ARCH" && HP_ARCH=hppa
fi ;;
esac
if test "$HP_ARCH" = hppa2.0w
then
set_cc_for_build
# hppa2.0w-hp-hpux* has a 64-bit kernel and a compiler generating
# 32-bit code. hppa64-hp-hpux* has the same kernel and a compiler
# generating 64-bit code. GNU and HP use different nomenclature:
#
# $ CC_FOR_BUILD=cc ./config.guess
# => hppa2.0w-hp-hpux11.23
# $ CC_FOR_BUILD="cc +DA2.0w" ./config.guess
# => hppa64-hp-hpux11.23
if echo __LP64__ | (CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) |
grep -q __LP64__
then
HP_ARCH=hppa2.0w
else
HP_ARCH=hppa64
fi
fi
GUESS=$HP_ARCH-hp-hpux$HPUX_REV
;;
ia64:HP-UX:*:*)
HPUX_REV=`echo "$UNAME_RELEASE" | sed -e 's/[^.]*.[0B]*//'`
GUESS=ia64-hp-hpux$HPUX_REV
;;
3050*:HI-UX:*:*)
set_cc_for_build
sed 's/^ //' << EOF > "$dummy.c"
#include
int
main ()
{
long cpu = sysconf (_SC_CPU_VERSION);
/* The order matters, because CPU_IS_HP_MC68K erroneously returns
true for CPU_PA_RISC1_0. CPU_IS_PA_RISC returns correct
results, however. */
if (CPU_IS_PA_RISC (cpu))
{
switch (cpu)
{
case CPU_PA_RISC1_0: puts ("hppa1.0-hitachi-hiuxwe2"); break;
case CPU_PA_RISC1_1: puts ("hppa1.1-hitachi-hiuxwe2"); break;
case CPU_PA_RISC2_0: puts ("hppa2.0-hitachi-hiuxwe2"); break;
default: puts ("hppa-hitachi-hiuxwe2"); break;
}
}
else if (CPU_IS_HP_MC68K (cpu))
puts ("m68k-hitachi-hiuxwe2");
else puts ("unknown-hitachi-hiuxwe2");
exit (0);
}
EOF
$CC_FOR_BUILD -o "$dummy" "$dummy.c" && SYSTEM_NAME=`"$dummy"` &&
{ echo "$SYSTEM_NAME"; exit; }
GUESS=unknown-hitachi-hiuxwe2
;;
9000/7??:4.3bsd:*:* | 9000/8?[79]:4.3bsd:*:*)
GUESS=hppa1.1-hp-bsd
;;
9000/8??:4.3bsd:*:*)
GUESS=hppa1.0-hp-bsd
;;
*9??*:MPE/iX:*:* | *3000*:MPE/iX:*:*)
GUESS=hppa1.0-hp-mpeix
;;
hp7??:OSF1:*:* | hp8?[79]:OSF1:*:*)
GUESS=hppa1.1-hp-osf
;;
hp8??:OSF1:*:*)
GUESS=hppa1.0-hp-osf
;;
i*86:OSF1:*:*)
if test -x /usr/sbin/sysversion ; then
GUESS=$UNAME_MACHINE-unknown-osf1mk
else
GUESS=$UNAME_MACHINE-unknown-osf1
fi
;;
parisc*:Lites*:*:*)
GUESS=hppa1.1-hp-lites
;;
C1*:ConvexOS:*:* | convex:ConvexOS:C1*:*)
GUESS=c1-convex-bsd
;;
C2*:ConvexOS:*:* | convex:ConvexOS:C2*:*)
if getsysinfo -f scalar_acc
then echo c32-convex-bsd
else echo c2-convex-bsd
fi
exit ;;
C34*:ConvexOS:*:* | convex:ConvexOS:C34*:*)
GUESS=c34-convex-bsd
;;
C38*:ConvexOS:*:* | convex:ConvexOS:C38*:*)
GUESS=c38-convex-bsd
;;
C4*:ConvexOS:*:* | convex:ConvexOS:C4*:*)
GUESS=c4-convex-bsd
;;
CRAY*Y-MP:*:*:*)
CRAY_REL=`echo "$UNAME_RELEASE" | sed -e 's/\.[^.]*$/.X/'`
GUESS=ymp-cray-unicos$CRAY_REL
;;
CRAY*[A-Z]90:*:*:*)
echo "$UNAME_MACHINE"-cray-unicos"$UNAME_RELEASE" \
| sed -e 's/CRAY.*\([A-Z]90\)/\1/' \
-e y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/ \
-e 's/\.[^.]*$/.X/'
exit ;;
CRAY*TS:*:*:*)
CRAY_REL=`echo "$UNAME_RELEASE" | sed -e 's/\.[^.]*$/.X/'`
GUESS=t90-cray-unicos$CRAY_REL
;;
CRAY*T3E:*:*:*)
CRAY_REL=`echo "$UNAME_RELEASE" | sed -e 's/\.[^.]*$/.X/'`
GUESS=alphaev5-cray-unicosmk$CRAY_REL
;;
CRAY*SV1:*:*:*)
CRAY_REL=`echo "$UNAME_RELEASE" | sed -e 's/\.[^.]*$/.X/'`
GUESS=sv1-cray-unicos$CRAY_REL
;;
*:UNICOS/mp:*:*)
CRAY_REL=`echo "$UNAME_RELEASE" | sed -e 's/\.[^.]*$/.X/'`
GUESS=craynv-cray-unicosmp$CRAY_REL
;;
F30[01]:UNIX_System_V:*:* | F700:UNIX_System_V:*:*)
FUJITSU_PROC=`uname -m | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz`
FUJITSU_SYS=`uname -p | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz | sed -e 's/\///'`
FUJITSU_REL=`echo "$UNAME_RELEASE" | sed -e 's/ /_/'`
GUESS=${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}
;;
5000:UNIX_System_V:4.*:*)
FUJITSU_SYS=`uname -p | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz | sed -e 's/\///'`
FUJITSU_REL=`echo "$UNAME_RELEASE" | tr ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz | sed -e 's/ /_/'`
GUESS=sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}
;;
i*86:BSD/386:*:* | i*86:BSD/OS:*:* | *:Ascend\ Embedded/OS:*:*)
GUESS=$UNAME_MACHINE-pc-bsdi$UNAME_RELEASE
;;
sparc*:BSD/OS:*:*)
GUESS=sparc-unknown-bsdi$UNAME_RELEASE
;;
*:BSD/OS:*:*)
GUESS=$UNAME_MACHINE-unknown-bsdi$UNAME_RELEASE
;;
arm:FreeBSD:*:*)
UNAME_PROCESSOR=`uname -p`
set_cc_for_build
if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
| grep -q __ARM_PCS_VFP
then
FREEBSD_REL=`echo "$UNAME_RELEASE" | sed -e 's/[-(].*//'`
GUESS=$UNAME_PROCESSOR-unknown-freebsd$FREEBSD_REL-gnueabi
else
FREEBSD_REL=`echo "$UNAME_RELEASE" | sed -e 's/[-(].*//'`
GUESS=$UNAME_PROCESSOR-unknown-freebsd$FREEBSD_REL-gnueabihf
fi
;;
*:FreeBSD:*:*)
UNAME_PROCESSOR=`/usr/bin/uname -p`
case $UNAME_PROCESSOR in
amd64)
UNAME_PROCESSOR=x86_64 ;;
i386)
UNAME_PROCESSOR=i586 ;;
esac
FREEBSD_REL=`echo "$UNAME_RELEASE" | sed -e 's/[-(].*//'`
GUESS=$UNAME_PROCESSOR-unknown-freebsd$FREEBSD_REL
;;
i*:CYGWIN*:*)
GUESS=$UNAME_MACHINE-pc-cygwin
;;
*:MINGW64*:*)
GUESS=$UNAME_MACHINE-pc-mingw64
;;
*:MINGW*:*)
GUESS=$UNAME_MACHINE-pc-mingw32
;;
*:MSYS*:*)
GUESS=$UNAME_MACHINE-pc-msys
;;
i*:PW*:*)
GUESS=$UNAME_MACHINE-pc-pw32
;;
*:SerenityOS:*:*)
GUESS=$UNAME_MACHINE-pc-serenity
;;
*:Interix*:*)
case $UNAME_MACHINE in
x86)
GUESS=i586-pc-interix$UNAME_RELEASE
;;
authenticamd | genuineintel | EM64T)
GUESS=x86_64-unknown-interix$UNAME_RELEASE
;;
IA64)
GUESS=ia64-unknown-interix$UNAME_RELEASE
;;
esac ;;
i*:UWIN*:*)
GUESS=$UNAME_MACHINE-pc-uwin
;;
amd64:CYGWIN*:*:* | x86_64:CYGWIN*:*:*)
GUESS=x86_64-pc-cygwin
;;
prep*:SunOS:5.*:*)
SUN_REL=`echo "$UNAME_RELEASE" | sed -e 's/[^.]*//'`
GUESS=powerpcle-unknown-solaris2$SUN_REL
;;
*:GNU:*:*)
# the GNU system
GNU_ARCH=`echo "$UNAME_MACHINE" | sed -e 's,[-/].*$,,'`
GNU_REL=`echo "$UNAME_RELEASE" | sed -e 's,/.*$,,'`
GUESS=$GNU_ARCH-unknown-$LIBC$GNU_REL
;;
*:GNU/*:*:*)
# other systems with GNU libc and userland
GNU_SYS=`echo "$UNAME_SYSTEM" | sed 's,^[^/]*/,,' | tr "[:upper:]" "[:lower:]"`
GNU_REL=`echo "$UNAME_RELEASE" | sed -e 's/[-(].*//'`
GUESS=$UNAME_MACHINE-unknown-$GNU_SYS$GNU_REL-$LIBC
;;
*:Minix:*:*)
GUESS=$UNAME_MACHINE-unknown-minix
;;
aarch64:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
aarch64_be:Linux:*:*)
UNAME_MACHINE=aarch64_be
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
alpha:Linux:*:*)
case `sed -n '/^cpu model/s/^.*: \(.*\)/\1/p' /proc/cpuinfo 2>/dev/null` in
EV5) UNAME_MACHINE=alphaev5 ;;
EV56) UNAME_MACHINE=alphaev56 ;;
PCA56) UNAME_MACHINE=alphapca56 ;;
PCA57) UNAME_MACHINE=alphapca56 ;;
EV6) UNAME_MACHINE=alphaev6 ;;
EV67) UNAME_MACHINE=alphaev67 ;;
EV68*) UNAME_MACHINE=alphaev68 ;;
esac
objdump --private-headers /bin/sh | grep -q ld.so.1
if test "$?" = 0 ; then LIBC=gnulibc1 ; fi
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
arc:Linux:*:* | arceb:Linux:*:* | arc32:Linux:*:* | arc64:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
arm*:Linux:*:*)
set_cc_for_build
if echo __ARM_EABI__ | $CC_FOR_BUILD -E - 2>/dev/null \
| grep -q __ARM_EABI__
then
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
else
if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
| grep -q __ARM_PCS_VFP
then
GUESS=$UNAME_MACHINE-unknown-linux-${LIBC}eabi
else
GUESS=$UNAME_MACHINE-unknown-linux-${LIBC}eabihf
fi
fi
;;
avr32*:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
cris:Linux:*:*)
GUESS=$UNAME_MACHINE-axis-linux-$LIBC
;;
crisv32:Linux:*:*)
GUESS=$UNAME_MACHINE-axis-linux-$LIBC
;;
e2k:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
frv:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
hexagon:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
i*86:Linux:*:*)
GUESS=$UNAME_MACHINE-pc-linux-$LIBC
;;
ia64:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
k1om:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
loongarch32:Linux:*:* | loongarch64:Linux:*:* | loongarchx32:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
m32r*:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
m68*:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
mips:Linux:*:* | mips64:Linux:*:*)
set_cc_for_build
IS_GLIBC=0
test x"${LIBC}" = xgnu && IS_GLIBC=1
sed 's/^ //' << EOF > "$dummy.c"
#undef CPU
#undef mips
#undef mipsel
#undef mips64
#undef mips64el
#if ${IS_GLIBC} && defined(_ABI64)
LIBCABI=gnuabi64
#else
#if ${IS_GLIBC} && defined(_ABIN32)
LIBCABI=gnuabin32
#else
LIBCABI=${LIBC}
#endif
#endif
#if ${IS_GLIBC} && defined(__mips64) && defined(__mips_isa_rev) && __mips_isa_rev>=6
CPU=mipsisa64r6
#else
#if ${IS_GLIBC} && !defined(__mips64) && defined(__mips_isa_rev) && __mips_isa_rev>=6
CPU=mipsisa32r6
#else
#if defined(__mips64)
CPU=mips64
#else
CPU=mips
#endif
#endif
#endif
#if defined(__MIPSEL__) || defined(__MIPSEL) || defined(_MIPSEL) || defined(MIPSEL)
MIPS_ENDIAN=el
#else
#if defined(__MIPSEB__) || defined(__MIPSEB) || defined(_MIPSEB) || defined(MIPSEB)
MIPS_ENDIAN=
#else
MIPS_ENDIAN=
#endif
#endif
EOF
cc_set_vars=`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^CPU\|^MIPS_ENDIAN\|^LIBCABI'`
eval "$cc_set_vars"
test "x$CPU" != x && { echo "$CPU${MIPS_ENDIAN}-unknown-linux-$LIBCABI"; exit; }
;;
mips64el:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
openrisc*:Linux:*:*)
GUESS=or1k-unknown-linux-$LIBC
;;
or32:Linux:*:* | or1k*:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
padre:Linux:*:*)
GUESS=sparc-unknown-linux-$LIBC
;;
parisc64:Linux:*:* | hppa64:Linux:*:*)
GUESS=hppa64-unknown-linux-$LIBC
;;
parisc:Linux:*:* | hppa:Linux:*:*)
# Look for CPU level
case `grep '^cpu[^a-z]*:' /proc/cpuinfo 2>/dev/null | cut -d' ' -f2` in
PA7*) GUESS=hppa1.1-unknown-linux-$LIBC ;;
PA8*) GUESS=hppa2.0-unknown-linux-$LIBC ;;
*) GUESS=hppa-unknown-linux-$LIBC ;;
esac
;;
ppc64:Linux:*:*)
GUESS=powerpc64-unknown-linux-$LIBC
;;
ppc:Linux:*:*)
GUESS=powerpc-unknown-linux-$LIBC
;;
ppc64le:Linux:*:*)
GUESS=powerpc64le-unknown-linux-$LIBC
;;
ppcle:Linux:*:*)
GUESS=powerpcle-unknown-linux-$LIBC
;;
riscv32:Linux:*:* | riscv32be:Linux:*:* | riscv64:Linux:*:* | riscv64be:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
s390:Linux:*:* | s390x:Linux:*:*)
GUESS=$UNAME_MACHINE-ibm-linux-$LIBC
;;
sh64*:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
sh*:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
sparc:Linux:*:* | sparc64:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
tile*:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
vax:Linux:*:*)
GUESS=$UNAME_MACHINE-dec-linux-$LIBC
;;
x86_64:Linux:*:*)
set_cc_for_build
CPU=$UNAME_MACHINE
LIBCABI=$LIBC
if test "$CC_FOR_BUILD" != no_compiler_found; then
ABI=64
sed 's/^ //' << EOF > "$dummy.c"
#ifdef __i386__
ABI=x86
#else
#ifdef __ILP32__
ABI=x32
#endif
#endif
EOF
cc_set_abi=`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^ABI' | sed 's, ,,g'`
eval "$cc_set_abi"
case $ABI in
x86) CPU=i686 ;;
x32) LIBCABI=${LIBC}x32 ;;
esac
fi
GUESS=$CPU-pc-linux-$LIBCABI
;;
xtensa*:Linux:*:*)
GUESS=$UNAME_MACHINE-unknown-linux-$LIBC
;;
i*86:DYNIX/ptx:4*:*)
# ptx 4.0 does uname -s correctly, with DYNIX/ptx in there.
# earlier versions are messed up and put the nodename in both
# sysname and nodename.
GUESS=i386-sequent-sysv4
;;
i*86:UNIX_SV:4.2MP:2.*)
# Unixware is an offshoot of SVR4, but it has its own version
# number series starting with 2...
# I am not positive that other SVR4 systems won't match this,
# I just have to hope. -- rms.
# Use sysv4.2uw... so that sysv4* matches it.
GUESS=$UNAME_MACHINE-pc-sysv4.2uw$UNAME_VERSION
;;
i*86:OS/2:*:*)
# If we were able to find `uname', then EMX Unix compatibility
# is probably installed.
GUESS=$UNAME_MACHINE-pc-os2-emx
;;
i*86:XTS-300:*:STOP)
GUESS=$UNAME_MACHINE-unknown-stop
;;
i*86:atheos:*:*)
GUESS=$UNAME_MACHINE-unknown-atheos
;;
i*86:syllable:*:*)
GUESS=$UNAME_MACHINE-pc-syllable
;;
i*86:LynxOS:2.*:* | i*86:LynxOS:3.[01]*:* | i*86:LynxOS:4.[02]*:*)
GUESS=i386-unknown-lynxos$UNAME_RELEASE
;;
i*86:*DOS:*:*)
GUESS=$UNAME_MACHINE-pc-msdosdjgpp
;;
i*86:*:4.*:*)
UNAME_REL=`echo "$UNAME_RELEASE" | sed 's/\/MP$//'`
if grep Novell /usr/include/link.h >/dev/null 2>/dev/null; then
GUESS=$UNAME_MACHINE-univel-sysv$UNAME_REL
else
GUESS=$UNAME_MACHINE-pc-sysv$UNAME_REL
fi
;;
i*86:*:5:[678]*)
# UnixWare 7.x, OpenUNIX and OpenServer 6.
case `/bin/uname -X | grep "^Machine"` in
*486*) UNAME_MACHINE=i486 ;;
*Pentium) UNAME_MACHINE=i586 ;;
*Pent*|*Celeron) UNAME_MACHINE=i686 ;;
esac
GUESS=$UNAME_MACHINE-unknown-sysv${UNAME_RELEASE}${UNAME_SYSTEM}${UNAME_VERSION}
;;
i*86:*:3.2:*)
if test -f /usr/options/cb.name; then
UNAME_REL=`sed -n 's/.*Version //p' /dev/null >/dev/null ; then
UNAME_REL=`(/bin/uname -X|grep Release|sed -e 's/.*= //')`
(/bin/uname -X|grep i80486 >/dev/null) && UNAME_MACHINE=i486
(/bin/uname -X|grep '^Machine.*Pentium' >/dev/null) \
&& UNAME_MACHINE=i586
(/bin/uname -X|grep '^Machine.*Pent *II' >/dev/null) \
&& UNAME_MACHINE=i686
(/bin/uname -X|grep '^Machine.*Pentium Pro' >/dev/null) \
&& UNAME_MACHINE=i686
GUESS=$UNAME_MACHINE-pc-sco$UNAME_REL
else
GUESS=$UNAME_MACHINE-pc-sysv32
fi
;;
pc:*:*:*)
# Left here for compatibility:
# uname -m prints for DJGPP always 'pc', but it prints nothing about
# the processor, so we play safe by assuming i586.
# Note: whatever this is, it MUST be the same as what config.sub
# prints for the "djgpp" host, or else GDB configure will decide that
# this is a cross-build.
GUESS=i586-pc-msdosdjgpp
;;
Intel:Mach:3*:*)
GUESS=i386-pc-mach3
;;
paragon:*:*:*)
GUESS=i860-intel-osf1
;;
i860:*:4.*:*) # i860-SVR4
if grep Stardent /usr/include/sys/uadmin.h >/dev/null 2>&1 ; then
GUESS=i860-stardent-sysv$UNAME_RELEASE # Stardent Vistra i860-SVR4
else # Add other i860-SVR4 vendors below as they are discovered.
GUESS=i860-unknown-sysv$UNAME_RELEASE # Unknown i860-SVR4
fi
;;
mini*:CTIX:SYS*5:*)
# "miniframe"
GUESS=m68010-convergent-sysv
;;
mc68k:UNIX:SYSTEM5:3.51m)
GUESS=m68k-convergent-sysv
;;
M680?0:D-NIX:5.3:*)
GUESS=m68k-diab-dnix
;;
M68*:*:R3V[5678]*:*)
test -r /sysV68 && { echo 'm68k-motorola-sysv'; exit; } ;;
3[345]??:*:4.0:3.0 | 3[34]??A:*:4.0:3.0 | 3[34]??,*:*:4.0:3.0 | 3[34]??/*:*:4.0:3.0 | 4400:*:4.0:3.0 | 4850:*:4.0:3.0 | SKA40:*:4.0:3.0 | SDS2:*:4.0:3.0 | SHG2:*:4.0:3.0 | S7501*:*:4.0:3.0)
OS_REL=''
test -r /etc/.relid \
&& OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
&& { echo i486-ncr-sysv4.3"$OS_REL"; exit; }
/bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
&& { echo i586-ncr-sysv4.3"$OS_REL"; exit; } ;;
3[34]??:*:4.0:* | 3[34]??,*:*:4.0:*)
/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
&& { echo i486-ncr-sysv4; exit; } ;;
NCR*:*:4.2:* | MPRAS*:*:4.2:*)
OS_REL='.3'
test -r /etc/.relid \
&& OS_REL=.`sed -n 's/[^ ]* [^ ]* \([0-9][0-9]\).*/\1/p' < /etc/.relid`
/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
&& { echo i486-ncr-sysv4.3"$OS_REL"; exit; }
/bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
&& { echo i586-ncr-sysv4.3"$OS_REL"; exit; }
/bin/uname -p 2>/dev/null | /bin/grep pteron >/dev/null \
&& { echo i586-ncr-sysv4.3"$OS_REL"; exit; } ;;
m68*:LynxOS:2.*:* | m68*:LynxOS:3.0*:*)
GUESS=m68k-unknown-lynxos$UNAME_RELEASE
;;
mc68030:UNIX_System_V:4.*:*)
GUESS=m68k-atari-sysv4
;;
TSUNAMI:LynxOS:2.*:*)
GUESS=sparc-unknown-lynxos$UNAME_RELEASE
;;
rs6000:LynxOS:2.*:*)
GUESS=rs6000-unknown-lynxos$UNAME_RELEASE
;;
PowerPC:LynxOS:2.*:* | PowerPC:LynxOS:3.[01]*:* | PowerPC:LynxOS:4.[02]*:*)
GUESS=powerpc-unknown-lynxos$UNAME_RELEASE
;;
SM[BE]S:UNIX_SV:*:*)
GUESS=mips-dde-sysv$UNAME_RELEASE
;;
RM*:ReliantUNIX-*:*:*)
GUESS=mips-sni-sysv4
;;
RM*:SINIX-*:*:*)
GUESS=mips-sni-sysv4
;;
*:SINIX-*:*:*)
if uname -p 2>/dev/null >/dev/null ; then
UNAME_MACHINE=`(uname -p) 2>/dev/null`
GUESS=$UNAME_MACHINE-sni-sysv4
else
GUESS=ns32k-sni-sysv
fi
;;
PENTIUM:*:4.0*:*) # Unisys `ClearPath HMP IX 4000' SVR4/MP effort
# says
GUESS=i586-unisys-sysv4
;;
*:UNIX_System_V:4*:FTX*)
# From Gerald Hewes .
# How about differentiating between stratus architectures? -djm
GUESS=hppa1.1-stratus-sysv4
;;
*:*:*:FTX*)
# From seanf@swdc.stratus.com.
GUESS=i860-stratus-sysv4
;;
i*86:VOS:*:*)
# From Paul.Green@stratus.com.
GUESS=$UNAME_MACHINE-stratus-vos
;;
*:VOS:*:*)
# From Paul.Green@stratus.com.
GUESS=hppa1.1-stratus-vos
;;
mc68*:A/UX:*:*)
GUESS=m68k-apple-aux$UNAME_RELEASE
;;
news*:NEWS-OS:6*:*)
GUESS=mips-sony-newsos6
;;
R[34]000:*System_V*:*:* | R4000:UNIX_SYSV:*:* | R*000:UNIX_SV:*:*)
if test -d /usr/nec; then
GUESS=mips-nec-sysv$UNAME_RELEASE
else
GUESS=mips-unknown-sysv$UNAME_RELEASE
fi
;;
BeBox:BeOS:*:*) # BeOS running on hardware made by Be, PPC only.
GUESS=powerpc-be-beos
;;
BeMac:BeOS:*:*) # BeOS running on Mac or Mac clone, PPC only.
GUESS=powerpc-apple-beos
;;
BePC:BeOS:*:*) # BeOS running on Intel PC compatible.
GUESS=i586-pc-beos
;;
BePC:Haiku:*:*) # Haiku running on Intel PC compatible.
GUESS=i586-pc-haiku
;;
ppc:Haiku:*:*) # Haiku running on Apple PowerPC
GUESS=powerpc-apple-haiku
;;
*:Haiku:*:*) # Haiku modern gcc (not bound by BeOS compat)
GUESS=$UNAME_MACHINE-unknown-haiku
;;
SX-4:SUPER-UX:*:*)
GUESS=sx4-nec-superux$UNAME_RELEASE
;;
SX-5:SUPER-UX:*:*)
GUESS=sx5-nec-superux$UNAME_RELEASE
;;
SX-6:SUPER-UX:*:*)
GUESS=sx6-nec-superux$UNAME_RELEASE
;;
SX-7:SUPER-UX:*:*)
GUESS=sx7-nec-superux$UNAME_RELEASE
;;
SX-8:SUPER-UX:*:*)
GUESS=sx8-nec-superux$UNAME_RELEASE
;;
SX-8R:SUPER-UX:*:*)
GUESS=sx8r-nec-superux$UNAME_RELEASE
;;
SX-ACE:SUPER-UX:*:*)
GUESS=sxace-nec-superux$UNAME_RELEASE
;;
Power*:Rhapsody:*:*)
GUESS=powerpc-apple-rhapsody$UNAME_RELEASE
;;
*:Rhapsody:*:*)
GUESS=$UNAME_MACHINE-apple-rhapsody$UNAME_RELEASE
;;
arm64:Darwin:*:*)
GUESS=aarch64-apple-darwin$UNAME_RELEASE
;;
*:Darwin:*:*)
UNAME_PROCESSOR=`uname -p`
case $UNAME_PROCESSOR in
unknown) UNAME_PROCESSOR=powerpc ;;
esac
if command -v xcode-select > /dev/null 2> /dev/null && \
! xcode-select --print-path > /dev/null 2> /dev/null ; then
# Avoid executing cc if there is no toolchain installed as
# cc will be a stub that puts up a graphical alert
# prompting the user to install developer tools.
CC_FOR_BUILD=no_compiler_found
else
set_cc_for_build
fi
if test "$CC_FOR_BUILD" != no_compiler_found; then
if (echo '#ifdef __LP64__'; echo IS_64BIT_ARCH; echo '#endif') | \
(CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
grep IS_64BIT_ARCH >/dev/null
then
case $UNAME_PROCESSOR in
i386) UNAME_PROCESSOR=x86_64 ;;
powerpc) UNAME_PROCESSOR=powerpc64 ;;
esac
fi
# On 10.4-10.6 one might compile for PowerPC via gcc -arch ppc
if (echo '#ifdef __POWERPC__'; echo IS_PPC; echo '#endif') | \
(CCOPTS="" $CC_FOR_BUILD -E - 2>/dev/null) | \
grep IS_PPC >/dev/null
then
UNAME_PROCESSOR=powerpc
fi
elif test "$UNAME_PROCESSOR" = i386 ; then
# uname -m returns i386 or x86_64
UNAME_PROCESSOR=$UNAME_MACHINE
fi
GUESS=$UNAME_PROCESSOR-apple-darwin$UNAME_RELEASE
;;
*:procnto*:*:* | *:QNX:[0123456789]*:*)
UNAME_PROCESSOR=`uname -p`
if test "$UNAME_PROCESSOR" = x86; then
UNAME_PROCESSOR=i386
UNAME_MACHINE=pc
fi
GUESS=$UNAME_PROCESSOR-$UNAME_MACHINE-nto-qnx$UNAME_RELEASE
;;
*:QNX:*:4*)
GUESS=i386-pc-qnx
;;
NEO-*:NONSTOP_KERNEL:*:*)
GUESS=neo-tandem-nsk$UNAME_RELEASE
;;
NSE-*:NONSTOP_KERNEL:*:*)
GUESS=nse-tandem-nsk$UNAME_RELEASE
;;
NSR-*:NONSTOP_KERNEL:*:*)
GUESS=nsr-tandem-nsk$UNAME_RELEASE
;;
NSV-*:NONSTOP_KERNEL:*:*)
GUESS=nsv-tandem-nsk$UNAME_RELEASE
;;
NSX-*:NONSTOP_KERNEL:*:*)
GUESS=nsx-tandem-nsk$UNAME_RELEASE
;;
*:NonStop-UX:*:*)
GUESS=mips-compaq-nonstopux
;;
BS2000:POSIX*:*:*)
GUESS=bs2000-siemens-sysv
;;
DS/*:UNIX_System_V:*:*)
GUESS=$UNAME_MACHINE-$UNAME_SYSTEM-$UNAME_RELEASE
;;
*:Plan9:*:*)
# "uname -m" is not consistent, so use $cputype instead. 386
# is converted to i386 for consistency with other x86
# operating systems.
if test "${cputype-}" = 386; then
UNAME_MACHINE=i386
elif test "x${cputype-}" != x; then
UNAME_MACHINE=$cputype
fi
GUESS=$UNAME_MACHINE-unknown-plan9
;;
*:TOPS-10:*:*)
GUESS=pdp10-unknown-tops10
;;
*:TENEX:*:*)
GUESS=pdp10-unknown-tenex
;;
KS10:TOPS-20:*:* | KL10:TOPS-20:*:* | TYPE4:TOPS-20:*:*)
GUESS=pdp10-dec-tops20
;;
XKL-1:TOPS-20:*:* | TYPE5:TOPS-20:*:*)
GUESS=pdp10-xkl-tops20
;;
*:TOPS-20:*:*)
GUESS=pdp10-unknown-tops20
;;
*:ITS:*:*)
GUESS=pdp10-unknown-its
;;
SEI:*:*:SEIUX)
GUESS=mips-sei-seiux$UNAME_RELEASE
;;
*:DragonFly:*:*)
DRAGONFLY_REL=`echo "$UNAME_RELEASE" | sed -e 's/[-(].*//'`
GUESS=$UNAME_MACHINE-unknown-dragonfly$DRAGONFLY_REL
;;
*:*VMS:*:*)
UNAME_MACHINE=`(uname -p) 2>/dev/null`
case $UNAME_MACHINE in
A*) GUESS=alpha-dec-vms ;;
I*) GUESS=ia64-dec-vms ;;
V*) GUESS=vax-dec-vms ;;
esac ;;
*:XENIX:*:SysV)
GUESS=i386-pc-xenix
;;
i*86:skyos:*:*)
SKYOS_REL=`echo "$UNAME_RELEASE" | sed -e 's/ .*$//'`
GUESS=$UNAME_MACHINE-pc-skyos$SKYOS_REL
;;
i*86:rdos:*:*)
GUESS=$UNAME_MACHINE-pc-rdos
;;
i*86:Fiwix:*:*)
GUESS=$UNAME_MACHINE-pc-fiwix
;;
*:AROS:*:*)
GUESS=$UNAME_MACHINE-unknown-aros
;;
x86_64:VMkernel:*:*)
GUESS=$UNAME_MACHINE-unknown-esx
;;
amd64:Isilon\ OneFS:*:*)
GUESS=x86_64-unknown-onefs
;;
*:Unleashed:*:*)
GUESS=$UNAME_MACHINE-unknown-unleashed$UNAME_RELEASE
;;
esac
# Do we have a guess based on uname results?
if test "x$GUESS" != x; then
echo "$GUESS"
exit
fi
# No uname command or uname output not recognized.
set_cc_for_build
cat > "$dummy.c" <
#include
#endif
#if defined(ultrix) || defined(_ultrix) || defined(__ultrix) || defined(__ultrix__)
#if defined (vax) || defined (__vax) || defined (__vax__) || defined(mips) || defined(__mips) || defined(__mips__) || defined(MIPS) || defined(__MIPS__)
#include
#if defined(_SIZE_T_) || defined(SIGLOST)
#include
#endif
#endif
#endif
main ()
{
#if defined (sony)
#if defined (MIPSEB)
/* BFD wants "bsd" instead of "newsos". Perhaps BFD should be changed,
I don't know.... */
printf ("mips-sony-bsd\n"); exit (0);
#else
#include
printf ("m68k-sony-newsos%s\n",
#ifdef NEWSOS4
"4"
#else
""
#endif
); exit (0);
#endif
#endif
#if defined (NeXT)
#if !defined (__ARCHITECTURE__)
#define __ARCHITECTURE__ "m68k"
#endif
int version;
version=`(hostinfo | sed -n 's/.*NeXT Mach \([0-9]*\).*/\1/p') 2>/dev/null`;
if (version < 4)
printf ("%s-next-nextstep%d\n", __ARCHITECTURE__, version);
else
printf ("%s-next-openstep%d\n", __ARCHITECTURE__, version);
exit (0);
#endif
#if defined (MULTIMAX) || defined (n16)
#if defined (UMAXV)
printf ("ns32k-encore-sysv\n"); exit (0);
#else
#if defined (CMU)
printf ("ns32k-encore-mach\n"); exit (0);
#else
printf ("ns32k-encore-bsd\n"); exit (0);
#endif
#endif
#endif
#if defined (__386BSD__)
printf ("i386-pc-bsd\n"); exit (0);
#endif
#if defined (sequent)
#if defined (i386)
printf ("i386-sequent-dynix\n"); exit (0);
#endif
#if defined (ns32000)
printf ("ns32k-sequent-dynix\n"); exit (0);
#endif
#endif
#if defined (_SEQUENT_)
struct utsname un;
uname(&un);
if (strncmp(un.version, "V2", 2) == 0) {
printf ("i386-sequent-ptx2\n"); exit (0);
}
if (strncmp(un.version, "V1", 2) == 0) { /* XXX is V1 correct? */
printf ("i386-sequent-ptx1\n"); exit (0);
}
printf ("i386-sequent-ptx\n"); exit (0);
#endif
#if defined (vax)
#if !defined (ultrix)
#include
#if defined (BSD)
#if BSD == 43
printf ("vax-dec-bsd4.3\n"); exit (0);
#else
#if BSD == 199006
printf ("vax-dec-bsd4.3reno\n"); exit (0);
#else
printf ("vax-dec-bsd\n"); exit (0);
#endif
#endif
#else
printf ("vax-dec-bsd\n"); exit (0);
#endif
#else
#if defined(_SIZE_T_) || defined(SIGLOST)
struct utsname un;
uname (&un);
printf ("vax-dec-ultrix%s\n", un.release); exit (0);
#else
printf ("vax-dec-ultrix\n"); exit (0);
#endif
#endif
#endif
#if defined(ultrix) || defined(_ultrix) || defined(__ultrix) || defined(__ultrix__)
#if defined(mips) || defined(__mips) || defined(__mips__) || defined(MIPS) || defined(__MIPS__)
#if defined(_SIZE_T_) || defined(SIGLOST)
struct utsname *un;
uname (&un);
printf ("mips-dec-ultrix%s\n", un.release); exit (0);
#else
printf ("mips-dec-ultrix\n"); exit (0);
#endif
#endif
#endif
#if defined (alliant) && defined (i860)
printf ("i860-alliant-bsd\n"); exit (0);
#endif
exit (1);
}
EOF
$CC_FOR_BUILD -o "$dummy" "$dummy.c" 2>/dev/null && SYSTEM_NAME=`"$dummy"` &&
{ echo "$SYSTEM_NAME"; exit; }
# Apollos put the system type in the environment.
test -d /usr/apollo && { echo "$ISP-apollo-$SYSTYPE"; exit; }
echo "$0: unable to guess system type" >&2
case $UNAME_MACHINE:$UNAME_SYSTEM in
mips:Linux | mips64:Linux)
# If we got here on MIPS GNU/Linux, output extra information.
cat >&2 <&2 <&2 </dev/null || echo unknown`
uname -r = `(uname -r) 2>/dev/null || echo unknown`
uname -s = `(uname -s) 2>/dev/null || echo unknown`
uname -v = `(uname -v) 2>/dev/null || echo unknown`
/usr/bin/uname -p = `(/usr/bin/uname -p) 2>/dev/null`
/bin/uname -X = `(/bin/uname -X) 2>/dev/null`
hostinfo = `(hostinfo) 2>/dev/null`
/bin/universe = `(/bin/universe) 2>/dev/null`
/usr/bin/arch -k = `(/usr/bin/arch -k) 2>/dev/null`
/bin/arch = `(/bin/arch) 2>/dev/null`
/usr/bin/oslevel = `(/usr/bin/oslevel) 2>/dev/null`
/usr/convex/getsysinfo = `(/usr/convex/getsysinfo) 2>/dev/null`
UNAME_MACHINE = "$UNAME_MACHINE"
UNAME_RELEASE = "$UNAME_RELEASE"
UNAME_SYSTEM = "$UNAME_SYSTEM"
UNAME_VERSION = "$UNAME_VERSION"
EOF
fi
exit 1
# Local variables:
# eval: (add-hook 'before-save-hook 'time-stamp)
# time-stamp-start: "timestamp='"
# time-stamp-format: "%:y-%02m-%02d"
# time-stamp-end: "'"
# End:
xorgproto-2023.2/xf86driproto.pc.in 0000644 0001750 0001750 00000000223 14443010026 014064 0000000 0000000 prefix=@prefix@
includedir=@includedir@
Name: XF86DRIProto
Description: XF86DRI extension headers
Version: 2.1.1
Cflags: -I${includedir}/X11/dri
xorgproto-2023.2/specs/ 0000755 0001750 0001750 00000000000 14443010036 011756 5 0000000 0000000 xorgproto-2023.2/specs/xextproto/ 0000755 0001750 0001750 00000000000 14443010036 014032 5 0000000 0000000 xorgproto-2023.2/specs/xextproto/tog-cup.xml 0000644 0001750 0001750 00000041144 14443010026 016055 0000000 0000000
%defs;
]>
Colormap Utilization Policy and Extension
X Project Team Standard
X Version 11, Release &fullrelvers;
Version 1.0
Kaleb
S.
Keithley
The Open Group
1986-1997 The Open Group
Permission is hereby granted, free of charge, to any person obtaining a
copy of this
software and associated documentation files (the Software), to use the
Software
without restriction, including, without limitation, the rights to copy,
modify, merge,
publish, distribute and sublicense the Software, to make, have made,
license and
distribute derivative works thereof, and to permit persons to whom the
Software is
furnished to do so, subject to the following conditions:
The above copyright notice and the following permission notice shall be
included in all copies of the Software:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-
INFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP 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 OF OTHER DEALINGS IN
THE SOFTWARE.
Except as contained in this notice, the name of The Open Group shall not be
used in
advertising or otherwise to promote the use or other dealings in this
Software without prior written authorization from The Open Group.
X Window System is a trademark of The Open Group.
Overview
This extension has three purposes: a) to provide mechanism for a special
application (a colormap manager) to discover any special colormap
requirements, e.g. the colormap entries that are nominally reserved for
desktop colors in the MS-Windows environment and initialize the default
colormap so that it can be more easily shared; and b) to encourage colormap
sharing and reduce colormap flashing on low-end 8-bit frame buffers by
providing a policy for sharing; and c) when colormaps aren't shared,
define a behavior in the X server color allocation scheme to reduce
colormap flashing.
To encourage colormap sharing and accommodate special colormap requirements
two new protocols are defined: the first provides a way to query the
server for a list of reserved colormap entries, and the second is a way
to initialize read-only (shareable) colormap entries at specific locations
in a colormap.
To minimize colormap flashing when the root window's default visual is one
of GrayScale, PseudoColor, or DirectColor, and a private colormap for the
default visual is being used, a minor (but compatible) change to the
server implementation of the AllocColor and AllocNamedColor requests is
required. Where the core protocol says nothing about the pixel values
returned, when this extension is in effect, the AllocColor and AllocNamedColor
requests will first look for a matching color in the default colormap, and,
if a match is found and the same cell in the private colormap has not
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.)
Requests
QueryVersion
client_major_version: CARD16
client_minor_version: CARD16
=>
server_major_version: CARD16
server_minor_version: CARD16
If supplied, the client_major_version and client_minor_version indicate
what version of the protocol the client wants the server to implement.
The server version numbers returned indicate the protocol this extension
actually supports. This might not equal the version sent by the client.
An implementation can (but need not) support more than one version
simultaneously. The server_major_version and the server_minor_version
are a mechanism to support future revisions of the TOG-CUP protocol that
may be necessary. In general, the major version would increment for
incompatible changes, and the minor version would increment for small
upward-compatible changes. Servers that support the protocol defined in
this document will return a server_major_version of one (1), and a
server_minor_version of zero (0).
GetReservedColormapEntries
screen: CARD32
=>
entries: LISTofCOLORITEM
This request returns a list of colormap entries (pixels) that are reserved
by the system, e.g. MS-Windows reserved desktop colors. This list will, at a
minimum, contain entries for the BlackPixel and WhitePixel of the specified
screen. The do-red, do-green, and do-blue elements of the COLORITEMs are
unused in this reply.
Rationale: There are colormap entries (pixels) that, e.g., MS-Windows
desktop reserves as desktop colors, that should not be altered. If they
are altered then X programs will cause colormap flashing between X and
MS-Windows applications running/displaying on the same desktop.
StoreColors
cmap: COLORMAP
items: LISTofCOLORITEM
=>
items: LISTofCOLORITEM
This request changes the colormap entries of the specified pixels. The
colormap entries are allocated as if by an AllocColor request. The do-red,
do-green, and do-blue elements of the COLORITEMs are unused in this request.
A boolean alloc-ok element (a bit) is returned indicating whether the
particular pixel was successfully allocated or not. If successfully
allocated the RGB and pixel are returned.
A Value error is generated if a pixel is not a valid index into cmap. A
BadMatch error is generated if if cmap does not belong to a GrayScale,
PseudoColor, or DirectColor visual.
Events and Errors
No new events or errors are defined by this extension.
Changes to existing protocol.
None.
Encoding
The name of this extension is "TOG-CUP".
The conventions used here are the same as those for the core X11
Protocol Encoding.
QueryVersion
1 CARD8 opcode
1 0 TOG-CUP opcode
2 2 request length
2 CARD16 client_major_version
2 CARD16 client_minor_version
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 0 length
2 CARD16 server_major_version
2 CARD16 server_minor_number
20 unused
GetReservedColormapEntries
1 CARD8 opcode
1 1 TOG-CUP opcode
2 2 request length
4 CARD32 screen
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 3n length
24 unused
12n LISTofCOLORITEM items
StoreColors
1 CARD8 opcode
1 2 TOG-CUP opcode
2 2+3n request length
4 COLORMAP cmap
12n LISTofCOLORITEM items
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 3n length
24 unused
12n LISTofCOLORITEM items
(The definition of COLORITEM here is only for the purpose of defining the
additional alloc-ok member in the CUPStoreColors reply.)
COLORITEM
4 CARD32 pixel
2 CARD16 red
2 CARD16 green
2 CARD16 blue
1 alloc-ok
#x07 unused
#x08 alloc-ok (1 is True, 0 is False)
#xF0 unused
1 unused
C Language Binding
The C functions provide direct access to the protocol and add no additional
semantics. For complete details on the effects of these functions, refer
to the appropriate protocol request, which can be derived by deleting XCup
at the start of the function. All functions that have return type Status
will return nonzero for success and zero for failure.
The include file for this extension is
<X11/extensions/Xcup.h> .
Status XCupQueryVersion
Display* display
int* major_version_return
int* minor_version_return
display
Specifies the connection to the X server.
major_version_return
Returns the major version supported by the server.
minor_version_return
Returns the minor version supported by the server.
XCupQueryVersions sets major_version_return and minor_version_return to
the major and minor TOG-CUP protocol version supported by the server. If
the TOG-CUP library is compatible with the version returned by the server,
it returns nonzero. If dpy does not support the TOG-CUP extension, or if
there was an error during communication with the server, or if the server
and library protocol versions are incompatible, it returns zero. No other
XCup functions may be called before this function. If a client violates
this rule, the effects of all subsequent XCup calls that it makes are
undefined.
To get the list of reserved colormap entries, use
XCupGetReservedColormapEntries.
Status XCupGetReservedColormapEntries
Display* display
int screen
XColor** colors_out
int* ncolors
display
Specifies the connection to the X server.
colors_out
Returns the values reserved by the server.
ncolors
Returns the number of items in colors_out.
The XCupGetReservedColormapEntries function gets system specific colormap
entries. E.g. the MS-Windows desktop uses N colormap entries at the beginning
(0..N) and end (256-N..255) of the colormap. Use XFree to free colors_out.
To allocate one or more read-only color cells with RGB values, use
XCupStoreColors.
Status XCupStoreColors
Display* display
Colormap colormap
XColor* colors_in_out
int ncolors
display
Specifies the connection to the X server.
colormap
Specifies the colormap.
colors_in_out
Specifies and returns the values actually used in the colormap.
ncolors
Specifies the number of items in colors_in_out.
The XCupStoreColors function changes the colormap entries of the pixel
values specified in the pixel members of the XColor structures. The colormap
entries are allocated as if an AllocColor had been used instead, i.e. the
colors are read-only (shareable). XCupStoreColors returns the number of
colors that were successfully allocated in the colormap.
Using the TOG-CUP extension and Colormap Utilization Policy
The X server preallocates any hardware or desktop special colors in the
default colormap; e.g. UNIX X servers preallocate Black and White pixels.
PC X servers should also preallocate the MS-Windows desktop colors. (Note
to implementors: in the Sample Implementation special colors are allocated
in the default colormap in cfbCreateDefColormap for dumb memory framebuffers.)
To minimize colormap flash an application which installs its own private
colormap should query the special colors by calling
XCupGetReservedColormapEntries, and can then store those entries (in the
proper location) in its private colormap using XCupStoreColors.
Applications which allocate many colors in a screen's default colormap, e.g.
a color-cube or a gray-ramp, should allocate them with XCupStoreColors. By
using XCupStoreColors the colors will be allocated shareable (read-only) and
any other application which allocates the same color will share that color
cell.
xorgproto-2023.2/specs/xextproto/shm.xml 0000644 0001750 0001750 00000041454 14443010026 015272 0000000 0000000
%defs;
]>
MIT-SHM(The MIT Shared Memory Extension)
How the shared memory extension works
Jonathan Corbet
National Center for Atmospheric Research
Atmospheric Technology Division
corbet@ncar.ucar.edu
Keith Packard
MIT X Consortium
X Version 11, Release &fullrelvers;
Version 1.0
1991 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
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.
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.
X Window System is a trademark of The OpenGroup.
This document briefly describes how to use the MIT-SHM shared memory
extension. I have tried to make it accurate, but it would not surprise me
if some errors remained. If you find anything wrong, do let me know and I
will incorporate the corrections. Meanwhile, please take this document "as
is" (eman improvement over what was there before, but certainly not the
definitive word.)
REQUIREMENTS
The shared memory extension is provided only by some X servers. To find out
if your server supports the extension, use xdpyinfo(1). In particular, to
be able to use this extension, your system must provide the SYSV shared
memory primitives. There is not an mmap-based version of this extension.
To use shared memory on Sun systems, you must have built your kernel with
SYSV shared memory enabled -- which is not the default configuration.
Additionally, the shared memory maximum size will need to be increased on
both Sun and Digital systems; the defaults are far too small for any useful
work.
WHAT IS PROVIDED
The basic capability provided is that of shared memory XImages. This is
essentially a version of the ximage interface where the actual image data
is stored in a shared memory segment, and thus need not be moved through
the Xlib interprocess communication channel. For large images, use of this
facility can result in some real performance increases.
Additionally, some implementations provided shared memory pixmaps. These
are 2 dimensional arrays of pixels in a format specified by the X server,
where the image data is stored in the shared memory segment. Through use of
shared memory pixmaps, it is possible to change the contents of these
pixmaps without using any Xlib routines at all. Shared memory pixmaps can
only be supported when the X server can use regular virtual memory for
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.
HOW TO USE THE SHARED MEMORY EXTENSION
Code which uses the shared memory extension must include a number of header
files:
#include <X11/Xlib.h> /* of course */
#include <sys/ipc.h>
#include <sys/shm.h>
#include <X11/extensions/XShm.h>
Of course, if the system you are building on does not support shared
memory, the file XShm.h may not be present. You may want to make
liberal use of #ifdefs.
Any code which uses the shared memory extension should first check to see
that the server provides the extension. You could always be running over
the net, or in some other environment where the extension will not work.
To perform this check, call either
Status XShmQueryExtension
Display *display
or
Status XShmQueryVersion
Display *display
int *major
int *minor
Bool *pixmaps
Where "display" is, of course, the display on which you are running. If
the shared memory extension may be used, the return value from either
function will be True; otherwise your program should operate using
conventional Xlib calls. When the extension is available,
\fCXShmQueryVersion\fP also returns "major" and "minor" which are the
version numbers of the extension implementation, and "pixmaps" which is
True iff shared memory pixmaps are supported.
USE OF SHARED MEMORY XIMAGES
The basic sequence of operations for shared memory XImages is as follows:
Create the shared memory XImage structure
Create a shared memory segment to store the image data
Inform the server about the shared memory segment
Use the shared memory XImage, much like a normal one.
To create a shared memory XImage, use:
XImage *XShmCreateImage
Display *display
Visual *visual
unsigned int depth
int format
char *data
XShmSegmentInfo *shminfo
unsigned int width
unsigned int height
Most of the arguments are the same as for XCreateImage; I will not go
through them here. Note, however, that there are no "offset", "bitmap_pad",
or "bytes_per_line" arguments. These quantities will be defined by the
server itself, and your code needs to abide by them. Unless you have already
allocated the shared memory segment (see below), you should pass in NULL for
the "data" pointer.
There is one additional argument: "shminfo", which is a pointer to a
structure of type XShmSegmentInfo. You must allocate one of these
structures such that it will have a lifetime at least as long as that of
the shared memory XImage. There is no need to initialize this structure
before the call to XShmCreateImage.
The return value, if all goes well, will be an XImage structure, which you
can use for the subsequent steps.
The next step is to create the shared memory segment. This is
best done after the creation of the XImage, since you need to make use of
the information in that XImage to know how much memory to allocate. To
create the segment, you need a call like:
shminfo.shmid = shmget (IPC_PRIVATE,
image->bytes_per_line * image->height, IPC_CREAT|0777);
(assuming that you have called your shared memory XImage "image"). You
should, of course, follow the Rules and do error checking on all of these
system calls. Also, be sure to use the bytes_per_line field, not the width
you used to create the XImage as they may well be different.
Note that the shared memory ID returned by the system is stored in the
shminfo structure. The server will need that ID to attach itself to the
segment.
Also note that, on many systems for security reasons, the X server
will only accept to attach to the shared memory segment if it's
readable and writeable by "other". On systems where the X server is
able to determine the uid of the X client over a local transport, the
shared memory segment can be readable and writeable only by the uid of
the client.
Next, attach this shared memory segment to your process:
shminfo.shmaddr = image->data = shmat (shminfo.shmid, 0, 0);
The address returned by shmat should be stored in *both* the XImage
structure and the shminfo structure.
To finish filling in the shminfo structure, you need to decide how you want
the server to attach to the shared memory segment, and set the "readOnly"
field as follows. Normally, you would code:
shminfo.readOnly = False;
If you set it to True, the server will not be able to write to this
segment, and thus XShmGetImage calls will fail.
Finally, tell the server to attach to your shared memory segment with:
Status XShmAttach (display, shminfo);
If all goes well, you will get a non-zero status back, and your XImage is
ready for use.
To write a shared memory XImage into an X drawable, use XShmPutImage:
Status XShmPutImage
Display *display
Drawable d
GC gc
XImage *image
int src_x
int src_y
int dest_x
int dest_y
unsigned int width
unsigned int height
bool send_event
The interface is identical to that of XPutImage, so I will spare my fingers
and not repeat that documentation here. There is one additional parameter,
however, called "send_event". If this parameter is passed as True, the
server will generate a "completion" event when the image write is complete;
thus your program can know when it is safe to begin manipulating the shared
memory segment again.
The completion event has type XShmCompletionEvent, which is defined as the
following:
typedef struct {
int type; /* of event */
unsigned long serial; /* # of last request processed */
Bool send_event; /* true if came from a SendEvent request */
Display *display; /* Display the event was read from */
Drawable drawable; /* drawable of request */
int major_code; /* ShmReqCode */
int minor_code; /* X_ShmPutImage */
ShmSeg shmseg; /* the ShmSeg used in the request */
unsigned long offset; /* the offset into ShmSeg used */
} XShmCompletionEvent;
The event type value that will be used can be determined at run time with a
line of the form:
int CompletionType = XShmGetEventBase (display) + ShmCompletion;
If you modify the shared memory segment before the arrival of the
completion event, the results you see on the screen may be inconsistent.
To read image data into a shared memory XImage, use the following:
Status XShmGetImage
Display *display
Drawable d
XImage *image
int x
int y
unsigned long plane_mask
Where "display" is the display of interest, "d" is the source drawable,
"image" is the destination XImage, "x" and "y" are the offsets within
"d", and "plane_mask" defines which planes are to be read.
To destroy a shared memory XImage, you should first instruct the server to
detach from it, then destroy the segment itself, as follows:
XShmDetach (display, shminfo);
XDestroyImage (image);
shmdt (shminfo.shmaddr);
shmctl (shminfo.shmid, IPC_RMID, 0);
USE OF SHARED MEMORY PIXMAPS
Unlike X images, for which any image format is usable, the shared memory
extension supports only a single format (i.e. XYPixmap or ZPixmap) for the
data stored in a shared memory pixmap. This format is independent of the
depth of the image (for 1-bit pixmaps it doesn't really matter what this
format is) and independent of the screen. Use XShmPixmapFormat to get the
format for the server:
int XShmPixmapFormat
Display *display
If your application can deal with the server pixmap data format (including
bits-per-pixel et al.), create a shared memory segment and "shminfo"
structure in exactly the same way as is listed above for shared memory
XImages. While it is, not strictly necessary to create an XImage first,
doing so incurs little overhead and will give you an appropriate
bytes_per_line value to use.
Once you have your shminfo structure filled in, simply call:
Pixmap XShmCreatePixmap
Display *display
Drawable d
char *data
XShmSegmentInfo *shminfo
unsigned int width
unsigned int height
unsigned int depth
The arguments are all the same as for XCreatePixmap, with two additions:
"data" and "shminfo". The second of the two is the same old shminfo
structure that has been used before. The first is the pointer to the shared
memory segment, and should be the same as the shminfo.shmaddr field. I am
not sure why this is a separate parameter.
If everything works, you will get back a pixmap, which you can manipulate in
all of the usual ways, with the added bonus of being able to tweak its
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.
xorgproto-2023.2/specs/xextproto/dbe.xml 0000644 0001750 0001750 00000107663 14443010026 015242 0000000 0000000
%defs;
]>
Double Buffer Extension Protocol
X Consortium Standard
Ian Elliott
Hewlett-Packard Company
David P. Wiggins
X Consortium
1989 1992 1993 1994
X Consortium, Inc.
1989 Digital Equipment Corporation 1992 Intergraph Corporation 1993 Silicon Graphics, Inc. 1994 Hewlett-Packard Company X Version 11, Release &fullrelvers;
Version 1.0
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. Digital Equipment
Corporation, Intergraph Corporation, Silicon Graphics, Hewlett-Packard, 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.
Introduction
The Double Buffer Extension (DBE) provides a standard way to utilize
double-buffering within the framework of the X Window System. Double-buffering
uses two buffers, called front and back, which hold images. The front buffer
is visible to the user; the back buffer is not. Successive frames of an
animation are rendered into the back buffer while the previously rendered
frame is displayed in the front buffer. When a new frame is ready, the back
and front buffers swap roles, making the new frame visible. Ideally, this
exchange appears to happen instantaneously to the user and with no visual
artifacts. Thus, only completely rendered images are presented to the user,
and they remain visible during the entire time it takes to render a new frame.
The result is a flicker-free animation.
Goals
This extension should enable clients to:
Allocate and deallocate double-buffering for a window.
Draw to and read from the front and back buffers associated with a window.
Swap the front and back buffers associated with a window.
Specify a wide range of actions to be taken when a window is swapped.
This includes explicit, simple swap actions (defined below), and more
complex actions (for example, clearing ancillary buffers) that can be put
together within explicit "begin" and "end" requests (defined below).
Request that the front and back buffers associated with multiple
double-buffered windows be swapped simultaneously.
In addition, the extension should:
Allow multiple clients to use double-buffering on the same window.
Support a range of implementation methods that can capitalize on existing
hardware features.
Add no new event types.
Be reasonably easy to integrate with a variety of direct graphics hardware
access (DGHA) architectures.
Concepts
Normal windows are created using the core CreateWindow
request, which allocates a set of window attributes and, for InputOutput
windows, a front buffer, into which an image can be drawn. The contents of
this buffer will be displayed when the window is visible.
This extension enables applications to use double-buffering with a window.
This involves creating a second buffer, called a back buffer, and associating
one or more back buffer names (XIDs) with the window for use when referring to
(that is, drawing to or reading from) the window's back buffer. The back
buffer name is a DRAWABLE of type BACKBUFFER.
DBE provides a relative double-buffering model. One XID, the window, always
refers to the front buffer. One or more other XIDs, the back buffer names,
always refer to the back buffer. After a buffer swap, the window continues to
refer to the (new) front buffer, and the back buffer name continues to refer
to the (new) back buffer. Thus, applications and toolkits that want to just
render to the back buffer always use the back buffer name for all drawing
requests to the window. Portions of an application that want to render to
the front buffer always use the window XID for all drawing requests to the
window.
Multiple clients and toolkits can all use double-buffering on the same
window. DBE does not provide a request for querying whether a window has
double-buffering support, and if so, what the back buffer name is. Given
the asynchronous nature of the X Window System, this would cause race
conditions. Instead, DBE allows multiple back buffer names to exist for
the same window; they all refer to the same physical back buffer. The first
time a back buffer name is allocated for a window, the window becomes
double-buffered and the back buffer name is associated with the window.
Subsequently, the window already is a double-buffered window, and nothing
about the window changes when a new back buffer name is allocated, except
that the new back buffer name is associated with the window. The window
remains double-buffered until either the window is destroyed or until all of
the back buffer names for the window are deallocated.
In general, both the front and back buffers are treated the same. In
particular, here are some important characteristics:
Only one buffer per window can be visible at a time (the front buffer).
Both buffers associated with a window have the same visual type, depth,
width, height, and shape as the window.
Both buffers associated with a window are "visible" (or "obscured") in
the same way. When an Expose event is generated for a window, both
buffers should be considered to be damaged in the exposed area. Damage
that occurs to either buffer will result in an Expose event on the window.
When a double-buffered window is exposed, both buffers are tiled with the
window background, exactly as stated by the core protocol. Even though
the back buffer is not visible, terms such as obscure apply to the back
buffer as well as to the front buffer.
It is acceptable at any time to pass a BACKBUFFER in any
request, notably any core or extension drawing request, that expects
a DRAWABLE. This enables an application to draw directly into
BACKBUFFERs in the same fashion as it would draw into any other
DRAWABLE.
It is an error (Window) to pass a BACKBUFFER in a core request that
expects a Window.
A BACKBUFFER will never be sent by core X in a reply, event, or error
where a Window is specified.
If core X11 backing-store and save-under applies to a double-buffered
window, it applies to both buffers equally.
If the core ClearArea request is executed on a
double-buffered window, the same area in both the front and back buffers
is cleared.
The effect of passing a window to a request that accepts a DRAWABLE is
unchanged by this extension. The window and front buffer are synonymous with
each other. This includes obeying the GetImage semantics
and the subwindow-mode semantics if a core graphics context is involved.
Regardless of whether the window was explicitly passed in a
GetImage request, or implicitly referenced (that is,
one of the windo's ancestors was passed in the request), the front (that is,
visible) buffer is always referenced. Thus, DBE-naive screen dump clients will
always get the front buffer. GetImage on a back buffer
returns undefined image contents for any obscured regions of the back buffer
that fall within the image.
Drawing to a back buffer always uses the clip region that would be used to
draw to the front buffer with a GC subwindow-mode of
ClipByChildren . If an
ancestor of a double-buffered window is drawn to with a core GC having a
subwindow-mode of IncludeInferiors , the effect on the
double-buffered window's back buffer depends on the depth of the
double-buffered window and the ancestor. If the depths are the same, the
contents of the back buffer of the double-buffered window are not changed.
If the depths are different, the contents of the back buffer of the
double-buffered window are undefined for the pixels that the
IncludeInferiors drawing touched.
DBE adds no new events. DBE does not extend the semantics of any existing
events with the exception of adding a new DRAWABLE type called BACKBUFFER. If
events, replies, or errors that contain a DRAWABLE (for example,
GraphicsExpose ) are generated in response to a request,
the DRAWABLE returned will be the one specified in the request.
DBE advertises which visuals support double-buffering.
DBE does not include any timing or synchronization facilities.
Applications that need such facilities (for example, to maintain a constant
frame rate) should investigate the Synchronization Extension, an X
Consortium standard.
Window Management Operations
The basic philosophy of DBE is that both buffers are treated the same by core
X window management operations.
When the core DestroyWindow is executed on a
double-buffered window, both buffers associated with the window are
destroyed, and all back buffer names associated with the window are freed.
If the core ConfigureWindow request changes the size of
a window, both buffers assume the new size. If the windo's size increases,
the effect on the buffers depends on whether the implementation honors bit
gravity for buffers. If bit gravity is implemented, then the contents of
both buffers are moved in accordance with the windo's bit gravity (see the
core ConfigureWindow request), and the remaining areas
are tiled with the window background. If bit gravity is not implemented, then
the entire unobscured region of both buffers is tiled with the window
background. In either case, Expose events are generated
for the region that is tiled with the window background.
If the core GetGeometry request is executed on a
BACKBUFFER, the returned x, y, and border-width will be zero.
If the Shape extension ShapeRectangles ,
ShapeMask ,
ShapeCombine , or
ShapeOffset
request is executed on a double-buffered window, both buffers are reshaped
to match the new window shape. The region difference is the following:
D = newshape - oldshape
It is tiled with the window background in both buffers, and
Expose events are generated for D.
Complex Swap Actions
DBE has no explicit knowledge of ancillary buffers (for example, depth
buffers or alpha buffers), and only has a limited set of defined swap
actions. Some applications may need a richer set of swap actions than DBE
provides. Some DBE implementations have knowledge of ancillary buffers,
and/or can provide a rich set of swap actions. Instead of continually
extending DBE to increase its set of swap actions, DBE provides a flexible
"idiom" mechanism. If an application's needs are served by the defined swap
actions, it should use them; otherwise, it should use the following method
of expressing a complex swap action as an idiom. Following this policy will
ensure the best possible performance across a wide variety of implementations.
As suggested by the term "idiom," a complex swap action should be expressed
as a group/series of requests. Taken together, this group of requests may be
combined into an atomic operation by the implementation, in order to maximize
performance. The set of idioms actually recognized for optimization is
implementation dependent. To help with idiom expression and interpretation,
an idiom must be surrounded by two protocol requests:
DBEBeginIdiom and
DBEEndIdiom . Unless this begin-end pair
surrounds the idiom, it may not be recognized by a given implementation, and
performance will suffer.
For example, if an application wants to swap buffers for two windows, and
use core X to clear only certain planes of the back buffers, the application
would issue the following protocol requests as a group, and in the following
order:
DBEBeginIdiom request.
DBESwapBuffers request with XIDs for two windows, each of which uses
a swap action of Untouched.
Core X PolyFillRectangle request to the back buffer of one window.
Core X PolyFillRectangle request to the back buffer of the other window.
DBEEndIdiom request.
The DBEBeginIdiom and DBEEndIdiom
requests do not perform any actions themselves. They are treated as markers
by implementations that can combine certain groups/series of requests as
idioms, and are ignored by other implementations or for nonrecognized
groups/series of requests. If these requests are sent out of order, or are
mismatched, no errors are sent, and the requests are executed as usual,
though performance may suffer.
An idiom need not include a DBESwapBuffers request. For
example, if a swap action of Copied is desired, but only some of the planes
should be copied, a core X
CopyArea request may be used instead of
DBESwapBuffers .
If DBESwapBuffers is included in an idiom, it should
immediately follow the DBEBeginIdiom request. Also, when
the DBESwapBuffers is included in an idiom, that
request's swap action will still be valid, and if the swap action might
overlap with another request, then the final result of the idiom must be as if
the separate requests were executed serially. For example, if the specified
swap action is Untouched, and if a PolyFillRectangle
using a client clip rectangle is done to the windo's back buffer after the
DBESwapBuffers request, then the contents of the new
back buffer (after the idiom) will be the same as if the idiom was not
recognized by the implementation.
It is highly recommended that Application Programming Interface (API)
providers define, and application developers use, "convenience" functions
that allow client applications to call one procedure that encapsulates
common idioms. These functions will generate the
DBEBeginIdiom request, the idiom requests, and
DBEEndIdiom request. Usage of these functions will
ensure best possible performance across a wide variety of implementations.
Requests
The DBE defines the following requests.
DBEGetVersion
This request returns the major and minor version numbers of this extension.
DBEGetVersion
client-major-version
CARD8
client-minor-version
CARD8
=>
server-major-version
CARD8
server-minor-version
CARD8
The client-major-version and client-minor-version numbers indicate what
version of the protocol the client wants the server to implement. The
server-major-version and the server-minor-version numbers returned indicate
the protocol this extension actually supports. This might not equal the
version sent by the client. An implementation can (but need not) support
more than one version simultaneously. The server-major-version and
server-minor-version allow the creation of future revisions of the DBE
protocol that may be necessary. In general, the major version
would increment for incompatible changes, and the minor version would increment
for small, upward-compatible changes. Servers that support the protocol
defined in this document will return a server-major-version of one (1), and a
server-minor-version of zero (0).
The DBE client must issue a DBEGetVersion request before any other double
buffering request in order to negotiate a compatible protocol version;
otherwise, the client will get undefined behavior (DBE may or may not work).
DBEGetVisualInfo
This request returns information about which visuals support double buffering.
DBEGetVisualInfo
screen-specifiers
LISTofDRAWABLE
=>
visinfo
LISTofSCREENVISINFO
where:
SCREENVISINFO
LISTofVISINFO
VISINFO
[ visual: VISUALID
depth: CARD8
perflevel: CARD8 ]
Errors: Drawable
All of the values passed in screen-specifiers must be valid DRAWABLEs (or a
Drawable error results). For each drawable in
screen-specifiers, the reply will contain a list of VISINFO structures for
visuals that support double-buffering on the screen on which the drawable
resides. The visual member specifies the VISUALID. The depth member specifies
the depth in bits for the visual. The perflevel is a performance hint. The
only operation defined on a perflevel is comparison to a perflevel of another
visual on the same screen. The visual having the higher perflevel is likely
to have better double-buffer graphics performance than the visual having the
lower perflevel. Nothing can be deduced from any of the following: the
magnitude of the difference of two perflevels, a perflevel value in isolation,
or comparing perflevels from different servers.
If the list of screen-specifiers is empty, information for all screens is
returned, starting with screen zero.
DBEAllocateBackBufferName
This request allocates a drawable ID used to refer to the back buffer of a
window.
DBEAllocateBackBufferName
window
WINDOW
back-buffer-name
BACKBUFFER
swap-action-hint
SWAPACTION
Errors: Alloc, Value, IDChoice, Match, Window
If the window is not already a double-buffered window, the window becomes
double-buffered, and the back-buffer-name is associated with the window. The
swap-action-hint tells the server which swap action is most likely to be
used with the window in subsequent DBESwapBuffers
requests. The swap-action-hint must have one of the values specified for type
SWAPACTION (or a Value error results). See the description of the
DBESwapBuffers request for a complete discussion of
swap actions and the SWAPACTION type.
If the window already is a double-buffered window, nothing about the window
changes, except that an additional back-buffer-name is associated with the
window. The window remains double-buffered until either the window is
destroyed, or until all of the back buffer names for the window are
deallocated.
The window passed into the request must be a valid WINDOW (or a Window error
results). The window passed into the request must be an InputOutput window (or
a Match error results). The visual of the window must be in the list returned
by DBEGetVisualInfo (or a Match error results). The
back-buffer-name must be in the range assigned to the client, and must not
already be in use (or an IDChoice error results). If the server cannot
allocate all resources associated with turning on double-buffering for the
window, an Alloc error results, the windo's double-buffer status (whether it
is already double-buffered or not) remains unchanged, and the
back-buffer-name is freed.
DBEDeallocateBackBufferName
This request frees a drawable ID that was obtained by
DBEAllocateBackBufferName .
DBEDeallocateBackBufferName
back-buffer-name
BACKBUFFER
Errors: Buffer
The back-buffer-name passed in the request is freed and no longer associated
with the window. If this is the last back-buffer-name associated with the
window, then the back buffer is no longer accessible to clients, and all
double-buffering resources associated with the window may be freed. The
window's current front buffer remains the front buffer.
The back-buffer-name must be a valid BACKBUFFER associated with a window (or
a Buffer error results).
DBESwapBuffers
This request swaps the buffers for all windows listed, applying the
appropriate swap action for each window.
DBESwapBuffers
windows
LISTofSWAPINFO
where:
SWAPINFO
[ window: WINDOW
swap-action: SWAPACTION ]
SWAPACTION
{ Undefined, Background, Untouched, Copied }
Errors: Match, Window, Value
Each window passed into the request must be a valid WINDOW (or a
Window error results). Each window passed into the
request must be a double-buffered window (or a Match
error results). Each window passed into the request must only be listed
once (or a Match error results). Each swap-action in
the list must have one of the values specified for type SWAPACTION (or a
Value error results). If an error results, none of
the valid double-buffered windows will have their buffers swapped.
The swap-action determines what will happen to the new back buffer of the
window it is paired with in the list in addition to making the old back
buffer become visible. The defined actions are as follows:
Undefined
The contents of the new back buffer become undefined. This may be the
most efficient action since it allows the implementation to discard the
contents of the buffer if it needs to.
Background
The unobscured region of the new back buffer will be tiled with the window
background. The background action allows devices to use a fast clear
capability during a swap.
Untouched
The unobscured region of the new back buffer will be unmodified by the swap.
Copied
The unobscured region of the new back buffer will be the contents of the
old back buffer.
If DBESwapBuffers is included in a "swap and clear"
type of idiom, it must immediately follow the
DBEBeginIdiom request.
DBEBeginIdiom
This request informs the server that a complex swap will immediately follow
this request.
DBEBeginIdiom
As previously discussed, a complex swap action is a group/series of
requests that, taken together, may be combined into an atomic operation by
the implementation. The sole function of this request is to serve as a
"marker" that the server can use to aid in idiom processing. The server is
free to implement this request as a no-op.
DBEEndIdiom
This request informs the server that a complex swap has concluded.
DBEEndIdiom
The sole function of this request is to serve as a "marker" that the server
can use to aid in idiom processing. The server is free to implement this
request as a no-op.
DBEGetBackBufferAttributes
This request returns information about a back buffer.
DBEGetBackBufferAttributes
back-buffer-name
BACKBUFFER
=>
attributes
BUFFER_ATTRIBUTES
where:
BUFFER_ATTRIBUTES: [ window: WINDOW ]
If back-buffer-name is a valid BACKBUFFER, the window field of the
attributes in the reply will be the window which has the back buffer that
back-buffer-name refers to. If back-buffer-name is not a valid BACKBUFFER,
the window field of the attributes in the reply will be None.
Encoding
Please refer to the X11 Protocol Encoding document as this section uses
syntactic conventions and data types established there.
The name of this extension is "DOUBLE-BUFFER".
Type
The following new types are used by the extension.
BACKBUFFER: XID
SWAPACTION
#x00 Undefined
#x01 Background
#x02 Untouched
#x03 Copied
SWAPINFO
4 WINDOW window
1 SWAPACTION swap action
3 unused
VISINFO
4 VISUALID visual
1 CARD8 depth
1 CARD8 perflevel
2 unused
SCREENVISINFO
4 CARD32 n, number in list
8n LISTofVISINFO n VISINFOs
BUFFER_ATTRIBUTES
4 WINDOW window
Error
Buffer
1 0 error
1 error base + 0 code
2 CARD16 sequence number
4 CARD32 bad buffer
2 CARD16 minor-opcode
1 CARD8 major-opcode
21 unused
Request
DBEGetVersion
1 CARD8 major-opcode
1 0 minor-opcode
2 2 request length
1 CARD8 client-major-version
1 CARD8 client-minor-version
2 unused
=>
1 unused
2 CARD16 sequence number
4 0 reply length
1 CARD8 server-major-version
1 CARD8 server-minor-version
22 unused
DBEAllocateBackBufferName
1 CARD8 major-opcode
1 1 minor-opcode
2 4 request length
4 WINDOW window
4 BACKBUFFER back buffer name
1 SWAPACTION swap action hint
3 unused
DBEDeallocateBackBufferName
1 CARD8 major-opcode
1 2 minor-opcode
2 2 request length
4 BACKBUFFER back buffer name
DBESwapBuffers
1 CARD8 major-opcode
1 3 minor-opcode
2 2+2n request length
4 CARD32 n, number of window/swap action pairs in list
8n LISTofSWAPINFO window/swap action pairs
DBEBeginIdiom
1 CARD8 major-opcode
1 4 minor-opcode
2 1 request length
DBEEndIdiom
1 CARD8 major-opcode
1 5 minor-opcode
2 1 request length
DBEGetVisualInfo
1 CARD8 major-opcode
1 6 minor-opcode
2 2+n request length
4 CARD32 n, number of screen specifiers in list
4n LISTofDRAWABLE n screen specifiers
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 CARD32 j, reply length
4 CARD32 m, number of SCREENVISINFOs in list
20 unused
4j LISTofSCREENVISINFO m SCREENVISINFOs
DBEGetBackBufferAttributes
1 CARD8 major-opcode
1 7 minor-opcode
2 2 request length
4 BACKBUFFER back-buffer-name
=>
1 unused
2 CARD16 sequence number
4 0 reply length
4 BUFFER_ATTRIBUTES attributes
20 unused
Acknowledgements
We wish to thank the following individuals who have contributed their time
and talent toward shaping the DBE specification:
T. Alex Chen, IBM; Peter Daifuku, Silicon Graphics, Inc.;
Ian Elliott, Hewlett-Packard Company; Stephen Gildea, X Consortium, Inc.;
Jim Graham, Sun; Larry Hare, AGE Logic; Jay Hersh, X Consortium, Inc.;
Daryl Huff, Sun; Deron Dann Johnson, Sun; Louis Khouw, Sun;
Mark Kilgard, Silicon Graphics, Inc.; Rob
Lembree, Digital Equipment Corporation; Alan Ricker, Metheus; Michael
Rosenblum, Digital Equipment Corporation; Bob Scheifler, X Consortium, Inc.;
Larry Seiler, Digital Equipment Corporation; Jeanne Sparlin Smith, IBM;
Jeff Stevenson, Hewlett-Packard Company; Walter Strand, Metheus; Ken
Tidwell, Hewlett-Packard Company; and David P. Wiggins, X Consortium, Inc.
Mark provided the impetus to start the DBE project. Ian wrote the first
draft of the specification. David served as architect.
References
Jeffrey Friedberg, Larry Seiler, and Jeff Vroom, "Multi-buffering Extension
Specification Version 3.3."
Tim Glauert, Dave Carver, Jim Gettys, and David P. Wiggins,
"X Synchronization Extension Version 3.0."
xorgproto-2023.2/specs/xextproto/security.xml 0000644 0001750 0001750 00000132537 14443010026 016355 0000000 0000000
%defs;
]>
Security Extension Specification
X Consortium Standard
David P. Wiggins
X Consortium
X Version 11, Release &fullrelvers;
Version 7.1
1996 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the “Software”), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
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.
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.
X Window System is a trademark of The OpenGroup.
November 15, 1996
Introduction
The Security extension contains new protocol needed to provide enhanced X
server security. The Security extension should not be exposed to untrusted
clients (defined below).
Requests
SecurityQueryVersion
This request returns the major and minor version numbers of this extension.
SecurityQueryVersion
client-major-version
CARD16
client-minor-version
CARD16
=>
server-major-version
CARD16
server-minor-version
CARD16
The client-major-version and client-minor-version numbers indicate what
version of the protocol the client wants the server to implement. The
server-major-version and the server-minor-version numbers returned
indicate the protocol this extension actually supports. This might not
equal the version sent by the client. An implementation can (but need not)
support more than one version simultaneously. The server-major-version
and server-minor-version allow the creation of future revisions of the
Security protocol that may be necessary. In general, the major version
would increment for incompatible changes, and the minor version would
increment for small, upward-compatible changes. Servers that support
the protocol defined in this document will return a server-major-version
of one (1), and a server-minor-version of zero (0).
Clients using the Security extension must issue a SecurityQueryVersion
request before any other Security request in order to negotiate a compatible
protocol version; otherwise, the client will get undefined behavior
(Security may or may not work).
SecurityGenerateAuthorization
This request causes the server to create and return a new authorization with
specific characteristics. Clients can subsequently connect using the new
authorization and will inherit some of the characteristics of the
authorization.
SecurityGenerateAuthorization
authorization-protocol-name
STRING8
authorization-protocol-data
STRING8
value-mask
BITMASK
value-list
LISTofVALUE
=>
authorization-id
AUTHID
authorization-data-return
STRING8
Errors: AuthorizationProtocol , Value , Alloc
authorization-protocol-name is the name of the authorization method for
which the server should generate a new authorization that subsequent
clients can use to connect to the server. If the authorization-protocol-name
is not one that the server supports, or if authorization-protocol-data
does not make sense for the given authorization-protocol-name, an
AuthorizationProtocol error results.
authorization-protocol-data is authorization-method specific data that can
be used in some way to generate the authorization.
In this version of the extension, the only authorization method
required to be supported is "MIT-MAGIC-COOKIE-1" with any amount
of authorization-protocol-data (including none). The server may use the
authorization-protocol-data as an additional source of randomness used
to generate the authorization. Other authorization methods can supply
their own interpretation of authorization-protocol-data.
The value-mask and value-list specify attributes of the authorization
that are to be explicitly initialized. The possible values are:
Attribute
Type
Default
timeout
CARD32
60
group
XID or None
None
trust-level
{SecurityClientTrusted,
SecurityClientUntrusted}
SecurityClientUntrusted
event-mask
SecurityAuthorizationRevoked,
or None
None
timeout is the timeout period in seconds for this authorization. A
timeout value of zero means this authorization will never expire. For
non-zero timeout values, when timeout seconds have elapsed since the
last time that the authorization entered the state of having no
connections authorized by it, and if no new connections used the
authorization during that time, the authorization is automatically purged.
(Note that when an authorization is created, it enters the state of having no
connections authorized by it.) Subsequent connection attempts using that
authorization will fail. This is to facilitate "fire and forget" launching of
applications.
group is an application group ID as defined by the Application Group
extension, or None. Any other values will cause a Value error. When a
group is destroyed, all authorizations specifying that group are revoked
as described under the SecurityRevokeAuthorization request. The Application
Group extension attaches additional semantics to the group.
trust-level tells whether clients using the authorization are trusted or
untrusted. If trust-level is not one of the constants SecurityClientTrusted
or SecurityClientUntrusted, a Value error results.
event-mask defines which events the client is interested in for this
authorization. When the authorization expires or is revoked if event-mask
contains SecurityAuthorizationRevoked a SecurityAuthorizationRevoked event
is reported to the client.
The SecurityAuthorizationRevoked event contains the following field:
Field
Type
authorization-id
AUTHID
where authorization-id is the identification of the authorization that was
revoked.
If an invalid value-mask is specified, a Value error occurs.
The returned authorization-id is a non-zero value that uniquely identifies
this authorization for use in other requests. The value space for type
AUTHID is not required to be disjoint from values spaces of other core
X types, e.g. resource ids, atoms, visual ids, and keysyms. Thus, a given
numeric value might be both a valid AUTHID and a valid atom, for example.
authorization-data-return is the data that a client should use in some
authorization-method-specific way to make a connection with this
authorization. For "MIT-MAGIC-COOKIE-1," authorization-data-return should
be sent as the authorization-protocol-data in the connection setup message.
It is not required that other authorization methods use
authorization-data-return this way.
SecurityRevokeAuthorization
This request deletes an authorization created by SecurityGenerateAuthorization.
SecurityRevokeAuthorization
authorization-id
AUTHID
Errors: Authorization
If authorization-id does not name a valid authorization, an Authorization
error occurs. Otherwise, this request kills all clients currently connected
using the authorization specified by authorization-id. The authorization is
deleted from the server's database, so future attempts by clients to connect
with this authorization will fail.
Changes to Core Requests
A server supporting this extension modifies the handling of some core
requests in the following ways.
Resource ID Usage
If an untrusted client makes a request that specifies a resource ID that is
not owned by another untrusted client, a protocol error is sent to the
requesting client indicating that the specified resource does not exist.
The following exceptions apply. An untrusted client can:
use the QueryTree, GetGeometry, and TranslateCoordinates requests
without restriction.
use colormap IDs that are returned in the default-colormap field of its
connection setup information in any colormap requests.
specify a root window as:
the drawable field of CreatePixmap, CreateGC, and QueryBestSize.
the parent field of CreateWindow.
the window field of CreateColormap, ListProperties, and GetWindowAttributes.
the grab-window or confine-to fields of GrabPointer.
the grab-window field of UngrabButton.
the destination of SendEvent, but only if all of the following are true.
(These conditions cover all the events that the ICCCM specifies with
a root window destination.)
The propagate field of SendEvent is False.
The event-mask field of SendEvent is ColormapChange,
StructureNotify, or the logical OR of SubstructureRedirect with
SubstructureNotify.
The event type being sent is UnmapNotify, ConfigureRequest, or
ClientMessage.
the window field of ChangeWindowAttributes, but only if the value-mask
contains only event-mask and the corresponding value is StructureNotify,
PropertyChange, or the logical OR of both.
ISSUE: are root window exceptions needed for these? WarpPointer, ReparentWindow
(parent), CirculateWindow, QueryPointer (emacs does this), GetMotionEvents.
Extension Security
This extension introduces the notion of secure and insecure extensions. A
secure extension is believed to be safe to use by untrusted clients; that
is, there are no significant security concerns known that an untrusted
client could use to destroy, modify, or steal data of trusted clients. This
belief may be founded on a careful analysis of the extension protocol,
its implementation, and measures taken to "harden" the extension to close
security weaknesses. All extensions not considered secure are called
insecure. The implementation details of how an extension is identified as
secure or insecure are beyond the scope of this specification.
ListExtensions will only return names of secure
extensions to untrusted clients.
If an untrusted client uses QueryExtension on an
insecure extension that the server supports, the reply will have the
present field set to False and the major-opcode field set to zero to
indicate that the extension is not supported.
If an untrusted client successfully guesses the major opcode of an
insecure extension, attempts by it to execute requests with that major
opcode will fail with a Request error.
Keyboard Security
The protocol interpretation changes in this section are intended to prevent
untrusted applications from stealing keyboard input that was meant for
trusted clients and to prevent them from interfering with the use of the
keyboard.
The behavior of some keyboard-related requests and events is modified when
the client is untrusted depending on certain server state at the time of
request execution or event generation. Specifically, if a hypothetical
keyboard event were generated given the current input focus, pointer
position, keyboard grab state, and window event selections, and if that
keyboard event would not be delivered to any untrusted client, the
following changes apply:
The bit vector representing the up/down state of the keys returned by
QueryKeymap and
KeymapNotify is all zeroes.
GrabKeyboard returns a status of AlreadyGrabbed.
SetInputFocus does nothing. Note that this means the
Globally Active
Input and WM_TAKE_FOCUS mechanisms specified in the ICCCM will
not work with untrusted clients.
Passive grabs established by GrabKey that would otherwise have activated
do not activate.
If an untrusted client attempts to use any of the following requests, the
only effect is that the client receives an Access error: SetModifierMapping,
ChangeKeyboardMapping, ChangeKeyboardControl.
If an InputOnly window owned by an untrusted client has a parent owned by a
trusted client, all attempts to map the window will be ignored. This includes
mapping attempts resulting from MapWindow, MapSubwindows, ReparentWindow,
and save-set processing.
However, if the parent of an InputOnly window owned by an untrusted client
is the root window, attempts to map that window will be performed as
expected. This is in line with the root window exceptions above.
Image Security
It should be impossible for an untrusted client to retrieve the image
contents of a trusted window unless a trusted client takes action to allow
this. We introduce the following defenses in support of this requirement.
The restrictions on resource ID usage listed above prevent untrusted clients
from using GetImage directly on windows not belonging to trusted clients.
If an untrusted client tries to set the background-pixmap attribute of an
untrusted window to None, the server will instead use a server-dependent
background which must be different than None.
The X protocol description of GetImage states that the
returned contents of regions of a window obscured by noninferior windows are
undefined if the window has no backing store. Some implementations return the
contents of the obscuring windows in these regions. When an untrusted client
uses GetImage , this behavior is forbidden; the server must
fill the obscured regions in the returned image with a server-dependent pattern.
If an untrusted window has trusted inferiors, their contents are vulnerable
to theft via GetImage on the untrusted parent, as well
as being vulnerable to destruction via drawing with subwindow-mode
IncludeInferiors on the untrusted parent. An untrusted window having trusted
inferiors can only occur at the request of a trusted client. It is expected
to be an unusual configuration.
Property Security
Unlike the other security provisions described in this document, security for
property access is not amenable to a fixed policy because properties are
used for inter-client communication in diverse ways and may contain data of
varying degrees of sensitivity. Therefore, we only list the possible
restrictions the server may decide to impose on use of properties on trusted
windows by untrusted clients. How the server chooses which restrictions from
this list to apply to a particular property access is implementation dependent
In the X Consortium server implementation, property access is controlled by
a configuration file; see the -sp option in the Xserver(1) manual page.
The X Protocol property requests are
ChangeProperty ,
GetProperty ,
DeleteProperty ,
RotateProperties , and
ListProperties . For these requests, the server can
allow the request to execute normally (as if it had been issued by a
trusted client), ignore the request completely (as if it were a NoOperation),
or ignore the request except to send an Atom error to the client. Ignoring
a ListProperties request means replying that
the window has no properties. ListProperties may also
reply with a subset of the existing properties if the server is doing
property hiding; see below. An ignored GetProperty
request may reply that the property does not exist, or that it exists but
contains no data.
The server may decide to hide certain properties on certain windows from
untrusted clients
The X Consortium server implementation does not currently provide a way to
hide properties.
That property should not be returned by
ListProperties .
PropertyNotify events should not be sent for that
property.
GetProperty on that property should reply that the
property does not exist (the return type is None, the format and
bytes-after are zero, and the value is empty).
For a property that the server is protecting but not hiding, consistency
must also be maintained:
That property should be returned by ListProperties .
PropertyNotify events should be sent for that property.
GetProperty on that property should reply that the
property exists (if it really does) but the value is empty
(return type and format are their real values, and the "length of value"
field in the reply is zero).
Miscellaneous Security
If an untrusted client attempts to use
ChangeHosts ,
ListHosts , or
SetAccessControl ,
the only effect is that the client receives an Access error.
If an untrusted client attempts to use ConvertSelection
on a selection with a trusted selection owner window, the server generates
a SelectionNotify event to the requestor with property None.
New Authorization Method
This extension includes a new authorization method named
"XC-QUERY-SECURITY-1". Its purpose is to allow an external agent such as
the X firewall proxy to probe an X server to determine whether that server
meets certain security criteria without requiring the agent to have its
own authorization for that server. The agent may use the returned information
to make a decision. For example, the X firewall proxy may choose not to
forward client connections to servers that do not meet the criteria.
To use this authorization method, the client (or proxy) sends
"XC-QUERY-SECURITY-1" as the authorization-protocol-name in the initial
connection setup message. The authorization-protocol-data may be empty or
may contain additional security criteria described below. If the success
field of the server's reply is Authenticate, the server supports the
security extension, and the server meets all specified additional security
criteria. In this case, the client should resend the initial connection
setup message substituting the authorization protocol name and data
that should be used to authorize the connection. If the success field of the
server's reply is anything other than Authenticate, either the server does not
support the security extension, does not meet (or cannot determine if it
meets) all of the additional security criteria, or chooses for internal reasons
not to answer with Authenticate. In this case, the client should close the
connection.
If the authorization-protocol-data sent with "XC-QUERY-SECURITY-1" is not
empty, it specifies additional security criteria for the server to check, as
follows.
authorization-protocol-data
policy-mask
BITMASK
policies
LISTofSECURITYPOLICY
The policy-mask field is any logical-OR combination of the constants
Extensions and SitePolicies. For each bit set in policy-mask, there is a
SECURITYPOLICY element in policies. The nth element in policies corresponds
to the nth 1-bit in policy-mask, counting upward from bit 0.
SECURITYPOLICY
policy-type
{Disallow, Permit}
names
LISTofSTR
For a SECURITYPOLICY corresponding to policy-mask Extensions, if
policy-type is Disallow the server is required to consider as insecure
all extensions given in names. No policy is specified for extensions
not listed in names. If policy-type is Permit the server may consider
only those extensions given in names to be secure; all other extensions
must be treated as insecure. If these constraints are not met, the server
should not return Authenticate in the success field of the reply.
Servers can but need not dynamically configure themselves in response
to an Extensions SECURITYPOLICY; a conforming server might simply compare
the policy with a compiled-in table of extensions and their security status.
For a SECURITYPOLICY corresponding to policy-mask SitePolicies, policy-type
Disallow means the server must not have been configured with any of the site
policies given in names. Policy-type Permit means the server must have
been configured with at least one of the site policies given in names. If
these constraints are not met, the server should not return Authenticate in
the success field of the reply.
SitePolicies provide a way to express new forms of security-relevant
information that could not be anticipated at the time of this writing.
For example, suppose the server is found to have a critical security defect.
When a fix is developed, a site policy string could be associated with the
fix. Servers with the fix would advertise that site policy, and the X
firewall proxy would specify that site policy in a SECURITYPOLICY with
policy-type Permit.
Encoding
Please refer to the X11 Protocol Encoding document as this section
uses syntactic conventions and data types established there.
The name of this extension is "SECURITY".
Types
AUTHID: CARD32
Request Encoding
SecurityQueryVersion
1 CARD8 major-opcode
1 0 minor-opcode
2 2 request length
2 CARD16 client-major-version
2 CARD16 client-minor-version
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 server-major-version
2 CARD16 server-minor-version
20 unused
SecurityRevokeAuthorization
1 CARD8 major-opcode
1 2 minor-opcode
2 2 request length
4 AUTHID authorization-id
SecurityGenerateAuthorization
1 CARD8 major-opcode
1 1 minor-opcode
2 3 + (m+n+3)/4 + s request length
2 CARD16 m, number of bytes in authorization protocol name
2 CARD16 n, number of bytes in authorization data
m STRING8 authorization protocol name
n STRING8 authorization protocol data
p unused, p=pad(m+n)
4 BITMASK value-mask (has s bits set to 1)
#x00000001 timeout
#x00000002 trust-level
#x00000004 group
#x00000008 event-mask
4s LISTofVALUE value-list
VALUES
4 CARD32 timeout
4 trust-level
0 SecurityClientTrusted
1 SecurityClientUntrusted
4 XID group
0 None
4 CARD32 event-mask
#x00000001 SecurityAuthorizationRevoked
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 (q+3)/4 reply length
4 AUTHID authorization-id
2 CARD16 data-length
18 unused
q STRING8 authorization-data-return
r unused, r=pad(q)
Event Encoding
SecurityAuthorizationRevoked
1 0+extension event base code
1 unused
2 CARD16 sequence number
4 AUTHID authorization id
24 unused
Authorization Method Encoding
For authorization-protocol-name "XC-QUERY-SECURITY-1", the
authorization-protocol-data is interpreted as follows:
authorization-protocol-data
1 BITMASK policy-mask
#x00000001 Extensions
#x00000002 SitePolicies
m LISTofSECURITYPOLICY policies
SECURITYPOLICY
1 policy-type
0 Permit
1 Disallow
1 CARD8 number of STRs in names
n LISTofSTR names
LISTofSTR has the same encoding as in the X protocol: each STR is a single
byte length, followed by that many characters, and there is no padding or
termination between STRs.
C Language Binding
The header for this extension is <X11/extensions/security.h>. All
identifier names provided by this header begin with XSecurity.
All functions that have return type Status will return nonzero for
success and zero for failure.
Status XSecurityQueryExtension
Display *dpy
int *major_version_return
int *minor_version_return
Xauth *XSecurityAllocXauth
void
In order to provide for future evolution, Xauth structures are used to
pass and return authorization data, and the library provides ways to
allocate and deallocate them.
For the purposes of the Security extension, the Xauth structure has
the following fields:
Type
Field name
Description
unsigned short
name_length
number of bytes in name
char *
name
authorization protocol name
unsigned short
data_length
number of bytes in data
char *
data
authorization protocol data
The Xauth structure returned by this function is initialized as follows:
name_length and data_length are zero, and name and data are NULL.
void XSecurityFreeXauth
Xauth *auth
Bool XSecurityRevokeAuthorization
Display *dpy
XSecurityAuthorization auth_id
Xauth *XSecurityGenerateAuthorization
Display *dpy
Xauth *auth_in
unsigned long valuemask
XSecurityAutorizationAttributes *attributes
XSecurityAutorization *auth_id_return
The XSecurityAuthorizationAttributes structure has the following fields:
Type
Field name
Mask
unsigned int
trust_level
XSecurityTrustLevel
unsigned int
timeout
XSecurityTimeout
XID
group
XSecurityGroup
long
event_mask
XSecurityEventMask
These correspond to the trust-level, timeout, group, and event-mask
described in the SecurityGenerateAuthorization protocol request. The
caller can fill in values for any subset of these attributes. The valuemask
argument must be the bitwise OR of the symbols listed in the Mask column
for all supplied attributes. The event_mask attribute can be None,
XSecurityAuthorizationRevokedMask, or XSecurityAllEventMasks. In this
revision of the protocol specification XSecurityAllEventMasks is equivalent
to XSecurityAuthorizationRevokedMask. If the caller does not need to
specify any attributes, the attributes argument can be NULL, and the
valuemask argument must be zero.
If the function fails, NULL is returned and auth_id_return is filled in
with zero. Otherwise, a pointer to an Xauth structure is returned. The name
and name_length fields of the returned Xauth structure will be copies of the
name that was passed in, and the data and data_length fields will be set to
the authorization data returned by the server. The caller should not assume
that name and data are null-terminated strings. If no authorization data was
returned by the server, the data and data_length fields will be set to NULL
and zero respectively. The returned Xauth structure must be freed with
The XSecurityAuthorizationRevokedEvent structure has the following fields:
Type
Field name
Description
int
type
event base + XSecurityAuthorizationRevoked
unsigned long
serial
# of last request processed by server
Bool
send_event
true if this came from SendEvent
Display*
display
Display the event was read from
XSecurityAuthorization
auth_id
revoked authorization id
xorgproto-2023.2/specs/xextproto/multibuf.xml 0000644 0001750 0001750 00000143173 14443010026 016333 0000000 0000000
%defs;
]>
Extending X for Double-Buffering, Multi-Buffering, and Stereo
Jeffrey Friedberg
Larry Seiler
Jeff Vroom
1989 Digital Equipment Corporation X Version 11, Release &fullrelvers;
Version 3.3
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.
Digital Equipment Corporation 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. This document
is subject to change.
Copyright © 1989, 1994 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the ``Software''), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
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.
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.
X Window System is a trademark of The OpenGroup.
Warning
The Multi-Buffering 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.
Introduction
Several proposals have been written that address some of the
issues surrounding the support of double-buffered, multi-buffered,
and stereo windows in the X Window System:
Extending X for Double-Buffering,
Jeffrey Friedberg, Larry Seiler, Randi Rost.
(Proposal for) Double-Buffering Extensions ,
Jeff Vroom.
An Extension to X.11 for Displays with Multiple Buffers,
David S.H. Rosenthal.
A Multiple Buffering/Stereo Proposal ,
Mark Patrick.
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.
Goals
Clients should be able to:
Associate multiple buffers with a window.
Paint in any buffer associated with a window.
Display any buffer associated with a window.
Display a series of buffers in a window in rapid succession
to achieve a smooth animation.
Request simultaneous display of different buffers in different windows.
In addition, the extension should:
Allow existing X applications to run unchanged.
Support a range of implementation methods that can capitalize on
existing hardware features.
Image Buffers
Normal windows are created using the standard
CreateWindow request:
CreateWindow
parent : WINDOW
w_id : WINDOW
depth : CARD8
visual : VISUALID or CopyFromParent
x, y : INT16
width, height : INT16
border_width : INT16
value_mask : BITMASK
value_list : LISTofVALUE
This request allocates a set of window attributes and
a buffer into which an image can be drawn.
The contents of this image buffer will
be displayed when the window is mapped to the screen.
To support double-buffering and multi-buffering,
we introduce the notion that additional image buffers can
be created and bound together to form groups.
The following rules will apply:
All image buffers in a group will have the same
visual type, depth, and geometry (ie: width and height).
Only one image buffer per group can be displayed
at a time.
Draw operations can occur to any image buffer at
any time.
Window management requests (MapWindow , DestroyWindow ,
ConfigureWindow , etc...)
affect all image buffers associated with a window.
Appropriate resize and exposure events will be generated
for every image buffer that is affected by a window
management operation.
By allowing draw operations to occur on any image buffer at any time,
a client could, on a multi-threaded multi-processor server,
simultaneously build up images for display.
To support this, each buffer must have its own resource ID.
Since buffers are different than windows and pixmaps
(buffers are not hierarchical and pixmaps cannot be displayed)
a new resource, Buffer , is introduced.
Furthermore, a Buffer is also a Drawable , thus
draw operations may also be performed on buffers simply
by passing a buffer ID to the existing pixmap/window
interface.
To allow existing X applications to work unchanged, we assume
a window ID passed in a draw request, for a multi-buffered
window, will be an alias for the ID of the currently
displayed image buffer. Any draw requests (eq: GetImage ) on
the window will be relative to the displayed image buffer.
In window management requests, only a window ID will be
accepted. Requests like QueryTree , will continue to
return only window ID's. Most events will return
just the window ID. Some new events, described in a subsequent
section, will return a buffer ID.
When a window has backing store the contents of the window
are saved off-screen. Likewise, when the contents of an image
buffer of a multi-buffer window is saved off-screen, it is
said to have backing store. This applies to all image buffers,
whether or not they are selected for display.
In some multi-buffer implementations, undisplayed buffers might be
implemented using pixmaps. Since the contents of pixmaps exist
off-screen and are not affected by occlusion, these image buffers
in effect have backing store.
On the other hand, both the displayed and undisplayed image buffers
might be implemented using a subset of the on-screen pixels.
In this case, unless the contents of an image buffer are saved
off-screen, these image buffers in effect do not have backing store.
Output to any image buffer of an unmapped multi-buffered window
that does not have backing store is discarded. Output to any
image buffer of a mapped multi-buffer window will be performed;
however, portions of an image buffer may be occluded or clipped.
When an unmapped multi-buffered window becomes mapped, the contents
of any image buffer buffer that did not have backing store is
tiled with the background and zero or more exposure events are
generated. If no background is defined for the window, then
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.
New Requests
The new request, CreateImageBuffers , creates a group of
image buffers and associates them with a normal X window:
CreateImageBuffers
w_id : WINDOW
buffers : LISTofBUFFER
update_action : {Undefined,Background,Untouched,Copied}
update_hint : {Frequent,Intermittent,Static}
=>
number_buffers : CARD16
(Errors: Window, IDChoice, Value)
One image buffer will be associated with each ID passed in
buffers .
The first buffer of the list is referred to as buffer[0], the next
buffer[1], and so on. Each buffer will have the same visual type
and geometry as the window.
Buffer[0] will refer to the image buffer already associated
with the window ID and its contents will not be modified.
The displayed image buffer attribute is set to buffer[0].
Image buffers for the remaining ID's (buffer[1],...) are allocated.
If the window is mapped, or if these image buffers have backing
store, their contents will be tiled with the window background
(if no background is defined, the buffer contents are undefined),
and zero or more expose events will be generated for each of these
buffers. The contents of an image buffer is undefined when
the window is unmapped and the buffer does not have backing store.
If the window already has a group of image buffers
associated with it (ie: from a previous CreateImageBuffers request)
the actions described for DestroyImageBuffers are performed first
(this will delete the association of the previous buffer ID's and
their buffers as well as de-allocate all buffers except for the
one already associated with the window ID).
To allow a server implementation to efficiently allocate the
buffers, the total number of buffers required and
the update action (how they will behave during an update)
is specified "up front" in the request.
If the server cannot allocate all the buffers requested, the
total number of buffers actually allocated will be returned.
No Alloc errors will be generated \- buffer[0] can
always be associated with the existing displayed image buffer.
For example, an application that wants to animate a short movie
loop may request 64 image buffers. The server may only be able to
support 16 image buffers of this type, size, and depth.
The application can then decide 16 buffers is sufficient and may
truncate the movie loop, or it may decide it really needs
64 and will free the buffers and complain to the user.
One might be tempted to provide a request that inquires whether
n
buffers of a particular type, size, and depth
could be allocated.
But if the query is decoupled from the actual allocation,
another client could sneak in and take the buffers before the
original client has allocated them.
While any buffer of a group can be selected for display,
some applications may display buffers in a predictable order
(ie: the movie loop application). The
list order
(buffer[0], buffer[1], ...) will be used as a hint by the
server as to which buffer will be displayed next.
A client displaying buffers in this order may see a
performance improvement.
update_action indicates what should happen to a previously
displayed buffer when a different buffer becomes displayed.
Possible actions are:
Undefined
The contents of the buffer that was
last displayed will become undefined after the update. This
is the most efficient action since it allows the implementation
to trash the contents of the buffer if it needs to.
Background
The contents of the buffer that was
last displayed will be set to the background of the window after the update.
The background action allows devices to use a fast clear
capability during an update.
Untouched
The contents of the buffer that was
last displayed will be untouched after the update. Used
primarily when cycling through images that have already
been drawn.
Copied
The contents of the buffer that was
last displayed will become the same as those that are being
displayed after the update. This is useful when incrementally
adding to an image.
update_hint indicates how often the client will
request a different buffer to be displayed.
This hint will allow smart server implementations to choose the
most efficient means to support a multi-buffered window based
on the current need of the application (dumb implementations
may choose to ignore this hint). Possible hints are:
Frequent
An animation or movie loop is
being attempted and the fastest, most efficient means for
multi-buffering should be employed.
Intermittent
The displayed image will be
changed every so often. This is common for images that are
displayed at a rate slower than a second. For example, a
clock that is updated only once a minute.
Static
The displayed image buffer will
not be changed any time soon. Typically set by an application
whenever there is a pause in the animation.
To display an image buffer the following request can be used:
DisplayImageBuffers
buffers : LISTofBUFFER
min_delay : CARD16
max_delay : CARD16
(Errors: Buffer, Match)
The image buffers listed will become displayed as simultaneously
as possible and the update action, bound at
CreateImageBuffers
time, will be performed.
A list of buffers is specified to
allow the server to efficiently change the display of more than one
window at a time (ie: when a global screen swap method is used).
Attempting to simultaneously display
multiple image buffers from the same window is an error
(Match ) since it violates the rule that only one
image buffer per group can be displayed at a time.
If a specified buffer is already displayed,
any delays and update action will still be
performed for that buffer. In this instance,
only the update action of Background
(and possibly
Undefined ) will have any affect on the
contents of the displayed buffer. These semantics allow
an animation application to successfully execute
even when there is only a single buffer available
for a window.
When a DisplayImageBuffers request is made to an unmapped
multi-buffered window, the effect of the update action depends
on whether the image buffers involved have backing store.
When the target of the update action is an image buffer that
does not have backing store, output is discarded. When the
target image buffer does have backing store, the update is performed;
however, when the source of the update is an image buffer does not
have backing store (as in the case of update action
Copied ), the
contents of target image buffer will become undefined.
min_delay and
max_delay put a bound on how long the
server should wait before processing the display request.
For each of the windows to be updated by this request, at least
min_delay milli-seconds should elapse since
the last
time any of the windows were updated; conversely, no window
should have to wait more than max_delay
milli-seconds before being updated.
min_delay allows an application to
slow down an animation or movie loop so that
it appears
synchronized at a rate the server can support given the current load.
For example, a min_delay of 100 indicates the
server should
wait at least 1/10 of a second since the last time any of the
windows were updated. A min_delay of zero
indicates no waiting is necessary.
max_delay can be thought of as an additional
delay beyond min_delay the server is allowed
to wait
to facilitate such things as efficient update of multiple windows.
If max_delay would require an update before
min_delay
is satisfied, then the server should process the display request as
soon as the min_delay requirement is met. A
typical value for max_delay is zero.
To implement the above functionality, the time since the last
update by a DisplayImageBuffers request for each
multi-buffered
window needs to be saved as state by the server.
The server may delay execution of the DisplayImageBuffers
request until the appropriate time (e.g. by requeuing the
request after computing the timeout);
however, the entire request must be processed in one operation.
Request execution indivisibility must be maintained. When
a server is implemented with internal concurrency, the
extension must adhere to the same concurrency semantics
as those defined for the core protocol.
To explicitly clear a rectangular area of an image buffer to
the window background, the following request can be used:
ClearImageBufferArea
buffer : BUFFER
x, y : INT16
w, h : CARD16
exposures : BOOL
(Errors: Buffer, Value)
Like the X ClearArea request,
x and y
are relative to
the window's origin and specify the upper-left corner of the rectangle.
If width is zero, it is replaced with the
current window width
minus x . If
height is zero it is replaced with the current
window height minus y . If the window has a
defined background tile, the rectangle is tiled with a plane mask of all ones,
a function of Copy , and a subwindow-mode of
ClipByChildren .
If the window has background None , the
contents of the buffer
are not changed. In either case, if
exposures is true, then one or
more exposure events are generated for regions of the rectangle that are
either visible or are being retained in backing store.
The group of image buffers allocated by a
CreateImageBuffers
request can be destroyed with the following request:
DestroyImageBuffers
w_id : WINDOW
(Error: Window)
The association between the buffer ID's and their corresponding
image buffers are deleted. Any image buffers not selected for
display are de-allocated. If the window is not multi-buffered,
the request is ignored.
Attributes
The following attributes will be associated with each window that
is multi-buffered:
displayed_buffer : CARD16
update_action : {Undefined,Background,Untouched,Copied}
update_hint : {Frequent,Intermittent,Static}
window_mode : {Mono,Stereo}
buffers : LISTofBUFFER
displayed_buffer is set to the
index of the currently
displayed image buffer (for stereo windows, this will be
the index of the left buffer \- the index of the right buffer
is simply index +1).
window_mode indicates whether this window is
Mono or Stereo .
The ID for each buffer associated with the window is recorded
in the buffers list.
The above attributes can be queried with the following request:
GetMultiBufferAttributes
w_id : WINDOW
=>
displayed_buffer : CARD16
update_action : {Undefined,Background,Untouched,Copied}
update_hint : {Frequent,Intermittent,Static}
window_mode : {Mono,Stereo}
buffers : LISTofBUFFER
(Errors: Window, Access, Value)
If the window is not multi-buffered, a Access error
will be generated.
The only multi-buffer attribute that can be explicitly set
is update_hint . Rather than have a specific
request to set this attribute, a generic set request is provided to
allow for future expansion:
SetMultiBufferAttributes
w_id : WINDOW
value_mask : BITMASK
value_list : LISTofVALUE
(Errors: Window, Match, Value)
If the window is not multi-buffered, a Match error
will be generated.
The following attributes are maintained for each buffer of a
multi-buffered window:
window : WINDOW
event_mask : SETofEVENT
index : CARD16
side : {Mono,Left,Right}
window indicates the window this buffer is
associated with.
event_mask specifies which events, relevant to
buffers, will be sent back to the client via the associated buffer ID
(initially no events are selected).
index is the list position (0, 1, ...) of the
buffer.
side indicates whether this buffer is
associated with
the left side or right side of a stereo window.
For non-stereo windows, this attribute will be set to
Mono .
These attributes can be queried with the following request:
GetBufferAttributes
buffer : BUFFER
=>
window : WINDOW
event_mask : SETofEVENT
index : CARD16
side : {Mono,Left,Right}
(Errors: Buffer, Value)
The only buffer attribute that can be explicitly set
is event_mask .
The only events that are valid are
Expose and the new
ClobberNotify and UpdateNotify
event (see Events section below).
A Value error will be generated if an event not
selectable for a buffer is specified in an event mask.
Rather than have a specific request
to set this attribute, a generic set request is provided to
allow for future expansion:
SetBufferAttributes
buffer : BUFFER
value_mask : BITMASK
value_list : LISTofVALUE
(Errors: Buffer, Value)
Clients may want to query the server about basic multi-buffer
and stereo capability on a per screen basis. The following request
returns a large list of information
that would most likely be read once by Xlib for each screen, and used as a
data base for other Xlib queries:
GetBufferInfo
root : WINDOW
=>
info : LISTofSCREEN_INFO
Where SCREEN_INFO and
BUFFER_INFO are defined as:
SCREEN_INFO : [ normal_info : LISTofBUFFER_INFO,
stereo_info : LISTofBUFFER_INFO ]
BUFFER_INFO : [ visual : VISUALID,
max_buffers : CARD16,
depth : CARD8 ]
Information regarding multi-buffering of normal (mono) windows
is returned in the normal_info list.
The stereo_info
list contains information about stereo windows.
If the stereo_info list is empty, stereo
windows are
not supported on the screen. If
max_buffers is zero,
the maximum number of buffers for the depth and visual is
a function of the size of the created window and current
memory limitations.
The following request returns the major and minor version numbers
of this extension:
GetBufferVersion
=>
major_number : CARD8
minor_number : CARD8
The version numbers are an escape hatch in case future revisions of
the protocol are necessary. In general, the major version would
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.
Events
All events normally generated for single-buffered
windows are also generated for multi-buffered windows.
Most of these events (ie: ConfigureNotify ) will
only be generated for the window and not for each buffer.
These events will return a window ID.
Expose events will be generated for both the window
and any buffer affected. When this event is generated for
a buffer, the same event structure will be used
but a buffer ID is returned instead of a window ID.
Clients, when processing these events, will know whether an
ID returned in an event structure is for a window or a buffer
by comparing the returned ID to the ones returned when the
window and buffer were created.
GraphicsExposure and
NoExposure are generated
using whatever ID is specified in the graphics operation.
If a window ID is specified, the event will contain the
window ID. If a buffer ID is specified, the event will
contain the buffer ID.
In some implementations, moving a window
over a multi-buffered window may cause one or more of its buffers
to get overwritten or become unwritable. To allow a
client drawing into one of these buffers the opportunity
to stop drawing until some portion of the buffer is
writable, the following event is added:
ClobberNotify
buffer : BUFFER
state : {Unclobbered,PartiallyClobbered,FullyClobbered}
The ClobberNotify event is reported to clients selecting
ClobberNotify on a buffer. When a buffer
that was fully
or partially clobbered becomes unclobbered, an event with
Unclobbered
is generated. When a buffer that was unclobbered becomes
partially clobbered, an event with
PartiallyClobbered
is generated. When a buffer that was unclobbered or
partially clobbered becomes fully clobbered, an event with
FullyClobbered is generated.
ClobberNotify events on a given buffer are
generated before any Expose events on that buffer,
but it is not required that all ClobberNotify
events on all buffers be generated before all
Expose events on all buffers.
The ordering of ClobberNotify events with respect
to VisibilityNotify events is not constrained.
If multiple buffers were used as an image FIFO between an image
server and the X display server, then the FIFO manager would like
to know when a buffer that was previously displayed, has been
undisplayed and updated, as the side effect of a
DisplayImageBuffers
request. This allows the FIFO manager to load up a future frame as
soon as a buffer becomes available. To support this,
the following event is added:
UpdateNotify
buffer : BUFFER
The UpdateNotify event is reported to clients selecting
UpdateNotify on a buffer. Whenever a buffer
becomes updated
(e.g. its update action is performed as part of a
DisplayImageBuffers
request), an UpdateNotify event is generated.
Errors
The following error type has been added to support
this extension:
Buffer
A value for a BUFFER argument does not name a defined BUFFER.
Double-Buffering Normal Windows
The following pseudo-code fragment illustrates how to create and display
a double-buffered image:
/*
* Create a normal window
*/
CreateWindow( W, ... )
/*
* Create two image buffers. Assume after display, buffer
* contents become "undefined". Assume we will "frequently"
* update the display. Abort if we don't get two buffers,
*/
n = CreateImageBuffers( W, [B0,B1], Undefined, Frequent )
if (n != 2) <abort>
/*
* Map window to the screen
*/
MapWindow( W )
/*
* Draw images using alternate buffers, display every
* 1/10 of a second. Note we draw B1 first so it will
* "pop" on the screen
*/
while animating
{
<draw picture using B1>
DisplayImageBuffers( [B1], 100, 0 )
<draw picture using B0>
DisplayImageBuffers( [B0], 100, 0 )
}
/*
* Strip image buffers and leave window with
* contents of last displayed image buffer.
*/
DestroyImageBuffers( W )
Multi-Buffering Normal Windows
Multi-buffered images are also supported by these requests.
The following pseudo-code fragment illustrates how to create a
a multi-buffered image and cycle through the images to
simulate a movie loop:
/*
* Create a normal window
*/
CreateWindow( W, ... )
/*
* Create 'N' image buffers. Assume after display, buffer
* contents are "untouched". Assume we will "frequently"
* update the display. Abort if we don't get all the buffers.
*/
n = CreateImageBuffers( W, [B0,B1,...,B(N-1)], Untouched, Frequent )
if (n != N) <abort>
/*
* Map window to screen
*/
MapWindow( W )
/*
* Draw each frame of movie one per buffer
*/
foreach frame
<draw frame using B(i)>
/*
* Cycle through frames, one frame every 1/10 of a second.
*/
while animating
{
foreach frame
DisplayImageBuffers( [B(i)], 100, 0 )
}
Stereo Windows
How stereo windows are supported on a server
is implementation
dependent. A server may contain specialized hardware that allows
left and right images to be toggled at field or frame rates. The
stereo affect may only be perceived with the aid of special
viewing glasses. The display of a
stereo picture should
be independent of how often the contents of the picture are
updated by an application. Double and
multi-buffering
of images should be possible regardless of whether the image
is displayed normally or in stereo.
To achieve this goal, a simple extension to normal windows
is suggested. Stereo windows are just like normal windows
except the displayed image is made up of a left image
buffer and a right image buffer. To create a stereo window,
a client makes the following request:
CreateStereoWindow
parent : WINDOW
w_id : WINDOW
left, right : BUFFER
depth : CARD8
visual : VISUALID or CopyFromParent
x, y : INT16
width, height : INT16
border_width : INT16
value_mask : BITMASK
value_list : LISTofVALUE
(Errors: Alloc, Color, Cursor, Match,
Pixmap, Value, Window)
This request, modeled after the CreateWindow request,
adds just two new parameters: left and
right .
For stereo, it is essential that one can distinguish whether
a draw operation is to occur on the left image or right image.
While an internal mode could have been added to achieve this,
using two buffer ID's allows clients to simultaneously build up
the left and right components of a stereo image. These
ID's always refer to (are an alias for) the left and right
image buffers that are currently displayed .
Like normal windows, the window ID is used whenever a window
management operation is to be performed. Window queries would
also return this window ID (eg: QueryTree ) as would most
events. Like the window ID, the left and right buffer ID's
each have their own event mask. They can be set and queried
using the Set/GetBufferAttributes requests.
Using the window ID of a stereo window in a draw request
(eg: GetImage ) results in pixels that are
undefined .
Possible semantics are that both left and right images get
drawn, or just a single side is operated on (existing applications
will have to be re-written to explicitly use the left and right
buffer ID's in order to successfully create, fetch, and store
stereo images).
Having an explicit CreateStereoWindow request is helpful
in that a server implementation will know from the onset whether
a stereo window is desired and can return appropriate status
to the client if it cannot support this functionality.
Some hardware may support separate stereo and non-stereo modes,
perhaps with different vertical resolutions. For example, the
vertical resolution in stereo mode may be half that of non-stereo
mode. Selecting one mode or the other must be done through some
means outside of this extension (eg: by providing a separate
screen for each hardware display mode). The screen attributes
(ie: x/y resolution) for a screen that supports normal windows,
may differ from a screen that supports stereo windows;
however, all windows, regardless of type, displayed on the
same screen must have the same screen attributes
(ie: pixel aspect ratio).
If a screen that supports stereo windows also supports
normal windows, then the images presented to the left and
right eyes for normal windows should be the same
(ie: have no stereo offset).
Single-Buffered Stereo Windows
The following shows how to create and display a single-buffered
stereo image:
/*
* Create the stereo window, map it the screen,
* and draw the left and right images
*/
CreateStereoWindow( W, L, R, ... )
MapWindow( W )
<draw picture using L,R>
Double-Buffering Stereo Windows
Additional image buffers may be added to a stereo window
to allow double or multi-buffering of stereo images.
Simply use the the CreateImageBuffers request.
Even numbered buffers (0,2,...) will be left buffers.
Odd numbered buffers (1,3,...) will be right buffers.
Displayable stereo images are formed by consecutive
left/right pairs of image buffers. For example,
(buffer[0],buffer[1]) form the first displayable
stereo image; (buffer[2],buffer[3]) the next;
and so on.
The CreateImageBuffers request will only create
pairs of left and right image buffers for stereo windows.
By always pairing left and right image
buffers together, implementations might be able to
perform some type of optimization. If an odd number
of buffers is specified, a Value error is generated.
All the rules mentioned at the start of this proposal
still apply to the image buffers supported by a stereo window.
To display a image buffer pair of a multi-buffered stereo image,
either the left buffer ID or right buffer ID may be specified in a
DisplayImageBuffers request, but not both.
To double-buffer a stereo window:
/*
* Create stereo window and map it to the screen
*/
CreateStereoWindow( W, L, R, ... )
/*
* Create two pairs of image buffers. Assume after display,
* buffer contents become "undefined". Assume we will "frequently"
* update the display. Abort if we did get all the buffers.
*/
n = CreateImageBuffers( W, [L0,R0,L1,R1], Undefined, Frequently )
if (n != 4) <abort>
/*
* Map window to the screen
*/
MapWindow( W )
/*
* Draw images using alternate buffers,
* display every 1/10 of a second.
*/
while animating
{
<draw picture using L1,R1>
DisplayImageBuffers( [L1], 100, 0 )
<draw picture using L0,R0>
DisplayImageBuffers( [L0], 100, 0 )
}
Multi-Buffering Stereo Windows
To cycle through N stereo images:
/*
* Create stereo window
*/
CreateStereoWindow( W, L, R, ... )
/*
* Create N pairs of image buffers. Assume after display,
* buffer contents are "untouched". Assume we will "frequently"
* update the display. Abort if we don't get all the buffers.
*/
n = CreateImageBuffers( W, [L0,R0,...,L(N-1),R(N-1)], Untouched, Frequently )
if (n != N*2) <abort>
/*
* Map window to screen
*/
MapWindow( W )
/*
* Draw the left and right halves of each image
*/
foreach stereo image
<draw picture using L(i),R(i)>
/*
* Cycle through images every 1/10 of a second
*/
while animating
{
foreach stereo image
DisplayImageBuffers( [L(i)], 100, 0 )
}
Protocol Encoding
The official name of this extension is "Multi-Buffering".
When this string passed to QueryExtension the
information returned should be interpreted as follows:
major-opcode
Specifies the major opcode of this extension.
The first byte of each extension request should
specify this value.
first-event
Specifies the code that will be returned when
ClobberNotify events are generated.
first-error
Specifies the code that will be returned when
Buffer errors are generated.
The following sections describe the protocol
encoding for this extension.
TYPES
BUFFER_INFO
4 VISUALID visual
2 CARD16 max-buffers
1 CARD8 depth
1 unused
SETofBUFFER_EVENT
#x00008000 Exposure
#x02000000 ClobberNotify
#x04000000 UpdateNotify
EVENTS
ClobberNotify
1 see first-event code
1 unused
2 CARD16 sequence number
4 BUFFER buffer
1 state
0 Unclobbered
1 PartiallyClobbered
2 FullyClobbered
23 unused
UpdateNotify
1 first-event +1 code
1 unused
2 CARD16 sequence number
4 BUFFER buffer
24 unused
ERRORS
Buffer
1 0 Error
1 see first-error code
2 CARD16 sequence number
4 CARD32 bad resource id
2 CARD16 minor-opcode
1 CARD8 major-opcode
21 unused
REQUESTS
GetBufferVersion
1 see major-opcode major-opcode
1 0 minor-opcode
2 1 request length
->
1 1 Reply
1 unused
2 CARD16 sequencenumber
4 0 reply length
1 CARD8 majorversion number
1 CARD8 minorversion number
22 unused
CreateImageBuffers
1 see major-opcode major-opcode
1 1 minor-opcode
2 3+n requestlength
4 WINDOW wid
1 update-action
0 Undefined
1 Background
2 Untouched
3 Copied
1 update-hint
0 Frequent
1 Intermittent
2 Static
2 unused
4n LISTofBUFFER buffer-list
->
1 1 Reply
1 unused
2 CARD16 sequencenumber
4 0 reply length
2 CARD16 number-buffers
22 unused
DestroyImageBuffers
1 see major-opcode major-opcode
1 2 minor-opcode
2 2 request length
4 WINDOW wid
DisplayImageBuffers
1 see major-opcode major-opcode
2 2+n requestlength
2 CARD16 min-delay
2 CARD16 max-delay
4n LISTofBUFFER buffer-list
SetMultiBufferAttributes
1 see major-opcode major-opcode
1 4 minor-opcode
2 3+n requestlength
4 WINDOW wid
4 BITMASK value-mask (has n bits set to 1)
#x00000001 update-hint
4n LISTofVALUE value-list
VALUEs
1 update-hint
0 Frequent
1 Intermittent
2 Static
GetMultiBufferAttributes
1 see major-opcode major-opcode
1 5 minor-opcode
2 2 request length
4 WINDOW wid
®
1 1 Reply
1 unused
2 CARD16 sequencenumber
4 n reply length
2 CARD16 displayed-buffer
1 update-action
0 Undefined
1 Background
2 Untouched
3 Copied
1 update-hint
0 Frequent
1 Intermittent
2 Static
1 window-mode
0 Mono
1 Stereo
19 unused
4n LISTofBUFFER buffer list
SetBufferAttributes
1 see major-opcode major-opcode
1 6 minor-opcode
2 3+n requestlength
4 BUFFER buffer
4 BITMASK value-mask (has n bits set to 1)
#x00000001 event-mask
4n LISTofVALUE value-list
VALUEs
4 SETofBUFFER_EVENT event-mask
GetBufferAttributes
1 see major-opcode major-opcode
1 7 minor-opcode
2 2 request length
4 BUFFER buffer
->
1 1 Reply
1 unused
2 CARD16 sequencenumber
4 0 reply length
4 WINDOW wid
4 SETofBUFFER_EVENT event-mask
2 CARD16 index
1 side
0 Mono
1 Left
2 Right
13 unused
GetBufferInfo
1 see major-opcode major-opcode
1 8 minor-opcode
2 2 request length
4 WINDOW root
®
1 1 Reply
1 unused
2 CARD16 sequencenumber
4 2(n+m) replylength
2 n number BUFFER_INFO in normal-info
2 m number BUFFER_INFO in stereo-info
20 unused
8n LISTofBUFFER_INFO normal-info
8m LISTofBUFFER_INFO stereo-info
CreateStereoWindow
1 see major-opcode major-opcode
1 9 minor-opcode
2 11+n requestlength
3 unused
1 CARD8 depth
4 WINDOW wid
4 WINDOW parent
4 BUFFER left
4 BUFFER right
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border-width
2 class
0 CopyFromParent
1 InputOutput
2 InputOnly
4 VISUALID visual
0 CopyFromParent
4 BITMASK value-mask (has n bits set to 1)
encodings are the same
as for CreateWindow
4n LISTofVALUE value-list
encodings are the same
as for CreateWindow
ClearImageBufferArea
1 see major-opcode major-opcode
1 10 minor-opcode
2 5 request length
4 WINDOW buffer
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
3 unused
1 BOOL exposures
xorgproto-2023.2/specs/xextproto/sync.xml 0000644 0001750 0001750 00000136060 14443010026 015455 0000000 0000000
%defs;
]>
X Synchronization Extension Protocol
X Consortium Standard
Tim Glauert
Olivetti Research
MultiWorks
Dave
Carver
Digital Equipment Corporation
MIT/Project Athena
Jim
Gettys
Digital Equipment Corporation
Cambridge Research Laboratory
David
P.
Wiggins
X Consortium, Inc.
James
Jones
NVIDIA Corporation
X Version 11, Release &fullrelvers;
Version 3.1
1991
Olivetti Research Limited, Cambridge England
Digital Equipment Corporation, Maynard, Massachusetts
X Consortium
2010 NVIDIA Corporation
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, 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.
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files
(the "Software"), to deal in the Software without
restriction, including without limitation the rights to use, copy,
modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished
to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY
KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
EVENT SHALL THE 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.
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.
Synchronization Protocol
The core X protocol makes no guarantees about the relative order of execution
of requests for different clients. This means that any synchronization between
clients must be done at the client level in an operating system-dependent and
network-dependent manner. Even if there was an accepted standard for such
synchronization, the use of a network introduces unpredictable delays between
the synchronization of the clients and the delivery of the resulting requests
to the X server.
The core X protocol also makes no guarantees about the time at which requests
are executed, which means that all clients with real-time constraints must
implement their timing on the host computer. Any such timings are subject to
error introduced by delays within the operating system and network and are
inefficient because of the need for round-trip requests that keep the client
and server synchronized.
The synchronization extension provides primitives that allow synchronization
between clients to take place entirely within the X server. This removes any
error introduced by the network and makes it possible to synchronize clients
on different hosts running different operating systems. This is important for
multimedia applications, where audio, video, and graphics data streams are
being synchronized. The extension also provides internal timers within the
X server to which client requests can be synchronized. This allows simple
animation applications to be implemented without any round-trip requests and
makes best use of buffering within the client, network, and server.
Description
The mechanism used by this extension for synchronization within the X
server is to block the processing of requests from a client until a
specific synchronization condition occurs. When the condition occurs, the
client is released and processing of requests continues. Multiple clients
may block on the same condition to give inter-client synchronization.
Alternatively, a single client may block on a condition such as an animation
frame marker.
The extension adds Counter , Alarm ,
and Fence 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. 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.
The CreateCounter request allows a client to create a
Counter that can be changed by explicit
SetCounter and ChangeCounter
requests. These can be used to implement synchronization between different
clients.
There are some counters, called System Counters , that
are changed by the server internally rather than by client requests. The
effect of any change to a system counter is not visible until the server
has finished processing the current request. In other words, system
counters are apparently updated in the gaps between the execution of
requests rather than during the actual execution of a request. The extension
provides a system counter that advances with the server time as defined by
the core protocol, and it may also provide counters that advance with the
real-world time or that change each time the CRT screen is refreshed.
Other extensions may provide their own extension-specific system counters.
The extension provides an Alarm mechanism that allows
clients to receive an event on a regular basis when a particular counter
is changed.
The CreateFence request allows a client to create a
Fence that can be triggered and reset using
TriggerFence and ResetFence
requests, respectively. CreateFence takes a drawable
argument that implies which screen the fence should be created on. The
TriggerFence 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.
Types
Please refer to the X11 Protocol specification as this document uses
syntactic conventions established there and references types defined there.
The following new types are used by the extension.
INT64: 64-bit signed integer
COUNTER: XID
VALUETYPE: {Absolute,Relative};
TESTTYPE: {PositiveTransition,NegativeTransition,
PositiveComparison,NegativeComparison}
TRIGGER: [
counter:COUNTER,
value-type:VALUETYPE,
wait-value:INT64,
test-type:TESTTYPE
]
WAITCONDITION: [
trigger:TRIGGER,
event-threshold:INT64
]
SYSTEMCOUNTER: [
name:STRING8,
counter:COUNTER,
resolution:INT64
]
ALARM: XID
ALARMSTATE: {Active,Inactive,Destroyed}
FENCE: XID
The COUNTER type defines the client-side handle on a server
Counter . The value of a counter is an INT64.
The TRIGGER type defines a test on a counter that is either TRUE or FALSE. The
value of the test is determined by the combination of a test value, the value
of the counter, and the specified test-type.
The test value for a trigger is calculated using the value-type and
wait-value fields when the trigger is initialized. If the value-type field
is not one of the named VALUETYPE constants, the request that initialized the
trigger will return a Value error. If the value-type
field is Absolute , the test value is given by the
wait-value field. If the value-type field is Relative ,
the test value is obtained by adding the wait-value field to the value of the
counter. If the resulting test value would lie outside the range for an
INT64, the request that initialized the trigger will return a
Value error. If counter is None
and the value-type is Relative , the request that
initialized the trigger will return a Match error. If
counter is not None and does not name a valid counter, a Counter error is
generated.
If the test-type is PositiveTransition , the trigger is
initialized to FALSE, and it will become TRUE when the counter changes from
a value less than the test value to a value greater than or equal to the
test value. If the test-type is NegativeTransition ,
the trigger is initialize to FALSE, and it will become TRUE when the counter
changes from a value greater than the test value to a value less than or
equal to the test value. If the test-type is
PositiveComparison , the trigger is TRUE if the
counter is greater than or equal to the test value and FALSE otherwise. If the
test-type is NegativeComparison , the trigger is TRUE
if the counter is less than or equal to the test value and FALSE otherwise.
If the test-type is not one of the named TESTTYPE constants, the request that
initialized the trigger will return a Value error. A trigger with a counter
value of None and a valid test-type is always TRUE.
The WAITCONDITION type is simply a trigger with an associated event-threshold.
The event threshold is used by the Await request to
decide whether or not to generate an event to the client after the trigger has
become TRUE. By setting the event-threshold to an appropriate value, it is
possible to detect the situation where an Await request
was processed after the TRIGGER became TRUE, which usually indicates that
the server is not processing requests as fast as the client expects.
The SYSTEMCOUNTER type provides the client with information about a
System Counter. The name field is the textual name of
the counter that identifies the counter to the client. The counter field
is the client-side handle that should be used in requests that require a
counter. The resolution field gives the approximate step size of the system
counter. This is a hint to the client
that the extension may not be able to resolve two wait conditions with test
values that differ by less than this step size. A microsecond clock, for
example, may advance in steps of 64 microseconds, so a counter based on this
clock would have a resolution of 64.
The only system counter that is guaranteed to be present is called SERVERTIME,
which counts milliseconds from some arbitrary starting point. The least
significant 32 bits of this counter track the value of Time used by the
server in Events and Requests. Other system counters may be provided by
different implementations of the extension. The X Consortium will maintain a
registry of system counter names to avoid collisions in the name space.
An ALARM is the client-side handle on an Alarm resource.
The FENCE type defines the client-side handle on a server
Fence . 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.
Errors
Counter
This error is generated if the value for a COUNTER argument in a request
does not name a defined COUNTER.
Alarm
This error is generated if the value for an ALARM argument in a request
does not name a defined ALARM.
Fence
This error is generated if the value for a FENCE argument in a request
does not name a defined FENCE.
Requests
Initialize
version-major,version-minor: CARD8
=>
version-major,version-minor: CARD8
This request must be executed before any other requests for this extension. If a
client violates this rule, the results of all SYNC requests that it issues are
undefined. The request takes the version number of the extension that the
client wishes to use and returns the actual version number being implemented
by the extension for this client. The extension may return different
version numbers to a client depending of the version number supplied by
that client. This request should be executed only once for each client
connection.
Given two different versions of the SYNC protocol, v1 and v2, v1 is
compatible with v2 if and only if v1.version_major = v2.version_major
and v1.version_minor <= v2.version_minor. Compatible means that the
functionality is fully supported in an identical fashion in the two versions.
This document describes major version 3, minor version 1 of the SYNC protocol.
ListSystemCounters
=>
system-counters: LISTofSYSTEMCOUNTER
Errors: Alloc
This request returns a list of all the system counters that are available at
the time the request is executed, which includes the system counters
that are maintained by other extensions. The list returned by this
request may change as counters are created and destroyed by other extensions.
CreateCounter
id: COUNTER
initial-value: INT64
Errors: IDChoice,Alloc
This request creates a counter and assigns the specified id to it. The counter
value is initialized to the specified initial-value and there are no clients
waiting on the counter.
DestroyCounter
counter: COUNTER
Errors: Counter,Access
This request destroys the given counter and sets the counter fields for all
triggers that specify this counter to None . All clients
waiting on the counter are released and a CounterNotify
event with the destroyed field set to TRUE is sent to each waiting client,
regardless of the event-threshold. All alarms specifying the counter become
Inactive and an AlarmNotify
event with a state field of Inactive is generated. A
counter is destroyed automatically when the connection to the creating client
is closed down if the close-down mode is Destroy. An
Access error is generated if counter is a system
counter. A Counter error is generated if counter does
not name a valid counter.
QueryCounter
counter: COUNTER
=>
value: INT64
Errors: Counter
This request returns the current value of the given counter or a generates
Counter error if counter does not name a valid counter.
Await
wait-list: LISTofWAITCONDITION
Errors: Counter,Alloc,Value
When this request is executed, the triggers in the wait-list are initialized
using the wait-value and value-type fields, as described in the definition of
TRIGGER above. The processing of further requests for the client is blocked
until one or more of the triggers becomes TRUE. This may happen immediately,
as a result of the initialization, or at some later time, as a result of
a subsequent SetCounter ,
ChangeCounter or
DestroyCounter request.
A Value error is generated if wait-list is empty.
When the client becomes unblocked, each trigger is checked to determine
whether a CounterNotify event should be generated.
The difference between the counter and the test value is calculated by
subtracting the test value from the value of the counter. If the test-type
is PositiveTransition or
PositiveComparison , a
CounterNotify event is generated if the difference is
at least event-threshold. If the test-type is
NegativeTransition or
NegativeComparison , a
CounterNotify event is generated if the difference
is at most event-threshold. If the difference lies outside the range for an
INT64, an event is not generated.
This threshold check is made for each trigger in the list and a
CounterNotify event is generated for every trigger for
which the check succeeds. The check for
CounterNotify events is performed even if one of the
triggers is TRUE when the request is first executed. Note that a
CounterNotify event may be generated for a trigger
that is FALSE if there are multiple triggers in the request. A
CounterNotify event with the destroyed flag set to
TRUE is always generated if the counter for one of the triggers is
destroyed.
ChangeCounter
counter: COUNTER
amount: INT64
Errors: Counter,Access,Value
This request changes the given counter by adding amount to the current
counter value. If the change to this counter satisfies a trigger for which a client
is waiting, that client is unblocked and one or more
CounterNotify events may be generated. If the change to
the counter satisfies the trigger for an alarm, an
AlarmNotify event is generated and the
alarm is updated. An Access error is generated if
counter is a system counter. A Counter error is
generated if counter does not name a valid counter. If the resulting value
for the counter would be outside the range for an INT64, a
Value error is generated and the counter is not changed.
It should be noted that all the clients whose triggers are satisfied by this
change are unblocked, so this request cannot be used to implement mutual
exclusion.
SetCounter
counter: COUNTER
value: INT64
Errors: Counter,Access
This request sets the value of the given counter to value. The effect is
equivalent to executing the appropriate ChangeCounter request to change
the counter value to value. An Access error is generated if counter names a
system counter. A Counter error is generated if counter does not name a valid
counter.
CreateAlarm
id: ALARM
values-mask: CARD32
values-list: LISTofVALUE
left">Errors: IDChoice,Counter,Match,Value,Alloc
This request creates an alarm and assigns the identifier id to it. The
values-mask and values-list specify the attributes that are to be explicitly
initialized. The attributes for an Alarm and their defaults are:
Attribute
Type
Default
trigger
TRIGGER
counter
None
value-type
Absolute
value
0
test-type
PositiveComparison
delta
INT64
1
events
BOOL
TRUE
The trigger is initialized as described in the definition of TRIGGER, with an
error being generated if necessary.
If the counter is None , the state of the alarm is set
to Inactive , else it is set to Active.
Whenever the trigger becomes TRUE, either as a result of this request or as the
result of a SetCounter ,
ChangeCounter , DestroyCounter , or
ChangeAlarm request, an
AlarmNotify event is generated and the alarm is
updated. The alarm is updated by repeatedly adding delta to the value of the
trigger and reinitializing it until it becomes FALSE. If this update would
cause value to fall outside the range for an INT64, or if the counter
value is None , or if the delta is 0 and test-type
is PositiveComparison or
NegativeComparison , no change is made to value and
the alarm state is changed to Inactive before the
event is generated. No further events are generated by an
Inactive alarm until a ChangeAlarm
or DestroyAlarm request is executed.
If the test-type is PositiveComparison or
PositiveTransition and delta is less than zero, or
if the test-type is NegativeComparison or
NegativeTransition and delta is greater than zero,
a Match error is generated.
The events value enables or disables delivery of
AlarmNotify events
to the requesting client. The alarm keeps a separate event flag for
each client so that other clients may select to receive events from this
alarm.
An AlarmNotify event is always generated at some time
after the execution of a CreateAlarm request. This
will happen immediately if the trigger is TRUE, or it will happen later
when the trigger becomes TRUE or the Alarm is destroyed.
ChangeAlarm
id: ALARM
values-mask: CARD32
values-list: LISTofVALUE
Errors: Alarm,Counter,Value,Match
This request changes the parameters of an Alarm. All of the parameters
specified for the CreateAlarm request may be changed
using this request. The trigger is reinitialized and an
AlarmNotify event is generated if appropriate, as
explained in the description of the CreateAlarm request.
Changes to the events flag affect the event delivery to the requesting
client only and may be used by a client to select or deselect event delivery
from an alarm created by another client.
The order in which attributes are verified and altered is server-dependent.
If an error is generated, a subset of the attributes may have been altered.
DestroyAlarm
alarm: ALARM
Errors: Alarm
This request destroys an alarm. An alarm is automatically destroyed when the
creating client is closed down if the close-down mode is
Destroy . When an alarm is destroyed, an
AlarmNotify event is generated with a state value of
Destroyed .
QueryAlarm
alarm: ALARM
=>
trigger: TRIGGER
delta: INT64
events: ALARMEVENTMASK
state: ALARMSTATE
Errors: Alarm
This request retrieves the current parameters for an Alarm.
SetPriority
client-resource: XID
priority: INT32
Errors: Match
This request changes the scheduling priority of the client that created
client-resource. If client-resource is None , then
the priority for the client making the request is changed. A
Match error is generated if client-resource is not
None and does not name an existing resource in the
server. For any two priority values, A and B, A is higher priority if
and only if A is greater than B.
The priority of a client is set to 0 when the initial client connection is
made.
The effect of different client priorities depends on the particular
implementation of the extension, and in some cases it may have no effect at
all. However, the intention is that higher priority clients will have
their requests executed before those of lower priority clients.
For most animation applications, it is desirable that animation clients be
given priority over nonrealtime clients. This improves the smoothness of the
animation on a loaded server. Because a server is free to implement very strict
priorities, processing requests for the highest priority client to the
exclusion of all others, it is important that a client that may potentially
monopolize the whole server, such as an animation that produces continuous
output as fast as it can with no rate control, is run at low rather than high
priority.
GetPriority
client-resource: XID
=>
priority: INT32
Errors: Match
This request returns the scheduling priority of the client that created
client-resource. If client-resource is None , then the
priority for the client making the request is returned. A
Match error is generated if client-resource is
not None and does not name an existing resource in the
server.
CreateFence
drawable: DRAWABLE
id: FENCE
initially-triggered: BOOL
Errors: IDChoice ,Alloc
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.
TriggerFence
fence: FENCE
Errors: Fence
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 Fence error is generated if
fence does not name a valid fence.
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. AwaitFence should first
be issued if subsequent requests require the fence to be in the triggered
state.
ResetFence
fence: FENCE
Errors: Fence ,Match
This request immediately puts the given fence in the not triggered state.
A Match error is generated if the fence is not in the
triggered state. A Fence error is generated if fence
does not name a valid fence.
See the warnings above regarding TriggerFence 's delayed
effect. In particular, a TriggerFence request
immediately followed by a ResetFence request is likely
to result in a Match error. An
AwaitFence request should be issued between the two.
DestroyFence
fence: FENCE
Errors: Fence
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
DestroyAll . A Fence error is
generated if fence does not name a valid fence.
QueryFence
fence: FENCE
=>
triggered: BOOL
Errors: Fence
This request returns TRUE if the given fence is triggered, or FALSE if it
is not triggered. A Fence error is generated if
fence does not name a valid fence.
AwaitFence
fence-list: LISTofFENCE
Errors: Fence ,Alloc
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 Fence error
is generated if any member of fence-list does not name a valid fence.
Events
CounterNotify
counter: COUNTER
wait-value: INT64
counter-value: INT64
time: TIME
count: CARD16
destroyed: BOOL
CounterNotify events may be generated when a client
becomes unblocked after an Await request has been
processed. The wait-value is the value being waited for, and counter-value
is the actual value of the counter at the time the event was generated.
The destroyed flag is TRUE if this request was generated as the result of
the destruction of the counter and FALSE otherwise. The time is the server
time at which the event was generated.
When a client is unblocked, all the CounterNotify
events for the Await request are generated contiguously. If count is 0,
there are no more events to follow for this request. If count is n,
there are at least n more events to follow.
AlarmNotify
alarm: ALARM
counter-value: INT64
alarm-value: INT64
state: ALARMSTATE
time: TIME
An AlarmNotify event is generated when an alarm is
triggered. alarm-value is the test value of the trigger in the alarm when
it was triggered, counter-value is the value of the counter that triggered
the alarm, and time is the server time at which the event was generated.
The state is the new state of the alarm. If state is
Inactive , no more events will be generated by this
alarm until a ChangeAlarm request is executed, the alarm
is destroyed, or the counter for the alarm is destroyed.
Encoding
Please refer to the X11 Protocol Encoding document as this section uses
syntactic conventions established there and references types defined there.
The name of this extension is "SYNC".
Encoding New Types
The following new types are used by the extension.
ALARM: CARD32
ALARMSTATE:
0 Active
1 Inactive
2 Destroyed
COUNTER: CARD32
INT64: 64-bit signed integer
SYSTEMCOUNTER:
4 COUNTER counter
8 INT64 resolution
2 n length of name in bytes
n STRING8 name
p pad,p=pad(n+2)
TESTTYPE:
0 PositiveTransition
1 NegativeTransition
2 PositiveComparison
3 NegativeComparison
TRIGGER:
4 COUNTER counter
4 VALUETYPE wait-type
8 INT64 wait-value
4 TESTTYPE test-type VALUETYPE:
0 Absolute
1 Relative
WAITCONDITION:
20 TRIGGER trigger
8 INT64 event threshold
FENCE: CARD32
An INT64 is encoded in 8 bytes with the most significant 4 bytes
first followed by the least significant 4 bytes. Within these 4-byte
groups, the byte ordering determined during connection setup is used.
Encoding Errors
Counter
1 0 Error
1 Base + 0 code
2 CARD16 sequence number
4 CARD32 bad counter
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Alarm
1 0 Error
1 Base + 1 code
2 CARD16 sequence number
4 CARD32 bad alarm
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Fence
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
Encoding Requests
Initialize
1 CARD8 major opcode
1 0 minor opcode
2 2 request length
1 CARD8 major version
1 CARD8 minor version
2 unused
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
1 CARD8 major version
1 CARD8 minor version
2 unused
20 unused
ListSystemCounters
1 CARD8 major opcode
1 1 minor opcode
2 1 request length
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 INT32 list length
20 unused
4n list of SYSTEMCOUNTER system counters
CreateCounter
1 CARD8 major opcode
1 2 minor opcode
2 4 request length
4 COUNTER id
8 INT64 initial value
DestroyCounter
1 CARD8 major opcode
1 6 minor opcodeA previous version of this document gave an incorrect minor opcode A previous version of this document gave an incorrect minor opcode. A previous version of this document gave an incorrect minor opcode. A previous version of this document gave an incorrect minor opcode. CreateAlarm
4n LISTofVALUE values
encodings as for CreateAlarm
DestroyAlarm
1 CARD8 major opcode
1 11 minor opcodeA previous version of this document gave an incorrect minor opcode. A previous version of this document gave an incorrect minor opcode.
Encoding Events
CounterNotify
1 Base + 0 code
1 0 kind
2 CARD16 sequence number
4 COUNTER counter
8 INT64 wait value
8 INT64 counter value
4 TIME timestamp
2 CARD16 count
1 BOOL destroyed
1 unused
AlarmNotify
1 Base + 1 code
1 1 kind
2 CARD16 sequence number
4 ALARM alarm
8 INT64 counter value
8 INT64 alarm value
4 TIME timestamp
1 ALARMSTATE state
3 unused
xorgproto-2023.2/specs/xextproto/appendix.xml 0000644 0001750 0001750 00000004065 14443010026 016310 0000000 0000000
System Window Encodings
The AppGroupCreateAssoc request has the following possible variations:
AppGroupCreateAssoc (X11)
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
AppGroupCreateAssoc (Macintosh)
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
AppGroupCreateAssoc (Win32)
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
AppGroupCreateAssoc (Win16)
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
xorgproto-2023.2/specs/xextproto/lbx.xml 0000644 0001750 0001750 00000475522 14443010026 015277 0000000 0000000
%defs;
]>
Low Bandwidth X Extension
X Consortium Standard
Donna
Converse
Jim
Fulton
David
Lemke
Ralph
Mor
Keith
Packard
Ray
Tice
Dale
Tonogai
X Version 11, Release &fullrelvers;
Version 1.0
1996 X Consortium
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
sell copies of the Software,
and to permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions
of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 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.
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.
X Window System is a trademark of The OpenGroup.
Introduction
Low Bandwidth X (LBX) is a network-transparent protocol for running X Window
System applications over transport channels whose bandwidth and latency are
significantly worse than that used in local area networks. It combines a
variety of caching and reencoding techniques to reduce the volume of data that
must be sent over the wire. It can be used with existing clients by placing a
proxy between the clients and server, so that the low bandwidth/high latency
communication occurs between the proxy and server.
This extension was designed and implemented by Jim Fulton, David Lemke, Keith
Packard, and Dale Tonogai, all of Network Computing Devices (NCD). Chris Kent
Kantarjiev (Xerox PARC) participated in early design discussions. Ralph Mor (X
Consortium) designed and implemented additional sections. Donna Converse (X
Consortium) authored the protocol description and encoding from design notes
and the implementation. Ray Tice (X Consortium) resolved the open issues in the
design and specification. Bob Scheifler (X Consortium) helped out in many areas.
The extension name is "LBX".
Description
The design center for LBX is to use a proxy as an intermediary between the
client and server. The proxy reencodes and compresses requests, events, replies
and errors, as well as the resulting data stream. Additionally, the proxy can
cache information from the server to provide low-latency replies to clients.
This reply generation by the proxy is known as short-circuiting. A proxy can
handle multiple clients for a given server, but does not prevent clients from
connecting directly to the server. The design allows the proxy to multiplex
multiple clients into a single data stream to the server.
Much of LBX is implemented as an extension. The compression and reencoding
changes can be isolated to the transport and dispatch portions of the server,
while short-circuiting requires minor changes to the server’s colormap and
property code.
LBX employs several different compression and short-circuiting methods. Use of
these methods is negotiable, and in some cases, the algorithm used by a given
method is negotiable as well. LBX also provides for negotiation of extensions
to LBX.
Data Flow
The LBX data stream goes through a number of layers:
Client requests
Read by LBX and potential byte-swapping
Request-specific compression
Potential byte swapping
Multiplexing of client request streams
Delta replacement
Stream compression
Transport
Stream decompression
Delta substitution
Demultiplexing of client request streams
Potential byte swapping
Reencoding
Request processing
The reverse process occurs with X server replies, events, and errors.
Tags
Tags are used to support caching of large data items that are expected to be
queried multiple times. Such things as the keyboard map and font metrics are
often requested by multiple clients. Rather than send the data each time, the
first time the data is sent it includes a tag. The proxy saves this data, so
that subsequent requests can send only the tag to refer to that same data. The
different types of tags are used for connection information, keyboard maps,
modifier maps, fonts information and properties.
Tag usage is negotiated as a boolean in the
LbxStartProxy
message. The proxy controls how many tags are stored in the proxy. The server
may wish to observe the proxy’s InvalidateTag behavior to limit how many tags
are cached at any one time. Tagged data is not shared across types of tags, but
the number space used for the tag ids is. The tag ids are generated by the
server.
The X server keeps track of what tags are known to the proxy. The proxy can
invalidate a tag if no tag bearing replies of that type are pending. The proxy
sends an
LbxInvalidateTag
message to release the tagged data. The proxy must not invalidate connection
tags unless instructed to do so by the server.
If the server wishes to discard tagged data, it must either have received an
LbxInvalidateTag
request from the proxy or send an
LbxInvalidateTag
event to the proxy for that tag.
Tag Substitution in Requests
Many substitution requests have a tag field, followed by fields marked
optional. For these requests, if the optional fields are present, the
data in them is stored in the indicated tag, unless the tag is 0. If
the optional fields are absent, the tag field indicates the tag that
contains the data for the "optional" fields.
Property Tags
Property data makes special use of tags. A common use of properties is for
inter-client communication. If both clients use the proxy, it is wasteful to
send the data to the server and then back, when the server may never need it.
LbxChangeProperty
request does the same work as the core
ChangeProperty
request, but it does not send the data. The reply to this request contains a
tag id corresponding to the data. If the property information is used locally,
the server responds to
LbxGetProperty
with the tag, and the property data need never be sent to the server. If the
server does require the data, it can issue an
LbxQueryTag
message. The proxy can also send the data on at any time if it judges it
appropriate (i.e., when the wire goes idle). Since the proxy owns the property
data, it must not invalidate the tag before sending the data back to the server
via an
LbxTagData
request.
Short-circuiting
Short-circuiting is used to handle constant data. This includes atoms, color
name/RGB mappings, and
AllocColor
calls. Atoms and color name/RGB mappings stay constant for the life of the
server.
AllocColor
replies are constant for each colormap. Short-circuiting replaces round-trip
requests with one-way requests, and can sometimes use one in place of many.
Atoms are used heavily for ICCCM communication. Once the proxy knows the string
to atom mapping, it has no need to send subsequent requests for this atom to
the server.
Colorname/RGB mappings are constant, so once the proxy sees the response from
LookupColor
, it need not forward any subsequent requests.
Clients often use the same color cells, so once a read-only color allocation
has occurred, the proxy knows what RGB values should be returned to the client.
The proxy doesn't need to forward any
AllocColor
requests it can resolve, but it must tell the server to modify the color
cell's reference count.
LbxIncrementPixel
is used to support this.
For all three classes of short-circuiting, the proxy must still tell the server
a request has occurred, so that the request sequence numbers stay in sync. This
is done with
LbxModifySequence
.
Sequence numbers cause the major complication with short-circuiting. X
guarantees that any replies, events or errors generated by a previous request
will be sent before those of a later request. This means that any requests that
can be handled by the proxy must have their reply sent after any previous
events or errors.
If a proxy’s applications do not require strict adherence to the X protocol
ordering of errors or events, a proxy might provide further optimization by
avoiding the overhead of maintaining this ordering, however, the resulting
protocol is not strictly X11 compliant.
Graphics Re-encoding
The LBX proxy attempts to reencode PolyPoint ,
PolyLine , PolySegment ,
PolyRectangle , PolyArc ,
FillPoly , PolyFillRectangle ,
PolyFillArc , CopyArea ,
CopyPlane , PolyText8 ,
PolyText16 , ImageText8 ,
and ImageText16 requests. If the request can be
reencoded, it may be replaced by an equivalent LBX form of the request.
The requests are reencoded by attempting to reduce 2-byte coordinate,
length, width and angle fields to 1 byte. Where applicable, the
coordinate mode is also converted to Previous
to improve the compressibility of the resulting data. In image requests,
the image data may also be compressed.
Motion events
To prevent clogging the wire with MotionNotify
events, the server and proxy work together to control the number
of events on the wire. This is done with the
LbxAllowMotion
request. The request adds an amount to an allowed motion count in
the server, which is kept on a per-proxy basis. Every motion notify
event sent to the proxy decrements the allowed motion counter. If
the allowed motion count is less than or equal to zero, motion
events not required by the X protocol definition are not sent to the
proxy. The allowed motion counter has a minimum value of -2^31.
Event Squishing
In the core protocol, all events are padded as needed to be 32 bytes long. The
LBX extension reduces traffic by removing padding at the end of events, and
implying the event length from its type. This is known as squishing.
Master Client
When the initial X connection between the proxy and the server is converted to
LBX mode, the proxy itself becomes the master client. New client requests and
some tag messages are sent in the context of the master client.
Multiplexing of Clients
The LBX proxy multiplexes the data streams of all its clients into one stream,
and then splits them apart again when they are received. The
LbxSwitch
message is used to tell each end which client is using the wire at the time.
The server should process delta requests in the order that they appear on the
LBX connection. If the server does not maintain the interclient request order
for requests sent by the proxy, it must still obey the semantics implied by the
interclient request order so that the delta cache functions correctly.
The server can affect the multiplexing of clients by the proxy using the
LbxListenToOne
and
LbxListenToAll
messages. This is useful during grabs, since the master connection can not be
blocked during grabs like other clients. The proxy is responsible for tracking
server grabs issued by its clients so that the proxy can multiplex the client
streams in an order executable by the server.
Replies must be ordered in the multiplexed data stream from the server to the
proxy such that the reply carrying tagged data precedes replies that refer to
that tagged data.
Swapping
Swapping is handled as with any X extension, with one caveat. Since a proxy can
be supporting clients with different byte orders, and they all share the same
wire, the length fields of all messages between the server and proxy are
expressed in the proxy byte order. This prevents any problems with length
computation that may occur when clients are switched.
Delta cache
LBX takes advantage of the fact that an X message may be very similar to one
that has been previously sent. For example, a
KeyPress
event may differ from a previous
KeyPress
event in just a few bytes. By sending just the bytes that differ (or
"deltas"), the number of bytes sent over the wire can be substantially reduced.
Delta compaction is used on requests being sent by the proxy as well as on
replies and events being sent by the server.
The server and the proxy each keep per-proxy request and response caches. The
response cache contains events, errors and replies. All messages are saved in
the appropriate delta cache if they are of an appropriate type and more than 8
bytes long but fit within the delta cache. The number of entries in the delta
cache and the maximum saved message size are negotiated in the
LbxStartProxy
request.
The LBX requests that are never stored in the request delta cache are the
LbxQueryVersion
,
LbxStartProxy
,
LbxSwitch
,
LbxNewClient
,
LbxAllowMotion
,
LbxDelta
,
LbxQueryExtension
,
LbxPutImage
,
LbxGetImage
,
LbxBeginLargeRequest
,
LbxLargeRequestData
,
LbxEndLargeRequest
and
LbxInternAtoms
requests. The responses that are never stored in the response cache are
LbxSwitchEvent
and
LbxDeltaResponse
. The message carried by a
delta
message is also cached, if it meets the other requirements. Messages after the
LbxStartProxy
request are cached starting at index 0, and incrementing the index, modulo the
number of entries, thereafter. The request and response caches are
independently indexed.
If the current message is cachable and the same length as a message in the
corresponding delta cache, a delta message may be substituted in place of the
original message in the protocol stream.
Stream Compression
Before being passed down to the transport layer messages can be passed through
a general purpose data compressor. The choice of compression algorithm is
negotiated with See LbxStartProxy . The proxy
and server are not required to support any specific stream compressor. As an
example, however, the X Consortium implementation of a ZLIB based compressor is
described below.
The XC-ZLIB compressor is presented with a simple byte stream - the X and LBX
message boundaries are not apparent. The data is broken up into fixed sized
blocks. Each block is compressed using zlib 1.0 (by Gailly & Adler), then a
two byte header is prepended, and then the entire packet is transmitted. The
header has the following information:
out[0] = (length & 0xfff) >> 8 | ((compflag) ? 0x80 : 0);
out[1] = length & 0xff;
Authentication Protocols
The current version of LBX does not support multipass authentication protocols
for clients of the proxy. These authentication protocols return an
Authenticate
message in response to a connection setup request, and require additional
authentication data from the client after the
LbxNewClient
request, and before the reply to
LbxNewClient
. One example of such a protocol is XC-QUERY-SECURITY-1.
C Library Interfaces
The C Library routines for LBX are in the Xext library. The prototypes are
located in a file named "XLbx.h".
Application Library Interfaces
In a proxy environment, applications do not need to call these routines to take
advantage of LBX. Clients can, however, obtain information about the LBX
extension to the server using this interface. Use of this routine may be
altered when connected through a proxy, as described in See C Library Interfaces .
XLbxQueryVersion
To determine the version of LBX supported by the X server, call
XLbxQueryVersion
.
Bool XLbxQueryVersion
Display * display
int * major_version_return
int * minor_version_return
display
Specifies the connection to the X server.
major_version_return
Returns the extension major version number.
minor_version_return
Returns the extension minor version number.
The
XLbxQueryVersion
function determines if the LBX extension is present. If the extension is not
present,
XLbxQueryVersion
returns
False
; otherwise, it returns
True
. If the extension is present,
XLbxQueryVersion
returns the major and minor version numbers of the extension as supported by
the X server.
Proxy Library Interfaces
The following interfaces are intended for use by the proxy.
XLbxQueryExtension
To determine the dynamically assigned codes for the extension, use the Xlib
function
XQueryExtension
or the LBX function
XLbxQueryExtension
.
Bool XLbxQueryExtension
Display * display
int * major_opcode_return
int * first_event_return
int * first_error_return
display
Specifies the connection to the X server.
major_opcode_return
Returns the major opcode.
first_event_return
Returns the first event code.
first_error_return
Returns the first error code.
The
XLbxQueryExtension
function determines if the LBX extension is present. If the extension is not
present,
XLbxQueryExtension
returns
False
; otherwise, it returns
True
. If the extension is present,
XLbxQueryExtension
returns the major opcode for the extension to major_opcode_return, the base
event type code to first_event_return, and the base error code to
first_error_return; otherwise, the return values are undefined.
XLbxGetEventBase
To determine the base event type code, use the Xlib function
XQueryExtension
or the LBX function
XLbxGetEventBase .
int XLbxGetEventBase
Display * display
display
Specifies the connection to the X server.
The XLbxGetEventBase
function returns the base event type code if the extension is
present; otherwise, it returns -1.
Protocol
Syntactic Conventions and Common Types
Please refer to the X Window System Protocol specification,
as this document uses the syntactic conventions established
there and references types defined there.
The following additional types are defined by this extension:
DIFFITEM
1 CARD8 offset
1 CARD8 diff
LBXANGLE: CARD8 or 2 BYTE
where (in order of precedence):
(0 <= in <= A(95)) && !(in % A(5)) out = 0x5a + (in /
A(5))
A(105) <= in <= A(360) && !(in % A(15)) out = 0x67 +
(in / A(15))
-A(100) <= in <= -A(5) && !(in % A(5)) out = 0xa6 +
(in / A(5))
-A(360) < in <= -A(105) && !(in % A(15)) out = 0x98 +
(in / A(15))
-A(360) < in <= A(360) out[0] = in >> 8; out[1] = in
LBXARC:
[x, y: LBXINT16,
width, height: LBXCARD16,
angle1, angle2: LBXANGLE]
Within a list of arcs, after the first arc, x and y are
relative to the corresponding fields of the prior arc.
LBXCARD16: CARD8 or 2 BYTE
where:
0x0000 <= in < 0x00F0 CARD8
0x00F0 <= in < 0x10F0 out[0] = 0xF0 | ((in - 0xF0) >>
8)
out[1] = in - 0xF0
LBXGCANDDRAWENT
[ gc-cache-index, drawable-cache-index: CARD4 ]
LBXGCANDDRAWUPDATE
drawable: DRAWABLE /* present only if
drawable-cache-index
== 0 */
gc: GC] /* present only if gc-cache-index == 0 */
LBXGCANDDRAWABLE
cache-entries: LBXGCANDDRAWENT
updates: LBXGCANDDRAWUPDATE
LBXINT16 : INT8 or 2 BYTE
where:
0xF790 <= in < 0xFF90 out[0] = 0x80 | (((in + 0x70) >>
8) & 0x0F)
out[1] = in + 0x70
0xFF90 <= in < 0x0080 CARD8
0x0080 <= in < 0x0880 out[0] = 0x80 | (((in - 0x80) >>
8) & 0x0F)
out[1] = in - 0x80
LBXPINT16 : CARD8 or 2 BYTE /* for
usually positive numbers */
where:
0xFE00 <= in < 0x0000 out[0] = 0xF0 | (((in + 0x1000)
>> 8) & 0x0F)
out[1] = in + 0x1000
0x0000 <= in < 0x00F0 CARD8
0x00F0 <= in < 0x0EF0 out[0] = 0xF0 | ((in - 0xF0) >>8)
out[1] = in - 0xF0
LBXPOINT : [x, y: LBXINT16]
Within a list of points, after the first rectangle, x and y are
relative to the corresponding fields of the prior point.
LBXRECTANGLE :
[x, y: LBXINT16,
width, height: LBXCARD16]
Within a list of rectangles, after the first rectangle, x and
y are relative to the corresponding fields of the prior rectangle.
MASK: CARD8
Errors
As with the X11 protocol, when a request terminates with an error,
the request has no side effects (that is, there is no partial execution).
There is one error,
LbxClient
. This error indicates that the client field of an LBX request was invalid, or
that the proxy’s connection was in an invalid state for a start or stop proxy
request.
Requests
There is one request that is expected to be used only by the client:
LbxQueryVersion
There is one request that is expected to be used by the client or the proxy:
LbxQueryExtension
.
The following requests are expected to be used only by the proxy, and are
instigated by the proxy:
LbxStartProxy
,
LbxStopProxy
,
LbxNewClient
,
LbxSwitch
,
LbxCloseClient
,
LbxModifySequence
,
LbxAllowMotion
,
LbxInvalidateTag
,
LbxTagData
and
LbxQueryTag
.
All other requests are sent by the proxy to the LBX server and are instigated
by reception of an X request from the client. They replace the X request.
Requests Initiated by the Proxy or by the Client
LbxQueryVersion
=>;
majorVersion: CARD16
minorVersion: CARD16
This request returns the major and minor version numbers of the LBX protocol.
The encoding of this request is on See
LbxQueryVersion .
Requests Initiated or Substituted by the Proxy
LbxQueryExtension
nbytes
: CARD32
name
: STRING8
=>
num-requests: CARD8
present: BOOL
major-opcode: CARD8
first-event: CARD8
first-error: CARD8
reply-mask: LISTofMASK /* optional */
event-mask:LISTofMASK /* optional */
Errors:
Alloc
This request is identical to the
QueryExtension
request, with an additional field, and two optional additional fields. When
the client issues an
QueryExtension
request, the proxy will substitute an
LbxQueryExtension
request.
This request determines if the named extension is present. If so, the major
opcode for the extension is returned, if it has one. Otherwise, zero is
returned. Any minor opcode and the request formats are specific to the
extension. If the extension involves additional event types, the base event
type code is returned. Otherwise, zero is returned. The format of events is
specific to the extension. If the extension involves additional error codes,
the base error code is returned. Otherwise, zero is returned. The format of
additional data in the errors is specific to the extension.
In addition, the number of requests defined by the named extension is returned.
If the number of requests is nonzero, and if the information is available,
reply-mask and event-mask will be included in the reply. The reply-mask
represents a bit-wise one-to-one correspondence with the extension requests.
The least significant bit corresponds to the first request, and the next bit
corresponds to the next request, and so on. Each element in the list contains
eight meaningful bits, except for the last element, which contains eight or
fewer meaningful bits. Unused bits are not guaranteed to be zero. The bit
corresponding to a request is set if the request could generate a reply,
otherwise it is zero. In the same way, the event-mask represents a bit-wise
one-to-one correspondence with the extension requests. A bit is set if the
corresponding request could result in the generation of one or more extension
or X11 events. If reply-mask is present in the reply, event-mask will also be
present.
The encoding of this request is on See
LbxQueryExtension .
Control Requests Initiated by the Proxy
LbxStartProxy
options
: LISTofOPTION
=>
choices: LISTofCHOICE
Errors:
LbxClient
,
Alloc
where:
OPTION [optcode: CARD8,
len: OPTLEN,
option: (See See StartProxy Options ) ]
CHOICE [optcode: CARD8,
len: OPTLEN,
choice: (See See StartProxy Options ) ]
StartProxy Options
optcode
option
choice
default
delta-proxy
DELTAOPT
DELTACHOICE
entries=16, maxlen=64
delta-server
DELTAOPT
DELTACHOICE
entries=16, maxlen=64
stream-comp
LISTofNAMEDOPT
INDEXEDCHOICE
No Compression
bitmap-comp
LISTofSTRING8
LISTofINDEXEDOPT
No Compression
pixmap-comp
LISTofPIXMAPMETHOD
LISTofPIXMAPCHOICE
No Compression
use-squish
BOOL
BOOL
True
use-tags
BOOL
BOOL
True
colormap
LISTofSTRING8
INDEXEDCHOICE
No Colormap Grabbing
extension
NAMEDOPT
INDEXEDCHOICE
Extension Disabled
DELTAOPT [minN, maxN, prefN: CARD8
minMaxMsgLen, maxMaxMsgLen, prefMaxMsgLen:
CARD8]
DELTACHOICE [entries, maxlen:
CARD8]
INDEXEDCHOICE [index: CARD8,
data: LISTofBYTE]
INDEXEDOPT [index, opcode: CARD8]
NAMEDOPT [name: STRING8,
detail: LISTofBYTE]
OPTLEN 1 or 3 CARD8
where:
(0 < in <= 0xFF): out =
in
(0 <= in<= 0xFFFF): out[0] =
0; out[1] = in >> 8; out[2] = in& 0xFF;
PIXMAPMETHOD [name: STRING8,
format-mask: BITMASK,
depths: LISTofCARD8]
PIXMAPCHOICE [index, opcode: CARD8,
format-mask: BITMASK,
depths: LISTofCARD8]
This request negotiates LBX protocol options, and switches the proxy-server
connection from X11 protocol to LBX protocol.
The proxy gives the preferred protocol options in the request. The server
chooses from the given options and informs the proxy which to use. The options
may be listed in any order, and the proxy may choose which options to
negotiate. If an option is not successfully negotiated, the default is used.
The server delta cache and proxy delta caches can be configured for number of
entries, and the length of entries. (See See Delta
cache for details.) The delta caches are configured using the
delta-server
and
delta-proxy
options. To configure a cache, the proxy sends the minimum, maximum and
preferred values for the number of cache entries, (
minN, maxN, prefN
), and the length of the cache entries, (
minMaxMsgLen, maxMaxMsgLen, prefMaxMsgLen
). The server’s reply fields,
entries
and
maxlen
, contains the values to use. These values must be within the ranges specified
by the proxy. The server may also specify an
entries
value of 0 to disable delta caching. The cache entry lengths are specified in
units of 4 bytes.
The stream compression algorithm is selected using the
stream-comp
option. (Stream compression is described in See
Stream Compression .) Each algorithm has a name that follows the naming
conventions in See Algorithm Naming . To
negotiate using the stream-comp option, the proxy lists its available
compressors. For each candidate algorithm, the proxy sends the name in the
name
field, and uses the
detail
field to send any additional data specific to each compression algorithm. The
reply contains a 0-based index into the list of algorithms to indicate which
algorithm to use, followed by data specific to that algorithm.
Bitmap compression is negotiated using the
bitmap-comp
option. The proxy sends a list of names of available algorithms, and the
server reply lists the algorithms to use. For each bitmap algorithm in the
reply, a 0-based index into the list of algorithms indicates the algorithm, and
the
opcode
field gives the value for use in requests. The algorithm names follow the
conventions in See Algorithm Naming .
Pixmap compression is negotiated using the
pixmap-comp
option. The proxy sends a list of available algorithms. For each algorithm,
the list includes, the name, a bitmask of supported formats, and a list of
depths that the format supports. The server reply lists the algorithms to use.
For each pixmap algorithm in the reply, the reply contains a 0-based index into
the list of proxy algorithms, the opcode to use in requests when referring to
this algorithm, a mask of valid formats, and a list of valid depths. Algorithm
names follow the conventions in See Algorithm
Naming .
Squishing is negotiated using the use-squish option. If the proxy desires
squishing, it sends a true value. The reply from the server indicates whether
to do squishing, and will indicate squishing only if
use-squish
is set to true in the request.
Tag caching, described in See Tags , is
negotiated using the use-tag option. If the proxy desires tag caching, it sends
a true value. The reply from the server indicates whether to do tag caching,
and will demand caching only if
use-tag
is set to true in the request.
The colormap option is used to negotiate what color matching algorithm will be
used by the proxy when the proxy uses the
LbxAllocColor
request to allocate pixels in a grabbed colormap. To negotiate using the
colormap option, the proxy lists the names of available colormap algorithms.
The choice in the reply contains a 0-based index into the list of algorithms to
indicate which algorithm to use, followed by data specific to that algorithm.
If no colormap algorithm is successfully negotiated, then the
LbxAllocColor
,
LbxGrabCmap
, and
LbxReleaseCmap
requests will not be used.
The extension option is used to control extensions to LBX. These extensions
may, for example, enable other types of compression. To negotiate an extension,
the name of the extension is sent, followed by any data specific to that
extension. The extension name follows the conventions in See Algorithm Naming . The extension option may
occur multiple times in the start proxy message, since multiple extensions can
be negotiated. The reply to an extension option contains the zero-based index
of the extension option, as counted in the
LbxStartProxy
message. This index is followed by extension-specific information. The server
does not respond to extensions it does not recognize.
An
LbxClient
error is returned when a client which is already communicating through an LBX
proxy to the X server sends a
LbxStartProxy
request.
The encoding for this request is on See
LbxStartProxy .
LbxStopProxy
Errors:
LbxClient
This request terminates the connection between the proxy and X server, and
terminates any clients connected through the proxy.
The encoding for this request is on See
LbxStopProxy .
An
LbxClient
error is returned if the requesting client is not an LBX proxy.
LbxNewClient
byte-order
: CARD8
client-id
: CARD32
protocol-major-version
: CARD16
protocol-minor-version:
CARD16
authorization-protocol-name
: STRING8
authorization-protocol-data
: STRING8
=>
Core X reply (if connection is rejected)
OR
success: BOOL
change-type: {NoDeltas, NormalClientDeltas,
AppGroupDeltas}
protocol-major-version: CARD16
protocol-minor-version: CARD16
tag-id: CARD32
length: CARD16
connection-data: CONINFO or CONDIF or
CONDIFROOT
where:
CONINFO: (the "additional data"
portion of the core connection reply for successes)
CONDIF: [resource-id-base: CARD32,
root-input-masks: LISTofSETofEVENT]
CONDIFROOT: [resource-id-base:
CARD32,
root: WINDOW
root-visual: VISUALID
default-colormap: COLORMAP
white-pixel, black-pixel: CARD32
root-input-masks: LISTofSETofEVENT]
Errors: LbxClient, Alloc
This request, which is sent by the proxy over the control connection, creates a
new virtual connection to the server.
Much of the information in the
LbxNewClient
request and reply is identical to the connection setup and reply information
in the core X protocol.
For the
LbxNewClient
request, the field unique to LBX is client-id. For the
LbxNewClient
reply,
tag-id
and
change-type
are fields unique to LBX, and the contents of connection-data may be different
in LBX from the core X protocol (see below).
The proxy assigns each virtual connection a unique identifier using the
client-id
field in the
LbxNewClient
request. This client-id is used in the LBX protocol to specify the current
client (see the
LbxSwitch
request and the
LbxSwitchEvent
). client-id 0 is reserved for the proxy control connection. An
LbxClient
error will result if the
LbxNewClient
request contains a client-id of 0 or an already in use client-id.
If the server rejects this new virtual connection, the server sends a core X
connection failure reply to the proxy. The current version of LBX does not
support the return of an
Authenticate
reply.
If the
change-type
field is set to
NoDeltas
, then
connection-data
is sent using the CONINFO structure, which is identical to the additional data
of the core connection reply. If the
tag-id
is non-zero, then the connection-data is stored by the proxy using this tag
value. Tagged connection data must be stored by the proxy, and can not be
invalidated by the proxy until an
LbxInvalidateTag
event is received for that tag.
When the
change-type
field is not set to
NoDeltas
, then connection data is sent as changes against connection information
previously sent to the proxy. The
tag-id
field, if non-zero, has the tag of the previously sent data to apply the
changes to. A zero tag-id indicates that the changes are with respect to the
connection information sent when the proxy connected to the server.
If the
change-type
field is set to
NormalClientDeltas
, then
connection-data
is sent using the CONDIF structure. The values in the CONDIF structure are
substituted for the identically named fields of the connection information for
the new connection.
If the
change-type
field is set to
AppGroupDeltas
, then
connection-data
is sent using the CONDIFROOT structure. The
root
,
root-visual
, and
default-colormap
fields, when nonzero, are substituted for the corresponding fields in the
reference connection information. The
white-pixel
and
black-pixel
fields are substituted only when the
default-colormap
field of the reply is non-zero. When
default-colormap
field of the reply is zero, so are
white-pixel
and
black-pixel
. The first entry in the
root-input-masks
field is the current-input-mask for the default root window. The remaining
entries in
root-input-masks
are input masks for non-video screens, as defined by the X Print Extension.
The number of non-video screens is one less than the number of entries in
root-input-masks
. These screens are at the end of screen list in the reference connection
information.
The encoding for this request is on See The
description of this request is on page 13. .
LbxCloseClient
client
: CARD32
Errors:
LbxClient
This requests the server to close down the connection represented by the
specified proxy’s client identifier. If the specified client wasn’t
previously registered with the server by a
LbxNewClient
request, the server will send the
LbxClient
error.
The encoding for this request is on See The
description of this request is on page 12. .
LbxSwitch
client
: CARD32
Errors:
LbxClient
This request causes the X server to treat subsequent requests as being from a
connection to the X server represented by the specified client identifier.
If the client making the request is not the proxy, or if the client identifier
sent in the request was not previously sent in a
LbxNewClient
request, an
LbxClient
error is returned.
The encoding for this request is on See
LbxSwitch .
LbxSync
=>
The sync request causes the server to send a reply when all requests before the
sync request have been processed.
The encoding for this client is on See
LbxSync .
LbxModifySequence
adjust
: CARD32
Errors: None
This request advances the sequence number of the virtual client connection by
the specified amount. The proxy sends the
LbxModifySequence
request to the server when it replies to a client request without forwarding
the client request on to the X server.
The encoding for this client is on See The
description of this request is on page 13. .
LbxAllowMotion
num
: CARD32
Errors: None
This request controls the delivery of optional motion notify events, as
described in See Motion events . The num
field specifies an increase in the allowed number of motion notify events sent.
The encoding for this request is on See The
description of this request is on page 14. .
LbxInvalidateTag
tag
: CARD32
The LBX proxy sends this notification to the X server when it refuses to store
tagged data, or when it releases tagged data which was previously stored and
which was not invalidated by a notification from the X server.
The encoding for this request is on See
LbxInvalidateTag .
LbxTagData
tag
: CARD32
real-length
: CARD32
data
: LISTofBYTE
This request specifies the data associated with a previously assigned tag. It
is sent in two circumstances: in response to receiving a
SendTagDataEvent
, and spontaneously, when the proxy must rely on the server to store data which
was not previously received from the server. The data is carried in the byte
order and structure as would have originally been sent in the core protocol
request.
The encoding for this request is on See
LbxTagData .
LbxGrabCmap
cmap
: Colormap
=>
smart-grab
: BOOL
large-pixel:
BOOL /* optional */
auto-release:
BOOL /* optional */
three-channels
: BOOL /* optional */
bits-per-rgb:
CARD4 /* optional */
cells
: LISTofCHAN /* optional */
where:
CHAN: LISTofLBXPIXEL
LBXPIXEL: PIXELPRIVATE or PIXELPRIVATERANGE
or
PIXELALLOC or PIXELALLOCRANGE
PIXEL: CARD8 or CARD16
PIXELPRIVATE: [ pixel: PIXEL ]
PIXELPRIVATERANGE: [ first-pixel,
last-pixel: PIXEL]
PIXELALLOC: [ pixel: PIXEL,
color: COLORSINGLE or COLORTRIPLE]
PIXELALLOCRANGE: [ first-pixel,
last-pixel: PIXEL,
colors: LISTofCOLORSINGLE or
LISTofCOLORTRIPLE]
COLORSINGLE: [ value: CARD8 or CARD16
]
COLORTRIPLE: [ r, g, b:
COLORSINGLE]
Errors:
Colormap
This request asks the server for control of allocating new colormap cells in
the specified colormap. The server grants control by replying to this request.
If no changes have occurred since the last time this proxy grabbed this
colormap, then the
smart-grab
field of the reply is set to true, and the optional fields are not sent.
Otherwise, the current contents of the colormap are placed in the reply, as
described later in this section.
Once the proxy has received the reply, it can use the
LbxAllocColor
request to allocate new colormap cells without the performance penalty of
round trips. The proxy is still permitted to use the normal colormap and
LbxIncrementPixel
requests while the colormap is grabbed. The grab is valid across all virtual
connections of the proxy.
The
LbxGrabCmap
request is limited to colormaps for the visual types negotiated as part of the
colormap algorithm negotiation in the start proxy request at connection setup.
The server and other proxies may not allocate new colormap cells in the
colormap while the colormap is grabbed by this proxy. If the server or another
proxy needs to allocate new colormap cells, the server sends a Lbx
ReleaseCmap
event to the proxy holding the grab, which then issues an
LbxReleaseCmap
request.
The server and other proxies may free colormap cells in a colormap grabbed by a
proxy. The server will send an
LbxFreeCells
event to the proxy that currently has the colormap grabbed when the cell
reference count reaches 0.
If the colormap is a of a static visual type, such as
StaticGray
,
StaticColor
,
GrayScale
, or
TrueColor
, then the proxy’s grab is immediately released by the server, and the proxy
must use
LbxIncrementPixel
requests in place of
LbxAllocColor
requests for this colormap.
If the cmap field does not refer to a valid colormap or the colormap is already
grabbed by this proxy then a
Colormap
error is generated.
The reply describes the contents of the colormap via several arguments and a
descriptive list containing one or three channels, with each channel describing
allocations in the colormap.
The
large-pixel
argument, if True, specifies that PIXEL indices will be listed as CARD16
quantities instead of CARD8. The
auto-release
field, if True, indicates that this colormap is of a static visual type and
the proxy’s grab is immediately released by the server.
If
three-channels
is False, a single channel is enclosed and color values are described using
COLORTRIPLE, which has fields for red, green and blue. A single channel is used
when the visual type is not
DirectColor
or
TrueColor
.
If
three-channels
is True, separate red, green and blue channel lists are enclosed, for
describing a
DirectColor
or
TrueColor
colormap. Color values for entries in each channel are sent using COLORSINGLE
and the corresponding PIXEL value refers to the RGB subfield of the current
channel, as defined by the corresponding red-mask, green-mask and blue-mask of
the visual.
The
bits-per-rgb
value is one less than the bits-per-rgb-value field of the visual that the
colormap belongs to. If the value is 7 or less, then COLORSINGLE values in the
descriptive list are sent using CARD8 fields. Otherwise these values are sent
using CARD16 fields.
The list describing current colormap allocations contains entries of the
following types:
An LBXPIXELPRIVATE entry indicates that the pixel in the
pixel
field is unavailable for allocation.
An LBXPIXELPRIVATERANGE entry indicates that a contiguous range of pixels are
unavailable for allocation. The range is
first-pixel
to
last-pixel
, and includes
last-pixel
.
An LBXPIXELALLOC entry indicates that the pixel in the
pixel
field is allocated as a read-only pixel. The
color
field carries the color information of the pixel.
An LBXPIXELALLOCRANGE entry indicates that a contiguous range of pixels are
allocated as read-only. The range starts
first-pixel
to
last-pixel
, and includes
last-pixel
. These fields are followed by a list of COLORSINGLE or COLORTRIPLE, depending
on the value of
three-channels
.
A NEXTCHANNEL entry indicates that the next channel of the colormap will be
described.
A LISTEND entry indicates the end of the colormap description.
All pixels not described in the reply are unallocated.
The encoding for this request is on See
LbxGrabCmap .
LbxReleaseCmap
cmap
: Colormap
This request releases the specified grabbed colormap. If the
cmap
field does not refer to a colormap, a
BadColormap
error is produced.
The proxy must remember the state of the colormap when the
LbxReleaseCmap
request is issued if this proxy may at some future time issue another
LbxGrabCmap
request on this colormap before the state of the colormap changes.
The encoding for this request is on See
LbxReleaseCmap .
LbxInternAtoms
count
: CARD16
names: LISTofSTRING8
=>
atoms
: LISTofATOM
Errors:
Alloc
This request allows the proxy to intern a group of atoms in a single round
trip. The server will create any atoms that do not exist.
The encoding for this request is on See
LbxInternAtoms .
Substitution Requests
LbxAllocColor
cmap
: Colormap
pixel
: CARD32
red
,
green
,
blue
: CARD16
This request is sent by a proxy that has given colormap grabbed to allocate a
new read-only cell in the colormap. The proxy may substitute this request for
the core
AllocColor
and
AllocNamedColor
requests.
The
pixel
field identifies the colormap cell to allocate. The
red
,
green
, and
blue
fields are the hardware specific color values of the corresponding fields of
the core
AllocColor
request. The mapping to hardware specific colormap values by the proxy is
performed using the color algorithm negotiated by
LbxStartProxy
.
For colormaps of static visual types, the
LbxIncrementPixel
request is used instead of LBX
AllocColor
.
If the
cmap
field does not identify a grabbed colormap then a
BadAccess
error is produced. If the
pixel
field refers to a read-write entry, or the pixel field refers to a pixel
outside of the range of this colormap, a
BadAlloc
error is produced.
The encoding for this request is on See
LbxAllocColor .
LbxIncrementPixel
cmap
: COLORMAP
pixel
: CARD32
Errors: None
This request replaces the
AllocColor
request for read-only pixels currently allocated for the current client. If
the visual type of the colormap is of a static type, this request may be used
on currently unallocated pixels. The colormap is not required to be grabbed to
use this request.
The encoding for this request is on See The
description of this request is on page 14. .
LbxDelta
count
: CARD8
cache-index
: CARD8
diffs
: LISTofDIFFITEM
This request contains a minimal amount of information relative to a similar
prior request. The information is in the form of a difference comparison to a
prior request. The prior request is specified by an index to a cache,
independently maintained by both the proxy and the server.
The encoding for this request is on See The
description of this request is on page 18. .
LbxGetModifierMapping
=>
keyspermod
: CARD8
tag
: CARD32
keycodes
: LISTofKEYCODE /* optional */
This request is identical to the core
GetModifierMapping
request, with the addition of a tag being returned in the reply. See See Tag Substitution in Requests for a description
of the
tag
field and optional fields.
The encoding for this request is on See
LbxGetModifierMapping .
LbxGetKeyboardMapping
firstKeyCode
: KEYCODE
count
: CARD8
=>
keysperkeycode
: CARD8
tag
: CARD32
keysyms
: LISTofKEYSYM /* optional */
Errors:
Value
This request is identical to the X
GetKeyboardMapping
protocol request, with the addition that a tag is returned in the reply. See
See Tag Substitution in Requests for a
description of the
tag
field and optional fields.
The encoding for this request is on See
LbxGetKeyboardMapping .
LbxGetWinAttrAndGeom
window
: WINDOW
=>
visual: VISUALID
class: {InputOutput, InputOnly}
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store: {NotUseful, WhenMapped,
Always}
backing-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
colormap: COLORMAP or None
map-is-installed: BOOL
map-state: {Unmapped, Unviewable,
Viewable}
all-event-masks, your-event-mask:
SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
root: WINDOW
depth: CARD8
x, y: INT16
width, height, border-width: CARD16
Errors:
Window
GetWindowAttributes
and
GetGeometry
are frequently used together in the X protocol.
LbxGetWinAttrAndGeom
allows the proxy to request the same information in one round trip.
The encoding for this request is on See
LbxGetWinAttrAndGeom .
LbxQueryFont
font
: FONTABLE
=>
compression: BOOL
tag: CARD32
font-info: FONTINFO /* optional
*/
char-infos: LISTofCHARINFO or LISTofLBXCHARINFO
/* optional */
where:
LBXCHARINFO: [left-side-bearing:
INT6
right-side-bearing: INT7
character-width: INT6
ascent: INT6
descent: INT7]
Errors:
Font,Alloc
This request is used to replace the core
QueryFont
request and has identical semantics.
See See Tag Substitution in Requests for a
description of the
tag
field and optional fields.
The
compression
field is True if the
char-infos
field is represented using LBXCHARINFO.
The per-character information will be encoded in an LBXCHARINFO when, for every
character, the character-width, left-side-bearing, and ascent can each be
represented in not more than 6 bits, and the right-side-bearing and descent can
each be represented in not more than 7 bits, and the attributes field is
identical the attributes field of the max_bounds of the
font_info
field of the font.
The encoding for this request is on See
LbxQueryFont .
LbxChangeProperty
window
: WINDOW
property
: ATOM
type
: ATOM
format
: {0,8,16,32}
mode
: {Replace, Prepend, Append}
nUnits
: CARD32
=>
tag: CARD32
This request is sent to the server when the client sends an X
ChangeProperty
request through the proxy. The size of the data is sent with this request, but
not the property data itself. The server reply contains a tag identifier for
the data, which is stored in the proxy. The proxy must not discard this data
before it is sent to the server, or invalidated by the server. This means that
before issuing an
LbxStopProxy
request, or exiting, the proxy must send Lbx
TagData
requests for these items. If the server loses the connection before the
information is sent back, the server should revert the property value to its
last known value, if possible.
If the
mode
field is
Prepend
or
Append
, the tag refers only to the prepended or appended data.
If the tag in the reply is zero, then the change was ignored by the server, as
defined in the security extension. The proxy should dump the associated data,
since the server will never ask for it.
The encoding for this request is on See
LbxChangeProperty .
LbxGetProperty
window
: WINDOW
property
: ATOM
type
: ATOM or AnyPropertyType
long-offset
: CARD32
long-length
: CARD32
delete
: CARD8
=>
type: ATOM or None
format: {0, 8, 16, 32}
bytes-after: CARD32
nItems: CARD32
tag: CARD32
value: LISTofINT8 or LISTofINT16 or
LISTofINT32
This request may be used by the proxy as a substitution for a core
GetProperty
request. It allows tags to be used for property data that is unlikely to
change often in value, but is likely to be fetched by multiple clients.
The
LbxGetProperty
request has the same arguments as the core
GetProperty
request. The reply for
LbxGetProperty
has all of the fields from the core
GetProperty
reply, but has the additional fields of
nItems
and
tag
.
In order to utilize tags in
LbxGetProperty
for a specific property, the server must first send the complete property data
to the proxy and associate this data with a tag. More precisely, the server
sends an
LbxGetProperty
reply with a new
tag
,
nItems
set to the number of items in the property, the size of the property data in
the reply length field, and the complete property data in value. The proxy
stores the property data in its tag cache and associates it with the specified
tag.
In response to future
LbxGetProperty
requests for the same property, if the server thinks that the proxy has the
actual property data in its tag cache, it may choose to send an
LbxGetProperty
reply without the actual property data. In this case, the reply would include
a non-zero
tag
, a zero reply length, and no data for value.
If the server chooses not to generate a tagged reply to
LbxGetProperty
, or for some reason is unable to do so, it would send a reply with a
tag
of zero, the size of the property data in the reply length field, and the
complete property data in value.
The encoding for this request is on See
LbxGetProperty .
LbxPolyPoint
gc-and-drawable:
LBXGCANDDRAWABLE
points
: LISTofLBXPOINT
Errors:
Alloc
and those given for the corresponding X request.
This request replaces the
PolyPoint
request. Not all
PolyPoint
requests can be represented as
LbxPolyPoint
requests.
The proxy will convert the representation of the points to be relative to the
previous point, as described by previous coordinate mode in the X protocol.
The encoding for this request is on See
LbxPolyPoint .
LbxPolyLine
gc-and-drawable:
LBXGCANDDRAWABLE
points
: LISTofLBXPOINT
Errors:
Alloc
and those given for the corresponding X request.
This request replaces the
PolyLine
request. Not all
PolyLine
requests can be represented as
LbxPolyline
requests.
The proxy will convert the representation of the points to be relative to the
previous point, as described by previous coordinate mode in the X protocol.
The encoding for this request is on See The
description of this request is on page 21. .
LbxPolySegment
gc-and-drawable:
LBXGCANDDRAWABLE
segments
: LISTofLBXSEGMENT
where:
LBXSEGEMENT; [x1, y1, x2, y2: LBXINT16]
Errors:
Alloc
and those given for the corresponding X request.
This request replaces the
PolySegment
request. Not all
PolySegment
requests can be represented as
LbxPolySegment
requests.
For segments other than the first segment of the request, [x1, y1] is
relative to [x1, y1] of the previous segment. For all segments, [x2, y2] is
relative to that segment’s [x1, y1].
The encoding for this request is on See
LbxPolySegment .
LbxPolyRectangle
gc-and-drawable:
LBXGCANDDRAWABLE
rectangles
: LISTofLBXRECTANGLE
Errors:
Alloc
and those given for the corresponding X request.
This request replaces the
PolyRectangle
request. Not all
PolyRectangle
requests can be represented as
LbxPolyRectangle
requests.
The encoding for this request is on See The
description of this request is on page 22. .
LbxPolyArc
gc-and-drawable:
LBXGCANDDRAWABLE
arcs
: LISTofLBXARC
Errors:
Alloc
and those given for the corresponding X request.
This request replaces the
PolyArc
request. Not all
PolyArc
requests can be represented as
LbxPolyArc
requests.
The encoding for this request is on See
LbxPolyArc .
LbxPolyFillRectangle
gc-and-drawable:
LBXGCANDDRAWABLE
rectangles
: LISTofLBXRECTANGLE
Errors:
Alloc
and those given for the corresponding X request.
This request replaces the
PolyFillRectangle
request. Not all
PolyFillRectangle
requests can be represented as
LbxPolyFillRectangle
requests.
The encoding for this request is on See
LbxPolyFillRectangle .
LbxPolyFillArc
gc-and-drawable:
LBXGCANDDRAWABLE
arcs
: LISTofLBXARC
Errors:
Alloc
and those given for the corresponding X request.
This request replaces the
PolyFillArc
request. Not all
PolyFillArc
requests can be represented as
LbxPolyFillArc
requests.
The encoding for this request is on See The
description of this request is on page 22. .
LbxFillPoly
gc-and-drawable:
LBXGCANDDRAWABLE
shape
: BYTE
points
: LISTofLBXPOINT
Errors:
Alloc
and those given for the corresponding X request.
This request replaces the
FillPoly
request. Not all
FillPoly
requests can be represented as
LbxFillPoly
requests.
The proxy will convert the representation of the points to be relative to the
previous point, as described by previous coordinate mode in the X protocol.
The encoding for this request is on See
LbxFillPoly .
LbxCopyArea
srcCache
: CARD8 /* source drawable */
gc-and-drawable:
LBXGCANDDRAWABLE
src-Drawable
: CARD32
src-x
: LBXPINT16
src-y
: LBXPINT16
width
: LBXCARD16
height
: LBXCARD16
dst-x
: LBXPINT16
dst-y
: LBXPINT16
Errors: Those given for the corresponding X
request.
This request replaces the
CopyArea
request for requests within its encoding range.
The encoding for this request is on See
LbxCopyArea .
LbxCopyPlane
bit-plane
: CARD32
src-cache
: CARD8 /* cache reference for source drawable */
gc-and-drawable:
LBXGCANDDRAWABLE
src-drawable
: CARD32
src-x
: LBXPINT16
src-y
: LBXPINT16
width
: LBXCARD16
height
: LBXCARD16
dst-x
: LBXPINT16
dst-y
: LBXPINT16
Errors: Those given for the corresponding X
request.
This request replaces the
CopyPlane
request for requests within its coding range.
The encoding for this request is on See
LbxCopyPlane .
LbxPolyText8
gc-and-drawable:
LBXGCANDDRAWABLE
x
: LBXPINT16
y
: LBXPINT16
items
: LISTofTEXTITEM8
Errors:
Alloc
, and those given for the corresponding X request.
This request replaces the
PolyText8
request for requests within its encoding range.
The encoding for this request is on See The
description of this request is on page 23. .
LbxPolyText16
gc-and-drawable:
LBXGCANDDRAWABLE
x:
LBXPINT16
y
: LBXPINT16
items
: LISTofTEXTITEM16
Errors:
Alloc
, and those given for the corresponding X request.
This request replaces the
PolyText16
request for requests within its encoding range.
The encoding for this request is on See The
description of this request is on page 24. .
LbxImageText8
gc-and-drawable:
LBXGCANDDRAWABLE
nChars
: CARD8
x
: LBXPINT16
y
: LBXPINT16
string
: STRING8
Errors:
Alloc
, and those given for the corresponding X request.
This request replaces the
ImageText8
request for requests within its encoding range.
The encoding for this request is on See The
description of this request is on page 24. .
LbxImageText16
nChars
: CARD8
gc-and-drawable:
LBXGCANDDRAWABLE
x: LBXPINT16
y
: LBXPINT16
string
: STRING16
Errors:
Alloc
, and those given for the corresponding X request.
This request replaces the
ImageText16
request for requests within its encoding range.
The encoding for this request is on See The
description of this request is on page 24. .
LbxPutImage
compression-method
: CARD8
format
: {
Bitmap
,
XYPixmap
,
ZPixmap
} /* packed */
gc-and-drawable:
LBXGCANDDRAWABLE
width
,
height
: LBXCARD16
dst-x
,
dst-y
: LBXPINT16
depth
: CARD8 /* packed */
left-pad
: CARD8 /* packed */
pad-bytes
: CARD8 /* packed */
data
:LISTofBYTE
Errors:
Alloc
,
Value
When the request can be usefully compressed, this request replaces the
PutImage
request. The
compression-method
parameter contains the opcode of a compression method returned in the
LbxStartProxy
reply. The
pad-bytes
parameter gives the number of unused pad bytes that follow the compressed
image data. All other parameters are as in the X request. If the specified
compression method is not recognized, the server returns a
Value
error.
The encoding for this request is on See
LbxPutImage .
LbxGetImage
drawable
: DRAWABLE
x
,
y
: INT16
width
,
height
: CARD16
plane-mask
: CARD32
format
: {XYPixmap, ZPixmap}
=>
depth: CARD8
x-length: CARD32
visual: VISUALID or None
compression-method: CARD8
data: LISTofBYTE
Errors:
Alloc,Match,Value
This request can replace the
GetImage
request. The same semantics apply, with the following exceptions.
The
compression-method
field contains the opcode of the compression method used in the reply. The
compression opcodes are supplied in the
LbxStartProxy
reply. The
x-length
field
contains the length of the uncompressed version of the reply in 4 byte units.
A
Value
error is returned if the format is not recognized by the X server. A
Match
error is returned under the same circumstances as described by the
GetImage
request.
The encoding for this request is on See
LbxGetImage .
LbxBeginLargeRequest
large-request-length
: CARD32
Errors:
Alloc
This request, along with the Lbx
LargeRequestData
and Lbx
EndLargeRequest
requests, is used to transport a large request in pieces. The smaller size of
the resulting requests allows smoother multiplexing of clients on a single low
bandwidth connection to the server. The resulting finer-grained multiplexing
improves responsiveness for the other clients.
After a
LbxBeginLargeRequest
request is sent, multiple
LbxLargeRequestData
requests are sent to transport all of the data in the large request, and
finally an
LbxEndLargeRequest
request is sent. The large-request-length field expresses the total length of
the transported large request, expressed as the number of bytes in the
transported request divided by four.
The encoding for this request is on See The
description of this request is on page 25. .
LbxLargeRequestData
data
: LISTofBYTE
Errors:
Alloc
This request is used to carry the segments of a larger request, as described in
the definition of
LbxBeginLargeRequest
. The data must be carried in order, starting with the request header, and each
segment must be multiples of 4 bytes long. If the
LbxLargeRequestData
is not preceded by a corresponding
LbxBeginLargeRequest
, a
BadAlloc
error is generated.
The encoding for this request is on See The
description of this request is on page 26. .
LbxEndLargeRequest
Errors:
Length, Alloc
As described in the definition of
LbxBeginLargeRequest
,
LbxEndLargeRequest
is used to signal the end of a series of
LargeRequestData
requests. If the total length of the data transported by the
LbxLargeRequestData
requests does not match the large-request-length field of the preceding
LbxBeginLargeRequest
request, then a
Length
error occurs. If the
LbxEndLargeRequest
is not preceded by a corresponding
LbxBeginLargeRequest
, a
BadAlloc
error is generated. The request is executed in order for that client as if it
were the request after the request preceding
LbxEndLargeRequest
.
The encoding for this request is on See
LbxEndLargeRequest .
Events
LbxSwitchEvent
client
: CARD32
Notify the proxy that the subsequent replies, events, and errors are relative
to the specified client.
The encoding for this event is on See
LbxSwitchEvent .
LbxCloseEvent
client
: CARD32
Notify the proxy that the specified client's connection to the server is closed.
The encoding for this event is on See The
description of this event is on page 27. .
LbxInvalidateTagEvent
tag
: CARD32
tag-type
: {Modmap, Keymap, Property, Font, ConnInfo}
This message informs the proxy that the tag and the server data referenced by
the tag are obsolete, and should be discarded. The tag type may be one of the
following values:
LbxTagTypeModmap
,
LbxTagTypeKeymap
,
LbxTagTypeProperty
,
LbxTagTypeFont
,
LbxTagTypeConnInfo
.
The encoding for this event is on See
LbxInvalidateTagEvent .
LbxSendTagDataEvent
tag
: CARD32
tag-type
: {Property}
The server sends this event to the proxy to request a copy of tagged data which
is being stored by the proxy. The request contains a tag which was previously
assigned to the data by the server. The proxy should respond to
SendTagData
by sending a
TagData
request to the server. The tag type may be one of the following values:
LbxTagTypeProperty
.
The encoding for this event is on See
LbxSendTagDataEvent .
LbxListenToOne
client
: CARD32 or
0xffffffff
When the server is grabbed,
ListenToOne
is sent to the proxy. As an X client, the proxy itself is unaffected by grabs,
in order that it may respond to requests for data from the X server.
When the client grabbing the server is managed through the proxy, the proxy
will permit messages from itself and the grabbing client to be sent immediately
to the server, and may buffer requests from other clients of the proxy. The
client is identified in the event.
When the client grabbing the server is not managed through the proxy, the
client field in the event will be
0xffffffff
. The proxy will communicate with the server, and it may buffer requests from
other clients. The proxy will continue to handle new connections while the
server is grabbed.
The server will send
ListenToAll
to the proxy when the server is ungrabbed. There is no time-out for this
interval in the protocol.
The encoding for this event is on See The
description of this event is on page 27. .
LbxListenToAll
Notify the proxy that the server has been ungrabbed, and that the proxy may now
send all buffered client requests on to the server.
The encoding for this event is on See The
description of this event is on page 27. .
LbxQuickMotionDeltaEvent
deltaTime
: CARD8
deltaX
: INT8
deltaY
: INT8
This event is used as a replacement for the
MotionNotify
event when possible. The fields are used as deltas to the most recent
MotionNotify
event encoded as a
MotionNotify
event,
LbxQuickMotionDeltaEvent
, or
LbxMotionDeltaEvent
. Not every
MotionNotify
event can be encoded as a
LbxQuickMotionDeltaEvent
.
The encoding for this event is on See
LbxQuickMotionDeltaEvent .
LbxMotionDeltaEvent
deltaX
: INT8
deltaY
: INT8
deltaTime
: CARD16
deltaSequence
: CARD16
This event is used as a replacement for the
MotionNotify
event when possible. The fields are used as deltas to the most recent
MotionNotify
event encoded as a
MotionNotify
event,
LbxQuickMotionDeltaEvent
, or
LbxMotionDeltaEvent
. Not every
MotionNotify
event can be encoded as
a LbxMotionDeltaEvent
.
The encoding for this event is on See
LbxMotionDeltaEvent .
LbxReleaseCmapEvent
colormap
: Colormap
This event notifies the proxy that it must release the grab on this colormap
via the ReleaseCmap request. See
LbxReleaseCmap
The encoding for this event is on See
LbxReleaseCmapEvent .
LbxFreeCellsEvent
colormap
: Colormap
pixelStart, pixelEnd
: CARD32
The
LbxFreeCells
event is sent to a proxy that has a colormap grabbed to notify the proxy that
the reference count of the described cells were decremented to zero by the
server or another proxy. The reference count includes those by this proxy. The
proxy must update its copy of the colormap state accordingly if the colormap is
still grabbed, or if the proxy may in the future grab the colormap using
smart-grab mode. See LbxGrabCmap
The pixelStart and pixelEnd fields of the event denote a continuous range of
cells that were freed.
The encoding for this event is on See
LbxFreeCellsEvent .
Responses
Responses are messages from the server to the proxy that not, strictly
speaking, events, replies or errors.
LbxDeltaResponse
count
: CARD8
cache-index
: CARD8
diffs
: LISTofDIFFITEM
This response carries an event, reply, or error that has been encoded relative
to a message in the response delta cache. The
cache-index
field is the index into the cache. Each entry in
diffs
provides a byte offset and replacement value to use in reconstructing the
response.
The encoding for this event is on See
LbxDeltaResponse .
Algorithm Naming
To avoid potential clashes between different but similar algorithms for stream,
bitmap, and pixmap compression, the following naming scheme will be adhered to:
Each algorithm has a unique name, which is a STRING8, of the following form:
<organization>-<some-descriptive-name>
The organization field above is the organization name as registered in section
1 of the X Registry (the registry is provided as a free service by the X
Consortium.) This prevents conflicts among different vendor’s extensions.
As an example, the X Consortium defines a zlib-based stream compression
algorithm called XC-ZLIB.
Encoding
The syntax and types used in the encoding are taken from the X protocol
encoding. Where LBX defines new types, they are defined earlier in this
document.
As in the X protocol, in various cases, the number of bytes occupied by a
component will be specified by a lowercase single-letter variable name instead
of a specific numeric value, and often some other component will have its value
specified as a simple numeric expression involving these variables. Components
specified with such expressions are always interpreted as unsigned integers.
The scope of such variables is always just the enclosing request, reply, error,
event, or compound type structure.
For unused bytes, the encode-form is:
N unused
If the number of unused bytes is variable, the encode-form typically is:
p unused, p=pad(E)
where E is some expression, and pad(E) is the number of bytes needed to round E
up to a multiple of four.
pad(E) = (4 - (E mod 4)) mod 4
In many of the encodings, the length depends on many variable length fields.
The variable L is used to indicate the number of padded 4 byte units needed to
carry the request. Similarly, the variable Lpad indicates the number of bytes
needed to pad the request to a 4 byte boundary.
For counted lists there is a common encoding of NLISTofFOO:
NLISTofFOO
1 m num items
m LISTofFOO items
For cached GC and Drawables:
LBXGCANDDRAWUPDATE
4 or 0 DRAWBLE optional drawable
4 or 0 GC optional GC
LBXGCANDDRAWABLE
8 LBXGCANDDRAWENT cache-entries
8 unused
m LBXGCANDDRAWUPDATE optional GC and Drawable
Errors
LbxClient
1 0 Error
1 CARD8 error-base + 0
2 CARD16 sequence number
4 unused
2 CARD16 lbx opcode
1 CARD8 major opcode
21 unused
Requests
LbxQueryVersion
1 CARD8 opcode
1 0 lbx opcode
2 1 request length
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 major version
2 CARD16 minor version
20 unused
The description of this request is on See
LbxQueryVersion .
LbxStartProxy
1 CARD8 opcode
1 1 lbx opcode
2 L request length
n NLISTofOPTION-REQUEST options
p unused, p=pad(n)
OPTION-REQUEST
1 OPTCODE option-code
m OPTLEN option-request-byte-length, (b=m+a+1)
a DELTAOPT or option
NLISTofNAMEDOPT or
NLISTofSTR or
NLISTofPIXMAPMETHOD or
BOOL
The encoding of the option field depends on the option-code.
See See StartProxy Options .
1 OPTCODE option-code
0 LbxOptionDeltaProxy
1 LbxOptionDeltaServer
2 LbxOptionStreamCompression
3 LbxOptionBitmapCompression
4 LbxOptionPixmapCompression
5 LbxOptionMessageCompression /* also known as squishing */
6 LbxOptionUseTags
7 LbxOptionColormapAllocation
255 LbxOptionExtension
OPTLEN has two possible encodings, depending on the size of the value carried:
OPTLEN
1 CARD8 b (0 < b <= 255)
OPTLEN
1 0 long length header
1 c length0, c = b >> 8
1 d length1, d= b & #xff
DELTAOPT
1 CARD8 min-cache-size
1 CARD8 max-cache-size
1 CARD8 preferred-cache-size
1 CARD8 min-message-length
1 CARD8 max-message-length (in 4-byte units)
1 CARD8 preferred-message-length
NAMEDOPT
f STR type-name
1 g+1 option-data-length
g LISTofBYTE option-data (option specific)
PIXMAPMETHOD
h STR name
1 BITMASK format mask
1 j depth count
j LISTofCARD8 depths
=>
=>
1 1 Reply
1 CARD8 count
0xff options in request cannot be decoded
2 CARD16 sequence number
4 (a+p-32)/4 reply length
a LISTofCHOICE options-reply
p unused, if (n<24) p=24-n else p=pad(n)
CHOICE
1 CARD8 request-option-index
b OPTLEN reply-option-byte-length
c DELTACHOICE or choice
INDEXEDCHOICE or
NLISTofINDEXEDOPT or
NLISTofPIXMAPCHOICE or
BOOL or
INDEXEDCHOICE
The encoding of the choice field depends on the option-code. See See StartProxy Options .
DELTACHOICE
1 CARD8 preferred cache size
1 CARD8 preferred message length in 4-byte units
INDEXEDCHOICE
1 CARD8 index
d LISTofBYTE data
PIXMAPCHOICE
1 CARD8 index
1 CARD8 opcode
1 BITMASK format mask
e NLISTofCARD8 depths
The description of this request is on See
LbxStartProxy .
LbxStopProxy
1 CARD8 opcode
1 2 lbx opcode
2 1 request length
The description of this request is on See
LbxStopProxy .
LbxSwitch
1 CARD8 opcode
1 3 lbx opcode
2 2 request length
4 CARD32 client
The description of this request is on
See LbxSwitch .
LbxNewClient
1 CARD8 opcode
1 4 lbx opcode
2 L request length
4 CARD32 client
The remaining bytes of the request are the core connection setup.
=>
If the connection is rejected, a core connection reply is sent. Otherwise the
reply has the form:
1 BOOL success
1 change type
0 no-deltas
1 normal-client-deltas
2 app-group-deltas
2 CARD16 major version
2 CARD16 minor version
2 1 + a length
4 CARD32 tag id
The remaining bytes depend on the value of change-type and length.
For no-deltas, the remaining bytes are the "additional data"
bytes of the core reply. (a = length of core reply, in 4 byte quantities).
For normal-client-deltas, the additional bytes have the form, with a length (a
= 1 +b):
4 CARD32 resource id base
4b LISTofSETofEVENT root input masks
For app-group-deltas, the additional bytes have the following form, with a
length of (a = 1 + 4c):
4 CARD32 resource id base
4 WINDOW root id base
4 VISUALID visual
4 COLORMAP colormap
4 CARD32 white pixel
4 CARD32 black pixel
4c LISTofSETofEVENT root input masks
The description of this request is on
See LbxNewClient .
LbxCloseClient
1 CARD8 opcode
1 5 lbx opcode
2 2 request length
4 CARD32 client
The description of this request is on
See LbxCloseClient .
LbxModifySequence
1 CARD8 opcode
1 6 lbx opcode
2 2 request length
4 CARD32 offset to sequence number
The description of this request is on See
LbxModifySequence .
LbxAllowMotion
1 CARD8 opcode
1 7 lbx opcode
2 2 request length
4 CARD32 number of MotionNotify events
The description of this request is on See
LbxAllowMotion .
LbxIncrementPixel
1 CARD8 opcode
1 8 lbx opcode
2 3 request length
4 COLORMAP colormap
4 CARD32 pixel
The description of this request is on See
LbxIncrementPixel .
LbxDelta
1 CARD8 opcode
1 9 lbx opcode
2 1+(2n +p+2)/4 request length
1 n count of diffs
1 CARD8 cache index
2n LISTofDIFFITEM offsets and differences
p unused, p=pad(2n + 2)
The description of this request is on See
LbxDelta .
LbxGetModifierMapping
1 CARD8 opcode
1 10 lbx opcode
2 1 request length
=>
1 1 Reply
1 n keycodes-per-modifier
2 CARD16 sequence number
4 2n reply length
4 CARD32 tag
20 unused
8n LISTofKEYCODE keycodes
The description of this request is on See
LbxGetModifierMapping .
LbxInvalidateTag
1 CARD8 opcode
1 12 lbx opcode
2 2 request length
4 CARD32 tag
The description of this request is on See
LbxInvalidateTag .
LbxPolyPoint
1 CARD8 opcode
1 13 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXPOINT points (n is data-dependent)
p 0 unused, p=Lpad
The description of this request is on See
LbxPolyPoint .
LbxPolyLine
1 CARD8 opcode
1 14 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXPOINT points (n is data-dependent)
p 0 unused, p=Lpad
The description of this request is on See
LbxPolyLine .
LbxPolySegment
1 CARD8 opcode
1 15 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXSEGMENT segments (n is data-dependent)
p 0 unused, p=Lpad
The description of this request is on See
LbxPolySegment .
LbxPolyRectangle
1 CARD8 opcode
1 16 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXRECTANGLE rectangles (n is data-dependent)
p 0 unused, p=pad(m+n)
The description of this request is on See
LbxPolyRectangle .
LbxPolyArc
1 CARD8 opcode
1 17 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXARCS arcs (n is data-dependent)
p 0 unused, p=Lpad
The description of this request is on See
LbxPolyArc .
LbxFillPoly
1 CARD8 opcode
1 18 lbx opcode
2 1+(3+m+n+p)/4 request length
1 LBXGCANDDRAWENT cache entries
1 shape
0 Complex
1 Nonconvex
2 Convex
1 p pad byte count
m LBXGCANDDRAWUPDATE optional gc and drawable
n LISTofLBXPOINT points (n is data-dependent)
p 0 unused, p=Lpad
The description of this request is on See
LbxFillPoly .
LbxPolyFillRectangle
1 CARD8 opcode
1 19 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXRECTANGLE rectangles (n is data-dependent)
p 0 unused, p=Lpad
The description of this request is on See
LbxPolyFillRectangle .
LbxPolyFillArc
1 CARD8 opcode
1 20 lbx opcode
2 1+(m+n+p)/4 request length
m LBXGCANDDRAWABLE cache entries
n LISTofLBXARC arcs (n is data-dependent)
p 0 unused, p=Lpad
The description of this request is on See
LbxPolyFillArc .
LbxGetKeyboardMapping
1 CARD8 opcode
1 21 lbx opcode
2 2 request length
1 KEYCODE first keycode
1 m count
2 unused
=>
1 1 Reply
1 n keysyms-per-keycode
2 CARD16 sequence number
4 nm reply length (m = count field from the request)
4 CARD32 tag
20 unused
4nm LISTofKEYSYM keysyms
The description of this request is on See
LbxGetKeyboardMapping .
LbxQueryFont
1 CARD8 opcode
1 22 lbx opcode
2 2 request length
4 FONTABLE font
=>
1 1 Reply
1 BOOL compression
2 CARD16 sequence number
4 L reply length
4 CARD32 tag
20 unused
All of the following is conditional:
12 CHARINFO min-bounds
4 unused
12 CHARINFO max-bounds
4 unused
2 CARD16 min-char-or-byte2
2 CARD16 max-char-or-byte2
2 CARD16 default-char
2 n number of FONTPROPs in properties
1 draw-direction
0 LeftToRight
1 RightToLeft
1 CARD8 min-byte1
1 CARD8 max-byte1
1 BOOL all-chars-exist
2 INT16 font-ascent
2 INT16 font-descent
4 m number of elements in char-infos
8n LISTofFONTPROP properties
and either
12m LISTofCHARINFO char-infos
or
m LISTofLBXCHARINFO char-infos
The description of this request is on See
LbxQueryFont .
LbxChangeProperty
1 CARD8 opcode
1 23 lbx opcode
2 6 request length
4 WINDOW window
4 ATOM property
4 ATOM type
1 CARD8 format
1 mode
0 Replace
1 Preprend
2 Append
2 unused
4 CARD32 length of data in format units
(= n for format = 8)
(= n/2 for format = 16)
(= n/4 for format = 32)
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 CARD32 tag
20 unused
The description of this request is on See
LbxChangeProperty .
LbxGetProperty
1 CARD8 opcode
1 24 lbx opcode
2 7 request length
4 WINDOW window
4 ATOM property
4 ATOM type
0 AnyPropertyType
1 CARD8 delete
3 unused
4 CARD32 long-offset
4 CARD32 long-length
=>
1 1 Reply
1 CARD8 format
2 CARD16 sequence number
4 CARD32 reply length
4 ATOM type
0 None
4 CARD32 bytes-after
4 CARD32 length of value in format units
(= 0 for format = 0)
(= n for format = 8)
(= n/2 for format = 16)
(= n/4 for format = 32)
4 CARD32 tag
8 unused
The description of this request is on See
LbxGetProperty .
LbxTagData
1 CARD8 opcode
1 25 lbx opcode
2 3+(n+p)/4 request length
4 CARD32 tag
4 CARD32 length of data in bytes
n LISTofBYTE data
p unused, p=pad(n)
The description of this request is on See
LbxTagData .
LbxCopyArea
1 CARD8 opcode
1 26 lbx opcode
2 L request length
1 CARD8 source drawable cache entry
1 LBXGCANDDRAWENT cache entries
4 or 0 DRAWABLE optional source drawable
b LBXGCANDDRAWUPDATE optional gc and dest drawable
c LBXPINT16 src-x
d LBXPINT16 src-y
e LBXPINT16 dst-x
f LBXPINT16 dst-y
g LBXCARD16 width
h LBXCARD16 height
p unused, p=Lpad
The description of this request is on See
LbxCopyArea .
LbxCopyPlane
1 CARD8 opcode
1 27 lbx opcode
2 L request length
4 CARD32 bit plane
1 CARD8 source drawable cache entry
1 LBXGCANDDRAWENT cache entries
4 or 0 DRAWABLE optional source drawable
b LBXGCANDDRAWUPDATE optional gc and dest drawable
c LBXPINT16 src-x
d LBXPINT16 src-y
e LBXPINT16 dst-x
f LBXPINT16 dst-y
g LBXCARD16 width
h LBXCARD16 height
p unused, p=Lpad
The description of this request is on See
LbxCopyPlane .
LbxPolyText8
1 CARD8 opcode
1 28 lbx opcode
2 L request length
1 LBXGCANDDRAWENT cache entries
a LBXGCANDDRAWUPDATE optional gc and drawable
b LBXPINT16 x
c LBXPINT16 y
n LISTofTEXTITEM8 items
p unused, p=Lpad
The description of this request is on See
LbxPolyText8 .
LbxPolyText16
1 CARD8 opcode
1 29 lbx opcode
2 L request length
1 LBXGCANDDRAWENT cache entries
a LBXGCANDDRAWUPDATE optional gc and drawable
b LBXPINT16 x
c LBXPINT16 y
2n LISTofTEXTITEM16 items
p unused, p=Lpad
The description of this request is on See
LbxPolyText16 .
LbxImageText8
1 CARD8 opcode
1 30 lbx opcode
2 L request length
1 LBXGCANDDRAWENT cache entries
a LBXGCANDDRAWUPDATE optional gc and drawable
b LBXPINT16 x
c LBXPINT16 y
n STRING8 string
p unused, p=Lpad
The description of this request is on See
LbxImageText8 .
LbxImageText16
1 CARD8 opcode
1 31 lbx opcode
2 L request length
1 LBXGCANDDRAWENT cache entries
a LBXGCANDDRAWUPDATE optional gc and drawable
b LBXPINT16 x
c LBXPINT16 y
2n STRING16 string
p unused, p=Lpad
The description of this request is on See
LbxImageText16 .
LbxQueryExtension
1 CARD8 opcode
1 32 lbx opcode
2 2+(n+p)/4 request length
4 n length of extension name
n STRING8 extension name
p unused, p=pad(n)
=>
1 1 Reply
1 n number of requests in the extension
2 CARD16 sequence number
4 0 or 2*(m + p) reply length, m = (n+7)/8
1 BOOL present
1 CARD8 major opcode
1 CARD8 first event
1 CARD8 first error
20 unused
m LISTofMASK optional reply-mask
p unused, p=pad(m)
m LISTofMASK optional event-mask
p unused, p=pad(m)
The description of this request is on See
LbxQueryExtension .
LbxPutImage
1 CARD8 opcode
1 33 lbx opcode
2 L request length
1 CARD8 compression method
1 LBXGCANDDRAWENT cache entries
a PIPACKED bit-packed
b LBXGCANDDRAWUPDATE optional gc and drawable
c LBXCARD16 width
d LBXCARD16 height
e LBXPINT16 x
f LBXPINT16 y
n LISTofBYTE compressed image data
p unused, p=Lpad
If there is no left padding and the depth is less than or equal to nine,
PIPPACKED is encoded as follows:
PIPACKED
1 #x80 | (format << 5) | ((depth -1) << 2)
Otherwise PIPACKED is defined as:
PIPACKED
1 (depth -1) << 2)
1 (format << 5) | left-pad
The description of this request is on See
LbxPutImage .
LbxGetImage
1 CARD8 opcode
1 34 lbx opcode
2 6 request length
4 DRAWABLE drawable
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
4 CARD32 plane mask
1 CARD8 format
3 unused
=>
1 1 Reply
1 CARD8 depth
2 CARD16 sequence number
4 (n+p)/4 reply length
4 (m+p)/4 X reply length; if uncompressed, m=n
4 VISUALID visual
0 None
1 compression method
15 unused
n LISTofBYTE data
p unused, p=pad(n)
The description of this request is on See
LbxGetImage .
LbxBeginLargeRequest
1 CARD8 opcode
1 35 lbx opcode
2 2 request length
4 CARD32 large request length
The description of this request is on See
LbxBeginLargeRequest .
LbxLargeRequestData
1 CARD8 opcode
1 36 lbx opcode
2 1+n request length
4n LISTofBYTE data
The description of this request is on See
LbxLargeRequestData .
LbxEndLargeRequest
1 CARD8 opcode
1 37 lbx opcode
2 1 request length
The description of this request is on See
LbxEndLargeRequest .
LbxInternAtoms
1 CARD8 opcode
1 38 lbx opcode
2 1+(2+m+n+p)/4 request length
2 m num-atoms
n LISTofLONGSTR names
p pad p=Lpad
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 a reply length, a = MAX(m - 6, 0)
4*m LISTofATOM atoms
p pad p = MAX(0, 4*(6 - m))
LONGSTR
2 c string length
c STRING8 string
The description of this request is on See
LbxInternAtoms .
LbxGetWinAttrAndGeom
1 CARD8 opcode
1 39 lbx opcode
2 2 request length
4 CARD32 window id
=>
1 1 Reply
1 backing store
0 NotUseful
1 WhenMapped
2 Always
2 CARD16 sequence number
4 7 reply length
4 VISUALID visual id
2 class
1 InputOutput
2 InputOnly
1 BITGRAVITY bit gravity
1 WINGRAVITY window gravity
4 CARD32 backing bit planes
4 CARD32 backing pixel
1 BOOL save under
1 BOOL map installed
1 map state
0 Unmapped
1 Unviewable
2 Viewable
1 BOOL override
4 COLORMAP colormap
4 SETofEVENT all events mask
4 SETofEVENT your event mask
2 SETofDEVICEEVENT do not propagate mask
2 unused
4 WINDOW root
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border width
1 CARD8 depth
1 unused
The description of this request is on See
LbxGetWinAttrAndGeom .
LbxGrabCmap
1 CARD8 opcode
1 40 lbx opcode
2 2 request length
4 COLORMAP colormap
=>
If smart-grab is true, the reply is as follows:
1 1 Reply
1 #x80 flags
2 CARD16 sequence number
4 0 reply length
24 unused
If smart-grab is false, the reply is as follows:
1 1 Reply
1 flags (set of)
#x40 auto-release
#x20 three-channels
#x10 two-byte-pixels
lower four bits specifies bits-per-pixel
2 CARD16 sequence number
4 L reply length
m CHAN or CHANNELS cells (CHAN if !three-channels)
p 0 pad(m)
CHANNELS
a CHAN red
1 5 next channel
b CHAN green
1 5 next channel
c CHAN blue
1 0 list end
CHAN
d LISTofLBXPIXEL
LBXPIXEL
e PIXELPRIVATE or
PIXELPRIVATERANGE or
PIXELALLOC or
PIXELALLOCRANGE
PIXELPRIVATE
1 1 pixel-private
f PIXEL pixel
PIXEL
f CARD8 or CARD16 (CARD8 if !two-byte-pixels)
PIXELPRIVATERANGE
1 2 pixel-private-range
f PIXEL fist-pixel
f PIXEL last-pixel
PIXELALLOC
1 3 pixel-private
f PIXEL pixel
g COLORSINGLE or COLORTRIPLE color (COLORSINGLE if
three-channels)
COLORSINGLE
h CARD8 or CARD16 value (CARD8 if bits-per-rgb =< 7)
COLORTRIPLE
h COLORSINGLE red
h COLORSINGLE green
h COLORSINGLE blue
PIXELALLOCRANGE
1 4 pixel-private
f PIXEL first-pixel
f PIXEL last-pixel
j LISTofCOLORSINGLE or color (COLORSINGLE if three-channels)
LISTofCOLORTRIPLE
The description of this request is on See
LbxGrabCmap .
LbxReleaseCmap
1 CARD8 opcode
1 41 lbx opcode
2 2 request length
4 COLORMAP cmap
The description of this request is on See
LbxReleaseCmap .
LbxAllocColor
1 CARD8 opcode
1 42 lbx opcode
2 5 request length
4 COLORMAP colormap
4 CARD32 pixel
2 CARD16 red
2 CARD16 green
2 CARD16 blue
2 unused
The description of this request is on See
LbxAllocColor .
LbxSync
1 CARD8 opcode
1 43 lbx opcode
2 1 request length
=>
1 1 Reply
1 n unused
2 CARD16 sequence number
4 0 reply length
24 unused
The description of this request is on See
LbxSync .
Events
LbxSwitchEvent
1 base + 0 code
1 0 lbx type
2 CARD16 sequence number
4 CARD32 client
24 unused
The description of this event is on See
LbxSwitchEvent .
LbxCloseEvent
1 base + 0 code
1 1 lbx type
2 CARD16 sequence number
4 CARD32 client
24 unused
The description of this event is on See
LbxCloseEvent .
LbxInvalidateTagEvent
1 base + 0 code
1 3 lbx type
2 CARD16 sequence number
4 CARD32 tag
4 tag-type
1 LbxTagTypeModmap
2 LbxTagTypeKeymap
3 LbxTagTypeProperty
4 LbxTagTypeFont
5 LbxTagTypeConnInfo
20 unused
The description of this event is on See
LbxInvalidateTagEvent .
LbxSendTagDataEvent
1 base + 0 code
1 4 lbx type
2 CARD16 sequence number
4 CARD32 tag
4 tag-type
3 LbxTagTypeProperty
20 unused
The description of this event is on See
LbxSendTagDataEvent .
LbxListenToOne
1 base + 0 code
1 5 lbx type
2 CARD16 sequence number
4 CARD32 client
#xFFFFFFFF
a client not managed by the proxy
24 unused
The description of this event is on See
LbxListenToOne .
LbxListenToAll
1 base + 0 code
1 6 lbx type
2 CARD16 sequence number
28 unused
The description of this event is on See
LbxListenToAll .
LbxQuickMotionDeltaEvent
1 base + 1 code
1 CARD8 delta-time
1 INT8 delta-x
1 INT8 delta-y
This event is not padded to 32 bytes.
The description of this event is on See
LbxQuickMotionDeltaEvent .
LbxMotionDeltaEvent
1 base + 0 code
1 7 lbx type
1 INT8 delta-x
1 INT8 delta-y
2 CARD16 delta-time
2 CARD16 delta-sequence
This event is not padded to 32 bytes.
The description of this event is on See
LbxMotionDeltaEvent .
LbxReleaseCmapEvent
1 base + 0 code
1 8 lbx type
2 CARD16 sequence number
4 COLORMAP colormap
24 unused
The description of this event is on See
LbxReleaseCmapEvent .
LbxFreeCellsEvent
1 base + 0 code
1 9 lbx type
2 CARD16 sequence number
4 COLORMAP colormap
4 PIXEL pixel start
4 PIXEL pixel end
16 unused
The description of this event is on See
LbxFreeCellsEvent .
Re-encoding of X Events
The X protocol requires all X events to be 32 bytes. The LBX server reduces the
number of bytes sent between the server and the proxy for some X events by not
appending unused pad bytes to the event data. The offsets of X event data are
unchanged. The proxy will pad the events to 32 bytes before passing them on to
the client.
LBX reencodes X event representations into the following sizes, if squishing is
enabled:
KeyOrButton 32
EnterOrLeave 32
Keymap 32
Expose 20
GraphicsExposure 24
NoExposure 12
VisibilityNotify 12
CreateNotify 24
DestroyNotify 12
UnmapNotify 16
MapNotify 16
MapRequest 12
Reparent 24
ConfigureNotify 28
ConfigureRequest 28
GravityNotify 16
ResizeRequest 12
Circulate 20
Property Notify 20
SelectionClear 20
SelectionRequest 28
SelectionNotify 24
Colormap Notify 16
MappingNotify 8
ClientMessage 32
Unknown 32
Responses
LbxDeltaResponse
1 event_base + 0 event code
1 2 lbx type
2 1+(2+2n+p)/4 request length
1 n count of diffs
1 CARD8 cache index
2n LISTofDIFFITEM offsets and differences
p unused, p=pad(2n)
The description of this response is on See
LbxDeltaResponse .
xorgproto-2023.2/specs/xextproto/geproto.xml 0000644 0001750 0001750 00000012017 14443010026 016153 0000000 0000000
%defs;
]>
X Generic Event Extension
Peter
Hutterer
peter.hutterer@who-t.net
X Version 11, Release &fullrelvers;
Version 1.0
2007 Peter Hutterer
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the "Software"),
to deal in the Software without restriction, including without limitation
the rights to use, copy, modify, merge, publish, distribute, sublicense,
and/or sell copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice (including the next
paragraph) shall be included in all copies or substantial portions of the
Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
DEALINGS IN THE SOFTWARE.
Introduction
X was designed to provide 64 event opcodes for all extensions. These
events are limited to 32 bytes.
The Generic Event Extension provides a template event for extensions
to re-use a single event opcode. GE only provide headers and the most
basic functionality, leaving the extensions to interpret the events in
their specific context.
GenericEvents may be longer than 32 bytes. If so, the number of 4
byte units following the initial 32 bytes must be specified in the length
field of the event.
Extension Initialization
The name of this extension is "Generic Event Extension"
GEQueryVersion
client-major-version: CARD16
client-minor-version: CARD16
==>
major-version: CARD16
minor-version: CARD16
The client sends the highest supported version to the server and the
server sends the highest version it supports, but no higher than the
requested version. Major versions changes can introduce incompatibilities
in existing functionality, minor version changes introduce only backward
compatible changes. It is the clients responsibility to ensure that the
server supports a version which is compatible with its
expectations.
As of version 1.0, no other requests are provided by this extension.
Events
GE defines a single event, to be used by all extensions. The event's
structure is similar to a reply. This is a core protocol event, ID 35, and
is not itself an extension event.
GenericEvent
type: BYTE always GenericEvent (35)
extension: CARD8 extension offset
sequenceNumber: CARD16 low 16 bits of request seq. number
length: CARD32 length
evtype: CARD16 event type
The field 'extension' is to be set to the major opcode of the
extension. The 'evtype' field is the actual opcode of the event. The
length field specifies the number of 4-byte blocks after the initial 32
bytes. If length is 0, the event is 32 bytes long.
Notes
Although the wire event is of arbitrary length, the actual size of
an XEvent is restricted to sizeof(XEvent) [96 bytes, see Xlib.h]. If an
extension converts a wire event to an XEvent > 96 bytes, it will
overwrite the space allocated for the event. See struct _XSQEvent in
Xlibint.h for details.
Extensions need to malloc additional data and fill the XEvent
structure with pointers to the malloc'd data. The client then needs to
free the data, only the XEvent structure will be released by Xlib.
The server must not send GenericEvents longer than 32 bytes until it
has verified that the client is able to interpret these events. If a long
event is sent to a client unable to process GenericEvents, future
interpretation of replies and events by this client will fail.
xorgproto-2023.2/specs/xextproto/shape.xml 0000644 0001750 0001750 00000112041 14443010026 015572 0000000 0000000
%defs;
]>
X Nonrectangular Window Shape Extension Protocol
X.Org Standard
Keith Packard
MIT X Consortium Intel Corporation
Hideki Hiura
SunSoft, Inc.
X Version 11, Release &fullrelvers;
Version 1.1
1989 2004 The Open Group 2006 Keith Packard
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN
AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Except as contained in this notice, the name of the copyright holders
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
copyright holders.
Overview
This extension provides arbitrary window and border shapes within the X11
protocol.
The restriction of rectangular windows within the X protocol is a significant
limitation in the implementation of many styles of user interface. For
example, many transient windows would like to display a "drop shadow'' to
give the illusion of 3 dimensions. As another example, some user interface
style guides call for buttons with rounded corners; the full simulation of a
nonrectangular shape, particularly with respect to event distribution and
cursor shape, is not possible within the core X protocol. As a final
example, round clocks and nonrectangular icons are desirable visual addition
to the desktop.
This extension provides mechanisms for changing both the visible and interactive shape of a
window to arbitrary, possibly disjoint, nonrectangular forms. The intent
of the extension is to supplement the existing semantics, not replace them.
In particular, it is desirable for clients that are unaware of the
extension to still be able to cope reasonably with shaped windows. For
example, window managers should still be able to negotiate screen
real estate in rectangular pieces. Toward this end, any shape specified for
a window is clipped by the bounding rectangle for the window as specified by
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.
Description
Each window (even with no shapes specified) is defined by three regions: the
bounding region , the clip
region and the input region . The
bounding region is the area of the
parent window that the window will occupy (including border). The clip region
is the subset of the bounding region that is available for subwindows and
graphics. The area between the bounding region and the clip region is defined
to be the border of the window. The input region is the subset of the
bounding region that can "contain" the pointer.
A nonshaped window will have a bounding region that is a rectangle
spanning the window, including its border; the clip region will be a rectangle
filling the inside dimensions (not including the border); the input
region will match the bounding region. In this document,
these areas are referred to as the
default bounding region , the
default clip region and the
default input region . For a window with inside
size of width by
height and border width
bwidth , the default bounding, clip
and input regions are the rectangles (relative to the window origin):
bounding.x = -bwidth
bounding.y = -bwidth
bounding.width = width + 2 * bwidth
bounding.height = height + 2 * bwidth
clip.x = 0
clip.y = 0
clip.width = width
clip.height = height
input.x = -bwidth
input.y = -bwidth
input.width = width + 2 * bwidth
input.height = height + 2 * bwidth
This extension allows a client to modify any combination of the bounding,
clip or input regions by specifying new regions that combine with the default
regions. These new regions are called the
client bounding region ,
the client clip region and the
client input region . They are specified
relative to the origin of
the window and are always defined by offsets relative to the window origin
(that is, region adjustments are not required when the window is moved).
Three mechanisms for specifying regions are provided: a list of rectangles,
a bitmap, and an existing bounding or clip region from a window. This is
modeled on the specification of regions in graphics contexts in the core
protocol and allows a variety of different uses of the extension.
When using an existing window shape as an operand in specifying a new shape,
the client region is used, unless none has been set, in which case the
default region is used instead.
The effective bounding region of a window
is defined to be the intersection of
the client bounding region with the default bounding region. Any portion of
the client bounding region that is not included in the default bounding
region will not be included in the effective bounding region on the screen.
This means that window managers (or other geometry managers) used to dealing
with rectangular client windows will be able to constrain the client to a
rectangular area of the screen.
Construction of the effective bounding region is dynamic; the client bounding
region is not mutated to obtain the effective bounding region. If a client
bounding region is specified that extends beyond the current default bounding
region, and the window is later enlarged, the effective bounding region will
be enlarged to include more of the client bounding region.
The effective clip region of a window is defined to be the intersection of the
client clip region with both the default clip region and the client bounding
region. Any portion of the client clip region that is not included in both
the default clip region and the client bounding region will not be included in
the effective clip region on the screen.
Construction of the effective clip region is dynamic; the client clip region is
not mutated to obtain the effective clip region. If a client clip region is
specified that extends beyond the current default clip region and the
window or its bounding region is later enlarged, the effective clip region will
be enlarged to include more of the client clip region if it is included in
the effective bounding region.
The border of a window is defined to be the difference between the effective
bounding region and the effective clip region. If this region is empty, no
border is displayed. If this region is nonempty, the border is filled
using the border-tile or border-pixel of the window as specified in the core
protocol. Note that a window with a nonzero border width will never be able
to draw beyond the default clip region of the window. Also note that a zero
border width does not prevent a window from having a border, since the clip
shape can still be made smaller than the bounding shape.
All output to the window and visible regions of any subwindows will be
clipped to the effective clip region. The server must not retain window
contents beyond the effective bounding region with backing store. The window's
origin (for graphics operations, background tiling, and subwindow placement)
is not affected by the existence of a bounding region or clip region.
The effective input region of a window is
defined to be the intersection of the
client input region with both the default input region and the client bounding
region. Any portion of the client input region that is not included in both
the default input region and the client bounding region will not be included in
the effective input region on the screen.
Construction of the effective input region is dynamic; the client input region is
not mutated to obtain the effective input region. If a client input region is
specified that extends beyond the current default input region and the
window or its bounding region is later enlarged, the effective input region will
be enlarged to include more of the client input region if it is included in
the effective bounding region.
Areas that are inside the default bounding region but outside the effective
bounding region are not part of the window; these areas of the screen will
be occupied by other windows. Input events that occur within the default
bounding region but outside the effective bounding region will be delivered as
if the window was not occluding the event position. Events that occur in
a nonrectangular border of a window will be delivered to that window, just
as for events that occur in a normal rectangular border.
An
InputOnly
window can have its bounding or input region set, but it is a
Match
error to attempt to set a clip region on an
InputOnly
window or to specify its clip region as a source to a request
in this extension.
The server must accept changes to the clip and input regions of a root window, but
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.
Types
The following types are used in the request and event definitions in
subsequent sections.
SHAPE_KIND:
{ Bounding ,
Clip ,
Input }
SHAPE_OP:
{ Set ,
Union ,
Intersect ,
Subtract ,
Invert }
Set
indicates that the region specified as an explicit source in the request is
stored unaltered as the new destination client region.
Union
indicates that the source and destination regions are unioned together to
produce the new destination client region.
Intersect
indicates that the source and destination regions are intersected together to
produce the new destination client region.
Subtract
indicates that the source region is subtracted from the destination region to
produce the new destination region.
Invert
indicates that the destination region is subtracted from the source region to
produce the new destination region.
Requests
ShapeQueryVersion
=>
majorVersion: CARD16
minorVersion: CARD16
This request can be used to ensure that the server version of the SHAPE
extension is usable by the client. This document defines major version one
(1), minor version one (1).
ShapeRectangles
dest : WINDOW
destKind : SHAPE_KIND
op : SHAPE_OP
xOff, yOff : INT16
rectangles : LISTofRECTANGLES
ordering :
{ UnSorted ,
YSorted ,
YXSorted ,
YXBanded }
Errors:
Window ,
Length ,
Match ,
Value
This request specifies an array of rectangles, relative to the origin of the
window plus the specified offset (xOff and yOff) that together
define a region. This region is combined (as specified by the operator
op) with the existing client region (specified by destKind) of the
destination window, and the result is stored as the specified client region of
the destination window. Note that the list of rectangles can be empty,
specifying an empty region; this is not the same as passing
None to
ShapeMask ,
If known by the client,
ordering relations on the rectangles can be specified with the ordering
argument.
This may provide faster operation by the server.
The meanings of the ordering values are the same as in the core protocol
SetClipRectangles
request.
If an incorrect ordering is specified,
the server may generate a
Match
error, but it is not required to do so.
If no error is generated,
the graphics results are undefined.
Except for
UnSorted ,
the rectangles should be nonintersecting, or the resulting region will
be undefined.
UnSorted
means that the rectangles are in arbitrary order.
YSorted
means that the rectangles are nondecreasing in their Y origin.
YXSorted
additionally constrains
YSorted
order in that all rectangles with an equal Y origin are
nondecreasing in their X origin.
YXBanded
additionally constrains
YXSorted
by requiring that, for every possible Y scanline,
all rectangles that include that scanline have identical Y origins and Y
extents.
ShapeMask
dest : WINDOW
destKind : SHAPE_KIND
op : SHAPE_OP
xOff, yOff : INT16
source : PIXMAP or
None
Errors:
Window ,
Pixmap ,
Match ,
Value
The source in this request is a 1-bit deep pixmap, or
None .
If source is
None ,
the specified client region is removed from the window, causing the effective
region to revert to the default region. The
ShapeNotify
event generated by this request and subsequent
ShapeQueryExtents
will report that a client shape has not been specified.
If a valid pixmap is specified, it is converted
to a region, with bits set to one included in the region and bits set to
zero excluded, and an offset from the window origin as specified by
xOff and yOff. The resulting region is then combined (as
specified by the operator op) with the existing client region
(indicated by destKind) of the destination window, and the result is
stored as the specified client region of the destination window. The source
pixmap and destination window must have been created on the same screen,
or else a
Match
error results.
ShapeCombine
dest : WINDOW
destKind : SHAPE_KIND
op : SHAPE_OP
xOff, yOff : INT16
source : WINDOW
sourceKind : SHAPE_KIND
Errors:
Window ,
Match ,
Value
The client region, indicated by sourceKind, of the source window is
offset from the window origin by xOff and yOff and combined with
the client region, indicated by destKind, of the destination window.
The result is stored as the specified client region of the destination
window.
The source and destination windows must be on the same screen, or else a
Match
error results.
ShapeOffset
dest : WINDOW
destKind : SHAPE_KIND
xOff, yOff : INT16
Errors:
Window ,
Match ,
Value
The client region, indicated by destKind, is moved relative to its
current position by the amounts xOff and yOff.
ShapeQueryExtents
dest : WINDOW
=>
boundingShaped: BOOL
clipShaped: BOOL
xBoundingShape: INT16
yBoundingShape: INT16
widthBoundingShape: CARD16
heightBoundingShape: CARD16
xClipShape: INT16
yClipShape: INT16
widthClipShape: CARD16
heightClipShape: CARD16
Errors:
Window
The boundingShaped and clipShaped results are
True
if the corresponding client regions have been specified, else they are
False .
The x, y, width, and height values define the extents of the client regions,
when a client region has not been specified, the extents of the
corresponding default region are reported.
ShapeSelectInput
window : WINDOW
enable : BOOL
Errors:
Window ,
Value
Specifying enable as
True
causes the server to send the requesting client a
ShapeNotify
event whenever the bounding, clip or input region of the specified window is
altered by any client.
Specifying enable as
False
causes the server to stop sending such events.
ShapeInputSelected
window : WINDOW
=>
enable: BOOL
Errors:
Window
If enable is
True , then
ShapeNotify
events for the window are generated for this client.
ShapeGetRectangles
window : WINDOW
kind : SHAPE_KIND
=>
rectangles: LISTofRECTANGLE
ordering:
{ UnSorted ,
YSorted ,
YXSorted ,
YXBanded }
Errors:
Window,
Match
A list of rectangles describing the region indicated by kind, and the
ordering of those rectangles, is returned. The meaning of the ordering
values is the same as in the
ShapeRectangles
request.
Events
ShapeNotify
window : WINDOW
kind : SHAPE_KIND
shaped : BOOL
x, y : INT16
width ,
height : CARD16
time : TIMESTAMP
Whenever the client bounding, clip or input shape of a window is modified, a
ShapeNotify
event is sent to each client that has used
ShapeSelectInput
to request it.
Kind indicates which client region (bounding or clip) has been modified;
shaped is
True
when the window has a client shape of type kind, and is
False
when the window no longer has a client shape of this type.
The x, y, width, and height indicate the extents of the
current shape. When shaped is
False
these will indicate the extents of the default region. The timestamp
indicates the server time when the shape was changed.
Encoding
Please refer to the X11 Protocol Encoding document as this document uses
conventions established there.
The name of this extension is "SHAPE".
New Types
SHAPE_KIND
0 Bounding
1 Clip
2 Input
SHAPE_OP
0 Set
1 Union
2 Intersect
3 Subtract
4 Invert
Requests
ShapeQueryVersion
1 CARD8 opcode
1 0 shape opcode
2 1 request length
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 length
2 CARD16 major version
2 CARD16 minor version
20 unused
ShapeRectangles
1 CARD8 opcode
1 1 shape opcode
2 4+2n request length
1 SHAPE_OP operation
1 SHAPE_KIND destination kind
1 ordering
0 UnSorted
1 YSorted
2 YXSorted
3 YXBanded
1 unused
4 WINDOW destination window
2 INT16 x offset
2 INT16 y offset
8n LISTofRECTANGLE rectangles
ShapeMask
1 CARD8 opcode
1 2 shape opcode
2 5 request length
1 SHAPE_OP operation
1 SHAPE_KIND destination kind
2 unused
4 WINDOW destination window
2 INT16 x offset
2 INT16 y offset
4 PIXMAP source bitmap
0 None
ShapeCombine
1 CARD8 opcode
1 3 shape opcode
2 5 request length
1 SHAPE_OP operation
1 SHAPE_KIND destination kind
1 SHAPE_KIND source kind
1 unused
4 WINDOW destination window
2 INT16 x offset
2 INT16 y offset
4 WINDOW source window
ShapeOffset
1 CARD8 opcode
1 4 shape opcode
2 4 request length
1 SHAPE_KIND destination kind
3 unused
4 WINDOW destination window
2 INT16 x offset
2 INT16 y offset
ShapeQueryExtents
1 CARD8 opcode
1 5 shape opcode
2 2 request length
4 WINDOW destination window
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
1 BOOL bounding shaped
1 BOOL clip shaped
2 unused
2 INT16 bounding shape extents x
2 INT16 bounding shape extents y
2 CARD16 bounding shape extents width
2 CARD16 bounding shape extents height
2 INT16 clip shape extents x
2 INT16 clip shape extents y
2 CARD16 clip shape extents width
2 CARD16 clip shape extents height
4 unused
ShapeSelectInput
1 CARD8 opcode
1 6 shape opcode
2 3 request length
4 WINDOW destination window
1 BOOL enable
3 unused
ShapeInputSelected
1 CARD8 opcode
1 7 shape opcode
2 2 request length
4 WINDOW destination window
=>
1 1 Reply
1 BOOL enabled
2 CARD16 sequence number
4 0 reply length
24 unused
ShapeGetRectangles
1 CARD8 opcode
1 8 shape opcode
2 3 request length
4 WINDOW window
1 SHAPE_KIND source kind
3 unused
=>
1 1 Reply
1 ordering
0 UnSorted
1 YSorted
2 YXSorted
3 YXBanded
2 CARD16 sequence number
4 2n reply length
4 CARD32 nrects
20 unused
8n LISTofRECTANGLE rectangles
Events
ShapeNotify
1 CARD8 type (0 + extension event base)
1 SHAPE_KIND shape kind
2 CARD16 sequence number
4 WINDOW affected window
2 INT16 x value of extents
2 INT16 y value of extents
2 CARD16 width of extents
2 CARD16 height of extents
4 TIMESTAMP server time
1 BOOL shaped
11 unused
Glossary
bounding region
The area of the parent window that this window will occupy. This area is
divided into two parts: the border and the interior.
clip region
The interior of the window, as a subset of the bounding region. This
region describes the area that will be painted with the window background
when the window is cleared, will contain all graphics output to the window,
and will clip any subwindows.
input region
The subset of the bounding region which can ``contain'' the
pointer.
default bounding region
The rectangular area, as described by the core protocol window size, that
covers the interior of the window and its border.
default clip region
The rectangular area, as described by the core protocol window size, that
covers the interior of the window and excludes the border.
default input region
The rectangular area, as described by the core protocol window size, that
covers the interior of the window and its border.
client bounding region
The region associated with a window that is directly modified via this
extension when specified by
ShapeBounding .
This region is used in conjunction with the default bounding region
to produce the effective bounding region.
client clip region
The region associated with a window that is directly modified via this
extension when specified by
ShapeClip .
This region is used in conjunction with the default clip region
and the client bounding region to produce the effective clip region.
client input region
The region associated with a window that is directly modified via this
extension when specified by
ShapeInput .
This region is used in conjunction with the default input region
and the client bounding region to produce the effective input region.
effective bounding region
The actual shape of the window on the screen, including border and interior
(but excluding the effects of overlapping windows). When a window has a client
bounding region, the effective bounding region is the intersection of the
default bounding region and the client bounding region. Otherwise, the
effective bounding region is the same as the default bounding region.
effective clip region
The actual shape of the interior of the window on the screen (excluding the
effects of overlapping windows). When a window has a client clip region or
a client bounding region, the effective clip region is the intersection of
the default clip region, the client clip region (if any) and the client
bounding region (if any). Otherwise, the effective clip region is the
same as the default clip region.
effective input region
The actual shape of the window on the screen (excluding the
effects of overlapping windows) which can ``contain'' the pointer.
When a window has a client input region or
a client bounding region, the effective input region is the intersection of
the default input region, the client input region (if any) and the client
bounding region (if any). Otherwise, the effective input region is the
same as the default input region.
xorgproto-2023.2/specs/xextproto/xtest.xml 0000644 0001750 0001750 00000046330 14443010026 015650 0000000 0000000
%defs;
]>
XTEST Extension Protocol
X Consortium Standard
Kieron Drake
UniSoft Ltd.
X Version 11, Release &fullrelvers;
Version 2.2
1992 UniSoft Group Ltd. 1992 1994 X Consortium
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.
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
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.
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.
Overview
This extension is a minimal set of client and server extensions
required to completely test the X11 server with no user intervention.
This extension is not intended to support general journaling and
playback of user actions. This is a difficult area [XTrap, 89] as it attempts
to synchronize synthetic user interactions with their effects; it is at the
higher level of dialogue recording/playback rather than at the strictly lexical
level. We are interested only in the latter, simpler, case. A more detailed
discussion and justification of the extension functionality is given in
[Drake, 91].
We are aiming only to provide a minimum set of facilities that
solve immediate testing and validation problems. The testing extension
itself needs testing, where possible, and so should be as simple as possible.
We have also tried to:
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.
Minimize the changes required in the rest of the server.
Minimize performance penalties on normal server operation.
Description
The functions provided by this extension fall into two groups:
Client Operations
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 "XTEST Extension Library", routines are
provided to access the internals of two opaque data structures
-- GC s
and
Visual s --
and to discard any requests pending within the
output buffer of a connection. The exact details can be expected to differ for
other language bindings.
Server Requests
The first of these requests is similar to that provided in most
extensions: it allows a client to specify a major and minor version
number to the server and for the server to respond with major and minor
versions of its own. The remaining two requests allow the following:
Access to an otherwise "write-only" server resource: the cursor
associated with a given window
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.
Types
The following types are used in the request and event definitions in
subsequent sections:
FAKE_EVENT_TYPE
{ KeyPress ,
KeyRelease ,
MotionNotify ,
ButtonPress ,
ButtonRelease }
FAKE_EVENT
[type: FAKE_EVENT_TYPE,
detail: BYTE,
time: TIME,
root: WINDOW,
rootX, rootY: INT16]
CURSOR { CurrentCursor , None }
or a cursor as defined by the X11 Protocol.
Client Operations
These are abstract definitions of functionality. They refer to client-side
objects such as "GC" and "VISUAL" that are quoted to
denote their abstract nature. Concrete versions of these functions are
defined only for particular language bindings. In some circumstances
a particular language binding may not implement the relevant abstract
type or may provide it as a transparent, rather than opaque, type, with
the result that the corresponding function does not make sense or is
not required, respectively.
XTestSetGContextOfGC
gc : "GC"
gid : GCONTEXT
Sets the GCONTEXT within the "GC" gc to have
the value specified by gid.
XTestSetVisualIDOfVisual
visual : "VISUAL"
visualid : VISUALID
Sets the VISUALID within the "VISUAL" visual to have
the value specified by visualid.
XTestDiscard
dpy : "CONNECTION"
=>
status: BOOL
Discards any requests that are present in the request buffer associated with
the "CONNECTION" dpy.
The status returned is
True
if there were one or more requests
in the buffer and
False
otherwise.
Server Requests
XTestGetVersion
clientMajorVersion : CARD16
clientMinorVersion : CARD16
=>
serverMajorVersion: CARD16
serverMinorVersion: CARD16
Errors: Length
This request can be used to ensure that the server version of the XTEST
extension is usable by the client. This document defines major version two
(2), minor version one (1).
XTestCompareCursor
window : WINDOW
cursor-id : CURSOR or
CurrentCursor
or
None
=>
same: BOOL
Errors:
Window ,
Length ,
Cursor
This request looks up the cursor associated with the window and
compares it with either the null cursor if cursor-id is
None ,
or the current cursor (that is, the one being displayed),
or the cursor whose ID is cursor-id, and returns
the result of the comparison in same.
XTestFakeInput
events : LISTofFAKE_EVENT
Errors:
Window ,
Length ,
Alloc ,
Value
This request simulates the limited set of core protocol
events within the set FAKE_EVENT_TYPE. Only the following event fields,
defined in FAKE_EVENT, are interpreted:
type
This must be one of
KeyPress ,
KeyRelease ,
MotionNotify ,
ButtonPress ,
or
ButtonRelease ,
or else a
Value
error occurs.
detail
For key events, this field is interpreted as the physical keycode.
If the keycode is less than min-keycode or greater than max-keycode,
as returned in the connection setup, then a
Value
error occurs.
For button events, this field is interpreted as the physical (or core) button,
meaning it will be mapped to the corresponding logical button according to
the most recent
SetPointerMapping
request.
If the button number is less than one or greater than the number of physical
buttons, then a
Value
error occurs.
For motion events, if this field is
True ,
then rootX and rootY
are relative distances from the current pointer location; if this field is
False,
then they are absolute positions.
time
This is either
CurrentTime
(meaning no delay)
or the delay in milliseconds that the server should wait before
simulating this event. No other requests from this client will be
processed until this delay, if any, has expired and subsequent processing
of the simulated event has been completed.
root
In the case of motion events this field is the ID of the root window on
which the new motion is to take place. If
None
is specified, the root window of the screen the pointer is currently on
is used instead.
If this field is not a valid window, then a
Window
error occurs.
rootX &
rootY
In the case of motion events these fields indicate relative distance or
absolute pointer coordinates, according to the setting of detail.
If the specified coordinates are off-screen, the closest on-screen
coordinates will be substituted.
When the simulated event(s) are processed, they cause event propagation,
passive grab activation, and so on, just as if the corresponding input device
action had occurred. However, motion events might not be recorded in the
motion history buffer.
For the currently supported event types, the event list must have length one,
otherwise a
BadLength
error occurs.
XTestGrabControl
impervious : BOOL
If impervious is
True ,
then the executing client becomes impervious to server grabs;
that is, it can continue executing requests even if another client
grabs the server.
If impervious is
False ,
then the executing client returns to the normal state of being
susceptible to server grabs.
Encoding
Please refer to the X11 Protocol Encoding document as this document uses
conventions established there.
The name of this extension is "XTEST".
New Types
FAKE_EVENT_TYPE
2 KeyPress
3 KeyRelease
4 ButtonPress
5 ButtonRelease
6 MotionNotify
NOTE that the above values are defined to be the same as those for
the corresponding core protocol event types.
Requests
XTestGetVersion
1 CARD8 opcode
1 0 xtest opcode
2 2 request length
1 CARD8 client major version
1 unused
2 CARD16 client minor version
=>
1 1 Reply
1 CARD8 server major version
2 CARD16 sequence number
4 0 reply length
2 CARD16 server minor version
22 unused
XTestCompareCursor
1 CARD8 opcode
1 1 xtest opcode
2 3 request length
4 WINDOW window
4 CURSOR cursor-id
0 None
1 CurrentCursor
=>
1 1 Reply
1 BOOL cursors are the same
2 CARD16 sequence number
4 0 reply length
24 unused
XTestFakeInput
1 CARD8 opcode
1 2 xtest opcode
2 1+(1*8) request length
1 FAKE_EVENT_TYPE fake device event type
1 BYTE detail: button or keycode
2 unused
4 TIME delay (milliseconds)
0 CurrentTime
4 WINDOW root window for MotionNotify
0 None
8 unused
2 INT16 x position for MotionNotify
2 INT16 y position for MotionNotify
8 unused
XTestGrabControl
References
Annicchiarico, D., et al.,
XTrap: The XTrap Architecture .
Digital Equipment Corporation, July 1991.
Drake, K. J.,
Some Proposals for a
Minimum X11 Testing Extension .
UniSoft Ltd., June 1991.
xorgproto-2023.2/specs/xextproto/Makefile.am 0000644 0001750 0001750 00000001051 14443010026 016002 0000000 0000000
if ENABLE_SPECS
# Main DocBook/XML files (DOCTYPE book)
docbook = \
appgrp.xml \
dbe.xml \
dpms.xml \
evi.xml \
geproto.xml \
lbx.xml \
multibuf.xml \
security.xml \
shape.xml \
shm.xml \
sync.xml \
tog-cup.xml \
xtest.xml
# Included chapters, appendix, images
chapters = appendix.xml
# The location where the DocBook/XML files and their generated formats are installed
shelfdir = $(datarootdir)/doc/xextproto
# Generate DocBook/XML output formats with or without stylesheets
include $(top_srcdir)/docbook.am
endif ENABLE_SPECS
xorgproto-2023.2/specs/xextproto/appgrp.xml 0000644 0001750 0001750 00000107667 14443010026 016005 0000000 0000000
%defs;
]>
Application Group Extension to the X Protocol
X Consortium Standard
Kaleb
S.
KEITHLEY
X Consortium, Inc kaleb@x.org
X Version 11, Release &fullrelvers;
Version 1.0
1996 X Consortium, Inc.
All Rights Reserved.
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 OF OR OTHER DEALINGS IN THE SOFTWARE.
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.
X Window System is a trademark of The OpenGroup.
27 September 1996
The Application Group Extension to the X protocol is intended to provide a framework to allow
more than one program to manage X applications on the desktop. The initial use of this extension
will be to insert or embed the windows of X programs into the windows of another program, such
as a web browser. This extension is not intended to address larger embedding issues that, for
example, OpenDoc does, such as shared menu bars, etc.
Purpose and Goals
The Application Group Extension to the X protocol is intended to provide
a framework to allow more than one program to manage X applications on
the desktop. The initial use of this extension will be to insert or embed
the windows of X programs into the windows of another program, such as a
web browser. This extension is not intended to address larger embedding
issues that, for example, OpenDoc does, such as shared menu bars, etc.
Using X programs on the World Wide Web allows for greater control of the
presentation and takes advantage of the existing body of X programs rather
than re-implement them in another language. In addition it allows the
embedding of non-X programs into web browsers by using third party products
like Wabi, MAE, and WinCenter.
Wabi is a trademark of Sun Microsystems, Inc. MAE is a trademark of Apple
Computer, Inc. WinCenter is a trademark of Network Computing Devices, Inc.
Overview of the protocol.
This extension introduces the concept of an Application Group. An Application Group is a set of one or more applications that are primarily managed by a special application known as the Application Group Leader, which, for example, might be a web browser. The primary purpose of Application Groups is to provide a means of sharing the Substructure-Redirect attribute of the root window between the window manager and one or more Application Group Leaders.
To join an Application Group an application must present the proper authorization during the connection setup. Authorizations are generated by the X server at the request of an Application Group Leader, and are then stored for the application to use to establish its connection to the X server. To generate an authorization the Application Group Leader sends a request to the server naming the Application Group to which the authorization will be bound, and any applications that connect using that authorization will automatically become part of the associated Application Group. The protocol to generate an authorization is defined in the Security Extension specification.
As a member of an Application Group, when an application creates and maps a window as a child of the root window, the MapRequest and ConfigureRequest events are delivered to the Application Group Leader instead of the window manager. The Application Group Leader may then reparent the window into its own window hierarchy; or reissue the map request, in which case the window comes under the control of the window manager.
Requests
AppGroupQueryVersion
client_major_version: CARD16
client_minor_version: CARD16
=>
server_major_version: CARD16
server_minor_version: CARD16
If supplied, the client_major_version and client_minor_version indicate what version of the protocol the application wants the server to implement. The server version numbers returned indicate the version of the protocol the X server actually supports. This may not match the versions requested by the application. An implementation may (but need not) support more than one version simultaneously. The server_major_version and server_minor_version numbers are a mechanism to support any future revisions of the Application Group extension protocol which may be necessary. In general, the major version would increment for incompatible changes, and the minor version would increment for small, upward-compatible changes. X servers that support the protocol defined in this document will return a server_major_version of 1 and a server_minor_version of 0.
AppGroupCreate
app_group: APPGROUP
value_mask: BITMASK
value_list: LISTofVALUE
This request creates an Application Group using app_group as the Application Group ID.
The value_mask and value_list specify attributes of the Application Group that are to be explicitly initialized. The attributes, their types, and the default values are:
Attribute
Type
Default
app_group_leader
Bool
True
single_screen
Bool
True
default_root
Window
None
root_visual
VisualID
None
default_colormap
Colormap
None
black_pixel
Pixel
0
white_pixel
Pixel
0
If the single_screen attribute is True then the number of video screens returned to a program in the Application Group in the connection setup message is one, irrespective of how many video screens the server actually has. If a server supports both video and print screens, then all print screens will always be returned. If single_screen is specified as True then the connection setup message will contain only the information about the video screen which has default_root as its root window, plus any print screens.
The intent is to allow an embedding manager to ensure that it will be able to reparent any top-level windows that Application Group members create. By hiding the fact that there are other screens it can be reasonably assured that applications will only create top-level windows on the same screen that it itself appears on. An embedding manager should take care not to supply an invalid display, e.g. :0.1, to a program that will be in an Application Group where the single_screen attribute is True.
If single_screen is set to True default_root specifies which screen will be returned as screen zero in the connection setup message for applications in the Application Group. If set to None, then the real screen zero is used, otherwise the screen which has default_root as its root window will be used.
If single_screen is set to True the root_visual and default_colormap attributes may be used to over-ride the default values that are returned in the connection setup information returned to new programs in the Application Group. If None is specified for root_visual or default_colormap then the normal default values for the screen (possibly specified by default_root) are used, otherwise the specified values are used. If root_visual and/or default_colormap are specified they must be valid, i.e. root_visual must be a visual type available on the screen, and the colormap, if specified, must be a valid colormap for the visual that is used.
IF single_screen is set to True and default_colormap is not specified as None, the black_pixel and white_pixel attributes must be specified, and they will over-ride the default values that are returned in the connection setup returned to new programs in the Application Group. If default_colormap is specified as None and black_pixel and/or white_pixel are specified, they will be ignored.
The app_group_leader attribute is used to identify the Application Group Leader program for the app_group. By specifying True the server will identify the program making the request as the Application Group Leader for the application group. The Application Group Leader receives MapRequest and ConfigureRequest events from the server when an attempt is made to map or configure top-level windows of a program in an Application Group, instead of being sent to a window manager that has selected SubstructureRedirect events on the root window. The parent window field in these events will contain the Application Group ID.
AppGroupDestroy app_group: APPGROUP
This request destroys the app_group. If the app_group_leader attribute for the app_group is True, then any applications in the Application Group that are still connected will be killed as if a KillClient request had been received for that application.
If the application that created a non-embedded Application Group exits, and therefore any Authorizations to be cancelled, and any applications that attempt to open new connections to the X server using one of those Authorizations will be unable to do so.
AppGroupGetAttr
>app_group: APPGROUP
=>
LISTofVALUE
This request returns the application group attributes for app_group.
AppGroupQuery
resource: XID
=>
app_group: APPGROUP
This request returns the Application Group ID of the application that created resource or None if that application is not associated with any Application Group. The resource value may be the resource base of the application.
AppGroupCreateAssociation
window: WINDOW
window_type: CARD32
system_window: LISTofCARD8
This request associates window with system_window. The window_type indicates the native window system of the application making the request. For non-X window_types both the embedding manager and the server must be executing on the same host. When system_window is Microsoft Windows or OS/2 Presentation Manager, the system_window is an HWND; when the native window system is Macintosh, the system_window is a WindowPtr and a Rect. The window may be used for any X request that takes a Window.
AppGroupDestroyAssociation
window: WINDOW
This request destroys the association created with AppGroupCreateAssociation. The window is destroyed. The system_window that was specified in the AppGroupCreateAssociation request is not affected.
Changes to Existing Requests
MapWindow
If the override-redirect attribute of the window is False and if the window is a child of a root window and if the window belongs to an application that is in an application group and if some other application is the application group leader for that group, then a MapRequest event is generated and the window remains unmapped. Otherwise, the core protocol semantics apply.
ConfigureWindow
If the override-redirect attribute of the window is False and if the window is a child of a root window and if the window belongs to an application that is in an application group and if some other application is the application group leader for that group, then a ConfigureRequest event is generated and the window remains unchanged. Otherwise, the core protocol semantics apply.
CreateWindow
When a program in an Application Group creates a window that is a child of a root window and specifies CopyFromParent for the Visual, if the single_screen attribute is True and the root_visual attribute is set to something other than None, then the window will be created using the Application Group’s root_visual, otherwise core protocol semantics apply.
When a program in an Application Group creates a window that is a child of a root window and specifies CopyFromParent for the Colormap, if the single_screen attribute is True, the default_colormap attribute is set to something other than None, and the window’s Visual is the same as the Application Group’s root_visual attribute, then the window will be created using the Application Group’s default_colormap, otherwise core protocol semantics apply.
ChangeWindowAttributes
When a program in an Application Group changes the attributes of a window that is a child of a root window and specifies CopyFromParent for the Colormap, if the single_screen attribute is True, the default_colormap attribute is set to something other than None, and the window’s Visual is the same as the Application Group’s root_visual attribute, then the window will be created using the Application Group’s default_colormap, otherwise core protocol semantics apply.
Changes to Existing Events
When the top-level window of an application that is a member of an Application Group is the target of a MapWindow or ConfigureWindow request, if there is an Application Group Leader then MapRequest and ConfigureRequest events are automatically delivered to it, otherwise the core protocol semantics apply, i.e. they are delivered to the client, if any, that has SubstructureRedirect set in its root-window event mask, e.g. the window manager.
The Application Group Leader must not select SubstructuRedirect events on a root window as doing so would result in a core protocol error; only one client is permitted to do so, and that is usually the window manager.
MapRequest
When a MapWindow request is received for a window whose override-redirect attribute is set to False and whose parent is the root window and the window belongs to an application that is in an application group and there is an application group leader for the group, then this event is delivered to the Application Group Leader with the parent field in the event set to the AppGroup ID. Otherwise the core protocol semantics apply.
ConfigureRequest
When a ConfigureWindow request is received for a window whose override-redirect attribute is set to False and whose parent is the root window and the window belongs to an application that is in an application group and there is an application group leader for the group, then this event is delivered to the Application Group Leader with the parent field in the event set to the AppGroup ID. Otherwise the core protocol semantics apply.
Errors
AppGroupQueryVersion
There are no errors for AppGroupQueryVersion.
AppGroupCreate
A Window error is returned if default_root is specified and is not a valid root window..
A Color error is returned default_colormap is specified but default_colormap is not a valid colormap for the screen of default_root.
A Match error is returned if root_visual and default_colormap are both specified, but
default_colormap’s visual is not root_visual.
A Match error is returned if root_visual does not exist for the screen of the default_root.
AppGroupDestroy
An AppGroup error is returned if app_group is not a valid Application Group.
An Access error is returned if an untrusted application attempts to destroy an Application Group created by a trusted application.
AppGroupGetAttr
An AppGroup error is returned if app_group is not a valid Application Group.
An Access error is returned if an untrusted application attempts to get the attributes of an Application Group created by a trusted application.
AppGroupQuery
An Access error is returned if an untrusted application attempts to query the Application Group of a trusted application.
AppGroupCreateAssociation
A Match error is returned if the X server does not support the window_type.
An Access error may be returned if the X server only supports the window_type on the local host and the program making the request is on a non-local host.
A Window error may be returned for system-specific errors related to system_window, e.g. system_window does not represent a valid native window.
AppGroupDestroyAssociation
A Window error is returned if window was not specified in a previous AppGroupCreateAssociation request.
Encoding
Please refer to the X11 Protocol encoding document as this document uses conventions established there.
The name of this extension is XC-APPGROUP
AppGroupQueryVersion
1 CARD8 opcode
1 0 XC-APPGROUP opcode
2 3 length
2 CARD16 client_major_version
2 CARD16 client_minor_version
=>
1 1 Reply
1 unused
2 CARD16 sequence_number
4 0 length
2 CARD16 server_major_version
2 CARD16 server_minor_version
20 unused
AppGroupCreate
1 CARD8 opcode
1 1 XC-APPGROUP opcode
2 8+n length
4 XID app_group
4 BITMASK attrib_mask
#x00000001 app_group_leader
#x00000002 single_screen
#0x0000004 default_root
#x00000008 root_visual
#x00000010 default_colormap
#x00000020 black_pixel
#x00000040 white_pixel
n LISTofVALUE value-list
VALUEs
4 BOOL app_group_leader
4 BOOL single_screen
4 WINDOW default_root
4 VISUALID root_visual
4 COLORMAP default_colormap
4 CARD32 black_pixel
4 CARD32 white_pixel
AppGroupDestroy
1 CARD8 opcode
1 2 XC-APPGROUP opcode
2 2 length
4 XID app_group
AAppGroupGetAttr
1 CARD8 opcode
1 4 XC-APPGROUP opcode
2 2 length
4 XID app_group
=>
1 1 Reply
1 unused
2 CARD16 sequence_number
4 0 length
4 WINDOW default_root
4 VISUALID root_visual
4 COLORMAP default_colormap
4 CARD32 black_pixel
4 CARD32 whte_pixel
1 BOOL single_screen
1 BOOL app_group_leader
2 unused
AppGroupQuery
1 CARD8 opcode
1 5 XC-APPGROUP opcode
2 2 length
4 XID resource
=>
1 1 Reply
1 unused
2 CARD16 sequence_number
4 0 length
4 XID app_group
20 unused
AppGroupCreateAssoc
1 CARD8 opcode
1 6 XC-APPGROUP opcode
2 n length
4 WINDOW window
2 CARD16 window_type
#0 X11
#1 Macintosh
#2 Win32, OS/2 PM 2.x
#3 Win16, OS/2 PM 1.x
2 n system_window_len
n LISTofCARD8 system_window
AppGroupDestroyAssoc
1 CARD8 opcode
1 7 XC-APPGROUP opcode
2 2 length
4 WINDOW window
Library API
Status XagQueryVersion ( xkb, keycode ) /* macro */
Display dpy ;
int * major_version_return ;
int * minor_version_return ;
XagQueryVersion sets major_version_return and minor_version_return to the major and minor Application Group protocol version supported by the server. If the Xag library is compatible with the version returned by the server it returns non-zero. If dpy does not support the Application Group extension, or if the server and library protocol versions are incompatible, or if there was an error during communication with the server, it returns zero. No other Xag functions may be called before this function. If a program violates this rule, the effects of all subsequent Xag calls that it makes are undefined.
An embedding manager in, e.g. a Personal Computer Web Browser, will need to open a connection to the Personal Computer X server by calling XOpenDisplay() before using the Application Group extension.
An embedding manager such as a web browser that intends to embed programs in an Application Group should create the Application Group with XagCreateEmbeddedApplicationGroup.
Status XagCreateEmbeddedApplicationGroup(
Display* dpy,
VisualID root_visual,
Colormap default_colormap,
unsigned long black_pixel,
unsigned long white_pixel,
XAppGroup* app_group_return);
XagCreateEmbeddedApplicationGroup creates an Application Group for an embedding manager with the attributes specified. It also sets the default_root attribute to DefaultRoot(dpy, DefaultsScreen(dpy)) and the single_screen and app_group_leader attributes to True. It returns the Application Group ID in app_group_return.
You can create an Application Group without intending to do embedding. One reason for doing this is to give a group of clients their own font-path.
A special font-path can be created by creating an Application Group, getting an Authorization using XSecurityGenerateAuthorization, and then running ‘xset fp+ <new font path>’ as a member of the Application Group. Font-path elements added in this way will be "private" to the Application Group.
Status XagCreateNonembeddedApplicationGroup(
Display* dpy,
XAppGroup* app_group_return);
An Application Group created with XagCreateNonembeddedApplicationGroup will have the default_root, root_visual, and default_colormap attributes all set to None; the single_screen and app_group_leader attributes are set to False, and the black_pixel and white_pixel attributes are not used since the default_colormap attribute is None.
To destroy an Application Group use XagDestroyApplicationGroup.
Status XagDestroyApplicationGroup(
Display* dpy,
XAppGroup app_group);
The Application Group specified by app_group is destroyed. If the Application Group was created using XagCreateEmbeddingApplicationGroup, i.e. and therefore the app_group_leader attribute is True, all programs that are members of the Application Group are killed as if a KillClient request had been issued.
To retrieve the attributes of an Application Group use XagGetApplicationGroupAttributes.
Status XagGetApplicationGroupAttributes(
Display* dpy,
XAppGroup app_group,
...);
XagGetApplicationGroupAttributes is a varargs function that retrieves the Application Group’s attributes specified in the vararg parameter list.
The attributes that may be specified are: XagNappGroupLeader, XagNsingleScreen, XagNdefaultRoot, XagNrootVisual, XagNdefaultColormap, XagNblackPixel, and XagNwhitePixel; which correspond to app_group_leader, single_screen, default_root, root_visual, default_colormap, black_pixel, and white_pixel respectively. See AppGroupCreate in Section 3 for a description of each attribute.
The types for each of the parameters are pointers to the following:
single_screen Bool
default_root Window
root_visual VisualID
default_colormap Colormap
black_pixel unsigned long
white_pixel unsigned long
app_group_leader Bool
Example:
...
Boolean app_group_leader, single_screen;
Window default_root;
VisualID root_visual;
Colormap default_colormap;
Pixel black_pixel, white_pixel;
...
status = XagGetApplicationGroupAttributes(dpy, app_group,
XagNappGroupLeader, &app_group_leader,
XagNsingleScreen, &single_screen,
XagNdefault_root, &default_root,
XagNrootVisual, &root_visual,
XagNdefaultColormap, &default_colormap,
XagNblackPixel, &black_pixel,
XagNwhitePixel, &white_pixel,
NULL);
...
To determine which Application Group a resource (such as a window) belongs to, use XagQueryApplicationGroup.
Status XagQueryApplicationGroup(
Display* dpy,
XID resource,
XAppGroup* app_group_return);
The Application Group is returned in app_group_return, if the resource is not in any Application Group then app_group_return will be set to None.
To associate an X Window ID with a system-specific window ID, such as a HWND or a WindowPtr, use XagCreateAssociation.
Status XagCreateAssociation(
Display* dpy,
Window* window_return,
void* system_window);
The window_ret may be used as the target for a ReparentWindow request.
Because XReparentWindow is not constrained in the same way that Win32’s SetParent and the Macintosh are, there is no reason to call XagCreateAssociation in an X-based embedding manager. As such if XagCreateAssociation is called in a native X program, the window_return will be the same as the system_window, and the implementation may even elect to not generate any protocol.
To create an association on the Macintosh:
struct {
WindowPtr win;
Rect rect;
} system_window;
system_window.win = win_ptr;
system_window.rect.top = system_window.rect.left = 20;
system_window.rect.bottom = 180;
system_window.rect.right = 380;
status = XagCreateAssociation (dpy, &window, (void*)&system_window);
To create an association using a Win16, Win32, or OS/2 PM:
HWND system_window;
status = XagCreateAssociation (dpy, &window, (void*)&system_window);
To destroy the association created with XagCreateAssociation use XagDestroyAssociation.
Status XagDestroyAssociation(
Display* dpy,
Window window);
After calling XagDestroyAssociation the window may no longer be used to
reparent windows with XReparentWindow.
Like XagCreateAssociation, if the native window system is X11 the implementation may elect to not generate any protocol as a result of this function call in order to avoid unintentionally destroying the the system_window that was specified in the prior XagCreateAssociation call.
xorgproto-2023.2/specs/xextproto/dpms.xml 0000644 0001750 0001750 00000052503 14443010026 015443 0000000 0000000
%defs;
]>
X Display Power Management Signaling (DPMS) Extension Protocol Specification
X Project Team Standard
Rob Lembree
Digital Equipment Corporation lembree@zk3.dec.com
X Version 11, Release &fullrelvers;
Version 1.0
1996 Digital Equipment Corporation
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. Digital Equipment Corporation
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.
Overview
This extension provides X Protocol control over the VESA Display
Power Management Signaling (DPMS) characteristics of video boards
under control of the X Window System.
X Window System is a trademark of The Open Group.
Traditionally, the X Window System has provided for both blanking and
non-blanking screen savers. Timeouts associated with these built-in
screen saver mechanisms are limited to idle (dwell) time, and a change
timeout that specifies the change interval for non-blanking screen savers.
The United States' Environmental Protection Agency (EPA) Energy Star program
requires that monitors power down after some idle time by default.
While it is possible to simply overload the existing screen saver timeouts,
this solution leaves the non-privileged user little to no control over
the DPMS characteristics of his or her system. For example, disabling
DPMS would require some unintended side effect in the core screen saver,
such as disabling the changing of a non-blanking screen saver. Providing
clients with this control requires an extension to the core X Window System
Protocol, and this extension seeks to fill this gap.
The design goal of the DPMS extension is to be a logical extension to
the traditional screen saver. The protocol and sample implementation is
designed to use the same date types and time units as the screen saver.
The sample implementation works independently from the screen saver so that
policy as it pertains to the interaction between screen saver and DPMS can
be deferred to the user or screen saver application. The extension has
been tested with and shown to work correctly with both the internal blanking
and non-blanking screen savers, as well as with screen saver extension
clients.
The DPMS extension is designed to be simple, yet export sufficient
VESA DPMS information to enable full function clients to be written.
Included is the ability to sense DPMS capability, set and get DPMS timeouts,
enable and disable individual DPMS modes, enable and disable DPMS (without
destroying timeout values), and sense current DPMS on/off state and
power level.
There are four power levels specified by the Video Electronics Standards
Association (VESA) Display Power Management Signaling (DPMS) standard.
These are:
DPMS Extension Power Levels
0 DPMSModeOn In use
1 DPMSModeStandby Blanked, low power
2 DPMSModeSuspend Blanked, lower power
3 DPMSModeOff Shut off, awaiting activity
It is logical to assume that successive DPMS modes be chronologically
at the same time or later than one another, and the protocol is designed
to enforce this rule.
Note however that a conscious decision is made to decouple the timeouts
associated with screen saver from the DPMS timeouts. While it might be
considered logical to require that the first non-zero DPMS timeout be
greater than or equal to the screen saver timeout, this is intentionally
omitted, leaving this policy decision to the user or the screen saver
application. In the case of a laptop where power may be scarce, the
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.
Requests
DPMSGetVersion
client_major_version : CARD16
client_minor_version : CARD16
=>
server_major_version : CARD16
server_minor_version : CARD16
If supplied, the client_major_version and
client_minor_version indicate what version
of the protocol the
client wants the server to implement. The server version numbers
returned indicate the protocol this extension actually supports. This
might not equal the version sent by the client. An implementation can
(but need not) support more than one version simultaneously. The
server_major_version and the
server_minor_version are a
mechanism to support future revisions of the Display Power Management
Signaling protocol which may be necessary. In general, the major version
would increment for incompatible changes, and the minor version would
increment for small, upward-compatible changes. Servers that support the
protocol defined in this document will return a
server_major_version
of one (1), and a server_minor_version
of two (2).
DPMSCapable
=>
capable : BOOL
This request is used to determine whether or not the currently running
server's devices are capable of DPMS operations. The truth value of this
request is implementation defined, but is generally based on the capabilities
of the graphic card and monitor combination. Also, the return value in the
case of heterogeneous multi-head servers is implementation defined.
DPMSGetTimeouts
=>
standby_timeout : CARD16
suspend_timeout : CARD16
off_timeout : CARD16
This request returns the current values of the DPMS timeout values. All
values are in units of seconds.
standby_timeout is the amount of time
of inactivity before standby
mode is invoked. The actual effects of this mode are implementation defined,
but in the case of DPMS compliant hardware, it is implemented by shutting off
the horizontal sync signal, and pulsing the vertical sync signal. Standby
mode provides the quickest monitor recovery time. Note also that many
monitors implement this mode identically to suspend mode. A value of
zero indicates that this mode is disabled.
suspend_timeout is the amount of time
of inactivity before the second
level of power savings is invoked. Suspend mode's physical and electrical
characteristics are implementation defined, but in DPMS compliant hardware,
results in the pulsing of the horizontal sync signal, and shutting off of
the vertical sync signal. Suspend mode recovery is considered to be slower
than standby mode, but faster than off mode, however this is monitor
dependent. As noted above, many monitors implement this mode identically to
standby mode. A value of zero indicates that this mode is disabled.
off_timeout is the amount of time of
inactivity before the third and
final level of power savings is invoked. Off mode's physical and electrical
characteristics are implementation defined, but in DPMS compliant hardware,
is implemented by shutting off both horizontal and vertical sync signals,
resulting in the power-down of the monitor. Recovery time is implementation
dependent, but frequently is similar to the power-up time of the monitor. A
value of zero indicates that this mode is disabled.
DPMSSetTimeouts
standby_timeout : CARD16
suspend_timeout : CARD16
off_timeout : CARD16
=>
All values are in units of seconds.
standby_timeout is the amount of
time of inactivity before standby mode will be invoked. This is the
lightest level of power savings, and the monitor is generally immediately
ready upon detection of user activity. This is most often implemented by
shutting off the horizontal sync signal to the monitor.
A value of zero disables this mode.
The suspend_timeout specifies the amount
of time of inactivity
before the screen is placed into suspend mode. Suspend mode is the
middle level of power savings, resulting in a slightly longer recovery
upon detection of activity. Suspend mode is most often implemented by
pulsing the horizontal sync signal, and removing the vertical sync
signal. A value of zero disables this mode.
The off_timeout specifies the amount of
time of inactivity before
the monitor is shut off. Off mode is the deepest level of power management,
resulting in the greatest power savings and the longest recovery time.
Off mode is most often implemented by removing both the horizontal and
vertical signals. A value of zero disables this mode.
The values of successive power levels must be greater than or equal
to the value of the previous (non-zero) level. A BadValue error is generated
if an illegal combination is detected.
DPMSEnable
=>
This request enables the DPMS characteristics of the server, using the
server's currently stored timeouts. If DPMS is already enabled, no change is
effected.
DPMSDisable
=>
This request disables the DPMS characteristics of the server. It does
not affect the core or extension screen savers. If DPMS is already
disabled, no change is effected. This request is provided so that DPMS
may be disabled without damaging the server's stored timeout values.
DPMSForceLevel
power_level : CARD16
=>
This request forces a specific DPMS level on the server. If DPMS is
disabled, a BadMatch error is generated. If an erroneous power level
is specified, a BadValue error is returned, and the error value contains
the bad value. If the power level specified is already in effect, no
changes occur. Power Level must be one of DPMSModeOn, DPMSModeStandby,
DPMSModeSuspend or DPMSModeOff.
DPMSInfo
=>
power_level : CARD16
state : BOOL
This request returns information about the current DPMS state of the
display. state is one of DPMSEnabled
or DPMSDisabled.
If state is DPMSEnabled,
power_level is returned as one
of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend or DPMSModeOff, otherwise
it is undefined.
DPMSSelectInput
event_mask : CARD32
=>
This request specifies whether DPMS extension events should be generated for this client.
If DPMSInfoNotifyMask is set in event-mask , then DPMSInfoNotifyEvent
events will be generated whenever the current DPMS on/off state or power level changes.
If no bits are set, then no events will be generated.
Events
The DPMS extension adds one event:
DPMSInfoNotifyEvent
timestamp : TIMESTAMP
power_level : CARD16
state : BOOL
This event is delivered to clients that have requested
DPMSInfoNotifyMask events using the DPMSSelectInput request
whenever the current DPMS on/off state or power level changes.
state is one of DPMSEnabled or DPMSDisabled.
If state is DPMSEnabled,
power_level is one
of DPMSModeOn, DPMSModeStandby, DPMSModeSuspend or DPMSModeOff, otherwise
it is undefined.
Encoding
Please refer to the X11 Protocol Encoding document as this document uses
conventions established there.
The name of this extension is "DPMS".
DPMSGetVersion
DPMSCapable
DPMSGetTimeouts
DPMSSetTimeouts
DPMSEnable
DPMSDisable
DPMSForceLevel
DPMSInfo
DPMSSelectInput
DPMSInfoNotifyEvent
xorgproto-2023.2/specs/xextproto/Makefile.in 0000644 0001750 0001750 00000056625 14443010031 016030 0000000 0000000 # Makefile.in generated by automake 1.16.5 from Makefile.am.
# @configure_input@
# Copyright (C) 1994-2021 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
@SET_MAKE@
#
# Generate output formats for a single DocBook/XML with/without chapters
#
# Variables set by the calling Makefile:
# shelfdir: the location where the docs/specs are installed. Typically $(docdir)
# docbook: the main DocBook/XML file, no chapters, appendix or image files
# chapters: all files pulled in by an XInclude statement and images.
#
#
# This makefile is intended for Users Documentation and Functional Specifications.
# Do not use for Developer Documentation which is not installed and does not require olink.
# Refer to http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html#id2584393
# for an explanation on documents classification.
#
VPATH = @srcdir@
am__is_gnu_make = { \
if test -z '$(MAKELEVEL)'; then \
false; \
elif test -n '$(MAKE_HOST)'; then \
true; \
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
else \
false; \
fi; \
}
am__make_running_with_option = \
case $${target_option-} in \
?) ;; \
*) echo "am__make_running_with_option: internal error: invalid" \
"target option '$${target_option-}' specified" >&2; \
exit 1;; \
esac; \
has_opt=no; \
sane_makeflags=$$MAKEFLAGS; \
if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
else \
case $$MAKEFLAGS in \
*\\[\ \ ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
esac; \
fi; \
skip_next=no; \
strip_trailopt () \
{ \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
}; \
for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
*=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
-*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
-*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
-*l?*) strip_trailopt 'l';; \
-[dEDm]) skip_next=yes;; \
-[JT]) skip_next=yes;; \
esac; \
case $$flg in \
*$$target_option*) has_opt=yes; break;; \
esac; \
done; \
test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_1 = $(docbook:.xml=.html)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@am__append_2 = $(docbook:.xml=.txt)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_3 = $(docbook:.xml=.pdf) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(docbook:.xml=.ps)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@am__append_4 = $(docbook:.xml=.html.db) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(docbook:.xml=.pdf.db)
subdir = specs/xextproto
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(am__dist_shelf_DATA_DIST) \
$(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
AM_V_P = $(am__v_P_@AM_V@)
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
am__v_P_0 = false
am__v_P_1 = :
AM_V_GEN = $(am__v_GEN_@AM_V@)
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
am__v_GEN_0 = @echo " GEN " $@;
am__v_GEN_1 =
AM_V_at = $(am__v_at_@AM_V@)
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
am__v_at_0 = @
am__v_at_1 =
SOURCES =
DIST_SOURCES =
am__can_run_installinfo = \
case $$AM_UPDATE_INFO_DIR in \
n|no|NO) false;; \
*) (install-info --version) >/dev/null 2>&1;; \
esac
am__dist_shelf_DATA_DIST = appgrp.xml dbe.xml dpms.xml evi.xml \
geproto.xml lbx.xml multibuf.xml security.xml shape.xml \
shm.xml sync.xml tog-cup.xml xtest.xml appendix.xml
am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
am__vpath_adj = case $$p in \
$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
*) f=$$p;; \
esac;
am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
am__install_max = 40
am__nobase_strip_setup = \
srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
am__nobase_strip = \
for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
am__nobase_list = $(am__nobase_strip_setup); \
for p in $$list; do echo "$$p $$p"; done | \
sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
$(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
if (++n[$$2] == $(am__install_max)) \
{ print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
END { for (dir in files) print dir, files[dir] }'
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
am__uninstall_files_from_dir = { \
test -z "$$files" \
|| { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
|| { echo " ( cd '$$dir' && rm -f" $$files ")"; \
$(am__cd) "$$dir" && rm -f $$files; }; \
}
am__installdirs = "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"
DATA = $(dist_shelf_DATA) $(shelf_DATA)
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
am__DIST_COMMON = $(srcdir)/Makefile.in $(top_srcdir)/docbook.am
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
ADMIN_MAN_DIR = @ADMIN_MAN_DIR@
ADMIN_MAN_SUFFIX = @ADMIN_MAN_SUFFIX@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
APP_MAN_DIR = @APP_MAN_DIR@
APP_MAN_SUFFIX = @APP_MAN_SUFFIX@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BASE_CFLAGS = @BASE_CFLAGS@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CHANGELOG_CMD = @CHANGELOG_CMD@
CPPFLAGS = @CPPFLAGS@
CSCOPE = @CSCOPE@
CTAGS = @CTAGS@
CWARNFLAGS = @CWARNFLAGS@
CYGPATH_W = @CYGPATH_W@
DEFS = @DEFS@
DEPDIR = @DEPDIR@
DRIVER_MAN_DIR = @DRIVER_MAN_DIR@
DRIVER_MAN_SUFFIX = @DRIVER_MAN_SUFFIX@
ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
ETAGS = @ETAGS@
EXEEXT = @EXEEXT@
FILE_MAN_DIR = @FILE_MAN_DIR@
FILE_MAN_SUFFIX = @FILE_MAN_SUFFIX@
FOP = @FOP@
INSTALL = @INSTALL@
INSTALL_CMD = @INSTALL_CMD@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIB_MAN_DIR = @LIB_MAN_DIR@
LIB_MAN_SUFFIX = @LIB_MAN_SUFFIX@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAN_SUBSTS = @MAN_SUBSTS@
MISC_MAN_DIR = @MISC_MAN_DIR@
MISC_MAN_SUFFIX = @MISC_MAN_SUFFIX@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
PKG_CONFIG = @PKG_CONFIG@
PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
PYTHON = @PYTHON@
PYTHON_EXEC_PREFIX = @PYTHON_EXEC_PREFIX@
PYTHON_PLATFORM = @PYTHON_PLATFORM@
PYTHON_PREFIX = @PYTHON_PREFIX@
PYTHON_VERSION = @PYTHON_VERSION@
SED = @SED@
SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
STRICT_CFLAGS = @STRICT_CFLAGS@
STRIP = @STRIP@
STYLESHEET_SRCDIR = @STYLESHEET_SRCDIR@
USE_FDS_BITS = @USE_FDS_BITS@
VERSION = @VERSION@
XMLTO = @XMLTO@
XORG_MAN_PAGE = @XORG_MAN_PAGE@
XORG_SGML_PATH = @XORG_SGML_PATH@
XSLTPROC = @XSLTPROC@
XSL_STYLESHEET = @XSL_STYLESHEET@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build = @build@
build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
pkgpyexecdir = @pkgpyexecdir@
pkgpythondir = @pkgpythondir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
pyexecdir = @pyexecdir@
pythondir = @pythondir@
runstatedir = @runstatedir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
# Main DocBook/XML files (DOCTYPE book)
@ENABLE_SPECS_TRUE@docbook = \
@ENABLE_SPECS_TRUE@ appgrp.xml \
@ENABLE_SPECS_TRUE@ dbe.xml \
@ENABLE_SPECS_TRUE@ dpms.xml \
@ENABLE_SPECS_TRUE@ evi.xml \
@ENABLE_SPECS_TRUE@ geproto.xml \
@ENABLE_SPECS_TRUE@ lbx.xml \
@ENABLE_SPECS_TRUE@ multibuf.xml \
@ENABLE_SPECS_TRUE@ security.xml \
@ENABLE_SPECS_TRUE@ shape.xml \
@ENABLE_SPECS_TRUE@ shm.xml \
@ENABLE_SPECS_TRUE@ sync.xml \
@ENABLE_SPECS_TRUE@ tog-cup.xml \
@ENABLE_SPECS_TRUE@ xtest.xml
# Included chapters, appendix, images
@ENABLE_SPECS_TRUE@chapters = appendix.xml
# The location where the DocBook/XML files and their generated formats are installed
@ENABLE_SPECS_TRUE@shelfdir = $(datarootdir)/doc/xextproto
# DocBook/XML generated output formats to be installed
@ENABLE_SPECS_TRUE@shelf_DATA = $(am__append_1) $(am__append_2) \
@ENABLE_SPECS_TRUE@ $(am__append_3) $(am__append_4)
# DocBook/XML file with chapters, appendix and images it includes
@ENABLE_SPECS_TRUE@dist_shelf_DATA = $(docbook) $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_OLINK_FLAGS)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_PDF_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_IMAGEPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_PDF_OLINK_FLAGS)
# Generate documents cross-reference target databases
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam targets.filename "$@" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam collect.xref.targets "only" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam olink.base.uri "$(@:.db=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_PDF_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@CLEANFILES = $(shelf_DATA)
all: all-am
.SUFFIXES:
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/docbook.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign specs/xextproto/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign specs/xextproto/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
*config.status*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
*) \
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \
esac;
$(top_srcdir)/docbook.am $(am__empty):
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(top_srcdir)/configure: $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
install-dist_shelfDATA: $(dist_shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-dist_shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
install-shelfDATA: $(shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
tags TAGS:
ctags CTAGS:
cscope cscopelist:
distdir: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) distdir-am
distdir-am: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
all-am: Makefile $(DATA)
installdirs:
for dir in "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"; do \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-am
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
mostlyclean-generic:
clean-generic:
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
clean: clean-am
clean-am: clean-generic mostlyclean-am
distclean: distclean-am
-rm -f Makefile
distclean-am: clean-am distclean-generic
dvi: dvi-am
dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am: install-dist_shelfDATA install-shelfDATA
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
-rm -f Makefile
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-generic
pdf: pdf-am
pdf-am:
ps: ps-am
ps-am:
uninstall-am: uninstall-dist_shelfDATA uninstall-shelfDATA
.MAKE: install-am install-strip
.PHONY: all all-am check check-am clean clean-generic cscopelist-am \
ctags-am distclean distclean-generic distdir dvi dvi-am html \
html-am info info-am install install-am install-data \
install-data-am install-dist_shelfDATA install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-shelfDATA install-strip installcheck installcheck-am \
installdirs maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-generic pdf pdf-am ps ps-am tags-am \
uninstall uninstall-am uninstall-dist_shelfDATA \
uninstall-shelfDATA
.PRECIOUS: Makefile
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.html: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@%.txt: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.pdf: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.ps: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.html.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_HTML_FLAGS) $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.pdf.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_PDF_FLAGS) $<
# Generate DocBook/XML output formats with or without stylesheets
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
xorgproto-2023.2/specs/xextproto/evi.xml 0000644 0001750 0001750 00000034271 14443010026 015265 0000000 0000000
%defs;
]>
Extended Visual Information Extension
X Project Team Standard
Peter Daifuku
Silicon Graphics, Inc.
X Version 11, Release &fullrelvers;
Version 1.0
1986-1997 The Open Group
Permission is hereby granted, free of charge, to any person obtaining a
copy of this
software and associated documentation files (the Software), to use the
Software without restriction, including, without limitation, the rights to
copy, modify, merge, publish, distribute and sublicense the Software,
to make, have made, license and distribute derivative works thereof, and
to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and the following permission notice shall be
included in all copies of the Software:
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-
INFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER USEABILITIY, WHETHER IN AN ACTION OF
CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF, OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OF OTHER DEALINGS IN
THE SOFTWARE.
Except as contained in this notice, the name of The Open Group shall not
be used in advertising or otherwise to promote the use or other dealings
in this Software without prior written authorization from The Open Group.
X Window System is a trademark of The Open Group.
Introduction
EVI (Extended Visual Information extension) allows a client to determine
information about core X visuals beyond what the core protocol provides.
Goals
As the X Window System has evolved, it has become clear that the information
returned by the core X protocol regarding Visuals is often insufficient for a
client to determine which is the most appropriate visual for its needs. This
extension allows clients to query the X server for additional visual
information, specifically as regards colormaps and framebuffer levels.
This extension is meant to address the needs of pure X clients only. It is
specifically and purposefully not designed to address the needs of X
extensions. Extensions that have an impact on visual information should provide
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.
Requests
GetVersion
client_major_version : CARD8
client_minor_version : CARD8
=>
server_major_version : CARD8
server_minor_version : CARD8
If supplied, the client_major_version and client_minor_version indicate
what version of the protocol the client wants the server to implement.
The server version numbers returned indicate the protocol this extension
actually supports. This might not equal the version sent by the client.
An implementation can (but need not) support more than one version
simultaneously. The server_major_version and the server_minor_version
are a mechanism to support future revisions of the EVI protocol that
may be necessary. In general, the major version would increment for
incompatible changes, and the minor version would increment for small
upward-compatible changes. Servers that support the protocol defined in
this document will return a server_major_version of one (1), and a
server_minor_version of zero (0).
GetVisualInfo
visual_list : LISTofVISUALID
=>
per_visual_info : LISTofVISUALINFO
where:
VISUALINFO: [core_visual_id: VISUALID
screen: CARD8
level: INT8
transparency_type: CARD8
unused: CARD8
transparency_value: CARD32
min_hw_colormaps: CARD8
max_hw_colormaps: CARD8
num_colormap_conflicts: CARD16
colormap_conflicts: LISTofVISUALID]
level is 0 for normal planes, > 0 for overlays, < 0 for underlays.
transparency_type is 0 for none, 1 for transparent pixel, 2 for
transparent mask.
transparency_value: value to get transparent pixel if transparency
supported.
min_hw_colormaps: minimum number of hardware colormaps backing up the
visual.
max_hw_colormaps: maximum number of hardware colormaps backing up the
visual.
(architectures with static colormap allocation/reallocation would have min
= max)
num_colormap_conflicts: number of elements in colormap_conflicts.
colormap_conflicts: list of visuals that may conflict with this one. For
example, if a 12-bit colormap is overloaded to support 8-bit visuals, the
8-bit visuals would conflict with the 12-bit visuals.
Events and Errors
No new events or errors are defined by this extension.
Changes to existing protocol.
None.
Encoding
The name of this extension is "Extended-Visual-Information".
The conventions used here are the same as those for the core X11
Protocol Encoding.
GetVersion
1 CARD8 opcode
1 0 EVI opcode
2 2 request length
2 CARD16 client_major_version
2 CARD16 client_minor_version
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 0 length
2 CARD16 server_major_version
2 CARD16 server_minor_version
20 unused
GetVisualInfo
1 CARD8 opcode
1 1 EVI opcode
2 2+n request length
4 CARD32 n_visual
4n CARD32 visual_ids
=>
1 1 reply
1 unused
2 CARD16 sequence number
4 n length
4 CARD32 n_info
4 CARD32 n_conflicts
16 unused
16n LISTofVISUALINFO items
VISUALINFO
4 VisualID core_visual_id
1 INT8 screen
1 INT8 level
1 CARD8 transparency_type
1 CARD8 unused
4 CARD32 transparency_value
1 CARD8 min_hw_colormaps
1 CARD8 max_hw_colormaps
2 CARD16 num_colormap_conflicts
C Language Binding
The C functions provide direct access to the protocol and add no additional
semantics. For complete details on the effects of these functions, refer
to the appropriate protocol request, which can be derived by deleting Xevi
at the start of the function. All functions that have return type Status
will return nonzero for success and zero for failure.
The include file for this extension is:
< X11/extensions/XEVI.h> .
Bool XeviQueryVersion
Display *display
int *major_version_return
int *minor_version_return
display
Specifies the connection to the X server.
major_version_return
Returns the major version supported by the server.
minor_version_return
Returns the minor version supported by the server.
XeviQueryVersion sets major_version_return and minor_version_return to
the major and minor EVI protocol version supported by the server. If
the EVI library is compatible with the version returned by the server,
it returns nonzero. If dpy does not support the EVI extension, or if
there was an error during communication with the server, or if the server
and library protocol versions are incompatible, it returns zero. No other
Xevi functions may be called before this function. If a client violates
this rule, the effects of all subsequent Xevi calls that it makes are
undefined.
To get the extended information for any subset of visuals use
XeviGetVisualInfo.
int XeviGetVisualInfo
Display *display
VisualID *visual
int n_visual
ExtendedVisualInfo **evi_return
int *n_info_return
display
Specifies the connection to the X server.
visual
If NULL, then information for all visuals of all
screens is returned. Otherwise, a pointer to a list of visuals for which
extended visual information is desired.
n_visual
If 0, then information for all visuals of all screens is returned. Otherwise,
the number of elements in the array visual .
evi_return
Returns a pointer to a list of ExtendedVisualInfo . When done, the client
should free the list using XFree .
n_info_return
Returns the number of elements in the list of
ExtendedVisualInfo .
XeviGetVisualInfo returns a list of ExtendedVisualInfo structures that describe
visual information beyond that supported by the core protocol. This includes
layer information relevant for systems supporting overlays and/or underlay
planes, and information that allows applications better to determine the level
of hardware support for multiple colormaps. XeviGetVisualInfo returns Success
if successful, or an X error otherwise.
xorgproto-2023.2/specs/xcmiscproto/ 0000755 0001750 0001750 00000000000 14443010036 014330 5 0000000 0000000 xorgproto-2023.2/specs/xcmiscproto/xc-misc.xml 0000644 0001750 0001750 00000020304 14443010026 016333 0000000 0000000
%defs;
]>
XC-MISC Extension
X Consortium Standard
Bob Scheifler
X Consortium
David P. Wiggins
X Consortium
X Version 11, Release &fullrelvers;
Version 1.1
1994 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 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.
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.
X Window System is a trademark of The Open Group.
Overview
When an X client connects to an X server, it receives a fixed range of
resource IDs to use to identify the client's resources inside the X
server. Xlib hands these out sequentially as needed. When it
overruns the end of the range, an IDChoice protocol error results.
Long running clients, or clients that use resource IDs at a rapid
rate, may encounter this circumstance. When it happens, there are
usually many resource IDs available, but Xlib doesn't know about them.
One approach to solving this problem would be to have Xlib notice when
a resource is freed and recycle its ID for future use. This strategy
runs into difficulties because sometimes freeing one resource causes
others to be freed (for example, when a window is destroyed, so are
its children). To do a complete job, Xlib would have to maintain a
large amount of state that currently resides only in the server (the
entire window tree in the above example). Even if a less
comprehensive strategy was adopted, such as recycling only those IDs
that Xlib can identify without maintaining additional state, the
additional bookkeeping at resource creation and destruction time
would likely introduce unacceptable overhead.
To avoid the problems listed above, the server's complete knowledge of
all resource IDs in use by a client is leveraged. This extension
provides two ways for Xlib to query the server for available resource
IDs. Xlib can use these extension requests behind the scenes when it has
exhausted its current pool of resource IDs.
Requests
XCMiscGetVersion
client_major_version : CARD16client_minor_version : CARD16
=>
client_major_version : CARD16client_minor_version : CARD16
If supplied, the client_major_version and
client_minor_version indicate what version of
the protocol the client wants the server to implement. The server version
numbers returned indicate the protocol this extension actually supports. This
might not equal the version sent by the client. An implementation can
(but need not) support more than one version simultaneously. The
server_major_version and the server_minor_version are a
mechanism to support future revisions of the XC-MISC protocol
which may be necessary. In general, the major version would increment
for incompatible changes, and the minor version would increment for
small, upward-compatible changes. Servers that support the protocol
defined in this document will return a
server_major_version of one (1), and a
server_minor_version of one (1).
XCMiscGetXIDRange =>
start_id : XIDcount : CARD32
This request returns a range of available resource IDs for the client
issuing the request. start_id is the first
ID in the range. count is the number of IDs
in the range. The returned range may or may not be the largest possible
range.
XCMiscGetXIDList
count : CARD32
=>
ids : LISTofXID
This request returns the a list of individual resource IDs in
ids .
count is the number of resource IDs requested.
The number returned may be smaller than the number requested.
Events and Errors
No new events or errors are defined by this extension.
Encoding
Please refer to the X11 Protocol Encoding document as this document uses
conventions established there.
The name of this extension is “XC-MISC”.
XCMiscGetVersion
1 CARD8 opcode
1 0 XC-MISC opcode
2 2 request length
2 CARD16 client_major_version
2 CARD16 client_minor_version
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 length
2 CARD16 server_major_version
2 CARD16 server_minor_version
20 unused
XCMiscGetXIDRange
1 CARD8 opcode
1 1 XC-MISC opcode
2 1 request length
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 length
4 XID start_id
4 CARD32 count
16 unused
XCMiscGetXIDList
1 CARD8 opcode
1 2 XC-MISC opcode
2 2 request length
4 CARD32 count
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 CARD32 length
4 CARD32 number of XIDs in ids
20 unused
4n LISTofXID ids
xorgproto-2023.2/specs/xcmiscproto/Makefile.am 0000644 0001750 0001750 00000000510 14443010026 016277 0000000 0000000
if ENABLE_SPECS
# Main DocBook/XML files (DOCTYPE book)
docbook = xc-misc.xml
# The location where the DocBook/XML files and their generated formats are installed
shelfdir = $(datarootdir)/doc/xcmiscproto
# Generate DocBook/XML output formats with or without stylesheets
include $(top_srcdir)/docbook.am
endif ENABLE_SPECS
xorgproto-2023.2/specs/xcmiscproto/Makefile.in 0000644 0001750 0001750 00000055447 14443010031 016327 0000000 0000000 # Makefile.in generated by automake 1.16.5 from Makefile.am.
# @configure_input@
# Copyright (C) 1994-2021 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
@SET_MAKE@
#
# Generate output formats for a single DocBook/XML with/without chapters
#
# Variables set by the calling Makefile:
# shelfdir: the location where the docs/specs are installed. Typically $(docdir)
# docbook: the main DocBook/XML file, no chapters, appendix or image files
# chapters: all files pulled in by an XInclude statement and images.
#
#
# This makefile is intended for Users Documentation and Functional Specifications.
# Do not use for Developer Documentation which is not installed and does not require olink.
# Refer to http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html#id2584393
# for an explanation on documents classification.
#
VPATH = @srcdir@
am__is_gnu_make = { \
if test -z '$(MAKELEVEL)'; then \
false; \
elif test -n '$(MAKE_HOST)'; then \
true; \
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
else \
false; \
fi; \
}
am__make_running_with_option = \
case $${target_option-} in \
?) ;; \
*) echo "am__make_running_with_option: internal error: invalid" \
"target option '$${target_option-}' specified" >&2; \
exit 1;; \
esac; \
has_opt=no; \
sane_makeflags=$$MAKEFLAGS; \
if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
else \
case $$MAKEFLAGS in \
*\\[\ \ ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
esac; \
fi; \
skip_next=no; \
strip_trailopt () \
{ \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
}; \
for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
*=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
-*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
-*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
-*l?*) strip_trailopt 'l';; \
-[dEDm]) skip_next=yes;; \
-[JT]) skip_next=yes;; \
esac; \
case $$flg in \
*$$target_option*) has_opt=yes; break;; \
esac; \
done; \
test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_1 = $(docbook:.xml=.html)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@am__append_2 = $(docbook:.xml=.txt)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_3 = $(docbook:.xml=.pdf) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(docbook:.xml=.ps)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@am__append_4 = $(docbook:.xml=.html.db) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(docbook:.xml=.pdf.db)
subdir = specs/xcmiscproto
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(am__dist_shelf_DATA_DIST) \
$(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
AM_V_P = $(am__v_P_@AM_V@)
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
am__v_P_0 = false
am__v_P_1 = :
AM_V_GEN = $(am__v_GEN_@AM_V@)
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
am__v_GEN_0 = @echo " GEN " $@;
am__v_GEN_1 =
AM_V_at = $(am__v_at_@AM_V@)
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
am__v_at_0 = @
am__v_at_1 =
SOURCES =
DIST_SOURCES =
am__can_run_installinfo = \
case $$AM_UPDATE_INFO_DIR in \
n|no|NO) false;; \
*) (install-info --version) >/dev/null 2>&1;; \
esac
am__dist_shelf_DATA_DIST = xc-misc.xml
am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
am__vpath_adj = case $$p in \
$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
*) f=$$p;; \
esac;
am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
am__install_max = 40
am__nobase_strip_setup = \
srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
am__nobase_strip = \
for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
am__nobase_list = $(am__nobase_strip_setup); \
for p in $$list; do echo "$$p $$p"; done | \
sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
$(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
if (++n[$$2] == $(am__install_max)) \
{ print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
END { for (dir in files) print dir, files[dir] }'
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
am__uninstall_files_from_dir = { \
test -z "$$files" \
|| { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
|| { echo " ( cd '$$dir' && rm -f" $$files ")"; \
$(am__cd) "$$dir" && rm -f $$files; }; \
}
am__installdirs = "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"
DATA = $(dist_shelf_DATA) $(shelf_DATA)
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
am__DIST_COMMON = $(srcdir)/Makefile.in $(top_srcdir)/docbook.am
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
ADMIN_MAN_DIR = @ADMIN_MAN_DIR@
ADMIN_MAN_SUFFIX = @ADMIN_MAN_SUFFIX@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
APP_MAN_DIR = @APP_MAN_DIR@
APP_MAN_SUFFIX = @APP_MAN_SUFFIX@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BASE_CFLAGS = @BASE_CFLAGS@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CHANGELOG_CMD = @CHANGELOG_CMD@
CPPFLAGS = @CPPFLAGS@
CSCOPE = @CSCOPE@
CTAGS = @CTAGS@
CWARNFLAGS = @CWARNFLAGS@
CYGPATH_W = @CYGPATH_W@
DEFS = @DEFS@
DEPDIR = @DEPDIR@
DRIVER_MAN_DIR = @DRIVER_MAN_DIR@
DRIVER_MAN_SUFFIX = @DRIVER_MAN_SUFFIX@
ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
ETAGS = @ETAGS@
EXEEXT = @EXEEXT@
FILE_MAN_DIR = @FILE_MAN_DIR@
FILE_MAN_SUFFIX = @FILE_MAN_SUFFIX@
FOP = @FOP@
INSTALL = @INSTALL@
INSTALL_CMD = @INSTALL_CMD@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIB_MAN_DIR = @LIB_MAN_DIR@
LIB_MAN_SUFFIX = @LIB_MAN_SUFFIX@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAN_SUBSTS = @MAN_SUBSTS@
MISC_MAN_DIR = @MISC_MAN_DIR@
MISC_MAN_SUFFIX = @MISC_MAN_SUFFIX@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
PKG_CONFIG = @PKG_CONFIG@
PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
PYTHON = @PYTHON@
PYTHON_EXEC_PREFIX = @PYTHON_EXEC_PREFIX@
PYTHON_PLATFORM = @PYTHON_PLATFORM@
PYTHON_PREFIX = @PYTHON_PREFIX@
PYTHON_VERSION = @PYTHON_VERSION@
SED = @SED@
SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
STRICT_CFLAGS = @STRICT_CFLAGS@
STRIP = @STRIP@
STYLESHEET_SRCDIR = @STYLESHEET_SRCDIR@
USE_FDS_BITS = @USE_FDS_BITS@
VERSION = @VERSION@
XMLTO = @XMLTO@
XORG_MAN_PAGE = @XORG_MAN_PAGE@
XORG_SGML_PATH = @XORG_SGML_PATH@
XSLTPROC = @XSLTPROC@
XSL_STYLESHEET = @XSL_STYLESHEET@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build = @build@
build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
pkgpyexecdir = @pkgpyexecdir@
pkgpythondir = @pkgpythondir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
pyexecdir = @pyexecdir@
pythondir = @pythondir@
runstatedir = @runstatedir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
# Main DocBook/XML files (DOCTYPE book)
@ENABLE_SPECS_TRUE@docbook = xc-misc.xml
# The location where the DocBook/XML files and their generated formats are installed
@ENABLE_SPECS_TRUE@shelfdir = $(datarootdir)/doc/xcmiscproto
# DocBook/XML generated output formats to be installed
@ENABLE_SPECS_TRUE@shelf_DATA = $(am__append_1) $(am__append_2) \
@ENABLE_SPECS_TRUE@ $(am__append_3) $(am__append_4)
# DocBook/XML file with chapters, appendix and images it includes
@ENABLE_SPECS_TRUE@dist_shelf_DATA = $(docbook) $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_OLINK_FLAGS)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_PDF_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_IMAGEPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_PDF_OLINK_FLAGS)
# Generate documents cross-reference target databases
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam targets.filename "$@" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam collect.xref.targets "only" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam olink.base.uri "$(@:.db=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_PDF_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@CLEANFILES = $(shelf_DATA)
all: all-am
.SUFFIXES:
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/docbook.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign specs/xcmiscproto/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign specs/xcmiscproto/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
*config.status*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
*) \
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \
esac;
$(top_srcdir)/docbook.am $(am__empty):
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(top_srcdir)/configure: $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
install-dist_shelfDATA: $(dist_shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-dist_shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
install-shelfDATA: $(shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
tags TAGS:
ctags CTAGS:
cscope cscopelist:
distdir: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) distdir-am
distdir-am: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
all-am: Makefile $(DATA)
installdirs:
for dir in "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"; do \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-am
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
mostlyclean-generic:
clean-generic:
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
clean: clean-am
clean-am: clean-generic mostlyclean-am
distclean: distclean-am
-rm -f Makefile
distclean-am: clean-am distclean-generic
dvi: dvi-am
dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am: install-dist_shelfDATA install-shelfDATA
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
-rm -f Makefile
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-generic
pdf: pdf-am
pdf-am:
ps: ps-am
ps-am:
uninstall-am: uninstall-dist_shelfDATA uninstall-shelfDATA
.MAKE: install-am install-strip
.PHONY: all all-am check check-am clean clean-generic cscopelist-am \
ctags-am distclean distclean-generic distdir dvi dvi-am html \
html-am info info-am install install-am install-data \
install-data-am install-dist_shelfDATA install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-shelfDATA install-strip installcheck installcheck-am \
installdirs maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-generic pdf pdf-am ps ps-am tags-am \
uninstall uninstall-am uninstall-dist_shelfDATA \
uninstall-shelfDATA
.PRECIOUS: Makefile
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.html: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@%.txt: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.pdf: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.ps: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.html.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_HTML_FLAGS) $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.pdf.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_PDF_FLAGS) $<
# Generate DocBook/XML output formats with or without stylesheets
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
xorgproto-2023.2/specs/kbproto/ 0000755 0001750 0001750 00000000000 14443010036 013436 5 0000000 0000000 xorgproto-2023.2/specs/kbproto/ch02.xml 0000644 0001750 0001750 00000034004 14443010026 014634 0000000 0000000
Keyboard State
The core protocol description of
keyboard state consists of eight
modifiers
(
Shift
,
Lock
,
Control
, and
Mod1
-
Mod5
). A modifier reports the state of one or modifier keys, which are similar to
qualifier keys as defined by the ISO9995 standard:
Qualifier key
A key whose operation
has no immediate effect, but which, for as long as it is held down, modifies
the effect of other keys. A qualifier key may be, for example, a shift key or a
control key.
Whenever a modifier key is physically or logically depressed, the modifier it
controls is set in the keyboard state. The protocol implies that certain
modifier keys lock (i.e. affect modifier state after they have been physically
released) but does not explicitly discuss locking keys or their behavior. The
current modifier state is reported to clients in a number of core protocol
events and can be determined using the
QueryPointer
request.
The XKB extension retains the eight "real" modifiers defined by the core
protocol but extends the core protocol notion of
keyboard state
to include up to four
keysym groups
, as defined by the ISO9995 standard:
Group:
A logical state of a keyboard providing
access to a collection of characters. A group usually contains a set of
characters which logically belong together and which may be arranged on several
shift levels within that group.
For example, keyboard group can be used to select between multiple alphabets on
a single keyboard, or to access less-commonly used symbols within a character
set.
Locking and Latching Modifiers and Groups
With the core protocol, there is no way to
tell whether a modifier is set due to a lock or because the user is actually
holding down a key; this can make for a clumsy user-interface as locked
modifiers or group state interfere with accelerators and translations.
XKB adds explicit support for locking
and latching modifiers and groups. Locked modifiers or groups apply to all
future key events until they are explicitly changed. Latched modifiers or
groups apply only to the next key event that does not change keyboard state.
Fundamental Components of XKB Keyboard State
The fundamental components of XKB keyboard state include:
The locked modifiers and group
The latched modifiers and group
The base modifiers and group (for which keys are physically or
logically down)
The effective modifiers and group (the cumulative effect of the base,
locked and latched modifier and group states).
State of the core pointer buttons.
The latched and locked state of modifiers and groups can be changed in response
to keyboard activity or under application control using the
XkbLatchLockState
request. The base modifier, base group
and pointer button states always reflect the logical state of the keyboard and
pointer and change
only
in response to keyboard or pointer activity.
Computing Effective Modifier and Group
The effective modifiers and group
report the cumulative effects of the base, latched and locked modifiers and
group respectively, and cannot be directly changed. Note that the effective
modifiers and effective group are computed differently.
The effective modifiers are simply the bitwise union of the base, latched and
locked modifiers.
The effective group is the arithmetic sum of the base, latched and locked
groups. The locked and effective keyboard group must fall in the range
Group1
-
Group4
, so they are adjusted into range as specified by the global
GroupsWrap
control as follows:
If the
RedirectIntoRange
flag is set, the four least significant
bits of the groups wrap control specify the index of a group to which all
illegal groups correspond. If the specified group is also out of range, all
illegal groups map to
Group1 .
If the
ClampIntoRange
flag is set, out-of-range groups
correspond to the nearest legal group. Effective groups larger than the highest
supported group are mapped to the highest supported group; effective groups
less than
Group1
are mapped to
Group1
. For example, a key with two groups of symbols uses
Group2
type and symbols if the global effective group is either
Group3
or
Group4 .
If neither flag is set, group is
wrapped into range using integer modulus. For example, a key with two groups of
symbols for which groups wrap uses
Group1
symbols if the global effective group is
Group3
or
Group2
symbols if the global effective group is
Group4 .
The base and latched keyboard groups are unrestricted eight-bit integer values
and are not affected by the
GroupsWrap
control.
Computing A State Field from an XKB State
Many events report the keyboard state
in a single
state
field. Using XKB, a state field combines modifiers, group and the pointer
button state into a single sixteen bit value as follows:
Bits 0 through 7 (the least significant eight bits) of the effective
state comprise a mask of type KEYMASK which reports the state modifiers.
Bits 8 through 12 comprise a mask of type BUTMASK which reports pointer
button state.
Bits 13 and 14 are interpreted as a two-bit unsigned numeric value and
report the state keyboard group.
Bit 15 (the most significant bit) is reserved and must be zero.
It is possible to assemble a state field from any of the components of the XKB
keyboard state. For example, the effective keyboard state would be assembled as
described above using the effective keyboard group, the effective keyboard
modifiers and the pointer button state.
Derived Components of XKB Keyboard State
In addition to the fundamental state
components, XKB keeps track of and reports a number of state components which
are derived from the fundamental components but stored and reported separately
to make it easier to track changes in the keyboard state. These derived
components are updated automatically whenever any of the fundamental components
change but cannot be changed directly.
The first pair of derived state components control the way that passive grabs
are activated and the way that modifiers are reported in core protocol events
that report state. The server uses the
ServerInternalModifiers
,
IgnoreLocksModifiers
and
IgnoreGroupLock
controls, described in
The lookup state is the state used to determine the symbols associated
with a key event and consists of the effective state minus any server internal
modifiers.
The grab state is the state used to decide whether a particular event
triggers a passive grab and consists of the lookup state minus any members of
the ignore locks modifiers that are not either latched or logically depressed.
If the ignore group locks control is set, the grab state does not include the
effects of any locked groups.
Server Internal Modifiers and Ignore Locks Behavior
The core protocol does not provide any
way to exclude certain modifiers from client events, so there is no way to set
up a modifier which affects only the server.
The modifiers specified in the mask of the
InternalMods
control are not reported in any core
protocol events, are not used to determine grabs and are not used to calculate
compatibility state for XKB-unaware clients. Server internal modifiers affect
only the action applied when a key is pressed.
The core protocol does not provide any way to exclude certain modifiers from
grab calculations, so locking modifiers often have unanticipated and
unfortunate side-effects. XKB provides another mask which can help avoid some
of these problems.
The locked state of the modifiers specified in mask of the
IgnoreLockMods
control is not reported in most core
protocol events and is not used to activate grabs. The only core events which
include the locked state of the modifiers in the ignore locks mask are key
press and release events that do not activate a passive grab and which do not
occur while a grab is active. If the
IgnoreGroupLock
control is set, the locked state of the
keyboard group is not considered when activating passive grabs.
Without XKB, the passive grab set by a translation (e.g.
Alt<KeyPress>space
) does not trigger if any modifiers other than those specified by the
translation are set, with the result that many user interface components do not
react when either Num Lock or when the secondary keyboard group are active. The
ignore locks mask and the ignore group locks control make it possible to avoid
this behavior without exhaustively grabbing every possible modifier combination.
Compatibility Components of Keyboard State
The core protocol interpretation of
keyboard modifiers does not include direct support for multiple groups, so XKB
reports the effective keyboard group to XKB-aware clients using some of the
reserved bits in the state field of some core protocol events, as described in
This modified state field would not be interpreted correctly by XKB-unaware
clients, so XKB provides a
group compatibility mapping
(see
The
compatibility state
corresponds to the effective modifier
and effective group state.
The
compatibility lookup state
is the core-protocol equivalent of the
lookup state.
The
compatibility grab state
is the nearest core-protocol equivalent
of the grab state.
Compatibility states are essentially the corresponding XKB state, but with
keyboard group possibly encoded as one or more modifiers;
The compatibility state reported to XKB-unaware
clients for any given core protocol event
is computed from the modifier state that XKB-capable clients would see for that
same event. For example, if the ignore group locks control is set and group 2
is locked, the modifier bound to
Mode_switch
is not reported in any event except (Device)KeyPress and (Device)KeyRelease
events that do not trigger a passive grab.
Referring to clients as "XKB-capable
is somewhat misleading in this context.
The sample implementation of XKB invisibly extends the X library to use the
keyboard extension if it is present. This means that most clients can take
advantage of all of XKB without modification, but it also means that the XKB
state can be reported to clients that have not explicitly requested the
keyboard extension. Clients that
directly
interpret the state field of core protocol events or that interpret the keymap
directly may be affected by some of the XKB differences; clients that use
library or toolkit routines to interpret keyboard events automatically use all
of the XKB features.
XKB-aware clients can query the keyboard state at any time or request immediate
notification of a change to any of the fundamental or derived components of the
keyboard state.
xorgproto-2023.2/specs/kbproto/ch09.xml 0000644 0001750 0001750 00000040477 14443010026 014656 0000000 0000000
Keyboard Indicators
Although the core X protocol supports thirty-two LEDs on a keyboard, it does
not provide any way to link the state of the LEDs and the logical state of the
keyboard. For example, most keyboards have a "Caps Lock" LED, but X does not
provide any standard way to make the LED automatically follow the logical state
of the modifier bound to the
Caps Lock
key.
The core protocol also gives no way to determine which bits in the
led_mask
field of the keyboard state map to the particular LEDs on the keyboard. For
example, X does not provide a method for a client to determine which bit to set
in the
led_mask
to turn on the "Scroll Lock" LED, or even if the keyboard has a "Scroll Lock"
LED.
Most X servers implement some kind of automatic behavior for one or more of the
keyboard LEDs, but the details of that automatic behavior are
implementation-specific and can be difficult or impossible to control.
XKB provides indicator names and programmable indicators to help solve these
problems. Using XKB, clients can determine the names of the various indicators,
determine and control the way that the individual indicators should be updated
to reflect keyboard changes, and determine which of the 32 keyboard indicators
reported by the protocol are actually present on the keyboard. Clients may also
request immediate notification of changes to the state of any subset of the
keyboard indicators, which makes it straightforward to provide an on-screen
"virtual" LED panel.
Global Information About Indicators
XKB provides only two pieces of information about the indicators as a group.
The
physical indicators
mask reports which of the 32 logical keyboard indicators supported by the core
protocol and XKB corresponds to some actual indicator on the keyboard itself.
Because the physical indicators mask describes a physical characteristic of the
keyboard, it cannot be directly changed under program control. It is possible,
however, for the set of physical indicators to be change if a new keyboard is
attached or if a completely new keyboard description is loaded by the
XkbGetKeyboardByName
request (see
The
indicator state
mask reports the current state of the 32 logical keyboard indicators. This
field and the core protocol indicator state (as reported by the
led-mask
field of the core protocol
GetKeyboardControl
request) are always identical.
Per-Indicator Information
Each of the thirty-two keyboard indicators has a symbolic name, of type ATOM.
The
XkbGetNames
request reports the symbolic names for all keyboard components, including the
indicators. Use the
XkbSetNames
request to change symbolic names. Both requests are described in
Indicator Maps
XKB also provides an
indicator map
for each of the thirty-two keyboard indicators; an indicator map specifies:
The conditions under which the keyboard modifier state affects the
indicator.
The conditions under which the keyboard group state affects the
indicator.
The conditions under which the state of the boolean controls affects
the indicator.
The effect (if any) of attempts to explicitly change the state of the
indicator using the core protocol
SetKeyboardControl
request.
If
IM_NoAutomatic
is set in the
flags
field of an indicator map, that indicator never changes in response to changes
in keyboard state or controls, regardless of the values for the other fields of
the indicator map. If
IM_NoAutomatic
is not set in
flags
, the other fields of the indicator map specify the automatic changes to the
indicator in response to changes in the keyboard state or controls.
The
which_groups
and the
groups
fields of an indicator map determine how the keyboard group state affects the
corresponding indicator. The
which_groups
field controls the interpretation of
groups
and may contain any one of the following values:
Value
Interpretation of the Groups Field
IM_UseNone
The
groups
field and the current keyboard group state are ignored.
IM_UseBase
If
groups
is non-zero, the indicator is lit whenever the base keyboard group is
non-zero. If
groups
is zero, the indicator is lit whenever the base keyboard group is zero.
IM_UseLatched
If
groups
is non-zero, the indicator is lit whenever the latched keyboard group is
non-zero. If
groups
is zero, the indicator is lit whenever the latched keyboard group is
zero.
IM_UseLocked
The
groups
field is interpreted as a mask. The indicator is lit when the current locked
keyboard group matches one of the bits that are set in
groups
.
IM_UseEffective
The
groups
field is interpreted as a mask. The indicator is lit when the current
effective keyboard group matches one of the bits that are set in
groups
.
The
which_mods
and
mods
fields of an indicator map determine how the state of the keyboard modifiers
affect the corresponding indicator. The
mods
field is an XKB modifier definition, as described in
mods
are unbound.
The
which_mods
field can specify one or more components of the XKB keyboard state. The
corresponding indicator is lit whenever any of the real modifiers specified in
the
mask
field of the
mods
modifier definition are also set in any of the current keyboard state
components specified by the
which_mods
. The
which_mods
field may have any combination of the following values:
Value
Keyboard State Component To Be Considered
IM_UseBase
Base modifier state
IM_UseLatched
Latched modifier state
IM_UseLocked
Locked modifier state
IM_UseEffective
Effective modifier state
IM_UseCompat
Modifier compatibility state
The
controls
field specifies a subset of the boolean keyboard controls (see
controls
are enabled.
An indicator is lit whenever any of the conditions specified by its indicator
map are met, unless overridden by the
IM_NoAutomatic
flag (described above) or an explicit indicator change (described below).
Effects of Explicit Changes on Indicators
If the
IM_NoExplicit
flag is set in an indicator map, attempts to change the state of the indicator
are ignored.
If both
IM_NoExplicit
and
IM_NoAutomatic
are both absent from an indicator map, requests to change the state of the
indicator are honored but might be immediately superseded by automatic changes
to the indicator state which reflect changes to keyboard state or controls.
If the
IM_LEDDrivesKB
flag is set and the
IM_NoExplicit
flag is not, the keyboard state and controls are changed to reflect the other
fields of the indicator map, as described in the remainder of this section.
Attempts to explicitly change the value of an indicator for which
IM_LEDDrivesKB
is absent or for which
IM_NoExplicit
is present do not affect keyboard state or controls.
The effect on group state of changing an explicit indicator which drives the
keyboard is determined by the value of
which_groups
and
groups
, as follows:
which_groups
New State
Effect on Keyboard Group State
IM_UseNone
, or
IM_UseBase
On or Off
No Effect
IM_UseLatched
On
The
groups
field is treated as a group mask. The keyboard group latch is changed to the
lowest numbered group specified in
groups
; if
groups
is empty, the keyboard group latch is changed to zero.
IM_UseLatched
Off
The
groups
field is treated as a group mask. If the indicator is explicitly extinguished,
keyboard group latch is changed to the lowest numbered group not specified in
groups
; if
groups
is zero, the keyboard group latch is set to the index of the highest legal
keyboard group.
IM_UseLocked
, or
IM_UseEffective
On
If the
groups
mask is empty, group is not changed, otherwise the locked keyboard group is
changed to the lowest numbered group specified in
groups
.
IM_UseLocked
, or
IM_UseEffective
Off
Locked keyboard group is changed to the lowest numbered group that
is not specified in the
groups
mask, or to
Group1
if the
groups
mask contains all keyboard groups.
The effect on the keyboard modifiers of changing an explicit indicator which
drives the keyboard is determined by the values that are set in of
which_mods
and
mods
, as follows:
Set in which_mods
New State
Effect on Keyboard Modifiers
IM_UseBase
On or Off
No Effect
IM_UseLatched
On
Any modifiers specified in the
mask
field of
mods
are added to the latched modifiers.
IM_UseLatched
Off
Any modifiers specified in the
mask
field of
mods
are removed from the latched modifiers.
IM_UseLocked
,
IM_UseCompat
, or
IM_UseEffective
On
Any modifiers specified in the
mask
field of
mods
are added to the locked modifiers.
IM_UseLocked
Off
Any modifiers specified in the
mask
field of
mods
are removed from the locked modifiers.
IM_UseCompat
, or
IM_UseEffective
Off
Any modifiers specified in the
mask
field of
mods
are removed from both the locked and latched modifiers.
Lighting an explicit indicator which drives the keyboard also enables all of
the boolean controls specified in the
controls
field of its indicator map. Explicitly extinguishing such an indicator
disables all of the boolean controls specified in
controls
.
The effects of changing an indicator which drives the keyboard are cumulative;
it is possible for a single change to affect keyboard group, modifiers and
controls simultaneously.
If an indicator for which both the
IM_LEDDrivesKB
and
IM_NoAutomatic
flags are specified is changed, the keyboard changes specified above are
applied and the indicator is changed to reflect the state that was explicitly
requested. The indicator will remain in the new state until it is explicitly
changed again.
If the
IM_NoAutomatic
flag is not set for an indicator which drives the keyboard, the changes
specified above are applied and the state of the indicator is set to the values
specified by the indicator map. Note that it is possible in this case for the
indicator to end up in a different state than the one that was explicitly
requested. For example, an indicator with
which_mods
of
IM_UseBase
and
mods
of
Shift
is not extinguished if one of the
Shift
keys is physically depressed when the request to extinguish the indicator is
processed.
xorgproto-2023.2/specs/kbproto/XKBproto-2.svg 0000644 0001750 0001750 00000056657 14443010026 015770 0000000 0000000
image/svg+xml
xorgproto-2023.2/specs/kbproto/XKBproto-9.svg 0000644 0001750 0001750 00000014511 14443010026 015756 0000000 0000000
image/svg+xml
xorgproto-2023.2/specs/kbproto/XKBproto-7.svg 0000644 0001750 0001750 00000053056 14443010026 015763 0000000 0000000
image/svg+xml
Key: Keycode: 13 Num Lock 15 Enter 12 1 End 9 è ö 8 Q q @ 10 A a
æ 11 ? \ ? Ï
xorgproto-2023.2/specs/kbproto/ch13.xml 0000644 0001750 0001750 00000032440 14443010026 014640 0000000 0000000
The Server Database of Keyboard Components
The X server maintains a database of keyboard components and common keyboard
mappings. This database contains five kinds of components; when combined, these
five components provide a complete description of a keyboard and its behavior.
The X Keyboard Extension provides requests to list the contents of this
database, to assemble and complete keyboard descriptions by merging the current
keyboard description with the contents of this database, or to replace the
current keyboard description with a complete keyboard description assembled as
described below.
Component Names
Component and keymap names have the form "
class
(
member
)" where
class
describes a subset of the available components for a particular type and the
optional
member
identifies a specific component from that subset. For example, the name
"atlantis(acme)" might specify the symbols used for the atlantis national
keyboard layout by the vendor "acme." Each class has an optional
default
member — references which specify a class but not a member refer to the
default member of the class, if one exists.
The
class
and
member
names are both specified using characters from the Latin-1 character set. XKB
implementations must accept all alphanumeric characters, minus (‘-’) and
underscore (‘_’) in class or member names, and must not accept parentheses,
plus, vertical bar, percent sign, asterisk, question mark or white space. The
use of other characters is implementation-dependent.
Partial Components and Combining Multiple Components
Some of the elements in the server database contain describe only a piece of
the corresponding keyboard component. These
partial
components should be combined with other components of the same type to be
useful.
For example, a partial symbols map might describe the differences between a
common ASCII keyboard and some national layout. Such a partial map is not
useful on its own because it does not include those symbols that are the same
on both the ASCII and national layouts (such as function keys). On the other
hand, this partial map can configure
any
ASCII keyboard to use a national layout.
Two components can be combined in two ways:
If the second component
overrides
the first, any definitions that are present in both components are taken from
the second.
If the second component
augments
the first, any definitions that are present in both components are taken from
the first.
Applications can use a
component expression
to combine multiple components of some time into a complete description of
some aspect of the keyboard. A component expression is a string which lists the
components to be combined separated by operators which specify the rules for
combining them. A complete description is assembled from the listed components,
left to right, as follows:
If the new elements are being merged with an existing map, the special
component name ‘%’ refers to the unmodified value of the map.
The ‘+’ operator specifies that the next specified component should
override the current assembled definition.
The ‘|’ operator specifies that the next specified component should
augment the currently assembled definition.
If the new elements are being merged with an existing map and the
component expression begins with an operator, a leading ‘%’ is implied.
If any unknown or illegal characters appear anywhere in the string, the
entire expression is invalid and is ignored.
For example, the component expression "+de" specifies that the default element
of the "de" map should be applied to the current keyboard mapping, overriding
any existing definitions.
A slightly more involved example: the expression
"acme(ascii)+de(basic)|iso9995-3" constructs a German (de) mapping for the
ASCII keyboard supplied by the "acme" vendor. The new definition begins with
the symbols for the default ASCII keyboard for Acme, overrides them with any
keys that are defined for the default German keyboard layout and then applies
the definitions from the iso9995-3 to any undefined keys or groups of keys
(part three of the iso9995 standard defines a common set of bindings for the
secondary group, but allows national layouts to override those definitions
where necessary).
Component Hints
Each component has a set of flags that provide some additional hints about that
component. XKB provides these hints for clients that present the keyboard
database to users and specifies their interpretation only loosely. Clients can
use these hints to constrain the list of components or to control the way that
components are presented to the user.
Hints for a component are reported with its name. The least significant byte of
the hints field has the same meaning for all five types of keyboard components,
and can contain any combination of the following values:
Flag
Meaning
LC_Hidden
Indicates a component that should not normally be presented to the
user.
LC_Default
Indicates a component that is the default member of its
class.
LC_Partial
Indicates a partial component.
The interpretation of the most significant byte of the hints field is dependent
on the type of component. The hints defined for each kind of component are
listed in the section below that describes that kind of component.
Keyboard Components
The five types of components stored in the server database of keyboard
components correspond to the
symbols
,
geometry
,
keycodes
,
compat
and
types
symbolic names associated with a keyboard.
The Keycodes Component
The
keycodes
component of a keyboard mapping specifies the range and interpretation of the
raw keycodes reported by the device. It sets the
keycodes
symbolic name, the minimum and maximum legal keycodes for the keyboard, and
the symbolic name for each key. The keycodes component might also contain
aliases for some keys, symbolic names for some indicators, and a description of
which indicators are physically present.
The special keycodes component named "computed" indicates that XKB should
assign unused keycodes to any unknown keys referenced by name by any of the
other components. The computed keycodes component is useful primarily when
browsing keymaps because it makes it possible to use the symbols and geometry
components without having to find a set of keycodes that includes keycode
definitions for all of the keys listed in the two components.
XKB defines no hints that are specific to the keycodes component.
The Types Component
The
types
component of a keyboard mapping specifies the key types that can be associated
with the various keyboard keys. It affects the
types
symbolic name and the list of types associated with the keyboard (see
The special types component named "canonical" always contains the types and
definitions listed in
XKB defines no hints that are specific to the types component.
The Compatibility Map Component
The
compatibility map
component of a keyboard mapping primarily specifies the rules used to assign
actions to keysyms. It affects the
compat
symbolic name, the symbol compatibility map and the group compatibility map.
The compat component might also specify maps for some indicators and the real
modifier bindings and symbolic names of some virtual modifiers.
XKB defines no hints that are specific to the compatibility map component.
The Symbols Component
The
symbols
component of a keyboard mapping specifies primarily the symbols bound to each
keyboard key. It affects the
symbols
symbolic name, a key symbol mapping for each key, they keyboard modifier
mapping, and the symbolic names for the keyboard symbol groups. Optionally, the
symbols
component can contain explicit actions and behaviors for some keys, or the
real modifier bindings and symbolic names for some virtual modifiers.
XKB defines the following additional hints for the symbols component:
Flag
Meaning
LC_AlphanumericKeys
Indicates a symbol component that contains bindings primarily for an
alphanumeric section of the keyboard.
LC_ModifierKeys
Indicates a symbol component that contains bindings primarily for
modifier keys.
LC_KeypadKeys
Indicates a symbol component that contains bindings primarily for
numeric keypad keys.
LC_FunctionKeys
Indicates a symbol component that contains bindings primarily for
function keys.
LC_AlternateGroup
Indicates a symbol component that contains bindings for an alternate
keyboard group.
These hints only apply to partial symbols components; full symbols components
are assumed to specify all of the pieces listed above.
The alphanumeric, modifier, keypad or function keys hints should
describe the primary intent of the component designer and should not simply an
exhaustive list of the kinds of keys that are affected. For example, national
keyboard layouts affect primarily alphanumeric keys, but many affect a few
modifier keys too; such mappings should set only
LC_AlphanumericKeys
hint. In general, symbol components should set only one of those four flags
(though
LC_AlternateGroup
may be combined with any of the other flags).
The Geometry Component
The
geometry
component of a keyboard mapping specifies primarily the geometry of the
keyboard. It contains the geometry symbolic name and the keyboard geometry
description. The geometry component might also contain aliases for some keys or
symbolic names for some indicators and might affect the set of indicators that
are physically present. Key aliases defined in the geometry component of a
keyboard mapping override those defined in the keycodes component.
XKB defines no hints that are specific to the geometry component.
Complete Keymaps
The X server also reports a set of fully specified keymaps. The keymaps
specified in this list are usually assembled from the components stored in the
rest of the database and typically represent the most commonly used keymaps for
a particular system.
XKB defines no hints that are specific to complete keymaps.
xorgproto-2023.2/specs/kbproto/XKBproto-6.svg 0000644 0001750 0001750 00000106762 14443010026 015765 0000000 0000000
image/svg+xml
Core Symbols
A a L1 L2 L1 L2 G1 G2
Xkb Symbols
A a L1 L2 G1 G2
Symbols a G1L1 = A G1L2 =
G2L1 =
G2L2 =
Physical Key Shift Level Group
a A
xorgproto-2023.2/specs/kbproto/appA.xml 0000644 0001750 0001750 00000053531 14443010026 014767 0000000 0000000
Default Symbol Transformations
Interpreting the Control Modifier
If the
Control
modifier is not consumed by the symbol lookup process, routines that determine
the symbol and string that correspond to an event should convert the symbol to
a string as defined in the table below. Only the string to be returned is
affected by the
Control
modifier; the symbol is not changed.
This table lists the decimal value of the standard control characters that
correspond to some keysyms for ASCII characters. Control characters for symbols
not listed in this table are application-specific.
Keysyms
Value
Keysyms
Value
Keysyms
Value
Keysyms
Value
atsign
0
h, H
8
p, P
16
x, X
24
a, A
1
i, I
9
q, Q
17
y, Y
25
b, B
2
j, J
10
r, R
18
z, Z
26
c, C
3
k, K
11
s, S
19
left_bracket
27
d, D
4
l, L
12
t, T
20
backslash
28
e, E
5
m, M
13
u, U
21
right_bracket
29
f, F
6
n, N
14
v, V
22
asciicircum
30
g, G
8
o, O
15
w, W
23
underbar
31
Interpreting the Lock Modifier
If the
Lock
modifier is not consumed by the symbol lookup process, routines that determine
the symbol and string that correspond to an event should capitalize the result.
Unlike the transformation for
Control
, the capitalization transformation changes both the symbol and the string
returned by the event.
Locale-Sensitive Capitalization
If
Lock
is set in an event and not consumed, applications should capitalize the string
and symbols that result from an event according to the capitalization rules in
effect for the system on which the application is running, taking the current
state of the user environment (e.g. locale) into account.
Locale-Insensitive Capitalization
XKB recommends but does not require locale-sensitive capitalization. In cases
where the locale is unknown or where locale-sensitive capitalization is
prohibitively expensive, applications can capitalize according to the rules
defined in this extension.
The following tables list all of the keysyms for which XKB defines
capitalization behavior. Any keysyms not explicitly listed in these tables are
not capitalized by XKB when locale-insensitive capitalization is in effect and
are not automatically assigned the
ALPHABETIC
type as described in the
Capitalization Rules for Latin-1 Keysyms
This table lists the Latin-11 keysyms for which XKB defines upper and lower
case:
Lower Case
Upper Case
Lower Case
Upper Case
Lower Case
Upper Case
Lower Case
Upper Case
a
A
o
O
acircumflex
Acircumflex
eth
ETH
b
B
p
P
adiaeresis
Adiaeresis
ntilde
Ntilde
c
C
q
Q
atilde
Atilde
ograve
Ograve
d
D
r
R
aring
Aring
oacute
Oacute
e
E
s
S
ae
AE
ocircumflex
Ocircumflex
f
F
t
T
ccedilla
Ccedilla
otilde
Otilde
g
G
u
U
egrave
Egrave
odiaeresis
Odiaeresis
h
H
v
V
eacute
Eacute
oslash
Ooblique
i
I
w
W
ecircumflex
Ecircumflex
ugrave
Ugrave
j
J
x
X
ediaeresis
Ediaeresis
uacute
Uacute
k
K
y
Y
igrave
Igrave
ucircumflex
Ucircumflex
l
L
z
Z
iacute
Iacute
udiaeresis
Udiaeresis
m
M
agrave
Agrave
icircumflex
Icircumflex
yacute
Yacute
n
N
aacute
Aacute
idiaeresis
Idiaeresis
thorn
THORN
Capitalization Rules for Latin-2 Keysyms
This table lists the Latin-2 keysyms for which XKB defines upper and lower case:
Lower Case
Upper Case
Lower Case
Upper Case
Lower Case
Upper Case
aogonek
Aogonek
zabovedot
Zabovedot
dstroke
Dstroke
lstroke
Lstroke
racute
Racute
nacute
Nacute
lcaron
Lcaron
abreve
Abreve
ncaron
Ncaron
sacute
Sacute
lacute
Lacute
odoubleacute
Odoubleacute
scaron
Scaron
cacute
Cacute
rcaron
Rcaron
scedilla
Scedilla
ccaron
Ccaron
uabovering
Uabovering
tcaron
Tcaron
eogonek
Eogonek
udoubleacute
Udoubleacute
zacute
Zacute
ecaron
Ecaron
tcedilla
Tcedilla
zcaron
Zcaron
dcaron
Dcaron
Capitalization Rules for Latin-3 Keysyms
This table lists the Latin-3 keysyms for which XKB defines upper and lower case:
Lower Case
Upper Case
Lower Case
Upper Case
Lower Case
Upper Case
hstroke
Hstroke
jcircumflex
Jcircumflex
gcircumflex
Gcircumflex
hcircumflex
Hcircumflex
cabovedot
Cabovedot
ubreve
Ubreve
idotless
Iabovedot
ccircumflex
Ccircumflex
scircumflex
Scircumflex
gbreve
Gbreve
gabovedot
Gabovedot
Capitalization Rules for Latin-4 Keysyms
This table lists the Latin-4 keysyms for which XKB defines upper and lower case:
Lower Case
Upper Case
Lower Case
Upper Case
Lower Case
Upper Case
rcedilla
Rcedilla
eng
ENG
omacron
Omacron
itilde
Itilde
amacron
Amacron
kcedilla
Kcedilla
lcedilla
Lcedilla
iogonek
Iogonek
uogonek
Uogonek
emacron
Emacron
eabovedot
eabovedot
utilde
Utilde
gcedilla
Gcedilla
imacron
Imacron
umacron
Umacron
tslash
Tslash
ncedilla
Ncedilla
Capitalization Rules for Cyrillic Keysyms
This table lists the Cyrillic keysyms for which XKB defines upper and lower
case:
Lower Case
Upper Case
Lower Case
Upper Case
Serbian_dje
Serbian_DJE
Cyrillic_i
Cyrillic_I
Macedonia_gje
Macedonia_GJE
Cyrillic_shorti
Cyrillic_SHORTI
Cyrillic_io
Cyrillic_IO
Cyrillic_ka
Cyrillic_KA
Ukrainian_ie
Ukrainian_IE
Cyrillic_el
Cyrillic_EL
Macedonia_dse
Macedonia_DSE
Cyrillic_em
Cyrillic_EM
Ukrainian_i
Ukrainian_I
Cyrillic_en
Cyrillic_EN
Ukrainian_yi
Ukrainian_YI
Cyrillic_o
Cyrillic_O
Cyrillic_je
Cyrillic_JE
Cyrillic_pe
Cyrillic_PE
Cyrillic_lje
Cyrillic_LJE
Cyrillic_ya
Cyrillic_YA
Cyrillic_nje
Cyrillic_NJE
Cyrillic_er
Cyrillic_ER
Serbian_tshe
Serbian_TSHE
Cyrillic_es
Cyrillic_ES
Macedonia_kje
Macedonia_KJE
Cyrillic_te
Cyrillic_TE
Byelorussian_shortu
Byelorussian_SHORTU
Cyrillic_u
Cyrillic_U
Cyrillic_dzhe
Cyrillic_DZHE
Cyrillic_zhe
Cyrillic_ZHE
Cyrillic_yu
Cyrillic_YU
Cyrillic_ve
Cyrillic_VE
Cyrillic_a
Cyrillic_A
Cyrillic_softsign
Cyrillic_SOFTSIGN
Cyrillic_be
Cyrillic_BE
Cyrillic_yeru
Cyrillic_YERU
Cyrillic_tse
Cyrillic_TSE
Cyrillic_ze
Cyrillic_ZE
Cyrillic_de
Cyrillic_DE
Cyrillic_sha
Cyrillic_SHA
Cyrillic_ie
Cyrillic_IE
Cyrillic_e
Cyrillic_E
Cyrillic_ef
Cyrillic_EF
Cyrillic_shcha
Cyrillic_SHCHA
Cyrillic_ghe
Cyrillic_GHE
Cyrillic_che
Cyrillic_CHE
Cyrillic_ha
Cyrillic_HA
Cyrillic_hardsign
Cyrillic_HARDSIGN
Capitalization Rules for Greek Keysyms
This table lists the Greek keysyms for which XKB defines upper and lower case:
Lower Case
Upper Case
Lower Case
Upper Case
Greek_omegaaccent
Greek_OMEGAACCENT
Greek_iota
Greek_IOTA
Greek_alphaaccent
Greek_ALPHAACCENT
Greek_kappa
Greek_KAPPA
Greek_epsilonaccent
Greek_EPSILONACCENT
Greek_lamda
Greek_LAMDA
Greek_etaaccent
Greek_ETAACCENT
Greek_lambda
Greek_LAMBDA
Greek_iotaaccent
Greek_IOTAACCENT
Greek_mu
Greek_MU
Greek_iotadieresis
Greek_IOTADIERESIS
Greek_nu
Greek_NU
Greek_omicronaccent
Greek_OMICRONACCENT
Greek_xi
Greek_XI
Greek_upsilonaccent
Greek_UPSILONACCENT
Greek_omicron
Greek_OMICRON
Greek_upsilondieresis
Greek_UPSILONDIERESIS
Greek_pi
Greek_PI
Greek_alpha
Greek_ALPHA
Greek_rho
Greek_RHO
Greek_beta
Greek_BETA
Greek_sigma
Greek_SIGMA
Greek_gamma
Greek_GAMMA
Greek_tau
Greek_TAU
Greek_delta
Greek_DELTA
Greek_upsilon
Greek_UPSILON
Greek_epsilon
Greek_EPSILON
Greek_phi
Greek_PHI
Greek_zeta
Greek_ZETA
Greek_chi
Greek_CHI
Greek_eta
Greek_ETA
Greek_psi
Greek_PSI
Greek_theta
Greek_THETA
Greek_omega
Greek_OMEGA
Capitalization Rules for Other Keysyms
XKB defines no capitalization rules for symbols in any other set of keysyms
provided by the consortium. Applications are free to apply additional rules for
private keysyms or for other keysyms not covered by XKB.
xorgproto-2023.2/specs/kbproto/ch14.xml 0000644 0001750 0001750 00000006227 14443010026 014645 0000000 0000000
Replacing the Keyboard "On-the-Fly"
XKB supports the
XkbNewKeyboardNotify
event, which reports a change in keyboard geometry or the range of supported
keycodes. The server can generate an
XkbNewKeyboardNotify
event when it detects a new keyboard, or in response to an
XkbGetKeyboardByName
request (see
When a client opens a connection to the X server, the server reports the
minimum and maximum keycodes. If the range of supported keycodes is changed,
XKB keeps track of the minimum and maximum keycodes that were reported to each
client and filters out any events that fall outside of that range. Note that
these events are simply ignored; they are not delivered to some other client.
When the server sends an
XkbNewKeyboardNotify
event to a client to inform it of the new keycode range, XKB resets the stored
range of legal keycodes to the keycode range reported in the event. Non-XKB
clients and XKB-aware clients that do not request
XkbNewKeyboardNotify
events never receive events from keys that fall outside of the legal range
that XKB maintains for that client.
When a client requests
XkbNewKeyboardNotify
events, the server compares the range of keycodes for the current keyboard to
the range of keycodes that are valid for the client. If they are not the same,
the server immediately sends that client an
XkbNewKeyboardNotify
event. Even if the "new" keyboard is not new to the server, it is new to this
particular client.
In addition to filtering out-of-range key events, XKB:
Adjusts core protocol
MappingNotify
events to refer only to keys that match the stored legal range.
Reports keyboard mappings for keys that match the stored legal range to
clients that issue a core protocol
GetKeyboardMapping
request.
Reports modifier mappings only for keys that match the stored legal
range to clients that issue a core protocol
GetModifierMapping
request.
Restricts the core protocol
ChangeKeyboardMapping
and
SetModifierMapping
requests to keys that fall inside the stored legal range.
In short, XKB does everything possible to hide the fact that the range of legal
keycodes has changed from clients non-XKB clients, which cannot be expected to
deal with it. The corresponding XKB events and requests do
not
pay attention to the legal keycode range in the same way because XKB makes it
possible for clients to track changes to the keycode range for a device and
respond to them.
xorgproto-2023.2/specs/kbproto/ch16.xml 0000644 0001750 0001750 00000673732 14443010026 014662 0000000 0000000
XKB Protocol Requests
This document uses the syntactic conventions and common types defined by the
specification of the core X protocol with a number of additions, which are
detailed below.
Errors
If a client attempts to use any other XKB request except
XkbUseExtension
before the extension is properly initialized, XKB reports an
Access
error and ignores the request. XKB is properly initialized once
XkbUseExtension
reports that the client has asked for a supported or compatible version of the
extension.
Keyboard Errors
In addition to all of the errors defined by the core protocol, the X Keyboard
Extension defines a single error,
Keyboard
, which indicates that some request specified an illegal device identifier or
an extension device that is not a member of an appropriate. Unless otherwise
noted, any request with an argument of type KB_DEVICESPEC can cause
Keyboard
errors if an illegal or inappropriate device is specified.
When the extension reports a Keyboard error, the most significant byte of the
resource_id
is a further refinement of the error cause, as defined in the table below. The
least significant byte contains the device, class, or feedback id as indicated:
high-order byte
value
meaning
low-order byte
XkbErr_BadDevice
0xff
device not found
device id
XkbErr_BadClass
0xfe
device found, but is the wrong class
class id
XkbErr_BadId
0xfd
device found, class ok, but device does not have a feedback with the
indicated id
feedback id
Side-Effects of Errors
With the exception of
Alloc
or
Implementation
errors, which might result in an inconsistent internal state, no XKB request
that reports an error condition has any effect. Unless otherwise stated,
requests which update some aspect of the keyboard description will not apply
only part of a request — if part of a request fails, the whole thing is
ignored.
Common Types
The following types are used in the request and event definitions in subsequent
sections:
Name
Value
LISTofITEMs
The type LISTofITEMs is special. It is similar to the
LISTofVALUE defined by the core protocol, but the elements of a LISTofITEMs are
not necessarily all the same size. The use of a BITMASK to indicate which
members are present is optional for a LISTofITEMs — it is possible for the
set of elements to be derived from one or more fields of the request.
KB_DEVICESPEC
8 bit unsigned integer,
UseCoreKbd, or UseCorePtr
KB_LEDCLASSSPEC
{
KbdFeedbackClass
,
LedFeedbackClass
,
DfltXIClass
,
AllXIClasses
,
XINone
}
KB_BELLCLASSSPEC
{
KbdFeedbackClass
,
BellFeedbackClass
,
DfltXIClass
,
AllXIClasses
}
KB_IDSPEC
8 bit unsigned integer or
DfltXIId
KB_VMODMASK
CARD16, each bit corresponds to a virtual modifier
KB_GROUPMASK
{
Group1
,
Group2
,
Group3
,
Group4
}
KB_GROUPSWRAP
{
WrapIntoRange
,
ClampIntoRange
,
RedirectIntoRange
}
KB_GROUPINFO
{ groupsWrap: KB_GROUPSWRAP
redirectGroup: 1…4,
numGroups: 1…4 }
KB_NKNDETAILSMASK
{
NKN_Keycodes
, NKN_Geometry,
NKN_DeviceID
}
KB_STATEMASK
KEYBUTMASK or KB_GROUPMASK
KB_STATEPARTMASK
{
ModifierState
,
ModifierBase
,
ModifierLatch
,
ModifierLock
,
GroupState
,
GroupBase
,
GroupLatch
,
GroupLock
,
CompatState
,
GrabMods
,
CompatGrabMods
,
LookupMods
,
CompatLookupMods
,
PointerButtons
}
KB_BOOLCTRLMASK
{
RepeatKeys
,
SlowKeys
,
BounceKeys
,
StickyKeys
,
MouseKeys
,
MouseKeysAccel
,
AccessXKeys
,
AccessXTimeout
,
AccessXFeedback
,
AudibleBell
,
Overlay1
,
Overlay2
,
IgnoreGroupLock
}
KB_CONTROLSMASK
{
GroupsWrap, InternalMods
,
IgnoreLockMods
,
PerKeyRepeat
,
ControlsEnabled
} or KB_BOOLCTRLMASK
KB_MAPPARTMASK
{
KeyTypes
,
KeySyms
,
ModifierMap
,
ExplicitComponents
,
KeyActions
,
KeyBehaviors
,
VirtualMods
,
VirtualModMap
}
KB_CMDETAILMASK
{
SymInterp
,
GroupCompat
}
KB_NAMEDETAILMASK
{
KeycodesName
,
GeometryName
,
SymbolsName
,
PhysSymbolsName
,
TypesName
,
CompatName
,
KeyTypeNames
,
KTLevelNames
,
IndicatorNames
,
KeyNames
,
KeyAliases
,
VirtualModNames
,
GroupNames
,
RGNames
}
KB_AXNDETAILMASK
{
AXN_SKPress
,
AXN_SKAccept
,
AXN_SKReject
,
AXN_SKRelease, AXN_BKAccept, AXN_BKReject, AXN_AXKWarning
}
KB_AXSKOPTSMASK
{
AX_TwoKeys
,
AX_LatchToLock
}
KB_AXFBOPTSMASK
{
AX_SKPressFB
,
AX_SKAcceptFB
,
AX_FeatureFB
,
AX_SlowWarnFB
,
AX_IndicatorFB
,
AX_StickyKeysFB
,
AX_SKReleaseFB
,
AX_SKRejectFB
,
AX_BKRejectFB
,
AX_DumbBellFB
}
KB_AXOPTIONSMASK
KB_AXFBOPTSMASK or KB_AXSKOPTSMASK
KB_GBNDETAILMASK
{
GBN_Types
,
GBN_CompatMap
,
GBN_ClientSymbols
,
GBN_ServerSymbols
,
GBN_IndicatorMap
,
GBN_KeyNames
,
GBN_Geometry
,
GBN_OtherNames
}
KB_BELLDETAILMASK
{
XkbAllBellNotifyEvents
}
KB_MSGDETAILMASK
{
XkbAllActionMessages
}
KB_EVENTTYPE
{
XkbNewKeyboardNotify
,
XkbMapNotify
,
XkbStateNotify
,
XkbControlsNotify
,
XkbIndicatorStateNotify
,
XkbIndicatorMapNotify
,
XkbNamesNotify
,
XkbCompatMapNotify
,
XkbBellNotify
,
XkbActionMessage
,
XkbAccessXNotify
,
XkbExtensionDeviceNotify
}
KB_ACTION
[ type: CARD8
data: LISTofCARD8 ]
KB_BEHAVIOR
[ type: CARD8, data: CARD 8 ]
KB_MODDEF
[ mask: KEYMASK,
mods: KEYMASK,
vmods: KB_VMODMASK ]
KB_KTMAPENTRY
[ active: BOOL,
level: CARD8,
mods: KB_MODDEF ]
KB_KTSETMAPENTRY
[ level: CARD8,
mods: KB_MODDEF ]
KB_KEYTYPE
[ mods: KB_MODDEF,
numLevels: CARD8,
map: LISTofKB_KTMAPENTRY,
preserve: LISTofKB_MODDEF ]
KB_SETKEYTYPE
[ realMods: KEYMASK,
vmods: CARD16,
numLevels: CARD8,
map: LISTofKB_KTSETMAPENTRY,
preserve: LISTofKB_MODDEF ]
KB_KEYSYMMAP
[ ktIndex: LISTofCARD8, width: CARD8
numGroups: 0…4,
groupsWrap: KB_GROUPSWRAP,
redirectGroup: 0…3,
syms: LISTofKEYSYM ]
KB_KEYVMODMAP
[ key: KEYCODE, vmods: CARD16 ]
KB_KEYMODMAP
[ key: KEYCODE, mods: KEYMASK ]
KB_EXPLICITMASK
{
ExplicitKeyType1
,
ExplicitKeyType2
,
ExplicitKeyType3
,
ExplicitKeyType4
,
ExplicitInterpret
,
ExplicitAutoRepeat
,
ExplicitBehavior
,
ExplicitVModMap
}
KB_INDICATORMASK
CARD32, each bit corresponds to an indicator
KB_IMFLAGS
{
IM_NoExplicit
,
IM_NoAutomatic
,
IM_LEDDrivesKB
}
KB_IMMODSWHICH
{
IM_UseNone
,
IM_UseBase
,
IM_UseLatched
,
IM_UseLocked
,
IM_UseEffective
,
IM_UseCompat
}
KB_IMGROUPSWHICH
{
IM_UseNone
,
IM_UseBase
,
IM_UseLatched
,
IM_UseLocked
,
IM_UseEffective
}
KB_INDICATORMAP
[ flags: CARD8,
mods: KB_MODDEF,
whichMods:
groups: KB_GROUPMASK,
whichGroups:
ctrls: KB_BOOLCTRLMASK ]
KB_SYMINTERPMATCH
{
SI_NoneOf
,
SI_AnyOfOrNone
,
SI_AnyOf
,
SI_AllOf
,
SI_Exactly
}
KB_SYMINTERP
[ sym: KEYSYM,
mods; KEYMASK,
levelOneOnly: BOOL,
match: KB_SYMINTERPMATCH,
virtualMod: CARD8,
autoRepeat: BOOL,
lockingKey: BOOL ]
KB_PCFMASK
{
PCF_DetectableAutorepeat
,
PCF_GrabsUseXkbState
,
PCF_AutoResetControls
,
PCF_LookupStateWhenGrabbed
,
PCF_SendEventUsesXKBState
}
KB_LCFLAGSMASK
{
LC_Hidden
,
LC_Default
,
LC_Partial
}
KB_LCSYMFLAGSMASK
{
LC_AlphanumericKeys
,
LC_ModifierKeys
,
LC_KeypadKeys
,
LC_FunctionKeys
,
LC_AlternateGroup
}
These types are used by the
XkbGetGeometry
and
XkbSetGeometry
requests:
Name
Value
KB_PROPERTY
[ name, value: STRING8 ]
KB_POINT
[ x, y: CARD16 ]
KB_OUTLINE
[ cornerRadius: CARD8, points: LISTofKB_POINT ]
KB_SHAPE
[ name: ATOM, outlines: LISTofKB_OUTLINE
primaryNdx, approxNdx: CARD8 ]
KB_KEYNAME
[ name: LISTofCHAR ]
KB_KEYALIAS
[ real: LISTofCHAR, alias: LISTofCHAR ]
KB_KEY
[ name: KB_KEYNAME, gap: INT16,
shapeNdx, colorNdx: CARD8 ]
KB_ROW
[ top, left: INT16, vertical: BOOL, keys LISTofKB_KEY ]
KB_OVERLAYKEY
[ over, under: KB_KEYNAME ]
KB_OVERLAYROW
[ rowUnder: CARD8, keys: LISTofKB_OVERLAYKEY ]
KB_OVERLAY
[ sectionUnder: CARD8,
rows: LISTofKB_OVERLAYROW ]
KB_SHAPEDOODAD
[ name: ATOM, priority: CARD8, top, left: INT16,
type: { SolidDoodad, OutlineDoodad },
angle: INT16, width, height: CARD16
colorNdx, shapeNdx: CARD8 ]
KB_TEXTDOODAD
[ name: ATOM, priority: CARD8, top, left: INT16,
angle: INT16, width, height: CARD16,
colorNdx: CARD8, text: STRING8, font: STRING8 ]
KB_INDICATORDOODAD
[ name: ATOM, priority: CARD8, top, left: INT16,
angle: INT16,
shapeNdx, onColorNdx, offColorNdx: CARD8 ]
KB_LOGODOODAD
[ name: ATOM, priority: CARD8, top, left: INT16,
angle: INT16, colorNdx, shapeNdx: CARD8,
logoName: STRING8 ]
KB_DOODAD
KB_SHAPEDOODAD, or KB_TEXTDOODAD, or KB_INDICATORDOODAD, or
KB_LOGODOODAD
KB_SECTION
[ name: ATOM,
top, left, angle: INT16,
width, height: CARD16,
priority: CARD8,
rows: LISTofKB_ROW,
doodads: LISTofKB_DOODAD,
overlays: LISTofKB_OVERLAY ]
These types are used by
XkbGetDeviceInfo
and
XkbSetDeviceInfo
:
Name
Value
KB_XIDEVFEATUREMASK
{
XI_ButtonActions
,
XI_IndicatorNames
,
XI_IndicatorMaps
,
XI_IndicatorState
}
KB_XIFEATUREMASK
{ KB_XIDEVFEATURES or
XI_Keyboards
KB_XIDETAILMASK
{ KB_XIFEATURES or
XI_UnsupportedFeature
}
KB_DEVICELEDINFO
[ ledClass: KB_LEDCLASSSPEC,
ledID: KB_IDSPEC,
physIndicators: CARD32,
state: CARD32,
names: LISTofATOM,
maps: LISTofKB_INDICATORMAP ]
Requests
This section lists all of the requests supported by the X Keyboard Extension,
separated into categories of related requests.
Initializing the X Keyboard Extension
XkbUseExtension
wantedMajor, wantedMinor: CARD16
supported: BOOL
serverMajor, serverMinor: CARD16
This request enables XKB extension capabilities for the client that issues the
request; the
wantedMajor
and
wantedMinor
fields specify the extension version in use by the requesting client. The
supported
field is
True
if the server supports a compatible version,
False
otherwise. The
serverMajor
and
serverMinor
fields return the actual version supported by the server.
Until a client explicitly and successfully requests the XKB extension, an XKB
capable server reports compatibility state in all core protocol events and
requests. Once a client asks for XKB extension semantics by issuing this
request, the server reports the extended XKB keyboard state in some core
protocol events and requests, as described in the overview section of this
specification.
Clients should issue an
XkbUseExtension
request before using any other extension requests.
Selecting Events
XkbSelectEvents
deviceSpec: KB_DEVICESPEC
affectWhich, clear, selectAll: KB_EVENTTYPE
affectMap, map: KB_MAPPARTMASK
details: LISTofITEMs
Errors:
Keyboard
,
Match
,
Value
This request updates the event masks of the keyboard indicated by
deviceSpec
for this client. If
deviceSpec
specifies an illegal device, a
Keyboard
error results.
The
affectMap
and
map
fields specify changes to the event details mask for the
XkbMapNotify
event. If any map components are set in
map
but not in
affectMap
, a
Match
error results. Otherwise, any map components that are set in
affectMap
are set or cleared in the map notify details mask, depending on the value of
the corresponding field in
map
.
The
affectWhich
,
clear
, and
selectAll
fields specify changes to any other event details masks. If any event types
are set in both
clear
and
selectAll
, a
Match
error results; if any event types are specified in either
clear
or
selectAll
but not in
affectWhich
, a
Match
error results. Otherwise, the detail masks for any event types specified in
the
affectWhich
field of this request are changed as follows:
If the event type is also set in
clear
, the detail mask for the corresponding event is set to
0
or
False
, as appropriate.
If the event type is also set in
selectAll
, the detail mask for the corresponding event is set to include all legal
detail values for that type.
If the event type is not set in either
clear
or
selectAll
, the corresponding element of
details
lists a set of explicit changes to the details mask for the event, as
described below.
Each entry of the
details
list specifies changes to the event details mask for a single type of event,
and consists of an
affects
mask and a
values
mask. All details that are specified in
affects
are set to the corresponding value from
values
; if any details are listed in
values
but not in
affects
, a
Match
error results.
The details list contains entries only for those event types, if any, that are
listed in the
affectWhich
mask and not in either
clear
or
selectAll
. When present, the items of the
details
list appear in the following order:
Event Type
Legal Details
Type
XkbNewKeyboardNotify
KB_NKNDETAILSMASK
CARD16
XkbStateNotify
KB_STATEPARTMASK
CARD16
XkbControlsNotify
KB_CONTROLMASK
CARD32
XkbIndicatorMapNotify
KB_INDICATORMASK
CARD32
XkbIndicatorStateNotify
KB_INDICATORMASK
CARD32
XkbNamesNotify
KB_NAMEDETAILMASK
CARD16
XkbCompatMapNotify
KB_CMDETAILMASK
CARD8
XkbBellNotify
KB_BELLDETAILMASK
CARD8
XkbActionMessage
KB_MSGDETAILMASK
CARD8
XkbAccessXNotify
KB_AXNDETAILMASK
CARD16
XkbExtensionDeviceNotify
KB_XIDETAILMASK
CARD16
Detail masks for event types that are not specified in
affectWhich
are not changed.
If any components are specified in a client’s event masks, the X server sends
the client an appropriate event whenever any of those components change state.
Unless explicitly modified, all event detail masks are empty.
Generating Named Keyboard Bells
XkbBell
deviceSpec: KB_DEVICESPEC
bellClass: KB_BELLCLASSSPEC
bellID: KB_IDSPEC
percent: INT8
forceSound: BOOL
eventOnly: BOOL
pitch, duration: INT16
name: ATOM
window: WINDOW
Errors:
Keyboard
,
Value
,
Match
This request generates audible bells and/or
XkbBellNotify
events for the bell specified by the
bellClass
and
bellID
on the device specified by
deviceSpec
at the specified
pitch
,
duration
and volume (
percent
). If deviceSpec specifies a device that does not have a bell or keyboard
feedback, a
Keyboard
error results.
If both
forceSound
and
eventOnly
are set, this request yields a
Match
error. Otherwise, if
forceSound
is
True
, this request always generates a sound and never generates an event; if
eventOnly
is
True
, it causes an event but no sound. If neither
forceSound
nor
eventOnly
are
True
, this request always generates an event; if the keyboard’s global
AudibleBell
control is enabled, it also generates a sound.
Any bell event generated by this request contains all of the information about
the bell that was requested, including the symbolic name specified by
name
and the event window specified by window. The
name
and
window
are not directly interpreted by XKB, but they must have the value
None
or specify a legal Atom or Window, respectively.
XkbBellNotify
events generated in response to core protocol or X input extension bell
requests always report
None
as their
name
.
The
bellClass
,
bellID
, and
percent
fields are interpreted as for the X input extension
DeviceBell
request. If
pitch
and
duration
are zero, the server uses the corresponding values for that bell from the core
protocol or input extension, otherwise
pitch
and
duration
are interpreted as for the core protocol
ChangeKeyboardControl
request; if they do not include legal values, a
Value
error results. The
window
field must specify a legal Window or have the value
None
, or a
Value
error results. The name field must specify a legal Atom or have the value
None
, or an
Atom
error results. If an error occurs, this request has no other effect (i.e. does
not cause a sound or generate an event).
The
pitch
,
volume
, and
duration
are suggested values for the bell, but XKB does not require the server to
honor them.
Querying and Changing Keyboard State
XkbGetState
deviceSpec: KB_DEVICESPEC
deviceID: CARD8
mods, baseMods, latchedMods, lockedMods: KEYMASK
group, lockedGroup: KB_GROUP
baseGroup, latchedGroup: INT16
compatState: KEYMASK
grabMods, compatGrabMods: KB_GROUP
lookupMods, compatLookupMods: KEYMASK
ptrBtnState: BUTMASK
Errors:
Keyboard
This request returns a detailed description of the current state of the
keyboard specified by
deviceSpec
.
The
deviceID
return value contains the input extension identifier for the specified device,
or
0
if the server does not support the input extension.
The
baseMods
return value reports the modifiers that are set because one or more modifier
keys are logically down. The
latchedMods
and
lockedMods
return values report the modifiers that are latched or locked respectively.
The
mods
return value reports the effective modifier mask which results from the
current combination of base, latched and locked modifiers.
The
baseGroup
return value reports the group state selected by group shift keys that are
logically down. The
latchedGroup
and
lockedGroup
return values detail the effects of latching or locking group shift keys and
XkbLatchLockState
requests. The
group
return value reports the effective keyboard group which results from the
current combination of base, latched and locked group values.
The
lookupMods
return value reports the lookup modifiers, which consist of the current
effective modifiers minus any server internal modifiers. The
grabMods
return value reports the grab modifiers, which consist of the lookup modifiers
minus any members of the ignore locks mask that are not either latched or
logically depressed.
The
ptrBtnState
return value reports the current logical state of up to five buttons on the
core pointer device.
The
compatState
return value reports the compatibility state that corresponds to the effective
keyboard group and modifier state. The
compatLookupMods
and
compatGrabMods
return values report the core protocol compatibility states that correspond to
the XKB lookup and grab state. All of the compatibility states are computed by
applying the group compatibility mapping to the corresponding XKB modifier and
group states, as described in
XkbLatchLockState
deviceSpec: KB_DEVICESPEC
affectModLocks, modLocks: KEYMASK
lockGroup: BOOL
groupLock: KB_GROUP
affectModLatches,modLatches: KEYMASK
latchGroup: BOOL
groupLatch: INT16
Errors:
Keyboard
,
Value
This request locks or latches keyboard modifiers and group state for the device
specified by
deviceSpec
. If
deviceSpec
specifies an illegal or non-keyboard device, a
Keyboard
error occurs.
The locked state of any modifier specified in the
affectModLocks
mask is set to the corresponding value from
modLocks
. If
lockGroup
is
True
, the locked keyboard group is set to the group specified by
groupLock
. If any modifiers are set in
modLocks
but not
affectModLocks
, a
Match
error occurs.
The latched state of any modifier specified in the
affectModLatches
mask is set to the corresponding value from
modLatches
. If
latchGroup
is
True
, the latched keyboard group is set to the group specified by
groupLatch
. if any modifiers are set in
modLatches
but not in
affectModLatches
, a
Match
error occurs.
If the locked group exceeds the maximum number of groups permitted for the
specified keyboard, it is wrapped or truncated back into range as specified by
the global
GroupsWrap
control. No error results from an out-of-range group specification.
After changing the locked and latched modifiers and groups as specified, the X
server recalculates the effective and compatibility keyboard state and
generates
XkbStateNotify
events as appropriate if any state components have changed. Changing the
keyboard state might also turn indicators on or off which can cause
XkbIndicatorStateNotify
events as well.
If any errors occur, this request has no effect.
Querying and Changing Keyboard Controls
XkbGetControls
deviceSpec: KB_DEVICESPEC
deviceID: CARD8
mouseKeysDfltBtn: CARD8
numGroups: CARD8
groupsWrap: KB_GROUPINFO
internalMods,ignoreLockMods: KB_MODDEF
repeatDelay,repeatInterval: CARD16
slowKeysDelay, debounceDelay: CARD16
mouseKeysDelay, mouseKeysInterval: CARD16
mouseKeysTimeToMax, mouseKeysMaxSpeed: CARD16
mouseKeysCurve: INT16
accessXOptions: KB_AXOPTIONMASK
accessXTimeout: CARD16
accessXTimeoutOptionsMask, accessXTimeoutOptionValues: CARD16
accessXTimeoutMask,accessXTimeoutValues: CARD32
enabledControls: KB_BOOLCTRLMASK
perKeyRepeat: LISTofCARD8
Errors:
Keyboard
This request returns the current values and status of all controls for the
keyboard specified by
deviceSpec
. If
deviceSpec
specifies an illegal device a
Keyboard
error results. On return, the
deviceID
specifies the identifier of the requested device or zero if the server does
not support the input extension.
The
numGroups
return value reports the current number of groups, and
groupsWrap
reports the treatment of out-of-range groups, as described in
internalMods
and
ignoreLockMods
return values report the current values of the server internal and ignore
locks modifiers as described in
The
repeatDelay
,
repeatInterval
,
slowKeysDelay
and
debounceDelay
fields report the current values of the for the autorepeat delay, autorepeat
interval, slow keys delay and bounce keys timeout, respectively. The
mouseKeysDelay
,
mouseKeysInterval
,
mouseKeysTimeToMax
and
mouseKeysMaxSpeed
and
mouseKeysCurve
return values report the current acceleration applied to mouse keys, as
described in
The
mouseKeysDfltBtn
return value reports the current default pointer button for which events are
synthesized by the mouse keys server actions.
The
accessXOptions
return value reports the current settings of the various AccessX options flags
which govern the behavior of the
StickyKeys
control and of AccessX feedback.
The
accessXTimeout
return value reports the length of time, in seconds, that the keyboard must
remain idle before AccessX controls are automatically changed; an
accessXTimeout
of
0
indicates that AccessX controls are not automatically changed. The
accessXTimeoutMask
specifies the boolean controls to be changed if the AccessX timeout expires;
the
accessXTimeoutValues
field specifies new values for all of the controls in the timeout mask. The
accessXTimeoutOptionsMask
field specifies the AccessX options to be changed when the AccessX timeout
expires; the
accessXTimeoutOptionValues
return value reports the values to which they will be set.
The
enabledControls
return value reports the current state of all of the global boolean controls.
The
perKeyRepeat
array consists of one bit per key and reports the current autorepeat behavior
of each keyboard key; if a bit is set in
perKeyRepeat
, the corresponding key repeats if it is held down while global keyboard
autorepeat is enabled. This array parallels the core protocol and input
extension keyboard controls, if the autorepeat behavior of a key is changed via
the core protocol or input extension, those changes are automatically reflected
in the
perKeyRepeat
array.
XkbSetControls
deviceSpec: KB_DEVICESPEC
affectInternalRealMods, internalRealMods: KEYMASK
affectInternalVirtualMods,internalVirtualMods: KB_VMODMASK
affectIgnoreLockRealMods,ignoreLockRealMods: KB_MODMASK
affectIgnoreLockVirtualMods,ignoreLockVirtualMods: KB_VMODMASK
mouseKeysDfltBtn: CARD8
groupsWrap: KB_GROUPINFO
accessXOptions: CARD16
affectEnabledControls: KB_BOOLCTRLMASK
enabledControls: KB_BOOLCTRLMASK
changeControls: KB_CONTROLMASK
repeatDelay,repeatInterval: CARD16
slowKeysDelay, debounceDelay: CARD16
mouseKeysDelay, mouseKeysInterval: CARD16
mouseKeysTimeToMax, mouseKeysMaxSpeed: CARD16
mouseKeysCurve: INT16
accessXTimeout: CARD16
accessXTimeoutMask, accessXTimeoutValues: KB_BOOLCTRLMASK
accessXTimeoutOptionsMask,accessXTimeoutOptionsValues: CARD16
perKeyRepeat: LISTofCARD8
Errors:
Keyboard
,
Value
This request sets the keyboard controls indicated in
changeControls
for the keyboard specified by
deviceSpec
. Each bit that is set in
changeControls
indicates that one or more of the other request fields should be applied, as
follows:
Bit in changeControls
Field(s) to be Applied
XkbRepeatKeysMask
repeatDelay
,
repeatInterval
XkbSlowKeysMask
slowKeysDelay
XkbStickyKeysMask
accessXOptions
(only the
XkbAX_TwoKeys
and the
XkbAX_LatchToLock
options are affected)
XkbBounceKeysMask
debounceDelay
XkbMouseKeysMask
mouseKeysDfltBtn
XkbMouseKeysAccelMask
mouseKeysDelay
,
mouseKeysInterval
,
mouseKeysCurve
,
mouseKeysTimeToMax
,
mouseKeysMaxSpeed
XkbAccessXKeysMask
accessXOptions (all options)
XkbAccessXTimeoutMask
accessXTimeout
,
accessXTimeoutMask
,
accessXTimeoutValues
,
accessXTimeoutOptionsMask
,
accessXTimeoutOptionsValues
XkbAccessXFeedbackMask
accessXOptions
(all options except those affected by the
XkbStickyKeysMask
bit)
XkbGroupsWrapMask
groupsWrap
XkbInternalModsMask
affectInternalRealMods
,
internalRealMods
,
affectInternalVirtualMods
,
internalVirtualMods
XkbIgnoreLockModsMask
affectIgnoreLockRealMods
,
ignoreLockRealMods
,
affectIgnoreLockVirtualMods
,
ignoreLockVirtualMods
XkbPerKeyRepeatMask
perKeyRepeat
XkbControlsEnabledMask
affectEnabledControls
,
enabledControls
If any other bits are set in
changeControls
, a
Value
error results. If any of the bits listed above are not set in
changeControls
, the corresponding fields must have the value
0
, or a
Match
error results.
If applied,
repeatDelay
and
repeatInterval
change the autorepeat characteristics of the keyboard, as described in
repeatDelay
and
repeatInterval
must both be non-zero or a
Value
error results.
If applied, the
slowKeysDelay
field specifies a new delay for the
SlowKeys
control, as defined in
slowKeysDelay
must be non-zero, or a
Value
error results.
If applied, the
debounceDelay
field specifies a new delay for the
BounceKeys
control, as described in
debounceDelay
must be non-zero or a
Value
error results.
If applied, the
mouseKeysDfltBtn
field specifies the core pointer button for which events are generated
whenever a
SA_PtrBtn
or
SA_LockPtrBtn
key action is activated. If present,
mouseKeysDfltBtn
must specify a legal button for the core pointer device, or a
Value
error results.
SA_PtrBtn
and
SA_LockPtrBtn
actions in more detail.
If applied, the
mouseKeysDelay
,
mouseKeysInterval
,
mouseKeysTimeToMax
,
mouseKeysMaxSpeed
and
mouseKeysCurve
fields change the rate at which the pointer moves when a key which generates a
SA_MovePtr
action is held down.
MouseKeysAccel
parameters in more detail. If defined, the
mouseKeysDelay
,
mouseKeysInterval
,
mouseKeysTimeToMax
and
mouseKeysMaxSpeed
values must all be greater than zero, or a
Value
error results. The
mouseKeysCurve
value must be greater than
-1000
or a
Value
error results.
If applied, the
accessXOptions
field sets the AccessX options, which are described in detail in
XkbStickyKeysMask
and
XkbAccessXFeedbackMask
are set in
changeControls
and
XkbAccessXKeysMask
is not, only a subset of the AccessX options are changed, as described in the
table above; if both are set or if the
AccessXKeys
bit is set in
changeControls
, all of the AccessX options are updated. Any bit in
accessXOptions
whose interpretation is undefined must be zero, or a
Value
error results.
If applied, the
accessXTimeout
,
accessXTimeoutMask
,
accessXTimeoutValues
,
accessXTimeoutOptionsMask
and
accessXTimeoutOptionsValues
fields change the behavior of the AccessX Timeout control, as described in
accessXTimeout
must be greater than zero, or a
Value
error results. The
accessXTimeoutMask
or
accessXTimeoutValues
fields must specify only legal boolean controls, or a
Value
error results. The
accessXTimeoutOptionsMask
and
accessXTimeoutOptionsValues
fields must contain only legal AccessX options or a
Value
error results. If any bits are set in either values field but not in the
corresponding mask, a
Match
error results.
If present, the
groupsWrap
field specifies the treatment of out-of-range keyboard groups, as described in
groupsWrap
field does not specify a legal treatment for out-of-range groups, a
Value
error results.
If present, the
affectInternalRealMods
field specifies the set of real modifiers to be changed in the internal
modifier definition and the
internalRealMods
field specifies new values for those modifiers. The
affectInternalVirtualMods
and
internalVirtualMods
fields update the virtual modifier component of the modifier definition that
describes the internal modifiers in the same way. If any bits are set in either
values field but not in the corresponding mask field, a
Match
error results.
If present, the
affectIgnoreLockRealMods
field specifies the set of real modifiers to be changed in the ignore locks
modifier definition and the
ignoreLockRealMods
field specifies new values for those modifiers. The
affectIgnoreLockVirtualMods
and
ignoreLockVirtualMods
fields update the virtual modifier component of the ignore locks modifier
definition in the same way. If any bits are set in either values field but not
in the corresponding mask field, a
Match
error results.
If present, the
perKeyRepeat
array specifies the repeat behavior of the individual keyboard keys. The
corresponding core protocol or input extension per-key autorepeat information
is updated to reflect any changes specified in
perKeyRepeat
. If the bits that correspond to any out-of-range keys are set in
perKeyRepeat
, a
Value
error results.
If present, the
affectEnabledControls
and
enabledControls
field enable and disable global boolean controls. Any controls set in both
fields are enabled; any controls that are set in
affectEnabledControls
but not in
enabledControls
are disabled. Controls that are not set in either field are not affected. If
any controls are specified in
enabledControls
but not in
affectEnabledControls
, a
Match
error results. If either field contains anything except boolean controls, a
Value
error results.
Querying and Changing the Keyboard Mapping
XkbGetMap
deviceSpec: KB_DEVICESPEC
full, partial: KB_MAPPARTMASK
firstType, nTypes: CARD8
firstKeySym, firstKeyAction: KEYCODE
nKeySyms, nKeyActions: CARD8
firstKeyBehavior,firstKeyExplicit: KEYCODE
nKeyBehaviors,nKeyExplicit: CARD8
firstModMapKey,firstVModMapKey: KEYCODE
nModMapKeys, nVModMapKeys: CARD8
virtualMods: KB_VMODMASK
deviceID: CARD8
minKeyCode, maxKeyCode: KEYCODE
present: KB_MAPPARTMASK
firstType, nTypes, nTotalTypes: CARD8
firstKeySym, firstKeyAction: KEYCODE
nKeySyms, nKeyActions: CARD8
totalSyms, totalActions: CARD16
firstKeyBehavior, firstKeyExplicit: KEYCODE
nKeyBehaviors, nKeyExplicit: CARD8
totalKeyBehaviors, totalKeyExplicit: CARD8
firstModMapKey, firstVModMapKey: KEYCODE
nModMapKeys, nVModMapKeys: CARD8
totalModMapKeys, totalVModMapKeys: CARD8
virtualMods: KB_VMODMASK
typesRtrn: LISTofKB_KEYTYPE
symsRtrn: LISTofKB_KEYSYMMAP
actsRtrn: { count: LISTofCARD8, acts: LISTofKB_ACTION }
behaviorsRtrn: LISTofKB_SETBEHAVIOR
vmodsRtrn: LISTofSETofKEYMASK
explicitRtrn: LISTofKB_SETEXPLICIT
modmapRtrn: LISTofKB_KEYMODMAP
vmodMapRtrn: LISTofKB_KEYVMODMAP
Errors:
Keyboard
,
Value
,
Match
,
Alloc
This request returns the indicated components of the server and client maps of
the keyboard specified by
deviceSpec
. The
full
mask specifies the map components to be returned in full; the
partial
mask specifies the components for which some subset of the legal elements are
to be returned. The server returns a
Match
error if any component is specified in both
full
and
partial
, or a
Value
error if any undefined bits are set in either
full
or
partial
.
Each bit in the
partial
mask controls the interpretation of one or more of the other request fields,
as follows:
Bit in the Partial Mask
Type
Corresponding Field(s)
XkbKeyTypesMask
key types
firstType
,
nTypes
XkbKeySymsMask
keycodes
firstKeySym
,
nKeySyms
XkbKeyActionsMask
keycodes
firstKeyAction
,
nKeyActions
XkbKeyBehaviorsMask
keycodes
firstKeyBehavior
,
nKeyBehaviors
XkbExplicitComponentsMask
keycodes
firstKeyExplicit
,
nKeyExplicit
XkbModifierMapMask
keycodes
firstModMapKey
,
nModMapKeys
XkbVirtualModMapMask
keycodes
firstVModMapKey
,
nVModMapKeys
XkbVirtualModsMask
virtual modifiers
virtualMods
If any of these keyboard map components are specified in
partial
, the corresponding values must specify a valid subset of the requested
components or this request reports a
Value
error. If a keyboard map component is not specified in
partial
, the corresponding fields must contain zeroes, or a
Match
error results.
If any error is generated, the request aborts and does not report any values.
On successful return, the
deviceID
field reports the X input extension device ID of the keyboard for which
information is being returned, or
0
if the server does not support the X input extension. The
minKeyCode
and
maxKeyCode
return values report the minimum and maximum keycodes that are legal for the
keyboard in question.
The
present
return value lists all of the keyboard map components contained in the reply.
The bits in
present
affect the interpretation of the other return values as follows:
If
XkbKeyTypesMask
is set in
present
:
firstType
and
nTypes
specify the types reported in the reply.
nTotalTypes
reports the total number of types defined for the keyboard
typesRtrn
has
nTypes
elements of type KB_KEYTYPE which describe consecutive key types starting from
firstType
.
If
XkbKeySymsMask
is set in
present
:
firstKeySym
and
nKeySyms
specify the subset of the keyboard keys for which symbols will be reported.
totalSyms
reports the total number of keysyms bound to the keys returned in this reply.
symsRtrn
has
nKeySyms
elements of type KB_KEYSYMMAP, which describe the symbols bound to consecutive
keys starting from
firstKeySym
.
If
XkbKeyActionsMask
is set in
present
:
firstKeyAction
and
nKeyActions
specify the subset of the keys for which actions are reported.
totalActions
reports the total number of actions bound to the returned keys.
The
count
field of the
actsRtrn
return value has
nKeyActions
entries of type CARD8, which specify the number of actions bound to
consecutive keys starting from
firstKeyAction
. The
acts
field of
actsRtrn
has
totalActions
elements of type KB_ACTION and specifies the actions bound to the keys.
If
XkbKeyBehaviorsMask
is set in
present
:
The
firstKeyBehavior
and
nKeyBehaviors
return values report the range of keyboard keys for which behaviors will be
reported.
The
totalKeyBehaviors
return value reports the number of keys in the range to be reported that have
non-default values.
The
behaviorsRtrn
value has
totalKeyBehaviors
entries of type KB_BEHAVIOR. Each entry specifies a key in the range for which
behaviors are being reported and the behavior associated with that key. Any
keys in that range that do not have an entry in
behaviorsRtrn
have the default behavior,
KB_Default
.
If
XkbExplicitComponentsMask
is set in
present
:
The
firstKeyExplicit
and
nKeyExplicit
return values report the range of keyboard keys for which the set of explicit
components is to be returned.
The
totalKeyExplicit
return value reports the number of keys in the range specified by
firstKeyExplicit
and
nKeyExplicit
that have one or more explicit components.
The
explicitRtrn
return value has
totalKeyExplicit
entries of type KB_KEYEXPLICIT. Each entry specifies the a key in the range
for which explicit components are being reported and the explicit components
that are bound to it. Any keys in that range that do not have an entry in
explicitRtrn
have no explicit components.
If
XkbModifierMapMask
is set in
present
:
The
firstModMapKey
and
nModMapKeys
return values report the range of keyboard keys for which the modifier map is
to be reported.
The
totalModMapKeys
return value reports the number of keys in the range specified by
firstModMapKey
and
nModMapKeys
that are bound with to one or more modifiers.
The
modmapRtrn
return value has
totalModMapKeys
entries of type KB_KEYMODMAP. Each entry specifies the a key in the range for
which the modifier map is being reported and the set of modifiers that are
bound to that key. Any keys in that range that do not have an entry in
modmapRtrn
are not associated with any modifiers by the modifier mapping.
If
XkbVirtualModMapMask
is set in
present
:
The
firstVModMapKey
and
nVModMapKeys
return values report the range of keyboard keys for which the virtual modifier
map is to be reported.
The
totalVModMapKeys
return value reports the number of keys in the range specified by
firstVModMapKey
and
nVModMapKeys
that are bound with to or more virtual modifiers.
The
vmodmapRtrn
return value has
totalVModMapKeys
entries of type KB_KEYVMODMAP. Each entry specifies the a key in the range for
which the virtual modifier map is being reported and the set of virtual
modifiers that are bound to that key. Any keys in that range that do not have
an entry in
vmodmapRtrn
are not associated with any virtual modifiers,
If
XkbVirtualModsMask
is set in
present
:
The
virtualMods
return value is a mask with one bit per virtual modifier which specifies the
virtual modifiers for which a set of corresponding real modifiers is to be
returned.
The
vmodsRtrn
return value is a list with one entry of type KEYBUTMASK for each virtual
modifier that is specified in
virtualMods
. The entries in
vmodsRtrn
contain the real modifier bindings for the specified virtual modifiers,
beginning with the lowest-numbered virtual modifier that is present in
virtualMods
and proceeding to the highest.
If any of these bits are not set in
present
, the corresponding numeric fields all have the value zero, and the
corresponding lists are all of length zero.
XkbSetMap
deviceSpec: KB_DEVICESPEC
flags: {
SetMapResizeTypes, SetMapRecomputeActions
}
present: KB_MAPPARTMASK
minKeyCode, maxKeyCode: KEYCODE
firstType, nTypes: CARD8
firstKeySym, firstKeyAction: KEYCODE
nKeySyms, nKeyActions: CARD8
totalSyms, totalActions: CARD16
firstKeyBehavior, firstKeyExplicit: KEYCODE
nKeyBehaviors, nKeyExplicit: CARD8
totalKeyBehaviors, totalKeyExplicit: CARD8
firstModMapKey, firstVModMapKey: KEYCODE
nModMapKeys, nVModMapKeys: CARD8
totalModMapKeys, totalVModMapKeys: CARD8
virtualMods: VMODMASK
types: LISTofKB_KEYTYPE
syms: LISTofKB_KEYSYMMAP
actions: { count: LISTofCARD8, actions: LISTofKB_ACTION }
behaviors: LISTofKB_BEHAVIOR
vmods: LISTofKEYMASK
explicit: LISTofKB_EXPLICIT
modmap: LISTofKB_KEYMODMAP
vmodmap: LISTofKB_KEYVMODMAP
Errors:
Keyboard
,
Value
,
Match
,
Alloc
This request changes the indicated parts of the keyboard specified by
deviceSpec
. With XKB, the effect of a key release is independent of the keyboard mapping
at the time of the release, so this request can be processed regardless of the
logical state of the modifier keys at the time of the request.
The
present
field specifies the keyboard map components contained to be changed. The bits
in
present
affect the interpretation of the other fields as follows:
If
XkbKeyTypesMask
is set in
present
,
firstType
and
nTypes
specify a subset of the key types bound to the keyboard to be changed or
created. The index of the first key type to be changed must be less than or
equal to the unmodified length of the list of key types or a
Value
error results.
If
XkbKeyTypesMask
is set in
present
and
SetMapResizeTypes
is set in
flags
, the server resizes the list of key types bound to the keyboard so that the
last key type specified by this request is the last element in the list. If the
list of key types is shrunk, any existing key definitions that use key types
that eliminated are automatically assigned key types from the list of canonical
key types as described in
XkbMaxTypesPerKey
(32) types; any attempt to reduce the number of types bound to a keyboard
below four or above
XkbMaxTypesPerKey
causes a
Value
error. Symbolic names for newly created key types or levels within a key type
are initialized to
None
.
If
XkbKeyTypesMask
is set in
present
, the types list has
nTypes
entries of type KB_KEYTYPE.Each key type specified in
types
must be valid or a
Value
error results. To be valid a key type definition must meet the following
criteria:
The
numLevels
for the type must be greater than zero.
If the key type is
ONE_LEVEL
(i.e. index zero in the list of key types),
numLevels
must be one.
If the key type is
TWO_LEVEL
or
KEYPAD
, or
ALPHABETIC
(i.e. index one, two, or three in the lest of key types) group width must be
two.
Each key type in types must also be internally consistent, or a Match error
results. To be internally consistent, a key type definition must meet the
following criteria:
Each map entry must specify a resulting level that is legal for the
type.
Any real or virtual modifiers specified in any of the map entries must
also be specified in the
mods
for the type.
If
XkbKeySymsMask
is set in
present
,
firstKeySym
and
nKeySyms
specify a subset of the keyboard keys to which new symbols are to be assigned
and
totalSyms
specifies the total number of symbols to be assigned to those keys. If any of
the keys specified by
firstKeySym
and
nKeySyms
are not legal, a
Match
error results. The
syms
list has
nKeySyms
elements of type KB_KEYSYMMAP. Each key in the resulting key symbol map must
be valid and internally consistent or a
Value
error results. To be valid and internally consistent, a key symbol map must
meet the following criteria:
The key type indices must specify legal result key types.
The number of groups specified by
groupInfo
must be in the range
0…4
.
The
width
of the key symbol map must be equal to
numLevels
of the widest key type bound to the key.
The number of symbols,
nSyms
, must equal the number of groups times
width
.
If
XkbKeyActionsMask
is set in
present
,
firstKeyAction
and
nKeyActions
specify a subset of the keyboard keys to which new actions are to be assigned
and
totalActions
specifies the total number of actions to be assigned to those keys. If any of
the keys specified by
firstKeyAction
and
nKeyActions
are not legal, a
Match
error results. The
count
field of the
actions
return value has
nKeyActions
elements of type CARD8; each element of
count
specifies the number of actions bound to the corresponding key. The
actions
list in the
actions
field has
totalActions
elements of type KB_ACTION. These actions are assigned to each target key in
turn, as specified by
count
. The list of actions assigned to each key must either be empty or have exactly
as many actions as the key has symbols, or a
Match
error results.
If
XkbKeyBehaviorsMask
is set in
present
,
firstKeyBehavior
and
nKeyBehaviors
specify a subset of the keyboard keys to which new behaviors are to be
assigned, and
totalKeyBehaviors
specifies the total number of keys in that range to be assigned non-default
behavior. If any of the keys specified by
firstKeyBehavior
and
nKeyBehaviors
are not legal, a
Match
error results. The
behaviors
list has
totalKeyBehaviors
elements of type KB_BEHAVIOR; each entry of
behaviors
specifies a key in the specified range and a new behavior for that key; any
key that falls in the range specified by
firstBehavior
and
nBehaviors
for which no behavior is specified in
behaviors
is assigned the default behavior,
KB_Default
. The new behaviors must be legal, or a
Value
error results. To be legal, the behavior specified in the
XkbSetMap
request must:
Specify a key in the range indicated by
firstKeyBehavior
and
nKeyBehaviors
.
Not specify the
permanent
flag; permanent behaviors cannot be set or changed using the
XkbSetMap
request.
If present, the
KB_Overlay1
and
KB_Overlay2
behaviors must specify a keycode for the overlay key that is valid for the
current keyboard.
If present, the
KB_RadioGroup
behavior must specify a legal index (0…31) for the radio group to which the
key belongs.
Key behaviors that are not recognized by the server are accepted but ignored.
Attempts to replace a "permanent" behavior are silently ignored; the behavior
is not replaced, but not error is generated and any other components specified
in the
XkbSetMap
request are updated, as appropriate.
If
XkbVirtualModsMask
is set in
present
,
virtualMods
is a mask which specifies the virtual modifiers to be rebound. The
vmods
list specifies the real modifiers that are bound to each of the virtual
modifiers specified in
virtualMods
, starting from the lowest numbered virtual modifier and progressing upward.
Any virtual modifier that is not specified in
virtualMods
has no corresponding entry in
vmods
, so the
vmods
list has one entry for each bit that is set in
virtualMods
.
If
XkbExplicitComponentsMask
is set in
present
,
firstKeyExplicit
and
nKeyExplicit
specify a subset of the keyboard keys to which new explicit components are to
be assigned, and
totalKeyExplicit
specifies the total number of keys in that range that have at least one
explicit component. The
explicit
list has
totalKeyExplicit
elements of type KB_KEYEXPLICIT; each entry of
explicit
specifies a key in the specified range and a new set of explicit components
for that key. Any key that falls in the range specified by
firstKeyExplicit
and
nKeyExplicit
that is not assigned some value in
explicit
has no explicit components.
If
XkbModifierMapMask
is set in
present
,
firstModMapKey
and
nModMapKeys
specify a subset of the keyboard keys for which new modifier mappings are to
be assigned, and
totalModMapKeys
specifies the total number of keys in that range to which at least one
modifier is bound. The
modmap
list has
totalModMapKeys
elements of type KB_KEYMODMAP; each entry of
modmap
specifies a key in the specified range and a new set of modifiers to be
associated with that key. Any key that falls in the range specified by
firstModMapKey
and
nModMapKeys
that is not assigned some value in
modmap
has no associated modifiers.
If the modifier map is changed by the
XkbSetMap
request, any changes are also reflected in the core protocol modifier mapping.
Changes to the core protocol modifier mapping are reported to XKB-unaware
clients via
MappingNotify
events and can be retrieved with the core protocol
GetModifierMapping
request.
If
XkbVirtualModMapMask
is set in
present
,
firstVModMapKey
and
nVModMapKeys
specify a subset of the keyboard keys for which new modifier mappings are to
be assigned, and
totalVModMapKeys
specifies the total number of keys in that range to which at least one virtual
modifier is bound. The
vmodmap
list has
totalVModMapKeys
elements of type KB_KEYVMODMAP; each entry of
vmodmap
specifies a key in the specified range and a new set of virtual modifiers to
be associated with that key. Any key that falls in the range specified by
firstVModMapKey
and
nVModMapKeys
that is not assigned some value in
vmodmap
has no associated virtual modifiers.
If the resulting keyboard map is legal, the server updates the keyboard map.
Changes to some keyboard components have indirect effects on others:
If the
XkbSetMapRecomputeActions
bit is set in
flags
, the actions associated with any keys for which symbol or modifier bindings
were changed by this request are recomputed as described in
after
any actions specified in this request are bound to keys, so the actions
specified in this request might be clobbered by the automatic assignment of
actions to keys.
If the group width of an existing key type is changed, the list of symbols
associated with any keys of the changed type might be resized accordingly. If
the list increases in size, any unspecified new symbols are initialized to
NoSymbol
.
If the list of actions associated with a key is not empty, changing the key
type of the key resizes the list. Unspecified new actions are calculated by
applying any keyboard symbol interpretations to the corresponding symbols.
The number of groups global to the keyboard is always equal to the largest
number of groups specified by any of the key symbol maps. Changing the number
of groups in one or more key symbol maps may change the number of groups global
to the keyboard.
Assigning key behavior
KB_RadioGroup
to a key adds that key as a member of the specified radio group. Changing a
key with the existing behavior
KB_RadioGroup
removes that key from the group. Changing the elements of a radio group can
cause synthetic key press or key release events if the key to be added or
removed is logically down at the time of the change.
Changing a key with behavior
KB_Lock
causes a synthetic key release event if the key is logically but not
physically down at the time of the change.
This request sends an
XkbMapNotify
event which reflects both explicit and indirect map changes to any interested
clients. If any symbolic names are changed, it sends a
XkbNamesNotify
reflecting the changes to any interested clients. XKB-unaware clients are
notified of keyboard changes via core protocol
MappingNotify
events.
Key press and key release events caused by changing key behavior may cause
additional
XkbStateNotify
or
XkbIndicatorStateNotify
events.
Querying and Changing the Compatibility Map
XkbGetCompatMap
deviceSpec: KB_DEVICESPEC
groups: KB_GROUPMASK
getAllSI: BOOL
firstSI, nSI: CARD16
deviceID: CARD8
groupsRtrn: KB_GROUPMASK
firstSIRtrn, nSIRtrn, nTotalSI: CARD16
siRtrn: LISTofKB_SYMINTERP
groupRtrn: LISTofKB_MODDEF
Errors:
Keyboard
,
Match
,
Alloc
This request returns the listed compatibility map components for the keyboard
specified by
deviceSpec
. If
deviceSpec
does not specify a valid keyboard device, a
Keyboard
Error results. On return,
deviceID
reports the input extension identifier of the keyboard device or
0
if the server does not support the input extension.
If
getAllSI
is
False
,
firstSI
and
nSI
specify a subset of the symbol interpretations to be returned; if used,
nSI
must be greater than
0
and all of the elements specified by
firstSI
and
nSI
must be defined or a
Value
error results. If
getAllSyms
is
True
, the server ignores
firstSym
and
nSyms
and returns all of the symbol interpretations defined for the keyboard.
The
groups
mask specifies the groups for which compatibility maps are to be returned.
The
nTotalSI
return value reports the total number of symbol interpretations defined for
the keyboard. On successful return, the
siRtrn
return list contains the definitions for
nSIRtrn
symbol interpretations beginning at
firstSIRtrn
.
The
groupRtrn
return values report the entries in the group compatibility map for any groups
specified in the
groupsRtrn
return value.
XkbSetCompatMap
deviceSpec: KB_DEVICESPEC
recomputeActions: BOOL
truncateSI: BOOL
groups: KB_GROUPMASK
firstSI, nSI: CARD16
si: LISTofKB_SYMINTERPRET
groupMaps: LISTofKB_MODDEF
Errors:
Keyboard
,
Match
,
Value
,
Alloc
This request changes a specified subset of the compatibility map of the
keyboard indicated by
deviceSpec
. If
deviceSpec
specifies an invalid device, a
Keyboard
error results and nothing is changed.
The
firstSI
and
nSI
fields specify a subset of the keyboard symbol interpretations to be changed.
The
si
list specifies new values for each of the interpretations in that range.
The first symbol interpretation to be changed,
firstSI
, must be less than or equal to the unchanged length of the list of symbol
interpretations, or a
Value
error results. If the resulting list would be larger than the unchanged list,
it server list of symbol interpretations is automatically increased in size.
Otherwise, if
truncateSyms
is
True
, the server deletes any symbol interpretations after the last element changed
by this request, and reduces the length of the list accordingly.
The
groupMaps
fields contain new definitions for a subset of the group compatibility map;
groups
specifies the group compatibility map entries to be updated from
groupMaps
.
All changed compatibility maps and symbol interpretations must either ignore
group state or specify a legal range of groups, or a
Value
error results.
If the
recomputeActions
field is
True
, the server regenerates recalculates the actions bound to all keyboard keys by
applying the new symbol interpretations to the entire key symbol map, as
described in
Querying and Changing Indicators
XkbGetIndicatorState
deviceSpec: KB_DEVICESPEC
deviceID: CARD8
state: KB_INDICATORMASK
Errors:
Keyboard
This request reports the current state of the indicators for the keyboard
specified by
deviceSpec
. If
deviceSpec
does not specify a valid keyboard, a
Keyboard
error results.
On successful return, the
deviceID
field reports the input extension identifier of the keyboard or
0
if the server does not support the input extension. The
state
return value reports the state of each of the thirty-two indicators on the
specified keyboard. The least-significant bit corresponds to indicator 0, the
most significant bit to indicator 31; if a bit is set, the corresponding
indicator is lit.
XkbGetIndicatorMap
deviceSpec: KB_DEVICESPEC
which: KB_INDICATORMASK
deviceID: CARD8
which: KB_INDICATORMASK
realIndicators: KB_INDICATORMASK
nIndicators: CARD8
maps: LISTofKB_INDICATORMAP
Errors:
Keyboard
,
Value
This request returns a subset of the maps for the indicators on the keyboard
specified by
deviceSpec
. If
deviceSpec
does not specify a valid keyboard device, a
Keyboard
error results.
The
which
field specifies the subset to be returned; a set bit in the which field
indicates that the map for the corresponding indicator should be returned.
On successful return, the
deviceID
field reports the input extension identifier of the keyboard or
0
if the server does not support the input extension. Any indicators specified
in
realIndicators
are actually present on the keyboard; the rest are virtual indicators. Virtual
indicators do not directly cause any visible or audible effect when they change
state, but they do cause
XkbIndicatorStateNotify
events.
The
maps
return value reports the requested indicator maps. Indicator maps are
described in
XkbSetIndicatorMap
deviceSpec: KB_DEVICESPEC
which: KB_INDICATORMASK
maps: LISTofKB_INDICATORMAP
Errors:
Keyboard
,
Value
This request changes a subset of the maps on the keyboard specified by
deviceSpec
. If
deviceSpec
does not specify a valid keyboard device, a
Keyboard
error results.
The
which
field specifies the subset to be changed; the
maps
field contains the new definitions.
If successful, the new indicator maps are applied immediately. If any
indicators change state as a result of the new maps, the server generates
XkbIndicatorStateNotify
events as appropriate.
XkbGetNamedIndicator
deviceSpec: KB_DEVICESPEC
ledClass: KB_LEDCLASSSPEC
ledID: KB_IDSPEC
indicator: ATOM
deviceID: CARD8
supported: BOOL
indicator: ATOM
found: BOOL
on: BOOL
realIndicator: BOOL
ndx: CARD8
map: KB_INDICATORMAP
Errors:
Keyboard
,
Atom
,
Value
This request returns information about the indicator specified by
ledClass
,
ledID
, and
indicator
on the keyboard specified by
deviceSpec
. The
indicator
field specifies the name of the indicator for which information is to be
returned.
If
deviceSpec
does not specify a device with indicators, a
Keyboard
error results. If
ledClass
does not have the value
DfltXIClass
,
LedFeedbackClass
, or
KbdFeedbackClass
, a
Value
error results. If
ledID
does not have the value
DfltXIId
or specify the identifier of a feedback of the class specified by
ledClass
on the device specified by
deviceSpec
, a
Match
error results. If
indicator
is not a valid ATOM other than
None
, an
Atom
error results.
This request is always supported with default class and identifier on the core
keyboard device. If the request specifies a device other than the core keyboard
device or a feedback class and identifier other than the defaults, and the
server does not support indicator names or indicator maps for extension
devices, the
supported
return value is
False
and the values of the other fields in the reply are undefined. If the client
which issued the unsupported request has also selected to do so, it will also
receive an
XkbExtensionDeviceNotify
event which reports the attempt to use an unsupported feature, in this case
one or both of
XkbXI_IndicatorMaps
or
XkbXI_IndicatorNames
.
Otherwise,
supported
is
True
and the
deviceID
field reports the input extension identifier of the keyboard or
0
if the server does not support the input extension. The
indicator
return value reports the name for which information was requested and the
found
return value is
True
if an indicator with the specified name was found on the device.
If a matching indicator was found:
The
on
return value reports the state of the indicator at the time of the request.
The
realIndicator
return value is
True
if the requested indicator is actually present on the keyboard or
False
if it is virtual.
The
ndx
return value reports the index of the indicator in the requested feedback.
The
map
return value reports the indicator map used by to automatically change the
state of the specified indicator in response to changes in keyboard state or
controls.
If no matching indicator is found, the
found
return value is
False
, and the
on
,
realIndicator
,
ndx
, and
map
return values are undefined.
XkbSetNamedIndicator
deviceSpec: KB_DEVICESPEC
ledClass: KB_LEDCLASSSPEC
ledID: KB_IDSPEC
indicator: ATOM
setState: BOOL
on: BOOL
setMap: BOOL
createMap: BOOL
map: KB_SETINDICATORMAP
Errors:
Keyboard
,
Atom
,
Access
This request changes various aspects of the indicator specified by
ledClass
,
ledID
, and
indicator
on the keyboard specified by
deviceSpec
. The
indicator
argument specifies the name of the indicator to be updated.
If
deviceSpec
does not specify a device with indicators, a
Keyboard
error results. If
ledClass
does not have the value
DfltXIClass
,
LedFeedbackClass
, or
KbdFeedbackClass
, a
Value
error results. If
ledID
does not have the value
DfltXIId
or specify the identifier of a feedback of the class specified by
ledClass
on the device specified by
deviceSpec
, a
Match
error results. If
indicator
is not a valid ATOM other than
None
, an
Atom
error results.
This request is always supported with default class and identifier on the core
keyboard device. If the request specifies a device other than the core keyboard
device or a feedback class and identifier other than the defaults, and the
server does not support indicator names or indicator maps for extension
devices, the
supported
return value is
False
and the values of the other fields in the reply are undefined. If the client
which issued the unsupported request has also selected to do so, it will also
receive an
XkbExtensionDeviceNotify
event which reports the attempt to use an unsupported feature, in this case
one or both of
XkbXI_IndicatorMaps
and
XkbXI_IndicatorNames
.
Otherwise,
supported
is
True
and the
deviceID
field reports the input extension identifier of the keyboard or
0
if the server does not support the input extension. The
indicator
return value reports the name for which information was requested and the
found
return value is
True
if an indicator with the specified name was found on the device.
If no indicator with the specified name is found on the specified device, and
the
createMap
field is
True
, XKB assigns the specified name to the lowest-numbered indicator that has no
name (i.e. whose name is
None
) and applies the rest of the fields in the request to the newly named
indicator. If no unnamed indicators remain, this request reports no error and
has no effect.
If no matching indicator is found or new indicator assigned this request
reports no error and has no effect. Otherwise, it updates the indicator as
follows:
If
setMap
is
True
, XKB changes the map for the indicator (see
map
.
If
setState
is
True
, XKB attempts to explicitly change the state of the indicator to the state
specified in
on
. The effects of an attempt to explicitly change the state of an indicator
depend on the values in the map for that indicator and are not guaranteed to
succeed.
If this request affects both indicator map and state, it updates the indicator
map before attempting to change its state, so the success of the explicit
change depends on the indicator map values specified in the request.
If this request changes the indicator map, it applies the new map immediately
to determine the appropriate state for the indicator given the new indicator
map and the current state of the keyboard.
Querying and Changing Symbolic Names
XkbGetNames
deviceSpec: KB_DEVICESPEC
which: KB_NAMEDETAILMASK
deviceID: CARD8
which: KB_NAMESMASK
minKeyCode, maxKeyCode: KEYCODE
nTypes: CARD8
nKTLevels: CARD16
groupNames: KB_GROUPMASK
virtualMods: KB_VMODMASK
firstKey: KEYCODE
nKeys: CARD8
indicators: KB_INDICATORMASK
nRadioGroups, nKeyAliases: CARD8
present: KB_NAMEDETAILMASK
valueList: LISTofITEMs
Errors:
Keyboard
,
Value
This request returns the symbolic names for various components of the keyboard
mapping for the device specified by
deviceSpec
. The
which
field specifies the keyboard components for which names are to be returned. If
deviceSpec
does not specify a valid keyboard device, a
Keyboard
error results. If any undefined bits in
which
are non-zero, a
Value
error results.
The
deviceID
return value contains the X Input Extension device identifier of the specified
device or
0
if the server does not support the input extension. The
present
and
valueList
return values specify the components for which names are being reported. If a
component is specified in
present
, the corresponding element is present in the
valueList
, otherwise that component has length
0
. The components of the
valueList
appear in the following order, when present:.
Component
Size
Type
XkbKeycodesName
1
ATOM
XkbGeometryName
1
ATOM
XkbSymbolsName
1
ATOM
XkbPhysSymbolsName
1
ATOM
XkbTypesName
1
ATOM
XkbCompatName
1
ATOM
XkbKeyTypeNames
nTypes
LISTofATOM
XkbKTLevelNames
nTypes
,
nKTLevels
{ count: LISTofCARD8,
names: LISTofATOM }
XkbIndicatorNames
One per bit set in
indicators
LISTofATOM
XkbVirtualModNames
One per bit set in
virtualMods
LISTofATOM
XkbGroupNames
One per bit set in
groupNames
LISTofATOM
XkbKeyNames
nKeys
LISTofKB_KEYNAME
XkbKeyAliases
nKeyAliases
LISTofKB_KEYALIAS
XkbRGNames
nRadioGroups
LISTofATOM
If type names are reported, the
nTypes
return value reports the number of types defined for the keyboard, and the
list of key type names in
valueList
has
nTypes
elements.
If key type level names are reported, the list of key type level names in the
valueList
has two parts: The
count
array has
nTypes
elements, each of which reports the number of level names reported for the
corresponding key type. The
names
array has
nKTLevels
atoms and reports the names of each type sequentially. The
nKTLevels
return value is always equal to the sum of all of the elements of the
count
array.
If indicator names are reported, the
indicators
mask specifies the indicators for which names are defined; any indicators not
specified in
indicators
have the name
None
. The list of indicator names in
valueList
contains the names of the listed indicators, beginning with the
lowest-numbered indicator for which a name is defined and proceeding to the
highest.
If virtual modifier names are reported, the
virtualMods
mask specifies the virtual modifiers for which names are defined; any virtual
modifiers not specified in
virtualMods
have the name
None
. The list of virtual modifier names in
valueList
contains the names of the listed virtual modifiers, beginning with the
lowest-numbered virtual modifier for which a name is defined and proceeding to
the highest.
If group names are reported, the
groupNames
mask specifies the groups for which names are defined; any groups not
specified in
groupNames
have the name
None
. The list of group names in
valueList
contains the names of the listed groups, beginning with the lowest-numbered
group for which a name is defined and proceeding to the highest.
If key names are reported, the
firstKey
and
nKeys
return values specify a range of keys which includes all keys for which names
are defined; any key that does not fall in the range specified by
firstKey
and
nKeys
has the name
NullKeyName
. The list of key names in the
valueList
has
nKeys
entries and specifies the names of the keys beginning at
firstKey
.
If key aliases are reported, the
nKeyAliases
return value specifies the total number of key aliases defined for the
keyboard. The list of key aliases in
valueList
has
nKeyAliases
entries, each of which reports an alias and the real name of the key to which
it corresponds.
If radio group names are reported, the
nRadioGroups
return value specifies the number of radio groups on the keyboard for which
names are defined. The list of radio group names in
valueList
reports the names of each group and has
nRadioGroups
entries.
XkbSetNames
deviceSpec: KB_DEVICESPEC
which: KB_NAMEDETAILMASK
virtualMods: KB_VMODMASK
firstType, nTypes: CARD8
firstKTLevel, nKTLevels: CARD8
totalKTLevelNames: CARD16
indicators: KB_INDICATORMASK
groupNames: KB_GROUPMASK
nRadioGroups: CARD8
firstKey: KEYCODE
nKeys, nKeyAliases: CARD8
valueList: LISTofITEMs
Errors:
Keyboard
,
Atom
,
Value
,
Match
,
Alloc
This request changes the symbolic names for the requested components of the
keyboard specified by
deviceSpec
. The
which
field specifies the components for which one or more names are to be updated.
If
deviceSpec
does not specify a valid keyboard device, a
Keyboard
error results. If any undefined bits in
which
are non-zero, a
Value
error results. If any error (other than
Alloc
or
Implementation
) occurs, this request returns without modifying any names.
The
which
and
valueList
fields specify the components to be changed; the type of each
valueList
entry, the order in which components appear in the
valueList
when specified, and the correspondence between components in
which
and the entries in the
valueList
are as specified for the
XkbGetNames
request.
If keycodes, geometry, symbols, physical symbols, types or compatibility map
names are to be changed, the corresponding entries in the
valueList
must have the value
None
or specify a valid ATOM, else an
Atom
error occurs.
If key type names are to be changed, the
firstType
and
nTypes
fields specify a range of types for which new names are supplied, and the list
of key type names in
valueList
has
nTypes
elements. Names for types that fall outside of the range specified by
firstType
and
nTypes
are not affected. If this request specifies names for types that are not
present on the keyboard, a
Match
error results. All of the type names in the
valueList
must be valid ATOMs or have the value
None
, or an
Atom
error results.
The names of the first four keyboard types are specified by the XKB extension
and cannot be changed; including any of the canonical types in this request
causes an
Access
error, as does trying to assign the name reserved for a canonical type to one
of the other key types.
If key type level names are to be changed, the
firstKTLevel
and
nKTLevels
fields specify a range of key types for which new level names are supplied,
and the list of key type level names in the
valueList
has two parts: The
count
array has
nKTLevels
elements, each of which specifies the number of levels for which names are
supplied on the corresponding key type; any levels for which no names are
specified are assigned the name
None
. The
names
array has
totalKTLevels
atoms and specifies the names of each type sequentially. The
totalKTLevels
field must always equal the sum of all of the elements of the
count
array. Level names for types that fall outside of the specified range are not
affected. If this request specifies level names for types that are not present
on the keyboard, or if it specifies more names for a type than the type has
levels, a
Match
error results. All specified type level names must be
None
or a valid ATOM or an
Atom
error results.
If indicator names are to be changed, the
indicators
mask specifies the indicators for which new names are specified; the names for
indicators not specified in
indicators
are not affected. The list of indicator names in
valueList
contains the new names for the listed indicators, beginning with the
lowest-numbered indicator for which a name is defined and proceeding to the
highest. All specified indicator names must be a valid ATOM or
None
, or an
Atom
error results.
If virtual modifier names are to be changed, the
virtualMods
mask specifies the virtual modifiers for which new names are specified; names
for any virtual modifiers not specified in
virtualMods
are not affected. The list of virtual modifier names in
valueList
contains the new names for the specified virtual modifiers, beginning with the
lowest-numbered virtual modifier for which a name is defined and proceeding to
the highest. All virtual modifier names must be valid ATOMs or
None
, or an
Atom
error results.
If group names are to be changed, the
groupNames
mask specifies the groups for which new names are specified; the name of any
group not specified in
groupNames
is not changed. The list of group names in
valueList
contains the new names for the listed groups, beginning with the
lowest-numbered group for which a name is defined and proceeding to the
highest. All specified group names must be a valid ATOM or
None
, or an
Atom
error results.
If key names are to be changed, the
firstKey
and
nKeys
fields specify a range of keys for which new names are defined; the name of
any key that does not fall in the range specified by
firstKey
and
nKeys
is not changed. The list of key names in the
valueList
has
nKeys
entries and specifies the names of the keys beginning at
firstKey
.
If key aliases are to be changed, the
nKeyAliases
field specifies the length of a new list of key aliases for the keyboard. The
list of key aliases can only be replaced in its entirety; it cannot be
replaced. The list of key aliases in
valueList
has
nKeyAliases
entries, each of which reports an alias and the real name of the key to which
it corresponds.
XKB does not check key names or aliases for consistency and validity, so
applications should take care not to assign duplicate names or aliases
If radio group names are to be changed, the
nRadioGroups
field specifies the length of a new list of radio group names for the
keyboard. There is no way to edit the list of radio group names; it can only be
replaced in its entirety. The list of radio group names in
valueList
reports the names of each group and has
nRadioGroups
entries. If the list of radio group names specifies names for more radio
groups than XKB allows (32), a
Match
error results. All specified radio group names must be valid ATOMs or have the
value
None
, or an
Atom
error results.
Querying and Changing Keyboard Geometry
XkbGetGeometry
deviceSpec: KB_DEVICESPEC
name: ATOM
deviceID: CARD8
name: ATOM
found: BOOL
widthMM, heightMM: CARD16
baseColorNdx, labelColorNdx: CARD8
properties: LISTofKB_PROPERTY
colors: LISTofSTRING8
shapes: LISTofKB_SHAPE
sections: LISTofKB_SECTION
doodads: LISTofKB_DOODAD
keyAliases: LISTofKB_KEYALIAS
Errors:
Keyboard
This request returns a description of the physical layout of a keyboard. If the
name
field has the value
None
, or if name is identical to the name of the geometry for the keyboard
specified by
deviceSpec
, this request returns the geometry of the keyboard specified by
deviceSpec
; otherwise, if
name
is a valid atom other than
None
, the server returns the keyboard geometry description with that name in the
server database of keyboard components (see
deviceSpec
does not specify a valid keyboard device, a
Keyboard
error results. If
name
has a value other than
None
or a valid ATOM, an
Atom
error results.
On successful return, the
deviceID
field reports the X Input extension identifier of the keyboard device
specified in the request, or
0
if the server does not support the input extension.
The
found
return value reports whether the requested geometry was available. If
found
is
False
, no matching geometry was found and the remaining fields in the request reply
are undefined; if
found
is
True
, the remaining fields of the reply describe the requested keyboard geometry.
The interpretation of the components that make up a keyboard geometry is
described in detail in
XkbSetGeometry
deviceSpec: KB_DEVICESPEC
name: ATOM
widthMM, heightMM, CARD16
baseColorNdx, labelColorNdx: CARD8
shapes: LISTofKB_SHAPE
sections: LISTofKB_SECTION
properties: LISTofKB_PROPERTY
colors: LISTofSTRING8
doodads: LISTofKB_DOODAD
keyAliases: LISTofKB_KEYALIAS
Errors:
Keyboard
,
Atom
,
Value
This request changes the reported description of the geometry for the keyboard
specified by
deviceSpec
. If deviceSpec does not specify a valid keyboard device, a
Keyboard
error results.
The
name
field specifies the name of the new keyboard geometry and must be a valid ATOM
or an
Atom
error results. The new geometry is not added to the server database of
keyboard components, but it can be retrieved using the
XkbGetGeometry
request for as long as it is bound to the keyboard. The keyboard geometry
symbolic name is also updated from the name field, and an
XkbNamesNotify
event is generated, if necessary.
The list of
colors
must include at least two definitions, or a
Value
error results. All color definitions in the geometry must specify a legal
color (i.e. must specify a valid index for one of the entries of the
colors
list) or a
Match
error results. The
baseColorNdx
and the
labelColorNdx
must be different or a
Match
error results.
The list of
shapes
must include at least one shape definition, or a
Value
error results. If any two shapes have the same name, a
Match
error result. All doodads and keys which specify shape must specify a valid
index for one of the elements of the
shapes
list, or a
Match
error results.
All section, shape and doodad names must be valid ATOMs or an
Atom
error results; the constant
None
is not permitted for any of these components.
All doodads must be of a known type; XKB does not support "private" doodad
types.
If, after rotation, any keys or doodads fall outside of the bounding box for a
section, the bounding box is automatically adjusted to the minimum size which
encloses all of its components.
If, after adjustment and rotation, the bounding box of any section or doodad
extends below zero on either the X or Y axes, the entire geometry is translated
so that the minimum extent along either axis is zero.
If, after rotation and translation, any keyboard components fall outside of the
rectangle specified by
widthMM
and
heightMM
, the keyboard dimensions are automatically resized to the minimum bounding box
that surrounds all components. Otherwise, the width and height of the keyboard
are left as specified.
The
under
field of any overlay key definitions must specify a key that is in the section
that contains the overlay key, or a
Match
error results. This request does not check the value of the
over
field of an overlay key definition, so applications must be careful to avoid
conflicts with actual keys.
This request does not verify that key names or aliases are unique. It also does
not verify that all key names specified in the geometry are bound to some
keycode or that all keys that are named in the keyboard definition are also
available in the geometry. Applications should make sure that keyboard geometry
has no internal conflicts and is consistent with the other components of the
keyboard definition, but XKB does not check for or guarantee it.
Querying and Changing Per-Client Flags
XkbPerClientFlags
deviceSpec: KB_DEVICESPEC
change: KB_PCFMASK
value: KB_PCFMASK
ctrlsToChange: KB_BOOLCTRLMASK
autoCtrls: KB_BOOLCTRLMASK
autoCtrlValues: KB_BOOLCTRLMASK
deviceID: CARD8
supported: KB_PCFMASK
value: KB_PCFMASK
autoCtrls: KB_BOOLCTRLMASK
autoCtrlValues: KB_BOOLCTRLMASK
where: KB_PCFMASK:
Errors:
Keyboard
,
Value
,
Match
,
Alloc
Changes the client specific flags for the keyboard specified by
deviceSpec
. Reports a
Keyboard
error if
deviceSpec
does not specify a valid keyboard device.
Any flags specified in
change
are set to the corresponding values in
value
, provided that the server supports the requested control. Legal
per-client-flags are:
Flag…
Described in…
XkbPCF_DetectableAutorepeat
XkbPCF_GrabsUseXKBStateMask
XkbPCF_AutoResetControlsMask
XkbPCF_LookupStateWhenGrabbed
XkbPCF_SendEventUsesXKBState
If
PCF_AutoResetControls
is set in both
change
and
value
, the client’s mask of controls to be changed is updated from
ctrlsToChange
,
autoCtrls
, and
autoCtrlValues
. Any controls specified in
ctrlsToChange
are modified in the auto-reset controls mask for the client; the corresponding
bits from the
autoCtrls
field are copied into the auto-reset controls mask and the corresponding bits
from
autoCtrlValues
are copied into the auto-reset controls state values. If any controls are
specified in
autoCtrlValues
but not in
autoCtrls
, a
Match
error results. If any controls are specified in
autoCtrls
but not in
ctrlsToChange
, a
Match
error results.
If
PCF_AutoResetControls
is set in
change
but not in
value
, the client’s mask of controls to be changed is reset to all zeroes (i.e.
the client does not change any controls when it exits).
This request reports a
Match
error if a bit is set in any of the value masks but not in the control mask
that governs it or a
Value
error if any undefined bits are set in any of the masks.
On successful return, the
deviceID
field reports the X Input extension identifier of the keyboard, or
0
if the server does not support the X Input Extension.
The
supported
return value reports the set of per-client flags that are supported by the
server; in this version of XKB, only the
XkbPCF_DetectableAutorepeat
per-client flag is optional; all other per-client flags must be supported.
The
value
return value reports the current settings of all per-client flags for the
specified keyboard. The
autoCtrls
return value reports the current set of controls to be reset when the client
exits, while the
autoCtrlValues
return value reports the state to which they should be set.
Using the Server’s Database of Keyboard Components
XkbListComponents
deviceSpec: KB_DEVICESPEC
maxNames: CARD16
keymapsSpec: STRING8
keycodesSpec: STRING8
typesSpec: STRING8
compatMapSpec: STRING8
symbolsSpec: STRING8
geometrySpec: STRING8
deviceID: CARD8
extra: CARD16
keymaps,keycodes,types,compatMaps: LISTofKB_COMPONENTNAME
symbols, geometries: LISTofKB_COMPONENTNAME
Where:
KB_COMPONENTNAME { hints: CARD8, name:
STRING8 }
Errors:
Keyboard
,
Alloc
This request returns one or more lists of keyboard components that are
available from the X server database of keyboard components for the device
specified by
deviceSpec
. The X server is allowed, but not required or expected, to maintain separate
databases for each keyboard device. A
Keyboard
error results if
deviceSpec
does not specify a valid keyboard device.
The
maxNames
field specifies the maximum number of component names to be reported, in
total, by this request.
The
keymapsSpec
,
keycodesSpec
,
typesSpec
,
compatMapSpec
,
symbolsSpec
and
geometrySpec
request fields specify a pattern to be matched against the names of all
components of the corresponding type in the server database of keyboard
components.
Each pattern uses the ISO Latin-1 encoding and should contain only parentheses,
the wildcard characters "?" and "*" or characters that are permitted in a
component class or member name (see
Comparison is case-sensitive and, in a pattern, the "?" wildcard character
matches any single character except parentheses while the "*" character matches
any number of characters except parentheses. If an implementation accepts
characters other than those required by XKB, whether or not those characters
match either wildcard is also implementation dependent. An empty pattern does
not match any component names.
On successful return, the
deviceID
return value reports the X Input Extension device identifier of the specified
device, or
0
if the server does not support the X input extension. The
extra
return value reports the number of matching component names that could not be
returned due to the setting of the
maxNames
field in the request.
The
keymaps
,
keycodes
,
types
,
compatMaps
,
symbols
and
geometries
return the hints (see
XkbGetKbdByName
deviceSpec: KB_DEVICESPEC
need, want: KB_GBNDETAILMASK
load: BOOL
keymapsSpec: STRING8
keycodesSpec, typesSpec: STRING8
compatMapSpec, symbolsSpec: STRING8
geometrySpec: STRING8
deviceID: CARD8
minKeyCode, maxKeyCode: KEYCODE
loaded, newKeyboard: BOOL
found, reported: KB_GBNDETAILMASK
map: optional
XkbGetMap
reply
compat: optional
XkbGetCompatMap
reply
indicators: optional
XkbGetIndicatorMap
reply
names: optional
XkbGetNames
reply
geometry: optional
XkbGetGeometry
reply
Errors:
Keyboard
,
Access
,
Alloc
Assembles and returns a keymap from the current mapping and specified elements
from the server database of keymap components for the keyboard specified by
deviceSpec
, and optionally replaces the current keyboard mapping with the newly generated
description. If
deviceSpec
does not specify a valid keyboard device, a
Keyboard
error results.
The
keymapsSpec
,
keycodesSpec
,
typesSpec
,
compatMapSpec
,
symbolsSpec
and
geometrySpec
component expressions (see
The
want
field lists the pieces of the keyboard description that the client wants to
have reported for the newly constructed keymap. The
need
field lists all of the pieces that must be reported. If any of the pieces in
need
cannot be loaded from the specified names, no description of the keyboard is
returned.
The
want
and
need
fields can include any combinations of these
XkbGetMapByName
(GBN) components:
XkbGetMapByName Keyboard Component…
Database Component…
Components of Keyboard Description
XkbGBN_Types
types
key types
XkbGBN_CompatMap
compat
symbol interpretations, group compatibility map
XkbGBN_ClientSymbols
symbols, types, keycodes
key types, key symbol mappings, modifier mapping
XkbGBN_ServerSymbols
symbols, types, keycodes
key behaviors, key actions, key explicit components, virtual
modifiers, virtual modifier mapping
XkbGBN_IndicatorMap
compat
indicator maps, indicator names
XkbGBN_KeyNames
keycodes
key names, key aliases
XkbGBN_Geometry
geometry
keyboard geometry
XkbGBN_OtherNames
all
key types, symbol interpretations, indicator maps, names,
geometry
If either field contains a GBN component that depends on some database
component for which the request does not supply an expression, XKB
automatically substitutes the special pattern "%" which copies the
corresponding component from the current keyboard description, as described in
The
load
flag asks the server to replace the current keyboard description for
deviceSpec
with the newly constructed keyboard description. If
load
is
True
, the request must include component expressions for all of the database
components; if any are missing, XKB substitutes "%" as described above.
If all necessary components are both specified and found, the new keyboard
description is loaded. If the new keyboard description has a different geometry
or keycode range than the previous keyboard description, XKB sends
XkbNewKeyboardNotify
events to all interested clients. See
If the range of keycodes changes, clients that have requested
XkbNewKeyboardNotify
events are not sent any other change notification events by this request.
Clients that do not request
XkbNewKeyboardNotify
events are sent other XKB change notification events (e.g.
XkbMapNotify
,
XkbNamesNotify
) as necessary to alert them to as many of the keyboard changes as possible.
If no error occurs, the request reply reports the GBN components that were
found and sends a description of any of the resulting keyboard that includes
and of the components that were requested.
The
deviceID
return value reports the X Input extension device identifier of the keyboard
that was used, or
0
if the server does not support the X input extension.
The
minKeyCode
and
maxKeyCode
return values report the legal range of keycodes for the keyboard description
that was created. If the resulting keyboard description does not include at
least one of the key names, client symbols or server symbols components,
minKeyCode
and
maxKeyCode
are both
0
.
The
loaded
return value reports whether or not the existing keyboard definition was
replaced with the newly created one. If
loaded
is
True
, the
newKeyboard
return value reports whether or not the new map changed the geometry or range
of keycodes and caused
XkbNewKeyboardNotify
events for clients that have requested them.
The
found
return value reports the GBN components that were present in the keymap that
was constructed by this request. The
reported
return value lists the subset of those components for which descriptions
follow. if any of the components specified in the
need
field of the request were not found,
reported
is empty, otherwise it contains the intersection of the
found
return value with the union of the
need
and
want
request fields.
If any of
GBN_Types
,
GBN_ClientSymbols
or
GBN_ServerSymbols
are set in
reported
, the
map
return value has the same format as the reply to an
XkbGetMap
request and reports the corresponding pieces of the newly constructed keyboard
description.
If
GBN_CompatMap
is set in
reported
, the
compat
return value has the same format as the reply to an
XkbGetCompatMap
request and reports the symbol interpretations and group compatibility map for
the newly constructed keyboard description.
If
GBN_IndicatorMap
is set in
reported
, the
indicators
return value has the same format as the reply to an
XkbGetIndicatorMap
request and reports the physical indicators and indicator maps for the newly
constructed keyboard description.
If
GBN_KeyNames
or
GBN_OtherNames
are set in
reported
, the
names
return value has the same format as the reply to an
XkbGetNames
reply and reports the corresponding set of symbolic names for the newly
constructed keyboard description.
If
GBN_Geometry
is set in
reported
, the
geometry
return value has the same format as the reply to an
XkbGetGeometryMap
request and reports the keyboard geometry for the newly constructed keyboard
description.
Querying and Changing Input Extension Devices
XkbGetDeviceInfo
deviceSpec: KB_DEVICESPEC
wanted: KB_XIDEVFEATUREMASK
ledClass: KB_LEDCLASSSPEC
ledID: KB_IDSPEC
allButtons: BOOL
firstButton, nButtons: CARD8
deviceID: CARD8
present: KB_XIDEVFEATUREMASK
supported: KB_XIFEATUREMASK
unsupported: KB_XIFEATUREMASK
firstBtnWanted: CARD8
nBtnsWanted: CARD8
firstBtnRtrn: CARD8
nBtnsRtrn: CARD8
totalBtns: CARD8
hasOwnState: BOOL
dfltKbdFB, dfltLedFB: KB_IDSPEC
devType: ATOM
name: STRING
btnActions: LISTofKB_ACTION
leds: LISTofKB_DEVICELEDINFO
Errors:
Device
,
Match
,
Access
,
Alloc
Reports a subset of the XKB-supplied information about the input device
specified by
deviceSpec
. Unlike most XKB requests, the device specified for
XkbGetDeviceInfo
need not be a keyboard device. Nonetheless, a
Keyboard
error results if
deviceSpec
does not specify a valid core or input extension device.
The
wanted
field specifies the types of information to be returned, and controls the
interpretation of the other request fields.
If the server does not support assignment of XKB actions to extension device
buttons, the
allButtons
,
firstButton
and
nButtons
fields are ignored.
Otherwise, if the
XkbXI_ButtonActions
flag is set in
wanted
, the
allButtons
,
firstButton
and
nButtons
fields specify the device buttons for which actions should be returned.
Setting
allButtons
to
True
requests actions for all device buttons; if
allButtons
is
False
,
firstButton
and
nButtons
specify a range of buttons for which actions are requested. If the device has
no buttons or if
firstButton
and
nButtons
specify illegal buttons, a
Match
error results. If
allButtons
is
True
,
firstButton
and
nButtons
are ignored.
If the server does not support XKB access to any aspect of the indicators on
extension devices, or if the
wanted
field does not include any of the indicator flags, the
ledClass
and
ledID
fields are ignored. Otherwise,
ledClass
and
ledID
specify one or more feedback(s) for which indicator information is requested.
If
ledClass
or
ledID
have illegal values, a
Value
error results. If they have legal values but do not specify a keyboard or
indicator class feedback for the device in question, a
Match
error results.
The
ledClass
field can specify either
KbdFeedbackClass
,
LedFeedbackClass
,
XkbDfltXIClass
, or
XkbAllXIClasses
. If at least one keyboard feedback is defined for the specified device,
XkbDfltXIClass
is equivalent to
KbdFeedbackClass
, otherwise it is equivalent to
LedFeedbackClass
. If
XkbAllXIClasses
is specified, this request returns information about both indicator and
keyboard class feedbacks which match the requested identifier, as described
below.
The
ledID
field can specify any valid input extension feedback identifier,
XkbDfltXIId
, or
XkbAllXIIds
. The default keyboard feedback is the one that is affected by core protocol
requests; the default led feedback is implementation-specific. If
XkbAllXIIds
is specified, this request returns indicator information about all feedbacks
of the class(es) specified by
ledClass
.
If no error results, the
deviceID
return value reports the input extension device identifier of the device for
which values are being returned. The
supported
return value reports the set of optional XKB extension device features that
are supported by this implementation (see
unsupported
features.
If
hasOwnState
is
True
, the device is also a keyboard, and any indicator maps bound to the device use
the current state and control settings for this device to control automatic
changes. If
hasOwnState
is
False
, the state and control settings of the core keyboard device control automatic
indicator changes.
The
name
field reports the X Input Extension name for the device. The
devType
field reports the X Input Extension device type. Both fields are provided
merely for convenience and are not interpreted by XKB.
The
present
return value reports the kinds of device information being returned, and
controls the interpretation of the remaining fields. The
present
field consists of the
wanted
field from the original request minus the flags for any unsupported features.
If
XkbXI_ButtonActions
is set in
present
, the
totalBtns
return value reports the total number of buttons present on the device,
firstBtnWanted
and
nBtnsWanted
specify the range of buttons for which actions were requested, and the
firstBtnRtrn
and
nBtnsRtrn
values specify the range of buttons for which actions are reported. The
actionsRtrn
list has
nButtonsRtrn
entries which contain the actions bound to the specified buttons on the
device. Any buttons for which actions were requested but not returned have the
action
NoAction()
.
If any indicator information is reported, the leds list contains one element
for each requested feedback. For example, if
ledClass
is
XkbAllXIClasses
and
ledID
is
XkbAllXIIds
,
leds
describes all of the indicators on the device and has one element for each
keyboard or led class feedback defined for the device. If any information at
all is reported about a feedback, the set of physical indicators is also
reported in the
physIndicators
field of the corresponding element of
leds
.
If the server supports assignment of indicator maps to extension device
indicators, and if the
XkbXI_IndicatorMaps
flag is set in
wanted
, each member of
leds
reports any indicators on the corresponding feedback to which names have been
assigned. Any indicators for which no map is reported have the default map,
which allows explicit changes and does not request any automatic changes.
If the server supports assignment of indicator names to extension device
indicators, and the
XkbXI_IndicatorNames
flag is set in
wanted
, each member of
leds
reports any indicators on the corresponding feedback to which names have been
assigned. Any indicators for which no name is reported have the name
None
.
If the server supports XKB access to the state of extension device indicators,
and the
XkbXI_IndicatorState
flag is set in wanted, each member of leds reports the state of the indicators
on the corresponding feedback.
If any unsupported features are requested, and the requesting client has
selected for them, the server sends the client an
XkbExtensionDeviceNotify
event which indicates that an unsupported feature was requested. This event is
only generated if the client which issued the unsupported request has selected
for it and, if generated, is not sent to any other clients.
XkbSetDeviceInfo
deviceSpec: KB_DEVICESPEC
change: KB_XIDEVFEATUREMASK
firstBtn, nBtns: CARD8
btnActions:LISTofKB_ACTION
leds: LISTofKB_DEVICELEDINFO
Errors:
Device
,
Match
,
Access
,
Alloc
Changes a subset of the XKB-supplied information about the input device
specified by
deviceSpec
. Unlike most XKB requests, the device specified for
XkbGetDeviceInfo
need not be a keyboard device. Nonetheless, a
Keyboard
error results if
deviceSpec
does not specify a valid core or input extension device
The
change
field specifies the features for which new values are supplied, and controls
the interpretation of the other request fields.
If the server does not support assignment of XKB actions to extension device
buttons, the
firstButton
and
nButtons
fields are ignored.
Otherwise, if the
XkbXI_ButtonActions
flag is set in
change
, the
firstBtn
and
nBtns
fields specify a range of buttons for which actions are specified in this
request. If the device has no buttons or if
firstBtn
and
nBtns
specify illegal buttons, a
Match
error results.
Each element of the
leds
list describes the changes for a single keyboard or led feedback. If the
ledClass
field of any element of
leds
contains any value other than
KbdFeedbackClass
,
LedFeedbackClass
or
XkbDfltXIClass
, a
Value
error results. If the
ledId
field of any element of leds contains any value other than a valid input
extension feedback identifier or
XkbDfltXIId
, a
Value
error results. If both fields are valid, but the device has no matching
feedback, a
Match
error results.
The fields of each element of
leds
are interpreted as follows:
If
XkbXI_IndicatorMaps
is set in
change
and the server supports XKB assignment of indicator maps to the corresponding
feedback, the maps for all indicators on the corresponding feedback are taken
from
leds
. If the server does not support this feature, any maps specified in
leds
are ignored.
If
XkbXI_IndicatorNames
is set in
change
, and the server supports XKB assignment of names to indicators for the
corresponding feedback, the names for all indicators on the corresponding
feedback are taken from
leds
. If the server does not support this feature, any names specified in
leds
are ignored. Regardless of whether they are used, any names be a valid Atom or
None
, or an
Atom
error results.
If
XkbXI_IndicatorState
is set in change, and the server supports XKB changes to extension device
indicator state, the server attempts to change the indicators on the
corresponding feedback as specified by
leds
. Any indicator maps bound to the feedback are applied, so state changes might
be blocked or have side-effects.
If any unsupported features are requested, and the requesting client has
selected for them, the server sends the client an
XkbExtensionDeviceNotify
event which indicates that an unsupported feature was requested. This event is
only generated if the client which issued the unsupported request has selected
for it and, if generated, is not sent to any other clients.
Debugging the X Keyboard Extension
XkbSetDebuggingFlags
affectFlags, flags: CARD32
affectCtrls, ctrls: CARD32
message: STRING
currentFlags, supportedFlags: CARD32
currentCtrls, supportedCtrls: CARD32
This request sets up various internal XKB debugging flags and controls. It is
intended for developer use and may be disabled in production servers. If
disabled,
XkbSetDebuggingFlags
has no effect but returns
Success
.
The
affectFlags
field specifies the debugging flags to be changed, the
flags
field specifies new values for the changed flags. The interpretation of the
debugging flags is implementation-specific, but flags are intended to control
debugging output and should not otherwise affect the operation of the server.
The
affectCtrls
field specifies the debugging controls to be changed, the
ctrls
field specifies new values for the changed controls. The interpretation of the
debugging controls is implementation-specific, but debugging controls are
allowed to affect the behavior of the server.
The
message
field provides a message that the X server can print in any logging or
debugging files before changing the flags. The server must accept this field
but it is not required to actually display it anywhere.
The X Test Suite makes some assumptions about the implementation of locking
modifier keys that do not apply when XKB is present. The
XkbDF_DisableLocks
debugging control provides a simple workaround to these test suite problems by
simply disabling all locking keys. If
XkbDF_DisableLocks
is enabled, the
SA_LockMods
and
SA_LockGroup
actions behave like
SA_SetMods
and
SA_LockMods
, respectively. If it is disabled,
SA_LockMods
and
SA_LockGroup
actions behave normally.
Implementations are free to ignore the
XkbDF_DisableLocks
debugging control or to define others.
The
currentFlags
return value reports the current setting for the debugging flags, if
applicable. The
currentCtrls
return value reports the setting for the debugging controls, if applicable.
The
supportedFlags
and
supportedCtrls
fields report the flags and controls that are recognized by the
implementation. Attempts to change unsupported fields or controls are silently
ignored.
If the
XkbSetDebuggingFlags
request contains more data than expected, the server ignores the extra data,
but no error results. If the request has less data than expected, a
Length
error results.
If the
XkbSetDebuggingFlags
reply contains more data than expected, the client just ignores any
uninterpreted data without reporting an error. If the reply has less data than
expected, a
Length
error results.
Events
All XKB events report the time at which they occurred in a field named
time
and the device on which they occurred in a field named
deviceID
. XKB uses a single X event code for all events and uses a common field to
distinguish XKB event type.
Tracking Keyboard Replacement
XkbNewKeyboardNotify
time: TIMESTAMP
deviceID: CARD8
changed: KB_NKNDETAILMASK
minKeyCode, maxKeyCode: KEYCODE
oldDeviceID: CARD8
oldMinKeyCode, oldMaxKeyCode: KEYCODE
requestMajor, requestMinor: CARD8
An
XkbNewKeyboardNotify
event reports that a new core keyboard has been installed. New keyboard notify
events can be generated:
When the X server detects that the keyboard was changed.
When a client installs a new extension device as the core keyboard
using the X Input Extension
ChangeKeyboardDevice
request.
When a client issues an
XkbGetMapByName
request which changes the keycodes range or geometry.
The
changed
field of the event reports the aspects of the keyboard that have changed, and
can contain any combination of the event details for this event:
Bit in Changed
Meaning
NKN_Keycodes
The new keyboard has a different minimum or maximum keycode.
NKN_Geometry
The new keyboard has a different keyboard geometry.
NKN_DeviceID
The new keyboard has a new X Input Extension device
identifier
The server sends an
XkbNewKeyboardNotify
event to a client only if at least one of the bits that is set in the
changed
field of the event is also set in the appropriate event details mask for the
client.
The
minKeyCode
and
maxKeyCode
fields report the minimum and maximum keycodes that can be returned by the new
keyboard. The
oldMinKeyCode
and
oldMaxKeyCode
fields report the minimum and maximum values that could be returned before the
change. This event always reports all four values, but the old and new values
are the same unless
NKN_Keycodes
is set in
changed
.
Once a client receives a new keyboard notify event which reports a new keycode
range, the X server reports events from all keys in the new range to that
client. Clients that do not request or receive new keyboard notify events
receive events only from keys that fall in the last range for legal keys
reported to that client. See
If
NKN_Keycodes
is set in
changed
, the
XkbNewKeyboardNotify
event subsumes all other change notification events (e.g.
XkbMapNotify
,
XkbNamesNotify
) that would otherwise result from the keyboard change. Clients who receive an
XkbNewKeyboardNotify
event should assume that all other aspects of the keyboard mapping have
changed and regenerate the entire local copy of the keyboard description.
The
deviceID
field reports the X Input Extension device identifier of the new keyboard
device;
oldDeviceID
reports the device identifier before the change. This event always includes
both values, but they are the same unless
NKN_DeviceID
is set in
changed
. If the server does not support the X Input Extension, both fields have the
value
0
.
The
requestMajor
and
requestMinor
fields report the major and minor opcode of the request that caused the
keyboard change. If the keyboard change was not caused by some client request,
both fields have the value
0
.
Tracking Keyboard Mapping Changes
XkbMapNotify
time: TIMESTAMP
deviceID: CARD8
ptrBtnActions: CARD8
changed: KB_MAPPARTMASK
minKeyCode, maxKeyCode: KEYCODE
firstType, nTypes: CARD8
firstKeySym, firstKeyAction: KEYCODE
nKeySyms, nKeyActions: CARD8
firstKeyBehavior, firstKeyExplicit: KEYCODE
nKeyBehaviors, nKeyExplicit: CARD8
virtualMods: KB_VMODMASK
firstModMapKey, firstVModMapKey: KEYCODE
nModMapKeys, nVModMapKeys: CARD8
An
XkbMapNotify
event reports that some aspect of XKB map for a keyboard has changed. Map
notify events can be generated whenever some aspect of the keyboard map is
changed by an XKB or core protocol request.
The
deviceID
field reports the keyboard for which some map component has changed and the
changed
field reports the components with new values, and can contain any of the
values that are legal for the
full
and
partial
fields of the
XkbGetMap
request. The server sends an
XkbMapNotify
event to a client only if at least one of the bits that is set in the
changed
field of the event is also set in the appropriate event details mask for the
client.
The
minKeyCode
and
maxKeyCode
fields report the range of keycodes that are legal on the keyboard for which
the change is being reported.
If
XkbKeyTypesMask
is set in
changed
, the
firstType
and
nTypes
fields report a range of key types that includes all changed types. Otherwise,
both fields are
0
.
If
XkbKeySymsMask
is set in
changed
, the
firstKeySym
and
nKeySyms
fields report a range of keycodes that includes all keys with new symbols.
Otherwise, both fields are
0
.
If
XkbKeyActionsMask
is set in
changed
, the
firstKeyAction
and
nKeyActions
fields report a range of keycodes that includes all keys with new actions.
Otherwise, both fields are
0
.
If
XkbKeyBehaviorsMask
is set in
changed
, the
firstKeyBehavior
and
nKeyBehaviors
fields report a range of keycodes that includes all keys with new key
behavior. Otherwise, both fields are
0
.
If
XkbVirtualModsMask
is set in
changed
,
virtualMods
contains all virtual modifiers to which a new set of real modifiers is bound.
Otherwise,
virtualMods
is
0
.
If
XkbExplicitComponentsMask
is set in
changed
, the
firstKeyExplicit
and
nKeyExplicit
fields report a range of keycodes that includes all keys with changed explicit
components. Otherwise, both fields are
0
.
If
XkbModifierMapMask
is set in
changed
, the
firstModMapKey
and
nModMapKeys
fields report a range of keycodes that includes all keys with changed modifier
bindings. Otherwise, both fields are
0
.
If
XkbVirtualModMapMask
is set in
changed
, the
firstVModMapKey
and
nVModMapKeys
fields report a range of keycodes that includes all keys with changed virtual
modifier mappings. Otherwise, both fields are
0
.
Tracking Keyboard State Changes
XkbStateNotify
time: TIMESTAMP
deviceID: CARD8
mods, baseMods, latchedMods, lockedMods: KEYMASK
group, lockedGroup: CARD8
baseGroup, latchedGroup: INT16
compatState: KEYMASK
grabMods, compatGrabMods: KEYMASK
lookupMods, compatLookupMods: KEYMASK
ptrBtnState: BUTMASK
changed: KB_STATEPARTMASK
keycode: KEYCODE
eventType: CARD8
requestMajor, requestMinor: CARD8
An XkbStateNotify
event reports that some component of the XKB state (see
XkbLatchLockState
request or by other extensions.
The
deviceID
field reports the keyboard on which some state component changed. The
changed
field reports the XKB state components (see
Bit in changed
Event field
Changed component
ModifierState
mods
The effective modifiers
ModifierBase
baseMods
The base modifiers
ModifierLatch
latchedMods
The latched modifiers
ModifierLock
lockedMods
The locked modifiers
GroupState
group
The effective keyboard group
GroupBase
baseGroup
The base keyboard group
GroupLatch
latchedGroup
The latched keyboard group
GroupLock
lockedGroup
The locked keyboard group
PointerButtons
ptrBtnState
The state of the core pointer buttons
GrabMods
grabMods
The XKB state used to compute grabs
LookupMods
lookupMods
The XKB state used to look up symbols
CompatState
compatState
Default state for non-XKB clients
CompatGrabMods
compatGrabMods
The core state used to compute grabs
CompatLookupMods
compatLookupMods
The core state used to look up symbols
The server sends an
XkbStateNotify
event to a client only if at least one of the bits that is set in the
changed
field of the event is also set in the appropriate event details mask for the
client.
A state notify event reports current values for all state components, even
those with unchanged values.
The
keycode
field reports the key or button which caused the change in state while the
eventType
field reports the exact type of event (e.g.
KeyPress
). If the change in state was not caused by key or button activity, both fields
have the value
0
.
The
requestMajor
and
requestMinor
fields report the major and minor opcodes of the request that caused the
change in state and have the value
0
if it was resulted from key or button activity.
Tracking Keyboard Control Changes
XkbControlsNotify
time: TIMESTAMP
deviceID: CARD8
numGroups: CARD8
changedControls: KB_CONTROLMASK
enabledControls,enabledControlChanges: KB_BOOLCTRLMASK
keycode: KEYCODE
eventType: CARD8
requestMajor: CARD8
requestMinor: CARD8
An
XkbControlsNotify
event reports a change in one or more of the global keyboard controls (see
XkbSetControls
request, but they can also be caused by keyboard activity or certain core
protocol and input extension requests.
The
deviceID
field reports the keyboard for which some control has changed, and the
changed
field reports the controls that have new values.
The
changed
field can contain any of the values that are permitted for the
changeControls
field of the
XkbSetControls
request. The server sends an
XkbControlsNotify
event to a client only if at least one of the bits that is set in the
changed
field of the event is also set in the appropriate event details mask for the
client.
The
numGroups
field reports the total number of groups defined for the keyboard, whether or
not the number of groups has changed.
The
enabledControls
field reports the current status of all of the boolean controls, whether or
not any boolean controls changed state. If
EnabledControls
is set in
changed
, the
enabledControlChanges
field reports the boolean controls that were enabled or disabled; if a control
is specified in
enabledControlChanges
, the value that is reported for that control in
enabledControls
represents a change in state.
The
keycode
field reports the key or button which caused the change in state while the
eventType
field reports the exact type of event (e.g.
KeyPress
). If the change in state was not caused by key or button activity, both fields
have the value
0
.
The
requestMajor
and
requestMinor
fields report the major and minor opcodes of the request that caused the
change in state and have the value
0
if it was resulted from key or button activity.
Tracking Keyboard Indicator State Changes
XkbIndicatorStateNotify
time: TIMESTAMP
deviceID: CARD8
stateChanged, state: KB_INDICATORMASK
An
XkbIndicatorStateNotify
event indicates that one or more of the indicators on a keyboard have changed
state. Indicator state notify events can be caused by:
Automatic update to reflect changes in keyboard state (keyboard
activity,
XkbLatchLockState
requests).
Automatic update to reflect changes in keyboard controls (
XkbSetControls
, keyboard activity, certain core protocol and input extension requests).
Explicit attempts to change indicator state (core protocol and input
extension requests,
XkbSetNamedIndicator
requests).
Changes to indicator maps (
XkbSetIndicatorMap
and
XkbSetNamedIndicator
requests).
The
deviceID
field reports the keyboard for which some indicator has changed, and the
state
field reports the new state for all indicators on the specified keyboard. The
stateChanged
field specifies which of the values in
state
represent a new state for the corresponding indicator. The server sends an
XkbIndicatorStateNotify
event to a client only if at least one of the bits that is set in the
stateChanged
field of the event is also set in the appropriate event details mask for the
client.
Tracking Keyboard Indicator Map Changes
XkbIndicatorMapNotify
time: TIMESTAMP
deviceID: CARD8
state: KB_INDICATORMASK
mapChanged: KB_INDICATORMASK
An
XkbIndicatorMapNotify
event indicates that the maps for one or more keyboard indicators have been
changed. Indicator map notify events can be caused by
XkbSetIndicatorMap
and
XkbSetNamedIndicator
requests.
The
deviceID
field reports the keyboard for which some indicator map has changed, and the
mapChanged
field reports the indicators with changed maps. The server sends an
XkbIndicatorMapNotify
event to a client only if at least one of the bits that is set in the
mapChanged
field of the event is also set in the appropriate event details mask for the
client.
The
state
field reports the current state of all indicators on the specified keyboard.
Tracking Keyboard Name Changes
XkbNamesNotify
time: TIMESTAMP
deviceID: CARD8
changed: KB_NAMEDETAILMASK
firstType, nTypes: CARD8
firstLevelName, nLevelNames: CARD8
firstKey: KEYCODE
nKeys, nKeyAliases, nRadioGroups: CARD8
changedGroupNames: KB_GROUPMASK
changedVirtualMods: KB_VMODMASK
changedIndicators: KB_INDICATORMASK
An
XkbNamesNotify
event reports a change to one or more of the symbolic names associated with a
keyboard. Symbolic names can change when:
Some client explicitly changes them using
XkbSetNames
.
The list of key types or radio groups is resized
The group width of some key type is changed
The
deviceID
field reports the keyboard on which names were changed. The
changed
mask lists the components for which some names have changed and can have any
combination of the values permitted for the
which
field of the
XkbGetNames
request. The server sends an
XkbNamesNotify
event to a client only if at least one of the bits that is set in the
changed
field of the event is also set in the appropriate event details mask for the
client.
If
KeyTypeNames
is set in
changed
, the
firstType
and
nTypes
fields report a range of types that includes all types with changed names.
Otherwise, both fields are
0
.
If
KTLevelNames
is set in
changed
, the
firstLevelName
and
nLevelNames
fields report a range of types that includes all types with changed level
names. Otherwise, both fields are
0
.
If
IndicatorNames
is set in
changed
, the
changedIndicators
field reports the indicators with changed names. Otherwise,
changedIndicators
is
0
.
If
VirtualModNames
is set in
changed
, the
changedVirtualMods
field reports the virtual modifiers with changed names. Otherwise,
changedVirtualMods
is
0
.
If
GroupNames
is set in
changed
, the
changedGroupNames
field reports the groups with changed names. Otherwise,
changedGroupNames
is
0
.
If
KeyNames
is set in
changed
, the
firstKey
and
nKeys
fields report a range of keycodes that includes all keys with changed names.
Otherwise, both fields are
0
.
The
nKeyAliases
field reports the total number of key aliases associated with the keyboard,
regardless of whether
KeyAliases
is set in
changed
.
The
nRadioGroups
field reports the total number of radio group names associated with the
keyboard, regardless of whether
RGNames
is set in
changed
.
Tracking Compatibility Map Changes
XkbCompatMapNotify
time: TIMESTAMP
deviceID: CARD8
changedGroups: KB_GROUPMASK
firstSI, nSI: CARD16
nTotalSI: CARD16
An
XkbCompatMapNotify
event indicates that some component of the compatibility map for a keyboard
has been changed. Compatibility map notify events can be caused by
XkbSetCompatMap
and
XkbGetMapByName
requests.
The
deviceID
field reports the keyboard for which the compatibility map has changed; if the
server does not support the X input extension,
deviceID
is
0
.
The
changedGroups
field reports the keyboard groups, if any, with a changed entry in the group
compatibility map. The
firstSI
and
nSI
fields specify a range of symbol interpretations in the symbol compatibility
map that includes all changed symbol interpretations; if the symbol
compatibility map is unchanged, both fields are
0
. The
nTotalSI
field always reports the total number of symbol interpretations present in the
symbol compatibility map, regardless of whether any symbol interpretations have
been changed.
The server sends an
XkbCompatMapNotify
event to a client only if at least one of the following conditions is met:
The
nSI
field of the event is non-zero, and the
XkbSymInterpMask
bit is set in the appropriate event details mask for the client.
The
changedGroups
field of the event contains at least one group, and the
XkbGroupCompatMask
bit is set in the appropriate event details mask for the client.
Tracking Application Bell Requests
XkbBellNotify
time: TIMESTAMP
deviceID: CARD8
bellClass: { KbdFeedbackClass, BellFeedbackClass }
bellID: CARD8
percent: CARD8
pitch: CARD16
duration: CARD16
eventOnly: BOOL
name: ATOM
window: WINDOW
An
XkbBellNotify
event indicates that some client has requested a keyboard bell. Bell notify
events are usually caused by
Bell
,
DeviceBell
, or
XkbBell
requests, but they can also be generated by the server (e.g. if the
AccessXFeedback
control is active).
The server sends an
XkbBellNotify
event to a client if the appropriate event details field for the client has
the value
True
.
The
deviceID
field specifies the device for which a bell was requested, while the
bellClass
and
bellID
fields specify the input extension class and identifier of the feedback for
which the bell was requested. If the reporting server does not support the
input extension, all three fields have the value 0.
The
percent
,
pitch
and
duration
fields report the volume, tone and duration requested for the bell as
specified by the
XkbBell
request. Bell notify events caused by core protocol or input extension
requests use the pitch and duration specified in the corresponding bell or
keyboard feedback control.
If the bell was caused by an
XkbBell
request or by the X server,
name
reports an optional symbolic name for the bell and the
window
field optionally reports the window for which the bell was generated.
Otherwise, both fields have the value
None
.
If the
eventOnly
field is
True
, the server did not generate a sound in response to the request, otherwise the
server issues the beep before sending the event. The eventOnly field can be
True
if the
AudibleBell
control is disabled or if a client explicitly requests
eventOnly
when it issues an
XkbBell
request.
Tracking Messages Generated by Key Actions
XkbActionMessage
time: TIMESTAMP
deviceID: CARD8
keycode: KEYCODE
press: BOOL
mods: KEYMASK
group: KB_GROUP
keyEventFollows: BOOL
message: LISTofCARD8
An
XkbActionMessage
event is generated when the user operates a key to which an
SA_ActionMessage
message is bound under the appropriate state and group. The server sends an
XkbActionMessage
event to a client if the appropriate event details field for the client has
the value
True
.
The
deviceID
field specifies the keyboard device that contains the key which activated the
event. The
keycode
field specifies the key whose operation caused the message and press is
True
if the message was caused by the user pressing the key. The
mods
and
group
fields report the effective keyboard modifiers and group in effect at the time
the key was pressed or released.
If
keyEventFollows
is
True
, the server will also send a key press or release event, as appropriate, for
the key that generated the message. If it is
False
, the key causes only a message. Note that the key event is delivered normally
with respect to passive grabs, keyboard focus, and cursor position, so that
keyEventFollows
does not guarantee that any particular client which receives the
XkbActionMessage
notify event will also receive a key press or release event.
The
message
field is
NULL
-terminated string of up to
ActionMessageLength
(
6
) bytes, which reports the contents of the
message
field in the action that caused the message notify event.
Tracking Changes to AccessX State and Keys
XkbAccessXNotify
time: TIMESTAMP
deviceID: CARD8
detail: KB_AXNDETAILMASK
keycode: KEYCODE
slowKeysDelay: CARD16
debounceDelay: CARD16
An
XkbAccessXNotify
event reports on some kinds of keyboard activity when any of the
SlowKeys
,
BounceKeys
or
AccessXKeys
controls are active. Compatibility map notify events can only be caused by
keyboard activity.
The
deviceID
and
keycode
fields specify the keyboard and key for which the event occurred. The
detail
field describes the event that occurred and has one of the following values:
Detail
Control
Meaning
AXN_SKPress
SlowKeys
Key pressed
AXN_SKAccept
SlowKeys
K
ey held until it was accepted.
AXN_SKReject
SlowKeys
Key released before it was accepted.
AXN_SKRelease
SlowKeys
Key released after it was accepted.
AXN_BKAccept
BounceKeys
Key pressed while it was active.
AXN_BKReject
BounceKeys
Key pressed while it was still disabled.
AXN_AXKWarning
AccessXKeys
Shift key held down for four seconds
Each subclass of the AccessX notify event is generated only when the control
specified in the table above is enabled. The server sends an
XkbAccessXNotify
event to a client only if the bit which corresponds to the value of the
detail
field for the event is set in the appropriate event details mask for the
client.
Regardless of the value of
detail
, the
slowKeysDelay
and
debounceDelay
fields always reports the current slow keys acceptance delay (see
Tracking Changes To Extension Devices
XkbExtensionDeviceNotify
time: TIMESTAMP
deviceID: CARD16
ledClass: { KbdFeedbackClass, LedFeedbackClass }
ledID: CARD16
reason: KB_XIDETAILMASK
supported: KB_XIFEATUREMASK
unsupported: KB_XIFEATUREMASK
ledsDefined: KB_INDICATORMASK
ledState: KB_INDICATORMASK
firstButton, nButtons: CARD8
An
XkbExtensionDeviceNotify
event reports:
A change to some part of the XKB information for an extension device.
An attempt to use an XKB extension device feature that is not supported
for the specified device by the current implementation.
The
deviceID
field specifies the X Input Extension device identifier of some device on
which an XKB feature was requested, or
XkbUseCorePtr
if the request affected the core pointer device. The
reason
field explains why the event was generated in response to the request, and can
contain any combination of
XkbXI_UnsupportedFeature
and the values permitted for the change field of the
XkbSetDeviceInfo
request.
If
XkbXI_ButtonActions
is set in
reason
, this event reports a successful change to the XKB actions bound to one or
more buttons on the core pointer or an extension device. The
firstButton
and
nButtons
fields report a range of device buttons that include all of the buttons for
which actions were changed.
If any combination of
XkbXI_IndicatorNames
,
XkbXI_IndicatorMaps
, or
XkbXI_IndicatorState
is set in either
reason
or
unsupported
, the
ledClass
and
ledID
fields specify the X Input Extension feedback class and identifier of the
feedback for which the change is reported. If this event reports any changes to
an indicator feedback, the
ledsDefined
field reports all indicators on that feedback for which either a name or a
indicator map are defined, and
ledState
reports the current state of all of the indicators on the specified feedback.
If
XkbXI_IndicatorNames
is set in
reason
, this event reports a successful change to the symbolic names bound to one or
more extension device indicators by XKB. If
XkbXI_IndicatorMaps
is set in
reason
, this event reports a successful change to the indicator maps bound to one or
more extension device indicators by XKB. If
XkbXI_IndicatorState
is set in reason, this event reports that one or more indicators in the
specified device and feedback have changed state.
If
XkbXI_UnsupportedFeature
is set in reason, this event reports an unsuccessful attempt to use some XKB
extension device feature that is not supported by the XKB implementation in the
server for the specified device. The
unsupported
mask reports the requested features that are not available on the specified
device. See
The server sends an
XkbExtensionDeviceNotify
event to a client only if at least one of the bits that is set in the
reason
field of the event is also set in the appropriate event details mask for the
client.
Events that report a successful change to some extension device feature are
reported to all clients that have expressed interest in the event; events that
report an attempt to use an unsupported feature are reported only to the client
which issued the request. Events which report a partial success are reported to
all interested clients, but only the client that issued the request is informed
of the attempt to use unsupported features.
xorgproto-2023.2/specs/kbproto/XKBproto-3.svg 0000644 0001750 0001750 00000057173 14443010026 015763 0000000 0000000
image/svg+xml
xorgproto-2023.2/specs/kbproto/acknowledgements.xml 0000644 0001750 0001750 00000005267 14443010026 017443 0000000 0000000
Acknowledgments
I am grateful for all of the comments and suggestions I have received over the years. I could not possibly list everyone who has helped, but a few people have gone well above and beyond the call of duty and simply must be listed here.
My managers here at SGI, Tom Paquin (now at Netscape) and Gianni Mariani were wonderful. Rather than insisting on some relatively quick, specialized proprietary solution to the keyboard problems we were having, both Tom and Gianni understood the importance of solving them in a general way and for the community as a whole. That was a difficult position to take and it was even harder to maintain when the scope of the project expanded beyond anything we imagined was possible. Gianni and Tom were unflagging in their support and their desire to “do the right thing†despite the schedule and budget pressure that intervened from time to time.
Will Walker, at Digital Equipment Corporation, has been a longtime supporter of XKB. His help and input was essential to ensure that the extension as a whole fits and works together well. His focus was AccessX but the entire extension has benefited from his input and hard work. Without his unflagging good cheer and willingness to lend a hand, XKB would not be where it is today.
Matt Landau, at the X Consortium, stood behind XKB during some tough spots in the release and standardization process. Without Matt’s support, XKB would likely not be a standard for a long time to come. When it became clear that we had too much to do for the amount of time we had remaining, Matt did a fantastic job of finding people to help finish the work needed for standardization.
One of those people was George Sachs, at Hewlett-Packard, who jumped in to help out. His help was essential in getting the extension into this release. Another was Donna Converse, who helped figure out how to explain all of this stuff to someone who hadn’t had their head buried in it for years.
Amber Benson and Gary Aitken were simply phenomenal. They jumped into a huge and complicated project with good cheer and unbelievable energy. They were “up to speed†and contributing within days. I stand in awe of the amount that they managed to achieve in such a short time. Thanks to Gary and Amber, the XKB library specification is a work of art and a thousand times easier to use and more useful than it would otherwise be.
I truly cannot express my gratitude to all of you, without whom this would not have been possible.
Erik Fortune
Silicon Graphics, Inc.
5 February 1996
xorgproto-2023.2/specs/kbproto/XKBproto-10.svg 0000644 0001750 0001750 00000012036 14443010026 016026 0000000 0000000
image/svg+xml
xorgproto-2023.2/specs/kbproto/appB.xml 0000644 0001750 0001750 00000005645 14443010026 014773 0000000 0000000
Canonical Key Types
Canonical Key Types
The ONE_LEVEL Key Type
The
ONE_LEVEL
key type describes groups that have only one symbol. The default
ONE_LEVEL
type has no map entries and does not pay attention to any modifiers.
The TWO_LEVEL Key Type
The
TWO_LEVEL
key type describes groups that have two symbols but are neither alphabetic nor
numeric keypad keys. The default
TWO_LEVEL
type uses only the
Shift
modifier. It returns level two if
Shift
is set, level one if it is not.
The ALPHABETIC Key Type
The
ALPHABETIC
key type describes groups that consist of two symbols — the lowercase form
of a symbol followed by the uppercase form of the same symbol. The default
ALPHABETIC
type implements locale-sensitive "shift cancels caps lock" behavior using both
the
Shift
and
Lock
modifiers as follows:
If
Shift
and
Lock
are both set, the default
ALPHABETIC
type yields level one.
If
Shift
alone is set, it yields level two.
If
Lock
alone is set, it yields level one but preserves the
Lock
modifier.
If neither
Shift
nor
Lock
are set, it yields level one.
The KEYPAD Key Type
The
KEYPAD
key type describes that consist of two symbols, at least one of which is a
numeric keypad symbol. The default
KEYPAD
type implements "shift cancels numeric lock" behavior using the
Shift
modifier and the real modifier bound to the virtual modifier named "NumLock"
(the "NumLock" modifier) as follows:
If
Shift
and the "NumLock" modifier are both set, the default
KEYPAD
type yields level one.
If either
Shift
or the "NumLock" modifier alone are set, it yields level two.
If neither
Shift
nor the "NumLock" modifier are set, it yields level one.
xorgproto-2023.2/specs/kbproto/ch04.xml 0000644 0001750 0001750 00000062234 14443010026 014644 0000000 0000000
Global Keyboard Controls
The X Keyboard Extension supports a number of
global key controls
, which affect the way that XKB handles the keyboard as a whole. Many of these
controls make the keyboard more accessible to the physically impaired and are
based on the AccessDOS package
AccessDOS provides access to the DOS operating system for people with physical
impairments and was developed by the Trace R&D Center at the University of
Wisconsin. For more information on AccessDOS, contact the Trace R&D Center,
Waisman Center and Department of Industrial Engineering, University of
Wisconsin-Madison WI 53705-2280. Phone: 608-262-6966. e-mail:
info@trace.wisc.edu.
The RepeatKeys Control
The core protocol only allows control over whether or not the entire keyboard
or individual keys should autorepeat when held down. The
RepeatKeys
control extends this capability by adding control over the delay until a key
begins to repeat and the rate at which it repeats.
RepeatKeys
is also coupled with the core autorepeat control; changes to one are always
reflected in the other.
The
RepeatKeys
control has two parameters. The
autorepeat delay
specifies the delay between the initial press of an autorepeating key and the
first generated repeat event in milliseconds. The
autorepeat interval
specifies the delay between all subsequent generated repeat events in
milliseconds.
The PerKeyRepeat Control
When
RepeatKeys
are active, the
PerKeyRepeat
control specifies whether or not individual keys should autorepeat when held
down. XKB provides the
PerKeyRepeat
for convenience only, and it always parallels the
auto-repeats
field of the core protocol
GetKeyboardControl
request — changes to one are always reflected in the other.
Detectable Autorepeat
The X server usually generates both press and release events whenever an
autorepeating key is held down. If an XKB-aware client enables the
DetectableAutorepeat
per-client option for a keyboard, the server sends that client a key release
event only when the key is
physically
released. For example, holding down a key to generate three characters without
detectable autorepeat yields:
Press -> Release -> Press -> Release -> Press -> Release
If detectable autorepeat is enabled, the client instead receives:
Press-> Press -> Press -> Release
Note that only clients that request detectable autorepeat are affected; other
clients continue to receive both press and release events for autorepeating
keys. Also note that support for detectable autorepeat is optional; servers are
not required to support detectable autorepeat, but they must correctly report
whether or not it is supported.
XkbPerClientFlags
request, which reports or changes values for all of the per-client flags, and
which lists the per-client flags that are supported.
The SlowKeys Control
Some users often bump keys accidentally while moving their hand or typing stick
toward the key they want. Usually, the keys that are bumped accidentally are
hit only for a very short period of time. The
SlowKeys
control helps filter these accidental bumps by telling the server to wait a
specified period, called the
SlowKeys acceptance delay
, before delivering key events. If the key is released before this period
elapses, no key events are generated. The user can then bump any number of keys
on their way to the one they want without generating unwanted characters. Once
they have reached the key they want, they can then hold it long enough for
SlowKeys
to accept it.
The
SlowKeys
control has one parameter; the
slow keys delay
specifies the length of time, in milliseconds, that a key must be held down
before it is accepted.
When
SlowKeys
are active, the X Keyboard Extension reports the initial press, acceptance,
rejection or release of any key to interested clients using
AccessXNotify
events. The
AccessXNotify
event is described in more detail in
The BounceKeys Control
Some people with physical impairments accidentally "bounce" on a key when they
press it. That is, they press it once, then accidentally press it again
immediately. The
BounceKeys
control temporarily disables a key after it has been pressed, effectively
"debouncing" the keyboard.
The
BounceKeys
has a single parameter. The
BounceKeys delay
specifies the period of time, in milliseconds, that the key is disabled after
it is pressed.
When
BounceKeys
are active, the server reports the acceptance or rejection of any key to
interested clients by sending an
AccessXNotify
event. The
AccessXNotify
event is described in more detail in
The StickyKeys Control
Some people find it difficult or impossible to press two keys at once. The
StickyKeys
control makes it easier for them to type by changing the behavior of the
modifier keys. When
StickyKeys
are enabled, a modifier is latched when the user presses it just once, so the
user can first press a modifier, release it, then press another key. For
example, to get an exclamation point (!) on a PC-style keyboard, the user can
press the
Shift
key, release it, then press the
1
key.
By default,
StickyKeys
also allows users to lock modifier keys without requiring special locking
keys. The user can press a modifier twice in a row to lock it, and then unlock
it by pressing it one more time.
Modifiers are automatically unlatched when the user presses a non-modifier key.
For instance, to enter the sequence
Shift
+
Ctrl
+
Z
the user could press and release the
Shift
key to latch the
Shift
modifier, then press and release the
Ctrl
key to latch the
Control
modifier — the
Ctrl
key is a modifier key, so pressing it does not unlatch the
Shift
modifier, but leaves both the
Shift
and
Control
modifiers latched, instead. When the user presses the
Z
key, it will be as though the user pressed
Shift
+
Ctrl
+
Z
simultaneously. The
Z
key is not a modifier key, so the
Shift
and
Control
modifiers are unlatched after the event is generated.
A locked a modifier remains in effect until the user unlocks it. For example,
to enter the sequence ("XKB") on a PC-style keyboard with a typical US/ASCII
layout, the user could press and release the
Shift
key twice to lock the
Shift
modifier. Then, when the user presses the
9
,
‘
,
x
,
k
,
b
,
‘
, and
0
keys in sequence, it will generate ("XKB"). To unlock the
Shift
modifier, the user can press and release the
Shift
key.
Two option flags modify the behavior of the
StickyKeys
control:
If the
XkbAX_TwoKeys
flag is set, XKB automatically turns
StickyKeys
off if the user presses two or more keys at once. This serves to automatically
disable StickyKeys when a user who does not require sticky keys is using the
keyboard.
The
XkbAX_LatchToLock
controls the locking behavior of
StickyKeys
; the
StickyKeys
control only locks modifiers as described above if the
XkbAX_LatchToLock
flag is set.
The MouseKeys Control
The
MouseKeys
control lets a user control all the mouse functions from the keyboard. When
MouseKeys
are enabled, all keys with
MouseKeys
actions bound to them generate core pointer events instead of normal key press
and release events.
The
MouseKeys
control has a single parameter, the
mouse keys default button
, which specifies the core pointer button to be used by mouse keys actions that
do not explicitly specify a button.
The MouseKeysAccel Control
If the
MouseKeysAccel
control is enabled, the effect of a pointer motion action changes as a key is
held down. The
mouse keys delay
specifies the amount of time between the initial key press and the first
repeated motion event. The
mouse keys interval
specifies the amount of time between repeated mouse keys events. The
steps to maximum acceleration
field specifies the total number of events before the key is travelling at
maximum speed. The
maximum acceleration
field specifies the maximum acceleration. The
curve
parameter controls the ramp used to reach maximum acceleration.
When
MouseKeys
are active and a
SA_MovePtr
key action (see
MouseKeysAccel
is enabled and if acceleration is enabled for the key in question, a second
event is generated after
mouse keys delay
milliseconds, and additional events are generated every
mouse keys interval
milliseconds for as long as the key is held down.
Relative Pointer Motion
If the
SA_MovePtr
action specifies relative motion, events are generated as follows: The initial
event always moves the cursor the distance specified in the action; after
steps to maximum acceleration
events have been generated, all subsequent events move the pointer the
distance specified in the action times the
maximum acceleration.
Events after the first but before maximum acceleration has been achieved are
accelerated according to the formula:
Where
action_delta
is the offset specified by the mouse keys action,
max_accel
and
steps_to_max
are parameters to the
MouseKeysAccel
ctrl, and the curveFactor is computed using the
MouseKeysAccel
curve
parameter as follows:
With the result that a
curve
of
0
causes the distance moved to increase linearly from
action_delta
to
, and the minimum legal
curve
of -
1000
causes all events after the first move at
max_accel
. A negative
curve
causes an initial sharp increase in acceleration which tapers off, while a
positive curve yields a slower initial increase in acceleration followed by a
sharp increase as the number of pointer events generated by the action
approaches
steps_to_max
.
Absolute Pointer Motion
If an
SA_MovePtr
action specifies an absolute position for one of the coordinates but still
allows acceleration, all repeated events contain any absolute coordinates
specified in the action.
The AccessXKeys Control
If
AccessXKeys
is enabled many controls can also be turned on or off from the keyboard by
entering the following standard key sequences:
Holding down a shift key by itself for eight seconds toggles the
SlowKeys
control.
Pressing and releasing a shift key five times in a row without any
intervening key events and with less than 30 seconds delay between consecutive
presses toggles the state of the
StickyKeys
control.
Simultaneously operating two or more modifier keys deactivates the
StickyKeys
control.
Some of these key sequences optionally generate audible feedback of the change
in state, as described in
XkbAccessXNotify
events as described in
The AccessXTimeout Control
In environments where computers are shared, features such as
SlowKeys
present a problem: if
SlowKeys
is on, the keyboard can appear to be unresponsive because keys have no effect
unless they are held for a certain period of time. To help address this
problem, XKB provides an
AccessXTimeout
control to automatically change the value of any global controls or AccessX
options if the keyboard is idle for a specified period of time.
The AccessXTimeout control has a number of parameters which affect the duration
of the timeout and the features changed when the timeout expires.
The
AccessX Timeout
field specifies the number of seconds the keyboard must be idle before the
global controls and AccessX options are modified. The
AccessX Options Mask
field specifies which values in the
AccessX Options
field are to be changed, and the
AccessX Options Values
field specifies the new values for those options. The
AccessX Controls Mask
field specifies which controls are to be changed in the global set of
enabled controls
, and the
AccessX Controls Values
field specifies the new values for those controls.
The AccessXFeedback Control
If
AccessXFeedback
is enabled, special beep-codes indicate changes in keyboard controls (or some
key events when
SlowKeys
or
StickyKeys
are active). Many beep codes sound as multiple tones, but XKB reports a single
XkbBellNotify
event for the entire sequence of tones.
All feedback tones are governed by the
AudibleBell
control. Individual feedback tones can be explicitly enabled or disabled using
the
accessX options mask
or set to deactivate after an idle period using the
accessX timeout options mask
. XKB defines the following feedback tones:
Feedback Name
Bell Name
Default Sound
Indicates
FeatureFB
AX_FeatureOn
rising tone
Keyboard control enabled
AX_FeatureOff
falling tone
Keyboard control disabled
AX_FeatureChange
two tones
Several controls changed state
IndicatorFB
AX_IndicatorOn
high tone
Indicator Lit
AX_IndicatorOff
low tone
Indicator Extinguished
AX_IndicatorChange
two high tones
Several indicators changed state
SlowWarnFB
AX_SlowKeysWarning
three high tones
Shift key held for four seconds
SKPressFB
AX_SlowKeyPress
single tone
Key press while
SlowKeys
are on
SKReleaseFB
AX_SlowKeyRelease
single tone
Key release while
SlowKeys
are on
SKAcceptFB
AX_SlowKeyAccept
single tone
Key event accepted by
SlowKeys
SKRejectFB
AX_SlowKeyReject
low tone
Key event rejected by
SlowKeys
StickyKeysFB
AX_StickyLatch
low tone then high tone
Modifier latched by
StickyKeys
AX_StickyLock
high tone
Modifier locked by
StickyKeys
AX_StickyUnlock
low tone
Modifier unlocked by
StickyKeys
BKRejectFB
AX_BounceKeysReject
low tone
Key event rejected by
BounceKeys
Implementations that cannot generate continuous tones may generate multiple
beeps instead of falling and rising tones; for example, they can generate a
high-pitched beep followed by a low-pitched beep instead of a continuous
falling tone.
If the physical keyboard bell is not very capable, attempts to simulate a
continuous tone with multiple bells can sound horrible. Set the
DumbBellFB
AccessX option to inform the server that the keyboard bell is not very capable
and that XKB should use only simple bell combinations. Keyboard capabilities
vary wildly, so the sounds generated for the individual bells when the
DumbBellFB
option is set are implementation specific.
The Overlay1 and Overlay2 Controls
A keyboard overlay allows some subset of the keyboard to report alternate
keycodes when the overlay is enabled. For example a keyboard overlay can be
used to simulate a numeric or editing keypad on keyboard that does not actually
have one by generating alternate of keycodes for some keys when the overlay is
enabled. This technique is very common on portable computers and embedded
systems with small keyboards.
XKB includes direct support for two keyboard overlays, using the
Overlay1
and
Overlay2
controls. When
Overlay1
is enabled, all of the keys that are members of the first keyboard overlay
generate an alternate keycode. When
Overlay2
is enabled, all of the keys that are members of the second keyboard overlay
generate an alternate keycode.
To specify the overlay to which a key belongs and the alternate keycode it
should generate when that overlay is enabled, assign it either the
KB_Overlay1
or
KB_Overlay2
key behaviors, as described in
"Boolean" Controls and The EnabledControls Control
All of the controls described above, along with the
AudibleBell
control (described in
IgnoreGroupLock
control (described in
boolean controls
. In addition to any parameters listed in the descriptions of the individual
controls, the boolean controls can be individually enabled or disabled by
changing the value of the
EnabledControls
control.
The following
non-boolean
controls are always active and cannot be changed using the
EnabledControls
control or specified in any context that accepts only boolean controls:
GroupsWrap
(
EnabledControls
,
InternalMods
(
IgnoreLockMods
(
PerKeyRepeat
(
Automatic Reset of Boolean Controls
The
auto-reset controls
are a per-client value which consist of two masks that can contain any of the
boolean controls (see
auto-reset mask
are set to the corresponding value from the
auto-reset values
mask. This makes it possible for clients to "clean up after themselves"
automatically, even if abnormally terminated.
For example, a client that replace the keyboard bell with some other audible
cue might want to turn off the
AudibleBell
control (
AudibleBell
control, the user would be left without any feedback at all. Setting
AudibleBell
in both the auto-reset mask and auto-reset values guarantees that the audible
bell will be turned back on when the client exits.
xorgproto-2023.2/specs/kbproto/ch08.xml 0000644 0001750 0001750 00000012440 14443010026 014642 0000000 0000000
Symbolic Names
The core protocol does not provide any information to clients other than that
actually used to interpret events. This makes it difficult to write a client
which presents the keyboard to a user in an easy-to-understand way. Such
applications have to examine the vendor string and keycodes to determine the
type of keyboard connected to the server and have to examine keysyms and
modifier mappings to determine the effects of most modifiers (the
Shift
,
Lock
and
Control
modifiers are defined by the core protocol but no semantics are implied for
any other modifiers).
This extension provides such applications with symbolic names for most
components of the keyboard extension and a description of the physical layout
of the keyboard.
The
keycodes
name describes the range and meaning of the keycodes returned by the keyboard
in question; the
keyboard
geometry
name describes the physical location, size and shape of the various keys on the
keyboard. As an example to distinguish between these two names, consider
function keys on PC-compatible keyboards. Function keys are sometimes above the
main keyboard and sometimes to the left of the main keyboard, but the same
keycode is used for the key that is logically
F1
regardless of physical position. Thus, all PC-compatible keyboards might share
a keycodes name but different geometry names.
The keycodes name is intended to be a very general description of
the keycodes returned by a keyboard; A single keycodes name might cover
keyboards with differing numbers of keys provided that the keys that all keys
have the same semantics when present. For example, 101 and 102 key PC keyboards
might use the same name. Applications can use the keyboard geometry to
determine which subset of the named keyboard type is in use.
The
symbols
name identifies the symbols bound to the keys. The symbols name is a human or
application-readable description of the intended locale or usage of the
keyboard with these symbols. The
physical symbols
name describes the symbols actually engraved on the keyboard, which might be
different than the symbols currently being used.
The
types
name provides some information about the set of key types that can be
associated with the keyboard keys. The
compat
name provides some information about the rules used to bind actions to keys
changed using core protocol requests.
The
compat
,
types
,
keycodes
,
symbols
and
geometry
names typically correspond to the keyboard components from which the current
keyboard description was assembled. These components are stored individually in
the server’s database of keyboard components, described in
Each key has a four-byte symbolic name. The key name links keys with similar
functions or in similar positions on keyboards that report different scan
codes.
Key aliases
allow the keyboard layout designer to assign multiple names to a single key,
to make it easier to refer to keys using either their position
or
their "function."
For example, consider the common keyboard customizations:
Set the "key to the left of the letter a" to be a control key.
Change the "caps lock" key, wherever it might be, to a control key.
If we specify key names by position, the first customization is simple but the
second is impossible; if we specify key names by function, the second
customization is simple but the first is impossible. Using key aliases, we can
specify both function and position for "troublesome" keys, and both
customizations are straightforward.
Key aliases can be specified both in the symbolic names component and in the
keyboard geometry (see
XKB provides symbolic names for each of the four keyboard groups, sixteen
virtual modifiers, thirty-two keyboard indicators, and up to
MaxRadioGroups
(32) radio groups.
XKB allows keyboard layout designers or editors to assign names to each key
type and to each of the levels in a key type. For example, the second position
on an alphabetic key might be called the "Caps" level while the second position
on a numeric keypad key might be called the "Num Lock" level.
xorgproto-2023.2/specs/kbproto/xkbproto.xml 0000644 0001750 0001750 00000007713 14443010026 015757 0000000 0000000
%defs;
]>
The X Keyboard Extension: Protocol Specification
X Consortium Standard
Erik
Fortune
Silicon Graphics, Inc
X Version 11, Release &fullrelvers;
Version 1.0
1995 1996
X Consortium Inc.
Silicon Graphics Inc.
Hewlett-Packard Company
Digital Equipment Corporation
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Softwareâ€), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 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.
Except as contained in this notice, the names of the X Consortium, Silicon Graphics Inc., Hewlett-Packard Company, and Digital Equipment Corporation shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization.
xorgproto-2023.2/specs/kbproto/appC.xml 0000644 0001750 0001750 00000036737 14443010026 015002 0000000 0000000
New KeySyms
New KeySyms
KeySyms Used by the ISO9995 Standard
Byte 3
Byte 4
Character
Name
254
1
ISO LOCK
254
2
ISO LATCHING LEVEL TWO SHIFT
254
3
ISO LEVEL THREE SHIFT
254
4
ISO LATCHING LEVEL THREE SHIFT
254
5
ISO LEVEL THREE SHIFT LOCK
254
6
ISO LATCHING GROUP SHIFT
254
7
ISO GROUP SHIFT LOCK
254
8
ISO NEXT GROUP
254
9
ISO LOCK NEXT GROUP
254
10
ISO PREVIOUS GROUP
254
11
ISO LOCK PREVIOUS GROUP
254
12
ISO FIRST GROUP
254
13
ISO LOCK FIRST GROUP
254
14
ISO LAST GROUP
254
15
ISO LOCK LAST GROUP
254
32
LEFT TAB
254
33
MOVE LINE UP
254
34
MOVE LINE DOWN
254
35
PARTIAL LINE UP
254
36
PARTIAL LINE DOWN
254
37
PARTIAL SPACE LEFT
254
38
PARTIAL SPACE RIGHT
254
39
SET MARGIN LEFT
254
40
SET MARGIN RIGHT
254
41
RELEASE MARGIN LEFT
254
42
RELEASE MARGIN RIGHT
254
43
RELEASE MARGIN LEFT AND RIGHT
254
44
FAST CURSOR LEFT
254
45
FAST CURSOR RIGHT
254
46
FAST CURSOR UP
254
47
FAST CURSOR DOWN
254
48
CONTINUOUS UNDERLINE
254
49
DISCONTINUOUS UNDERLINE
254
50
EMPHASIZE
254
51
CENTER OBJECT
254
52
ISO_ENTER
KeySyms Used to Control The Core Pointer
Byte 3
Byte 4
Character
Name
254
224
POINTER LEFT
254
225
POINTER RIGHT
254
226
POINTER UP
254
227
POINTER DOWN
254
228
POINTER UP AND LEFT
254
229
POINTER UP AND RIGHT
254
230
POINTER DOWN AND LEFT
254
231
POINTER DOWN AND RIGHT
254
232
DEFAULT POINTER BUTTON
254
233
POINTER BUTTON ONE
254
234
POINTER BUTTON TWO
254
235
POINTER BUTTON THREE
254
236
POINTER BUTTON FOUR
254
237
POINTER BUTTON FIVE
254
238
DEFAULT POINTER BUTTON DOUBLE CLICK
254
239
POINTER BUTTON ONE DOUBLE CLICK
254
240
POINTER BUTTON TWO DOUBLE CLICK
254
241
POINTER BUTTON THREE DOUBLE CLICK
254
242
POINTER BUTTON FOUR DOUBLE CLICK
254
243
POINTER BUTTON FIVE DOUBLE CLICK
254
244
DRAG DEFAULT POINTER BUTTON
254
245
DRAG POINTER BUTTON ONE
254
246
DRAG POINTER BUTTON TWO
254
247
DRAG POINTER BUTTON THREE
254
248
DRAG POINTER BUTTON FOUR
254
249
ENABLE POINTER FROM KEYBOARD
254
250
ENABLE KEYBOARD POINTER ACCEL
254
251
SET DEFAULT POINTER BUTTON NEXT
254
252
SET DEFAULT POINTER BUTTON PREVIOUS
254
253
DRAG POINTER BUTTON FIVE
KeySyms Used to Change Keyboard Controls
Byte 3
Byte 4
Character
Name
254
112
ENABLE ACCESSX KEYS
254
113
ENABLE ACCESSX FEEDBACK
254
114
TOGGLE REPEAT KEYS
254
115
TOGGLE SLOW KEYS
254
116
ENABLE BOUNCE KEYS
254
117
ENABLE STICKY KEYS
254
118
ENABLE MOUSE KEYS
254
119
ENABLE MOUSE KEYS ACCELERATION
254
120
ENABLE OVERLAY1
254
121
ENABLE OVERLAY2
254
122
ENABLE AUDIBLE BELL
KeySyms Used To Control The Server
Byte
Byte
Character
Name
254
208
FIRST SCREEN
254
209
PREVIOUS SCREEN
254
210
NEXT SCREEN
254
211
LAST SCREEN
254
212
TERMINATE SERVER
KeySyms for Non-Spacing Diacritical Keys
Byte
Byte
Character
Name
254
80
DEAD GRAVE ACCENT
254
81
DEAD ACUTE ACCENT
254
82
DEAD CIRCUMFLEX
254
83
DEAD TILDE
254
84
DEAD MACRON
254
85
DEAD BREVE
254
86
DEAD DOT ABOVE
254
87
DEAD DIAERESIS
254
88
DEAD RING ABOVE
254
89
DEAD DOUBLE ACUTE ACCENT
254
90
DEAD CARON
254
91
DEAD CEDILLA
254
92
DEAD OGONEK
254
93
DEAD IOTA
254
94
DEAD VOICED SOUND
254
95
DEAD SEMI VOICED SOUND
254
96
DEAD DOT BELOW
xorgproto-2023.2/specs/kbproto/ch11.xml 0000644 0001750 0001750 00000032026 14443010026 014636 0000000 0000000
Keyboard Geometry
The XKB description of a keyboard includes an optional keyboard geometry which
describes the physical appearance of the keyboard. Keyboard geometry describes
the shape, location and color of all keyboard keys or other visible keyboard
components such as indicators. The information contained in a keyboard geometry
is sufficient to allow a client program to draw an accurate two-dimensional
image of the keyboard.
The components of the keyboard geometry include the following:
A
symbolic name
to help users identify the keyboard.
The
width
and
height
of the keyboard, in
. For non-rectangular keyboards, the width and height describe the smallest
bounding-box that encloses the outline of the keyboard.
A list of up to
MaxColors
(
32
)
color names
. A color name is a string whose interpretation is not specified by XKB. Other
geometry components refer to colors using their indices in this list.
The
base color
of the keyboard is the predominant color on the keyboard and is used as the
default color for any components whose color is not explicitly specified.
The
label color
is the color used to draw the labels on most of the keyboard keys.
The
label font
is a string which describes the font used to draw labels on most keys; XKB
does not specify a format or name space for font names.
A list of
geometry properties
. A geometry property associates an arbitrary string with an equally arbitrary
name. Geometry properties can be used to provide hints to programs that display
images of keyboards, but they are not interpreted by XKB. No other geometry
structures refer to geometry properties.
A list of
key aliases
, as described in
A list of
shapes
; other keyboard components refer to shapes by their index in this list. A
shape consists of a name and one or more closed-polygons called
outlines
. Shapes and outlines are described in detail in
Unless otherwise specified, geometry measurements are in
units. The origin (0,0) is in the top left corner of the keyboard image. Some
geometry components can be drawn rotated; all such objects rotate about their
origin in
increments.
All geometry components include a
priority
, which indicates the order in which overlapping objects should be drawn.
Objects are drawn in order from highest priority (
0
) to lowest (
255
).
The description of the actual appearance of the keyboard is subdivided into
named
sections
of related keys and
doodads
. A a
doodad
describes some visible aspect of the keyboard that is not a key. A section is
a collection of keys and doodads that are physically close together and
logically related.
Shapes and Outlines
An outline is a list of one or more points which describes a single
closed-polygon, as follows:
A list with a single point describes a rectangle with one corner at the
origin of the shape (
0
,
0
) and the opposite corner at the specified point.
A list of two points describes a rectangle with one corner at the
position specified by the first point and the opposite corner at the position
specified by the second point.
A list of three or more points describes an arbitrary polygon. If
necessary, the polygon is automatically closed by connecting the last point in
the list with the first.
A non-zero value for the
cornerRadius
field specifies that the corners of the polygon should be drawn as circles
with the specified radius.
All points in an outline are specified relative to the origin of the enclosing
shape. Points in an outline may have negative values for the X and Y coordinate.
One outline (usually the first) is the primary outline; a keyboard display
application can generate a simpler but still accurate keyboard image by
displaying only the primary outlines for each shape. Non-rectangular keys must
include a rectangular
approximation
as one of the outlines associated with the shape; the approximation is not
normally displayed but can be used by very simple keyboard display applications
to generate a recognizable but degraded image of the keyboard.
Sections
Each section has its own coordinate system — if a section is rotated, the
coordinates of any components within the section are interpreted relative to
the edges that were on the top and left before rotation. The components that
make up a section include:
A list of
rows
. A row is a list of horizontally or vertically adjacent keys. Horizontal rows
parallel the (pre-rotation) top of the section and vertical rows parallel the
(pre-rotation) left of the section. All keys in a horizontal row share a common
top coordinate; all keys in a vertical row share a left coordinate.
A key description consists of a key
name
, a
shape
, a key
color
, and a
gap
. The key
name
should correspond to one of the keys named in the keyboard names description,
the
shape
specifies the appearance of the key, and the key
color
specifies the color of the key (not the label on the key). Keys are normally
drawn immediately adjacent to one another from left-to-right (or top-to-bottom)
within a row. The
gap
field specifies the distance between a key and its predecessor.
An optional list of doodads; any type of doodad can be enclosed within
a section. Position and angle of rotation are relative to the origin and angle
of rotation of the sections that contain them. Priority is relative to the
other components of the section, not to the keyboard as a whole.
An optional list of
overlay keys
. Each overlay key definition indicates a key that can yield multiple scan
codes and consists of a field named
under
, which specifies the primary name of the key and a field named
over
, which specifies the name for the key when the overlay keycode is selected.
The key specified in
under
must be a member of the section that contains the overlay key definition,
while the key specified in over must not.
Doodads
Doodads can be global to the keyboard or part of a section. Doodads have
symbolic names of arbitrary length. The only doodad name whose interpretation
is specified by XKB is "Edges", which describes the outline of the entire
keyboard, if present.
All doodads report their origin in fields named
left
and
top
. XKB supports five kinds of doodads:
An
indicator doodad
describes one of the physical keyboard indicators. Indicator doodads specify
the shape of the indicator, the indicator color when it is lit (
on_color
) and the indicator color when it is dark (
off_color
).
An
outline doodad
describes some aspect of the keyboard to be drawn as one or more hollow,
closed polygons. Outline doodads specify the shape, color, and angle of
rotation about the doodad origin at which they should be drawn.
A
solid doodad
describes some aspect of the keyboard to be drawn as one or more filled
polygons. Solid doodads specify the shape, color and angle of rotation about
the doodad origin at which they should be drawn.
A
text doodad
describes a text label somewhere on the keyboard. Text doodads specify the
label string, the font and color to use when drawing the label, and the angle
of rotation of the doodad about its origin.
A
logo doodad
is a catch-all, which describes some other visible element of the keyboard. A
logo doodad is essentially an outline doodad with an additional symbolic name
that describes the element to be drawn.
If a keyboard display program recognizes the symbolic name, it can draw
something appropriate within the bounding region of the shape specified in the
doodad. If the symbolic name does not describe a recognizable image, it should
draw an outline using the specified shape, outline, and angle of rotation.
The XKB extension does not specify the interpretation of logo names.
Keyboard Geometry Example
Consider the following example keyboard:
This keyboard has six sections: The left and right function sections (at the
very top) each have one horizontal row with eight keys. The left and right
alphanumeric sections (the large sections in the middle) each have six vertical
rows, with four or five keys in each row. The left and right editing sections
each have three vertical rows with one to three keys per row; the left editing
section is rotated 20° clockwise about its origin while the right editing
section is rotated 20° counterclockwise.
This keyboard has four global doodads: Three small, round indicators and a
rectangular logo. The program which generated this image did not recognize the
logo, so it displays an outline with an appropriate shape in its place.
This keyboard has seven shapes: All of the keys in the two function sections
use the "FKEY" shape. Most of the keys in the alphanumeric sections, as well as
four of the keys in each of the editing sections use the "NORM" shape. The keys
in the first column of the left alphanumeric section and the last column of the
right alphanumeric section all use the "WIDE" shape. Two keys in each of the
editing sections use the "TALL" shape. The "LED" shape describes the three
small, round indicators between the function and alphabetic sections. The
"LOGO" shape describes the keyboard logo, and the "EDGE" shape describes the
outline of the keyboard as a whole.
The keyboard itself is white, as are all of the keys except for the eight keys
that make up the home row, which use the "grey20" color. It isn’t really
visible in this picture, but the three indicators have an "on" color of "green"
and are "green30" when they are turned off. The keys in the alphanumeric and
editing sections all have a (vertical) gap of 0.5mm; the keys in the two
function sections have a (horizontal) gap of 3mm.
Many of the keys in the right alphanumeric section, and the rightmost key in
the right editing section are drawn with two names in this image. Those are
overlay keys; the bottom key name is the normal name while the overlay name is
printed at the top. For example, the right editing section has a single overlay
key entry, which specifies an
under
name of
<SPCE>
and an
over
name of
<KP0>
, which indicates that the key in question is usually the shift key, but can
behave like the
0
key on the numeric keypad when an overlay is active.
xorgproto-2023.2/specs/kbproto/ch07.xml 0000644 0001750 0001750 00000047106 14443010026 014650 0000000 0000000
Key Event Processing in the Client
The XKB
client map
for a keyboard is the collection of information a client needs to interpret
key events that come from that keyboard. It contains a global list of
key types
, described in
key symbol map
s, each of which describes the symbols bound to one particular key and the
rules to be used to interpret those symbols.
Notation and Terminology
XKB associates a two-dimensional array of symbols with each key. Symbols are
addressed by keyboard group (see
Level
One of several states (normally 2 or 3) which govern which graphic
character is produced when a graphic key is actuated. In certain cases the
level may also affect function keys.
Note that shift level is derived from the modifier state, but not necessarily
in the same way for all keys. For example, the
Shift
modifier selects shift level 2 on most keys, but for keypad keys the modifier
bound to
Num_Lock
(i.e. the
NumLock
virtual modifier) also selects shift level 2.gray symbols on a key
We use the notation G
n
L
n
to specify the position of a symbol on a key or in memory:
The gray characters indicate symbols that are implied or expected but are not
actually engraved on the key.
Unfortunately, the "natural" orientation of symbols on a key and
the natural orientation in memory are reversed from one another, so keyboard
group refers to a column on the key and a row in memory. There’s no real help
for it, but we try to minimize confusion by using "group" and "level" (or
"shift level") to refer to symbols regardless of context.
Determining the KeySym Associated with a Key Event
To look up the symbol associated with an XKB key event, we need to know the
group and shift level that correspond to the event.
Group is reported in bits 13-14 of the state field of the key event, as
described in
group info
field which is interpreted identically to the global groups wrap control (see
Once we have determined the group to be used for the event, we have to
determine the shift level. The description of a key includes a
key type
for each group of symbols bound to the key. Given the modifiers from the key
event, this key type yields a shift level and a set of "leftover" modifiers, as
described in
Finally, we can use the effective group and the shift level returned by the
type of that group to look up a symbol in a two-dimensional array of symbols
associated with the key.
Key Types
Each entry of a key type’s
map
field specifies the shift level that corresponds to some XKB modifier
definition; any combination of modifiers that is not explicitly listed
somewhere in the map yields shift level one. Map entries which specify unbound
virtual modifiers (see
active
field which indicates whether or not it should be used.
Each key type includes a few fields that are derived from the contents of the
map and which report some commonly used values so they don’t have to be
constantly recalculated. The
numLevels
field contains the highest shift level reported by any of its map entries; XKB
uses
numLevels
to insure that the array of symbols bound to a key is large enough (the number
of levels reported by a key type is also referred to as its width). The
modifiers
field reports all real modifiers considered by any of the map entries for the
type. Both
modifiers
and
numLevels
are updated automatically by XKB and neither can be changed explicitly.
Any modifiers specified in
modifiers
are normally
consumed
(see
should
be considered despite having been used to look up a symbol, key types include
an optional
preserve
field. If a
preserve
list is present, each entry corresponds to one of the key type’s map entries
and lists the modifiers that should
not
be consumed if the matching map entry is used to determine shift level.
For example, the following key type implements caps lock as defined by the core
protocol (using the second symbol bound to the key):
type "ALPHABETIC" {
modifiers = Shift+Lock;
map[Shift]= Level2;
map[Lock]= Level2;
map[Shift+Lock]= Level2;
};
The problem with this kind of definition is that we could assign completely
unrelated symbols to the two shift levels, and "Caps Lock" would choose the
second symbol. Another definition for alphabetic keys uses system routines to
capitalize the keysym:
type "ALPHABETIC" {
modifiers= Shift;
map[Shift]= Level2;
};
When caps lock is applied using this definition, we take the symbol from shift
level one and capitalize it using system-specific capitalization rules. If
shift and caps lock are both set, we take the symbol from shift level two and
try to capitalize it, which usually has no effect.
The following key type implements shift-cancels-caps lock behavior for
alphabetic keys:
type "ALPHABETIC" {
modifiers = Shift+Lock;
map[Shift] = Level2;
preserve[Lock]= Lock;
};
Consider the four possible states that can affect alphabetic keys: no
modifiers, shift alone, caps lock alone or shift and caps lock together. The
map contains no explicit entry for
None
(no modifiers), so if no modifiers are set, any group with this type returns
the first keysym. The map entry for
Shift
reports
Level2
, so any group with this type returns the second symbol when
Shift
is set. There is no map entry for
Lock
alone, but the type specifies that the
Lock
modifier should be preserved in this case, so
Lock
alone returns the first symbol in the group but first applies the
capitalization transformation, yielding the capital form of the symbol. In the
final case, there is no map entry for
Shift+Lock
, so it returns the first symbol in the group; there is no preserve entry, so
the
Lock
modifier is consumed and the symbol is not capitalized.
Key Symbol Map
The
key symbol map
for a key contains all of the information that a client needs to process
events generated by that key. Each key symbol mapping reports:
The number of groups of symbols bound to the key (
numGroups
).
The treatment of out-of-range groups (
groupInfo
).
The index of the key type to for each
possible
group (
kt_index[MaxKbdGroups]
).
The width of the widest type associated with the key (
groupsWidth
).
The two-dimensional (numGroups
×
groupsWidth) array of symbols bound to the key.
It is legal for a key to have zero groups, in which case it also has zero
symbols and all events from that key yield
NoSymbol
. The array of key types is of fixed width and is large enough to hold key
types for the maximum legal number of groups (
MaxKbdGroups
, currently four); if a key has fewer than
MaxKbdGroups
groups, the extra key types are reported but ignored. The
groupsWidth
field cannot be explicitly changed; it is updated automatically whenever the
symbols or set of types bound to a key are changed.
If, when looking up a symbol, the effective keyboard group is out-of-range for
the key, the
groupInfo
field of the key symbol map specifies the rules for determining the
corresponding legal group as follows:
If the
RedirectIntoRange
flag is set, the two least significant bits of
groupInfo
specify the index of a group to which all illegal groups correspond. If the
specified group is also out of range, all illegal groups map to
Group1
.
If
ClampIntoRange
flag is set, out-of-range groups correspond to the nearest legal group.
Effective groups larger than the highest supported group are mapped to the
highest supported group; effective groups less than
Group1
are mapped to
Group1
. For example, a key with two groups of symbols uses
Group2
type and symbols if the global effective group is either
Group3
or
Group4
.
If neither flag is set, group is wrapped into range using integer
modulus. For example, a key with two groups of symbols for which groups wrap
uses
Group1
symbols if the global effective group is
Group3
or
Group2
symbols if the global effective group is
Group4
.
The client map contains an array of key symbol mappings, with one entry for
each key between the minimum and maximum legal keycodes, inclusive. All
keycodes which fall in that range have key symbol mappings, whether or not any
key actually yields that code.
Transforming the KeySym Associated with a Key Event
Any modifiers that were not used to look up the keysym, or which were
explicitly preserved, might indicate further transformations to be performed on
the keysym or the character string that is derived from it. For example, If the
Lock
modifier is set, the symbol and corresponding string should be capitalized
according to the locale-sensitive capitalization rules specified by the system.
If the
Control
modifier is set, the keysym is not affected, but the corresponding character
should be converted to a control character as described in
This extension specifies the transformations to be applied when the
Control
or
Lock
modifiers are active but were not used to determine the keysym to be used:
Modifier
Transformation
Control
Report the control character associated with the symbol. This
extension defines the control characters associated with the ASCII alphabetic
characters (both upper and lower case) and for a small set of punctuation
characters (see
Lock
Capitalize the symbol either according to capitalization rules
appropriate to the application locale or using the capitalization rules defined
by this extension (see
Interpretation of other modifiers is application dependent.
This definition of capitalization is fundamentally different from
the core protocol’s, which uses the lock modifier to select from the symbols
bound to the key. Consider key 9 in the
XKB specifies the behavior of
Lock
and
Control
, but interpretation of other modifiers is left to the application.
Client Map Example
Consider a simple, if unlikely, keyboard with the following keys (gray
characters indicate symbols that are implied or expected but are not actually
engraved on the key):
The core protocol represents this keyboard as a simple array with one row per
key and four columns (the widest key, key 10, determines the width of the
entire array).
Key
G1L1
G1L2
G2L1
G2L2
8
Q
NoSymbol
at
NoSymbol
9
odiaeresis
egrave
NoSymbol
NoSymbol
10
A
NoSymbol
Æ
NoSymbol
11
ssharp
question
backslash
questiondown
12
KP_End
KP_1
NoSymbol
NoSymbol
13
Num_Lock
NoSymbol
NoSymbol
NoSymbol
14
NoSymbol
NoSymbol
NoSymbol
NoSymbol
15
Return
NoSymbol
NoSymbol
NoSymbol
The row to be used for a given key event is determined by keycode; the column
to be used is determined by the symbols bound to the key, the state of the
Shift
and
Lock
Modifiers and the state of the modifiers bound to the
Num_Lock
and
Mode_switch
keys as specified by the core protocol.
The XKB description of this keyboard consists of six key symbol maps, each of
which specifies the types and symbols associated with each keyboard group for
one key:
Key
Group: Type
L1
L2
8
G1: ALPHABETIC
q
Q
G2: ONE_LEVEL
@
NoSymbol
9
G1: TWO_LEVEL
odiaeresis
egrave
10
G1: ALPHABETIC
a
A
G2: ALPHABETIC
ae
AE
11
G1: TWO_LEVEL
ssharp
question
G2: ONE_LEVEL
backslash
questiondown
12
G1: KEYPAD
KP_End
KP_1
13
G1: ONE_LEVEL
Num_Lock
14
No Groups
15
G1: ONE_LEVEL
Return
The keycode reported in a key event determines the row to be used for that
event; the effective keyboard group determines the list of symbols and key type
to be used. The key type determines which symbol is chosen from the list.
xorgproto-2023.2/specs/kbproto/ch10.xml 0000644 0001750 0001750 00000012176 14443010026 014641 0000000 0000000
Keyboard Bells
The core protocol provides requests to control the pitch, volume and duration
of the keyboard bell and a request to explicitly sound the bell.
The X Keyboard Extension allows clients to disable the audible bell, attach a
symbolic name to a bell request or receive an event when the keyboard bell is
rung.
Client Notification of Bells
Clients can ask to receive
XkbBellNotify
event when a bell is requested by a client or generated by the server. Bells
can be sounded due to core protocol
Bell
requests, X Input Extension
DeviceBell
requests, X Keyboard Extension
XkbBell
requests or for reasons internal to the server such as the XKB
AccessXFeedback
control.
Bell events caused by the
XkbBell
request or by the
AccessXFeedback
control include an optional window and symbolic name for the bell. If present,
the window makes it possible to provide some kind of visual indication of which
window caused the sound. The symbolic name can report some information about
the reason the bell was generated and makes it possible to generate a distinct
sound for each type of bell.
Disabling Server Generated Bells
The global
AudibleBell
boolean control for a keyboard indicates whether bells sent to that device
should normally cause the server to generate a sound. Applications which
provide "sound effects" for the various named bells will typically disable the
server generation of bells to avoid burying the user in sounds.
When the
AudibleBell
control is active, all bells caused by core protocol
Bell
and X Input Extension
DeviceBell
requests cause the server to generate a sound, as do all bells generated by
the XKB
AccessXFeedback
control. Bells requested via the X
kbBell
request normally cause a server-generated sound, but clients can ask the
server not to sound the default keyboard bell.
When the
AudibleBell
control is disabled, the server generates a sound only for bells that are
generated using the
XkbBell
request and which specify forced delivery of the bell.
Generating Named Bells
The
XkbBell
request allows clients to specify a symbolic name which is reported in the
bell events they cause. Bells generated by the
AccessXFeedback
control of this extension also include a symbolic name, but all kinds of
feedback cause a single event even if they sound multiple tones.
The X server is permitted to use symbolic bell names (when present) to generate
sounds other than simple tones, but it is not required to do so.
Aside from those used by the XKB
AccessXFeedback
control (see
Generating Optional Named Bells
Under some circumstances, some kind of quiet audio feedback is useful, but a
normal keyboard bell is not. For example, a quiet "launch effect" can be
helpful to let the user know that an application has been started, but a loud
bell would simply be annoying.
To simplify generation of these kinds of effects, the
XkbBell
request allows clients to specify "event only" bells. The X server never
generates a normal keyboard bell for "event only" bells, regardless of the
setting of the global
AudibleBell
control.
If the X server generates different sounds depending bell name, it is permitted
to generate a sound even for "event only" bells. This field is intended simply
to weed out "normal" keyboard bells.
Forcing a Server Generated Bell
Occasionally, it is useful to force the server to generate a sound. For
example, a client could "filter" server bells, generating sound effects for
some but sounding the normal server bell for others. Such a client needs a way
to tell the server that the requested bell should be generated regardless of
the setting of the
AudibleBell
control.
To simplify this process, clients which call the
XkbBell
request can specify that a bell is forced. A forced bell always causes a
server generated sound and never causes a
XkbBellNotify
event. Because forced bells do not cause bell notify events, they have no
associated symbolic name or event window.
xorgproto-2023.2/specs/kbproto/ch12.xml 0000644 0001750 0001750 00000102111 14443010026 014630 0000000 0000000
Interactions Between XKB and the Core Protocol
In addition to providing a number of new requests, XKB replaces or extends
existing core protocol requests and events. Some aspects of the this extension,
such as the ability to lock any key or modifier, are visible even to clients
that are unaware of the XKB extension. Other capabilities, such as control of
keysym selection on a per-key basis, are available only to XKB-aware clients.
Though they do not have access to some advanced extension capabilities, the XKB
extension includes compatibility mechanisms to ensure that non-XKB clients
behave as expected and operate at least as well with an XKB-capable server as
they do today.
There are a few significant areas in which XKB state and mapping differences
might be visible to XKB-unaware clients:
The core protocol uses a modifier to choose between two keyboard
groups, while this extension provides explicit support for multiple groups.
The order of the symbols associated with any given key by XKB might not
match the ordering demanded by the core protocol.
To minimize problems that might result from these differences, XKB includes
ways to specify the correspondence between core protocol and XKB modifiers and
symbols.
This section describes the differences between the core X protocol’s notion
of a keyboard mapping and XKB and explains the ways they can interact.
Group Compatibility Map
As described in
A keyboard description includes one
group compatibility map
per keyboard group (four in all). Each such map is a modifier definition (i.e.
specifies both real and virtual modifiers) which specifies the modifiers to be
set in the compatibility states when the corresponding keyboard group is
active. Here are a few examples to illustrate the application of the group
compatibility map:
Group
GroupCompat Map
Effective Modifiers
State for XKB Clients
Compatibility Modifiers
State for non-XKB Clients
1
Group1=None
Shift
x00xxxxx00000001
Shift
xxxxxxxx00000001
2
Group2=Mod3
None
x01xxxxx00000000
Mod3
xxxxxxxx00100000
3
Group3=Mod2
Shift
x10xxxxx00000001
Shift+Mod2
xxxxxxxx00010001
4
Group4=None
Control
x11xxxxx00000100
Control
xxxxxxxx00000100
Note that non-XKB clients (i.e. clients that are linked with a version of the X
library that does not support XKB) cannot detect the fact that
Group4
is active in this example because the group compatibility map for
Group4
does not specify any modifiers.
Setting a Passive Grab for an XKB State
The fact that the
state
field of an event might look different when XKB is present can cause problems
with passive grabs. Existing clients specify the modifiers they wish to grab
using the rules defined by the core protocol, which use a normal modifier to
indicate keyboard group. If we used an XKB state field, the high bits of the
state field would be non-zero whenever the keyboard was in any group other than
Group1
, and none of the passive grabs set by clients could ever be triggered.
To avoid this behavior, the X server normally uses the compatibility grab state
to decide whether or not to activate a passive grab, even for XKB-aware
clients. The group compatibility map attempts to encode the keyboard group in
one or more modifiers of the compatibility state, so existing clients continue
to work exactly the way they do today. By default, there is no way to directly
specify a keyboard group in a
Grabbed
or
GrabButton
request, but groups can be specified indirectly by correctly adjusting the
group compatibility map.
Clients that wish to specify an XKB keyboard state, including a separate
keyboard group, can set the
GrabsUseXKBState
per-client flag which indicates that all subsequent key and button grabs from
the requesting clients are specified using an XKB state.
Whether the XKB or core state should be used to trigger a grab is determined by
the setting of the
GrabsUseXKBState
flag for the requesting client at the time the key or button is grabbed. There
is no way to change the state to be used for a grab that is already registered
or for grabs that are set by some other client.
Changing the Keyboard Mapping Using the Core Protocol
An XKB keyboard description includes a lot of information that is not present
in the core protocol description of a keyboard. Whenever a client remaps the
keyboard using core protocol requests, XKB examines the map to determine likely
default values for the components that cannot be specified using the core
protocol.
Some aspects of this automatic mapping are configurable, and make it fairly
easy to take advantage of many XKB features using existing tools like
xmodmap
, but much of the process of mapping a core keyboard description into an XKB
description is designed to preserve compatible behavior for pre-XKB clients and
cannot be redefined by the user. Clients or users that want behavior that
cannot be described using this mapping should use XKB functions directly.
Explicit Keyboard Mapping Components
This automatic remapping might accidentally replace definitions that were
explicitly requested by an application, so the XKB keyboard description defines
a set of
explicit components
for each key; any components that are listed in the explicit components for a
key are not changed by the automatic keyboard mapping. The explicit components
field for a key can contain any combination of the following values:
Bit in Explicit Mask
Protects Against
ExplicitKeyType1
Automatic determination of the key type associated with
Group1
(see
ExplicitKeyType2
Automatic determination of the key type associated with
Group2
(see
ExplicitKeyType3
Automatic determination of the key type associated with
Group3
(see
ExplicitKeyType4
Automatic determination of the key type associated with
Group4
(see
ExplicitInterpret
Application of any of the fields of a symbol interpretation to the
key in question (see
ExplicitAutoRepeat
Automatic determination of autorepeat status for the key, as
specified in a symbol interpretation (see
ExplicitBehavior
Automatic assignment of the
KB_Lock
behavior to the key, if the
LockingKey
flag is set in a symbol interpretation (see
ExplicitVModMap
Automatic determination of the virtual modifier map for the key
based on the actions assigned to the key and the symbol interpretations which
match the key (see
Assigning Symbols To Groups
The first step in applying the changes specified by a core protocol
ChangeKeyboardMapping
request to the XKB description of a keyboard is to determine the number of
groups that are defined for the key and the width of each group. The XKB
extension does not change key types in response to core protocol
SetModifierMapping
requests, but it does choose key actions as described in
Determining the number of symbols required for each group is straightforward.
If the key type for some group is not protected by the corresponding
ExplicitKeyType
component, that group has two symbols. If any of the explicit components for
the key include
ExplicitKeyType3
or
ExplicitKeyType4
, the width of the key type currently assigned to that group determines the
number of symbols required for the group in the core protocol keyboard
description. The explicit type components for
Group1
and
Group2
behave similarly, but for compatibility reasons the first two groups must have
at least two symbols in the core protocol symbol mapping. Even if an explicit
type assigned to either of the first two keyboard groups has fewer than two
symbols, XKB requires two symbols for it in the core keyboard description.
If the core protocol request contains fewer symbols than XKB needs, XKB adds
trailing
NoSymbol
keysyms to the request to pad it to the required length. If the core protocol
request includes more symbols than it needs, XKB truncates the list of keysyms
to the appropriate length.
Finally, XKB divides the symbols from the (possibly padded or truncated) list
of symbols specified by the core protocol request among the four keyboard
groups. In most cases, the symbols for each group are taken from the core
protocol definition in sequence (i.e. the first pair of symbols is assigned to
Group1
, the second pair of symbols is assigned to
Group2
, and so forth). If either
Group1
or
Group2
has an explicitly defined key type with a width other than two, it gets a
little more complicated.
Assigning Symbols to Groups One and Two with Explicitly Defined Key Types
The server assigns the first four symbols from the expanded or truncated map to
the symbol positions G1L1 , G1L2 ,
G2L1 and G2L2 , respectively. If the key
type assigned to Group1 reports more than two shift levels,
the fifth and following symbols contain
the extra keysyms for
Group2
. If the key type assigned to
Group2
reports more than two shift levels, the extra symbols follow the symbols (if
any) for
Group1
in the core protocol list of symbols. Symbols for
Group3
and
Group4
are contiguous and follow the extra symbols, if any, for
Group1
and
Group2
.
For example, consider a key with a key type that returns three shift levels
bound to each group. The symbols bound to the core protocol are assigned in
sequence to the symbol positions:
G1L1 , G1L2 , G2L1 , G2L2 , G1L3 , G2L3 , G3L1 , G3L2 , G3L3 , G4L1 , G4L2 , and G4L3
For a key with a width one key type on group one, a width two key type on group
two and a width three key type on group three, the symbols bound to the key by
the core protocol are assigned to the following key positions:
G1L1 , (G1L2 ), G2L1 , G2L2 , G3L1 , G3L2 , G3L3
Note that the second and fourth symbols (positions
G1L2 and G2L2
) can never be generated if the key type associated with the group yields only
one symbol. XKB accepts and ignores them in order to maintain compatibility
with the core protocol.
Assigning Types To Groups of Symbols for a Key
Once the symbols specified by
ChangeKeyboardMapping
have been assigned to the four keyboard groups for a key, the X server assigns
a key type to each group on the key from a canonical list of key types. The
first four key types in any keyboard map are reserved for these standard key
types:
Key Type Name
Standard Definition
ONE_LEVEL
Describes keys that have exactly one symbol per group. Most special
or function keys (such as
Return
) are
ONE_LEVEL
keys. Any combination of modifiers yields level
0
. Index
0
in any key symbol map specifies key type
ONE_LEVEL
.
TWO_LEVEL
Describes non-keypad and non-alphabetic keys that have exactly two
symbols per group. By default, the
TWO_LEVEL
type yields column
1
if the Shift modifier is set, column
0
otherwise. Index
1
in any key symbol map specifies key type
TWO_LEVEL
.
ALPHABETIC
Describes alphabetic keys that have exactly two symbols per group.
The default definition of the
ALPHABETIC
type provides shift-cancels-caps behavior as described in
2
in any key symbol map specifies key type
ALPHABETIC
.
KEYPAD
Describes numeric keypad keys with two symbols per group. Yields
column
1
if either of the
Shift
modifier or the real modifier bound to the virtual modifier named
NumLock
are set. Yields column
0
if neither or both modifiers are set. Index
3
in any key symbol map specifies key type
KEYPAD
.
Users or applications may change these key types to get different default
behavior (to make shift cancel caps lock, for example) but they must always
have the specified number of symbols per group.
Before assigning key types to groups, the X server expands any alphanumeric
symbol definitions as follows:
If the second symbol of either group is
NoSymbol
and the first symbol of that group is an alphabetic keysym for which both
lowercase and uppercase forms are defined, the X server treats the key as if
the first element of the group were the lowercase form of the symbol and the
second element were the uppercase form of the symbol. For the purposes of this
expansion, XKB ignores the locale and uses the capitalization rules defined in
For each keyboard group that does not have an explicit type definition, XKB
chooses a key type from the canonical key types. If the second symbol assigned
to a group is
NoSymbol
(after alphabetic expansion), the server assigns key type
ONE_LEVEL
. If the group contains the lowercase and uppercase forms of a single glyph
(after alphanumeric expansion), the server assigns key type
ALPHABETIC
. If either of the symbols in a group is a numeric keypad keysym (
KP_*
), the server assigns key type
KEYPAD
. Otherwise, it assigns key type
TWO_LEVEL
.
Finally, XKB determines the number of groups of symbols that are actually
defined for the key. Trailing empty groups (i.e. groups that have
NoSymbol
in all symbol positions) are ignored.
There are two last special cases for compatibility with the core protocol: If,
after trailing empty groups are excluded, all of the groups of symbols bound to
the key have identical type and symbol bindings, XKB assigns only one group to
the key. If
Group2
is empty and either of
Group3
or
Group4
are not, and if neither
Group1
nor
Group2
have explicit key types, XKB copies the symbols and key type from
Group1
into
Group2
.
Assigning Actions To Keys
Once symbols have been divided into groups and key types chosen for the keys
affected by a
ChangeKeyboardMapping
request, XKB examines the symbols and modifier mapping for each changed key
and assigns server actions where appropriate. XKB also automatically assigns
server actions to changed keys if the client issues a core protocol
SetModifierMapping
request, and does so optionally in response to
XkbSetMap
and
XkbSetCompatMap
requests.
The compatibility map includes a list of
symbol interpretations
, which XKB compares to each symbol associated with any changed keys in turn,
unless the
ExplicitInterp
component is set for a key. Setting the
ExplicitInterp
component prevents the application of symbol interpretations to that key.
If the modifiers and keysym specified in a symbol interpretation match the
modifier mapping and a symbol bound to a changed key that is not protected by
ExplicitInterp
, the server applies the symbol interpretation to the symbol position. The
server considers all symbol interpretations which specify an explicit keysym
before considering any that do not. The server uses the first interpretation
which matches the given combination of keysym and modifier mapping; other
matching interpretations are ignored.
XKB uses four of the fields of a symbol interpretation to decide if it matches
one of the symbols bound to some changed key:
The
symbol
field is a keysym which matches if it has the value
NoSymbol
or is identical to the symbol in question.
The modifiers specified in the
mods
field are compared to the modifiers affected by the key in question as
indicated by
match
.
The
match
field can specify any of the comparisons:
NoneOf
,
AnyOfOrNone
,
AnyOf
,
AllOf
or
Exactly
.
The
levelOneOnly
setting, indicates that the interpretation in question should only use the
modifiers bound to this key by the modifier mapping if the symbol that matches
in level one of its group. Otherwise, if the symbol being considered is not in
shift level one of its group, the server behaves as if the modifier map for the
key were empty. Note that it is still possible for such an interpretation to
apply to a symbol in a shift level other than one if it matches a key without
modifiers; the
levelOneOnly
flag only controls the way that matches are determined and that the key
modifiers are applied when an interpretation does match.
Applying a symbol interpretation can affect several aspects of the XKB
definition of the key symbol mapping to which it is applied:
The
action
specified in the symbol interpretation is bound to the symbol position; any
key event which yields that symbol will also activate the new action.
If the matching symbol is in position G1L1, the autorepeat behavior of
the key is set from the
autorepeat
field of the symbol interpretation. The
ExplicitAutoRepeat
component protects the autorepeat status of a key from symbol interpretation
initiated changes.
If the symbol interpretation specifies an associated virtual modifier,
that virtual modifier is added to the virtual modifier map for the key. The
ExplicitVModMap
component guards the virtual modifier map for a key from automatic changes. If
the
levelOneOnly
flag is set for the interpretation, and the symbol in question is not in
position G1L1, the virtual modifier map is not updated.
If the matching symbol is in position G1L1, and the
locking key
field is set in the symbol interpretation, the behavior of the key is changed
to
KB_Lock
(see
ExplicitBehavior
component prevents this change.
If no interpretations match a given symbol or key, the server uses:
SA_NoAction
, autorepeat enabled, non-locking key. with no virtual modifiers.
If all of the actions computed for a key are
SA_NoAction
, the server assigns an length zero list of actions to the key.
If the core protocol modifier mapping is changed, the server regenerates
actions for the affected keys. The
XkbSetMap
and
XkbSetCompatMap
requests can also cause actions for some or all keyboard keys to be recomputed.
Updating Everything Else
Changes to the symbols or modifier mapping can affect the bindings of virtual
modifiers. If any virtual modifiers change, XKB updates all of its data
structures to reflect the change. Applying virtual modifier changes to the
keyboard mapping night result in changes to types, the group compatibility map,
indicator maps, internal modifiers or ignore locks modifiers.
Effects of XKB on Core Protocol Events
After applying server actions which modify the base, latched or locked modifier
or group state of the keyboard, the X server recomputes the effective group and
state. Several components of the keyboard state are reported to XKB-aware
clients depending on context (see
The effective modifier state is reported in
XkbStateNotify
events and in response to
XkbGetState
requests.
The symbol lookup state is reported to XKB-aware clients in the state
field of core protocol and input extension key press and release events that do
not activate passive grabs. Unless the
LookupStateWhenGrabbed
per-client flag is set, the lookup state is only reported in these events when
no grabs are active.
The grab state is reported to XKB-aware clients in the state field of
all core protocol events that report keyboard state, except
KeyPress
and
KeyRelease
events that do not activate passive grabs.
The effective group is the sum of the base, latched and locked keyboard
groups. An out of range effective group is wrapped or truncated into range
according to the setting of the
groupsWrap
flag for the keyboard.
The server reports compatibility states to any clients that have not issued a
successful
XkbUseExtension
request. The server computes the compatibility symbol lookup state and the
compatibility effective grab state by applying the compatibility modifier map
to the corresponding computed XKB states.
The compatibility symbol lookup state is reported to non-XKB clients whenever
an XKB-aware client would receive the XKB lookup state. The compatibility grab
state is reported to XKB-unaware clients whenever an XKB client would receive
the XKB grab state.
If the
GrabsUseXKBState
per-client option is not set, even XKB-aware clients receive the compatibility
grab state in events that trigger or terminate passive grabs. If this flag is
not set, XKB clients also receive the compatibility grab or lookup state
whenever any keyboard grab is active.
If the
LookupStateWhenGrabbed
per-client option is set, clients receive either the XKB or compatibility
lookup state when the keyboard is grabbed, otherwise they receive either the
XKB or compatibility grab state. All non-XKB clients receive the compatibility
form of the appropriate state component; the form that is sent to an XKB-aware
client depends on the setting of the
GrabsUseXKBState
option for that client.
Effect of XKB on Core Protocol Requests
Whenever a client updates the keyboard mapping using a core protocol request,
the server saves the requested core protocol keyboard mapping and reports it to
any clients that issue
GetKeyboardMapping
or
GetModifierMapping
requests. Whenever a client updates the keyboard mapping using XKB requests,
the server discards the affected portion of the stored core keyboard
description and regenerates it based on the XKB description of the keyboard.
The symbols associated with the XKB keyboard description appear in the order:
G1L1 G1L2 G2L1 G2L2 G1L3-n G2L3-n G3L* G4L*
If the type associated with
Group1
is width one, the second symbol is
NoSymbol
; if the type associated with
Group2
is width one, the fourth symbol is
NoSymbol
.
If a key has only one group but the keyboard has several, the symbols for
Group1
are repeated for each group. For example, given a keyboard with three groups
and a key with one group that contains the symbols {
a A
}, the core protocol description would contain the six symbols: {
a
A
a
A
a
A
}. As a slightly more complicated example, an XKB key which had a single width
three group with the symbols {
a
b
c
} would show up in the generated core protocol keyboard description with the
symbols {
a
b
a
b
c
c
a
b
c
} for a keyboard with three groups.
The generated modifier mapping for a key contains all of the modifiers affected
by all of the actions associated with the key plus all of the modifiers
associated with any virtual modifiers bound to the key by the virtual modifier
mapping. If any of the actions associated with a key affect any component of
the keyboard group, any modifiers specified in any entry of the group
compatibility map (see
SA_ISOLock
action can theoretically affect any modifier, but the modifier map of an
SA_ISOLock
key contains only the modifiers or group state that it sets by default.
The server notifies interested clients of keyboard map changes in one of two
ways. It sends
XkbMapNotify
to clients that have explicitly selected them and core protocol
MappingNotify
events to clients that have not. Once a client requests
XkbMapNotify
events, the server stops sending it
MappingNotify
events to inform it of keyboard changes.
Sending Events to Clients
XKB normally assumes that events sent to clients using the core protocol
SendEvent
request contain a core protocol state, if applicable. If the client which will
receive the event is not XKB-capable, XKB attempts to convert the core state to
an XKB state as follows: if any of the modifiers bound to
Group2
in the group compatibility map are set in the event state, XKB clears them in
the resulting event but sets the effective group in the event state to
Group2
.
If the
PCF_SendEventUsesXKBState
per-client flag is set at the time of the SendEvent request, XKB instead
assumes that the event reported in the event is an XKB state. If the receiving
client is not XKB-aware, the extension converts the XKB state (which contains
the effective state in bits 13-14) to a core state by applying the group
compatibility map just as it would for actual key events.
xorgproto-2023.2/specs/kbproto/appD.xml 0000644 0001750 0001750 00000203167 14443010026 014774 0000000 0000000
Protocol Encoding
Syntactic Conventions
This document uses the same syntactic conventions as the encoding of the core X
protocol, with the following additions:
A LISTofITEMs contains zero or more items of variable type and size. The encode
form for a LISTofITEMs is:
v LISTofITEMs NAME
TYPE MASK-EXPRESSION
value1 corresponding field(s)
...
valuen corresponding field(s)
The MASK-EXPRESSION is an expression using C-style boolean operators and fields
of the request which specifies the bitmask used to determine whether or not a
member of the LISTofITEMs is present. If present, TYPE specifies the
interpretation of the resulting bitmask and the values are listed using the
symbolic names of the members of the set. If TYPE is blank, the values are
numeric constants.
It is possible for a single bit in the MASK-EXPRESSION to control more than one
ITEM — if the bit is set, all listed ITEMs are present. It is also possible
for multiple bits in the MASK-EXPRESSION to control a single ITEM — if any of
the bits associated with an ITEM are set, it is present in the LISTofITEMs.
The size of a LISTofITEMS is derived from the items that are present in the
list, so it is always given as a variable in the request description, and the
request is followed by a section of the form:
ITEMs
encode-form
...
encode-form
listing an encode-form for each ITEM. The NAME in each encode-form keys to the
fields listed as corresponding to each bit in the MASK-EXPRESSION. Items are
not necessarily the same size, and the size specified in the encoding form is
the size that the item occupies if it is present.
Some types are of variable size. The encode-form for a list of items of a
single type but variable size is:
S0+..Ss LISTofTYPE name
Which indicates that the list has
s
elements of variable size and that the size of the list is the sum of the
sizes of all of the elements that make up the list. The notation Sn refers to
the size of the
n
th element of the list and the notation S* refers to the size of the list as a
whole.
The definition of a type of variable size includes an expression which
specifies the size. The size is specified as a constant plus a variable
expression; the constant specifies the size of the fields that are always
present and the variables which make up the variable expression are defined in
the constant portion of the structure. For example, the following definition
specifies a counted string with a two-byte length field preceding the string:
TYPE 2+n+p
2 n length
n STRING8 string
p unused,p=pad(n)
Some fields are optional. The size of an optional field has the form:
"[
expr
]" where expr specifies the size of the field if it is present. An explanation
of the conditions under which the field is present follows the name in the
encode form:
1 BOOL more
3 unused
[4] CARD32 optData, if more==TRUE
This portion of the structure is four bytes long if more is FALSE or eight
bytes long if more is TRUE. This notation can also be used in size expressions;
for example, the size of the previous structure is written as "4+[4]" bytes.
Common Types
SETofKB_EVENTTYPE
#x0001 XkbNewKeyboardNotify
#x0002 XkbMapNotify
#x0004 XkbStateNotify
#x0008 XkbControlsNotify
#x0010 XkbIndicatorStateNotify
#x0020 XkbIndicatorMapNotify
#x0040 XkbNamesNotify
#x0080 XkbCompatMapNotify
#x0100 XkbBellNotify
#x0200 XkbActionMessage
#x0400 XkbAccessXNotify
#x0800 XkbExtensionDeviceNotify
SETofKB_NKNDETAIL
#x01 XkbNKN_Keycodes
#x02 XkbNKN_Geometry
#x04 XkbNKN_DeviceID
SETofKB_AXNDETAIL
#x01 XkbAXN_SKPress
#x02 XkbAXN_SKAccept
#x04 XkbAXN_SKReject
#x08 XkbAXN_SKRelease
#x10 XkbAXN_BKAccept
#x20 XkbAXN_BKReject
#x40 XkbAXN_AXKWarning
SETofKB_MAPPART
#x0001 XkbKeyTypes
#x0002 XkbKeySyms
#x0004 XkbModifierMap
#x0008 XkbExplicitComponents
#x0010 XkbKeyActions
#x0020 XkbKeyBehaviors
#x0040 XkbVirtualMods
#x0080 XkbVirtualModMap
SETofKB_STATEPART
#x0001 XkbModifierState
#x0002 XkbModifierBase
#x0004 XkbModifierLatch
#x0008 XkbModifierLock
#x0010 XkbGroupState
#x0020 XkbGroupBase
#x0040 XkbGroupLatch
#x0080 XkbGroupLock
#x0100 XkbCompatState
#x0200 XkbGrabMods
#x0400 XkbCompatGrabMods
#x0800 XkbLookupMods
#x1000 XkbCompatLookupMods
#x2000 XkbPointerButtons
SETofKB_BOOLCTRL
#x00000001 XkbRepeatKeys
#x00000002 XkbSlowKeys
#x00000004 XkbBounceKeys
#x00000008 XkbStickyKeys
#x00000010 XkbMouseKeys
#x00000020 XkbMouseKeysAccel
#x00000040 XkbAccessXKeys
#x00000080 XkbAccessXTimeoutMask
#x00000100 XkbAccessXFeedbackMask
#x00000200 XkbAudibleBellMask
#x00000400 XkbOverlay1Mask
#x00000800 XkbOverlay2Mask
#x00001000 XkbIgnoreGroupLockMask
SETofKB_CONTROL
Encodings are the same as for SETofKB_BOOLCTRL, with the addition of:
#x080000000 XkbGroupsWrap
#x100000000 XkbInternalMods
#x200000000 XkbIgnoreLockMods
#x400000000 XkbPerKeyRepeat
#x800000000 XkbControlsEnabled
SETofKB_AXFBOPT
#x0001 XkbAX_SKPressFB
#x0002 XkbAX_SKAcceptFB
#x0004 XkbAX_FeatureFB
#x0008 XkbAX_SlowWarnFB
#x0010 XkbAX_IndicatorFB
#x0020 XkbAX_StickyKeysFB
#x0100 XkbAX_SKReleaseFB
#x0200 XkbAX_SKRejectFB
#x0400 XkbAX_BKRejectFB
#x0800 XkbAX_DumbBell
SETofKB_AXSKOPT
#x0040 XkbAX_TwoKeys
#x0080 XkbAX_LatchToLock
SETofKB_AXOPTION
Encoding same as the bitwise union of :
SETofKB_AXFBOPT
SETofKB_AXSKOPT
KB_DEVICESPEC
0..255 input extension device id
#x100 XkbUseCoreKbd
#x200 XkbUseCorePtr
KB_LEDCLASSRESULT
0 KbdFeedbackClass
4 LedFeedbackClass
KB_LEDCLASSSPEC
Encoding same as KB_LEDCLASSRESULT, with the addition of:
#x0300 XkbDfltXIClass
#x0500 XkbAllXIClasses
KB_BELLCLASSRESULT
0 KbdFeedbackClass
5 BellFeedbackClass
KB_BELLCLASSSPEC
Encoding same as KB_BELLCLASSRESULT, with the addition of:
#x0300 XkbDfltXIClass
KB_IDSPEC
0..255 input extension feedback id
#x0400 XkbDfltXIId
KB_IDRESULT
Encoding same as KB_IDSPEC, with the addition of:
#xff00 XkbXINone
KB_MULTIIDSPEC
encodings same as KB_IDSPEC, with the addition of:
#x0500 XkbAllXIIds
KB_GROUP
0 XkbGroup1
1 XkbGroup2
2 XkbGroup3
3 XkbGroup4
KB_GROUPS
Encoding same as KB_GROUP, with the addition of:
254 XkbAnyGroup
255 XkbAllGroups
SETofKB_GROUP
#x01 XkbGroup1
#x02 XkbGroup2
#x04 XkbGroup3
#x08 XkbGroup4
SETofKB_GROUPS
Encoding same as SETofKB_GROUP, with the addition of:
#x80 XkbAnyGroup
KB_GROUPSWRAP
#x00 XkbWrapIntoRange
#x40 XkbClampIntoRange
#x80 XkbRedirectIntoRange
SETofKB_VMODSHIGH
#x80 virtual modifier 15
#x40 virtual modifier 14
#x20 virtual modifier 13
#x10 virtual modifier 12
#x08 virtual modifier 11
#x04 virtual modifier 10
#x02 virtual modifier 9
#x01 virtual modifier 8
SETofKB_VMODSLOW
#x80 virtual modifier 7
#x40 virtual modifier 6
#x20 virtual modifier 5
#x10 virtual modifier 4
#x08 virtual modifier 3
#x04 virtual modifier 2
#x02 virtual modifier 1
#x01 virtual modifier 0
SETofKB_VMOD
#x8000 virtual modifier 15
#x4000 virtual modifier 14
#x2000 virtual modifier 13
#x1000 virtual modifier 12
#x0800 virtual modifier 11
#x0400 virtual modifier 10
#x0200 virtual modifier 9
#x0100 virtual modifier 8
#x0080 virtual modifier 7
#x0040 virtual modifier 6
#x0020 virtual modifier 5
#x0010 virtual modifier 4
#x0008 virtual modifier 3
#x0004 virtual modifier 2
#x0002 virtual modifier 1
#x0001 virtual modifier 0
SETofKB_EXPLICIT
#x80 XkbExplicitVModMap
#x40 XkbExplicitBehavior
#x20 XkbExplicitAutoRepeat
#x10 XkbExplicitInterpret
#x08 XkbExplicitKeyType4
#x04 XkbExplicitKeyType3
#x02 XkbExplicitKeyType2
#x01 XkbExplicitKeyType1
KB_SYMINTERPMATCH
#x80 XkbSI_LevelOneOnly
#x7f operation, one of the following:
0 XkbSI_NoneOf
1 XkbSI_AnyOfOrNone
2 XkbSI_AnyOf
3 XkbSI_AllOf
4 XkbSI_Exactly
SETofKB_IMFLAG
#x80 XkbIM_NoExplicit
#x40 XkbIM_NoAutomatic
#x20 XkbIM_LEDDrivesKB
SETofKB_IMMODSWHICH
#x10 XkbIM_UseCompat
#x08 XkbIM_UseEffective
#x04 XkbIM_UseLocked
#x02 XkbIM_UseLatched
#x01 XkbIM_UseBase
SETofKB_IMGROUPSWHICH
#x10 XkbIM_UseCompat
#x08 XkbIM_UseEffective
#x04 XkbIM_UseLocked
#x02 XkbIM_UseLatched
#x01 XkbIM_UseBase
KB_INDICATORMAP
1 SETofKB_IMFLAGS flags
1 SETofKB_IMGROUPSWHICH whichGroups
1 SETofKB_GROUP groups
1 SETofKB_IMMODSWHICH whichMods
1 SETofKEYMASK mods
1 SETofKEYMASK realMods
2 SETofKB_VMOD vmods
4 SETofKB_BOOLCTRL ctrls
SETofKB_CMDETAIL
#x01 XkbSymInterp
#x02 XkbGroupCompat
SETofKB_NAMEDETAIL
#x0001 XkbKeycodesName
#x0002 XkbGeometryName
#x0004 XkbSymbolsName
#x0008 XkbPhysSymbolsName
#x0010 XkbTypesName
#x0020 XkbCompatName
#x0040 XkbKeyTypeNames
#x0080 XkbKTLevelNames
#x0100 XkbIndicatorNames
#x0200 XkbKeyNames
#x0400 XkbKeyAliases
#x0800 XkbVirtualModNames
#x1000 XkbGroupNames
#x2000 XkbRGNames
SETofKB_GBNDETAIL
#x01 XkbGBN_Types
#x02 XkbGBN_CompatMap
#x04 XkbGBN_ClientSymbols
#x08 XkbGBN_ServerSymbols
#x10 XkbGBN_IndicatorMaps
#x20 XkbGBN_KeyNames
#x40 XkbGBN_Geometry
#x80 XkbGBN_OtherNames
SETofKB_XIEXTDEVFEATURE
#x02 XkbXI_ButtonActions
#x04 XkbXI_IndicatorNames
#x08 XkbXI_IndicatorMaps
#x10 XkbXI_IndicatorState
SETofKB_XIFEATURE
Encoding same as SETofKB_XIEXTDEVFEATURE, with the addition of:
#x01 XkbXI_Keyboards
SETofKB_XIDETAIL
Encoding same as SETofKB_XIFEATURE, with the addition of:
#x8000 XkbXI_UnsupportedFeature
SETofKB_PERCLIENTFLAG
#x01 XkbDetectableAutorepeat
#x02 XkbGrabsUseXKBState
#x04 XkbAutoResetControls
#x08 XkbLookupStateWhenGrabbed
#x10 XkbSendEventUsesXKBState
KB_MODDEF
1 SETofKEYMASK mask
1 SETofKEYMASK realMods
2 SETofVMOD vmods
KB_COUNTED_STRING8
1 l length
l STRING8 string
KB_COUNTED_STRING16
2 l length
l STRING8 string
KB_COUNTED_STRING16
p unused,p=pad(2+l)
Errors
1 0 Error
2 ?? code
2 CARD16 sequence
4 CARD32 error value
most significant 8 bits of error value have the meaning:
0xff XkbErrBadDevice
0xfe XkbErrBadClass
0xfd XkbErrBadId
the least significant 8 bits of the error value contain the device id,
class, or feedback
id which failed.
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Key Actions
1 0 type
7 unused
1 1 type
1 BITMASK flags
#x01 XkbSA_ClearLocks
#x02 XkbSA_LatchToLock
#x04 XkbSA_UseModMapMods
1 SETofKEYMASK mask
1 SETofKEYMASK real modifiers
1 SETofKB_VMODSHIGH virtual modifiers high
1 SETofKB_VMODSLOW virtual modifiers low
2 unused
1 2 type
1 BITMASK flags
#x01 XkbSA_ClearLocks
#x02 XkbSA_LatchToLock
#x04 XkbSA_UseModMapMods
1 SETofKEYMASK mask
1 SETofKEYMASK real modifiers
1 SETofKB_VMODSHIGH virtual modifiers high
1 SETofKB_VMODSLOW virtual modifiers low
2 unused
1 3 type
1 BITMASK flags
#x01 XkbSA_LockNoLock
#x02 XkbSA_LockNoUnlock
#x04 XkbSA_UseModMapMods
1 SETofKEYMASK mask
1 SETofKEYMASK real modifiers
1 SETofKB_VMODSHIGH virtual modifiers high
1 SETofKB_VMODSLOW virtual modifiers low
2 unused
1 4 type
1 BITMASK flags
#x01 XkbSA_ClearLocks
#x02 XkbSA_LatchToLock
#x04 XkbSA_GroupAbsolute
1 INT8 group
5 unused
1 5 type
1 BITMASK flags
#x01 XkbSA_ClearLocks
#x02 XkbSA_LatchToLock
#x04 XkbSA_GroupAbsolute
1 INT8 group
5 unused
1 6 type
1 BITMASK flags
#x01 XkbSA_LockNoLock
#x02 XkbSA_LockNoUnlock
#x04 XkbSA_GroupAbsolute
1 INT8 group
5 unused
1 7 type
1 BITMASK flags
#x01 XkbSA_NoAcceleration
#x02 XkbSA_MoveAbsoluteX
#x04 XkbSA_MoveAbsoluteY
1 INT8 x high
1 CARD8 x low
1 INT8 y high
1 CARD8 y low
2 unused
1 8 type
1 BITMASK flags
1 CARD8 count
1 CARD8 button
4 unused
1 9 type
1 BITMASK flags
1 unused
1 CARD8 button
4 unused
1 10 type
1 BITMASK flags
#x04 XkbSA_DfltBtnAbsolute
1 BITMASK affect
#x01 XkbSA_AffectDfltBtn
1 INT8 value
4 unused
1 11 type
1 BITMASK flags
#x01 XkbSA_LockNoLock
#x02 XkbSA_LockNoUnlock
#x04 XkbSA_UseModMapMods (if SA_ISODfltIsGroup is 0)
#x04 XkbSA_GroupAbsolute (if SA_ISODfltIsGroup is 1)
#x80 XkbSA_ISODfltIsGroup
1 SETofKEYMASK mask
1 SETofKEYMASK real modifiers
1 INT8 group
1 BITMASK affect
#x08 XkbSA_ISONoAffectCtrls
#x10 XkbSA_ISONoAffectPtr
#x20 XkbSA_ISONoAffectGroup
#x40 XkbSA_ISONoAffectMods
1 SETofKB_VMODSHIGH virtual modifiers high
1 SETofKB_VMODSLOW virtual modifiers low
1 12 type
7 unused
1 13 type
1 BITMASK flags
#x01 XkbSA_SwitchApplication
#x04 XkbSA_SwitchAbsolute
1 INT8 new screen
5 unused (must be 0)
1 14 type
3 unused (must be 0)
1 BITMASK boolean controls high
#x01 XkbAccessXFeedbackMask
#x02 XkbAudibleBellMask
#x04 XkbOverlay1Mask
#x08 XkbOverlay2Mask
#x10 XkbIgnoreGroupLockMask
1 BITMASK boolean controls low
#x01 XkbRepeatKeys
#x02 XkbSlowKeys
#x04 XkbBounceKeys
#x08 XkbStickyKeys
#x10 XkbMouseKeys
#x20 XkbMouseKeysAccel
#x40 XkbAccessXKeys
#x80 XkbAccessXTimeoutMask
2 unused (must be 0)
1 15 type
3 unused (must be 0)
1 BITMASK boolean controls high
#x01 XkbAccessXFeedbackMask
#x02 XkbAudibleBellMask
#x04 XkbOverlay1Mask
#x08 XkbOverlay2Mask
#x10 XkbIgnoreGroupLockMask
1 BITMASK boolean controls low
#x01 XkbRepeatKeys
#x02 XkbSlowKeys
#x04 XkbBounceKeys
#x08 XkbStickyKeys
#x10 XkbMouseKeys
#x20 XkbMouseKeysAccel
#x40 XkbAccessXKeys
#x80 XkbAccessXTimeoutMask
1 16 type
2 unused (must be 0)
1 16 type
1 BITMASK flags
#x01 XkbSA_MessageOnPress
#x02 XkbSA_MessageOnRelease
#x04 XkbSA_MessageGenKeyEvent
6 STRING message
1 17 type
1 KEYCODE new key
1 SETofKEYMASK mask
1 SETofKEYMASK real modifiers
1 SETofKB_VMODSHIGH virtual modifiers mask high
1 SETofKB_VMODSLOW virtual modifiers mask low
1 SETofKB_VMODSHIGH virtual modifiers high
1 SETofKB_VMODSLOW virtual modifiers low
1 18 type
1 0 flags
1 CARD8 count
1 CARD8 button
1 CARD8 device
3 unused (must be 0)
1 19 type
1 BITMASK flags
#x01 XkbSA_LockNoLock
#x02 XkbSA_LockNoUnlock
1 unused
1 CARD8 button
1 CARD8 device
1 20 type
1 CARD8 device
1 KB_SA_VALWHAT valuator 1 what
#x00 XkbSA_IgnoreVal
#x01 XkbSA_SetValMin
#x02 XkbSA_SetValCenter
#x03 XkbSA_SetValMax
#x04 XkbSA_SetValRelative
#x05 XkbSA_SetValAbsolute
1 CARD8 valuator 1 index
1 CARD8 valuator 1 value
1 KB_SA_VALWHAT valuator 2 what
Encodings as for "valuator 1 what" above
1 CARD8 valuator 2 index
1 CARD8 valuator 2 value
Key Behaviors
1 #x00 type
1 unused
1 #x01 type
1 unused
1 #x02 type
1 0..31 group
1 #x03 type
1 KEYCODE key
1 #x04 type
1 CARD8 key
1 #x81 type
1 unused
1 #x82 type
1 0..31 group
1 #x83 type
1 KEYCODE key
1 #x84 type
1 KEYCODE key
Requests
1 ?? opcode
1 0 xkb-opcode
2 2 request-length
2 CARD16 wantedMajor
2 CARD16 wantedMinor
1 1 Reply
1 BOOL supported
2 CARD16 sequence number
4 0 reply length
2 1 serverMajor
2 0 serverMinor
20 unused
1 ?? opcode
1 1 xkb-opcode
2 4+(V+p)/4 request-length
2 KB_DEVICESPEC deviceSpec
2 SETofKB_EVENTTYPE affectWhich
2 SETofKB_EVENTTYPE clear
2 SETofKB_EVENTTYPE selectAll
2 SETofKB_MAPDETAILS affectMap
2 SETofKB_MAPDETAILS map
V LISTofITEMs details
SETofKB_EVENTTYPE
(affectWhich&(~clear)&(~selectAll))
XkbNewKeyboardNotify affectNewKeyboard, newKeyboardDetails
XkbStateNotify affectState, stateDetails
XkbControlsNotify affectCtrls, ctrlDetails
XkbIndicatorStateNotify affectIndicatorState, indicatorStateDetails
XkbIndicatorMapNotify affectIndicatorMap, indicatorMapDetails
XkbNamesNotify affectNames, namesDetails
XkbCompatMapNotify affectCompat, compatDetails
XkbBellNotify affectBell, bellDetails
XkbActionMessage affectMsgDetails, msgDetails
XkbExtensionDeviceNotify affectExtDev, extdevDetails
ITEMs
p unused, p=pad(V)
ITEMs
2 SETofKB_NKNDETAIL affectNewKeyboard
2 SETofKB_NKNDETAIL newKeyboardDetails
2 SETofKB_STATEPART affectState
2 SETofKB_STATEPART stateDetails
4 SETofKB_CONTROL affectCtrls
4 SETofKB_CONTROL ctrlDetails
4 SETofKB_INDICATOR affectIndicatorState
4 SETofKB_INDICATOR indicatorStateDetails
4 SETofKB_INDICATOR affectIndicatorMaps
4 SETofKB_INDICATOR indicatorMapDetails
2 SETofKB_NAME_DETAIL affectNames
2 SETofKB_NAME_DETAIL namesDetails
1 SETofKB_CMDETAIL affectCompat
1 SETofKB_CMDETAIL compatDetails
1 SETofKB_BELLDETAIL affectBell
1 SETofKB_BELLDETAIL bellDetails
1 SETofKB_MSGDETAIL affectMsgDetails
1 SETofKB_MSGDETAIL msgDetails
2 SETofKB_AXNDETAIL affectAccessX
2 SETofKB_AXNDETAIL accessXDetails
2 SETofKB_XIDETAIL affectExtDev
2 SETofKB_XIDETAIL extdevDetails
1 ?? opcode
1 3 xkb-opcode
2 7 request-length
2 KB_DEVICESPEC deviceSpec
2 KB_BELLCLASSSPEC bellClass
2 KB_IDSPEC bellID
1 INT8 percent
1 BOOL forceSound
1 BOOL eventOnly
1 unused
2 INT16 pitch
2 INT16 duration
2 unused
4 ATOM name
4 WINDOW window
1 ?? opcode
1 4 xkb-opcode
2 2 request-length
2 KB_DEVICESPEC deviceSpec
2 unused
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 0 length
1 SETofKEYMASK mods
1 SETofKEYMASK baseMods
1 SETofKEYMASK latchedMods
1 SETofKEYMASK lockedMods
1 KP_GROUP group
1 KP_GROUP lockedGroup
2 INT16 baseGroup
2 INT16 latchedGroup
1 SETofKEYMASK compatState
1 SETofKEYMASK grabMods
1 SETofKEYMASK compatGrabMods
1 SETofKEYMASK lookupMods
1 SETofKEYMASK compatLookupMods
1 unused
2 SETofBUTMASK ptrBtnState
6 unused
1 ?? opcode
1 5 xkb-opcode
2 4 request-length
2 KB_DEVICESPEC deviceSpec
1 SETofKEYMASK affectModLocks
1 SETofKEYMASK modLocks
1 BOOL lockGroup
1 KB_GROUP groupLock
1 SETofKEYMASK affectModLatches
1 SETofKEYMASK modLatches
1 unused
1 BOOL latchGroup
2 INT16 groupLatch
1 ?? opcode
1 6 xkb-opcode
2 2 request-length
2 KB_DEVICESPEC deviceSpec
2 unused
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 15 length
1 CARD8 mouseKeysDfltBtn
1 CARD8 numGroups
1 CARD8 groupsWrap
1 SETofKEYMASK internalMods.mask
1 SETofKEYMASK ignoreLockMods.mask
1 SETofKEYMASK internalMods.realMods
1 SETofKEYMASK ignoreLockMods.realMods
1 unused
2 SETofKB_VMOD internalMods.vmods
2 SETofKB_VMOD ignoreLockMods.vmods
2 CARD16 repeatDelay
2 CARD16 repeatInterval
2 CARD16 slowKeysDelay
2 CARD16 debounceDelay
2 CARD16 mouseKeysDelay
2 CARD16 mouseKeysInterval
2 CARD16 mouseKeysTimeToMax
2 CARD16 mouseKeysMaxSpeed
2 INT16 mouseKeysCurve
2 SETofKB_AXOPTION accessXOptions
2 CARD16 accessXTimeout
2 SETofKB_AXOPTION accessXTimeoutOptionsMask
2 SETofKB_AXOPTION accessXTimeoutOptionValues
2 unused
4 SETofKB_BOOLCTRL accessXTimeoutMask
4 SETofKB_BOOLCTRL accessXTimeoutValues
4 SETofKB_BOOLCTRL enabledControls
32 LISTofCARD8 perKeyRepeat
1 ?? opcode
1 7 xkb-opcode
2 25 request-length
2 KB_DEVICESPEC deviceSpec
1 SETofKEYMASK affectInternalRealMods
1 SETofKEYMASK internalRealMods
1 SETofKEYMASK affectIgnoreLockRealMods
1 SETofKEYMASK ignoreLockRealMods
2 SETofKB_VMOD affectInternalVirtualMods
2 SETofKB_VMOD internalVirtualMods
2 SETofKB_VMOD affectIgnoreLockVirtualMods
2 SETofKB_VMOD ignoreLockVirtualMods
1 CARD8 mouseKeysDfltBtn
1 CARD8 groupsWrap
2 SETofKB_AXOPTION accessXOptions
2 unused
4 SETofKB_BOOLCTRL affectEnabledControls
4 SETofKB_BOOLCTRL enabledControls
4 SETofKB_CONTROL changeControls
2 CARD16 repeatDelay
2 CARD16 repeatInterval
2 CARD16 slowKeysDelay
2 CARD16 debounceDelay
2 CARD16 mouseKeysDelay
2 CARD16 mouseKeysInterval
2 CARD16 mouseKeysTimeToMax
2 CARD16 mouseKeysMaxSpeed
2 INT16 mouseKeysCurve
2 CARD16 accessXTimeout
4 SETofKB_BOOLCTRL accessXTimeoutMask
4 SETofKB_BOOLCTRL accessXTimeoutValues
2 SETofKB_AXOPTION accessXTimeoutOptionsMask
2 SETofKB_AXOPTION accessXTimeoutOptionsValues
32 LISTofCARD8 perKeyRepeat
1 CARD8 opcode
1 8 xkb-opcode
2 7 request-length
2 KB_DEVICESPEC deviceSpec
2 SETofKB_MAPPART full
2 SETofKB_MAPPART partial
1 CARD8 firstType
1 CARD8 nTypes
1 KEYCODE firstKeySym
1 CARD8 nKeySyms
1 KEYCODE firstKeyAction
1 CARD8 nKeyActions
1 KEYCODE firstKeyBehavior
1 CARD8 nKeyBehaviors
2 SETofKB_VMOD virtualMods
1 KEYCODE firstKeyExplicit
1 CARD8 nKeyExplicit
1 KEYCODE firstModMapKey
1 CARD8 nModMapKeys
1 KEYCODE firstVModMapKey
1 CARD8 nVModMapKeys
2 unused
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 2+(I/4) length
2 unused
1 KEYCODE minKeyCode
1 KEYCODE maxKeyCode
2 SETofKB_MAPPART present
1 CARD8 firstType
1 t nTypes
1 CARD8 totalTypes
1 KEYCODE firstKeySym
2 S totalSyms
1 s nKeySyms
1 KEYCODE firstKeyAction
2 A totalActions
1 a nKeyActions
1 KEYCODE firstKeyBehavior
1 b nKeyBehaviors
1 B totalKeyBehaviors
1 KEYCODE firstKeyExplicit
1 e nKeyExplicit
1 E totalKeyExplicit
1 KEYCODE firstModMapKey
1 m nModMapKeys
1 M totalModMapKeys
1 KEYCODE firstVModMapKey
1 0 nVModMapKeys
1 V totalVModMapKeys
1 unused
2 SETofKB_VMOD virtualMods (has v bits set to 1)
I LISTofITEMs map
SETofKB_MAPPART (present)
XkbKeyTypes typesRtrn
XkbKeySyms symsRtrn
XkbKeyActions actsRtrn.count, actsRtrn.acts
XkbKeyBehaviors behaviorsRtrn
XkbVirtualMods vmodsRtrn
XkbExplicitComponents explicitRtrn
XkbModifierMap modmapRtrn
XkbVirtualModMap vmodMapRtrn
ITEMs
T1+..Tt LISTofKB_KEYTYPE typesRtrn
8s+4S LISTofKB_KEYSYMMAP symsRtrn
a LISTofCARD8 actsRtrn.count
p unused,p=pad(a)
8A LISTofKB_ACTION actsRtrn.acts
4B LISTofKB_SETBEHAVIOR behaviorsRtrn
v LISTofSETofKEYMASK vmodsRtrn
p unused, p=pad(v)
2E LISTofKB_SETEXPLICIT explicitRtrn
p unused,p=pad(2E)
2M LISTofKB_KEYMODMAP modmapRtrn
p unused, p=pad(2M)
4V LISTofKB_KEYVMODMAP vmodMapRtrn
KB_KEYTYPE 8+8m+[4m]
1 SETofKEYMASK mods.mask
1 SETofKEYMASK mods.mods
2 SETofKB_VMOD mods.vmods
1 CARD8 numLevels
1 m nMapEntries
1 BOOL hasPreserve
1 unused
8m LISTofKB_KTMAPENTRY map
[4m] LISTofKB_MODDEF preserve
KB_KTMAPENTRY
1 BOOL active
1 SETofKEYMASK mods.mask
1 CARD8 level
1 SETofKEYMASK mods.mods
2 SETofKB_VMOD mods.vmods
2 unused
KB_KEYSYMMAP 8+4n
4 LISTofCARD8 ktIndex
1 CARD8 groupInfo
1 CARD8 width
2 n nSyms
4n LISTofKEYSYM syms
KB_SETBEHAVIOR
1 KEYCODE keycode
2 KB_BEHAVIOR behavior
1 unused
KB_SETEXPLICIT
1 KEYCODE keycode
1 SETofKB_EXPLICIT explicit
KB_KEYMODMAP
1 KEYCODE keycode
1 SETofKB_KEYMASK mods
KB_KEYVMODMAP
1 KEYCODE keycode
1 unused
2 SETofKB_VMOD vmods
1 CARD8 opcode
1 9 xkb-opcode
2 9+(I/4) request-length
2 KB_DEVICESPEC deviceSpec
2 SETofKB_MAPPART present
2 SETofKB_SETMAPFLAGS flags
#0001 SetMapResizeTypes
#0002 SetMapRecomputeActions
1 KEYCODE minKeyCode
1 KEYCODE maxKeyCode
1 CARD8 firstType
1 t nTypes
1 KEYCODE firstKeySym
1 s nKeySyms
2 S totalSyms
1 KEYCODE firstKeyAction
1 a nKeyActions
2 A totalActions
1 KEYCODE firstKeyBehavior
1 b nKeyBehaviors
1 B totalKeyBehaviors
1 KEYCODE firstKeyExplicit
1 e nKeyExplicit
1 E totalKeyExplicit
1 KEYCODE firstModMapKey
1 m nModMapKeys
1 M totalModMapKeys
1 KEYCODE firstVModMapKey
1 v nVModMapKeys
1 V totalVModMapKeys
2 SETofKB_VMOD virtualMods (has n bits set to 1)
I LISTofITEMs values
SETofKB_MAPPART (present)
XkbKeyTypes types
XkbKeySymbols syms
XkbKeyActions actions.count,actions.actions
XkbKeyBehaviors behaviors
XkbVirtualMods vmods
XkbExplicitComponents explicit
XkbModifierMap modmap
XkbVirtualModMap vmodmap
ITEMs
T0+..Tt LISTofKB_SETKEYTYPE types
8s+4S LISTofKB_KEYSYMMAP syms
a LISTofCARD8 actions.count
p unused,p=pad(a)
8A LISTofKB_ACTION actions.actions
4B LISTofKB_SETBEHAVIOR behaviors
v LISTofSETofKEYMASK vmods
p unused, p=pad(v)
2E LISTofKB_SETEXPLICIT explicit
p unused,p=pad(2E)
2M LISTofKB_KEYMODMAP modmap
P unused, p=pad(2M)
4V LISTofKB_KEYVMODMAP vmodmap
KB_SETKEYTYPE 8+4m+[4m]
1 SETofKEYMASK mask
1 SETofKEYMASK realMods
2 SETofKB_VMOD virtualMods
1 CARD8 numLevels
1 m nMapEntries
1 BOOL preserve
1 unused
4m LISTofKB_KTSETMAPENTRY entries
[4m] LISTofKB_MODDEF preserveEntries (if preserve==TRUE)
KB_KTSETMAPENTRY
1 CARD8 level
1 SETofKEYMASK realMods
2 SETofKB_VMOD virtualMods
1 ?? opcode
1 10 xkb-opcode
2 3 request-length
2 KB_DEVICESPEC deviceSpec
1 SETofKB_GROUP groups
1 BOOL getAllSI
2 CARD16 firstSI
2 CARD16 nSI
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 (16n+4g)/4 length
1 SETofKB_GROUP groupsRtrn (has g bits set to 1)
1 unused
2 CARD16 firstSIRtrn
2 n nSIRtrn
2 CARD16 nTotalSI
16 unused
16n LISTofKB_SYMINTERPRET siRtrn
4g LISTofKB_MODDEF groupRtrn
1 ?? opcode
1 11 xkb-opcode
2 4+(16n+4g) request-length
2 KB_DEVICESPEC deviceSpec
1 unused
1 BOOL recomputeActions
1 BOOL truncateSI
1 SETofKB_GROUP groups (has g bits set to 1)
2 CARD16 firstSI
2 n nSI
2 unused
16n LISTofKB_SYMINTERPRET si
4g LISTofKB_MODDEF groupMaps
1 ?? opcode
1 12 xkb-opcode
2 2 request-length
2 KB_DEVICESPEC deviceSpec
ITEMs
2 unused
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 0 length
4 SETofKB_INDICATOR state
20 unused
1 ?? opcode
1 13 xkb-opcode
2 3 request-length
2 KB_DEVICESPEC deviceSpec
2 unused
4 SETofKB_INDICATOR which
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 12n/4 length
4 SETofKB_INDICATOR which (has n bits set to 1)
4 SETofKB_INDICATOR realIndicators
1 n nIndicators
15 unused
12n LISTofKB_INDICATORMAP maps
1 ?? opcode
1 14 xkb-opcode
2 3+3n request-length
2 KB_DEVICESPEC deviceSpec
2 unused
4 SETofKB_INDICATOR which (has n bits set to 1)
12n LISTofKB_INDICATORMAP maps
1 CARD8 opcode
1 15 xkb-opcode
2 4 request-length
2 KB_DEVICESPEC deviceSpec
2 KB_LEDCLASSSPEC ledClass
2 KB_IDSPEC ledID
2 unused
4 ATOM indicator
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 0 length
4 ATOM indicator
1 BOOL found
1 BOOL on
1 BOOL realIndicator
1 KB_INDICATOR ndx
1 SETofKB_IMFLAGS map.flags
1 SETofKB_IMGROUPSWHICH map.whichGroups
1 SETofKB_GROUPS map.groups
1 SETofKB_IMMODSWHICH map.whichMods
1 SETofKEYMASK map.mods
1 SETofKEYMASK map.realMods
2 SETofKB_VMOD map.vmods
4 SETofKB_BOOLCTRL map.ctrls
1 BOOL supported
3 unused
1 ?? opcode
1 16 xkb-opcode
2 8 request-length
2 KB_DEVICESPEC deviceSpec
2 KB_LEDCLASSSPEC ledClass
2 KB_IDSPEC ledID
2 unused
4 ATOM indicator
1 BOOL setState
1 BOOL on
1 BOOL setMap
1 BOOL createMap
1 unused
1 SETofKB_IMFLAGS map.flags
1 SETofKB_IMGROUPSWHICH map.whichGroups
1 SETofKB_GROUP map.groups
1 SETofKB_IMMODSWHICH map.whichMods
1 SETofKEYMASK map.realMods
2 SETofKB_VMOD map.vmods
4 SETofKB_BOOLCTRL map.ctrls
1 CARD8 opcode
1 17 xkb-opcode
2 3 request-length
2 KB_DEVICESPEC deviceSpec
2 unused
4 SETofKB_NAMEDETAIL which
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 V/4 length
4 SETofKB_NAMEDETAIL which
1 KEYCODE minKeyCode
1 KEYCODE maxKeyCode
1 t nTypes
1 SETofKB_GROUP groupNames (has g bits set to 1)
2 SETofKB_VMOD virtualMods (has v bits set to 1)
1 KEYCODE firstKey
1 k nKeys
4 SETofKB_INDICATOR indicators (has i bits set to 1)
1 r nRadioGroups
1 a nKeyAliases
2 l nKTLevels
4 unused
V LISTofITEMs valueList
SETofKB_NAMEDETAIL (which)
XkbKeycodesName keycodesName
XkbGeometryName geometryName
XkbSymbolsName symbolsName
XkbPhySymbolsName physSymbolsName
XkbTypesName typesName
XkbCompatName compatName
XkbKeyTypeNames typeNames
XkbKTLevelNames nLevelsPerType, ktLevelNames
XkbIndicatorNames indicatorNames
XkbVirtualModNames virtualModNames
XkbGroupNames groupNames
XkbKeyNames keyNames
XkbKeyAliases keyAliases
XkbRGNames radioGroupNames
ITEMs
4 ATOM keycodesName
4 ATOM geometryName
4 ATOM symbolsName
4 ATOM physSymbolsName
4 ATOM typesName
4 ATOM compatName
4t LISTofATOM typeNames
l LISTofCARD8 nLevelsPerType, sum of all elements=L
p unused, p=pad(l)
4L LISTofATOM ktLevelNames
4i LISTofATOM indicatorNames
4v LISTofATOM virtualModNames
4g LISTofATOM groupNames
4k LISTofKB_KEYNAME keyNames
8a LISTofKB_KEYALIAS keyAliases
4r LISTofATOM radioGroupNames
1 CARD8 opcode
1 18 xkb-opcode
2 7+(V/4) request-length
2 KB_DEVICESPEC deviceSpec
2 SETofKB_VMOD virtualMods
4 SETofKB_NAMEDETAIL which
1 CARD8 firstType
1 t nTypes
1 CARD8 firstKTLevel
1 l nKTLevels
4 SETofKB_INDICATOR indicators (has i bits set to 1)
1 SETofKB_GROUP groupNames (has g bits set to 1)
1 r nRadioGroups
1 KEYCODE firstKey
1 k nKeys
1 a nKeyAliases
1 unused
2 L totalKTLevelNames
V LISTofITEMs values
SETofKB_NAMEDETAIL (which)
XkbKeycodesName keycodesName
XkbGeometryName geometryName
XkbSymbolsName symbolsName
XkbPhySymbolsName physSymbolsName
XkbTypesName typesName
XkbCompatName compatName
XkbKeyTypeNames typeNames
XkbKTLevelNames nLevelsPerType, ktLevelNames
XkbIndicatorNames indicatorNames
XkbVirtualModNames virtualModNames
XkbGroupNames groupNames
XkbKeyNames keyNames
XkbKeyAliases keyAliases
XkbRGNames radioGroupNames
ITEMs
4 ATOM keycodesName
4 ATOM geometryName
4 ATOM symbolsName
4 ATOM physSymbolsName
4 ATOM typesName
4 ATOM compatName
4t LISTofATOM typeNames
l LISTofCARD8 nLevelsPerType
p unused, p=pad(l)
4L LISTofATOM ktLevelNames
4i LISTofATOM indicatorNames
4v LISTofATOM virtualModNames
4g LISTofATOM groupNames
4k LISTofKB_KEYNAME keyNames
8a LISTofKB_KEYALIAS keyAliases
4r LISTofATOM radioGroupNames
1 CARD8 opcode
1 19 xkb-opcode
2 3 request-length
2 KB_DEVICESPEC deviceSpec
2 unused
4 ATOM name
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 (f+8p+C*+H*+S*+D*+A*)/4 length
4 ATOM name
1 BOOL found
1 unused
2 CARD16 widthMM
2 CARD16 heightMM
2 p nProperties
2 c nColors
2 h nShapes
2 s nSections
2 d nDoodads
2 a nKeyAliases
1 CARD8 baseColorNdx
1 CARD8 labelColorNdx
f KB_COUNTED_STRING16 labelFont
8p LISTofKB_PROPERTY properties
C0+..Cc LISTofKB_COUNTED_STRING16 colors
H0+..Hh LISTofKB_SHAPE shapes
S0+..Ss LISTofKB_SECTION sections
D0+..Dd LISTofKB_DOODAD doodads
A0+..Aa LISTofKB_KEYALIAS keyAliases
KB_PROPERTY 4+n+v
2 n nameLength
n STRING8 name
2 v valueLength
v STRING8 value
KB_SHAPE 8+O*
4 ATOM name
1 o nOutlines
1 CARD8 primaryNdx
1 CARD8 approxNdx
1 unused
O0+..Oo LISTofKB_OUTLINE outlines
KB_OUTLINE 4+4p
1 p nPoints
1 CARD8 cornerRadius
2 unused
4p LISTofKB_POINT points
KB_POINT
2 INT16 x
2 INT16 y
KB_SECTION 20+R*+D*+O*
4 ATOM name
2 INT16 top
2 INT16 left
2 CARD16 width
2 CARD16 height
2 INT16 angle
1 CARD8 priority
1 r nRows
1 d nDoodads
1 o nOverlays
2 unused
R0+..Rr LISTofKB_ROW rows
D0+..Dd LISTofKB_DOODAD doodads
O0+..Oo LISTofKB_OVERLAY overlays
KB_ROW 8+8k
2 INT16 top
2 INT16 left
1 k nKeys
1 BOOL vertical
2 unused
8k LISTofKB_KEY keys
KB_KEY
4 STRING8 name
2 INT16 gap
1 CARD8 shapeNdx
1 CARD8 colorNdx
KB_OVERLAY 8+R*
4 ATOM name
1 r nRows
3 unused
R0+..Rr LISTofKB_OVERLAYROW rows
KB_OVERLAYROW 4+8k
1 CARD8 rowUnder
1 k nKeys
2 unused
8k LISTofKB_OVERLAYKEY keys
KB_OVERLAYKEY
4 STRING8 over
4 STRING8 under
KB_SHAPEDOODAD
4 ATOM name
1 CARD8 type
KB_SHAPEDOODAD
#1 XkbOutlineDoodad
#2 XkbSolidDoodad
1 CARD8 priority
2 INT16 top
2 INT16 left
2 INT16 angle
1 CARD8 colorNdx
1 CARD8 shapeNdx
6 unused
KB_TEXTDOODAD 20+t+f
4 ATOM name
1 CARD8 type
#3 XkbTextDoodad
1 CARD8 priority
2 INT16 top
2 INT16 left
2 INT16 angle
2 CARD16 width
2 CARD16 height
1 CARD8 colorNdx
3 unused
t KB_COUNTED_STRING16 text
f KB_COUNTED_STRING16 font
KB_INDICATORDOODAD
4 ATOM name
1 CARD8 type
#4 XkbIndicatorDoodad
1 CARD8 priority
2 INT16 top
2 INT16 left
2 INT16 angle
1 CARD8 shapeNdx
1 CARD8 onColorNdx
1 CARD8 offColorNdx
5 unused
KB_LOGODOODAD 20+n
4 ATOM name
1 CARD8 type
#5 XkbLogoDoodad
1 CARD8 priority
2 INT16 top
2 INT16 left
2 INT16 angle
1 CARD8 colorNdx
1 CARD8 shapeNdx
6 unused
n KB_COUNTED_STRING16 logoName
KB_DOODAD:
KB_SHAPEDOODAD, or KB_TEXTDOODAD, or
KB_INDICATORDOODAD, or KB_LOGODOODAD
1 CARD8 opcode
1 20 xkb-opcode
2 7+(f+8p+C*+H*+S*+D*+A*)/4 request-length
2 KB_DEVICESPEC deviceSpec
1 h nShapes
1 s nSections
4 ATOM name
2 CARD16 widthMM
2 CARD16 heightMM
2 p nProperties
2 c nColors
2 d nDoodads
2 a nKeyAliases
1 CARD8 baseColorNdx
1 CARD8 labelColorNdx
2 unused
f KB_COUNTED_STRING16 labelFont
8p LISTofKB_PROPERTY properties
C0+..Cc LISTofKB_COUNTED_STRING16 colors
H0+..Hh LISTofKB_SHAPE shapes
S0+..Ss LISTofKB_SECTION sections
D0+..Dd LISTofKB_DOODAD doodads
A0+..Aa LISTofKB_KEYALIAS keyAliases
1 CARD8 opcode
1 21 xkb-opcode
2 7 request-length
2 KB_DEVICESPEC deviceSpec
2 unused
4 SETofKB_PERCLIENTFLAG change
4 SETofKB_PERCLIENTFLAG value
4 SETofKB_BOOLCTRL ctrlsToChange
4 SETofKB_BOOLCTRL autoCtrls
4 SETofKB_BOOLCTRL autoCtrlValues
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 0 length
4 SETofKB_PERCLIENTFLAG supported
4 SETofKB_PERCLIENTFLAG value
4 SETofKB_BOOLCTRL autoCtrls
4 SETofKB_BOOLCTRL autoCtrlValues
8 unused
1 CARD8 opcode
1 22 xkb-opcode
2 2+(6+m+k+t+c+s+g+p)/4 request-length
2 KB_DEVICESPEC deviceSpec
2 CARD16 maxNames
1 m keymapsSpecLen
m STRING keymapsSpec
1 k keycodesSpecLen
k STRING keycodesSpec
1 t typesSpecLen
t STRING typesSpec
1 c compatMapSpecLen
c STRING compatMapSpec
1 s symbolsSpecLen
s STRING symbolsSpec
1 g geometrySpecLen
g STRING geometrySpec
p unused,p=pad(6+m+k+t+c+s+g)
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 (M*+K*+T*+C*+S*+G*+p)/4 length
2 m nKeymaps
2 k nKeycodes
2 t nTypes
2 c nCompatMaps
2 s nSymbols
2 g nGeometries
2 CARD16 extra
10 unused
M0+..Mm LISTofKB_LISTING keymaps
K0+..Kk LISTofKB_LISTING keycodes
T0+..Tt LISTofKB_LISTING types
C0+..Cc LISTofKB_LISTING compatMaps
S0+..Ss LISTofKB_LISTING symbols
G0+..Gg LISTofKB_LISTING geometries
p unused,p=pad(M*+K*+T*+C*+S*+G*)
KB_LISTING 4+n+p
2 CARD16 flags
2 n length
n STRING8 string
p unused,p=pad(n) to a 2-byte boundary
1 CARD8 opcode
1 23 xkb-opcode
2 3+(6+m+k+t+c+s+g+p)/4 request-length
2 KB_DEVICESPEC deviceSpec
2 SETofKB_GBNDETAILMASK need
2 SETofKB_GBNDETAILMASK want
1 BOOL load
1 unused
1 m keymapsSpecLen
m STRING8 keymapsSpec
1 k keycodesSpecLen
k STRING8 keycodesSpec
1 t typesSpecLen
t STRING8 typesSpec
1 c compatMapSpecLen
c STRING8 compatMapSpec
1 s symbolsSpecLen
s STRING8 symbolsSpec
1 g geometrySpecLen
g STRING8 geometrySpec
p unused,p=pad(6+m+k+t+c+s+g)
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 V/4 length
1 KEYCODE minKeyCode
1 KEYCODE maxKeyCode
1 BOOL loaded
1 BOOL newKeyboard
2 SETofKB_GBNDETAILMASK found
2 SETofKB_GBNDETAILMASK reported
16 unused
V LISTofITEMs replies
SETofKB_GBNDETAILMASK (reported)
XkbGBN_Types map
XkbGBN_CompatMap compat
XkbGBN_ClientSymbols map
XkbGBN_ServerSymbols map
XkbGBN_IndicatorMap indicators
XkbGBN_KeyNames names
XkbGBN_OtherNames names
XkbGBN_Geometry geometry
ITEMs
M XkbGetMap reply map
C XkbGetCompatMap reply compat
I XkbGetIndicatorMap reply indicators
N XkbGetNames reply names
G XkbGetGeometry reply geometry
1 CARD8 opcode
1 24 xkb-opcode
2 4 request-length
2 KB_DEVICESPEC deviceSpec
2 SETofKB_DEVFEATURE wanted
1 BOOL allButtons
1 CARD8 firstButton
1 CARD8 nButtons
1 unused
2 KB_LEDCLASSSPEC ledClass
2 KB_IDSPEC ledID
1 1 Reply
1 CARD8 deviceID
2 CARD16 sequence number
4 (2+n+p+8b+L*)/4 length
2 SETofKB_DEVFEATURE present
2 SETofKB_FEATURE supported
2 SETofKB_FEATURE unsupported
2 l nDeviceLedFBs
1 CARD8 firstBtnWanted
1 CARD8 nBtnsWanted
1 CARD8 firstBtnRtrn
1 b nBtnsRtrn
1 CARD8 totalBtns
1 BOOL hasOwnState
2 SETofKB_IDRESULT dfltKbdFB
2 SETofKB_IDRESULT dfltLedFB
2 unused
4 ATOM devType
2 n nameLen
n STRING8 name
p unused,p=pad(2+n)
8b LISTofKB_ACTION btnActions
L0+..Ll LISTofKB_DEVICELEDINFO leds
KB_DEVICELEDINFO 20+4n+12m
2 KB_LEDCLASSSPEC ledClass
2 KB_IDSPEC ledID
4 SETofKB_INDICATOR namesPresent (has n bits set to 1)
4 SETofKB_INDICATOR mapsPresent (has m bits set to 1)
4 SETofKB_INDICATOR physIndicators
4 SETofKB_INDICATOR state
4n LISTofATOM names
12m LISTofKB_INDICATORMAP maps
1 ?? opcode
1 25 xkb-opcode
2 3+(8b+L*)/4 request-length
2 KB_DEVICESPEC deviceSpec
1 CARD8 firstBtn
1 b nBtns
2 SETofKB_DEVFEATURE change
2 l nDeviceLedFBs
8b LISTofKB_ACTION btnActions
L0+..Ll LISTofKB_DEVICELEDINFO leds
Encoding of KB_DEVICELEDINFO is as for XkbGetDeviceInfo
1 ?? opcode
1 101 xkb-opcode
2 6+(n+p)/4 request-length
2 n msgLength
2 unused
4 CARD32 affectFlags
4 CARD32 flags
4 CARD32 affectCtrls
4 CARD32 ctrls
n STRING8 message
p unused, p=pad(n)
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 length
4 CARD32 currentFlags
4 CARD32 currentCtrls
4 CARD32 supportedFlags
4 CARD32 supportedCtrls
8 unused
Events
1 ?? code
1 0 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 CARD8 oldDeviceID
1 KEYCODE minKeyCode
1 KEYCODE maxKeyCode
1 KEYCODE oldMinKeyCode
1 KEYCODE oldMaxKeyCode
1 CARD8 requestMajor
1 CARD8 requestMinor
2 SETofKB_NKNDETAIL changed
14 unused
1 ?? code
1 1 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 SETofBUTMASK ptrBtnActions
2 SETofKB_MAPPART changed
1 KEYCODE minKeyCode
1 KEYCODE maxKeyCode
1 CARD8 firstType
1 CARD8 nTypes
1 KEYCODE firstKeySym
1 CARD8 nKeySyms
1 KEYCODE firstKeyAct
1 CARD8 nKeyActs
1 KEYCODE firstKeyBehavior
1 CARD8 nKeyBehavior
1 KEYCODE firstKeyExplicit
1 CARD8 nKeyExplicit
1 KEYCODE firstModMapKey
1 CARD8 nModMapKeys
1 KEYCODE firstVModMapKey
1 CARD8 nVModMapKeys
2 SETofKB_VMOD virtualMods
2 unused
1 ?? code
1 2 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 SETofKEYMASK mods
1 SETofKEYMASK baseMods
1 SETofKEYMASK latchedMods
1 SETofKEYMASK lockedMods
1 KB_GROUP group
2 INT16 baseGroup
2 INT16 latchedGroup
1 KB_GROUP lockedGroup
1 SETofKEYMASK compatState
1 SETofKEYMASK grabMods
1 SETofKEYMASK compatGrabMods
1 SETofKEYMASK lookupMods
1 SETofKEYMASK compatLookupMods
2 SETofBUTMASK ptrBtnState
2 SETofKB_STATEPART changed
1 KEYCODE keycode
1 CARD8 eventType
1 CARD8 requestMajor
1 CARD8 requestMinor
1 ?? code
1 3 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 CARD8 numGroups
2 unused
4 SETofKB_CONTROL changedControls
4 SETofKB_BOOLCTRL enabledControls
4 SETofKB_BOOLCTRL enabledControlChanges
1 KEYCODE keycode
1 CARD8 eventType
1 CARD8 requestMajor
1 CARD8 requestMinor
4 unused
1 ?? code
1 4 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
3 unused
4 SETofKB_INDICATOR state
4 SETofKB_INDICATOR stateChanged
12 unused
1 ?? code
1 5 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
3 unused
4 SETofKB_INDICATOR state
4 SETofKB_INDICATOR mapChanged
12 unused
1 ?? code
1 6 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 unused
2 SETofKB_NAMEDETAIL changed
1 CARD8 firstType
1 CARD8 nTypes
1 CARD8 firstLevelName
1 CARD8 nLevelNames
1 unused
1 CARD8 nRadioGroups
1 CARD8 nKeyAliases
1 SETofKB_GROUP changedGroupNames
2 SETofKB_VMOD changedVirtualMods
1 KEYCODE firstKey
1 CARD8 nKeys
4 SETofKB_INDICATOR changedIndicators
4 unused
1 ?? code
1 7 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 SETofKB_GROUP changedGroups
2 CARD16 firstSI
2 CARD16 nSI
2 CARD16 nTotalSI
16 unused
1 ?? code
1 8 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 KB_BELLCLASSRESULT bellClass
1 CARD8 bellID
1 CARD8 percent
2 CARD16 pitch
2 CARD16 duration
4 ATOM name
4 WINDOW window
1 BOOL eventOnly
7 unused
1 ?? code
1 9 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 KEYCODE keycode
1 BOOL press
1 BOOL keyEventFollows
1 SETofKEYMASK mods
1 KB_GROUP group
8 STRING8 message
10 unused
1 ?? code
1 10 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 KEYCODE keycode
2 SETofKB_AXNDETAIL detail
2 CARD16 slowKeysDelay
2 CARD16 debounceDelay
1 ?? code
16 unused
1 ?? code
1 11 xkb code
2 CARD16 sequence number
4 TIMESTAMP time
1 CARD8 deviceID
1 unused
2 SETofKB_XIDETAIL reason
2 KB_LEDCLASSRESULT ledClass
2 CARD8 ledID
4 SETofKB_INDICATOR ledsDefined
4 SETofKB_INDICATOR ledState
1 CARD8 firstButton
1 CARD8 nButtons
2 SETofKB_XIFEATURE supported
2 SETofKB_XIFEATURE unsupported
2 unused
xorgproto-2023.2/specs/kbproto/XKBproto-4.svg 0000644 0001750 0001750 00000064210 14443010026 015752 0000000 0000000
image/svg+xml
xorgproto-2023.2/specs/kbproto/XKBproto-1.svg 0000644 0001750 0001750 00000152342 14443010026 015753 0000000 0000000
image/svg+xml
xorgproto-2023.2/specs/kbproto/ch03.xml 0000644 0001750 0001750 00000016351 14443010026 014642 0000000 0000000
Virtual Modifiers
The core protocol specifies that
certain keysyms, when bound to modifiers, affect the rules of keycode to keysym
interpretation for all keys; for example, when
Num_Lock
is bound to some modifier, that modifier is used to choose shifted or
unshifted state for the numeric keypad keys. The core protocol does not provide
a convenient way to determine the mapping of modifier bits, in particular
Mod1
through
Mod5
, to keysyms such as
Num_Lock
and
Mode_switch
. Clients must retrieve and search the modifier map to determine the keycodes
bound to each modifier, and then retrieve and search the keyboard mapping to
determine the keysyms bound to the keycodes. They must repeat this process for
all modifiers whenever any part of the modifier mapping is changed.
XKB provides a set of sixteen named virtual modifiers, each of which can be
bound to any set of the eight "real" modifiers (
Shift
,
Lock
,
Control
and
Mod1
-
Mod5
as reported in the keyboard state). This makes it easier for applications and
keyboard layout designers to specify to the function a modifier key or data
structure should fulfill without having to worry about which modifier is bound
to a particular keysym.
The use of a single, server-driven mechanism for reporting changes to all data
structures makes it easier for clients to stay synchronized. For example, the
core protocol specifies a special interpretation for the modifier bound to the
Num_Lock
key. Whenever any keys or modifiers are rebound, every application has to
check the keyboard mapping to make sure that the binding for
Num_Lock
has not changed. If
Num_Lock
is remapped when XKB is in use, the keyboard description is automatically
updated to reflect the new binding, and clients are notified immediately and
explicitly if there is a change they need to consider.
The separation of function from physical modifier bindings also makes it easier
to specify more clearly the intent of a binding. X servers do not all assign
modifiers the same way — for example,
Num_Lock
might be bound to
Mod2
for one vendor and to
Mod4
for another. This makes it cumbersome to automatically remap the keyboard to a
desired configuration without some kind of prior knowledge about the keyboard
layout and bindings. With XKB, applications simply use virtual modifiers to
specify the behavior they want, without regard for the actual physical bindings
in effect.
XKB puts most aspects of the keyboard under user or program control, so it is
even more important to clearly and uniformly refer to modifiers by function.
Modifier Definitions
Use an
XKB modifier definition
to specify the modifiers affected by any XKB control or data structure. An XKB
modifier definition consists of a set of real modifiers, a set of virtual
modifiers, and an effective mask. The mask is derived from the real and virtual
modifiers and cannot be explicitly changed — it contains all of the real
modifiers specified in the definition
plus
any real modifiers that are bound to the virtual modifiers specified in the
definition. For example, this modifier definition specifies the numeric lock
modifier if the
Num_Lock
keysym is not bound to any real modifier:
{ real_mods= None, virtual_mods= NumLock, mask= None }
If we assign
Mod2
to the
Num_Lock
key, the definition changes to:
{ real_mods= None, virtual_mods= NumLock, mask= Mod2 }
Using this kind of modifier definition makes it easy to specify the desired
behavior in such a way that XKB can automatically update all of the data
structures that make up a keymap to reflect user or application specified
changes in any one aspect of the keymap.
The use of modifier definitions also makes it possible to unambiguously specify
the reason that a modifier is of interest. On a system for which the
Alt
and
Meta
keysyms are bound to the same modifier, the following definitions behave
identically:
{ real_mods= None, virtual_mods= Alt, mask= Mod1 }
{ real_mods= None, virtual_mods= Meta, mask= Mod1 }
If we rebind one of the modifiers, the modifier definitions automatically
reflect the change:
{ real_mods= None, virtual_mods= Alt, mask= Mod1 }
{ real_mods= None, virtual_mods= Meta, mask= Mod4 }
Without the level of indirection provided by virtual modifier maps and modifier
definitions, we would have no way to tell which of the two definitions is
concerned with
Alt
and which is concerned with
Meta .
Inactive Modifier Definitions
Some XKB structures ignore modifier
definitions in which the virtual modifiers are unbound. Consider this
example:
if ( state matches { Shift } ) Do OneThing;
if ( state matches { Shift+NumLock } ) Do Another;
If the
NumLock
virtual modifier is not bound to any real modifiers, these effective masks for
these two cases are identical (i.e. they contain only
Shift
). When it is essential to distinguish between
OneThing
and Another, XKB considers only those modifier definitions for which all
virtual modifiers are bound.
Virtual Modifier Mapping
XKB maintains a
virtual modifier mapping
, which lists the virtual modifiers associated with each key. The real
modifiers bound to a virtual modifier always include all of the modifiers bound
to any of the keys that specify that virtual modifier in their virtual modifier
mapping.
For example, if
Mod3
is bound to the
Num_Lock
key by the core protocol modifier mapping, and the
NumLock
virtual modifier is bound to they
Num_Lock
key by the virtual modifier mapping,
Mod3
is added to the set of modifiers associated with the
NumLock
virtual modifier.
The virtual modifier mapping is normally updated automatically whenever actions
are assigned to keys (see
xorgproto-2023.2/specs/kbproto/ch05.xml 0000644 0001750 0001750 00000007127 14443010026 014645 0000000 0000000
Key Event Processing Overview
There are three steps to processing each key event in the X server, and at
least three in the client. This section describes each of these steps briefly;
the following sections describe each step in more detail.
First, the server applies global keyboard controls to determine whether
the key event should be processed immediately, deferred, or ignored. For
example, the
SlowKeys
control can cause a key event to be deferred until the slow keys delay has
elapsed while the
RepeatKeys
control can cause multiple X events from a single physical key press if the
key is held down for an extended period. The global keyboard controls affect
all of the keys on the keyboard and are described in
Next, the server applies per-key behavior. Per key-behavior can be used
to simulate or indicate some special kinds of key behavior. For example,
keyboard overlays, in which a key generates an alternate keycode under certain
circumstances, can be implemented using per-key behavior. Every key has a
single behavior, so the effect of key behavior does not depend on keyboard
modifier or group state, though it might depend on global keyboard controls.
Per-key behaviors are described in detail in
Finally, the server applies key actions. Logically, every keysym on the
keyboard has some action associated with it. The key action tells the server
what to do when an event which yields the corresponding keysym is generated.
Key actions might change or suppress the event, generate some other event, or
change some aspect of the server. Key actions are described in
If the global controls, per-key behavior and key action combine to cause a key
event, the client which receives the event processes it in several steps.
First the client extracts the effective keyboard group and a set of
modifiers from the state field of the event. See
Using the modifiers and effective keyboard group, the client selects a
symbol from the list of keysyms bound to the key.
If necessary, the client transforms the symbol and resulting string
using any modifiers that are "left over" from the process of looking up a
symbol. For example, if the
Lock
modifier is left over, the resulting keysym is capitalized according to the
capitalization rules specified by the system. See
Finally, the client uses the keysym and remaining modifiers in an
application-specific way. For example, applications based on the X toolkit
might apply translations based on the symbol and modifiers reported by the
first three steps.
xorgproto-2023.2/specs/kbproto/Makefile.am 0000644 0001750 0001750 00000001550 14443010026 015412 0000000 0000000
if ENABLE_SPECS
# Main DocBook/XML files (DOCTYPE book)
docbook = xkbproto.xml
# Included chapters, appendix, images
chapters = \
acknowledgements.xml \
appA.xml \
appB.xml \
appC.xml \
appD.xml \
ch01.xml \
ch02.xml \
ch03.xml \
ch04.xml \
ch05.xml \
ch06.xml \
ch07.xml \
ch08.xml \
ch09.xml \
ch10.xml \
ch11.xml \
ch12.xml \
ch13.xml \
ch14.xml \
ch15.xml \
ch16.xml \
XKBproto-1.svg \
XKBproto-2.svg \
XKBproto-3.svg \
XKBproto-4.svg \
XKBproto-5.svg \
XKBproto-6.svg \
XKBproto-7.svg \
XKBproto-8.svg \
XKBproto-9.svg \
XKBproto-10.svg \
XKBproto-11.svg
# The location where the DocBook/XML files and their generated formats are installed
shelfdir = $(datarootdir)/doc/kbproto
# Generate DocBook/XML output formats with or without stylesheets
include $(top_srcdir)/docbook.am
endif ENABLE_SPECS
xorgproto-2023.2/specs/kbproto/XKBproto-8.svg 0000644 0001750 0001750 00000014511 14443010026 015755 0000000 0000000
image/svg+xml
xorgproto-2023.2/specs/kbproto/Makefile.in 0000644 0001750 0001750 00000060457 14443010031 015432 0000000 0000000 # Makefile.in generated by automake 1.16.5 from Makefile.am.
# @configure_input@
# Copyright (C) 1994-2021 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
@SET_MAKE@
#
# Generate output formats for a single DocBook/XML with/without chapters
#
# Variables set by the calling Makefile:
# shelfdir: the location where the docs/specs are installed. Typically $(docdir)
# docbook: the main DocBook/XML file, no chapters, appendix or image files
# chapters: all files pulled in by an XInclude statement and images.
#
#
# This makefile is intended for Users Documentation and Functional Specifications.
# Do not use for Developer Documentation which is not installed and does not require olink.
# Refer to http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html#id2584393
# for an explanation on documents classification.
#
VPATH = @srcdir@
am__is_gnu_make = { \
if test -z '$(MAKELEVEL)'; then \
false; \
elif test -n '$(MAKE_HOST)'; then \
true; \
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
else \
false; \
fi; \
}
am__make_running_with_option = \
case $${target_option-} in \
?) ;; \
*) echo "am__make_running_with_option: internal error: invalid" \
"target option '$${target_option-}' specified" >&2; \
exit 1;; \
esac; \
has_opt=no; \
sane_makeflags=$$MAKEFLAGS; \
if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
else \
case $$MAKEFLAGS in \
*\\[\ \ ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
esac; \
fi; \
skip_next=no; \
strip_trailopt () \
{ \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
}; \
for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
*=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
-*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
-*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
-*l?*) strip_trailopt 'l';; \
-[dEDm]) skip_next=yes;; \
-[JT]) skip_next=yes;; \
esac; \
case $$flg in \
*$$target_option*) has_opt=yes; break;; \
esac; \
done; \
test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_1 = $(docbook:.xml=.html)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@am__append_2 = $(docbook:.xml=.txt)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_3 = $(docbook:.xml=.pdf) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(docbook:.xml=.ps)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@am__append_4 = $(docbook:.xml=.html.db) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(docbook:.xml=.pdf.db)
subdir = specs/kbproto
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(am__dist_shelf_DATA_DIST) \
$(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
AM_V_P = $(am__v_P_@AM_V@)
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
am__v_P_0 = false
am__v_P_1 = :
AM_V_GEN = $(am__v_GEN_@AM_V@)
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
am__v_GEN_0 = @echo " GEN " $@;
am__v_GEN_1 =
AM_V_at = $(am__v_at_@AM_V@)
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
am__v_at_0 = @
am__v_at_1 =
SOURCES =
DIST_SOURCES =
am__can_run_installinfo = \
case $$AM_UPDATE_INFO_DIR in \
n|no|NO) false;; \
*) (install-info --version) >/dev/null 2>&1;; \
esac
am__dist_shelf_DATA_DIST = xkbproto.xml acknowledgements.xml appA.xml \
appB.xml appC.xml appD.xml ch01.xml ch02.xml ch03.xml ch04.xml \
ch05.xml ch06.xml ch07.xml ch08.xml ch09.xml ch10.xml ch11.xml \
ch12.xml ch13.xml ch14.xml ch15.xml ch16.xml XKBproto-1.svg \
XKBproto-2.svg XKBproto-3.svg XKBproto-4.svg XKBproto-5.svg \
XKBproto-6.svg XKBproto-7.svg XKBproto-8.svg XKBproto-9.svg \
XKBproto-10.svg XKBproto-11.svg
am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
am__vpath_adj = case $$p in \
$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
*) f=$$p;; \
esac;
am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
am__install_max = 40
am__nobase_strip_setup = \
srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
am__nobase_strip = \
for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
am__nobase_list = $(am__nobase_strip_setup); \
for p in $$list; do echo "$$p $$p"; done | \
sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
$(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
if (++n[$$2] == $(am__install_max)) \
{ print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
END { for (dir in files) print dir, files[dir] }'
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
am__uninstall_files_from_dir = { \
test -z "$$files" \
|| { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
|| { echo " ( cd '$$dir' && rm -f" $$files ")"; \
$(am__cd) "$$dir" && rm -f $$files; }; \
}
am__installdirs = "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"
DATA = $(dist_shelf_DATA) $(shelf_DATA)
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
am__DIST_COMMON = $(srcdir)/Makefile.in $(top_srcdir)/docbook.am
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
ADMIN_MAN_DIR = @ADMIN_MAN_DIR@
ADMIN_MAN_SUFFIX = @ADMIN_MAN_SUFFIX@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
APP_MAN_DIR = @APP_MAN_DIR@
APP_MAN_SUFFIX = @APP_MAN_SUFFIX@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BASE_CFLAGS = @BASE_CFLAGS@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CHANGELOG_CMD = @CHANGELOG_CMD@
CPPFLAGS = @CPPFLAGS@
CSCOPE = @CSCOPE@
CTAGS = @CTAGS@
CWARNFLAGS = @CWARNFLAGS@
CYGPATH_W = @CYGPATH_W@
DEFS = @DEFS@
DEPDIR = @DEPDIR@
DRIVER_MAN_DIR = @DRIVER_MAN_DIR@
DRIVER_MAN_SUFFIX = @DRIVER_MAN_SUFFIX@
ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
ETAGS = @ETAGS@
EXEEXT = @EXEEXT@
FILE_MAN_DIR = @FILE_MAN_DIR@
FILE_MAN_SUFFIX = @FILE_MAN_SUFFIX@
FOP = @FOP@
INSTALL = @INSTALL@
INSTALL_CMD = @INSTALL_CMD@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIB_MAN_DIR = @LIB_MAN_DIR@
LIB_MAN_SUFFIX = @LIB_MAN_SUFFIX@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAN_SUBSTS = @MAN_SUBSTS@
MISC_MAN_DIR = @MISC_MAN_DIR@
MISC_MAN_SUFFIX = @MISC_MAN_SUFFIX@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
PKG_CONFIG = @PKG_CONFIG@
PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
PYTHON = @PYTHON@
PYTHON_EXEC_PREFIX = @PYTHON_EXEC_PREFIX@
PYTHON_PLATFORM = @PYTHON_PLATFORM@
PYTHON_PREFIX = @PYTHON_PREFIX@
PYTHON_VERSION = @PYTHON_VERSION@
SED = @SED@
SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
STRICT_CFLAGS = @STRICT_CFLAGS@
STRIP = @STRIP@
STYLESHEET_SRCDIR = @STYLESHEET_SRCDIR@
USE_FDS_BITS = @USE_FDS_BITS@
VERSION = @VERSION@
XMLTO = @XMLTO@
XORG_MAN_PAGE = @XORG_MAN_PAGE@
XORG_SGML_PATH = @XORG_SGML_PATH@
XSLTPROC = @XSLTPROC@
XSL_STYLESHEET = @XSL_STYLESHEET@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build = @build@
build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
pkgpyexecdir = @pkgpyexecdir@
pkgpythondir = @pkgpythondir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
pyexecdir = @pyexecdir@
pythondir = @pythondir@
runstatedir = @runstatedir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
# Main DocBook/XML files (DOCTYPE book)
@ENABLE_SPECS_TRUE@docbook = xkbproto.xml
# Included chapters, appendix, images
@ENABLE_SPECS_TRUE@chapters = \
@ENABLE_SPECS_TRUE@ acknowledgements.xml \
@ENABLE_SPECS_TRUE@ appA.xml \
@ENABLE_SPECS_TRUE@ appB.xml \
@ENABLE_SPECS_TRUE@ appC.xml \
@ENABLE_SPECS_TRUE@ appD.xml \
@ENABLE_SPECS_TRUE@ ch01.xml \
@ENABLE_SPECS_TRUE@ ch02.xml \
@ENABLE_SPECS_TRUE@ ch03.xml \
@ENABLE_SPECS_TRUE@ ch04.xml \
@ENABLE_SPECS_TRUE@ ch05.xml \
@ENABLE_SPECS_TRUE@ ch06.xml \
@ENABLE_SPECS_TRUE@ ch07.xml \
@ENABLE_SPECS_TRUE@ ch08.xml \
@ENABLE_SPECS_TRUE@ ch09.xml \
@ENABLE_SPECS_TRUE@ ch10.xml \
@ENABLE_SPECS_TRUE@ ch11.xml \
@ENABLE_SPECS_TRUE@ ch12.xml \
@ENABLE_SPECS_TRUE@ ch13.xml \
@ENABLE_SPECS_TRUE@ ch14.xml \
@ENABLE_SPECS_TRUE@ ch15.xml \
@ENABLE_SPECS_TRUE@ ch16.xml \
@ENABLE_SPECS_TRUE@ XKBproto-1.svg \
@ENABLE_SPECS_TRUE@ XKBproto-2.svg \
@ENABLE_SPECS_TRUE@ XKBproto-3.svg \
@ENABLE_SPECS_TRUE@ XKBproto-4.svg \
@ENABLE_SPECS_TRUE@ XKBproto-5.svg \
@ENABLE_SPECS_TRUE@ XKBproto-6.svg \
@ENABLE_SPECS_TRUE@ XKBproto-7.svg \
@ENABLE_SPECS_TRUE@ XKBproto-8.svg \
@ENABLE_SPECS_TRUE@ XKBproto-9.svg \
@ENABLE_SPECS_TRUE@ XKBproto-10.svg \
@ENABLE_SPECS_TRUE@ XKBproto-11.svg
# The location where the DocBook/XML files and their generated formats are installed
@ENABLE_SPECS_TRUE@shelfdir = $(datarootdir)/doc/kbproto
# DocBook/XML generated output formats to be installed
@ENABLE_SPECS_TRUE@shelf_DATA = $(am__append_1) $(am__append_2) \
@ENABLE_SPECS_TRUE@ $(am__append_3) $(am__append_4)
# DocBook/XML file with chapters, appendix and images it includes
@ENABLE_SPECS_TRUE@dist_shelf_DATA = $(docbook) $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_OLINK_FLAGS)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_PDF_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_IMAGEPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_PDF_OLINK_FLAGS)
# Generate documents cross-reference target databases
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam targets.filename "$@" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam collect.xref.targets "only" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam olink.base.uri "$(@:.db=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_PDF_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@CLEANFILES = $(shelf_DATA)
all: all-am
.SUFFIXES:
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/docbook.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign specs/kbproto/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign specs/kbproto/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
*config.status*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
*) \
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \
esac;
$(top_srcdir)/docbook.am $(am__empty):
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(top_srcdir)/configure: $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
install-dist_shelfDATA: $(dist_shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-dist_shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
install-shelfDATA: $(shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
tags TAGS:
ctags CTAGS:
cscope cscopelist:
distdir: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) distdir-am
distdir-am: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
all-am: Makefile $(DATA)
installdirs:
for dir in "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"; do \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-am
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
mostlyclean-generic:
clean-generic:
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
clean: clean-am
clean-am: clean-generic mostlyclean-am
distclean: distclean-am
-rm -f Makefile
distclean-am: clean-am distclean-generic
dvi: dvi-am
dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am: install-dist_shelfDATA install-shelfDATA
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
-rm -f Makefile
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-generic
pdf: pdf-am
pdf-am:
ps: ps-am
ps-am:
uninstall-am: uninstall-dist_shelfDATA uninstall-shelfDATA
.MAKE: install-am install-strip
.PHONY: all all-am check check-am clean clean-generic cscopelist-am \
ctags-am distclean distclean-generic distdir dvi dvi-am html \
html-am info info-am install install-am install-data \
install-data-am install-dist_shelfDATA install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-shelfDATA install-strip installcheck installcheck-am \
installdirs maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-generic pdf pdf-am ps ps-am tags-am \
uninstall uninstall-am uninstall-dist_shelfDATA \
uninstall-shelfDATA
.PRECIOUS: Makefile
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.html: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@%.txt: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.pdf: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.ps: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.html.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_HTML_FLAGS) $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.pdf.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_PDF_FLAGS) $<
# Generate DocBook/XML output formats with or without stylesheets
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
xorgproto-2023.2/specs/kbproto/ch06.xml 0000644 0001750 0001750 00000126032 14443010026 014643 0000000 0000000
Key Event Processing in the Server
This section describes the steps involved in processing a key event within the
server when XKB is present. Key events can be generated due to keyboard
activity and passed to XKB by the DDX layer, or they can be synthesized by
another extension, such as XTEST.
Applying Global Controls
When the X Keyboard Extension receives a key event, it first checks the global
key controls to decide whether to process the event immediately or at all. The
global key controls which might affect the event, in descending order of
priority, are:
If a key is pressed while the
BounceKeys
control is enabled, the extension generates the event only if the key is
active. When a key is released, the server deactivates the key and starts a
bounce keys timer
with an interval specified by the debounce delay.
If the bounce keys timer expires or if some other key is pressed before the
timer expires, the server reactivates the corresponding key and deactivates the
timer. Neither expiration nor deactivation of a bounce keys timer causes an
event.
If the
SlowKeys
control is enabled, the extension sets a
slow keys timer
with an interval specified by the slow keys delay, but does not process the
key event immediately. The corresponding key release deactivates this timer.
If the slow keys timer expires, the server generates a key press for the
corresponding key, sends an
XkbAccessXNotify
and deactivates the timer.
The extension processes key press events normally whether or not the
RepeatKeys
control is active, but if
RepeatKeys
are enabled and per-key autorepeat is enabled for the event key, the extension
processes key press events normally, but it also initiates an
autorepeat timer
with an interval specified by the autorepeat delay. The corresponding key
release deactivates the timer.
If the autorepeat timer expires, the server generates a key release and a key
press for the corresponding key and reschedules the timer according to the
autorepeat interval.
Key events are processed by each global control in turn: if the
BounceKeys
control accepts a key event,
SlowKeys
considers it. Once
SlowKeys
allows or synthesizes an event, the
RepeatKeys
control acts on it.
Key Behavior
Once an event is accepted by all of the controls or generated by a timer, the
server checks the per-key behavior of the corresponding key. This extension
currently defines the following key behaviors:
Behavior
Effect
KB_Default
Press and release events are processed normally.
KB_Lock
If a key is logically up (i.e. the corresponding bit of the core key
map is cleared) when it is pressed, the key press is processed normally and the
corresponding release is ignored. If the key is logically down when pressed,
the key press is ignored but the corresponding release is processed normally.
KB_RadioGroup
flags: CARD8
index: CARD8
If another member of the radio group specified by
index
is logically down when a key is pressed, the server synthesizes a key release
for the member that is logically down and then processes the new key press
event normally.
If the key itself is logically down when pressed, the key press event is
ignored, but the processing of the corresponding key release depends on the
value of the
RGAllowNone
bit in
flags
. If it is set, the key release is processed normally; otherwise the key
release is also ignored.
All other key release events are ignored.
KB_Overlay1
key: KEYCODE
If the
Overlay1
control is enabled, events from this key are reported as if they came from the
key specified in
key
. Otherwise, press and release events are processed normally.
KB_Overlay2
key: KEYCODE
If the
Overlay2
control is enabled, events from this key are reported as if they came from the
key specified in
key
. Otherwise, press and release events are processed normally.
The X server uses key behavior to determine whether to process or filter out
any given key event; key behavior is independent of keyboard modifier or group
state (each key has exactly one behavior.
Key behaviors can be used to simulate any of these types of keys or to indicate
an unmodifiable physical, electrical or software driver characteristic of a
key. An optional
permanent
flag can modify any of the supported behaviors and indicates that behavior
describes an unalterable physical, electrical or software aspect of the
keyboard. Permanent behaviors cannot be changed or set by the
XkbSetMap
request. The
permanent
flag indicates a characteristic of the underlying system that XKB cannot
affect, so XKB treats all permanent behaviors as if they were
KB_Default
and does not filter key events described in the table above.
Key Actions
Once the server has applied the global controls and per-key behavior and has
decided to process a key event, it applies
key actions
to determine the effects of the key on the internal state of the server. A key
action consists of an operator and some optional data. XKB supports actions
which:
change base, latched or locked modifiers or group
move the core pointer or simulate core pointer button events
change most aspects of keyboard behavior
terminate or suspend the server
send a message to interested clients
simulate events on other keys
Each key has an optional list of actions. If present, this list parallels the
list of symbols associated with the key (i.e. it has one action per symbol
associated with the key). For key press events, the server looks up the action
to be applied from this list using the key symbol mapping associated with the
event key, just as a client looks up symbols as described in
SA_NoAction
event for that key regardless of modifier or group state.
Key actions have essentially two halves; the effects on the server when the key
is pressed and the effects when the key is released. The action applied for a
key press event determines the further actions, if any, that are applied to the
corresponding release event or to events that occur while the key is held down.
Clients can change the actions associated with a key while the key is down
without changing the action applied next time the key is released; subsequent
press-release pairs will use the newly bound key action.
Most actions directly change the state of the keyboard or server; some actions
also modify other actions that occur simultaneously with them. Two actions
occur simultaneously if the keys which invoke the actions are both logically
down at the same time, regardless of the order in which they are pressed or
delay between the activation of one and the other.
Most actions which affect keyboard modifier state accept a modifier definition
(see
mods
and a boolean flag name
useModMap
among their arguments. These two fields combine to specify the modifiers
affected by the action as follows: If
useModMap
is
True
, the action sets any modifiers bound by the modifier mapping to the key that
initiated the action; otherwise, the action sets the modifiers specified by
mods
. For brevity in the text of the following definitions, we refer to this
combination of
useModMap
and
mods
as the "action modifiers."
The X Keyboard Extension supports the following actions:
Action
Effect
SA_NoAction
No direct effect, though SA_NoAction
events may change the effect of other server actions (see below).
SA_SetMods
mods: MOD_DEF
useModMap: BOOL
clearLocks: BOOL
Key press adds any action modifiers to the keyboard’s base modifiers.
Key release clears any action modifiers in the keyboard’s base
modifiers, provided that no other key which affects the same modifiers is
logically down.
If no keys were operated simultaneously with this key and
clearLocks
is set, release unlocks any action modifiers.
SA_LatchMods
mods: MOD_DEF
useModMap: BOOL
clearLocks: BOOL
latchToLock: BOOL
Key press and release events have the same effect as for
SA_SetMods
; if no keys were operated simultaneously with the latching modifier key, key
release events have the following additional effects:
Modifiers that were unlocked due to
clearLocks
have no further effect.
If
latchToLock
is set, key release locks and then unlatches any remaining action modifiers
that are already latched.
Finally, key release latches any action modifiers that were not used by
the
clearLocks
or
latchToLock
flags.
SA_LockMods
mods: MOD_DEF
useModMap: BOOL
noLock: BOOL
noUnlock: BOOL
Key press sets the base and possibly the locked state of any action
modifiers. If
noLock
is
True
, only the base state is changed.
For key release events, clears any action modifiers in the keyboard’s
base modifiers, provided that no other key which affects the same modifiers is
down. If
noUnlock
is
False
and any of the action modifiers were locked before the corresponding key press
occurred, key release unlocks them.
SA_SetGroup
group: INT8
groupAbsolute: BOOL
clearLocks: BOOL
If
groupAbsolute
is set, key press events change the base keyboard group to
group
; otherwise, they add
group
to the base keyboard group. In either case, the resulting effective keyboard
group is brought back into range depending on the value of the
GroupsWrap
control for the keyboard.
If an
SA_ISOLock
key is pressed while this key is held down, key release has no effect,
otherwise it cancels the effects of the press.
If no keys were operated simultaneously with this key and
clearLocks
is set, key release also sets the locked keyboard group to
Group1
.
SA_LatchGroup
group: INT8
groupAbsolute: BOOL
clearLocks: BOOL
latchToLock: BOOL
Key press and release events have the same effect as an
SA_SetGroup
action; if no keys were operated simultaneously with the latching group key
and the
clearLocks
flag was not set or had no effect, key release has the following additional
effects:
If
latchToLock
is set and the latched keyboard group is non-zero, the key release adds the
delta applied by the corresponding key press to the locked keyboard group and
subtracts it from the latched keyboard group. The locked and effective keyboard
group are brought back into range according to the value of the global
GroupsWrap
control for the keyboard.
Otherwise, key release adds the key press delta to the latched keyboard
group.
SA_LockGroup
group: INT8
groupAbsolute: BOOL
If
groupAbsolute
is set, key press sets the locked keyboard group to
group
. Otherwise, key press adds
group
to the locked keyboard group. In either case, the resulting locked and
effective group is brought back into range depending on the value of the
GroupsWrap
control for the keyboard.
Key release has no effect.
SA_MovePtr
x, y: INT16
noAccel: BOOL
absoluteX: BOOL
absoluteY: BOOL
If
MouseKeys
are not enabled, this action behaves like
SA_NoAction
, otherwise this action cancels any pending repeat key timers for this key and
has the following additional effects.
Key press generates a core pointer
MotionNotify
event instead of the usual
KeyPress
. If
absoluteX
is
True
,
x
specifies the new pointer X coordinate, otherwise
x
is added to the current pointer X coordinate;
absoluteY
and
y
specify the new Y coordinate in the same way.
If
noAccel
is
False
, and the
MouseKeysAccel
keyboard control is enabled, key press also initiates the mouse keys timer for
this key; every time this timer expires, the cursor moves again. The distance
the cursor moves in these subsequent events is determined by the mouse keys
acceleration as described in
Key release disables the mouse keys timer (if it was initiated by the
corresponding key press) but has no other effect and is ignored (does not
generate an event of any type).
SA_PtrBtn
button: CARD8
count: CARD8
useDfltBtn: BOOL
If
MouseKeys
are not enabled, this action behaves like
SA_NoAction
.
If
useDfltBtn
is set, the event is generated for the current default core button. Otherwise,
the event is generated for the button specified by
button
.
If the mouse button specified for this action is logically down, the
key press and corresponding release are ignored and have no effect.
Otherwise, key press causes one or more core pointer button events
instead of the usual key press. If
count
is
0
, key press generates a single
ButtonPress
event; if
count
is greater than
0
, key press generates
count
pairs of
ButtonPress
and
ButtonRelease
events.
If
count
is
0
, key release generates a core pointer
ButtonRelease
which matches the event generated by the corresponding key press; if count is
non-zero, key release does not cause a
ButtonRelease
event. Key release never causes a key release event.
SA_LockPtrBtn
button: BUTTON
noLock: BOOL
noUnlock: BOOL
useDfltBtn: BOOL
If
MouseKeys
are not enabled, this action behaves like
SA_NoAction
.
Otherwise, if the button specified by
useDfltBtn
and
button
is not locked, key press causes a
ButtonPress
instead of a key press and locks the button. If the button is already locked
or if
noLock
is
True
, key press is ignored and has no effect.
If the corresponding key press was ignored, and if
noUnlock
is
False
, key release generates a
ButtonRelease
event instead of a key release event and unlocks the specified button. If the
corresponding key press locked a button, key release is ignored and has no
effect.
SA_SetPtrDflt
affect: CARD8
value: CARD8
dfltBtnAbs: BOOL
If
MouseKeys
are not enabled, this action behaves like
SA_NoAction
.
Otherwise, both key press and key release are ignored, but key press
changes the pointer value specified by
affect
to
value
, as follows:
If
which
is
SA_AffectDfltBtn
,
value
and
dfltBtnAbs
specify the default pointer button used by the various pointer actions as
follow: If
dfltBtnAbs
is True, value specifies the button to be used, otherwise,
value
specifies the amount to be added to the current default button. In either
case, illegal button choices are wrapped back into range.
SA_ISOLock
dfltIsGroup:
False
mods: MOD_DEF
useModMap: BOOL
noLock: BOOL
noUnlock: BOOL
noAffectMods: BOOL
noAffectGrp: BOOL
noAffectPtr: BOOL
noAffectCtrls: BOOL
or
dfltIsGroup:
True
group: INT8
groupAbsolute: BOOL
noAffectMods: BOOL
noAffectGrp: BOOL
noAffectPtr: BOOL
noAffectCtrls: BOOL
If
dfltIsGroup
is
True
, key press sets the base group specified by
groupAbsolute
and
group
. Otherwise, key press sets the action modifiers in the keyboard’s base
modifiers.
Key release clears the base modifiers or group that were set by the key
press; it may have additional effects if no other appropriate actions occur
simultaneously with the
SA_ISOLock
operation.
If
noAffectMods
is
False
, any
SA_SetMods
or
SA_LatchMods
actions that occur simultaneously with the
ISOLock
action are treated as
SA_LockMods
instead.
If
noAffectGrp
is
False
, any
SA_SetGroup
or
SA_LatchGroup
actions that occur simultaneously with this action are treated as
SA_LockGroup
actions instead.
If
noAffectPtr
is
False
,
SA_PtrBtn
actions that occur simultaneously with the
SA_ISOLock
action are treated as
SA_LockPtrBtn
actions instead.
If
noAffectCtrls
is
False
, any
SA_SetControls
actions that occur simultaneously with the
SA_ISOLock
action are treated as
SA_LockControls
actions instead.
If no other actions were transformed by the
SA_ISOLock
action, key release locks the group or modifiers specified by the action
arguments.
SA_TerminateServer
Key press terminates the server. Key release is ignored.
This action is optional; servers are free to ignore it. If ignored, it
behaves like
SA_NoAction
.
SA_SwitchScreen
num: INT8
switchApp: BOOL
screenAbs: BOOL
If the server supports this action and multiple screens or displays
(either virtual or real), this action changes to the active screen indicated by
num
and
screenAbs
. If
screenAbs
is
True
, num specifies the index of the new screen; otherwise, num specifies an offset
from the current screen to the new screen.
If
switchApp
is
False
, it should switch to another screen on the same server. Otherwise it should
switch to another X server or application which shares the same physical
display.
This action is optional; servers are free to ignore the action or any
of its flags if they do not support the requested behavior. If the action is
ignored, it behaves like
SA_NoAction
, otherwise neither key press nor release generate an event.
SA_SetControls controls: KB_BOOLCTRLMASK
Key press enables any boolean controls that are specified in
controls
and not already enabled at the time of the key press. Key release disables any
controls that were enabled by the corresponding key press. This action can
cause
XkbControlsNotify
events.
SA_LockControls
controls: KB_BOOLCTRLMASK
noLock: BOOL
noUnlock: BOOL
If
noLock
is
False
, key press locks and enables any controls that are specified in
controls
and not already locked at the time of the key press.
If
noUnlock
is
False
, key release unlocks and disables any controls that are specified in
controls
and were not enabled at the time of the corresponding key press.
SA_ActionMessage
:
pressMsg: BOOL
releaseMsg: BOOL
genEvent: BOOL
message: STRING
if
pressMsg
is
True
, key press generates an
XkbActionMessage
event which reports the keycode, event type and the contents of
message
.
If
releaseMsg
is
True
, key release generates an
XkbActionMessage
event which reports the keycode, event type and contents of
message
.
If
genEvent
is
True
, both press and release generate key press and key release events, regardless
of whether they also cause an
XkbActionMessage
.
SA_RedirectKey
newKey: KEYCODE
modsMask: KEYMASK
mods: KEYMASK
vmodsMask: CARD16
vmods: CARD16
Key press causes a key press event for the key specified by
newKey
instead of for the actual key. The state reported in this event reports of the
current effective modifiers changed as follow: Any real modifiers specified in
modsMask
are set to corresponding values from
mods
. Any real modifiers bound to the virtual modifiers specified in
vmodsMask
are either set or cleared, depending on the corresponding value in
vmods
. If the real and virtual modifier definitions specify conflicting values for a
single modifier, the real modifier definition has priority.
Key release causes a key release event for the key specified by
newKey
; the state field for this event consists of the effective keyboard modifiers
at the time of the release, changed as described above.
The
SA_RedirectKey
action normally redirects to another key on the same device as the key or
button which caused the event, unless that device does not belong to the input
extension KEYCLASS, in which case this action causes an event on the core
keyboard device.
SA_DeviceBtn
count: CARD8
button: BUTTON
device: CARD8
The
device
field specifies the ID of an extension device; the
button
field specifies the index of a button on that device. If the button specified
by this action is logically down, the key press and corresponding release are
ignored and have no effect. If the device or button specified by this action
are illegal, this action behaves like
SA_NoAction
.
Otherwise, key press causes one or more input extension device button
events instead of the usual key press event. If
count
is
0
, key press generates a single
DeviceButtonPress
event; if
count
is greater than
0
, key press generates
count
pairs of
DeviceButtonPress
and
DeviceButtonRelease
events.
If
count
is
0
, key release generates an input extension
DeviceButtonRelease
which matches the event generated by the corresponding key press; if count is
non-zero, key release does not cause a
DeviceButtonRelease
event. Key release never causes a key release event.
SA_LockDeviceBtn
button: BUTTON
device: CARD8
noLock: BOOL
noUnlock: BOOL
The
device
field specifies the ID of an extension device; the
button
field specifies the index of a button on that device. If the device or button
specified by this action are illegal, it behaves like
SA_NoAction
.
Otherwise, if the specified button is not locked and if
noLock
is
False
, key press causes an input extension
DeviceButtonPress
event instead of a key press event and locks the button. If the button is
already locked or if
noLock
is
True
, key press is ignored and has no effect.
If the corresponding key press was ignored, and if
noUnlock
is
False
, key release generates an input extension
DeviceButtonRelease
event instead of a core protocol or input extension key release event and
unlocks the specified button. If the corresponding key press locked a button,
key release is ignored and has no effect.
SA_DeviceValuator
device
: CARD8
val1What
: SA_DVOP
val1
: CARD8
val1Value
: INT8
val1Scale
: 0...7
val2What
: BOOL
val2
: CARD8
val2Value
: INT8
val2Scale
: 0...7
The
device
field specifies the ID of an extension device;
val1
and
val2
specify valuators on that device. If
device
is illegal or if neither
val1
nor
val2
specifies a legal valuator, this action behaves like
SA_NoAction
.
If
valn
specifies a legal valuator and
valnWhat
is not
SA_IgnoreVal
, the specified value is adjusted as specified by
valnWhat
:
If
valnWhat
is
SA_SetValMin
,
valn
is set to its minimum legal value.
If
valnWhat
is
SA_SetValCenter
,
valn
is centered (to (max-min)/2).
If
valnWhat
is
SA_SetValMax
,
valn
is set to its maximum legal value.
if
valnWhat
is
SA_SetValRelative
,
is added to
valn
.
if
valnWhat
is
SA_SetValAbsolute
,
valn
is set to
.
Illegal values for
SA_SetValRelative
or
SA_SetValAbsolute
are clamped into range.
If
StickyKeys
are enabled, all
SA_SetMods
and
SA_SetGroup
actions act like
SA_LatchMods
and
SA_LatchGroup
respectively. If the
LatchToLock
AccessX option is set, either action behaves as if both the
SA_ClearLocks
and
SA_LatchToLock
flags are set.
Actions which cause an event from another key or from a button on another
device immediately generate the specified event. These actions do not consider
the behavior or actions (if any) that are bound to the key or button to which
the event is redirected.
Core events generated by server actions contain the keyboard state that was in
effect at the time the key event occurred; the reported state does not reflect
any changes in state that occur as a result of the actions bound to the key
event that caused them.
Events sent to clients that have not issued an
XkbUseExtension
request contain a compatibility state in place of the actual XKB keyboard
state. See
Delivering a Key or Button Event to a Client
The window and client that receive core protocol and input extension key or
button events are determined using the focus policy, window hierarchy and
passive grabs as specified by the core protocol and the input extension, with
the following changes:
A passive grab triggers if the modifier state specified in the grab
matches the grab compatibility state (described in
GrabsUseXKBState
per-client flag. This flag affects all passive grabs that are requested by the
client which sets it but does not affect passive grabs that are set by any
other client.
The state field of events which trigger a passive grab reports the XKB
or compatibility grab state in effect at the time the grab is triggered; the
state field of the corresponding release event reports the corresponding grab
state in effect when the key or button is released.
If the
LookupStateWhenGrabbed
per-client flag is set, all key or button events that occur while a keyboard
or pointer grab is active contain the XKB or compatibility lookup state,
depending on the value of the
GrabsUseXKBState
per-client flag. If
LookupStateWhenGrabbed
is not set, they include the XKB or compatibility grab state, instead.
Otherwise, the state field of events that do not trigger a passive grab
report is derived from the XKB effective modifiers and group, as described in
If a key release event is the result of an autorepeating key that is
being held down, and the client to which the event is reported has requested
detectable autorepeat (see
The following section explains the intent of the XKB interactions with core
protocol grabs and the reason that the per-client flags are needed.
XKB Interactions With Core Protocol Grabs
XKB provides the separate lookup and grab states to help work around some
difficulties with the way the core protocol specifies passive grabs.
Unfortunately, many clients work around those problems differently, and the way
that XKB handles grabs and reports keyboard state can sometimes interact with
those client workarounds in unexpected and unpleasant ways.
To provide more reasonable behavior for clients that are aware of XKB without
causing problems for clients that are unaware of XKB, this extension provides
two per-client flags that specify the way that XKB and the core protocol should
interact.
The largest problems arise from the fact that an XKB state field
encodes an explicit keyboard group in bits 13-14 (as described in
GrabsUseXKBState
per-client flag to indicate that they are specifying passive grabs using an
XKB state.
Some toolkits start an active grab when a passive grab is triggered, in
order to have more control over the conditions under which the grab is
terminated. Unfortunately, the fact that XKB reports a different state in
events that trigger or terminate grabs means that this grab simulation can fail
to terminate the grab under some conditions. To work around this problem, XKB
normally reports the grab state in all events whenever a grab is active.
Clients which do not use active grabs like this can set the
LookupStateWhenGrabbed
per-client flag in order to receive the same state component whether or not a
grab is active.
The
GrabsUseXKBState
per-client flag also applies to the state of events sent while a grab is
active. If it is set, events during a grab contain the XKB lookup or grab
state; by default, events during a grab contain the compatibility lookup or
grab state.
The state used to trigger a passive grab is controlled by the setting of the
GrabsUseXKBState
per-client flag at the time the grab is registered. Changing this flag does
not affect existing passive grabs.
xorgproto-2023.2/specs/kbproto/ch15.xml 0000644 0001750 0001750 00000016050 14443010026 014641 0000000 0000000
Interactions Between XKB and the X Input Extension
All XKB interactions with the input extension are optional; implementors are
free to restrict the effects of the X Keyboard Extension to the core keyboard
device. The
XkbGetExtensionDeviceInfo
request reports whether or not an XKB implementation supports a particular
capability for input extension devices.
XKB recognizes the following interactions with the X Input Extension:
Name
Capability
XI_Keyboards
If set, applications can use all XKB requests and events with
extension keyboards.
XI_ButtonActions
If set, clients can assign key actions to buttons, even on input
extension devices that are not keyboards.
XI_IndicatorNames
If set, clients can assign names to indicators on non-keyboard
extension devices.
XI_IndicatorMaps
If set, clients can assign indicator maps to indicators on
non-keyboard extension devices.
XI_IndicatorState
If set, clients can change the state of device indicators using the
XkbSetExtensionDeviceInfo
request.
Attempts to use an XKB feature with an extension device fail with a
Keyboard
error if the server does not support the
XkbXI_Keyboards
optional feature. If a capability particular capability other than
XkbXI_Keyboards
is not supported, attempts to use it fail silently. The replies for most
requests that can use one of the other optional features include a field to
report whether or not the request was successful, but such requests do not
cause an error condition.
Clients can also request an
XkbExtensionDeviceNotify
event. This event notifies interested clients of changes to any of the
supported XKB features for extension devices, or if a request from the client
that is receiving the event attempted to use an unsupported feature.
Using XKB Functions with Input Extension Keyboards
All XKB requests and events include a device identifier which can refer to an
input extension
KeyClass
device, if the implementation allows XKB to control extension devices. If the
implementation does not support XKB manipulation of extension devices, the
device identifier is ignored but it must be either
0
or
UseCoreKbd
.
Implementations which do not support the use of XKB functions with extension
keyboards must not set the
XkbXI_Keyboards
flag. Attempts to use XKB features on an extension keyboard with an
implementation that does not support this feature yield a
Keyboard
error.
Pointer and Device Button Actions
The XKB extension optionally allows clients to assign any key action (see
XKB implementations are required to support actions for the buttons of the core
pointer device, but support for actions on extension devices is optional.
Implementations which do not support button actions for extension devices must
not set the
XkbXI_ButtonActions
flag.
Attempts to query or assign button actions with an implementation that does not
support this feature report failure in the request reply and might cause the
server to send an
XkbExtensionDeviceNotify
event to the client which issued the request that failed. Such requests never
cause an error condition.
Indicator Maps for Extension Devices
The XKB extension allows applications to assign indicator maps to the
indicators of non-keyboard extension devices. If supported, maps can be
assigned to all extension device indicators, whether they are part of a
keyboard feedback or part of an indicator feedback.
Implementations which do not support indicator maps for extension devices must
not set the
XkbXI_IndicatorMaps
flag.
Attempts to query or assign indicator maps with an implementation that does not
support this feature report failure in the request reply and might cause the
server to send an
XkbExtensionDeviceNotify
event to the client which issued the request that failed. Such requests never
cause an error condition.
If this feature is supported, the maps for the default indicators on the core
keyboard device are visible both as extension indicators and as the core
indicators. Changes made with
XkbSetDeviceInfo
are visible via
XkbGetIndicatorMap
and changes made with
XkbSetIndicatorMap
are visible via
XkbGetDeviceInfo
.
Indicator Names for Extension Devices
The XKB extension allows applications to assign symbolic names to the
indicators of non-keyboard extension devices. If supported, symbolic names can
be assigned to all extension device indicators, whether they are part of a
keyboard feedback or part of an indicator feedback.
Implementations which do not support indicator maps for extension devices must
not set the
XkbXI_IndicatorMaps
flag.
Attempts to query or assign indicator names with an implementation that does
not support this feature report failure in the request reply and might cause
the server to send an
XkbExtensionDeviceNotify
event to the client which issued the request that failed. Such requests never
cause an error condition.
If this feature is supported, the names for the default indicators on the core
keyboard device are visible both as extension indicators and as the core
indicators. Changes made with
XkbSetDeviceInfo
are visible via
XkbGetNames
and changes made with
XkbSetNames
are visible via
XkbGetDeviceInfo
.
xorgproto-2023.2/specs/kbproto/XKBproto-11.svg 0000644 0001750 0001750 00000366072 14443010026 016043 0000000 0000000
image/svg+xml
<ESC> <FK01> <FK02> <FK03> <FK04> <FK05> <FK06> <FK07> <FK08>
<AE12> <TAB> <CAPS> <LFSH> <AE01> <AD01> <AC01> <AB01> <TLDE> <AE02> <AD02> <AC02> <AB02> <INS> <AE03> <AD03> <AC03> <AB03> <LEFT> <AE04> <AD04> <AC04> <AB04> <RGHT> <AE05> <AD05> <AC05> <AB05>
<FK09> <FK10> <FK11> <FK12> <PRSC> <SCLK> <PAUS> <FK16> <FK17>
<AE06> <AD06> <AC06> <AB06> <NMLK> <AE07> <KP7> <AD07> <KP4> <AC07> <KP1> <AB07> <UP> <KPEQ> <AE08> <KP8> <AD08> <KP5> <AC08> <KP2> <AB08> <DOWN> <KPSL> <AE09> <KP9> <AD09> <KP6> <AC09> <KP3> <AB09> <AD11> <KPMU> <AE10> <KPSU> <AD10> <KPAD> <AC10> <KPEN> <AB10> <AD12> <KPEN> <AE11> <BKSL> <AC11> <RTSH>
<RALT>
<PGUP>
<PGDN>
<RCTL>
<RTRN>
<KP0> <SPCE>
<LALT>
<HOME>
<END>
<LCTL>
<DELE>
<BKSP>
xorgproto-2023.2/specs/kbproto/ch01.xml 0000644 0001750 0001750 00000007533 14443010026 014642 0000000 0000000
Overview
This extension provides a number of new capabilities and controls for
text keyboards.
The core X protocol specifies the ways that the
Shift
,
Control
and
Lock
modifiers and the modifiers bound to the
Mode_switch
or
Num_Lock
keysyms interact to generate keysyms and characters. The core protocol also
allows users to specify that a key affects one or more modifiers. This behavior
is simple and fairly flexible, but it has a number of limitations that make it
difficult or impossible to properly support many common varieties of keyboard
behavior. The limitations of core protocol support for keyboards include:
Use of a single, uniform, four-symbol mapping for all keyboard keys
makes it difficult to properly support keyboard overlays, PC-style break keys
or keyboards that comply with ISO9995 or a host of other national and
international standards.
Use of a modifier to specify a second keyboard group has side-effects
that wreak havoc with client grabs and X toolkit translations and limit us to
two keyboard groups.
Poorly specified locking key behavior requires X servers to look for a
few "magic" keysyms to determine which keys should lock when pressed. This
leads to incompatibilities between X servers with no way for clients to detect
implementation differences.
Poorly specified capitalization and control behavior requires
modifications to X library source code to support new character sets or locales
and can lead to incompatibilities between system-wide and X library
capitalization behavior.
Limited interactions between modifiers specified by the core protocol
make many common keyboard behaviors difficult or impossible to implement. For
example, there is no reliable way to indicate whether or not using shift should
"cancel" the lock modifier.
The lack of any explicit descriptions for indicators, most modifiers
and other aspects of the keyboard appearance requires clients that wish to
clearly describe the keyboard to a user to resort to a mishmash of prior
knowledge and heuristics.
This extension makes it possible to clearly and explicitly specify most aspects
of keyboard behavior on a per-key basis. It adds the notion of a numeric
keyboard group to the global keyboard state and provides mechanisms to more
closely track the logical and physical state of the keyboard. For keyboard
control clients, this extension provides descriptions and symbolic names for
many aspects of keyboard appearance and behavior. It also includes a number of
keyboard controls designed to make keyboards more accessible to people with
movement impairments.
The X Keyboard Extension essentially replaces the core protocol definition of a
keyboard. The following sections describe the new capabilities of the extension
and the effect of the extension on core protocol requests, events and errors.
Conventions and Assumptions
This document uses the syntactic
conventions, common types, and errors defined in sections two through four of
the specification of the X Window System Protocol. This document assumes
familiarity with the fundamental concepts of X, especially those related to the
way that X handles keyboards. Readers who are not familiar with the meaning or
use of keycodes, keysyms or modifiers should consult (at least) the first five
chapters of the protocol specification of the X Window System before
continuing.
xorgproto-2023.2/specs/kbproto/XKBproto-5.svg 0000644 0001750 0001750 00000065156 14443010026 015765 0000000 0000000
image/svg+xml
xorgproto-2023.2/specs/bigreqsproto/ 0000755 0001750 0001750 00000000000 14443010036 014476 5 0000000 0000000 xorgproto-2023.2/specs/bigreqsproto/Makefile.am 0000644 0001750 0001750 00000000510 14443010026 016445 0000000 0000000
if ENABLE_SPECS
# Main DocBook/XML files (DOCTYPE book)
docbook = bigreq.xml
# The location where the DocBook/XML files and their generated formats are installed
shelfdir = $(datarootdir)/doc/bigreqsproto
# Generate DocBook/XML output formats with or without stylesheets
include $(top_srcdir)/docbook.am
endif ENABLE_SPECS
xorgproto-2023.2/specs/bigreqsproto/bigreq.xml 0000644 0001750 0001750 00000030466 14443010026 016421 0000000 0000000
%defs;
]>
Big Requests Extension
X Consortium Standard
X Version 11, Release &fullrelvers;
Version 2.0
Bob Scheifler
X Consortium
1993 1994 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 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.
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.
X Window System is a trademark of The Open Group.
Overview
This extension enables the use of protocol requests that exceed 262140 bytes in length.
The core protocol restricts the maximum length of a protocol request to 262140 bytes, in that it uses a 16-bit length field specifying the number of 4-byte units in the request. This is a problem in the core protocol when joining large numbers of lines (PolyLine ) or arcs (PolyArc ), since these requests cannot be broken up into smaller requests without disturbing the rendering of the join points. It is also much more of a problem for protocol extensions, such as the PEX extension for 3D graphics and the XIE extension for imaging, that need to send long data lists in output commands.
This extension defines a mechanism for extending the length field beyond 16 bits. If the normal 16-bit length field of the protocol request is zero, then an additional 32-bit field containing the actual length (in 4-byte units) is inserted into the request, immediately following the 16-bit length field.
For example, a normal PolyLine encoding is:
PolyLine
1
65
opcode
1
coordinate-mode
0
Origin
1
Previous
2
3+n
4
DRAWABLE
drawable
4
GCONTEXT
gc
4n
LISTofPOINT
points
An extended-length PolyLine encoding is:
PolyLine
1
65
opcode
1
coordinate-mode
0
Origin
1
Previous
2
0
extended length flag
4
4+n
request length
4
DRAWABLE
drawable
4
GCONTEXT
gc
4n
LISTofPOINT
points
Extended-length protocol encodings, once enabled, can be used on all protocol requests, including all extensions.
Requests
BigReqEnable =>
maximum-request-length : CARD32This request enables extended-length protocol requests for the requesting client. It also returns the maximum length of a request, in 4-byte units, that can be used in extended-length protocol requests. This value will always be greater than the maximum-request-length returned in the connection setup information.
Events and Errors
No new events or errors are defined by this extension.
Encoding
Please refer to the X11 Protocol Encoding document as this document uses conventions established there.
The name of this extension is “BIG-REQUESTS”.
BigReqEnable
1
Card8
opcode
1
0
bigreq opcode
2
1
request length
=>
1
1
Reply
1
unused
2
CARD16
sequence number
4
0
length
4
CARD32
maximum-request-length
20
unused
C language binding
It is desirable for core Xlib, and other extensions, to use this extension internally when necessary. It is also desirable to make the use of this extension as transparent as possible to the X client. For example, if enabling of the extension were delayed until the first time it was needed, an application that used
XNextRequest XOpenDisplay
The core Xlib functions
XDrawLines XDrawArcs XFillPolygon XChangeProperty XSetClipRectangles XSetRegion XDrawPoints XDrawRectangles XDrawSegments XFillArcs XFillRectangles XPutImage
To permit clients to know what the maximum-request-length for extended-length encodings is, the following function is added to Xlib:
long XExtendedMaxRequestSize
Display *display
Returns zero (0) if the specified display does not support this extension, otherwise returns the maximum-request-length (in 4-byte units) supported by the server through the extended-length encoding.
Acknowledgements
Clive Feather (IXI) originated the extended-length encoding used in this extension proposal.
xorgproto-2023.2/specs/bigreqsproto/Makefile.in 0000644 0001750 0001750 00000055451 14443010031 016470 0000000 0000000 # Makefile.in generated by automake 1.16.5 from Makefile.am.
# @configure_input@
# Copyright (C) 1994-2021 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
@SET_MAKE@
#
# Generate output formats for a single DocBook/XML with/without chapters
#
# Variables set by the calling Makefile:
# shelfdir: the location where the docs/specs are installed. Typically $(docdir)
# docbook: the main DocBook/XML file, no chapters, appendix or image files
# chapters: all files pulled in by an XInclude statement and images.
#
#
# This makefile is intended for Users Documentation and Functional Specifications.
# Do not use for Developer Documentation which is not installed and does not require olink.
# Refer to http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html#id2584393
# for an explanation on documents classification.
#
VPATH = @srcdir@
am__is_gnu_make = { \
if test -z '$(MAKELEVEL)'; then \
false; \
elif test -n '$(MAKE_HOST)'; then \
true; \
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
else \
false; \
fi; \
}
am__make_running_with_option = \
case $${target_option-} in \
?) ;; \
*) echo "am__make_running_with_option: internal error: invalid" \
"target option '$${target_option-}' specified" >&2; \
exit 1;; \
esac; \
has_opt=no; \
sane_makeflags=$$MAKEFLAGS; \
if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
else \
case $$MAKEFLAGS in \
*\\[\ \ ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
esac; \
fi; \
skip_next=no; \
strip_trailopt () \
{ \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
}; \
for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
*=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
-*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
-*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
-*l?*) strip_trailopt 'l';; \
-[dEDm]) skip_next=yes;; \
-[JT]) skip_next=yes;; \
esac; \
case $$flg in \
*$$target_option*) has_opt=yes; break;; \
esac; \
done; \
test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_1 = $(docbook:.xml=.html)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@am__append_2 = $(docbook:.xml=.txt)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_3 = $(docbook:.xml=.pdf) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(docbook:.xml=.ps)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@am__append_4 = $(docbook:.xml=.html.db) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(docbook:.xml=.pdf.db)
subdir = specs/bigreqsproto
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(am__dist_shelf_DATA_DIST) \
$(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
AM_V_P = $(am__v_P_@AM_V@)
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
am__v_P_0 = false
am__v_P_1 = :
AM_V_GEN = $(am__v_GEN_@AM_V@)
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
am__v_GEN_0 = @echo " GEN " $@;
am__v_GEN_1 =
AM_V_at = $(am__v_at_@AM_V@)
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
am__v_at_0 = @
am__v_at_1 =
SOURCES =
DIST_SOURCES =
am__can_run_installinfo = \
case $$AM_UPDATE_INFO_DIR in \
n|no|NO) false;; \
*) (install-info --version) >/dev/null 2>&1;; \
esac
am__dist_shelf_DATA_DIST = bigreq.xml
am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
am__vpath_adj = case $$p in \
$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
*) f=$$p;; \
esac;
am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
am__install_max = 40
am__nobase_strip_setup = \
srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
am__nobase_strip = \
for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
am__nobase_list = $(am__nobase_strip_setup); \
for p in $$list; do echo "$$p $$p"; done | \
sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
$(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
if (++n[$$2] == $(am__install_max)) \
{ print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
END { for (dir in files) print dir, files[dir] }'
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
am__uninstall_files_from_dir = { \
test -z "$$files" \
|| { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
|| { echo " ( cd '$$dir' && rm -f" $$files ")"; \
$(am__cd) "$$dir" && rm -f $$files; }; \
}
am__installdirs = "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"
DATA = $(dist_shelf_DATA) $(shelf_DATA)
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
am__DIST_COMMON = $(srcdir)/Makefile.in $(top_srcdir)/docbook.am
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
ADMIN_MAN_DIR = @ADMIN_MAN_DIR@
ADMIN_MAN_SUFFIX = @ADMIN_MAN_SUFFIX@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
APP_MAN_DIR = @APP_MAN_DIR@
APP_MAN_SUFFIX = @APP_MAN_SUFFIX@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BASE_CFLAGS = @BASE_CFLAGS@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CHANGELOG_CMD = @CHANGELOG_CMD@
CPPFLAGS = @CPPFLAGS@
CSCOPE = @CSCOPE@
CTAGS = @CTAGS@
CWARNFLAGS = @CWARNFLAGS@
CYGPATH_W = @CYGPATH_W@
DEFS = @DEFS@
DEPDIR = @DEPDIR@
DRIVER_MAN_DIR = @DRIVER_MAN_DIR@
DRIVER_MAN_SUFFIX = @DRIVER_MAN_SUFFIX@
ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
ETAGS = @ETAGS@
EXEEXT = @EXEEXT@
FILE_MAN_DIR = @FILE_MAN_DIR@
FILE_MAN_SUFFIX = @FILE_MAN_SUFFIX@
FOP = @FOP@
INSTALL = @INSTALL@
INSTALL_CMD = @INSTALL_CMD@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIB_MAN_DIR = @LIB_MAN_DIR@
LIB_MAN_SUFFIX = @LIB_MAN_SUFFIX@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAN_SUBSTS = @MAN_SUBSTS@
MISC_MAN_DIR = @MISC_MAN_DIR@
MISC_MAN_SUFFIX = @MISC_MAN_SUFFIX@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
PKG_CONFIG = @PKG_CONFIG@
PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
PYTHON = @PYTHON@
PYTHON_EXEC_PREFIX = @PYTHON_EXEC_PREFIX@
PYTHON_PLATFORM = @PYTHON_PLATFORM@
PYTHON_PREFIX = @PYTHON_PREFIX@
PYTHON_VERSION = @PYTHON_VERSION@
SED = @SED@
SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
STRICT_CFLAGS = @STRICT_CFLAGS@
STRIP = @STRIP@
STYLESHEET_SRCDIR = @STYLESHEET_SRCDIR@
USE_FDS_BITS = @USE_FDS_BITS@
VERSION = @VERSION@
XMLTO = @XMLTO@
XORG_MAN_PAGE = @XORG_MAN_PAGE@
XORG_SGML_PATH = @XORG_SGML_PATH@
XSLTPROC = @XSLTPROC@
XSL_STYLESHEET = @XSL_STYLESHEET@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build = @build@
build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
pkgpyexecdir = @pkgpyexecdir@
pkgpythondir = @pkgpythondir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
pyexecdir = @pyexecdir@
pythondir = @pythondir@
runstatedir = @runstatedir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
# Main DocBook/XML files (DOCTYPE book)
@ENABLE_SPECS_TRUE@docbook = bigreq.xml
# The location where the DocBook/XML files and their generated formats are installed
@ENABLE_SPECS_TRUE@shelfdir = $(datarootdir)/doc/bigreqsproto
# DocBook/XML generated output formats to be installed
@ENABLE_SPECS_TRUE@shelf_DATA = $(am__append_1) $(am__append_2) \
@ENABLE_SPECS_TRUE@ $(am__append_3) $(am__append_4)
# DocBook/XML file with chapters, appendix and images it includes
@ENABLE_SPECS_TRUE@dist_shelf_DATA = $(docbook) $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_OLINK_FLAGS)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_PDF_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_IMAGEPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_PDF_OLINK_FLAGS)
# Generate documents cross-reference target databases
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam targets.filename "$@" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam collect.xref.targets "only" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam olink.base.uri "$(@:.db=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_PDF_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@CLEANFILES = $(shelf_DATA)
all: all-am
.SUFFIXES:
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/docbook.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign specs/bigreqsproto/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign specs/bigreqsproto/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
*config.status*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
*) \
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \
esac;
$(top_srcdir)/docbook.am $(am__empty):
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(top_srcdir)/configure: $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
install-dist_shelfDATA: $(dist_shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-dist_shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
install-shelfDATA: $(shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
tags TAGS:
ctags CTAGS:
cscope cscopelist:
distdir: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) distdir-am
distdir-am: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
all-am: Makefile $(DATA)
installdirs:
for dir in "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"; do \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-am
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
mostlyclean-generic:
clean-generic:
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
clean: clean-am
clean-am: clean-generic mostlyclean-am
distclean: distclean-am
-rm -f Makefile
distclean-am: clean-am distclean-generic
dvi: dvi-am
dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am: install-dist_shelfDATA install-shelfDATA
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
-rm -f Makefile
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-generic
pdf: pdf-am
pdf-am:
ps: ps-am
ps-am:
uninstall-am: uninstall-dist_shelfDATA uninstall-shelfDATA
.MAKE: install-am install-strip
.PHONY: all all-am check check-am clean clean-generic cscopelist-am \
ctags-am distclean distclean-generic distdir dvi dvi-am html \
html-am info info-am install install-am install-data \
install-data-am install-dist_shelfDATA install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-shelfDATA install-strip installcheck installcheck-am \
installdirs maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-generic pdf pdf-am ps ps-am tags-am \
uninstall uninstall-am uninstall-dist_shelfDATA \
uninstall-shelfDATA
.PRECIOUS: Makefile
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.html: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@%.txt: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.pdf: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.ps: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.html.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_HTML_FLAGS) $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.pdf.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_PDF_FLAGS) $<
# Generate DocBook/XML output formats with or without stylesheets
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
xorgproto-2023.2/specs/recordproto/ 0000755 0001750 0001750 00000000000 14443010036 014320 5 0000000 0000000 xorgproto-2023.2/specs/recordproto/record.xml 0000644 0001750 0001750 00000167233 14443010026 016253 0000000 0000000
%defs;
]>
Record Extension Protocol Specification
X Consortium Standard
Martha Zimet
Network Computing Devices, Inc.
Stephen Gildea
X Consortium
X Version 11, Release &fullrelvers;
1994 Network Computing Devices, Inc.
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.
Copyright © 1994, 1995 X Consortium
Permission is hereby granted, free of charge, to any person obtaining
a copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE 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.
Except as contained in this notice, the name of the X Consortium and
shall not be used in advertising or otherwise to promote the sale, use
or other dealings in this Software without prior written authorization
from the X Consortium.
X Window System is a trademark of The Open Group.
Introduction
Several proposals have been written over the past few years that address some
of the issues surrounding the recording and playback of user actions
in the X Window System
X Window System is a trademark of The Open Group.
Some Proposals for a Minimal X11 Testing Extension ,
Kieron Drake, UniSoft Ltd., April 1991
X11 Input Synthesis Extension Proposal , Larry Woestman,
Hewlett Packard, November 1991
XTrap Architecture , Dick Annicchiario, et al, Digital Equipment Corporation,
July 1991
XTest Extension Recording Specification , Yochanan Slonim,
Mercury Interactive, December 1992
This document both unifies and extends the previous diverse approaches
to generate a proposal for an X extension that provides support for
the recording of all core X protocol and arbitrary extension protocol.
Input synthesis, or playback, has already been implemented in the
XTest extension, an X Consortium standard. Therefore, this extension
is limited to recording.
In order to provide both record and playback functionality, a
hypothetical record application could use this extension to capture
both user actions and their consequences. For example, a button press
(a user action) may cause a window to be mapped and a corresponding
MapNotify
event to be sent (a consequence). This information could be
stored for later use by a playback application.
The playback application could use the recorded actions as input for
the XTest extension's
XTestFakeInput
operation to synthesize the
appropriate input events. The "consequence" or synchronization
information is then used as a synchronization point during playback.
That is, the playback application does not generate specific
synthesized events until their matching synchronization condition
occurs. When the condition occurs the processing of synthesized
events continues. Determination that the condition has occurred may be
made by capturing the consequences of the synthesized events and
comparing them to the previously recorded synchronization information.
For example, if a button press was followed by a
MapNotify
event on a
particular window in the recorded data, the playback application might
synthesize the button press then wait for the
MapNotify
event on the
appropriate window before proceeding with subsequent synthesized
input.
Because
it is impossible to predict what synchronization information will be
required by a particular application, the extension provides
facilities to record any subset of core X protocol and arbitrary
extension protocol.
As such, this extension does not enforce a specific
synchronization methodology; any method based on information in the X
protocol stream (e.g., watching for window mapping/unmapping, cursor
changes, drawing of certain text strings, etc.) can capture the
information it needs using RECORD facilities.
Acknowledgements
The document represents the culmination of two years of debate and
experiments done under the auspices of the X Consortium xtest working
group. Although this was a group effort, the author remains
responsible for any errors or omissions.
Two years ago, Robert Chesler of Absol-puter, Kieron Drake of UniSoft
Ltd., Marc Evans of Synergytics and Ken Miller of Digital shared the
vision of a standard extension for recording and were all instrumental
in the early protocol development. During the last two years, Bob
Scheifler of the X Consortium and Jim Fulton of NCD continuously
provided input to the protocol design, as well as encouragement to the
author. In the last few months, Stephen Gildea and Dave Wiggins,
both X Consortium staff, have spent considerable time fine tuning the
protocol design and reviewing the protocol specifications. Most
recently, Amnon Cohen of Mercury Interactive has assisted in
clarification of the recorded event policy, and Kent Siefkes of
Performance Awareness has assisted in clarification of the timestamp
policy.
Goals
To provide a standard for recording,
whereby both device events and synchronization information in the
form of device event consequences are recorded.
To record contextual information used in synchronized playback
without prior knowledge of the application
that
is being recorded.
To provide the ability to record arbitrary X protocol extensions.
Requirements
The extension should function as follows:
It should
not be dependent on other clients or extensions for its operation.
It should
not significantly impact performance.
It should
support the recording of all device input (core devices and XInput devices).
It should
be extendible.
It should
support the recording of synchronization information for user events.
Design
This section gives an overview of the RECORD extension and discusses
its overall operation and data types.
Overview
The mechanism used by this extension for recording is to intercept
core X protocol and arbitrary X extension protocol entirely within the X server
itself. When the extension has been requested to intercept specific
protocol by one or more clients, the protocol data are formatted and
returned to the recording clients.
The extension provides a mechanism for capturing all events, including
input device events that go to no clients, that is analogous to a client
expressing "interest" in all events in all windows, including the root
window. Event filtering in the extension provides a mechanism for feeding
device events to recording clients; it does not provide a mechanism for
in-place, synchronous event substitution, modification, or withholding.
In addition, the
extension does not provide data compression before intercepted protocol
is returned to the recording clients.
Data Delivery
Because
events are limited in size to
32 bytes, using events to return intercepted protocol data to recording
clients is prohibitive in terms of performance. Therefore, intercepted
protocol data are returned to recording clients through multiple replies
to the extension request to begin protocol interception and reporting.
This utilization is consistent with
ListFontsWithInfo ,
for example, where a
single request has multiple replies.
Individual requests, replies, events or errors intercepted by the extension
on behalf of recording clients cannot be split across reply packets. In order
to reduce overhead, multiple intercepted requests, replies, events and errors
might be collected
into a single reply.
Nevertheless, all data are returned to the client in a timely manner.
Record Context
The extension adds a record context resource (RC)
to the set of resources managed by the server. All the
extension operations take an RC as an argument. Although the protocol
permits sharing of RCs between clients, it is expected that clients will
use their own RCs. The attributes used in extension operations are stored
in the RCs, and these attributes include the protocol and clients to
intercept.
The terms "register" and "unregister" are used to describe the
relationship between clients to intercept and the RC. To register
a client with an RC means the client is added to the list
of clients to intercept; to unregister a client means the client
is deleted from the list of clients to intercept. When the
server is requested to register or unregister clients from an RC,
it is required to do so immediately. That is, it is not permissible for
the server to wait until recording is enabled to register clients
or recording is disabled to unregister clients.
Record Client Connections
The typical communication model for a recording client is to open
two connections to the server and use one for RC control and
the other for reading protocol data.
The "control" connection can execute requests to obtain information about
the supported protocol version, create and destroy RCs, specify protocol
types to intercept and clients to be recorded, query the current state
of an RC, and to stop interception and reporting of protocol data. The
"data" connection can execute a request to
enable interception
and reporting of specified protocol for a particular RC. When the
"enable" request is issued, intercepted protocol is sent back on the
same connection, generally in more than one reply packet. Until the last
reply to the "enable" request is sent by the server, signifying that
the request execution is complete, no other requests will be executed by
the server on that connection. That is, the connection that data are being
reported on cannot issue the "disable" request until the last reply
to the "enable" request is sent by the server. Therefore, unless a
recording client never has the need to disable the interception and reporting
of protocol data, two client connections are necessary.
Events
The terms "delivered events" and "device events" are used
to describe the two event classes recording clients may
select for interception. These event classes are handled differently
by the extension. Delivered events are core X events or X extension events
the server actually delivers to one or more clients. Device events are
events generated by core X devices or extension input devices that the
server may or may not deliver to any clients. When device events
are selected for interception by a recording client, the extension
guarantees each device event is recorded and will be forwarded
to the recording client in the same order it is generated by the
device.
The recording of selected device events is not affected
by server grabs. Delivered events, on the other hand, can be affected
by server grabs.
If a recording client selects both
a device event and delivered events that result from that device
event, the delivered events are recorded after the device event.
In the absence of grabs, the delivered events for a
device event precede later device events.
Requests that have side effects on
devices, such as
WarpPointer
and
GrabPointer
with a confine-to window,
will cause RECORD to record an associated device event.
The XTEST extension request
XTestFakeInput
causes a device event to be recorded; the
device events are recorded in the same order that the
XTestFakeInput
requests are received by the server.
If a key autorepeats, multiple
KeyPress
and
KeyRelease
device events are reported.
Timing
Requests are recorded just before
they are executed; the time associated with a request is the server
time when it is recorded.
Types
The following new types are used in the request definitions that appear
in section 3.
RC: CARD32
The
"RC"
type is a resource identifier for a server record context.
RANGE8:
[first, last:
CARD8]
RANGE16:
[first, last:
CARD16]
EXTRANGE:
[major:
RANGE8
minor:
RANGE16]
RECORDRANGE:
[core-requests:
RANGE8
core-replies:
RANGE8
ext-requests:
EXTRANGE
ext-replies:
EXTRANGE
delivered-events:
RANGE8
device-events:
RANGE8
errors:
RANGE8
client-started:
BOOL
client-died:
BOOL]
The
"RECORDRANGE"
structure contains the protocol values to intercept. Typically,
this structure is sent by recording clients over the control connection
when creating or modifying an RC.
Specifies core X protocol requests with an opcode field between first
and last inclusive. If first is equal to 0 and last is equal to 0, no
core requests are specified by this RECORDRANGE. If first is greater
than last , a
"Value"
error results.
Specifies replies resulting from core X protocol requests with an opcode
field between first and last inclusive. If first is equal to 0 and last
is equal to 0, no core replies are specified by this RECORDRANGE. If
first is greater than last , a
"Value"
error results.
Specifies extension protocol requests with a major opcode field between
major.first and major.last and a minor opcode field between minor.first
and minor.last inclusive.
If major.first and major.last are equal to 0, no
extension protocol requests are specified by this RECORDRANGE. If
major.first or major.last is less than 128 and greater than 0,
if major.first is greater than major.last ,
or if minor.first
is greater than minor.last , a
"Value"
error results.
Specifies replies resulting from extension protocol requests with a
major opcode field between major.first and major.last and
a minor opcode field between minor.first and minor.last
inclusive. If major.first and major.last are equal to 0,
no extension protocol replies are specified by this RECORDRANGE. If
major.first or major.last is less than 128 and greater
than 0,
if major.first is greater than major.last ,
or if minor.first is greater than minor.last , a
"Value"
error results.
This is used for both core X protocol events and arbitrary extension
events. Specifies events that are delivered to at least one client
that have a code field between first and last
inclusive. If first is equal to 0 and last is equal to 0,
no events are specified by this RECORDRANGE.
Otherwise, if first is less than 2
or last is less than 2, or if
first is greater than last , a
"Value"
error results.
This is used for both core X device events and X extension device
events that may or may not be delivered to a client.
Specifies device events that have a code field between first and
last inclusive. If first is equal to 0 and last
is equal to 0, no device events are specified by this RECORDRANGE.
Otherwise,
if first is less than 2 or last is less
than 2, or if first is greater than last , a
"Value"
error results.
Because
the generated device event may or may not be associated with a
client, unlike other RECORDRANGE components, which select protocol for a
specific client, selecting for device events in any RECORDRANGE in an RC
causes the recording client to receive one instance for each device event
generated that is in the range specified.
This is used for both core X protocol errors and arbitrary extension
errors. Specifies errors that have a code field between first and
last inclusive. If first is equal to 0 and last is equal to 0, no
errors are specified by this RECORDRANGE. If first is greater
than last , a
"Value"
error results.
Specifies the connection setup reply.
If
False ,
the connection setup reply is not specified by
this RECORDRANGE.
Specifies notification when a client disconnects.
If
False ,
notification when a client disconnects is not specified by
this RECORDRANGE.
ELEMENT_HEADER:
[from-server-time:
BOOL
from-client-time:
BOOL
from-client-sequence:
BOOL]
The
ELEMENT_HEADER
structure specifies additional data that precedes each protocol
element in the data field of a
RecordEnableContext
reply.
If from-server-time is
True ,
each intercepted protocol element
with category
FromServer
is preceded by the server time when the protocol was recorded.
If from-client-time is
True ,
each intercepted protocol element
with category
FromClient
is preceded by the server time when the protocol was recorded.
If from-client-sequence is
True ,
each intercepted protocol
element with category
FromClient
or
ClientDied
is preceded by the
32-bit sequence number of the recorded client's most recent request
processed by the server at that time.
For
FromClient ,
this will be one less than the sequence number of the
following request.
For
ClientDied ,
the sequence number will be the only data, because no
protocol is recorded.
Note that a reply containing device events is treated the same as
other replies with category
FromServer
for purposes of these flags.
Protocol with category
FromServer
is never preceded by a sequence
number because almost all such protocol has a sequence number in it anyway.
If both a server time and a sequence number have been requested for a
reply, each protocol request is
preceded first by the time and second by the sequence number.
XIDBASE: CARD32
The XIDBASE type is used to identify a particular client. Valid
values are any existing resource identifier
of any connected client,
in which case the client
that created the resource is specified, or the resource identifier
base sent to the target client from the server in the connection setup
reply. A value of 0 (zero) is valid when the XIDBASE is associated
with device events that may not have been delivered to a client.
CLIENTSPEC: XIDBASE or {CurrentClients ,
FutureClients , AllClients }
The CLIENTSPEC type defines the set of clients the RC attributes are
associated with. This type is used by recording clients when creating
an RC or when changing RC attributes. XIDBASE specifies that the RC
attributes apply to a single client only.
CurrentClients
specifies
that the RC attributes apply to current client connections;
FutureClients
specifies future client connections;
AllClients
specifies all client connections, which includes current and future.
The numeric values for
CurrentClients ,
FutureClients
and
AllClients
are
defined such that there will be no intersection with valid XIDBASEs.
When the context is enabled, the data connection is unregistered if it
was registered.
If the context is enabled,
CurrentClients
and
AllClients
silently exclude the recording data connection.
It is an error to explicitly register the data connection.
CLIENT_INFO:
[client-resource:
CLIENTSPEC
intercepted-protocol:
LISTofRECORDRANGE]
This structure specifies an intercepted client and the protocol to be
intercepted for the client. The client-resource field is a
resource base that identifies the intercepted client. The
intercepted-protocol field specifies the protocol to intercept
for the client-resource .
Errors
RecordContext
This error is returned if the value for an RC argument
in a request does not name a defined record context.
Protocol Requests
RecordQueryVersion
major-version ,
minor-version : CARD16
->
major-version ,
minor-version : CARD16
This request specifies the RECORD extension protocol version the client
would like to use. When the specified protocol version is supported
by the extension, the protocol version the server expects from the
client is returned. Clients must use this request before other RECORD
extension requests.
This request also determines whether or not the RECORD extension protocol
version specified by the client is supported by the extension. If the
extension supports the version specified by the client, this version number
should be returned. If the client has requested a higher version than is
supported by the server, the server's highest version should be returned.
Otherwise, if the client has requested a lower version than is supported
by the server, the server's lowest version should be returned. This document
defines major version one (1),
minor version thirteen (13).
RecordCreateContext
context : RC
element-header : ELEMENT_HEADER
client-specifiers : LISTofCLIENTSPEC
ranges : LISTofRECORDRANGE
Errors:
Match ,
Value ,
IDChoice ,
Alloc
This request creates a new
record context
within the server and assigns the identifier context to
it. After the context is created, this request registers the
set of clients in client-specifiers with the context and
specifies the protocol to intercept for those clients.
The recorded protocol elements will be preceded by data as specified
by element-header .
Typically,
this request is used by a recording client over the control
connection. Multiple RC
objects can exist simultaneously, containing overlapping sets of
protocol and clients to intercept.
If any of the values in
element-header or
ranges is invalid, a
"Value"
error results. Duplicate items in the list of client-specifiers are
ignored. If any item in the client-specifiers list is not a valid
CLIENTSPEC, a
"Match"
error results. Otherwise, each item in the client-specifiers list is
processed as follows:
If the item is an XIDBASE identifying a particular client, the
specified client is registered with the context and the protocol
to intercept for the client is then set to ranges .
If the item is
CurrentClients ,
all existing clients are registered with the
context at this time.
The protocol to intercept for all clients registered
with the context is then set to ranges .
If the item is
FutureClients ,
all clients that connect to the server
after this request executes will be automatically registered with the
context . The protocol to intercept for such clients will be set to
ranges in the context .
If the item is
AllClients ,
the effect is as if the actions described
for
FutureClients
are performed, followed by the actions for
CurrentClients .
The
"Alloc"
error results when the server is unable to allocate the necessary
resources.
RecordRegisterClients
context : RC
element-header : ELEMENT_HEADER
client-specifiers : LISTofCLIENTSPEC
ranges : LISTofRECORDRANGE
Errors:
Match ,
Value ,
RecordContext ,
Alloc
This request registers the set of clients in client-specifiers with
the given context and specifies the protocol to intercept for those
clients.
The header preceding each recorded protocol element is set as specified
by element-header .
These flags affect the entire
context; their effect is not limited to the clients registered by
this request.
Typically, this request is used by a recording client over
the control connection.
If context does not name a valid RC, a
"RecordContext"
error results. If any of the values in
element-header or ranges is invalid, a
"Value"
error results. Duplicate items in the list of client-specifiers are
ignored. If any item in the list of client-specifiers is not a
valid CLIENTSPEC, a
"Match"
error results.
If the context is enabled and the XID of the enabling connection
is specified, a
"Match"
error results.
Otherwise, each item in the client-specifiers list is
processed as follows:
If the item is an XIDBASE identifying a particular client, the
specified client is registered with the context if it is not already
registered. The protocol to intercept for the client is then set to
ranges .
If the item is
CurrentClients ,
all existing clients that are not
already registered with the specified context ,
except the enabling connection if the context is enabled,
are registered at this
time. The protocol to intercept for all clients registered with the
context is then set to ranges .
If the item is
FutureClients ,
all clients that connect to the server
after this request executes will be automatically registered with the
context . The protocol to intercept for such clients will be set to
ranges in the context .
The set of clients that are registered with the
context and their corresponding sets
of protocol to intercept are left intact.
If the item is
AllClients ,
the effect is as if the actions described
for
FutureClients
are performed, followed by the actions for
CurrentClients .
The
"Alloc"
error results when the server is unable to allocate the necessary
resources.
RecordUnregisterClients
context : RC
client-specifiers : LISTofCLIENTSPEC
Errors:
Match ,
RecordContext
This request removes the set of clients in client-specifiers from the
given context 's set of registered clients. Typically, this request is
used by a recording client over the control connection.
If context does not name a valid RC, a
"RecordContext"
error results. Duplicate items in the list of client-specifiers are
ignored. If any item in the list is not a valid CLIENTSPEC, a
"Match"
error results. Otherwise, each item in the client-specifiers list is
processed as follows:
If the item is an XIDBASE identifying a particular client, and the
specified client is currently registered with the context , it is
unregistered, and the set of protocol to intercept for the client is
deleted from the context . If the specified client is not registered
with the context , the item has no effect.
If the item is
CurrentClients ,
all clients currently registered with
the context are unregistered from it, and their corresponding sets of
protocol to intercept are deleted from the context .
If the item is
FutureClients ,
clients that connect to the server after
this request executes will not automatically be registered with the
context . The set of clients that are registered with this context
and their corresponding sets of protocol that will be
intercepted are left intact.
If the item is
AllClients ,
the effect is as if the actions described
for
FutureClients
are performed, followed by the actions for
CurrentClients .
A client is unregistered automatically when it disconnects.
RecordGetContext
context : RC
->
enabled : BOOL
element-header : ELEMENT_HEADER
intercepted-clients : LISTofCLIENT_INFO
Errors:
RecordContext
This request queries the current state of the specified context
and is typically used by a recording client over the control connection.
The enabled field
specifies the state of data transfer between the extension and the
recording client, and is either enabled
( True )
or disabled
( False ).
The initial state is disabled.
When enabled, all core X protocol and
extension protocol received from (requests) or sent to (replies,
errors, events) a particular client, and requested to be intercepted
by the recording client, is reported to the recording client over the
data connection.
The element-header specifies the header that precedes each
recorded protocol element.
The
intercepted-clients field specifies the list of clients currently
being recorded and the protocol associated with each client.
If future clients will be automatically registered with the context,
one of the returned CLIENT_INFO structures has a client-resource value
of FutureClients and an intercepted-protocol giving the protocol to
intercept for future clients.
Protocol ranges may be decomposed, coalesced, or otherwise modified
by the server from how they were specified by the client.
All CLIENTSPECs registered with the server are returned, even if the
RECORDRANGE(s) associated with them specify no protocol to record.
When the context argument is not valid, a
RecordContext
error results.
RecordEnableContext
context : RC
->+
category :
{FromServer , FromClient ,
ClientStarted , ClientDied ,
StartOfData ,
EndOfData }
element-header : ELEMENT_HEADER
client-swapped : BOOL
id-base : XIDBASE
server-time : TIMESTAMP
recorded-sequence-number : CARD32
data : LISTofBYTE
Errors:
Match ,
RecordContext
This request enables data transfer between the recording client
and the extension and returns the protocol data the recording client
has previously expressed interest in. Typically, this request is
executed by the recording client over the data connection.
If the client is registered on the context , it is unregistered
before any recording begins.
Once the server receives this request, it begins intercepting
and reporting to the recording client all core and extension protocol
received from or sent to clients registered with the RC that the
recording client has expressed interest in. All intercepted protocol data
is returned in the byte-order of the recorded client. Therefore,
recording clients are responsible for all byte swapping, if required.
More than one recording client cannot enable data transfer on the
same RC at the same time. Multiple intercepted requests, replies,
events and errors might be packaged into a single reply before
being returned to the recording clients.
The
category field determines the possible
types of the data.
When a context is enabled, the server will immediately send a reply of
category
StartOfData
to notify the client that recording is enabled.
A category of
FromClient
means the data are from the client
(requests);
FromServer
means data are from the server (replies,
errors, events, or device events).
For a new client, the category is
ClientStarted
and the data are the connection setup reply.
When
the recorded client connection is closed, category is
set to the value
ClientDied
and no protocol is included in this reply.
When the disable request is made over the control connection,
a final reply is sent over the data connection with category
EndOfData
and no protocol.
The element-header field returns the value currently set for the
context, which tells what header information precedes each recorded
protocol element in this reply.
The client-swapped field is
True
if the byte order of
the protocol being recorded
is swapped
relative to the recording client;
otherwise, client-swapped is
False .
The recorded protocol
is in the byte order of the client being
recorded; device events are in the byte order of the
recording client.
For replies of category
StartOfData
and
EndOfData
the
client-swapped bit is set
according
to the byte order of the server relative to the recording client.
The id-base field is the resource identifier base
sent to the client from the server in the
connection setup reply, and hence, identifies the client being
recorded. The id-base field is 0 (zero) when the protocol
data being
returned are device events.
The server-time field is set to the time of the
server when the first protocol element in this reply was intercepted.
The server-time
of reply N+1 is greater than or equal to the server-time of reply N,
and is greater than or equal to the time of the last protocol
element in reply N.
The recorded-sequence-number field is set to the sequence number
of the recorded client's most recent request processed by the server.
The data field
contains the raw protocol data being returned to the recording client.
If requested by the element-header of this record context, each
protocol element may be preceded by a 32-bit timestamp and/or
a 32-bit sequence number.
If present, both the timestamp and sequence number are always in the
byte order of the recording client.
For the core X events
KeyPress ,
KeyRelease ,
ButtonPress ,
and
ButtonRelease ,
the fields of a device event that contain
valid information are time and detail .
For the core X event
MotionNotify ,
the fields of a device event that contain
valid information are time , root ,
root-x and root-y .
The time field refers to the time the event was generated by the
device.
For the extension input device events
DeviceKeyPress ,
DeviceKeyRelease ,
DeviceButtonPress ,
and
DeviceButtonRelease ,
the fields of a device event that contain valid information are
device , time and detail .
For
DeviceMotionNotify ,
the valid device event fields are
device and time .
For the extension input device events
ProximityIn
and
ProximityOut ,
the fields of a device event that contain valid
information are device and time .
For the extension input device event
DeviceValuator ,
the fields of a device event that contain valid information are
device ,
num_valuators , first_valuator , and valuators .
The time field refers to the time the event was generated by the
device.
The error
"Match"
is returned when data transfer is already enabled.
When the context argument is not valid, a
RecordContext
error results.
RecordDisableContext
context : RC
Errors:
RecordContext
This request is typically executed by the recording client over the
control connection. This request directs the extension to immediately
send any complete protocol elements currently buffered,
to send a final reply with category
EndOfData ,
and to discontinue
data transfer between the extension and the recording client.
Protocol reporting is disabled
on the data connection that is currently enabled for the given
context . Once the extension completes
processing this request, no additional recorded protocol will
be reported to the recording client. If a data connection is not
currently enabled when this request is executed, then this request has
no affect on the state of data transfer.
An RC is disabled automatically when the connection to the enabling
client is closed down.
When the context argument is not valid, a
RecordContext
error results.
RecordFreeContext
context RC
Errors:
RecordContext
This request deletes the association between the resource ID and the
RC and destroys the RC.
If a client has enabled data transfer on this context , the actions
described in
RecordDisableContext
are performed before the context
is freed.
An RC is destroyed automatically when the connection to the creating client
is closed down and the close-down mode is DestroyAll . When the
context argument is not valid, a
RecordContext
error results.
Encoding
Please refer to the X11 Protocol Encoding document as this document uses
conventions established there.
The name of this extension is "RECORD".
Types
RC: CARD32
RANGE8
1 CARD8 first
1 CARD8 last
RANGE16
2 CARD16 first
2 CARD16 last
EXTRANGE
2 RANGE8 major
4 RANGE16 minor
RECORDRANGE
2 RANGE8 core-requests
2 RANGE8 core-replies
6 EXTRANGE ext-requests
6 EXTRANGE ext-replies
2 RANGE8 delivered-events
2 RANGE8 device-events
2 RANGE8 errors
1 BOOL client-started
1 BOOL client-died
ELEMENT_HEADER
1 CARD8
0x01 from-server-time
0x02 from-client-time
0x04 from-client-sequence
XIDBASE: CARD32
CLIENTSPEC
4 XIDBASE client-id-base
1 CurrentClients
2 FutureClients
3 AllClients
CLIENT_INFO
4 CLIENTSPEC client-resource
4 CARD32 n, number of record ranges in
intercepted-protocol
24n LISTofRECORDRANGE intercepted-protocol
Errors
RecordContext
1 0 Error
1 CARD8 extension's base error code + 0
2 CARD16 sequence number
4 CARD32 invalid record context
24 unused
Requests
RecordQueryVersion
1 CARD8 major opcode
1 0 minor opcode
2 2 request length
2 CARD16 major version
2 CARD16 minor version
=>
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 major version
2 CARD16 minor version
20 unused
RecordCreateContext
1 CARD8 major opcode
1 1 minor opcode
2 5+m+6n request length
4 RC context
1 ELEMENT_HEADER element-header
3 unused
4 CARD32 m, number of client-specifiers
4 CARD32 n, number of ranges
4m LISTofCLIENTSPEC client-specifiers
24n LISTofRECORDRANGE ranges
RecordRegisterClients
1 CARD8 major opcode
1 2 minor opcode
2 5+m+6n request length
4 RC context
1 ELEMENT_HEADER element-header
3 unused
4 CARD32 m, number of client-specifiers
4 CARD32 n, number of ranges
4m LISTofCLIENTSPEC client-specifiers
24n LISTofRECORDRANGE ranges
RecordUnregisterClients
1 CARD8 major opcode
1 3 minor opcode
2 3+m request length
4 RC context
4 CARD32 m, number of client-specifiers
4m LISTofCLIENTSPEC client-specifiers
RecordGetContext
1 CARD8 major opcode
1 4 minor opcode
2 2 request length
4 RC context
=>
1 1 Reply
1 BOOL enabled
2 CARD16 sequence number
4 j reply length
1 ELEMENT_HEADER element-header
3 unused
4 CARD32 n, number of intercepted-clients
16 unused
4j LISTofCLIENT_INFO intercepted-clients
RecordEnableContext
1 CARD8 major opcode
1 5 minor opcode
2 2 request length
4 RC context
=>+
1 1 Reply
1 category
0 FromServer
1 FromClient
2 ClientStarted
3 ClientDied
4 StartOfData
5 EndOfData
2 CARD16 sequence number
4 n reply length
1 ELEMENT_HEADER element-header
1 BOOL client-swapped
2 unused
4 XIDBASE id-base
4 TIMESTAMP server-time
4 CARD32 recorded-sequence-number
8 unused
4n BYTE data
RecordDisableContext
1 CARD8 major opcode
1 6 minor opcode
2 2 request length
4 RC context
RecordFreeContext
1 CARD8 major opcode
1 7 minor opcode
2 2 request length
4 RC context
xorgproto-2023.2/specs/recordproto/Makefile.am 0000644 0001750 0001750 00000000507 14443010026 016275 0000000 0000000
if ENABLE_SPECS
# Main DocBook/XML files (DOCTYPE book)
docbook = record.xml
# The location where the DocBook/XML files and their generated formats are installed
shelfdir = $(datarootdir)/doc/recordproto
# Generate DocBook/XML output formats with or without stylesheets
include $(top_srcdir)/docbook.am
endif ENABLE_SPECS
xorgproto-2023.2/specs/recordproto/Makefile.in 0000644 0001750 0001750 00000055445 14443010031 016315 0000000 0000000 # Makefile.in generated by automake 1.16.5 from Makefile.am.
# @configure_input@
# Copyright (C) 1994-2021 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
@SET_MAKE@
#
# Generate output formats for a single DocBook/XML with/without chapters
#
# Variables set by the calling Makefile:
# shelfdir: the location where the docs/specs are installed. Typically $(docdir)
# docbook: the main DocBook/XML file, no chapters, appendix or image files
# chapters: all files pulled in by an XInclude statement and images.
#
#
# This makefile is intended for Users Documentation and Functional Specifications.
# Do not use for Developer Documentation which is not installed and does not require olink.
# Refer to http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html#id2584393
# for an explanation on documents classification.
#
VPATH = @srcdir@
am__is_gnu_make = { \
if test -z '$(MAKELEVEL)'; then \
false; \
elif test -n '$(MAKE_HOST)'; then \
true; \
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
else \
false; \
fi; \
}
am__make_running_with_option = \
case $${target_option-} in \
?) ;; \
*) echo "am__make_running_with_option: internal error: invalid" \
"target option '$${target_option-}' specified" >&2; \
exit 1;; \
esac; \
has_opt=no; \
sane_makeflags=$$MAKEFLAGS; \
if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
else \
case $$MAKEFLAGS in \
*\\[\ \ ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
esac; \
fi; \
skip_next=no; \
strip_trailopt () \
{ \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
}; \
for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
*=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
-*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
-*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
-*l?*) strip_trailopt 'l';; \
-[dEDm]) skip_next=yes;; \
-[JT]) skip_next=yes;; \
esac; \
case $$flg in \
*$$target_option*) has_opt=yes; break;; \
esac; \
done; \
test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_1 = $(docbook:.xml=.html)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@am__append_2 = $(docbook:.xml=.txt)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_3 = $(docbook:.xml=.pdf) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(docbook:.xml=.ps)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@am__append_4 = $(docbook:.xml=.html.db) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(docbook:.xml=.pdf.db)
subdir = specs/recordproto
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(am__dist_shelf_DATA_DIST) \
$(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
AM_V_P = $(am__v_P_@AM_V@)
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
am__v_P_0 = false
am__v_P_1 = :
AM_V_GEN = $(am__v_GEN_@AM_V@)
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
am__v_GEN_0 = @echo " GEN " $@;
am__v_GEN_1 =
AM_V_at = $(am__v_at_@AM_V@)
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
am__v_at_0 = @
am__v_at_1 =
SOURCES =
DIST_SOURCES =
am__can_run_installinfo = \
case $$AM_UPDATE_INFO_DIR in \
n|no|NO) false;; \
*) (install-info --version) >/dev/null 2>&1;; \
esac
am__dist_shelf_DATA_DIST = record.xml
am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
am__vpath_adj = case $$p in \
$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
*) f=$$p;; \
esac;
am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
am__install_max = 40
am__nobase_strip_setup = \
srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
am__nobase_strip = \
for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
am__nobase_list = $(am__nobase_strip_setup); \
for p in $$list; do echo "$$p $$p"; done | \
sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
$(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
if (++n[$$2] == $(am__install_max)) \
{ print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
END { for (dir in files) print dir, files[dir] }'
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
am__uninstall_files_from_dir = { \
test -z "$$files" \
|| { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
|| { echo " ( cd '$$dir' && rm -f" $$files ")"; \
$(am__cd) "$$dir" && rm -f $$files; }; \
}
am__installdirs = "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"
DATA = $(dist_shelf_DATA) $(shelf_DATA)
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
am__DIST_COMMON = $(srcdir)/Makefile.in $(top_srcdir)/docbook.am
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
ADMIN_MAN_DIR = @ADMIN_MAN_DIR@
ADMIN_MAN_SUFFIX = @ADMIN_MAN_SUFFIX@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
APP_MAN_DIR = @APP_MAN_DIR@
APP_MAN_SUFFIX = @APP_MAN_SUFFIX@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BASE_CFLAGS = @BASE_CFLAGS@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CHANGELOG_CMD = @CHANGELOG_CMD@
CPPFLAGS = @CPPFLAGS@
CSCOPE = @CSCOPE@
CTAGS = @CTAGS@
CWARNFLAGS = @CWARNFLAGS@
CYGPATH_W = @CYGPATH_W@
DEFS = @DEFS@
DEPDIR = @DEPDIR@
DRIVER_MAN_DIR = @DRIVER_MAN_DIR@
DRIVER_MAN_SUFFIX = @DRIVER_MAN_SUFFIX@
ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
ETAGS = @ETAGS@
EXEEXT = @EXEEXT@
FILE_MAN_DIR = @FILE_MAN_DIR@
FILE_MAN_SUFFIX = @FILE_MAN_SUFFIX@
FOP = @FOP@
INSTALL = @INSTALL@
INSTALL_CMD = @INSTALL_CMD@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIB_MAN_DIR = @LIB_MAN_DIR@
LIB_MAN_SUFFIX = @LIB_MAN_SUFFIX@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAN_SUBSTS = @MAN_SUBSTS@
MISC_MAN_DIR = @MISC_MAN_DIR@
MISC_MAN_SUFFIX = @MISC_MAN_SUFFIX@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
PKG_CONFIG = @PKG_CONFIG@
PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
PYTHON = @PYTHON@
PYTHON_EXEC_PREFIX = @PYTHON_EXEC_PREFIX@
PYTHON_PLATFORM = @PYTHON_PLATFORM@
PYTHON_PREFIX = @PYTHON_PREFIX@
PYTHON_VERSION = @PYTHON_VERSION@
SED = @SED@
SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
STRICT_CFLAGS = @STRICT_CFLAGS@
STRIP = @STRIP@
STYLESHEET_SRCDIR = @STYLESHEET_SRCDIR@
USE_FDS_BITS = @USE_FDS_BITS@
VERSION = @VERSION@
XMLTO = @XMLTO@
XORG_MAN_PAGE = @XORG_MAN_PAGE@
XORG_SGML_PATH = @XORG_SGML_PATH@
XSLTPROC = @XSLTPROC@
XSL_STYLESHEET = @XSL_STYLESHEET@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build = @build@
build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
pkgpyexecdir = @pkgpyexecdir@
pkgpythondir = @pkgpythondir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
pyexecdir = @pyexecdir@
pythondir = @pythondir@
runstatedir = @runstatedir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
# Main DocBook/XML files (DOCTYPE book)
@ENABLE_SPECS_TRUE@docbook = record.xml
# The location where the DocBook/XML files and their generated formats are installed
@ENABLE_SPECS_TRUE@shelfdir = $(datarootdir)/doc/recordproto
# DocBook/XML generated output formats to be installed
@ENABLE_SPECS_TRUE@shelf_DATA = $(am__append_1) $(am__append_2) \
@ENABLE_SPECS_TRUE@ $(am__append_3) $(am__append_4)
# DocBook/XML file with chapters, appendix and images it includes
@ENABLE_SPECS_TRUE@dist_shelf_DATA = $(docbook) $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_OLINK_FLAGS)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_PDF_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_IMAGEPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_PDF_OLINK_FLAGS)
# Generate documents cross-reference target databases
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam targets.filename "$@" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam collect.xref.targets "only" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam olink.base.uri "$(@:.db=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_PDF_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@CLEANFILES = $(shelf_DATA)
all: all-am
.SUFFIXES:
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/docbook.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign specs/recordproto/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign specs/recordproto/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
*config.status*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
*) \
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \
esac;
$(top_srcdir)/docbook.am $(am__empty):
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(top_srcdir)/configure: $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
install-dist_shelfDATA: $(dist_shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-dist_shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
install-shelfDATA: $(shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
tags TAGS:
ctags CTAGS:
cscope cscopelist:
distdir: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) distdir-am
distdir-am: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
all-am: Makefile $(DATA)
installdirs:
for dir in "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"; do \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-am
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
mostlyclean-generic:
clean-generic:
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
clean: clean-am
clean-am: clean-generic mostlyclean-am
distclean: distclean-am
-rm -f Makefile
distclean-am: clean-am distclean-generic
dvi: dvi-am
dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am: install-dist_shelfDATA install-shelfDATA
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
-rm -f Makefile
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-generic
pdf: pdf-am
pdf-am:
ps: ps-am
ps-am:
uninstall-am: uninstall-dist_shelfDATA uninstall-shelfDATA
.MAKE: install-am install-strip
.PHONY: all all-am check check-am clean clean-generic cscopelist-am \
ctags-am distclean distclean-generic distdir dvi dvi-am html \
html-am info info-am install install-am install-data \
install-data-am install-dist_shelfDATA install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-shelfDATA install-strip installcheck installcheck-am \
installdirs maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-generic pdf pdf-am ps ps-am tags-am \
uninstall uninstall-am uninstall-dist_shelfDATA \
uninstall-shelfDATA
.PRECIOUS: Makefile
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.html: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@%.txt: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.pdf: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.ps: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.html.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_HTML_FLAGS) $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.pdf.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_PDF_FLAGS) $<
# Generate DocBook/XML output formats with or without stylesheets
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
xorgproto-2023.2/specs/xproto/ 0000755 0001750 0001750 00000000000 14443010036 013311 5 0000000 0000000 xorgproto-2023.2/specs/xproto/encoding.xml 0000644 0001750 0001750 00000404635 14443010026 015554 0000000 0000000
Protocol Encoding
Syntactic Conventions
All numbers are in decimal,
unless prefixed with #x, in which case they are in hexadecimal (base 16).
The general syntax used to describe requests, replies, errors, events, and
compound types is:
NameofThing
encode-form
...
encode-form
Each encode-form describes a single component.
For components described in the protocol as:
name: TYPE
the encode-form is:
N TYPE name
N is the number of bytes occupied in the data stream,
and TYPE is the interpretation of those bytes.
For example,
depth: CARD8
becomes:
1 CARD8 depth
For components with a static numeric value the encode-form is:
N value name
The value is always interpreted as an N-byte unsigned integer.
For example,
the first two bytes of a
Window
error are always zero (indicating an
error in general) and three (indicating the
Window
error in particular):
1 0 Error
1 3 code
For components described in the protocol as:
name:
{ Name1 ,...,
NameI }
the encode-form is:
N name
value1 Name1
...
valueI NameI
The value is always interpreted as an N-byte unsigned integer.
Note that the size of N is sometimes larger than that strictly required
to encode the values.
For example:
class:
{ InputOutput ,
InputOnly ,
CopyFromParent }
becomes:
2 class
0 CopyFromParent
1 InputOutput
2 InputOnly
For components described in the protocol as:
NAME: TYPE or
Alternative1 ...or
AlternativeI
the encode-form is:
N TYPE NAME
value1 Alternative1
...
valueI AlternativeI
The alternative values are guaranteed not to conflict with the encoding
of TYPE.
For example:
destination: WINDOW or
PointerWindow
or
InputFocus
becomes:
4 WINDOW destination
0 PointerWindow
1 InputFocus
For components described in the protocol as:
value-mask: BITMASK
the encode-form is:
N BITMASK value-mask
mask1 mask-name1
...
maskI mask-nameI
The individual bits in the mask are specified and named,
and N is 2 or 4.
The most-significant bit in a BITMASK is reserved for use in defining
chained (multiword) bitmasks, as extensions augment existing core requests.
The precise interpretation of this bit is not yet defined here,
although a probable mechanism is that a 1-bit indicates that another N bytes
of bitmask follows, with bits within the overall mask still interpreted
from least-significant to most-significant with an N-byte unit,
with N-byte units
interpreted in stream order, and with the overall mask being byte-swapped
in individual N-byte units.
For LISTofVALUE encodings, the request is followed by a section of the form:
VALUEs
encode-form
...
encode-form
listing an encode-form for each VALUE.
The NAME in each encode-form keys to the corresponding BITMASK bit.
The encoding of a VALUE always occupies four bytes,
but the number of bytes specified in the encoding-form indicates how
many of the least-significant bytes are actually used;
the remaining bytes are unused and their values do not matter.
In various cases, the number of bytes occupied by a component will be
specified
by a lowercase single-letter variable name instead of a specific numeric
value, and often some other component will have its value specified as a
simple numeric expression involving these variables.
Components specified with such expressions are always interpreted
as unsigned integers.
The scope of such variables is always just the enclosing request, reply,
error, event, or compound type structure.
For example:
2 3+n request length
4n LISTofPOINT points
For unused bytes (the values of the bytes are undefined and do no matter),
the encode-form is:
N unused
If the number of unused bytes is variable, the encode-form typically is:
p unused, p=pad(E)
where E is some expression,
Padding
pad(E) = (4 - (E mod 4)) mod 4
Common Types
Types encoding
LISTofFOO
In this document the LISTof notation strictly means some number of repetitions
of the FOO encoding;
the actual length of the list is encoded elsewhere.
SETofFOO
A set is always represented by a bitmask, with a 1-bit indicating presence in
the set.
BITMASK: CARD32
WINDOW: CARD32
PIXMAP: CARD32
CURSOR: CARD32
FONT: CARD32
GCONTEXT: CARD32
COLORMAP: CARD32
DRAWABLE: CARD32
FONTABLE: CARD32
ATOM: CARD32
VISUALID: CARD32
BYTE: 8-bit value
INT8: 8-bit signed integer
INT16: 16-bit signed integer
INT32: 32-bit signed integer
CARD8: 8-bit unsigned integer
CARD16: 16-bit unsigned integer
CARD32: 32-bit unsigned integer
TIMESTAMP: CARD32
BITGRAVITY
0 Forget
1 NorthWest
2 North
3 NorthEast
4 West
5 Center
6 East
7 SouthWest
8 South
9 SouthEast
10 Static
WINGRAVITY
0 Unmap
1 NorthWest
2 North
3 NorthEast
4 West
5 Center
6 East
7 SouthWest
8 South
9 SouthEast
10 Static
BOOL
0 False
1 True
SETofEVENT
#x00000001 KeyPress
#x00000002 KeyRelease
#x00000004 ButtonPress
#x00000008 ButtonRelease
#x00000010 EnterWindow
#x00000020 LeaveWindow
#x00000040 PointerMotion
#x00000080 PointerMotionHint
#x00000100 Button1Motion
#x00000200 Button2Motion
#x00000400 Button3Motion
#x00000800 Button4Motion
#x00001000 Button5Motion
#x00002000 ButtonMotion
#x00004000 KeymapState
#x00008000 Exposure
#x00010000 VisibilityChange
#x00020000 StructureNotify
#x00040000 ResizeRedirect
#x00080000 SubstructureNotify
#x00100000 SubstructureRedirect
#x00200000 FocusChange
#x00400000 PropertyChange
#x00800000 ColormapChange
#x01000000 OwnerGrabButton
#xFE000000 unused but must be zero
SETofPOINTEREVENT
encodings are the same as for SETofEVENT, except with
#xFFFF8003 unused but must be zero
SETofDEVICEEVENT
encodings are the same as for SETofEVENT, except with
#xFFFFC0B0 unused but must be zero
KEYSYM: CARD32
KEYCODE: CARD8
BUTTON: CARD8
SETofKEYBUTMASK
#x0001 Shift
#x0002 Lock
#x0004 Control
#x0008 Mod1
#x0010 Mod2
#x0020 Mod3
#x0040 Mod4
#x0080 Mod5
#x0100 Button1
#x0200 Button2
#x0400 Button3
#x0800 Button4
#x1000 Button5
#xE000 unused but must be zero
SETofKEYMASK
encodings are the same as for SETofKEYBUTMASK, except with
#xFF00 unused but must be zero
STRING8: LISTofCARD8
STRING16: LISTofCHAR2B
CHAR2B
1 CARD8 byte1
1 CARD8 byte2
POINT
2 INT16 x
2 INT16 y
RECTANGLE
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
ARC
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 INT16 angle1
2 INT16 angle2
HOST
1 family
0 Internet
1 DECnet
2 Chaos
5 ServerInterpreted
6 InternetV6
1 unused
2 n length of address
n LISTofBYTE address
p unused, p=pad(n)
STR
1 n length of name in bytes
n STRING8 name
Errors
Error report encoding
Request
1 0 Error
1 1 code
2 CARD16 sequence number
4 unused
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Value
1 0 Error
1 2 code
2 CARD16 sequence number
4 <32-bits> bad value
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Window
1 0 Error
1 3 code
2 CARD16 sequence number
4 CARD32 bad resource id
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Pixmap
1 0 Error
1 4 code
2 CARD16 sequence number
4 CARD32 bad resource id
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Atom
1 0 Error
1 5 code
2 CARD16 sequence number
4 CARD32 bad atom id
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Cursor
1 0 Error
1 6 code
2 CARD16 sequence number
4 CARD32 bad resource id
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Font
1 0 Error
1 7 code
2 CARD16 sequence number
4 CARD32 bad resource id
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Match
1 0 Error
1 8 code
2 CARD16 sequence number
4 unused
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Drawable
1 0 Error
1 9 code
2 CARD16 sequence number
4 CARD32 bad resource id
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Access
1 0 Error
1 10 code
2 CARD16 sequence number
4 unused
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Alloc
1 0 Error
1 11 code
2 CARD16 sequence number
4 unused
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Colormap
1 0 Error
1 12 code
2 CARD16 sequence number
4 CARD32 bad resource id
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
GContext
1 0 Error
1 13 code
2 CARD16 sequence number
4 CARD32 bad resource id
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
IDChoice
1 0 Error
1 14 code
2 CARD16 sequence number
4 CARD32 bad resource id
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Name
1 0 Error
1 15 code
2 CARD16 sequence number
4 unused
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Length
1 0 Error
1 16 code
2 CARD16 sequence number
4 unused
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Implementation
1 0 Error
1 17 code
2 CARD16 sequence number
4 unused
2 CARD16 minor opcode
1 CARD8 major opcode
21 unused
Keyboards
KEYCODE values are always greater than 7 (and less than 256).
KEYSYM values with the bit #x10000000 set are reserved as vendor-specific.
The names and encodings of the standard KEYSYM values are contained in
Pointers
BUTTON values are numbered starting with one.
Predefined Atoms
Atom predefined
PRIMARY 1 WM_NORMAL_HINTS 40
SECONDARY 2 WM_SIZE_HINTS 41
ARC 3 WM_ZOOM_HINTS 42
ATOM 4 MIN_SPACE 43
BITMAP 5 NORM_SPACE 44
CARDINAL 6 MAX_SPACE 45
COLORMAP 7 END_SPACE 46
CURSOR 8 SUPERSCRIPT_X 47
CUT_BUFFER0 9 SUPERSCRIPT_Y 48
CUT_BUFFER1 10 SUBSCRIPT_X 49
CUT_BUFFER2 11 SUBSCRIPT_Y 50
CUT_BUFFER3 12 UNDERLINE_POSITION 51
CUT_BUFFER4 13 UNDERLINE_THICKNESS 52
CUT_BUFFER5 14 STRIKEOUT_ASCENT 53
CUT_BUFFER6 15 STRIKEOUT_DESCENT 54
CUT_BUFFER7 16 ITALIC_ANGLE 55
DRAWABLE 17 X_HEIGHT 56
FONT 18 QUAD_WIDTH 57
INTEGER 19 WEIGHT 58
PIXMAP 20 POINT_SIZE 59
POINT 21 RESOLUTION 60
RECTANGLE 22 COPYRIGHT 61
RESOURCE_MANAGER 23 NOTICE 62
RGB_COLOR_MAP 24 FONT_NAME 63
RGB_BEST_MAP 25 FAMILY_NAME 64
RGB_BLUE_MAP 26 FULL_NAME 65
RGB_DEFAULT_MAP 27 CAP_HEIGHT 66
RGB_GRAY_MAP 28 WM_CLASS 67
RGB_GREEN_MAP 29 WM_TRANSIENT_FOR 68
RGB_RED_MAP 30
STRING 31
VISUALID 32
WINDOW 33
WM_COMMAND 34
WM_HINTS 35
WM_CLIENT_MACHINE 36
WM_ICON_NAME 37
WM_ICON_SIZE 38
WM_NAME 39
Connection Setup
For TCP connections,
displays on a given host are numbered starting from 0,
and the server for display N listens and accepts connections on port 6000 + N.
For DECnet connections,
displays on a given host are numbered starting from 0,
and the server for display N listens and accepts connections on the object
name obtained by concatenating "X$X" with the decimal representation of N,
for example, X$X0 and X$X1.
Information sent by the client at connection setup:
1 byte-order
#x42 MSB first
#x6C LSB first
1 unused
2 CARD16 protocol-major-version
2 CARD16 protocol-minor-version
2 n length of authorization-protocol-name
2 d length of authorization-protocol-data
2 unused
n STRING8 authorization-protocol-name
p unused, p=pad(n)
d STRING8 authorization-protocol-data
q unused, q=pad(d)
Except where explicitly noted in the protocol,
all 16-bit and 32-bit quantities sent by the client must be transmitted
with the specified byte order,
and all 16-bit and 32-bit quantities returned by the server will be transmitted
with this byte order.
Information received by the client if the connection is refused:
1 0 Failed
1 n length of reason in bytes
2 CARD16 protocol-major-version
2 CARD16 protocol-minor-version
2 (n+p)/4 length in 4-byte units of "additional data"
n STRING8 reason
p unused, p=pad(n)
Information received by the client if further authentication is required:
1 2 Authenticate
5 unused
2 (n+p)/4 length in 4-byte units of "additional data"
n STRING8 reason
p unused, p=pad(n)
Information received by the client if the connection is accepted:
1 1 Success
1 unused
2 CARD16 protocol-major-version
2 CARD16 protocol-minor-version
2 8+2n+(v+p+m)/4 length in 4-byte units of
"additional data"
4 CARD32 release-number
4 CARD32 resource-id-base
4 CARD32 resource-id-mask
4 CARD32 motion-buffer-size
2 v length of vendor
2 CARD16 maximum-request-length
1 CARD8 number of SCREENs in roots
1 n number for FORMATs in
pixmap-formats
1 image-byte-order
0 LSBFirst
1 MSBFirst
1 bitmap-format-bit-order
0 LeastSignificant
1 MostSignificant
1 CARD8 bitmap-format-scanline-unit
1 CARD8 bitmap-format-scanline-pad
1 KEYCODE min-keycode
1 KEYCODE max-keycode
4 unused
v STRING8 vendor
p unused, p=pad(v)
8n LISTofFORMAT pixmap-formats
m LISTofSCREEN roots (m is always a multiple of 4)
FORMAT
1 CARD8 depth
1 CARD8 bits-per-pixel
1 CARD8 scanline-pad
5 unused
SCREEN
4 WINDOW root
4 COLORMAP default-colormap
4 CARD32 white-pixel
4 CARD32 black-pixel
4 SETofEVENT current-input-masks
2 CARD16 width-in-pixels
2 CARD16 height-in-pixels
2 CARD16 width-in-millimeters
2 CARD16 height-in-millimeters
2 CARD16 min-installed-maps
2 CARD16 max-installed-maps
4 VISUALID root-visual
1 backing-stores
0 Never
1 WhenMapped
2 Always
1 BOOL save-unders
1 CARD8 root-depth
1 CARD8 number of DEPTHs in allowed-depths
n LISTofDEPTH allowed-depths (n is always a
multiple of 4)
DEPTH
1 CARD8 depth
1 unused
2 n number of VISUALTYPES in visuals
4 unused
24n LISTofVISUALTYPE visuals
VISUALTYPE
4 VISUALID visual-id
1 class
0 StaticGray
1 GrayScale
2 StaticColor
3 PseudoColor
4 TrueColor
5 DirectColor
1 CARD8 bits-per-rgb-value
2 CARD16 colormap-entries
4 CARD32 red-mask
4 CARD32 green-mask
4 CARD32 blue-mask
4 unused
Requests
Request encoding
CreateWindow
1 1 opcode
1 CARD8 depth
2 8+n request length
4 WINDOW wid
4 WINDOW parent
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border-width
2 class
0 CopyFromParent
1 InputOutput
2 InputOnly
4 VISUALID visual
0 CopyFromParent
4 BITMASK value-mask (has n bits set to 1)
#x00000001 background-pixmap
#x00000002 background-pixel
#x00000004 border-pixmap
#x00000008 border-pixel
#x00000010 bit-gravity
#x00000020 win-gravity
#x00000040 backing-store
#x00000080 backing-planes
#x00000100 backing-pixel
#x00000200 override-redirect
#x00000400 save-under
#x00000800 event-mask
#x00001000 do-not-propagate-mask
#x00002000 colormap
#x00004000 cursor
4n LISTofVALUE value-list
VALUEs
4 PIXMAP background-pixmap
0 None
1 ParentRelative
4 CARD32 background-pixel
4 PIXMAP border-pixmap
0 CopyFromParent
4 CARD32 border-pixel
1 BITGRAVITY bit-gravity
1 WINGRAVITY win-gravity
1 backing-store
0 NotUseful
1 WhenMapped
2 Always
4 CARD32 backing-planes
4 CARD32 backing-pixel
1 BOOL override-redirect
1 BOOL save-under
4 SETofEVENT event-mask
4 SETofDEVICEEVENT do-not-propagate-mask
4 COLORMAP colormap
0 CopyFromParent
4 CURSOR cursor
0 None
ChangeWindowAttributes
1 2 opcode
1 unused
2 3+n request length
4 WINDOW window
4 BITMASK value-mask (has n bits set to 1)
encodings are the same as for CreateWindow
4n LISTofVALUE value-list
encodings are the same as for CreateWindow
GetWindowAttributes
1 3 opcode
1 unused
2 2 request length
4 WINDOW window
â–¶
1 1 Reply
1 backing-store
0 NotUseful
1 WhenMapped
2 Always
2 CARD16 sequence number
4 3 reply length
4 VISUALID visual
2 class
1 InputOutput
2 InputOnly
1 BITGRAVITY bit-gravity
1 WINGRAVITY win-gravity
4 CARD32 backing-planes
4 CARD32 backing-pixel
1 BOOL save-under
1 BOOL map-is-installed
1 map-state
0 Unmapped
1 Unviewable
2 Viewable
1 BOOL override-redirect
4 COLORMAP colormap
0 None
4 SETofEVENT all-event-masks
4 SETofEVENT your-event-mask
2 SETofDEVICEEVENT do-not-propagate-mask
2 unused
DestroyWindow
1 4 opcode
1 unused
2 2 request length
4 WINDOW window
DestroySubwindows
1 5 opcode
1 unused
2 2 request length
4 WINDOW window
ChangeSaveSet
1 6 opcode
1 mode
0 Insert
1 Delete
2 2 request length
4 WINDOW window
ReparentWindow
1 7 opcode
1 unused
2 4 request length
4 WINDOW window
4 WINDOW parent
2 INT16 x
2 INT16 y
MapWindow
1 8 opcode
1 unused
2 2 request length
4 WINDOW window
MapSubwindows
1 9 opcode
1 unused
2 2 request length
4 WINDOW window
UnmapWindow
1 10 opcode
1 unused
2 2 request length
4 WINDOW window
UnmapSubwindows
1 11 opcode
1 unused
2 2 request length
4 WINDOW window
ConfigureWindow
1 12 opcode
1 unused
2 3+n request length
4 WINDOW window
2 BITMASK value-mask (has n bits set to 1)
#x0001 x
#x0002 y
#x0004 width
#x0008 height
#x0010 border-width
#x0020 sibling
#x0040 stack-mode
2 unused
4n LISTofVALUE value-list
VALUEs
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border-width
4 WINDOW sibling
1 stack-mode
0 Above
1 Below
2 TopIf
3 BottomIf
4 Opposite
CirculateWindow
1 13 opcode
1 direction
0 RaiseLowest
1 LowerHighest
2 2 request length
4 WINDOW window
GetGeometry
1 14 opcode
1 unused
2 2 request length
4 DRAWABLE drawable
â–¶
1 1 Reply
1 CARD8 depth
2 CARD16 sequence number
4 0 reply length
4 WINDOW root
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border-width
10 unused
QueryTree
1 15 opcode
1 unused
2 2 request length
4 WINDOW window
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 n reply length
4 WINDOW root
4 WINDOW parent
0 None
2 n number of WINDOWs in children
14 unused
4n LISTofWINDOW children
InternAtom
1 16 opcode
1 BOOL only-if-exists
2 2+(n+p)/4 request length
2 n length of name
2 unused
n STRING8 name
p unused, p=pad(n)
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 ATOM atom
0 None
20 unused
GetAtomName
1 17 opcode
1 unused
2 2 request length
4 ATOM atom
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 (n+p)/4 reply length
2 n length of name
22 unused
n STRING8 name
p unused, p=pad(n)
ChangeProperty
1 18 opcode
1 mode
0 Replace
1 Prepend
2 Append
2 6+(n+p)/4 request length
4 WINDOW window
4 ATOM property
4 ATOM type
1 CARD8 format
3 unused
4 CARD32 length of data in format units
(= n for format = 8)
(= n/2 for format = 16)
(= n/4 for format = 32)
n LISTofBYTE data
(n is a multiple of 2 for format = 16)
(n is a multiple of 4 for format = 32)
p unused, p=pad(n)
DeleteProperty
1 19 opcode
1 unused
2 3 request length
4 WINDOW window
4 ATOM property
GetProperty
1 20 opcode
1 BOOL delete
2 6 request length
4 WINDOW window
4 ATOM property
4 ATOM type
0 AnyPropertyType
4 CARD32 long-offset
4 CARD32 long-length
â–¶
1 1 Reply
1 CARD8 format
2 CARD16 sequence number
4 (n+p)/4 reply length
4 ATOM type
0 None
4 CARD32 bytes-after
4 CARD32 length of value in format units
(= 0 for format = 0)
(= n for format = 8)
(= n/2 for format = 16)
(= n/4 for format = 32)
12 unused
n LISTofBYTE value
(n is zero for format = 0)
(n is a multiple of 2 for format = 16)
(n is a multiple of 4 for format = 32)
p unused, p=pad(n)
ListProperties
1 21 opcode
1 unused
2 2 request length
4 WINDOW window
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 n reply length
2 n number of ATOMs in atoms
22 unused
4n LISTofATOM atoms
SetSelectionOwner
1 22 opcode
1 unused
2 4 request length
4 WINDOW owner
0 None
4 ATOM selection
4 TIMESTAMP time
0 CurrentTime
GetSelectionOwner
1 23 opcode
1 unused
2 2 request length
4 ATOM selection
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 WINDOW owner
0 None
20 unused
ConvertSelection
1 24 opcode
1 unused
2 6 request length
4 WINDOW requestor
4 ATOM selection
4 ATOM target
4 ATOM property
0 None
4 TIMESTAMP time
0 CurrentTime
SendEvent
1 25 opcode
1 BOOL propagate
2 11 requestlength
4 WINDOW destination
0 PointerWindow
1 InputFocus
4 SETofEVENT event-mask
32 event
standard event format (see GrabPointer
1 26 opcode
1 BOOL owner-events
2 6 request length
4 WINDOW grab-window
2 SETofPOINTEREVENT event-mask
1 pointer-mode
0 Synchronous
1 Asynchronous
1 keyboard-mode
0 Synchronous
1 Asynchronous
4 WINDOW confine-to
0 None
4 CURSOR cursor
0 None
4 TIMESTAMP time
0 CurrentTime
â–¶
1 1 Reply
1 status
0 Success
1 AlreadyGrabbed
2 InvalidTime
3 NotViewable
4 Frozen
2 CARD16 sequence number
4 0 reply length
24 unused
UngrabPointer
1 27 opcode
1 unused
2 2 request length
4 TIMESTAMP time
0 CurrentTime
GrabButton
1 28 opcode
1 BOOL owner-events
2 6 request length
4 WINDOW grab-window
2 SETofPOINTEREVENT event-mask
1 pointer-mode
0 Synchronous
1 Asynchronous
1 keyboard-mode
0 Synchronous
1 Asynchronous
4 WINDOW confine-to
0 None
4 CURSOR cursor
0 None
1 BUTTON button
0 AnyButton
1 unused
2 SETofKEYMASK modifiers
#x8000 AnyModifier
UngrabButton
1 29 opcode
1 BUTTON button
0 AnyButton
2 3 request length
4 WINDOW grab-window
2 SETofKEYMASK modifiers
#x8000 AnyModifier
2 unused
ChangeActivePointerGrab
1 30 opcode
1 unused
2 4 request length
4 CURSOR cursor
0 None
4 TIMESTAMP time
0 CurrentTime
2 SETofPOINTEREVENT event-mask
2 unused
GrabKeyboard
1 31 opcode
1 BOOL owner-events
2 4 request length
4 WINDOW grab-window
4 TIMESTAMP time
0 CurrentTime
1 pointer-mode
0 Synchronous
1 Asynchronous
1 keyboard-mode
0 Synchronous
1 Asynchronous
2 unused
â–¶
1 1 Reply
1 status
0 Success
1 AlreadyGrabbed
2 InvalidTime
3 NotViewable
4 Frozen
2 CARD16 sequence number
4 0 reply length
24 unused
UngrabKeyboard
1 32 opcode
1 unused
2 2 request length
4 TIMESTAMP time
0 CurrentTime
GrabKey
1 33 opcode
1 BOOL owner-events
2 4 request length
4 WINDOW grab-window
2 SETofKEYMASK modifiers
#x8000 AnyModifier
1 KEYCODE key
0 AnyKey
1 pointer-mode
0 Synchronous
1 Asynchronous
1 keyboard-mode
0 Synchronous
1 Asynchronous
3 unused
UngrabKey
1 34 opcode
1 KEYCODE key
0 AnyKey
2 3 request length
4 WINDOW grab-window
2 SETofKEYMASK modifiers
#x8000 AnyModifier
2 unused
AllowEvents
1 35 opcode
1 mode
0 AsyncPointer
1 SyncPointer
2 ReplayPointer
3 AsyncKeyboard
4 SyncKeyboard
5 ReplayKeyboard
6 AsyncBoth
7 SyncBoth
2 2 request length
4 TIMESTAMP time
0 CurrentTime
GrabServer
1 36 opcode
1 unused
2 1 request length
UngrabServer
1 37 opcode
1 unused
2 1 request length
QueryPointer
1 38 opcode
1 unused
2 2 request length
4 WINDOW window
â–¶
1 1 Reply
1 BOOL same-screen
2 CARD16 sequence number
4 0 reply length
4 WINDOW root
4 WINDOW child
0 None
2 INT16 root-x
2 INT16 root-y
2 INT16 win-x
2 INT16 win-y
2 SETofKEYBUTMASK mask
6 unused
GetMotionEvents
1 39 opcode
1 unused
2 4 request length
4 WINDOW window
4 TIMESTAMP start
0 CurrentTime
4 TIMESTAMP stop
0 CurrentTime
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 2n reply length
4 n number of TIMECOORDs in events
20 unused
8n LISTofTIMECOORD events
TIMECOORD
4 TIMESTAMP time
2 INT16 x
2 INT16 y
TranslateCoordinates
1 40 opcode
1 unused
2 4 request length
4 WINDOW src-window
4 WINDOW dst-window
2 INT16 src-x
2 INT16 src-y
â–¶
1 1 Reply
1 BOOL same-screen
2 CARD16 sequence number
4 0 reply length
4 WINDOW child
0 None
2 INT16 dst-x
2 INT16 dst-y
16 unused
WarpPointer
1 41 opcode
1 unused
2 6 request length
4 WINDOW src-window
0 None
4 WINDOW dst-window
0 None
2 INT16 src-x
2 INT16 src-y
2 CARD16 src-width
2 CARD16 src-height
2 INT16 dst-x
2 INT16 dst-y
SetInputFocus
1 42 opcode
1 revert-to
0 None
1 PointerRoot
2 Parent
2 3 request length
4 WINDOW focus
0 None
1 PointerRoot
4 TIMESTAMP time
0 CurrentTime
GetInputFocus
1 43 opcode
1 unused
2 1 request length
â–¶
1 1 Reply
1 revert-to
0 None
1 PointerRoot
2 Parent
2 CARD16 sequence number
4 0 reply length
4 WINDOW focus
0 None
1 PointerRoot
20 unused
QueryKeymap
1 44 opcode
1 unused
2 1 request length
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 2 reply length
32 LISTofCARD8 keys
OpenFont
1 45 opcode
1 unused
2 3+(n+p)/4 request length
4 FONT fid
2 n length of name
2 unused
n STRING8 name
p unused, p=pad(n)
CloseFont
1 46 opcode
1 unused
2 2 request length
4 FONT font
QueryFont
1 47 opcode
1 unused
2 2 request length
4 FONTABLE font
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 7+2n+3m reply length
12 CHARINFO min-bounds
4 unused
12 CHARINFO max-bounds
4 unused
2 CARD16 min-char-or-byte2
2 CARD16 max-char-or-byte2
2 CARD16 default-char
2 n number of FONTPROPs in properties
1 draw-direction
0 LeftToRight
1 RightToLeft
1 CARD8 min-byte1
1 CARD8 max-byte1
1 BOOL all-chars-exist
2 INT16 font-ascent
2 INT16 font-descent
4 m number of CHARINFOs in char-infos
8n LISTofFONTPROP properties
12m LISTofCHARINFO char-infos
FONTPROP
4 ATOM name
4 <32-bits> value
CHARINFO
2 INT16 left-side-bearing
2 INT16 right-side-bearing
2 INT16 character-width
2 INT16 ascent
2 INT16 descent
2 CARD16 attributes
QueryTextExtents
1 48 opcode
1 BOOL odd length, True if p = 2
2 2+(2n+p)/4 request length
4 FONTABLE font
2n STRING16 string
p unused, p=pad(2n)
â–¶
1 1 Reply
1 draw-direction
0 LeftToRight
1 RightToLeft
2 CARD16 sequence number
4 0 reply length
2 INT16 font-ascent
2 INT16 font-descent
2 INT16 overall-ascent
2 INT16 overall-descent
4 INT32 overall-width
4 INT32 overall-left
4 INT32 overall-right
4 unused
ListFonts
1 49 opcode
1 unused
2 2+(n+p)/4 request length
2 CARD16 max-names
2 n length of pattern
n STRING8 pattern
p unused, p=pad(n)
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 (n+p)/4 reply length
2 CARD16 number of STRs in names
22 unused
n LISTofSTR names
p unused, p=pad(n)
ListFontsWithInfo
1 50 opcode
1 unused
2 2+(n+p)/4 request length
2 CARD16 max-names
2 n length of pattern
n STRING8 pattern
p unused, p=pad(n)
â–¶ (except for last in series)
1 1 Reply
1 n length of name in bytes
2 CARD16 sequence number
4 7+2m+(n+p)/4 reply length
12 CHARINFO min-bounds
4 unused
12 CHARINFO max-bounds
4 unused
2 CARD16 min-char-or-byte2
2 CARD16 max-char-or-byte2
2 CARD16 default-char
2 m number of FONTPROPs in properties
1 draw-direction
0 LeftToRight
1 RightToLeft
1 CARD8 min-byte1
1 CARD8 max-byte1
1 BOOL all-chars-exist
2 INT16 font-ascent
2 INT16 font-descent
4 CARD32 replies-hint
8m LISTofFONTPROP properties
n STRING8 name
p unused, p=pad(n)
FONTPROP
encodings are the same as for QueryFont
CHARINFO
encodings are the same as for QueryFont
â–¶ (last in series)
1 1 Reply
1 0 last-reply indicator
2 CARD16 sequence number
4 7 reply length
52 unused
SetFontPath
1 51 opcode
1 unused
2 2+(n+p)/4 request length
2 CARD16 number of STRs in path
2 unused
n LISTofSTR path
p unused, p=pad(n)
GetFontPath
1 52 opcode
1 unused
2 1 request list
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 (n+p)/4 reply length
2 CARD16 number of STRs in path
22 unused
n LISTofSTR path
p unused, p=pad(n)
CreatePixmap
1 53 opcode
1 CARD8 depth
2 4 request length
4 PIXMAP pid
4 DRAWABLE drawable
2 CARD16 width
2 CARD16 height
FreePixmap
1 54 opcode
1 unused
2 2 request length
4 PIXMAP pixmap
CreateGC
1 55 opcode
1 unused
2 4+n request length
4 GCONTEXT cid
4 DRAWABLE drawable
4 BITMASK value-mask (has n bits set to 1)
#x00000001 function
#x00000002 plane-mask
#x00000004 foreground
#x00000008 background
#x00000010 line-width
#x00000020 line-style
#x00000040 cap-style
#x00000080 join-style
#x00000100 fill-style
#x00000200 fill-rule
#x00000400 tile
#x00000800 stipple
#x00001000 tile-stipple-x-origin
#x00002000 tile-stipple-y-origin
#x00004000 font
#x00008000 subwindow-mode
#x00010000 graphics-exposures
#x00020000 clip-x-origin
#x00040000 clip-y-origin
#x00080000 clip-mask
#x00100000 dash-offset
#x00200000 dashes
#x00400000 arc-mode
4n LISTofVALUE value-list
VALUEs
1 function
0 Clear
1 And
2 AndReverse
3 Copy
4 AndInverted
5 NoOp
6 Xor
7 Or
8 Nor
9 Equiv
10 Invert
11 OrReverse
12 CopyInverted
13 OrInverted
14 Nand
15 Set
4 CARD32 plane-mask
4 CARD32 foreground
4 CARD32 background
2 CARD16 line-width
1 line-style
0 Solid
1 OnOffDash
2 DoubleDash
1 cap-style
0 NotLast
1 Butt
2 Round
3 Projecting
1 join-style
0 Miter
1 Round
2 Bevel
1 fill-style
0 Solid
1 Tiled
2 Stippled
3 OpaqueStippled
1 fill-rule
0 EvenOdd
1 Winding
4 PIXMAP tile
4 PIXMAP stipple
2 INT16 tile-stipple-x-origin
2 INT16 tile-stipple-y-origin
4 FONT font
1 subwindow-mode
0 ClipByChildren
1 IncludeInferiors
1 BOOL graphics-exposures
2 INT16 clip-x-origin
2 INT16 clip-y-origin
4 PIXMAP clip-mask
0 None
2 CARD16 dash-offset
1 CARD8 dashes
1 arc-mode
0 Chord
1 PieSlice
ChangeGC
1 56 opcode
1 unused
2 3+n request length
4 GCONTEXT gc
4 BITMASK value-mask (has n bits set to 1)
encodings are the same as for CreateGC
4n LISTofVALUE value-list
encodings are the same as for CreateGC
CopyGC
1 57 opcode
1 unused
2 4 request length
4 GCONTEXT src-gc
4 GCONTEXT dst-gc
4 BITMASK value-mask
encodings are the same as for CreateGC
SetDashes
1 58 opcode
1 unused
2 3+(n+p)/4 request length
4 GCONTEXT gc
2 CARD16 dash-offset
2 n length of dashes
n LISTofCARD8 dashes
p unused, p=pad(n)
SetClipRectangles
1 59 opcode
1 ordering
0 UnSorted
1 YSorted
2 YXSorted
3 YXBanded
2 3+2n request length
4 GCONTEXT gc
2 INT16 clip-x-origin
2 INT16 clip-y-origin
8n LISTofRECTANGLE rectangles
FreeGC
1 60 opcode
1 unused
2 2 request length
4 GCONTEXT gc
ClearArea
1 61 opcode
1 BOOL exposures
2 4 request length
4 WINDOW window
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
CopyArea
1 62 opcode
1 unused
2 7 request length
4 DRAWABLE src-drawable
4 DRAWABLE dst-drawable
4 GCONTEXT gc
2 INT16 src-x
2 INT16 src-y
2 INT16 dst-x
2 INT16 dst-y
2 CARD16 width
2 CARD16 height
CopyPlane
1 63 opcode
1 unused
2 8 request length
4 DRAWABLE src-drawable
4 DRAWABLE dst-drawable
4 GCONTEXT gc
2 INT16 src-x
2 INT16 src-y
2 INT16 dst-x
2 INT16 dst-y
2 CARD16 width
2 CARD16 height
4 CARD32 bit-plane
PolyPoint
1 64 opcode
1 coordinate-mode
0 Origin
1 Previous
2 3+n request length
4 DRAWABLE drawable
4 GCONTEXT gc
4n LISTofPOINT points
PolyLine
1 65 opcode
1 coordinate-mode
0 Origin
1 Previous
2 3+n request length
4 DRAWABLE drawable
4 GCONTEXT gc
4n LISTofPOINT points
PolySegment
1 66 opcode
1 unused
2 3+2n request length
4 DRAWABLE drawable
4 GCONTEXT gc
8n LISTofSEGMENT segments
SEGMENT
2 INT16 x1
2 INT16 y1
2 INT16 x2
2 INT16 y2
PolyRectangle
1 67 opcode
1 unused
2 3+2n request length
4 DRAWABLE drawable
4 GCONTEXT gc
8n LISTofRECTANGLE rectangles
PolyArc
1 68 opcode
1 unused
2 3+3n request length
4 DRAWABLE drawable
4 GCONTEXT gc
12n LISTofARC arcs
FillPoly
1 69 opcode
1 unused
2 4+n request length
4 DRAWABLE drawable
4 GCONTEXT gc
1 shape
0 Complex
1 Nonconvex
2 Convex
1 coordinate-mode
0 Origin
1 Previous
2 unused
4n LISTofPOINT points
PolyFillRectangle
1 70 opcode
1 unused
2 3+2n request length
4 DRAWABLE drawable
4 GCONTEXT gc
8n LISTofRECTANGLE rectangles
PolyFillArc
1 71 opcode
1 unused
2 3+3n request length
4 DRAWABLE drawable
4 GCONTEXT gc
12n LISTofARC arcs
PutImage
1 72 opcode
1 format
0 Bitmap
1 XYPixmap
2 ZPixmap
2 6+(n+p)/4 request length
4 DRAWABLE drawable
4 GCONTEXT gc
2 CARD16 width
2 CARD16 height
2 INT16 dst-x
2 INT16 dst-y
1 CARD8 left-pad
1 CARD8 depth
2 unused
n LISTofBYTE data
p unused, p=pad(n)
GetImage
1 73 opcode
1 format
1 XYPixmap
2 ZPixmap
2 5 request length
4 DRAWABLE drawable
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
4 CARD32 plane-mask
â–¶
1 1 Reply
1 CARD8 depth
2 CARD16 sequence number
4 (n+p)/4 reply length
4 VISUALID visual
0 None
20 unused
n LISTofBYTE data
p unused, p=pad(n)
PolyText8
1 74 opcode
1 unused
2 4+(n+p)/4 request length
4 DRAWABLE drawable
4 GCONTEXT gc
2 INT16 x
2 INT16 y
n LISTofTEXTITEM8 items
p unused, p=pad(n) (p is always 0
or 1)
TEXTITEM8
1 m length of string (cannot be 255)
1 INT8 delta
m STRING8 string
or
1 255 font-shift indicator
1 font byte 3 (most-significant)
1 font byte 2
1 font byte 1
1 font byte 0 (least-significant)
PolyText16
1 75 opcode
1 unused
2 4+(n+p)/4 request length
4 DRAWABLE drawable
4 GCONTEXT gc
2 INT16 x
2 INT16 y
n LISTofTEXTITEM16 items
p unused, p=pad(n) (p must be 0 or
1)
TEXTITEM16
1 m number of CHAR2Bs in string
(cannot be 255)
1 INT8 delta
2m STRING16 string
or
1 255 font-shift indicator
1 font byte 3 (most-significant)
1 font byte 2
1 font byte 1
1 font byte 0 (least-significant)
ImageText8
1 76 opcode
1 n length of string
2 4+(n+p)/4 request length
4 DRAWABLE drawable
4 GCONTEXT gc
2 INT16 x
2 INT16 y
n STRING8 string
p unused, p=pad(n)
ImageText16
1 77 opcode
1 n number of CHAR2Bs in string
2 4+(2n+p)/4 request length
4 DRAWABLE drawable
4 GCONTEXT gc
2 INT16 x
2 INT16 y
2n STRING16 string
p unused, p=pad(2n)
CreateColormap
1 78 opcode
1 alloc
0 None
1 All
2 4 request length
4 COLORMAP mid
4 WINDOW window
4 VISUALID visual
FreeColormap
1 79 opcode
1 unused
2 2 request length
4 COLORMAP cmap
CopyColormapAndFree
1 80 opcode
1 unused
2 3 request length
4 COLORMAP mid
4 COLORMAP src-cmap
InstallColormap
1 81 opcode
1 unused
2 2 request length
4 COLORMAP cmap
UninstallColormap
1 82 opcode
1 unused
2 2 request length
4 COLORMAP cmap
ListInstalledColormaps
1 83 opcode
1 unused
2 2 request length
4 WINDOW window
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 n reply length
2 n number of COLORMAPs in cmaps
22 unused
4n LISTofCOLORMAP cmaps
AllocColor
1 84 opcode
1 unused
2 4 request length
4 COLORMAP cmap
2 CARD16 red
2 CARD16 green
2 CARD16 blue
2 unused
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 red
2 CARD16 green
2 CARD16 blue
2 unused
4 CARD32 pixel
12 unused
AllocNamedColor
1 85 opcode
1 unused
2 3+(n+p)/4 request length
4 COLORMAP cmap
2 n length of name
2 unused
n STRING8 name
p unused, p=pad(n)
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
4 CARD32 pixel
2 CARD16 exact-red
2 CARD16 exact-green
2 CARD16 exact-blue
2 CARD16 visual-red
2 CARD16 visual-green
2 CARD16 visual-blue
8 unused
AllocColorCells
1 86 opcode
1 BOOL contiguous
2 3 request length
4 COLORMAP cmap
2 CARD16 colors
2 CARD16 planes
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 n+m reply length
2 n number of CARD32s in pixels
2 m number of CARD32s in masks
20 unused
4n LISTofCARD32 pixels
4m LISTofCARD32 masks
AllocColorPlanes
1 87 opcode
1 BOOL contiguous
2 4 request length
4 COLORMAP cmap
2 CARD16 colors
2 CARD16 reds
2 CARD16 greens
2 CARD16 blues
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 n reply length
2 n number of CARD32s in pixels
2 unused
4 CARD32 red-mask
4 CARD32 green-mask
4 CARD32 blue-mask
8 unused
4n LISTofCARD32 pixels
FreeColors
1 88 opcode
1 unused
2 3+n request length
4 COLORMAP cmap
4 CARD32 plane-mask
4n LISTofCARD32 pixels
StoreColors
1 89 opcode
1 unused
2 2+3n request length
4 COLORMAP cmap
12n LISTofCOLORITEM items
COLORITEM
4 CARD32 pixel
2 CARD16 red
2 CARD16 green
2 CARD16 blue
1 do-red, do-green, do-blue
#x01 do-red (1 is True, 0 is False)
#x02 do-green (1 is True, 0 is False)
#x04 do-blue (1 is True, 0 is False)
#xF8 unused
1 unused
StoreNamedColor
1 90 opcode
1 do-red, do-green, do-blue
#x01 do-red (1 is True, 0 is False)
#x02 do-green (1 is True, 0 is False)
#x04 do-blue (1 is True, 0 is False)
#xF8 unused
2 4+(n+p)/4 request length
4 COLORMAP cmap
4 CARD32 pixel
2 n length of name
2 unused
n STRING8 name
p unused, p=pad(n)
QueryColors
1 91 opcode
1 unused
2 2+n request length
4 COLORMAP cmap
4n LISTofCARD32 pixels
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 2n reply length
2 n number of RGBs in colors
22 unused
8n LISTofRGB colors
RGB
2 CARD16 red
2 CARD16 green
2 CARD16 blue
2 unused
LookupColor
1 92 opcode
1 unused
2 3+(n+p)/4 request length
4 COLORMAP cmap
2 n length of name
2 unused
n STRING8 name
p unused, p=pad(n)
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 exact-red
2 CARD16 exact-green
2 CARD16 exact-blue
2 CARD16 visual-red
2 CARD16 visual-green
2 CARD16 visual-blue
12 unused
CreateCursor
1 93 opcode
1 unused
2 8 request length
4 CURSOR cid
4 PIXMAP source
4 PIXMAP mask
0 None
2 CARD16 fore-red
2 CARD16 fore-green
2 CARD16 fore-blue
2 CARD16 back-red
2 CARD16 back-green
2 CARD16 back-blue
2 CARD16 x
2 CARD16 y
CreateGlyphCursor
1 94 opcode
1 unused
2 8 request length
4 CURSOR cid
4 FONT source-font
4 FONT mask-font
0 None
2 CARD16 source-char
2 CARD16 mask-char
2 CARD16 fore-red
2 CARD16 fore-green
2 CARD16 fore-blue
2 CARD16 back-red
2 CARD16 back-green
2 CARD16 back-blue
FreeCursor
1 95 opcode
1 unused
2 2 request length
4 CURSOR cursor
RecolorCursor
1 96 opcode
1 unused
2 5 request length
4 CURSOR cursor
2 CARD16 fore-red
2 CARD16 fore-green
2 CARD16 fore-blue
2 CARD16 back-red
2 CARD16 back-green
2 CARD16 back-blue
QueryBestSize
1 97 opcode
1 class
0 Cursor
1 Tile
2 Stipple
2 3 request length
4 DRAWABLE drawable
2 CARD16 width
2 CARD16 height
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 width
2 CARD16 height
20 unused
QueryExtension
1 98 opcode
1 unused
2 2+(n+p)/4 request length
2 n length of name
2 unused
n STRING8 name
p unused, p=pad(n)
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
1 BOOL present
1 CARD8 major-opcode
1 CARD8 first-event
1 CARD8 first-error
20 unused
ListExtensions
1 99 opcode
1 unused
2 1 request length
â–¶
1 1 Reply
1 CARD8 number of STRs in names
2 CARD16 sequence number
4 (n+p)/4 reply length
24 unused
n LISTofSTR names
p unused, p=pad(n)
ChangeKeyboardMapping
1 100 opcode
1 n keycode-count
2 2+nm request length
1 KEYCODE first-keycode
1 m keysyms-per-keycode
2 unused
4nm LISTofKEYSYM keysyms
GetKeyboardMapping
1 101 opcode
1 unused
2 2 request length
1 KEYCODE first-keycode
1 m count
2 unused
â–¶
1 1 Reply
1 n keysyms-per-keycode
2 CARD16 sequence number
4 nm reply length (m = count field
from the request)
24 unused
4nm LISTofKEYSYM keysyms
ChangeKeyboardControl
1 102 opcode
1 unused
2 2+n request length
4 BITMASK value-mask (has n bits set to 1)
#x0001 key-click-percent
#x0002 bell-percent
#x0004 bell-pitch
#x0008 bell-duration
#x0010 led
#x0020 led-mode
#x0040 key
#x0080 auto-repeat-mode
4n LISTofVALUE value-list
VALUEs
1 INT8 key-click-percent
1 INT8 bell-percent
2 INT16 bell-pitch
2 INT16 bell-duration
1 CARD8 led
1 led-mode
0 Off
1 On
1 KEYCODE key
1 auto-repeat-mode
0 Off
1 On
2 Default
GetKeyboardControl
1 103 opcode
1 unused
2 1 request length
â–¶
1 1 Reply
1 global-auto-repeat
0 Off
1 On
2 CARD16 sequence number
4 5 reply length
4 CARD32 led-mask
1 CARD8 key-click-percent
1 CARD8 bell-percent
2 CARD16 bell-pitch
2 CARD16 bell-duration
2 unused
32 LISTofCARD8 auto-repeats
Bell
1 104 opcode
1 INT8 percent
2 1 request length
ChangePointerControl
1 105 opcode
1 unused
2 3 request length
2 INT16 acceleration-numerator
2 INT16 acceleration-denominator
2 INT16 threshold
1 BOOL do-acceleration
1 BOOL do-threshold
GetPointerControl
1 106 opcode
1 unused
2 1 request length
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 acceleration-numerator
2 CARD16 acceleration-denominator
2 CARD16 threshold
18 unused
SetScreenSaver
1 107 opcode
1 unused
2 3 request length
2 INT16 timeout
2 INT16 interval
1 prefer-blanking
0 No
1 Yes
2 Default
1 allow-exposures
0 No
1 Yes
2 Default
2 unused
GetScreenSaver
1 108 opcode
1 unused
2 1 request length
â–¶
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
2 CARD16 timeout
2 CARD16 interval
1 prefer-blanking
0 No
1 Yes
1 allow-exposures
0 No
1 Yes
18 unused
ChangeHosts
1 109 opcode
1 mode
0 Insert
1 Delete
2 2+(n+p)/4 request length
1 family
0 Internet
1 DECnet
2 Chaos
1 unused
2 n length of address
n LISTofCARD8 address
p unused, p=pad(n)
ListHosts
1 110 opcode
1 unused
2 1 request length
â–¶
1 1 Reply
1 mode
0 Disabled
1 Enabled
2 CARD16 sequence number
4 n/4 reply length
2 CARD16 number of HOSTs in hosts
22 unused
n LISTofHOST hosts (n always a multiple of 4)
SetAccessControl
1 111 opcode
1 mode
0 Disable
1 Enable
2 1 request length
SetCloseDownMode
1 112 opcode
1 mode
0 Destroy
1 RetainPermanent
2 RetainTemporary
2 1 request length
KillClient
1 113 opcode
1 unused
2 2 request length
4 CARD32 resource
0 AllTemporary
RotateProperties
1 114 opcode
1 unused
2 3+n request length
4 WINDOW window
2 n number of properties
2 INT16 delta
4n LISTofATOM properties
ForceScreenSaver
1 115 opcode
1 mode
0 Reset
1 Activate
2 1 request length
SetPointerMapping
1 116 opcode
1 n length of map
2 1+(n+p)/4 request length
n LISTofCARD8 map
p unused, p=pad(n)
â–¶
1 1 Reply
1 status
0 Success
1 Busy
2 CARD16 sequence number
4 0 reply length
24 unused
GetPointerMapping
1 117 opcode
1 unused
2 1 request length
â–¶
1 1 Reply
1 n length of map
2 CARD16 sequence number
4 (n+p)/4 reply length
24 unused
n LISTofCARD8 map
p unused, p=pad(n)
SetModifierMapping
1 118 opcode
1 n keycodes-per-modifier
2 1+2n request length
8n LISTofKEYCODE keycodes
â–¶
1 1 Reply
1 status
0 Success
1 Busy
2 Failed
2 CARD16 sequence number
4 0 reply length
24 unused
GetModifierMapping
1 119 opcode
1 unused
2 1 request length
â–¶
1 1 Reply
1 n keycodes-per-modifier
2 CARD16 sequence number
4 2n reply length
24 unused
8n LISTofKEYCODE keycodes
NoOperation
1 127 opcode
1 unused
2 1+n request length
4n unused
Events
Event encoding
KeyPress
1 2 code
1 KEYCODE detail
2 CARD16 sequence number
4 TIMESTAMP time
4 WINDOW root
4 WINDOW event
4 WINDOW child
0 None
2 INT16 root-x
2 INT16 root-y
2 INT16 event-x
2 INT16 event-y
2 SETofKEYBUTMASK state
1 BOOL same-screen
1 unused
KeyRelease
1 3 code
1 KEYCODE detail
2 CARD16 sequence number
4 TIMESTAMP time
4 WINDOW root
4 WINDOW event
4 WINDOW child
0 None
2 INT16 root-x
2 INT16 root-y
2 INT16 event-x
2 INT16 event-y
2 SETofKEYBUTMASK state
1 BOOL same-screen
1 unused
ButtonPress
1 4 code
1 BUTTON detail
2 CARD16 sequence number
4 TIMESTAMP time
4 WINDOW root
4 WINDOW event
4 WINDOW child
0 None
2 INT16 root-x
2 INT16 root-y
2 INT16 event-x
2 INT16 event-y
2 SETofKEYBUTMASK state
1 BOOL same-screen
1 unused
ButtonRelease
1 5 code
1 BUTTON detail
2 CARD16 sequence number
4 TIMESTAMP time
4 WINDOW root
4 WINDOW event
4 WINDOW child
0 None
2 INT16 root-x
2 INT16 root-y
2 INT16 event-x
2 INT16 event-y
2 SETofKEYBUTMASK state
1 BOOL same-screen
1 unused
MotionNotify
1 6 code
1 detail
0 Normal
1 Hint
2 CARD16 sequence number
4 TIMESTAMP time
4 WINDOW root
4 WINDOW event
4 WINDOW child
0 None
2 INT16 root-x
2 INT16 root-y
2 INT16 event-x
2 INT16 event-y
2 SETofKEYBUTMASK state
1 BOOL same-screen
1 unused
EnterNotify
1 7 code
1 detail
0 Ancestor
1 Virtual
2 Inferior
3 Nonlinear
4 NonlinearVirtual
2 CARD16 sequence number
4 TIMESTAMP time
4 WINDOW root
4 WINDOW event
4 WINDOW child
0 None
2 INT16 root-x
2 INT16 root-y
2 INT16 event-x
2 INT16 event-y
2 SETofKEYBUTMASK state
1 mode
0 Normal
1 Grab
2 Ungrab
1 same-screen, focus
#x01 focus (1 is True, 0 is False)
#x02 same-screen (1 is True, 0 is False)
#xFC unused
LeaveNotify
1 8 code
1 detail
0 Ancestor
1 Virtual
2 Inferior
3 Nonlinear
4 NonlinearVirtual
2 CARD16 sequence number
4 TIMESTAMP time
4 WINDOW root
4 WINDOW event
4 WINDOW child
0 None
2 INT16 root-x
2 INT16 root-y
2 INT16 event-x
2 INT16 event-y
2 SETofKEYBUTMASK state
1 mode
0 Normal
1 Grab
2 Ungrab
1 same-screen, focus
#x01 focus (1 is True, 0 is False)
#x02 same-screen (1 is True, 0 is False)
#xFC unused
FocusIn
1 9 code
1 detail
0 Ancestor
1 Virtual
2 Inferior
3 Nonlinear
4 NonlinearVirtual
5 Pointer
6 PointerRoot
7 None
2 CARD16 sequence number
4 WINDOW event
1 mode
0 Normal
1 Grab
2 Ungrab
3 WhileGrabbed
23 unused
FocusOut
1 10 code
1 detail
0 Ancestor
1 Virtual
2 Inferior
3 Nonlinear
4 NonlinearVirtual
5 Pointer
6 PointerRoot
7 None
2 CARD16 sequence number
4 WINDOW event
1 mode
0 Normal
1 Grab
2 Ungrab
3 WhileGrabbed
23 unused
KeymapNotify
1 11 code
31 LISTofCARD8 keys (byte for keycodes 0-7 is
omitted)
Expose
1 12 code
1 unused
2 CARD16 sequence number
4 WINDOW window
2 CARD16 x
2 CARD16 y
2 CARD16 width
2 CARD16 height
2 CARD16 count
14 unused
GraphicsExposure
1 13 code
1 unused
2 CARD16 sequence number
4 DRAWABLE drawable
2 CARD16 x
2 CARD16 y
2 CARD16 width
2 CARD16 height
2 CARD16 minor-opcode
2 CARD16 count
1 CARD8 major-opcode
11 unused
NoExposure
1 14 code
1 unused
2 CARD16 sequence number
4 DRAWABLE drawable
2 CARD16 minor-opcode
1 CARD8 major-opcode
21 unused
VisibilityNotify
1 15 code
1 unused
2 CARD16 sequence number
4 WINDOW window
1 state
0 Unobscured
1 PartiallyObscured
2 FullyObscured
23 unused
CreateNotify
1 16 code
1 unused
2 CARD16 sequence number
4 WINDOW parent
4 WINDOW window
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border-width
1 BOOL override-redirect
9 unused
DestroyNotify
1 17 code
1 unused
2 CARD16 sequence number
4 WINDOW event
4 WINDOW window
20 unused
UnmapNotify
1 18 code
1 unused
2 CARD16 sequence number
4 WINDOW event
4 WINDOW window
1 BOOL from-configure
19 unused
MapNotify
1 19 code
1 unused
2 CARD16 sequence number
4 WINDOW event
4 WINDOW window
1 BOOL override-redirect
19 unused
MapRequest
1 20 code
1 unused
2 CARD16 sequence number
4 WINDOW parent
4 WINDOW window
20 unused
ReparentNotify
1 21 code
1 unused
2 CARD16 sequence number
4 WINDOW event
4 WINDOW window
4 WINDOW parent
2 INT16 x
2 INT16 y
1 BOOL override-redirect
11 unused
ConfigureNotify
1 22 code
1 unused
2 CARD16 sequence number
4 WINDOW event
4 WINDOW window
4 WINDOW above-sibling
0 None
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border-width
1 BOOL override-redirect
5 unused
ConfigureRequest
1 23 code
1 stack-mode
0 Above
1 Below
2 TopIf
3 BottomIf
4 Opposite
2 CARD16 sequence number
4 WINDOW parent
4 WINDOW window
4 WINDOW sibling
0 None
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border-width
2 BITMASK value-mask
#x0001 x
#x0002 y
#x0004 width
#x0008 height
#x0010 border-width
#x0020 sibling
#x0040 stack-mode
4 unused
GravityNotify
1 24 code
1 unused
2 CARD16 sequence number
4 WINDOW event
4 WINDOW window
2 INT16 x
2 INT16 y
16 unused
ResizeRequest
1 25 code
1 unused
2 CARD16 sequence number
4 WINDOW window
2 CARD16 width
2 CARD16 height
20 unused
CirculateNotify
1 26 code
1 unused
2 CARD16 sequence number
4 WINDOW event
4 WINDOW window
4 WINDOW unused
1 place
0 Top
1 Bottom
15 unused
CirculateRequest
1 27 code
1 unused
2 CARD16 sequence number
4 WINDOW parent
4 WINDOW window
4 unused
1 place
0 Top
1 Bottom
15 unused
PropertyNotify
1 28 code
1 unused
2 CARD16 sequence number
4 WINDOW window
4 ATOM atom
4 TIMESTAMP time
1 state
0 NewValue
1 Deleted
15 unused
SelectionClear
1 29 code
1 unused
2 CARD16 sequence number
4 TIMESTAMP time
4 WINDOW owner
4 ATOM selection
16 unused
SelectionRequest
1 30 code
1 unused
2 CARD16 sequence number
4 TIMESTAMP time
0 CurrentTime
4 WINDOW owner
4 WINDOW requestor
4 ATOM selection
4 ATOM target
4 ATOM property
0 None
4 unused
SelectionNotify
1 31 code
1 unused
2 CARD16 sequence number
4 TIMESTAMP time
0 CurrentTime
4 WINDOW requestor
4 ATOM selection
4 ATOM target
4 ATOM property
0 None
8 unused
ColormapNotify
1 32 code
1 unused
2 CARD16 sequence number
4 WINDOW window
4 COLORMAP colormap
0 None
1 BOOL new
1 state
0 Uninstalled
1 Installed
18 unused
ClientMessage
1 33 code
1 CARD8 format
2 CARD16 sequence number
4 WINDOW window
4 ATOM type
20 data
MappingNotify
1 34 code
1 unused
2 CARD16 sequence number
1 request
0 Modifier
1 Keyboard
2 Pointer
1 KEYCODE first-keycode
1 CARD8 count
25 unused
xorgproto-2023.2/specs/xproto/x11protocol.xml 0000644 0001750 0001750 00000005034 14443010026 016147 0000000 0000000
%defs;
]>
X Window System Protocol
X Consortium Standard
Robert
W.
Scheifler
X Consortium, Inc.
X Version 11, Release &fullrelvers;
Version 1.0
1986 1987 1988 1994 2004
The Open Group
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
OPEN GROUP 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.
Except as contained in this notice, the name of the Open Group 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 Open Group.
X Window System is a trademark of The Open Group.
xorgproto-2023.2/specs/xproto/glossary.xml 0000644 0001750 0001750 00000141103 14443010026 015615 0000000 0000000
Glossary
Access control list
Access control list
X maintains a list of hosts from which client programs can be run.
By default,
only programs on the local host and hosts specified in an initial list read
by the server can use the display.
Clients on the local host can change this access control list.
Some server implementations can also implement other authorization mechanisms
in addition to or in place of this mechanism.
The action of this mechanism can be conditional based on the authorization
protocol name and data received by the server at connection setup.
Active grab
Active grab
A grab is active when the pointer or keyboard is actually owned by
the single grabbing client.
Ancestors
Ancestors
If W is an inferior of A, then A is an ancestor of W.
Atom
Atom
An atom is a unique ID corresponding to a string name.
Atoms are used to identify properties, types, and selections.
Background
Background
An
InputOutput
Backing store
Backing store
When a server maintains the contents of a window,
the pixels saved off screen are known as a backing store.
Bit gravity
Bit gravity
When a window is resized,
the contents of the window are not necessarily discarded.
It is possible to request that the server relocate the previous contents
to some region of the window (though no guarantees are made).
This attraction of window contents for some location of
a window is known as bit gravity.
Bit plane
Bit plane
When a pixmap or window is thought of as a stack of bitmaps,
each bitmap is called a bit plane or plane.
Bitmap
Bitmap
A bitmap is a pixmap of depth one.
Border
Border
An
InputOutput
Button grabbing
Button grabbing
Buttons on the pointer may be passively grabbed by a client.
When the button is pressed,
the pointer is then actively grabbed by the client.
Byte order
Byte order
For image (pixmap/bitmap) data,
the server defines the byte order,
and clients with different native byte ordering must swap bytes as necessary.
For all other parts of the protocol,
the client defines the byte order,
and the server swaps bytes as necessary.
Children
Children Window children
The children of a window are its first-level subwindows.
Client
Client
An application program connects to the window system server by some
interprocess communication path, such as a TCP connection or a
shared memory buffer.
This program is referred to as a client of the window system server.
More precisely,
the client is the communication path itself;
a program with multiple paths open to the server is viewed as
multiple clients by the protocol.
Resource lifetimes are controlled by connection lifetimes,
not by program lifetimes.
Clipping region
Clipping region
In a graphics context ,
a bitmap or list of rectangles can be specified
to restrict output to a particular region of the window.
The image defined by the bitmap or rectangles is called a clipping region.
Colormap
Colormap
A colormap consists of a set of entries defining color values.
The colormap associated with a window is used to display the contents of
the window; each pixel value indexes the colormap to produce RGB values
that drive the guns of a monitor.
Depending on hardware limitations,
one or more colormaps may be installed at one time,
so that windows associated with those maps display with correct colors.
Connection
Connection
The interprocess communication path between the server and client
program is known as a connection.
A client program typically (but not necessarily) has one
connection to the server over which requests and events are sent.
Containment
Containment
A window contains
the pointer if the window is viewable and the
hotspot of the cursor is
within a visible region of the window or a
visible region of one of its inferiors.
The border of the window is included as part of the window for containment.
The pointer is in
a window if the window contains the pointer
but no inferior contains the pointer.
Coordinate system
Coordinate system
The coordinate system has the X axis horizontal and the Y axis vertical,
with the origin [0, 0] at the upper left.
Coordinates are integral,
in terms of pixels,
and coincide with pixel centers.
Each window and pixmap has its own coordinate system.
For a window,
the origin is inside the border at the inside upper left.
Cursor
Cursor
A cursor is the visible shape of the pointer on a screen.
It consists of a hotspot ,
a source bitmap, a shape bitmap, and a pair of colors.
The cursor defined for a window controls the visible appearance
when the pointer is in that window.
Depth
Depth
The depth of a window or pixmap is the number of bits per pixel that it has.
The depth of a graphics context is the depth of the drawables it can be
used in conjunction with for graphics output.
Device
Device
Keyboards, mice, tablets, track-balls, button boxes, and so on are all
collectively known as input devices.
The core protocol only deals with two devices,
the keyboard
and the pointer.
DirectColor
DirectColor
DirectColor
is a class of colormap in which a pixel value is decomposed into three
separate subfields for indexing.
The first subfield indexes an array to produce red intensity values.
The second subfield indexes a second array to produce blue intensity values.
The third subfield indexes a third array to produce green intensity values.
The RGB values can be changed dynamically.
Display
Display
A server, together with its screens and input devices, is called a display.
Drawable
Drawable
Both windows and pixmaps can be used as sources and destinations in
graphics operations.
These windows and pixmaps are collectively known as drawables.
However, an
InputOnly
Event
Event
Clients are informed of information asynchronously by means of events.
These events can be generated either asynchronously from devices
or as side effects of client requests.
Events are grouped into types.
The server never sends events to a client unless the
client has specifically asked to be informed of that type of event.
However, other clients can force events to be sent to other clients.
Events are typically reported relative to a window.
Event mask
Event mask
Events are requested relative to a window.
The set of event types that a client requests relative to a window
is described by using an event mask.
Event synchronization
Event synchronization
There are certain race conditions possible when demultiplexing device
events to clients (in particular deciding where pointer and keyboard
events should be sent when in the middle of window management
operations).
The event synchronization mechanism allows synchronous processing
of device events.
Event propagation
Event propagation
Device-related events propagate from the source window to ancestor
windows until some client has expressed interest in handling that type
of event or until the event is discarded explicitly.
Event source
Event source
The window the pointer is in is the source of a device-related
event.
Exposure event
Event Exposure
Servers do not guarantee to preserve the contents of windows when
windows are obscured or reconfigured.
Exposure events are sent to clients to inform them when contents
of regions of windows have been lost.
Extension
Extension
Named extensions to the core protocol can be defined to extend the
system.
Extension to output requests, resources, and event types are
all possible and are expected.
Focus window
Focus window
The focus window is another term for the input focus .
Font
Font
A font is a matrix of glyphs (typically characters).
The protocol does no translation or interpretation of character sets.
The client simply indicates values used to index the glyph array.
A font contains additional metric information to determine interglyph
and interline spacing.
GC, GContext
GC Graphics context GContext Graphics context
GC and gcontext are abbreviations for graphics context .
Glyph
Glyph
A glyph is an image, typically of a character, in a font.
Grab
Grab Active grab Passive grab
Keyboard keys, the keyboard, pointer buttons, the pointer, and the
server can be grabbed for exclusive use by a client.
In general,
these facilities are not intended to be used by normal applications
but are intended for various input and window managers to implement
various styles of user interfaces.
Graphics context
Graphics context
Various information for graphics output is stored in a graphics context
such as foreground pixel, background pixel, line width,
clipping region ,
and so on.
A graphics context can only be used with drawables that have the same root
and the same depth as the graphics context.
Gravity
Gravity
See bit gravity
and window gravity .
GrayScale
GrayScale
GrayScale
can be viewed as a degenerate case of
PseudoColor
Hotspot
Hotspot
A cursor has an associated hotspot that defines the point in the
cursor corresponding to the coordinates reported for the pointer.
Identifier
Identifier
An identifier is a unique value associated with a resource that clients use
to name that resource.
The identifier can be used over any connection.
Inferiors
Inferiors
The inferiors of a window are all of the subwindows nested below it:
the children, the children's children, and so on.
Input focus
Input focus
The input focus is normally a window defining the scope for
processing of keyboard input.
If a generated keyboard event would normally be reported to this window
or one of its inferiors,
the event is reported normally.
Otherwise, the event is reported with respect to
the focus window.
The input focus also can be set such that all
keyboard events are discarded and such that the focus
window is dynamically taken to be the root window of whatever screen
the pointer is on at each keyboard event.
Input manager
Input manager
Control over keyboard input is typically provided by an input manager client.
InputOnly window
Window InputOnly
An
InputOnly
window is a window that cannot be used for graphics requests.
InputOnly
windows are invisible and can be used to control such things
as cursors, input event generation, and grabbing.
InputOnly
windows cannot have
InputOutput
windows as inferiors.
InputOutput window
Window InputOutput
An
InputOutput
window is the normal kind of opaque window, used for both input and output.
InputOutput
windows can have both
InputOutput
and
InputOnly
windows as inferiors.
Key grabbing
Key grabbing
Keys on the keyboard can be passively grabbed by a client.
When the key is pressed,
the keyboard is then actively grabbed by the client.
Keyboard grabbing
Keyboard grabbing
A client can actively grab control of the keyboard, and key events
will be sent to that client rather than the client the events would
normally have been sent to.
Keysym
Keysym
An encoding of a symbol on a keycap on a keyboard.
Mapped
Mapped window
A window is said to be mapped if a map call has been performed on it.
Unmapped windows and their inferiors are never viewable or visible.
Modifier keys
Modifier keys Key modifier Modifier keys
Shift, Control, Meta, Super, Hyper, Alt, Compose, Apple, CapsLock,
ShiftLock, and similar keys are called modifier keys.
Monochrome
Monochrome
Monochrome is a special case of
StaticGray
Obscure
Obscure
A window is obscured if some other window obscures it.
Window A obscures window B if both are viewable
InputOutput
Occlude
Occlude
A window is occluded if some other window occludes it.
Window A occludes window B if both are mapped, A is higher in the global
stacking order, and the rectangle defined by the outside edges of A
intersects the rectangle defined by the outside edges of B.
Note the distinction between occludes and obscures.
Also note that window borders are included in the calculation.
Padding
Padding
Some padding bytes are inserted in the data stream to maintain
alignment of the protocol requests on natural boundaries.
This increases ease of portability to some machine architectures.
Parent window
Window parent
If C is a child of P,
then P is the parent of C.
Passive grab
Passive grab
Grabbing a key or button is a passive grab.
The grab activates when the key or button is actually pressed.
Pixel value
Pixel value
A pixel is an N-bit value, where N is the number of bit planes used
in a particular window or pixmap (that is,
N is the depth of the window or pixmap).
For a window,
a pixel value indexes a colormap to derive an actual color to be displayed.
Pixmap
Pixmap
A pixmap is a three-dimensional array of bits.
A pixmap is normally thought of as a two-dimensional array of pixels,
where each pixel can be a value from 0 to (2^N)-1
and where N is the depth (z axis) of the pixmap.
A pixmap can also be thought of as a stack of N bitmaps.
Plane
Plane
When a pixmap or window is thought of as a stack of bitmaps,
each bitmap is called a plane or bit plane.
Plane mask
Plane mask
Graphics operations can be restricted to only affect a subset of bit
planes of a destination.
A plane mask is a bit mask describing which planes are to be modified.
The plane mask is stored in a graphics context.
Pointer
Pointer
The pointer is the pointing device attached to the cursor
and tracked on the screens.
Pointer grabbing
Pointer grabbing
A client can actively grab control of the pointer.
Then button and motion events will be sent to that client
rather than the client the events would normally have been sent to.
Pointing device
Pointing device
A pointing device is typically a mouse, tablet, or some other
device with effective dimensional motion.
There is only one visible cursor defined by the core protocol,
and it tracks whatever pointing device is attached as the pointer.
Property
Property
Windows may have associated properties,
which consist of a name, a type, a data format, and some data.
The protocol places no interpretation on properties.
They are intended as a general-purpose naming mechanism for clients.
For example, clients might use properties to share information such as resize
hints, program names, and icon formats with a window manager.
Property list
Property list
The property list of a window is the list of properties that have
been defined for the window.
PseudoColor
PseudoColor
PseudoColor
is a class of colormap in which a pixel value indexes the colormap to
produce independent red, green, and blue values;
that is, the colormap is viewed as an array of triples (RGB values).
The RGB values can be changed dynamically.
Redirecting control
Redirecting control
Window managers (or client programs) may want to enforce window layout
policy in various ways.
When a client attempts to change the size or position of a window,
the operation may be redirected to a specified client
rather than the operation actually being performed.
Reply
Reply
Information requested by a client program is sent back to the client
with a reply.
Both events and replies are multiplexed on the same connection.
Most requests do not generate replies,
although some requests generate multiple replies.
Request
Request
A command to the server is called a request.
It is a single block of data sent over a connection.
Resource
Resource
Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are
known as resources.
They all have unique identifiers associated with them for naming purposes.
The lifetime of a resource usually is bounded by the lifetime of the connection
over which the resource was created.
RGB values
RGB values
Red, green, and blue (RGB) intensity values are used to define color.
These values are always represented as 16-bit unsigned numbers,
with 0 being the minimum intensity and 65535 being the maximum intensity.
The server scales the values to match the display hardware.
Root
Root
The root of a pixmap, colormap, or graphics context is the same as the root of
whatever drawable was used when the pixmap, colormap, or graphics context was
created.
The root of a window is the root window under which the window was created.
Root window
Window root
Each screen has a root window covering it.
It cannot be reconfigured or unmapped,
but it otherwise acts as a full-fledged window.
A root window has no parent.
Save set
Save set
The save set of a client is a list of other clients' windows that,
if they are inferiors of one of the client's windows at connection close,
should not be destroyed and that should be remapped if currently unmapped.
Save sets are typically used by window managers to avoid
lost windows if the manager terminates abnormally.
Scanline
Scanline
A scanline is a list of pixel or bit values viewed as a horizontal
row (all values having the same y coordinate) of an image, with the
values ordered by increasing x coordinate.
Scanline order
Scanline order
An image represented in scanline order contains scanlines ordered by
increasing y coordinate.
Screen
Screen
A server can provide several independent screens,
which typically have physically independent monitors.
This would be the expected configuration when there is only a single keyboard
and pointer shared among the screens.
Selection
Selection
A selection can be thought of as an indirect property with dynamic
type; that is, rather than having the property stored in the server,
it is maintained by some client (the owner
).
A selection is global in nature and is thought of as belonging to the user
(although maintained by clients), rather than as being private to a particular
window subhierarchy or a particular set of clients.
When a client asks for the contents of a selection,
it specifies a selection target type
.
This target type can be used to control the transmitted representation of the
contents.
For example,
if the selection is the last thing the user clicked on
and that is currently an image, then the target type might specify
whether the contents of the image should be sent in XY format or Z format.
The target type can also be used to control the class of contents transmitted;
for example, asking for the looks
(fonts, line
spacing, indentation, and so on) of a paragraph selection rather than the
text of the paragraph.
The target type can also be used for other purposes.
The protocol does not constrain the semantics.
Server
Server
The server provides the basic windowing mechanism.
It handles connections from clients,
multiplexes graphics requests onto the screens,
and demultiplexes input back to the appropriate clients.
Server grabbing
Server grabbing
The server can be grabbed by a single client for exclusive use.
This prevents processing of any requests from other client connections until
the grab is completed.
This is typically only a transient state for
such things as rubber-banding, pop-up menus, or to execute requests
indivisibly.
Sibling
Sibling
Children of the same parent window are known as sibling windows.
Stacking order
Stacking order
Sibling windows may stack on top of each other.
Windows above other windows both obscure and occlude those lower windows.
This is similar to paper on a desk.
The relationship between sibling windows is known as the stacking order.
StaticColor
StaticColor
StaticColor
can be viewed as a degenerate case of
PseudoColor
StaticGray
StaticGray
StaticGray
can be viewed as a degenerate case of
GrayScale
Stipple
Stipple
A stipple pattern is a bitmap that is used to tile a region that will serve
as an additional clip mask for a fill operation with the foreground
color.
String Equivalence
String Equivalence
Two ISO Latin-1 STRING8 values are considered equal if they are the same
length and if corresponding bytes are either equal or are equivalent as
follows: decimal values 65 to 90 inclusive (characters A
to Z
) are
pairwise equivalent to decimal values 97 to 122 inclusive
(characters a
to z
), decimal values 192 to 214 inclusive
(characters A grave
to O diaeresis
) are pairwise equivalent to decimal
values 224 to 246 inclusive (characters a grave
to o diaeresis
),
and decimal values 216 to 222 inclusive (characters O oblique
to THORN
)
are pairwise equivalent to decimal values 246 to 254 inclusive
(characters o oblique
to thorn
).
Tile
Tile
A pixmap can be replicated in two dimensions to tile a region.
The pixmap itself is also known as a tile.
Timestamp
Timestamp CurrentTime
A timestamp is a time value, expressed in milliseconds.
It typically is the time since the last
server reset.
Timestamp values wrap around (after about 49.7 days).
The server, given its current time is represented by timestamp T,
always interprets timestamps from clients by treating half of the
timestamp space as being earlier in time than T and half of the
timestamp space as being later in time than T.
One timestamp value (named
CurrentTime )
is never generated by the server.
This value is reserved for use in requests to represent the current
server time.
TrueColor
TrueColor
TrueColor
can be viewed as a degenerate case of
DirectColor
Type
Type
A type is an arbitrary atom used to identify the interpretation of
property data.
Types are completely uninterpreted by the server
and are solely for the benefit of clients.
Viewable
Viewable
A window is viewable if it and all of its ancestors are mapped.
This does not imply that any portion of the window is actually visible.
Graphics requests can be performed on a window when it is not viewable,
but output will not be retained unless the server is maintaining
backing store.
Visible
Visible
A region of a window is visible if someone looking at the screen can
actually see it;
that is, the window is viewable and the region is not occluded by any
other window.
Window gravity
Window gravity
When windows are resized,
subwindows may be repositioned automatically relative to some position
in the window.
This attraction of a subwindow to some part of its parent is known
as window gravity.
Window manager
Window manager
Manipulation of windows on the screen and much of the user interface
(policy) is typically provided by a window manager client.
XYFormat
XYFormat
The data for a pixmap is said to be in XY format if it is organized as
a set of bitmaps representing individual bit planes, with the planes
appearing from most-significant to least-significant in bit order.
ZFormat
ZFormat
The data for a pixmap is said to be in Z format if it is organized as
a set of pixel values in scanline order.
xorgproto-2023.2/specs/xproto/sect1-9.xml 0000644 0001750 0001750 00001620245 14443010026 015151 0000000 0000000
Acknowledgements
The primary contributors to the X11 protocol are:
Dave Carver (Digital HPW) Branko Gerovac (Digital HPW) Jim Gettys (MIT/Project Athena, Digital) Phil Karlton (Digital WSL) Scott McGregor (Digital SSG) Ram Rao (Digital UEG) David Rosenthal (Sun) Dave Winchell (Digital UEG)
The implementors of initial server who provided useful
input are:
Susan Angebranndt (Digital) Raymond Drewry (Digital) Todd Newman (Digital)
The invited reviewers who provided useful input are:
Andrew Cherenson (Berkeley) Burns Fisher (Digital) Dan Garfinkel (HP) Leo Hourvitz (Next) Brock Krizan (HP) David Laidlaw (Stellar) Dave Mellinger (Interleaf) Ron Newman (MIT) John Ousterhout (Berkeley) Andrew Palay (ITC CMU) Ralph Swick (MIT) Craig Taylor (Sun) Jeffery Vroom (Stellar)
Thanks go to Al Mento of Digital's UEG Documentation Group for
formatting this document.
This document does not attempt to provide the rationale or pragmatics required
to fully understand the protocol or to place it in perspective within a
complete system.
The protocol contains many management mechanisms that are not intended for
normal applications.
Not all mechanisms are needed to build a particular user interface.
It is important to keep in mind that the protocol is intended to
provide mechanism, not policy.
Robert W. Scheifler
X Consortium, Inc.
Protocol Formats
Syntactic Conventions
The rest of this document uses the following syntactic conventions.
The syntax {...} encloses a set of alternatives.
The syntax [...] encloses a set of structure components.
In general, TYPEs are in uppercase and
AlternativeValues
are capitalized.
Requests in
RequestName
arg1 : type1
...
argN : typeN
â–¶
result1: type1
...
resultM: typeM
Errors: kind1, ..., kindK
Description.
If no â–¶ is present in the description,
then the request has no reply (it is asynchronous),
although errors may still be reported.
If â–¶+ is used,
then one or more replies can be generated for a single request.
Events in
EventName
value1 : type1
...
valueN : typeN
Description.
Common Types
Name
Value
LISTofFOOTypes LISTofFOO
A type name of the form LISTofFOO means a counted list of elements of type
FOO.
The size of the length field may vary (it is not necessarily the same
size as a FOO), and in some cases, it may be implicit.
It is fully specified in Appendix B.
Except where explicitly noted,
zero-length lists are legal.
BITMASKTypes BITMASK LISTofVALUETypes LISTofVALUE
The types BITMASK and LISTofVALUE are somewhat special.
Various requests contain arguments of the form:
value-mask : BITMASK
value-list : LISTofVALUE
These are used to allow the client to specify a subset of a heterogeneous
collection of optional arguments.
The value-mask specifies which arguments are to be provided;
each such argument is assigned a unique bit position.
The representation of the BITMASK will typically contain more bits than
there are defined arguments.
The unused bits in the value-mask must be zero (or the server generates a
Value
error).
The value-list contains one value for each bit set to 1 in the mask,
from least significant to most significant bit in the mask.
Each value is represented with four bytes,
but the actual value occupies only the least significant bytes as required.
The values of the unused bytes do not matter.
ORTypes OR
A type of the form "T1 or ... or Tn" means the union of the indicated types.
A single-element type is given as the element without enclosing braces.
WINDOWTypes WINDOW
32-bit value (top three bits guaranteed to be zero)
PIXMAPTypes PIXMAP
32-bit value (top three bits guaranteed to be zero)
CURSORTypes CURSOR
32-bit value (top three bits guaranteed to be zero)
FONTTypes FONT
32-bit value (top three bits guaranteed to be zero)
GCONTEXTTypes GCONTEXT
32-bit value (top three bits guaranteed to be zero)
COLORMAPTypes COLORMAP
32-bit value (top three bits guaranteed to be zero)
DRAWABLETypes DRAWABLE
WINDOW or PIXMAP
FONTABLETypes FONTABLE
FONT or GCONTEXT
ATOMTypes ATOM
32-bit value (top three bits guaranteed to be zero)
VISUALIDTypes VISUALID
32-bit value (top three bits guaranteed to be zero)
VALUETypes VALUE
32-bit quantity (used only in LISTofVALUE)
BYTETypes BYTE
8-bit value
INT8Types INT8
8-bit signed integer
INT16Types INT16
16-bit signed integer
INT32Types INT32
32-bit signed integer
CARD8Types CARD8
8-bit unsigned integer
CARD16Types CARD16
16-bit unsigned integer
CARD32Types CARD32
32-bit unsigned integer
TIMESTAMPTypes TIMESTAMP
CARD32
BITGRAVITYTypes BITGRAVITY
{ Forget ,
Static ,
NorthWest ,
North ,
NorthEast ,
West ,
Center ,
East ,
SouthWest ,
South ,
SouthEast }
WINGRAVITYTypes WINGRAVITY
{ Unmap ,
Static ,
NorthWest ,
North ,
NorthEast ,
West ,
Center ,
East ,
SouthWest ,
South ,
SouthEast }
BOOLTypes BOOL
{ True ,
False }
EVENTTypes EVENT
{ KeyPress ,
KeyRelease ,
OwnerGrabButton ,
ButtonPress ,
ButtonRelease ,
EnterWindow ,
LeaveWindow ,
PointerMotion ,
PointerMotionHint ,
Button1Motion ,
Button2Motion ,
Button3Motion ,
Button4Motion ,
Button5Motion ,
ButtonMotion ,
Exposure ,
VisibilityChange ,
StructureNotify ,
ResizeRedirect ,
SubstructureNotify ,
SubstructureRedirect ,
FocusChange ,
PropertyChange ,
ColormapChange ,
KeymapState }
POINTEREVENTTypes POINTEREVENT
{ ButtonPress ,
ButtonRelease ,
EnterWindow ,
LeaveWindow ,
PointerMotion ,
PointerMotionHint ,
Button1Motion ,
Button2Motion ,
Button3Motion ,
Button4Motion ,
Button5Motion ,
ButtonMotion ,
KeymapState }
DEVICEEVENTTypes DEVICEEVENT
{ KeyPress ,
KeyRelease ,
ButtonPress ,
ButtonRelease ,
PointerMotion ,
Button1Motion ,
Button2Motion ,
Button3Motion ,
Button4Motion ,
Button5Motion ,
ButtonMotion }
KEYSYMTypes KEYSYM
32-bit value (top three bits guaranteed to be zero)
KEYCODETypes KEYCODE
CARD8
BUTTONTypes BUTTON
CARD8
KEYMASKTypes KEYMASK
{ Shift ,
Lock ,
Control ,
Mod1 ,
Mod2 ,
Mod3 ,
Mod4 ,
Mod5 }
BUTMASKTypes BUTMASK
{ Button1 ,
Button2 ,
Button3 ,
Button4 ,
Button5 }
KEYBUTMASKTypes KEYBUTMASK
KEYMASK or BUTMASK
STRING8Types STRING8
LISTofCARD8
STRING16Types STRING16
LISTofCHAR2B
CHAR2BTypes CHAR2B
[byte1, byte2: CARD8]
POINTTypes POINT
[x, y: INT16]
RECTANGLETypes RECTANGLE
[x, y: INT16,
width, height: CARD16]
ARCTypes ARC
[x, y: INT16,
width, height: CARD16,
angle1, angle2: INT16]
HOSTTypes HOST
[family:
{ Internet ,
InternetV6 ,
ServerInterpreted ,
DECnet ,
Chaos }
address: LISTofBYTE]
The [x,y] coordinates of a RECTANGLE specify the upper-left corner.
The primary interpretation of large characters in a STRING16 is that they
are composed of two bytes used to index a two-dimensional matrix,
hence, the use of CHAR2B rather than CARD16.
This corresponds to the JIS/ISO method of indexing 2-byte characters.
It is expected that most large fonts will be defined with 2-byte
matrix indexing.
For large fonts constructed with linear indexing,
a CHAR2B can be interpreted as a 16-bit number by treating byte1 as
the most significant byte.
This means that clients should always transmit such
16-bit character values most significant byte first, as the server will never
byte-swap CHAR2B quantities.
The length, format, and interpretation of a HOST address are specific to the
family (see
ChangeHosts
request).
Errors
In general, when a request terminates with an error,
the request has no side effects (that is, there is no partial execution).
The only requests for which this is not true are
ChangeWindowAttributes ,
ChangeGC ,
PolyText8 ,
PolyText16 ,
FreeColors ,
StoreColors
and
ChangeKeyboardControl .
The following error codes result from various requests as follows:
Error
Description
Access Error Codes Access
An attempt is made to grab a key/button combination already grabbed by another
client.
An attempt is made to free a colormap entry not allocated by the client
or to free an entry in a colormap that was created with all entries writable.
An attempt is made to store into a read-only or an unallocated colormap entry.
An attempt is made to modify the access control list from other than the local
host (or otherwise authorized client).
An attempt is made to select an event type that only one client can
select at a time when another client has already selected it.
Alloc Error Codes Alloc
The server failed to allocate the requested resource.
Note that the explicit listing of
Alloc
errors in request only covers allocation errors at a very coarse level
and is not intended to cover all cases
of a server running out of allocation space in the middle of service.
The semantics when a server runs out of allocation space are left unspecified,
but a server may generate an
Alloc
error on any request for this reason,
and clients should be prepared to receive such errors and handle
or discard them.
Atom Error Codes Atom
A value for an ATOM argument does not name a defined ATOM.
Colormap Error Codes Colormap
A value for a COLORMAP argument does not name a defined COLORMAP.
Cursor Error Codes Cursor
A value for a CURSOR argument does not name a defined CURSOR.
Drawable Error Codes Drawable
A value for a DRAWABLE argument does not name a defined WINDOW
or PIXMAP.
Font Error Codes Font
A value for a FONT argument does not name a defined FONT.
A value for a FONTABLE argument does not name a defined FONT or a
defined GCONTEXT.
GContext Error Codes GContext
A value for a GCONTEXT argument does not name a defined GCONTEXT.
IDChoice Error Codes IDChoice
The value chosen for a resource identifier either is not included
in the range assigned to the client or is already in use.
Implementation Error Codes Implementation
The server does not implement some aspect of the request.
A server that generates this error for a core request is deficient.
As such, this error is not listed for any of the requests,
but clients should be prepared to receive such errors
and handle or discard them.
Length Error Codes Length
The length of a request is shorter or longer than that required
to minimally contain the arguments.
The length of a request exceeds the maximum length accepted by the
server.
Match Error Codes Match
An
InputOnly
window is used as a DRAWABLE.
In a graphics request, the GCONTEXT argument does not have the same
root and depth as the destination DRAWABLE argument.
Some argument (or pair of arguments) has the correct type and range,
but it fails to match in some other way required by the request.
Name Error Codes Name
A font or color of the specified name does not exist.
Pixmap Error Codes Pixmap
A value for a PIXMAP argument does not name a defined PIXMAP.
Request Error Codes Request
The major or minor opcode does not specify a valid request.
Value Error Codes Value
Some numeric value falls outside the range of values accepted by the request.
Unless a specific range is specified for an argument,
the full range defined by the argument's type is accepted.
Any argument defined as a set of alternatives typically can generate
this error (due to the encoding).
Window Error Codes Window
A value for a WINDOW argument does not name a defined WINDOW.
The
Atom ,
Colormap ,
Cursor ,
Drawable ,
Font ,
GContext ,
Pixmap
and
Window
errors are also used when the argument type is extended by union with a
set of fixed alternatives, for example, <WINDOW or
PointerRoot
or
None >.
Keyboards
Keyboard
A KEYCODE represents a physical (or logical) key.
Types KEYCODE Keycode
A KEYSYM is an encoding of a symbol on the cap of a key.
Types KEYSYM Keysym
A list of KEYSYMs is associated with each KEYCODE.
The list is intended to convey the set of symbols on the corresponding key.
If the list (ignoring trailing
NoSymbol
entries) is a single KEYSYM "K ",
then the list is treated as if it were
the list "K NoSymbol
K NoSymbol ".
If the list (ignoring trailing NoSymbol entries)
is a pair of KEYSYMs
"K1 K2 ", then the list is treated as
if it were the list
"K1 K2 K1 K2 ".
If the list (ignoring trailing
NoSymbol
entries) is
a triple of KEYSYMs "K1 K2 K3 ",
then the list is treated as if it were the list "
K1 K2 K3 NoSymbol ".
When an explicit "void" element is desired in the list,
the value
VoidSymbol
can be used.
The first four elements of the list are split into two groups of KEYSYMs.
Group 1 contains the first and second KEYSYMs, Group 2 contains the third and
fourth KEYSYMs.
Within each group,
if the second element of the group is
NoSymbol ,
then the group should be treated as if the second element were the
same as the first element, except when the first element is an alphabetic
KEYSYM "K " for which both lowercase
and uppercase forms are defined.
In that case, the group should be treated as if the first element were the
lowercase form of "K " and the second
element were the uppercase form
of "K ".
The standard rules for obtaining a KEYSYM from a
KeyPress
KeyPress Mod1
through
Mod5 .
This modifier is
modifier group group modifier ". For any KEYCODE, Group 1 is used when the
group modifier is off, and Group 2 is used when the group modifier is on.
The
Lock
modifier Lock Lock
modifier. The
Lock
modifier is interpreted as ShiftLock when the KEYSYM
named SHIFT LOCK is attached to some KEYCODE and that KEYCODE is attached
to the
Lock
modifier. If the
Lock
modifier could be interpreted as both
CapsLock and ShiftLock, the CapsLock interpretation is used.
The operation of "keypad" keys is controlled by the KEYSYM named NUM LOCK,
by attaching that KEYSYM to some KEYCODE and attaching that KEYCODE to any
one of the modifiers
Mod1
through
Mod5 .
This modifier is called the
modifier NumLock
Within a group, the choice of KEYSYM is determined by applying the first
rule that is satisfied from the following list:
The numlock modifier is on and the second KEYSYM is a keypad KEYSYM. In
this case, if the
Shift
modifier is on, or if the
Lock
modifier is on and
is interpreted as ShiftLock, then the first KEYSYM is used; otherwise, the
second KEYSYM is used.
The
Shift
and
Lock
modifiers are both off. In this case, the first
KEYSYM is used.
The
Shift
modifier is off, and the
Lock
modifier is on and is
interpreted as CapsLock. In this case, the first KEYSYM is used, but if
that KEYSYM is lowercase alphabetic, then the corresponding uppercase
KEYSYM is used instead.
The
Shift
modifier is on, and the
Lock
modifier is on and is interpreted
as CapsLock. In this case, the second KEYSYM is used, but if that KEYSYM
is lowercase alphabetic, then the corresponding uppercase KEYSYM is used
instead.
The
Shift
modifier is on, or the
Lock
modifier is on and is interpreted
as ShiftLock, or both. In this case, the second KEYSYM is used.
The mapping between KEYCODEs and KEYSYMs is not used directly by the server;
it is merely stored for reading and writing by clients.
Pointers
Buttons are always numbered starting with one.
Button number
Predefined Atoms
Atom predefined InternAtom
requests in most applications.
Note that they are predefined only in the sense of having numeric values,
not in the sense of having required semantics.
The core protocol imposes no semantics on these names,
but semantics are specified in other X Window System standards,
such as the
Inter-Client Communication Conventions Manual
and the X Logical Font Description Conventions .
The following names have predefined atom values.
Note that uppercase and lowercase matter.
ARC
ATOM
BITMAP
CAP_HEIGHT
CARDINAL
COLORMAP
COPYRIGHT
CURSOR
CUT_BUFFER0
CUT_BUFFER1
CUT_BUFFER2
CUT_BUFFER3
CUT_BUFFER4
CUT_BUFFER5
CUT_BUFFER6
CUT_BUFFER7
DRAWABLE
END_SPACE
FAMILY_NAME
FONT
FONT_NAME
FULL_NAME
INTEGER
ITALIC_ANGLE
MAX_SPACE
MIN_SPACE
NORM_SPACE
NOTICE
PIXMAP
POINT
POINT_SIZE
PRIMARY
QUAD_WIDTH
RECTANGLE
RESOLUTION
RESOURCE_MANAGER
RGB_BEST_MAP
RGB_BLUE_MAP
RGB_COLOR_MAP
RGB_DEFAULT_MAP
RGB_GRAY_MAP
RGB_GREEN_MAP
RGB_RED_MAP
SECONDARY
STRIKEOUT_ASCENT
STRIKEOUT_DESCENT
STRING
SUBSCRIPT_X
SUBSCRIPT_Y
SUPERSCRIPT_X
SUPERSCRIPT_Y
UNDERLINE_POSITION
UNDERLINE_THICKNESS
VISUALID
WEIGHT
WINDOW
WM_CLASS
WM_CLIENT_MACHINE
WM_COMMAND
WM_HINTS
WM_ICON_NAME
WM_ICON_SIZE
WM_NAME
WM_NORMAL_HINTS
WM_SIZE_HINTS
WM_TRANSIENT_FOR
WM_ZOOM_HINTS
X_HEIGHT
To avoid conflicts with possible future names for which semantics might be
imposed (either at the protocol level or in terms of higher level user
interface models),
names beginning with an underscore should be used for atoms
that are private to a particular vendor or organization.
To guarantee no conflicts between vendors and organizations,
additional prefixes need to be used.
However, the protocol does not define the mechanism for choosing such prefixes.
For names private to a single application or end user but stored in globally
accessible locations,
it is suggested that two leading underscores be used to avoid conflicts with
other names.
Connection Setup
Connection
For remote clients,
the X protocol can be built on top of any reliable byte stream.
Connection Initiation
Connection opening
The client must send an initial byte of data to identify the byte order to be
employed.
Byte order
Following the byte-order byte,
the client sends the following information at connection setup:
protocol-major-version: CARD16
protocol-minor-version: CARD16
authorization-protocol-name: STRING8
authorization-protocol-data: STRING8
The version numbers indicate what version of the protocol the client
expects the server to implement.
The authorization name indicates what authorization (and authentication)
protocol the client
expects the server to use, and the data is specific to that protocol.
Authorization
Server Response
The client receives the following information at connection setup:
success:
{ Failed ,
Success ,
Authenticate }
The client receives the following additional data if the returned success
value is
Failed ,
and the connection is not successfully established:
protocol-major-version: CARD16
protocol-minor-version: CARD16
reason: STRING8
The client receives the following additional data if the returned success
value is
Authenticate ,
and further authentication negotiation is required:
reason: STRING8
The contents of the reason string are specific to the authorization
protocol in use. The semantics of this authentication negotiation are
not constrained, except that the negotiation must eventually terminate
with a reply from the server containing a success value of
Failed
or
Success .
The client receives the following additional data if the returned success
value is
Success ,
and the connection is successfully established:
protocol-major-version: CARD16
protocol-minor-version: CARD16
vendor: STRING8
release-number: CARD32
resource-id-base, resource-id-mask: CARD32
image-byte-order:
{ LSBFirst ,
MSBFirst }
bitmap-scanline-unit: {8, 16, 32}
bitmap-scanline-pad: {8, 16, 32}
bitmap-bit-order:
{ LeastSignificant ,
MostSignificant }
pixmap-formats: LISTofFORMAT
roots: LISTofSCREEN
motion-buffer-size: CARD32
maximum-request-length: CARD16
min-keycode, max-keycode: KEYCODE
where:
FORMAT:
[depth: CARD8,
bits-per-pixel: {1, 4, 8, 16, 24, 32}
scanline-pad: {8, 16, 32}]
SCREEN:
[root: WINDOW
width-in-pixels, height-in-pixels: CARD16
width-in-millimeters, height-in-millimeters: CARD16
allowed-depths: LISTofDEPTH
root-depth: CARD8
root-visual: VISUALID
default-colormap: COLORMAP
white-pixel, black-pixel: CARD32
min-installed-maps, max-installed-maps: CARD16
backing-stores: {Never, WhenMapped, Always}
save-unders: BOOL
current-input-masks: SETofEVENT]
DEPTH:
[depth: CARD8
visuals: LISTofVISUALTYPE]
VISUALTYPE:
[visual-id: VISUALID
class: {StaticGray, StaticColor, TrueColor, GrayScale,
PseudoColor, DirectColor}
red-mask, green-mask, blue-mask: CARD32
bits-per-rgb-value: CARD8
colormap-entries: CARD16]
Requests
CreateWindow
CreateWindow
wid , parent : WINDOW
class :
{ InputOutput ,
InputOnly ,
CopyFromParent }
depth : CARD8
visual : VISUALID or
CopyFromParent
x , y : INT16
width , height , border-width : CARD16
value-mask : BITMASK
value-list : LISTofVALUE
Errors:
Alloc ,
Colormap ,
Cursor ,
IDChoice ,
Match ,
Pixmap ,
Value ,
Window
This request creates an unmapped window and assigns the identifier wid to it.
A class of
CopyFromParent
means the class is taken from the parent.
A depth of zero for class
InputOutput
or
CopyFromParent
means the depth is taken from the parent.
A visual of
CopyFromParent
means the visual type is taken from the parent.
For class
InputOutput ,
the visual type and depth must be a combination supported for the screen
(or a
Match
error results).
The depth need not be the same as the parent,
but the parent must not be of class
InputOnly
(or a
Match
error results).
For class
InputOnly ,
the depth must be zero (or a
Match
error results), and the visual must be one supported for the screen (or a
Match
error results).
However, the parent can have any depth and class.
The server essentially acts as if
InputOnly
windows do not exist for the purposes of graphics requests,
exposure processing, and
VisibilityNotify
events.
An
InputOnly
window cannot be used as a drawable (as a source or destination for graphics
requests).
InputOnly
and
InputOutput
windows act identically in other respects-properties,
grabs, input control, and so on.
The coordinate system has the X axis horizontal and the Y axis vertical
with the origin [0, 0] at the upper-left corner.
Coordinates are integral,
in terms of pixels,
and coincide with pixel centers.
Each window and pixmap has its own coordinate system.
For a window,
the origin is inside the border at the inside, upper-left corner.
The x and y coordinates
for the window are relative to the parent's origin
and specify the position of the upper-left outer corner of the window
(not the origin).
The width and height specify the inside size (not including the border)
and must be nonzero (or a
Value
error results).
The border-width for an
InputOnly
window must be zero (or a
Match
error results).
The window is placed on top in the stacking order with respect to siblings.
The value-mask and value-list specify attributes of the window that are
to be explicitly initialized.
The possible values are:
Attribute
Type
background-pixmap
PIXMAP or
None
or
ParentRelative
background-pixel
CARD32
border-pixmap
PIXMAP or
CopyFromParent
border-pixel
CARD32
bit-gravity
BITGRAVITY
win-gravity
WINGRAVITY
backing-store
{ NotUseful ,
WhenMapped ,
Always }
backing-planes
CARD32
backing-pixel
CARD32
save-under
BOOL
event-mask
SETofEVENT
do-not-propagate-mask
SETofDEVICEEVENT
override-redirect
BOOL
colormap
COLORMAP or
CopyFromParent
cursor
CURSOR or
None
The default values when attributes are not explicitly initialized
are:
Attribute
Default
background-pixmap
None
border-pixmap
CopyFromParent
bit-gravity
Forget
win-gravity
NorthWest
backing-store
NotUseful
backing-planes
all ones
backing-pixel
zero
save-under
False
event-mask
{} (empty set)
do-not-propagate-mask
{} (empty set)
override-redirect
False
colormap
CopyFromParent
cursor
None
Only the following attributes are defined for
InputOnly
windows:
win-gravity
event-mask
do-not-propagate-mask
override-redirect
cursor
It is a
Match
error to specify any other attributes for
InputOnly
windows.
Background Match
error results).
Any size pixmap can be used, although some sizes may be faster than others.
If background
None
is specified, the window has no defined background.
If background
ParentRelative
is specified, the parent's background is used,
but the window must have the same depth as the parent (or a
Match
error results).
If the parent has background
None ,
then the window will also have background
None .
A copy of the parent's background is not made.
The parent's background is reexamined each time the window background is
required.
If background-pixel is given, it overrides the default
background-pixmap and any background-pixmap given explicitly,
and a pixmap of undefined size filled with background-pixel is used for the
background.
Range checking is not performed on the background-pixel value;
it is simply truncated to the appropriate number of bits.
For a
ParentRelative
background,
the background tile origin always aligns with the parent's background tile
origin.
Otherwise, the background tile origin is always the window origin.
When no valid contents are available for regions of a window
and the regions are either visible or the server is maintaining backing store,
the server automatically tiles the regions with the window's background
unless the window has a background of
None .
If the background is
None ,
the previous screen contents from other windows of the same depth as the window
are simply left in place if the contents come from the parent of the window
or an inferior of the parent;
otherwise, the initial contents of the exposed regions are undefined.
Exposure events are then generated for the regions, even if the background is
None .
The border tile origin is always the same as the background tile origin.
If border-pixmap is given,
it overrides the default border-pixmap.
The border pixmap and the window must have the same root
and the same depth (or a
Match
error results).
Any size pixmap can be used,
although some sizes may be faster than others.
If
CopyFromParent
is given, the parent's border pixmap is copied (subsequent changes to
the parent's border attribute do not affect the child),
but the window must have the same depth as the parent (or a
Match
error results).
The pixmap might be copied by sharing the same pixmap object between the
child and parent or by making a complete copy of the pixmap contents.
If border-pixel is given,
it overrides the default border-pixmap and any border-pixmap given explicitly,
and a pixmap of undefined size filled with border-pixel is used for the border.
Range checking is not performed on the border-pixel value;
it is simply truncated to the appropriate number of bits.
Output to a window is always clipped to the inside of the window,
so that the border is never affected.
The bit-gravity defines which region of the window should be retained
if the window is resized, and win-gravity defines how the window should
be repositioned if the parent is resized (see
ConfigureWindow
request).
A backing-store of
WhenMapped
advises the server that maintaining contents of obscured regions
when the window is mapped would be beneficial.
A backing-store of
Always
advises the server that maintaining contents even when the window is
unmapped would be beneficial.
In this case,
the server may generate an exposure event when the window is created.
A value of
NotUseful
advises the server that maintaining contents is unnecessary,
although a server may still choose to maintain contents while the window
is mapped.
Note that if the server maintains contents,
then the server should maintain complete contents
not just the region within the parent boundaries,
even if the window is larger than its parent.
While the server maintains contents,
exposure events will not normally be generated,
but the server may stop maintaining contents at any time.
If save-under is
True ,
the server is advised that when this window is
mapped, saving the contents of windows it obscures would be beneficial.
When the contents of obscured regions of a window are being maintained,
regions obscured by noninferior windows are included in the
destination (and source, when the window is the source) of graphics
requests, but regions obscured by inferior windows are not included.
The backing-planes indicates (with bits set to 1) which bit planes
of the window hold dynamic data that must be preserved in backing-stores
and during save-unders.
The backing-pixel specifies what value to use in planes not
covered by backing-planes.
The server is free to save only the specified bit planes in the backing-store
or save-under and regenerate the remaining planes with the specified pixel
value.
Any bits beyond the specified depth of the window in these
values are simply ignored.
Event mask Event propagation
The override-redirect specifies whether map and configure requests on this
window should override a
SubstructureRedirect
on the parent, typically to inform a window manager not to tamper with
the window.
The colormap specifies the colormap that best reflects the true
colors of the window.
Servers capable of supporting multiple hardware colormaps may use this
information, and window managers may use it for
InstallColormap
requests.
The colormap must have the same visual type and root as the window (or a
Match
error results).
If
CopyFromParent
is specified,
the parent's colormap is copied (subsequent changes to the parent's
colormap attribute do not affect the child).
However, the window must have the same visual type as the parent (or a
Match
error results), and the parent must not have a colormap of
None
(or a
Match
error results).
For an explanation of
None ,
see FreeColormap
request.
The colormap is copied by sharing the colormap object between the child
and the parent,
not by making a complete copy of the colormap contents.
If a cursor is specified,
it will be used whenever the pointer is in the window.
If
None
is specified,
the parent's cursor will be used when the pointer is in the window,
and any change in the parent's cursor will cause an immediate change
in the displayed cursor.
This request generates a
CreateNotify
event.
The background and border pixmaps and the cursor may be freed
immediately if no further explicit references to them are to be made.
Subsequent drawing into the background or border pixmap has an
undefined effect on the window state.
The server might or might not make a copy of the pixmap.
ChangeWindowAttributes
ChangeWindowAttributes
window : WINDOW
value-mask : BITMASK
value-list : LISTofVALUE
Errors:
Access ,
Colormap ,
Cursor ,
Match ,
Pixmap ,
Value ,
Window
The value-mask and value-list specify which attributes are to be changed.
The values and restrictions are the same as for
CreateWindow .
Setting a new background, whether by background-pixmap or
background-pixel, overrides any previous background.
Setting a new border, whether by border-pixel or border-pixmap,
overrides any previous border.
Changing the background does not cause the window contents to be changed.
Setting the border or changing the background such that the
border tile origin changes causes the border to be repainted.
Changing the background of a root window to
None
or
ParentRelative
restores the default background pixmap.
Changing the border of a root window to
CopyFromParent
restores the default border pixmap.
Changing the win-gravity does not affect the current position of the
window.
Changing the backing-store of an obscured window to
WhenMapped
or
Always
or changing the backing-planes, backing-pixel, or save-under of
a mapped window may have no immediate effect.
Multiple clients can select input on the same window;
their event-masks are disjoint.
When an event is generated,
it will be reported to all interested clients.
However, only one client at a time can select for
SubstructureRedirect ,
only one client at a time can select for
ResizeRedirect ,
and only one client at a time can select for
ButtonPress .
An attempt to violate these restrictions results in an
Access
error.
There is only one do-not-propagate-mask for a window, not one per
client.
Changing the colormap of a window (by defining a new map, not by
changing the contents of the existing map) generates a
ColormapNotify
event.
Changing the colormap of a visible window might have no immediate effect
on the screen (see
InstallColormap
request).
Changing the cursor of a root window to
None
restores the default cursor.
The order in which attributes are verified and altered is server-dependent.
If an error is generated,
a subset of the attributes may have been altered.
GetWindowAttributes
GetWindowAttributes
window : WINDOW
â–¶
visual: VISUALID
class:
{ InputOutput ,
InputOnly }
bit-gravity: BITGRAVITY
win-gravity: WINGRAVITY
backing-store:
{ NotUseful ,
WhenMapped ,
Always }
backing-planes: CARD32
backing-pixel: CARD32
save-under: BOOL
colormap: COLORMAP or
None
map-is-installed: BOOL
map-state:
{ Unmapped ,
Unviewable ,
Viewable }
all-event-masks, your-event-mask: SETofEVENT
do-not-propagate-mask: SETofDEVICEEVENT
override-redirect: BOOL
Errors:
Window
This request returns the current attributes of the window.
A window is
Unviewable
if it is mapped but some ancestor is unmapped.
All-event-masks is the inclusive-OR of all event masks selected on the window
by clients.
Your-event-mask is the event mask selected by the querying client.
DestroyWindow
DestroyWindow
window : WINDOW
Errors:
Window
If the argument window is mapped,
an
UnmapWindow
request is performed automatically.
The window and all inferiors are then destroyed, and a
DestroyNotify
event is generated for each window.
The ordering of the
DestroyNotify
events is such that for any given window,
DestroyNotify
is generated on all inferiors of the window before being generated on
the window itself.
The ordering among siblings and across subhierarchies is not otherwise
constrained.
Normal exposure processing on formerly obscured windows is performed.
If the window is a root window,
this request has no effect.
DestroySubwindows
DestroySubwindows
window : WINDOW
Errors:
Window
This request performs a
DestroyWindow
request on all children of the window, in bottom-to-top stacking order.
ChangeSaveSet
ChangeSaveSet
window : WINDOW
mode :
{ Insert ,
Delete }
Errors:
Match ,
Value ,
Window
This request adds or removes the specified window from the client's
save-set.
The window must have been created by some other client (or a
Match
error results).
For further information about the use of the save-set,
see
When windows are destroyed,
the server automatically removes them from the save-set.
ReparentWindow
ReparentWindow
window , parent : WINDOW
x , y : INT16
Errors:
Match ,
Window
If the window is mapped,
an
UnmapWindow
request is performed automatically first.
The window is then removed from its current position in the hierarchy
and is inserted as a child of the specified parent.
The x and y coordinates are relative to the parent's origin
and specify the new position of the upper-left outer corner of the
window.
The window is placed on top in the stacking order with respect
to siblings.
A
ReparentNotify
event is then generated.
The override-redirect attribute of the window is passed on in this event;
a value of
True
indicates that a window manager should not tamper with this window.
Finally, if the window was originally mapped, a
MapWindow
request is performed automatically.
Normal exposure processing on formerly obscured windows is performed.
The server might not generate exposure events for regions from the
initial unmap that are immediately obscured by the final map.
A
Match
error is generated if:
The new parent is not on the same screen as the old parent.
The new parent is the window itself or an inferior of the window.
The new parent is
InputOnly ,
and the window is not.
The window has a
ParentRelative
background, and the new parent is not the same depth as the window.
MapWindow
MapWindow Mapped window
window : WINDOW
Errors:
Window
If the window is already mapped, this request has no effect.
If the override-redirect attribute of the window is
False
and some other client has selected
SubstructureRedirect
on the parent, then a
MapRequest
event is generated, but the window remains unmapped.
Otherwise, the window is mapped,
and a
MapNotify
event is generated.
If the window is now viewable and its contents have been discarded,
the window is tiled with its background (if no background is defined,
the existing screen contents are not altered), and zero or more exposure
events are generated.
If a backing-store has been maintained while the window was unmapped,
no exposure events are generated.
If a backing-store will now be maintained,
a full-window exposure is always generated.
Otherwise, only visible regions may be reported.
Similar tiling and exposure take place for any newly viewable inferiors.
MapSubwindows
MapSubwindows
window : WINDOW
Errors:
Window
This request performs a
MapWindow
request on all unmapped children of the window,
in top-to-bottom stacking order.
UnmapWindow
UnmapWindow
window : WINDOW
Errors:
Window
If the window is already unmapped, this request has no effect.
Otherwise, the window is unmapped, and an
UnmapNotify
event is generated.
Normal exposure processing on formerly obscured windows is performed.
UnmapSubwindows
UnmapSubwindows
window : WINDOW
Errors:
Window
This request performs an
UnmapWindow
request on all mapped children of the window,
in bottom-to-top stacking order.
CirculateWindow
CirculateWindow
window : WINDOW
direction :
{ RaiseLowest ,
LowerHighest }
Errors:
Value ,
Window
If some other client has selected
SubstructureRedirect
on the window, then a
CirculateRequest
event is generated, and no further processing is performed.
Otherwise, the following is performed, and then a
CirculateNotify
event is generated if the window is actually restacked.
For
RaiseLowest ,
CirculateWindow
raises the lowest mapped child (if any) that is
occluded by another child to the top of the stack.
For
LowerHighest ,
CirculateWindow
lowers the highest mapped child (if any) that occludes another child to
the bottom of the stack.
Exposure processing is performed on formerly obscured windows.
GetGeometry
GetGeometry
drawable : DRAWABLE
â–¶
root: WINDOW
depth: CARD8
x, y: INT16
width, height, border-width: CARD16
Errors:
Drawable
This request returns the root and current geometry of the drawable.
The depth is the number of bits per pixel for the object.
The x, y, and border-width will always be zero for pixmaps.
For a window,
the x and y coordinates specify the upper-left outer corner of the window
relative to its parent's origin,
and the width and height specify the inside size, not including the border.
It is legal to pass an
InputOnly
window as a drawable to this request.
QueryTree
QueryTree Children
window : WINDOW
â–¶
root: WINDOW
parent: WINDOW or
None
children: LISTofWINDOW
Errors:
Window
This request returns the root, the parent, and the children of the window.
The children are listed in bottom-to-top stacking order.
InternAtom
InternAtom Atom
name : STRING8
only-if-exists : BOOL
â–¶
atom: ATOM or
None
Errors:
Alloc ,
Value
This request returns the atom for the given name.
If only-if-exists is
False ,
then the atom is created if it does not exist.
The string should use the ISO Latin-1 encoding.
Uppercase and lowercase matter.
The lifetime of an atom is not tied to the interning client.
Atoms remain defined until server reset (see
GetAtomName
GetAtomName
atom : ATOM
â–¶
name: STRING8
Errors:
Atom
This request returns the name for the given atom.
ChangeProperty
ChangeProperty Property
window : WINDOW
property , type : ATOM
format : {8, 16, 32}
mode :
{ Replace ,
Prepend ,
Append }
data : LISTofINT8 or LISTofINT16 or LISTofINT32
Errors:
Alloc ,
Atom ,
Match ,
Value ,
Window
This request alters the property for the specified window.
The type is uninterpreted by the server.
The format specifies whether the data should be viewed as a list of 8-bit,
16-bit, or 32-bit quantities so that the server can correctly byte-swap
as necessary.
If the mode is
Replace ,
the previous property value is discarded.
If the mode is
Prepend
or
Append ,
then the type and format must match the existing property value (or a
Match
error results).
If the property is undefined,
it is treated as defined with the correct type
and format with zero-length data.
For
Prepend ,
the data is tacked on to the beginning of the existing data, and for
Append ,
it is tacked on to the end of the existing data.
This request generates a
PropertyNotify
event on the window.
The lifetime of a property is not tied to the storing client.
Properties remain until explicitly deleted, until the window is destroyed,
or until server reset (see
The maximum size of a property is server-dependent and may vary dynamically.
DeleteProperty
DeleteProperty
window : WINDOW
property : ATOM
Errors:
Atom ,
Window
This request deletes the property from the specified window
if the property exists and generates a
PropertyNotify
event on the window unless the property does not exist.
GetProperty
GetProperty
window : WINDOW
property : ATOM
type : ATOM or
AnyPropertyType
long-offset , long-length : CARD32
delete : BOOL
â–¶
type: ATOM or
None
format: {0, 8, 16, 32}
bytes-after: CARD32
value: LISTofINT8 or LISTofINT16 or LISTofINT32
Errors:
Atom ,
Value ,
Window
If the specified property does not exist for the specified window,
then the return type is
None ,
the format and bytes-after are zero,
and the value is empty.
The delete argument is ignored in this case.
If the specified property exists but its type does not match the specified type,
then the return type is the actual type of the property,
the format is the actual format of the property (never zero),
the bytes-after is the length of the property in bytes
(even if the format is 16 or 32),
and the value is empty.
The delete argument is ignored in this case.
If the specified property exists and either
AnyPropertyType
is specified or the specified type matches the actual type of the property,
then the return type is the actual type of the property,
the format is the actual format of the property (never zero),
and the bytes-after and value are as follows, given:
N = actual length of the stored property in bytes
(even if the format is 16 or 32)
I = 4 * long-offset
T = N - I
L = MINIMUM(T, 4 * long-length)
A = N - (I + L)
The returned value starts at byte index I in the property (indexing from 0),
and its length in bytes is L.
However, it is a
Value
error if long-offset is given such that L is negative.
The value of bytes-after is A,
giving the number of trailing unread bytes in the stored
property.
If delete is
True
and the bytes-after is zero,
the property is also deleted from the window,
and a
PropertyNotify
event is generated on the window.
RotateProperties
RotateProperties
window : WINDOW
delta : INT16
properties : LISTofATOM
Errors:
Atom ,
Match ,
Window
If the property names in the list are viewed as being numbered starting
from zero, and there are N property names in the list,
then the value associated with property name I becomes the value
associated with property name (I + delta) mod N, for all I from zero to N - 1.
The effect is to rotate the states by delta places around the virtual ring
of property names (right for positive delta, left for negative delta).
If delta mod N is nonzero,
a
PropertyNotify
event is generated for each property in the order listed.
If an atom occurs more than once in the list or no property with that
name is defined for the window,
a
Match
error is generated.
If an
Atom
or
Match
error is generated, no properties are changed.
ListProperties
ListProperties
window : WINDOW
â–¶
atoms: LISTofATOM
Errors:
Window
This request returns the atoms of properties currently defined on the window.
SetSelectionOwner
SetSelectionOwner Selection
selection : ATOM
owner : WINDOW or
None
time : TIMESTAMP or
CurrentTime
Errors:
Atom ,
Window
This request changes the owner, owner window,
and last-change time of the specified selection.
This request has no effect if the specified time is earlier
than the current last-change time of the specified selection or is
later than the current server time.
Otherwise, the last-change time is set to the specified time
with
CurrentTime
replaced by the current server time.
If the owner window is specified as
None ,
then the owner of the selection becomes
None
(that is, no owner).
Otherwise, the owner of the selection becomes the client executing the request.
If the new owner (whether a client or
None )
is not the same as the current owner
and the current owner is not
None ,
then the current owner is sent a
SelectionClear
event.
If the client that is the owner of a selection is later terminated
(that is, its connection is closed) or if the owner window it has
specified in the request is later destroyed,
then the owner of the selection automatically reverts to
None ,
but the last-change time is not affected.
The selection atom is uninterpreted by the server.
The owner window is returned by the
GetSelectionOwner
request and is reported in
SelectionRequest
and
SelectionClear
events.
Selections are global to the server.
GetSelectionOwner
GetSelectionOwner
selection : ATOM
â–¶
owner: WINDOW or
None
Errors:
Atom
This request returns the current owner window of the specified selection,
if any.
If
None
is returned, then there is no owner for the selection.
ConvertSelection
ConvertSelection
selection , target : ATOM
property : ATOM or
None
requestor : WINDOW
time : TIMESTAMP or
CurrentTime
Errors:
Atom ,
Window
If the specified selection has an owner,
the server sends a
SelectionRequest
event to that owner.
If no owner for the specified selection exists,
the server generates a
SelectionNotify
event to the requestor with property
None .
The arguments are passed on unchanged in either of the events.
SendEvent
SendEvent Event sending
destination : WINDOW or
PointerWindow
or
InputFocus
propagate : BOOL
event-mask : SETofEVENT
event : <normal-event-format>
Errors:
Value ,
Window
If
PointerWindow
is specified,
destination is replaced with the window that the pointer is in.
If
InputFocus
is specified and the focus window contains the pointer,
destination is replaced with the window that the pointer is in.
Otherwise, destination is replaced with the focus window.
If the event-mask is the empty set,
then the event is sent to the client that created the destination window.
If that client no longer exists, no event is sent.
If propagate is
False ,
then the event is sent to every client selecting
on destination any of the event types in event-mask.
If propagate is
True
and no clients have selected on destination any
of the event types in event-mask,
then destination is replaced with the
closest ancestor of destination for which some client has selected a
type in event-mask and no intervening window has that type in its
do-not-propagate-mask.
If no such window exists or if the window is an ancestor of the focus window
and
InputFocus
was originally specified as the destination,
then the event is not sent to any clients.
Otherwise, the event is reported to every client selecting on the final
destination any of the types specified in event-mask.
The event code must be one of the core events or one of the events
defined by an extension (or a
Value
error results) so that the server can correctly byte-swap the
contents as necessary.
The contents of the event are otherwise unaltered and unchecked
by the server except to force on the most significant bit of the event code
and to set the sequence number in the event correctly.
Active grabs are ignored for this request.
GrabPointer
GrabPointer Active grab pointer Pointer grabbing
grab-window : WINDOW
owner-events : BOOL
event-mask : SETofPOINTEREVENT
pointer-mode , keyboard-mode :
{ Synchronous ,
Asynchronous }
confine-to : WINDOW or
None
cursor : CURSOR or
None
time : TIMESTAMP or
CurrentTime
â–¶
status:
{ Success ,
AlreadyGrabbed ,
Frozen ,
InvalidTime ,
NotViewable }
Errors:
Cursor ,
Value ,
Window
This request actively grabs control of the pointer.
Further pointer events are only reported to the grabbing client.
The request overrides any active pointer grab by this client.
If owner-events is
False ,
all generated pointer events are reported with respect to grab-window
and are only reported if selected by event-mask.
If owner-events is
True
and a generated pointer event would normally be reported to this client,
it is reported normally.
Otherwise, the event is reported with respect to the grab-window and is
only reported if selected by event-mask.
For either value of owner-events,
unreported events are simply discarded.
If pointer-mode is
Asynchronous ,
pointer event processing continues normally.
If the pointer is currently frozen by this client,
then processing of pointer events is resumed.
If pointer-mode is
Synchronous ,
the state of the pointer (as seen by means of the protocol) appears to freeze,
and no further pointer events are generated by the server until the
grabbing client issues a releasing
AllowEvents
request or until the pointer grab is released.
Actual pointer changes are not lost while the pointer is frozen.
They are simply queued for later processing.
If keyboard-mode is
Asynchronous ,
keyboard event processing is unaffected by activation of the grab.
If keyboard-mode is
Synchronous ,
the state of the keyboard (as seen by means of the protocol) appears to freeze,
and no further keyboard events are generated by the server until the grabbing
client issues a releasing
AllowEvents
request or until the pointer grab is released.
Actual keyboard changes are not lost while the keyboard is frozen.
They are simply queued for later processing.
If a cursor is specified,
then it is displayed regardless of what window the pointer is in.
If no cursor is specified,
then when the pointer is in grab-window or one of its subwindows,
the normal cursor for that window is displayed.
Otherwise, the cursor for grab-window is displayed.
If a confine-to window is specified,
then the pointer will be restricted to stay contained in that window.
The confine-to window need have no relationship to the grab-window.
If the pointer is not initially in the confine-to window,
then it is warped automatically to the closest edge
(and enter/leave events are generated normally) just before the grab activates.
If the confine-to window is subsequently reconfigured,
the pointer will be warped automatically as necessary to
keep it contained in the window.
This request generates
EnterNotify
and
LeaveNotify
events.
The request fails with status
AlreadyGrabbed
if the pointer is actively grabbed by some other client.
The request fails with status
Frozen
if the pointer is frozen by an active grab of another client.
The request fails with status
NotViewable
if grab-window or confine-to window is not viewable
or if the confine-to window lies completely outside the boundaries
of the root window.
The request fails with status
InvalidTime
if the specified time is earlier than the last-pointer-grab time or later than
the current server time.
Otherwise, the last-pointer-grab time is set to the specified time, with
CurrentTime
replaced by the current server time.
UngrabPointer
UngrabPointer
time : TIMESTAMP or
CurrentTime
This request releases the pointer if this client has it actively grabbed (from
either
GrabPointer
or
GrabButton
or from a normal button press) and releases any queued events.
The request has no effect if the specified time is earlier than
the last-pointer-grab time or is later than the current server time.
This request generates
EnterNotify
and
LeaveNotify
events.
An
UngrabPointer
request is performed automatically if the event window or
confine-to window for an active pointer grab becomes not viewable
or if window reconfiguration causes the confine-to window to lie
completely outside the boundaries of the root window.
ChangeActivePointerGrab
ChangeActivePointerGrab Active grab pointer
event-mask : SETofPOINTEREVENT
cursor : CURSOR or
None
time : TIMESTAMP or
CurrentTime
Errors:
Cursor ,
Value
This request changes the specified dynamic parameters if the pointer is
actively grabbed by the client and the specified time is no earlier than the
last-pointer-grab time and no later than the current server time.
The interpretation of event-mask and cursor are the same as in
GrabPointer .
This request has no effect on the parameters of any passive grabs established
with
GrabButton .
GrabKeyboard
GrabKeyboard Active grab keyboard Keyboard grabbing
grab-window : WINDOW
owner-events : BOOL
pointer-mode , keyboard-mode :
{ Synchronous ,
Asynchronous }
time : TIMESTAMP or
CurrentTime
â–¶
status:
{ Success ,
AlreadyGrabbed ,
Frozen ,
InvalidTime ,
NotViewable }
Errors:
Value ,
Window
This request actively grabs control of the keyboard.
Further key events are reported only to the grabbing client.
This request overrides any active keyboard grab by this client.
If owner-events is
False ,
all generated key events are reported with respect to grab-window.
If owner-events is
True
and if a generated key event would normally be reported to this client,
it is reported normally.
Otherwise, the event is reported with respect to the grab-window.
Both
KeyPress
and
KeyRelease
events are always reported,
independent of any event selection made by the client.
If keyboard-mode is
Asynchronous ,
keyboard event processing continues normally.
If the keyboard is currently frozen by this client,
then processing of keyboard events is resumed.
If keyboard-mode is
Synchronous ,
the state of the keyboard (as seen by means of the protocol) appears to freeze.
No further keyboard events are generated by the server until the
grabbing client issues a releasing
AllowEvents
request or until the keyboard grab is released.
Actual keyboard changes are not lost while the keyboard is frozen.
They are simply queued for later processing.
If pointer-mode is
Asynchronous ,
pointer event processing is unaffected by activation of the grab.
If pointer-mode is
Synchronous ,
the state of the pointer (as seen by means of the protocol) appears to freeze.
No further pointer events are generated by the server
until the grabbing client issues a releasing
AllowEvents
request or until the keyboard grab is released.
Actual pointer changes are not lost while the pointer is frozen.
They are simply queued for later processing.
This request generates
FocusIn
and
FocusOut
events.
The request fails with status
AlreadyGrabbed
if the keyboard is actively grabbed by some other client.
The request fails with status
Frozen
if the keyboard is frozen by an active grab of another client.
The request fails with status
NotViewable
if grab-window is not viewable.
The request fails with status
InvalidTime
if the specified time is earlier than the last-keyboard-grab time
or later than the current server time.
Otherwise, the last-keyboard-grab time is set to the specified time with
CurrentTime
replaced by the current server time.
UngrabKeyboard
UngrabKeyboard
time : TIMESTAMP or
CurrentTime
This request releases the keyboard if this client has it actively grabbed
(as a result of either
GrabKeyboard
or
GrabKey )
and releases any queued events.
The request has no effect if the specified time is earlier than the
last-keyboard-grab time or is later than the current server time.
This request generates
FocusIn
and
FocusOut
events.
An
UngrabKeyboard
is performed automatically if the event window for an active keyboard grab
becomes not viewable.
GrabKey
GrabKey Key grabbing
key : KEYCODE or
AnyKey
modifiers : SETofKEYMASK or
AnyModifier
grab-window : WINDOW
owner-events : BOOL
pointer-mode , keyboard-mode :
{ Synchronous ,
Asynchronous }
Errors:
Access ,
Value ,
Window
This request establishes a passive grab on the keyboard.
Passive grab keyboard GrabKeyboard ,
the last-keyboard-grab time is set to the time at which the key was pressed
(as transmitted in the
KeyPress
event), and the
KeyPress
event is reported if all of the following conditions are true:
The keyboard is not grabbed and the specified key
(which can itself be a modifier key) is logically pressed
when the specified modifier keys are logically down,
and no other modifier keys are logically down.
Either the grab-window is an ancestor of (or is) the focus window,
or the grab-window is a descendent of the focus window and contains the pointer.
A passive grab on the same key combination does not exist
on any ancestor of grab-window.
The interpretation of the remaining arguments is the same as for
GrabKeyboard .
The active grab is terminated automatically when the logical state
of the keyboard has the specified key released,
independent of the logical state of modifier keys.
Note that the logical state of a device (as seen by means of the protocol)
may lag the physical state if device event processing is frozen.
This request overrides all previous passive grabs by the same client
on the same key combinations on the same window.
A modifier of
AnyModifier
is equivalent to issuing the request for all possible modifier combinations
(including the combination of no modifiers).
It is not required that all modifiers specified have
currently assigned keycodes.
A key of
AnyKey
is equivalent to issuing the request for all possible keycodes.
Otherwise, the key must be in the range specified by min-keycode
and max-keycode in the connection setup (or a
Value
error results).
An
Access
error is generated if some other client has issued a
GrabKey
with the same key combination on the same window.
When using
AnyModifier
or
AnyKey ,
the request fails completely (no grabs are established),
and an
Access
error is generated if there is a conflicting grab for any combination.
UngrabKey
UngrabKey
key : KEYCODE or
AnyKey
modifiers : SETofKEYMASK or
AnyModifier
grab-window : WINDOW
Errors:
Value ,
Window
This request releases the key combination on the specified window
if it was grabbed by this client.
A modifiers argument of
AnyModifier
is equivalent to issuing the request for all possible modifier combinations
(including the combination of no modifiers).
A key of
AnyKey
is equivalent to issuing the request for all possible keycodes.
This request has no effect on an active grab.
AllowEvents
AllowEvents
mode :
{ AsyncPointer ,
SyncPointer ,
ReplayPointer ,
AsyncKeyboard ,
SyncKeyboard ,
ReplayKeyboard ,
AsyncBoth ,
SyncBoth }
time : TIMESTAMP or
CurrentTime
Errors:
Value
This request releases some queued events if the client has caused a device to
freeze.
The request has no effect if the specified time is earlier
than the last-grab time of the most recent active grab for the client
or if the specified time is later than the current server time.
For
AsyncPointer ,
if the pointer is frozen by the client,
pointer event processing continues normally.
If the pointer is frozen twice by the client on behalf of two separate grabs,
AsyncPointer
thaws for both.
AsyncPointer
has no effect if the pointer is not frozen by the client,
but the pointer need not be grabbed by the client.
For
SyncPointer ,
if the pointer is frozen and actively grabbed by the client,
pointer event processing continues normally until the next
ButtonPress
or
ButtonRelease
event is reported to the client,
at which time the pointer again appears to freeze.
However, if the reported event causes the pointer grab to be released,
then the pointer does not freeze.
SyncPointer
has no effect if the pointer is not frozen by the
client or if the pointer is not grabbed by the client.
For
ReplayPointer ,
if the pointer is actively grabbed by the client and
is frozen as the result of an event having been sent to the client
(either from the activation of a
GrabButton
or from a previous
AllowEvents
with mode
SyncPointer
but not from a
GrabPointer ),
then the pointer grab is released and that event is completely reprocessed,
this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released.
The request has no effect if the pointer is not grabbed by the client
or if the pointer is not frozen as the result of an event.
For
AsyncKeyboard ,
if the keyboard is frozen by the client,
keyboard event processing continues normally.
If the keyboard is frozen twice by the client on behalf of two separate grabs,
AsyncKeyboard
thaws for both.
AsyncKeyboard
has no effect if the keyboard is not frozen by the client,
but the keyboard need not be grabbed by the client.
For
SyncKeyboard ,
if the keyboard is frozen and actively grabbed by the client,
keyboard event processing continues normally until the next
KeyPress
or
KeyRelease
event is reported to the client,
at which time the keyboard again appears to freeze.
However, if the reported event causes the keyboard grab to be released,
then the keyboard does not freeze.
SyncKeyboard
has no effect if the keyboard is not frozen by the client or
if the keyboard is not grabbed by the client.
For
ReplayKeyboard ,
if the keyboard is actively grabbed by the client
and is frozen as the result of an event having been sent to the client
(either from the activation of a
GrabKey
or from a previous
AllowEvents
with mode
SyncKeyboard
but not from a
GrabKeyboard ),
then the keyboard grab is released and that event is completely reprocessed,
this time ignoring any passive grabs at or above (towards the root)
the grab-window of the grab just released.
The request has no effect if the keyboard is not grabbed by the client
or if the keyboard is not frozen as the result of an event.
For
SyncBoth ,
if both pointer and keyboard are frozen by the client,
event processing (for both devices) continues normally until the next
ButtonPress ,
ButtonRelease ,
KeyPress ,
or
KeyRelease
event is reported to the client for a grabbed device
(button event for the pointer, key event for the keyboard),
at which time the devices again appear to freeze.
However, if the reported event causes the grab to be released,
then the devices do not freeze (but if the other device is still
grabbed, then a subsequent event for it will still cause both devices
to freeze).
SyncBoth
has no effect unless both pointer and keyboard are frozen by the client.
If the pointer or keyboard is frozen twice by the client on behalf
of two separate grabs,
SyncBoth
thaws for both (but a subsequent freeze for
SyncBoth
will only freeze each device once).
For
AsyncBoth ,
if the pointer and the keyboard are frozen by the client,
event processing for both devices continues normally.
If a device is frozen twice by the client on behalf of two separate grabs,
AsyncBoth
thaws for both.
AsyncBoth
has no effect unless both pointer and keyboard are frozen by the client.
AsyncPointer ,
SyncPointer ,
and
ReplayPointer
have no effect on processing of keyboard events.
AsyncKeyboard ,
SyncKeyboard ,
and
ReplayKeyboard
have no effect on processing of pointer events.
It is possible for both a pointer grab and a keyboard grab to be active
simultaneously (by the same or different clients).
When a device is frozen on behalf of either grab,
no event processing is performed for the device.
It is possible for a single device to be frozen because of both grabs.
In this case, the freeze must be released on behalf of both grabs
before events can again be processed.
If a device is frozen twice by a single client, then a single
AllowEvents
releases both.
GrabServer
GrabServer Server grabbing
This request disables processing of requests and close-downs on all
connections other than the one this request arrived on.
UngrabServer
UngrabServer
This request restarts processing of requests and close-downs
on other connections.
QueryPointer
QueryPointer
window : WINDOW
â–¶
root: WINDOW
child: WINDOW or
None
same-screen: BOOL
root-x, root-y, win-x, win-y: INT16
mask: SETofKEYBUTMASK
Errors:
Window
The root window the pointer is logically on and the pointer coordinates
relative to the root's origin are returned.
If same-screen is
False ,
then the pointer is not on the same screen as the argument window,
child is
None ,
and win-x and win-y are zero.
If same-screen is
True ,
then win-x and win-y are the pointer coordinates relative to the
argument window's origin, and child is the child containing the
pointer, if any.
The current logical state of the modifier keys and the buttons
are also returned.
Note that the logical state of a device (as seen by means of the protocol)
may lag the physical state if device event processing is frozen.
GetMotionEvents
GetMotionEvents
start ,
stop : TIMESTAMP or
CurrentTime
window : WINDOW
â–¶
events: LISTofTIMECOORD
where:
TIMECOORD: [x, y: INT16
time: TIMESTAMP]
Errors:
Window
This request returns all events in the motion history buffer that fall
between the specified start and stop times (inclusive)
and that have coordinates that lie within (including borders)
the specified window at its present placement.
The x and y coordinates are reported relative to the origin of the window.
If the start time is later than the stop time or if the start time is
in the future, no events are returned.
If the stop time is in the future, it is equivalent to specifying
CurrentTime .
TranslateCoordinates
TranslateCoordinates Coordinate system translating
src-window , dst-window : WINDOW
src-x , src-y : INT16
â–¶
same-screen: BOOL
child: WINDOW or
None
dst-x, dst-y: INT16
Errors:
Window
The src-x and src-y coordinates are taken relative to src-window's
origin and are returned as dst-x and dst-y coordinates relative to
dst-window's origin.
If same-screen is
False ,
then src-window and dst-window are on different screens,
and dst-x and dst-y are zero.
If the coordinates are contained in a mapped child of dst-window,
then that child is returned.
WarpPointer
WarpPointer
src-window : WINDOW or
None
dst-window : WINDOW or
None
src-x , src-y : INT16
src-width , src-height : CARD16
dst-x , dst-y : INT16
Errors:
Window
If dst-window is
None ,
this request moves the pointer by offsets [dst-x, dst-y]
relative to the current position of the pointer.
If dst-window is a window,
this request moves the pointer to [dst-x, dst-y] relative to dst-window's
origin.
However, if src-window is not
None ,
the move only takes place if src-window contains the pointer
and the pointer is contained in the specified rectangle of src-window.
The src-x and src-y coordinates are relative to src-window's origin.
If src-height is zero,
it is replaced with the current height of src-window minus src-y.
If src-width is zero,
it is replaced with the current width of src-window minus src-x.
This request cannot be used to move the pointer outside the confine-to
window of an active pointer grab.
An attempt will only move the pointer as far as the closest edge
of the confine-to window.
This request will generate events just as if the user had instantaneously
moved the pointer.
QueryKeymap
QueryKeymap
â–¶
keys: LISTofCARD8
This request returns a bit vector for the logical state of the keyboard.
Each bit set to 1 indicates that the corresponding key is currently pressed.
The vector is represented as 32 bytes.
Byte N (from 0) contains the bits for keys 8N to 8N + 7
with the least significant bit in the byte representing key 8N.
Note that the logical state of a device (as seen by means of the protocol)
may lag the physical state if device event processing is frozen.
OpenFont
OpenFont Font
fid : FONT
name : STRING8
Errors:
Alloc ,
IDChoice ,
Name
This request loads the specified font, if necessary,
and associates identifier fid with it.
The font name should use the ISO Latin-1 encoding,
and uppercase and lowercase do not matter.
When the characters ?
and *
are used in a font name, a
pattern match is performed and any matching font is used.
In the pattern,
the ?
character (octal value 77) will match any single character,
and the *
character (octal value 52) will match any number
of characters.
A structured format for font names is specified in the
X.Org standard X Logical Font Description Conventions .
Fonts are not associated with a particular screen
and can be stored as a component of any graphics context.
CloseFont
CloseFont
font : FONT
Errors:
Font
This request deletes the association between the resource ID and the font.
The font itself will be freed when no other resource references it.
QueryFont
QueryFont
font : FONTABLE
â–¶
font-info: FONTINFO
char-infos: LISTofCHARINFO
where:
FONTINFO:
[draw-direction:
{ LeftToRight ,
RightToLeft }
min-char-or-byte2, max-char-or-byte2: CARD16
min-byte1, max-byte1: CARD8
all-chars-exist: BOOL
default-char: CARD16
min-bounds: CHARINFO
max-bounds: CHARINFO
font-ascent: INT16
font-descent: INT16
properties: LISTofFONTPROP]
FONTPROP:
[name: ATOM
value: <32-bit-value>]
CHARINFO:
[left-side-bearing: INT16
right-side-bearing: INT16
character-width: INT16
ascent: INT16
descent: INT16
attributes: CARD16]
Errors:
Font
This request returns logical information about a font.
If a gcontext is given for font,
the currently contained font is used.
The draw-direction is just a hint
and indicates whether most char-infos have a positive,
LeftToRight ,
or a negative,
RightToLeft ,
character-width metric.
The core protocol defines no support for vertical text.
If min-byte1 and max-byte1 are both zero,
then min-char-or-byte2 specifies the linear character index corresponding
to the first element of char-infos,
and max-char-or-byte2 specifies the linear character index of the last element.
If either min-byte1 or max-byte1 are nonzero,
then both min-char-or-byte2 and max-char-or-byte2 will be less than 256,
and the 2-byte character index values corresponding to char-infos element N
(counting from 0) are:
byte1 = N/D + min-byte1
byte2 = N\\D + min-char-or-byte2
where:
D = max-char-or-byte2 - min-char-or-byte2 + 1
/ = integer division
\\ = integer modulus
If char-infos has length zero,
then min-bounds and max-bounds will be identical,
and the effective char-infos is one filled with this char-info, of length:
L = D * (max-byte1 - min-byte1 + 1)
That is,
all glyphs in the specified linear or matrix range have the same information,
as given by min-bounds (and max-bounds).
If all-chars-exist is
True ,
then all characters in char-infos have nonzero bounding boxes.
The default-char specifies the character that will be used when an
undefined or nonexistent character is used.
Note that default-char is a CARD16, not CHAR2B.
For a font using 2-byte matrix format,
the default-char has byte1 in the most significant byte
and byte2 in the least significant byte.
If the default-char itself specifies an undefined or nonexistent character,
then no printing is performed for an undefined or nonexistent character.
The min-bounds and max-bounds contain the minimum and maximum values of
each individual CHARINFO component over all char-infos (ignoring
nonexistent characters).
The bounding box of the font (that is, the
smallest rectangle enclosing the shape obtained by superimposing all
characters at the same origin [x,y]) has its upper-left coordinate at:
[x + min-bounds.left-side-bearing, y - max-bounds.ascent]
with a width of:
max-bounds.right-side-bearing - min-bounds.left-side-bearing
and a height of:
max-bounds.ascent + max-bounds.descent
The font-ascent is the logical extent of the font above the baseline
and is used for determining line spacing.
Specific characters may extend beyond this.
The font-descent is the logical extent of the font at or below the baseline
and is used for determining line spacing.
Specific characters may extend beyond this.
If the baseline is at Y-coordinate y,
then the logical extent of the font is inclusive
between the Y-coordinate values (y - font-ascent) and (y + font-descent - 1).
A font is not guaranteed to have any properties.
The interpretation of the property value (for example, INT32, CARD32)
must be derived from a priori knowledge of the property.
A basic set of font properties is specified in the X.Org
standard X Logical Font Description Conventions .
For a character origin at [x,y],
the bounding box of a character (that is,
the smallest rectangle enclosing the character's shape), described in
terms of CHARINFO components, is a rectangle with its upper-left corner at:
[x + left-side-bearing, y - ascent]
with a width of:
right-side-bearing - left-side-bearing
and a height of:
ascent + descent
and the origin for the next character is defined to be:
[x + character-width, y]
Note that the baseline is logically viewed as being just below
nondescending characters (when descent is zero, only pixels with
Y-coordinates less than y are drawn) and that the origin is logically
viewed as being coincident with the left edge of a nonkerned character
(when left-side-bearing is zero, no pixels with X-coordinate less than
x are drawn).
Note that CHARINFO metric values can be negative.
A nonexistent character is represented with all CHARINFO components
zero.
The interpretation of the per-character attributes field is
server-dependent.
QueryTextExtents
QueryTextExtents
font : FONTABLE
string : STRING16
â–¶
draw-direction:
{ LeftToRight ,
RightToLeft }
font-ascent: INT16
font-descent: INT16
overall-ascent: INT16
overall-descent: INT16
overall-width: INT32
overall-left: INT32
overall-right: INT32
Errors:
Font
This request returns the logical extents of the specified string of characters
in the specified font.
If a gcontext is given for font,
the currently contained font is used.
The draw-direction, font-ascent, and font-descent are the same as
described in
QueryFont .
The overall-ascent is the maximum of the ascent metrics of all characters
in the string, and the overall-descent is the maximum of the descent metrics.
The overall-width is the sum of the character-width metrics of all characters
in the string.
For each character in the string,
let W be the sum of the character-width metrics of all characters preceding it
in the string,
let L be the left-side-bearing metric of the character plus W,
and let R be the right-side-bearing metric of the character plus W.
The overall-left is the minimum L of all characters in the string,
and the overall-right is the maximum R.
For fonts defined with linear indexing rather than 2-byte matrix indexing,
the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (that is, byte1 of the
CHAR2B is taken as the most significant byte).
Characters with all zero metrics are ignored.
If the font has no defined default-char,
then undefined characters in the string are also ignored.
ListFonts
ListFonts
pattern : STRING8
max-names : CARD16
â–¶
names: LISTofSTRING8
This request returns a list
of available font names (as controlled by the font search path; see
SetFontPath
request)
that match the pattern.
At most, max-names names will be returned.
The pattern should use the ISO Latin-1 encoding,
and uppercase and lowercase do not matter.
In the pattern,
the ?
character (octal value 77) will match any single character,
and the *
character (octal value 52) will match any number
of characters.
The returned names are in lowercase.
ListFontsWithInfo
ListFontsWithInfo
pattern : STRING8
max-names : CARD16
â–¶
name: STRING8
info FONTINFO
replies-hint: CARD32
where:
FONTINFO: <same type definition as in
QueryFont >
This request is similar to
ListFonts ,
but it also returns information about each font.
The information returned for each font is identical to what
QueryFont
would return except that the per-character metrics are not returned.
Note that this request can generate multiple replies.
With each reply,
replies-hint may provide an indication of how many more fonts will be returned.
This number is a hint only and may be larger or smaller than
the number of fonts actually returned.
A zero value does not guarantee that no more fonts will be returned.
After the font replies,
a reply with a zero-length name is sent to indicate the end of the reply
sequence.
SetFontPath
SetFontPath
path : LISTofSTRING8
Errors:
Value
This request defines the search path for font lookup.
There is only one search path per server, not one per client.
The interpretation of the strings is operating-system-dependent,
but the strings are intended to specify directories to be searched in the
order listed.
Setting the path to the empty list restores the default path defined
for the server.
As a side effect of executing this request,
the server is guaranteed to flush all cached information about fonts
for which there currently are no explicit resource IDs allocated.
The meaning of an error from this request is system specific.
GetFontPath
GetFontPath
â–¶
path: LISTofSTRING8
This request returns the current search path for fonts.
CreatePixmap
CreatePixmap
pid : PIXMAP
drawable : DRAWABLE
depth : CARD8
width , height : CARD16
Errors:
Alloc ,
Drawable ,
IDChoice ,
Value
This request creates a pixmap and assigns the identifier pid to it.
The width and height must be nonzero (or a
Value
error results).
The depth must be one of the depths supported by the root of the specified
drawable (or a
Value
error results).
The initial contents of the pixmap are undefined.
It is legal to pass an
InputOnly
window as a drawable to this request.
FreePixmap
FreePixmap
pixmap : PIXMAP
Errors:
Pixmap
This request deletes the association between the resource ID and the pixmap.
The pixmap storage will be freed when no other resource references it.
CreateGC
CreateGC Graphics context
cid : GCONTEXT
drawable : DRAWABLE
value-mask : BITMASK
value-list : LISTofVALUE
Errors:
Alloc ,
Drawable ,
Font ,
IDChoice ,
Match ,
Pixmap ,
Value
This request creates a graphics context
and assigns the identifier cid to it.
The gcontext can be used with any destination drawable having the same root
and depth as the specified drawable;
use with other drawables results in a
Match
error.
The value-mask and value-list specify which components are to be
explicitly initialized.
The context components are:
Component
Type
function
{ Clear ,
And ,
AndReverse ,
Copy ,
AndInverted ,
NoOp ,
Xor ,
Or ,
Nor ,
Equiv ,
Invert ,
OrReverse ,
CopyInverted ,
OrInverted ,
Nand ,
Set }
plane-mask
CARD32
foreground
CARD32
background
CARD32
line-width
CARD16
line-style
{ Solid ,
OnOffDash ,
DoubleDash }
cap-style
{ NotLast ,
Butt ,
Round ,
Projecting }
join-style
{ Miter ,
Round ,
Bevel }
fill-style
{ Solid ,
Tiled ,
OpaqueStippled ,
Stippled }
fill-rule
{ EvenOdd ,
Winding }
arc-mode
{ Chord ,
PieSlice }
tile
PIXMAP
stipple
PIXMAP
tile-stipple-x-origin
INT16
tile-stipple-y-origin
INT16
font
FONT
subwindow-mode
{ ClipByChildren ,
IncludeInferiors }
graphics-exposures
BOOL
clip-x-origin
INT16
clip-y-origin
INT16
clip-mask
PIXMAP or
None
dash-offset
CARD16
dashes
CARD8
Plane mask
((src FUNC dst) AND plane-mask) OR (dst AND (NOT plane-mask))
Range checking is not performed on the values for foreground, background,
or plane-mask.
They are simply truncated to the appropriate number of bits.
The meanings of the functions are:
Function
Operation
Clear
0
And
src AND dst
AndReverse
src AND (NOT dst)
Copy
src
AndInverted
(NOT src) AND dst
NoOp
dst
Xor
src XOR dst
Or
src OR dst
Nor
(NOT src) AND (NOT dst)
Equiv
(NOT src) XOR dst
Invert
NOT dst
OrReverse
src OR (NOT dst)
CopyInverted
NOT src
OrInverted
(NOT src) OR dst
Nand
(NOT src) OR (NOT dst)
Set
1
Line drawing
Wide lines are drawn centered on the path described by the graphics request.
Unless otherwise specified by the join or cap style,
the bounding box of a wide line with endpoints [x1, y1], [x2, y2] and
width w is a rectangle with vertices at the following real coordinates:
[x1-(w*sn/2), y1+(w*cs/2)], [x1+(w*sn/2), y1-(w*cs/2)],
[x2-(w*sn/2), y2+(w*cs/2)], [x2+(w*sn/2), y2-(w*cs/2)]
The sn is the sine of the angle of the line and cs is the cosine of
the angle of the line.
A pixel is part of the line (and hence drawn) if the center of the pixel
is fully inside the bounding box, which is viewed as having infinitely thin
edges.
If the center of the pixel is exactly on the bounding box,
it is part of the line if and only if the interior is immediately to its right
(x increasing direction).
Pixels with centers on a horizontal edge are a special case and are part of
the line if and only if the interior or the boundary is immediately below
(y increasing direction) and if the interior or the boundary is immediately
to the right (x increasing direction).
Note that this description is a mathematical model describing the pixels
that are drawn for a wide line and does not imply that trigonometry is required
to implement such a model.
Real or fixed point arithmetic is recommended for computing the corners of the
line endpoints for lines greater than one pixel in width.
Thin lines (zero line-width) are nominally one pixel wide lines drawn using an
unspecified, device-dependent algorithm.
There are only two constraints on this algorithm.
First, if a line is drawn unclipped from [x1,y1] to [x2,y2]
and another line is drawn unclipped from [x1+dx,y1+dy] to [x2+dx,y2+dy],
then a point [x,y] is touched by drawing the first line if
and only if the point [x+dx,y+dy] is touched by drawing the second line.
Second, the effective set of points comprising a line cannot be affected
by clipping.
Thus, a point is touched in a clipped line if and only if the point lies
inside the clipping region and the point would be touched by the line
when drawn unclipped.
Note that a wide line drawn from [x1,y1] to [x2,y2] always draws the
same pixels as a wide line drawn from [x2,y2] to [x1,y1], not counting
cap-style and join-style.
Implementors are encouraged to make this property true for thin lines,
but it is not required.
A line-width of zero may differ from a line-width of one in which pixels
are drawn.
In general,
drawing a thin line will be faster than drawing a wide line of width one,
but thin lines may not mix well aesthetically with wide lines
because of the different drawing algorithms.
If it is desirable to obtain precise and uniform results across all displays,
a client should always use a line-width of one, rather than a line-width of
zero.
The line-style defines which sections of a line are drawn:
Solid
The full path of the line is drawn.
DoubleDash
The full path of the line is drawn,
but the even dashes are filled differently than the odd dashes
(see fill-style), with
Butt
cap-style used where even and odd dashes meet.
OnOffDash
Only the even dashes are drawn,
and cap-style applies to all internal ends of the individual dashes
(except
NotLast
is treated as
Butt ).
The cap-style defines how the endpoints of a path are drawn:
NotLast
The result is equivalent to
Butt ,
except that for a line-width of zero the final endpoint is not drawn.
Butt
The result is square at the endpoint (perpendicular to the slope of the
line) with no projection beyond.
Round
The result is a circular arc with its diameter equal to the line-width,
centered on the endpoint; it is equivalent to
Butt
for line-width zero.
Projecting
The result is square at the end, but the path continues beyond the
endpoint for a distance equal to half the line-width;
it is equivalent to
Butt
for line-width zero.
The join-style defines how corners are drawn for wide lines:
Miter
The outer edges of the two lines extend to meet at an angle.
However, if the angle is less than 11 degrees, a
Bevel
join-style is used instead.
Round
The result is a circular arc with a diameter equal to the line-width,
centered on the joinpoint.
Bevel
The result is
Butt
endpoint styles, and then the triangular notch is filled.
For a line with coincident endpoints (x1=x2, y1=y2), when the cap-style
is applied to both endpoints, the semantics depends on the line-width
and the cap-style:
NotLast
thin
This is device-dependent, but the desired effect is that nothing is drawn.
Butt
thin
This is device-dependent, but the desired effect is that
a single pixel is drawn.
Round
thin
This is the same as
Butt /thin.
Projecting
thin
This is the same as
Butt /thin.
Butt
wide
Nothing is drawn.
Round
wide
The closed path is a circle, centered at the endpoint and
with a diameter equal to the line-width.
Projecting
wide
The closed path is a square, aligned with the coordinate axes,
centered at the endpoint and with sides equal to the line-width.
For a line with coincident endpoints (x1=x2, y1=y2),
when the join-style is applied at one or both endpoints,
the effect is as if the line was removed from the overall path.
However, if the total path consists of (or is reduced to) a single point
joined with itself,
the effect is the same as when the cap-style is applied at both endpoints.
The tile/stipple represents an infinite two-dimensional plane
with the tile/stipple
replicated in all dimensions. When that plane is superimposed on
the drawable for use in a graphics operation, the upper-left corner
of some instance of the tile/stipple is at the coordinates within
the drawable specified by the tile/stipple origin.
The tile/stipple and clip origins are interpreted relative to the
origin of whatever destination drawable is specified in a graphics
request.
The tile pixmap must have the same root and depth as the gcontext (or a
Match
error results).
The stipple pixmap must have depth one and must have the same root
as the gcontext (or a
Match
error results).
For fill-style
Stippled
(but not fill-style
OpaqueStippled ),
the stipple pattern is tiled in a single plane
and acts as an additional clip mask to be ANDed with the clip-mask.
Any size pixmap can be used for tiling or stippling,
although some sizes may be faster to use than others.
The fill-style defines the contents of the source for line, text, and
fill requests.
For all text and fill requests (for example,
PolyText8 ,
PolyText16 ,
PolyFillRectangle ,
FillPoly ,
and
PolyFillArc )
as well as for line requests with line-style
Solid ,
(for example,
PolyLine ,
PolySegment ,
PolyRectangle ,
PolyArc )
and for the even dashes for line requests with line-style
OnOffDash
or
DoubleDash :
Solid
Foreground
Tiled
Tile
OpaqueStippled
A tile with the same width and height as stipple
but with background everywhere stipple has a zero
and with foreground everywhere stipple has a one
Stippled
Foreground masked by stipple
For the odd dashes for line requests with line-style
DoubleDash :
Solid
Background
Tiled
Same as for even dashes
OpaqueStippled
Same as for even dashes
Stippled
Background masked by stipple
The dashes value allowed here is actually a simplified form of the more
general patterns that can be set with
SetDashes .
Specifying a value of N here is equivalent to specifying
the two element list [N, N] in
SetDashes .
The value must be nonzero (or a
Value
error results).
The meaning of dash-offset and dashes are explained in the
SetDashes
request.
Clipping region Match
error results).
If clip-mask is
None ,
then pixels are always drawn, regardless of the clip origin.
The clip-mask can also be set with the
SetClipRectangles
request.
For
ClipByChildren ,
both source and destination windows are additionally clipped by all viewable
InputOutput
children.
For
IncludeInferiors ,
neither source nor destination window is clipped by inferiors.
This will result in including subwindow contents in the
source and drawing through subwindow boundaries of the destination.
The use of
IncludeInferiors
with a source or destination window of one depth with mapped inferiors
of differing depth is not illegal,
but the semantics is undefined by the core protocol.
Winding rule Fill rule FillPoly
requests.
EvenOdd
means a point is inside if an infinite ray with the point as origin crosses
the path an odd number of times.
For
Winding ,
a point is inside if an infinite ray with the point as origin crosses an
unequal number of clockwise and counterclockwise directed path segments.
A clockwise directed path segment is one that crosses the ray from left
to right as observed from the point.
A counter-clockwise segment is one that crosses the ray from right to left
as observed from the point.
The case where a directed line segment is coincident with the ray is
uninteresting because one can simply choose a different ray that is not
coincident with a segment.
For both fill rules,
a point is infinitely small and the path is an infinitely thin line.
A pixel is inside if the center point of the pixel is inside
and the center point is not on the boundary.
If the center point is on the boundary,
the pixel is inside if and only if the polygon interior is immediately
to its right (x increasing direction).
Pixels with centers along a horizontal edge are a special case
and are inside if and only if the polygon interior is immediately below
(y increasing direction).
The arc-mode controls filling in the
PolyFillArc
request.
The graphics-exposures flag controls
GraphicsExposure
event generation for
CopyArea
and
CopyPlane
requests (and any similar requests defined by extensions).
The default component values are:
Component
Default
function
Copy
plane-mask
all ones
foreground
0
background
1
line-width
0
line-style
Solid
cap-style
Butt
join-style
Miter
fill-style
Solid
fill-rule
EvenOdd
arc-mode
PieSlice
tile
Pixmap of unspecified size filled with foreground pixel
(that is, client specified pixel if any, else 0)
(subsequent changes to foreground do not affect this pixmap)
stipple
Pixmap of unspecified size filled with ones
tile-stipple-x-origin
0
tile-stipple-y-origin
0
font
<server-dependent-font>
subwindow-mode
ClipByChildren
graphics-exposures
True
clip-x-origin
0
clip-y-origin
0
clip-mask
None
dash-offset
0
dashes
4 (that is, the list [4, 4])
Storing a pixmap in a gcontext might or might not result in a copy
being made.
If the pixmap is later used as the destination for a graphics request,
the change might or might not be reflected in the gcontext.
If the pixmap is used simultaneously in a graphics request
as both a destination and as a tile or stipple,
the results are not defined.
It is quite likely that some amount of gcontext information will be
cached in display hardware and that such hardware can only cache a
small number of gcontexts.
Given the number and complexity of components,
clients should view switching between gcontexts with nearly
identical state as significantly more expensive than making minor
changes to a single gcontext.
ChangeGC
ChangeGC
gc : GCONTEXT
value-mask : BITMASK
value-list : LISTofVALUE
Errors:
Alloc ,
Font ,
GContext ,
Match ,
Pixmap ,
Value
This request changes components in gc.
The value-mask and value-list specify which components are to be changed.
The values and restrictions are the same
as for
CreateGC .
Changing the clip-mask also overrides any previous
SetClipRectangles
request on the context.
Changing dash-offset or dashes overrides any previous
SetDashes
request on the context.
The order in which components are verified and altered is server-dependent.
If an error is generated,
a subset of the components may have been altered.
CopyGC
CopyGC
src-gc , dst-gc : GCONTEXT
value-mask : BITMASK
Errors:
Alloc ,
GContext ,
Match ,
Value
This request copies components from src-gc to dst-gc.
The value-mask specifies which components to copy, as for
CreateGC .
The two gcontexts must have the same root and the same depth (or a
Match
error results).
SetDashes
SetDashes
gc : GCONTEXT
dash-offset : CARD16
dashes : LISTofCARD8
Errors:
Alloc ,
GContext ,
Value
This request sets dash-offset and dashes in gc for dashed line styles.
Dashes cannot be empty (or a
Value
error results).
Specifying an odd-length list is equivalent to specifying the same list
concatenated with itself to produce an even-length list.
The initial and alternating elements of dashes are the even dashes;
the others are the odd dashes.
Each element specifies a dash length in pixels.
All of the elements must be nonzero (or a
Value
error results).
The dash-offset defines the phase of the pattern,
specifying how many pixels into dashes the pattern should actually begin in
any single graphics request.
Dashing is continuous through path elements combined with a join-style
but is reset to the dash-offset between each sequence of joined lines.
The unit of measure for dashes is the same as in the ordinary
coordinate system.
Ideally, a dash length is measured along the slope of the line,
but implementations are only required to match this ideal
for horizontal and vertical lines.
Failing the ideal semantics,
it is suggested that the length be measured along the major axis of the line.
The major axis is defined as the x axis for lines drawn at an angle of
between -45 and +45 degrees or between 135 and 225 degrees from the x axis.
For all other lines, the major axis is the y axis.
For any graphics primitive, the computation of the endpoint of an individual
dash only depends on the geometry of the primitive, the start position
of the dash, the direction of the dash, and the dash length.
For any graphics primitive, the total set of pixels used to render the
primitive (both even and odd numbered dash elements) with
DoubleDash
line-style is the same as the set of pixels used to render the
primitive with
Solid
line-style.
For any graphics primitive, if the primitive is drawn with
OnOffDash
or
DoubleDash
line-style unclipped at position [x,y] and again at position
[x+dx,y+dy], then a point [x1,y1] is included in a dash in the first
instance if and only if the point [x1+dx,y1+dy] is included in the dash in
the second instance. In addition, the effective set of points comprising a
dash cannot be affected by clipping. A point is included in a clipped dash
if and only if the point lies inside the clipping region and the point
would be included in the dash when drawn unclipped.
SetClipRectangles
SetClipRectangles
gc : GCONTEXT
clip-x-origin , clip-y-origin : INT16
rectangles : LISTofRECTANGLE
ordering :
{ UnSorted ,
YSorted ,
YXSorted ,
YXBanded }
Errors:
Alloc ,
GContext ,
Match ,
Value
This request changes clip-mask in gc to the specified list of rectangles
and sets the clip origin.
Output will be clipped to remain contained within the rectangles.
The clip origin is interpreted relative to the origin of
whatever destination drawable is specified in a graphics request.
The rectangle coordinates are interpreted relative to the clip origin.
The rectangles should be nonintersecting, or graphics results will be
undefined.
Note that the list of rectangles can be empty,
which effectively disables output.
This is the opposite of passing
None
as the clip-mask in
CreateGC
and
ChangeGC .
If known by the client,
ordering relations on the rectangles can be specified with the ordering
argument.
This may provide faster operation by the server.
If an incorrect ordering is specified,
the server may generate a
Match
error, but it is not required to do so.
If no error is generated,
the graphics results are undefined.
UnSorted
means that the rectangles are in arbitrary order.
YSorted
means that the rectangles are nondecreasing in their Y origin.
YXSorted
additionally constrains
YSorted
order in that all rectangles with an equal Y origin are
nondecreasing in their X origin.
YXBanded
additionally constrains
YXSorted
by requiring that, for every possible Y scanline,
all rectangles that include that scanline have identical Y origins and Y
extents.
FreeGC
FreeGC
gc : GCONTEXT
Errors:
GContext
This request deletes the association between the resource ID and the gcontext
and destroys the gcontext.
ClearArea
ClearArea Background
window : WINDOW
x , y : INT16
width , height : CARD16
exposures : BOOL
Errors:
Match ,
Value ,
Window
The x and y coordinates are relative to the window's origin
and specify the upper-left corner of the rectangle.
If width is zero,
it is replaced with the current width of the window minus x.
If height is zero,
it is replaced with the current height of the window minus y.
If the window has a defined background tile,
the rectangle is tiled with a plane-mask of all ones and function of
Copy
and a subwindow-mode of
ClipByChildren .
If the window has background
None ,
the contents of the window are not changed.
In either case,
if exposures is
True ,
then one or more exposure events are generated for regions of the rectangle
that are either visible or are being retained in a backing store.
It is a
Match
error to use an
InputOnly
window in this request.
CopyArea
CopyArea
src-drawable , dst-drawable : DRAWABLE
gc : GCONTEXT
src-x , src-y : INT16
width , height : CARD16
dst-x , dst-y : INT16
Errors:
Drawable ,
GContext ,
Match
This request combines the specified rectangle of src-drawable with the
specified rectangle of dst-drawable.
The src-x and src-y coordinates are relative to src-drawable's origin.
The dst-x and dst-y are relative to dst-drawable's origin,
each pair specifying the upper-left corner of the rectangle.
The src-drawable must have the same root and the same depth
as dst-drawable (or a
Match
error results).
If regions of the source rectangle are obscured and have not been retained
in backing store
or if regions outside the boundaries of the source drawable are specified,
then those regions are not copied,
but the following occurs on all corresponding destination regions that are
either visible or are retained in backing-store.
If the dst-drawable is a window with a background other than
None ,
these corresponding destination regions are tiled
(with plane-mask of all ones and function
Copy )
with that background.
Regardless of tiling and whether the destination is a window or a pixmap,
if graphics-exposures in gc is
True ,
then
GraphicsExposure
events for all corresponding destination regions are generated.
If graphics-exposures is
True
but no
GraphicsExposure
events are generated,
then a
NoExposure
event is generated.
GC components: function, plane-mask, subwindow-mode,
graphics-exposures, clip-x-origin, clip-y-origin, clip-mask
CopyPlane
CopyPlane
src-drawable , dst-drawable : DRAWABLE
gc : GCONTEXT
src-x , src-y : INT16
width , height : CARD16
dst-x , dst-y : INT16
bit-plane : CARD32
Errors:
Drawable ,
GContext ,
Match ,
Value
The src-drawable must have the same root as dst-drawable (or a
Match
error results), but it need not have the same depth.
The bit-plane must have exactly one bit set to 1 and the value of bit-plane
must be less than %2 sup n% where n is the depth of src-drawable (or a
Value
error results).
Effectively, a pixmap of the same depth as dst-drawable and with size specified
by the source region is formed using the foreground/background pixels in gc
(foreground everywhere the bit-plane in src-drawable contains a bit set to 1,
background everywhere the bit-plane contains a bit set to 0),
and the equivalent of a
CopyArea
is performed, with all the same exposure semantics.
This can also be thought of as using the specified region of the source
bit-plane as a stipple with a fill-style of
OpaqueStippled
for filling a rectangular area of the destination.
GC components: function, plane-mask, foreground, background,
subwindow-mode, graphics-exposures, clip-x-origin, clip-y-origin,
clip-mask
PolyPoint
PolyPoint
drawable : DRAWABLE
gc : GCONTEXT
coordinate-mode :
{ Origin ,
Previous }
points : LISTofPOINT
Errors:
Drawable ,
GContext ,
Match ,
Value
This request combines the foreground pixel in gc with the pixel
at each point in the drawable.
The points are drawn in the order listed.
The first point is always relative to the drawable's origin.
The rest are relative either to that origin or the previous point,
depending on the coordinate-mode.
GC components: function, plane-mask, foreground, subwindow-mode,
clip-x-origin, clip-y-origin, clip-mask
PolyLine
PolyLine Line drawing
drawable : DRAWABLE
gc : GCONTEXT
coordinate-mode :
{ Origin ,
Previous }
points : LISTofPOINT
Errors:
Drawable ,
GContext ,
Match ,
Value
This request draws lines between each pair of points (point[i], point[i+1]).
The lines are drawn in the order listed.
The lines join correctly at all intermediate points,
and if the first and last points coincide,
the first and last lines also join correctly.
For any given line,
no pixel is drawn more than once.
If thin (zero line-width) lines intersect,
the intersecting pixels are drawn multiple times.
If wide lines intersect,
the intersecting pixels are drawn only once, as though the entire
PolyLine
were a single filled shape.
The first point is always relative to the drawable's origin.
The rest are relative either to that origin or the previous point,
depending on the coordinate-mode.
When either of the two lines involved in a
Bevel
join is neither vertical
nor horizontal, then the slope and position of the line segment defining
the bevel join edge is implementation dependent. However, the computation
of the slope and distance (relative to the join point) only depends on
the line width and the slopes of the two lines.
GC components: function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes
PolySegment
PolySegment
drawable : DRAWABLE
gc : GCONTEXT
segments : LISTofSEGMENT
where:
SEGMENT: [x1, y1, x2, y2: INT16]
Errors:
Drawable ,
GContext ,
Match
For each segment,
this request draws a line between [x1, y1] and [x2, y2].
The lines are drawn in the order listed.
No joining is performed at coincident endpoints.
For any given line,
no pixel is drawn more than once.
If lines intersect,
the intersecting pixels are drawn multiple times.
GC components: function, plane-mask, line-width, line-style,
cap-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,
clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes
PolyRectangle
PolyRectangle
drawable : DRAWABLE
gc : GCONTEXT
rectangles : LISTofRECTANGLE
Errors:
Drawable ,
GContext ,
Match
This request draws the outlines of the specified rectangles, as if a five-point
PolyLine
were specified for each rectangle:
[x,y] [x+width,y] [x+width,y+height] [x,y+height] [x,y]
The x and y coordinates of each rectangle are relative to the drawable's origin
and define the upper-left corner of the rectangle.
The rectangles are drawn in the order listed.
For any given rectangle,
no pixel is drawn more than once.
If rectangles intersect,
the intersecting pixels are drawn multiple times.
GC components: function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes
PolyArc
PolyArc
drawable : DRAWABLE
gc : GCONTEXT
arcs : LISTofARC
Errors:
Drawable ,
GContext ,
Match
This request draws circular or elliptical arcs.
Each arc is specified by a rectangle and two angles.
The angles are signed integers in degrees scaled by 64,
with positive indicating counterclockwise motion and
negative indicating clockwise motion.
The start of the arc is specified by angle1 relative to the three-o'clock
position from the center of the rectangle,
and the path and extent of the arc is specified by angle2 relative to the
start of the arc.
If the magnitude of angle2 is greater than 360 degrees,
it is truncated to 360 degrees.
The x and y coordinates of the rectangle are relative to the origin of
the drawable.
For an arc specified as [x,y,w,h,a1,a2],
the origin of the major and minor axes is at [x+(w/2),y+(h/2)],
and the infinitely thin path describing the entire circle/ellipse intersects
the horizontal axis at [x,y+(h/2)] and [x+w,y+(h/2)] and intersects the
vertical axis at [x+(w/2),y] and [x+(w/2),y+h].
These coordinates are not necessarily integral; that is,
they are not truncated to discrete coordinates.
For a wide line with line-width lw, the ideal bounding outlines for filling
are given by the two infinitely thin paths consisting of all points whose
perpendicular distance from a tangent to the path of the circle/ellipse is
equal to lw/2 (which may be a fractional value). When the width and height
of the arc are not equal and both are nonzero, then the actual bounding
outlines are implementation dependent. However, the computation of the
shape and position of the bounding outlines (relative to the center of the
arc) only depends on the width and height of the arc and the
line-width.
The cap-style is applied the same as for a line corresponding to the
tangent of the circle/ellipse at the endpoint. When the angle of an arc
face is not an integral multiple of 90 degrees, and the width and height of
the arc are both are nonzero, then the shape and position of the cap at
that face is implementation dependent. However, for a
Butt
cap, the face
is defined by a straight line, and the computation of the position
(relative to the center of the arc) and the slope of the line only
depends on the width and height of the arc and the angle of the arc face.
For other cap styles, the computation of the position (relative to the
center of the arc) and the shape of the cap only depends on the width
and height of the arc, the line-width, the angle of the arc face, and the
direction (clockwise or counter clockwise) of the arc from the endpoint.
The join-style is applied the same as for two lines corresponding to the
tangents of the circles/ellipses at the join point. When the width and
height of both arcs are nonzero, and the angle of either arc face is not an
integral multiple of 90 degrees, then the shape of the join is
implementation dependent. However, the computation of the shape only
depends on the width and height of each arc, the line-width, the angles of
the two arc faces, the direction (clockwise or counter clockwise) of the
arcs from the join point, and the relative orientation of the two arc
center points.
For an arc specified as [x,y,w,h,a1,a2],
the angles must be specified in the effectively skewed coordinate system of
the ellipse (for a circle, the angles and coordinate systems are identical).
The relationship between these angles and angles expressed in the normal
coordinate system of the screen (as measured with a protractor) is as
follows:
skewed-angle = atan(tan(normal-angle) * w/h) + adjust
The skewed-angle and normal-angle are expressed in radians (rather
than in degrees scaled by 64) in the range [0,2*PI).
The atan returns a value in the range [-PI/2,PI/2].
The adjust is:
0
for normal-angle in the range [0,PI/2)
PI
for normal-angle in the range [PI/2,(3*PI)/2)
2*PI
for normal-angle in the range [(3*PI)/2,2*PI)
The arcs are drawn in the order listed.
If the last point in one arc coincides with the first point in the following
arc,
the two arcs will join correctly.
If the first point in the first arc coincides with the last point
in the last arc,
the two arcs will join correctly.
For any given arc,
no pixel is drawn more than once.
If two arcs join correctly and the line-width is greater than zero
and the arcs intersect,
no pixel is drawn more than once.
Otherwise, the intersecting pixels of intersecting arcs are drawn multiple
times.
Specifying an arc with one endpoint and a clockwise extent draws the
same pixels as specifying the other endpoint and an equivalent
counterclockwise extent, except as it affects joins.
By specifying one axis to be zero,
a horizontal or vertical line can be drawn.
Angles are computed based solely on the coordinate system,
ignoring the aspect ratio.
GC components: function, plane-mask, line-width, line-style,
cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes
FillPoly
FillPoly
drawable : DRAWABLE
gc : GCONTEXT
shape :
{ Complex ,
Nonconvex ,
Convex }
coordinate-mode :
{ Origin ,
Previous }
points : LISTofPOINT
Errors:
Drawable ,
GContext ,
Match ,
Value
This request fills the region closed by the specified path.
The path is closed automatically if the last point in the list does not
coincide with the first point.
No pixel of the region is drawn more than once.
The first point is always relative to the drawable's origin.
The rest are relative either to that origin or the previous point,
depending on the coordinate-mode.
The shape parameter may be used by the server to improve performance.
Complex
means the path may self-intersect.
Contiguous coincident points in the path are not treated
as self-intersection.
Nonconvex
means the path does not self-intersect,
but the shape is not wholly convex.
If known by the client,
specifying
Nonconvex
over
Complex
may improve performance.
If
Nonconvex
is specified for a self-intersecting path,
the graphics results are undefined.
Convex
means that for every pair of points inside the polygon,
the line segment connecting them does not intersect the path.
If known by the client,
specifying
Convex
can improve performance.
If
Convex
is specified for a path that is not convex,
the graphics results are undefined.
GC components: function, plane-mask, fill-style, fill-rule,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillRectangle
PolyFillRectangle
drawable : DRAWABLE
gc : GCONTEXT
rectangles : LISTofRECTANGLE
Errors:
Drawable ,
GContext ,
Match
This request fills the specified rectangles, as if a four-point
FillPoly
were specified for each rectangle:
[x,y] [x+width,y] [x+width,y+height] [x,y+height]
The x and y coordinates of each rectangle are relative to the drawable's origin
and define the upper-left corner of the rectangle.
The rectangles are drawn in the order listed.
For any given rectangle,
no pixel is drawn more than once.
If rectangles intersect,
the intersecting pixels are drawn multiple times.
GC components: function, plane-mask, fill-style, subwindow-mode,
clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyFillArc
PolyFillArc
drawable : DRAWABLE
gc : GCONTEXT
arcs : LISTofARC
Errors:
Drawable ,
GContext ,
Match
For each arc,
this request fills the region closed by the infinitely thin path
described by the specified arc and one or two line segments,
depending on the arc-mode.
For
Chord ,
the single line segment joining the endpoints of the arc is used.
For
PieSlice ,
the two line segments joining the endpoints of the arc with the center point
are used.
For an arc specified as [x,y,w,h,a1,a2], the origin of the major and minor
axes is at [x+(w/2),y+(h/2)], and the infinitely thin path describing the
entire circle/ellipse intersects the horizontal axis at [x,y+(h/2)] and
[x+w,y+(h/2)] and intersects the vertical axis at [x+(w/2),y] and
[x+(w/2),y+h]. These coordinates are not necessarily integral; that is,
they are not truncated to discrete coordinates.
The arc angles are interpreted as specified in the
PolyArc
request. When
the angle of an arc face is not an integral multiple of 90 degrees, then
the precise endpoint on the arc is implementation dependent. However, for
Chord
arc-mode, the computation of the pair of endpoints (relative to the
center of the arc) only depends on the width and height of the arc and
the angles of the two arc faces. For
PieSlice
arc-mode, the computation of
an endpoint only depends on the angle of the arc face for that
endpoint and the ratio of the arc width to arc height.
The arcs are filled in the order listed.
For any given arc,
no pixel is drawn more than once.
If regions intersect,
the intersecting pixels are drawn multiple times.
GC components: function, plane-mask, fill-style, arc-mode,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PutImage
PutImage
drawable : DRAWABLE
gc : GCONTEXT
depth : CARD8
width , height : CARD16
dst-x , dst-y : INT16
left-pad : CARD8
format :
{ Bitmap ,
XYPixmap ,
ZPixmap }
data : LISTofBYTE
Errors:
Drawable ,
GContext ,
Match ,
Value
This request combines an image with a rectangle of the drawable.
The dst-x and dst-y coordinates are relative to the drawable's origin.
If
Bitmap
format is used,
then depth must be one (or a
Match
error results), and the image must be in XY format.
The foreground pixel in gc defines the source for bits set to 1 in the image,
and the background pixel defines the source for the bits set to 0.
For
XYPixmap
and
ZPixmap ,
the depth must match the depth of the drawable (or a
Match
error results).
For
XYPixmap ,
the image must be sent in XY format.
For
ZPixmap ,
the image must be sent in the Z format defined for the given depth.
The left-pad must be zero for
ZPixmap
format (or a
Match
error results).
For
Bitmap
and
XYPixmap
format,
left-pad must be less than bitmap-scanline-pad as given in the server
connection setup information (or a
Match
error results).
The first left-pad bits in every scanline are to be ignored by the server.
The actual image begins that many bits into the data.
The width argument defines the width of the actual image
and does not include left-pad.
GC components: function, plane-mask, subwindow-mode, clip-x-origin,
clip-y-origin, clip-mask
GC mode-dependent components: foreground, background
GetImage
GetImage
drawable : DRAWABLE
x , y : INT16
width , height : CARD16
plane-mask : CARD32
format :
{ XYPixmap ,
ZPixmap }
â–¶
depth: CARD8
visual: VISUALID or
None
data: LISTofBYTE
Errors:
Drawable ,
Match ,
Value
This request returns the contents of the given rectangle of the drawable in the
given format.
The x and y coordinates are relative to the drawable's origin
and define the upper-left corner of the rectangle.
If
XYPixmap
is specified,
only the bit planes specified in plane-mask are transmitted,
with the planes appearing from most significant to least significant
in bit order.
If
ZPixmap
is specified, then bits in all planes not specified in plane-mask are
transmitted as zero.
Range checking is not performed on plane-mask;
extraneous bits are simply ignored.
The returned depth is as specified when the drawable was created
and is the same as a depth component in a FORMAT structure (in the connection
setup), not a bits-per-pixel component.
If the drawable is a window,
its visual type is returned.
If the drawable is a pixmap,
the visual is
None .
If the drawable is a pixmap,
then the given rectangle must be wholly contained within the pixmap (or a
Match
error results).
If the drawable is a window,
the window must be viewable,
and it must be the case that,
if there were no inferiors or overlapping windows,
the specified rectangle of the window would be fully visible on the screen
and wholly contained within the outside edges of the window (or a
Match
error results).
Note that the borders of the window can be included and read with this request.
If the window has a backing store,
then the backing-store contents are returned for regions of the window
that are obscured by noninferior windows;
otherwise, the returned contents of such obscured regions are undefined.
Also undefined are the returned contents of visible
regions of inferiors of different depth than the specified window.
The pointer cursor image is not included in the contents returned.
This request is not general-purpose in the same sense as other
graphics-related requests.
It is intended specifically for rudimentary hardcopy support.
PolyText8
PolyText8
drawable : DRAWABLE
gc : GCONTEXT
x , y : INT16
items : LISTofTEXTITEM8
where:
TEXTITEM8:
TEXTELT8 or FONT
TEXTELT8:
[delta: INT8
string: STRING8]
Errors:
Drawable ,
Font ,
GContext ,
Match
The x and y coordinates are relative to the drawable's origin
and specify the baseline starting position (the initial character origin).
Each text item is processed in turn.
A font item causes the font to be stored in gc
and to be used for subsequent text.
Switching among fonts does not affect the next character origin.
A text element delta specifies an additional change in the position
along the x axis before the string is drawn;
the delta is always added to the character origin.
Each character image, as defined by the font in gc,
is treated as an additional mask for a fill operation on the drawable.
All contained FONTs are always transmitted most significant byte first.
If a
Font
error is generated for an item,
the previous items may have been drawn.
For fonts defined with 2-byte matrix indexing,
each STRING8 byte is interpreted as a byte2 value of a CHAR2B with a byte1
value of zero.
GC components: function, plane-mask, fill-style, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
GC mode-dependent components: foreground, background, tile, stipple,
tile-stipple-x-origin, tile-stipple-y-origin
PolyText16
PolyText16
drawable : DRAWABLE
gc : GCONTEXT
x , y : INT16
items : LISTofTEXTITEM16
where:
TEXTITEM16:
TEXTELT16 or FONT
TEXTELT16:
[delta: INT8
string: STRING16]
Errors:
Drawable ,
Font ,
GContext ,
Match
This request is similar to
PolyText8 ,
except 2-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than 2-byte matrix indexing,
the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (that is, byte1 of the
CHAR2B is taken as the most significant byte).
ImageText8
ImageText8
drawable : DRAWABLE
gc : GCONTEXT
x , y : INT16
string : STRING8
Errors:
Drawable ,
GContext ,
Match
The x and y coordinates are relative to the drawable's origin
and specify the baseline starting position (the initial character origin).
The effect is first to fill a destination rectangle with the background
pixel defined in gc and then to paint the text with the foreground pixel.
The upper-left corner of the filled rectangle is at:
[x, y - font-ascent]
the width is:
overall-width
and the height is:
font-ascent + font-descent
The overall-width, font-ascent, and font-descent are as
they would be returned by a
QueryTextExtents
call using gc and string.
The function and fill-style defined in gc are ignored for this request.
The effective function is
Copy ,
and the effective fill-style
Solid .
For fonts defined with 2-byte matrix indexing,
each STRING8 byte is interpreted as a byte2 value of a CHAR2B with a byte1
value of zero.
GC components: plane-mask, foreground, background, font,
subwindow-mode, clip-x-origin, clip-y-origin, clip-mask
ImageText16
ImageText16
drawable : DRAWABLE
gc : GCONTEXT
x , y : INT16
string : STRING16
Errors:
Drawable ,
GContext ,
Match
This request is similar to
ImageText8 ,
except 2-byte (or 16-bit) characters are used.
For fonts defined with linear indexing rather than 2-byte matrix indexing,
the server will interpret each CHAR2B as a 16-bit number that
has been transmitted most significant byte first (that is, byte1 of the
CHAR2B is taken as the most significant byte).
CreateColormap
CreateColormap Colormap
mid : COLORMAP
visual : VISUALID
window : WINDOW
alloc :
{ None ,
All }
Errors:
Alloc ,
IDChoice ,
Match ,
Value ,
Window
This request creates a colormap of the specified visual type for the screen
on which the window resides and associates the identifier mid with it.
The visual type must be one supported by the screen (or a
Match
error results).
The initial values of the colormap entries are undefined for classes
GrayScale ,
PseudoColor ,
and
DirectColor .
For
StaticGray ,
StaticColor ,
and
TrueColor ,
the entries will have defined values,
but those values are specific to the visual and are not defined
by the core protocol.
For
StaticGray ,
StaticColor ,
and
TrueColor ,
alloc must be specified as
None
(or a
Match
error results).
For the other classes, if alloc is
None ,
the colormap initially has no allocated entries,
and clients can allocate entries.
If alloc is
All ,
then the entire colormap is allocated writable.
The initial values of all allocated entries are undefined.
For
GrayScale
and
PseudoColor ,
the effect is as if an
AllocColorCells
request returned all pixel values from zero to N - 1,
where N is the colormap-entries value in the specified visual.
For
DirectColor ,
the effect is as if an
AllocColorPlanes
request returned a pixel value of zero and red-mask,
green-mask, and blue-mask values containing the same bits as the
corresponding masks in the specified visual.
However,
in all cases, none of these entries can be freed with
FreeColors .
FreeColormap
FreeColormap
cmap : COLORMAP
Errors:
Colormap
This request deletes the association between the resource ID and the colormap
and frees the colormap storage.
If the colormap is an installed map for a screen,
it is uninstalled (see
UninstallColormap
request).
If the colormap is defined as the colormap for a window (by means of
CreateWindow
or
ChangeWindowAttributes ),
the colormap for the window is changed to
None ,
and a
ColormapNotify
event is generated.
The protocol does not define the colors displayed for a window with a colormap of
None .
This request has no effect on a default colormap for a screen.
CopyColormapAndFree
CopyColormapAndFree
mid , src-cmap : COLORMAP
Errors:
Alloc ,
Colormap ,
IDChoice
This request creates a colormap of the same visual type
and for the same screen as src-cmap,
and it associates identifier mid with it.
It also moves all of the client's existing allocations from src-cmap
to the new colormap with their color values intact
and their read-only or writable characteristics intact,
and it frees those entries in src-cmap.
Color values in other entries in the new colormap are undefined.
If src-cmap was created by the client with alloc
All
(see
CreateColormap
request),
then the new colormap is also created with alloc
All ,
all color values for all entries are copied from src-cmap,
and then all entries in src-cmap are freed.
If src-cmap was not created by the client with alloc
All ,
then the allocations to be moved are all those pixels and planes that have
been allocated by the client using either
AllocColor ,
AllocNamedColor ,
AllocColorCells ,
or
AllocColorPlanes
and that have not been freed since they were allocated.
InstallColormap
InstallColormap
cmap : COLORMAP
Errors:
Colormap
This request makes this colormap an installed map for its screen.
All windows associated with this colormap immediately display with true colors.
As a side effect,
additional colormaps might be implicitly installed
or uninstalled by the server.
Which other colormaps get installed or uninstalled is server-dependent
except that the required list must remain installed.
If cmap is not already an installed map, a
ColormapNotify
event is generated on every window having cmap as an attribute.
In addition,
for every other colormap that is installed or uninstalled as a result
of the request, a
ColormapNotify
event is generated on every window having that colormap as an attribute.
At any time, there is a subset of the installed maps that are viewed as an
ordered list and are called the required list.
The length of the required list is at most M,
where M is the min-installed-maps specified for the screen in the
connection setup.
The required list is maintained as follows.
When a colormap is an explicit argument to
InstallColormap ,
it is added to the head of the list; the list is truncated at the
tail, if necessary, to keep the length of the list to at most M.
When a colormap is an explicit argument to
UninstallColormap
and it is in the required list, it is removed from the list.
A colormap is not added to the required list when it is installed implicitly
by the server, and the server cannot implicitly uninstall a colormap that is
in the required list.
Initially the default colormap for a screen is installed (but is not in
the required list).
UninstallColormap
UninstallColormap
cmap : COLORMAP
Errors:
Colormap
If cmap is on the required list for its screen (see
InstallColormap
request),
it is removed from the list.
As a side effect,
cmap might be uninstalled,
and additional colormaps might be implicitly installed or uninstalled.
Which colormaps get installed or uninstalled is server-dependent
except that the required list must remain installed.
If cmap becomes uninstalled, a
ColormapNotify
event is generated on every window having cmap as an attribute.
In addition,
for every other colormap that is installed or uninstalled as a result of
the request, a
ColormapNotify
event is generated on every window having that colormap as an attribute.
ListInstalledColormaps
ListInstalledColormaps
window : WINDOW
â–¶
cmaps: LISTofCOLORMAP
Errors:
Window
This request returns a list of the currently installed colormaps for the
screen of the specified window.
The order of colormaps is not significant,
and there is no explicit indication of the required list (see
InstallColormap
request).
AllocColor
AllocColor
cmap : COLORMAP
red , green , blue : CARD16
â–¶
pixel: CARD32
red, green, blue: CARD16
Errors:
Alloc ,
Colormap
This request allocates a read-only colormap entry corresponding to the closest
RGB values provided by the hardware.
It also returns the pixel and the RGB values actually used.
Multiple clients requesting the same effective RGB values can be assigned
the same read-only entry, allowing entries to be shared.
AllocNamedColor
AllocNamedColor
cmap : COLORMAP
name : STRING8
â–¶
pixel: CARD32
exact-red, exact-green, exact-blue: CARD16
visual-red, visual-green, visual-blue: CARD16
Errors:
Alloc ,
Colormap ,
Name
This request looks up the named color with respect to the screen associated
with the colormap.
Then, it does an
AllocColor
on cmap.
The name should use the ISO Latin-1 encoding,
and uppercase and lowercase do not matter.
The exact RGB values specify the true values for the color,
and the visual values specify the values actually used in the colormap.
AllocColorCells
AllocColorCells
cmap : COLORMAP
colors , planes : CARD16
contiguous : BOOL
â–¶
pixels, masks: LISTofCARD32
Errors:
Alloc ,
Colormap ,
Value
The number of colors must be positive,
and the number of planes must be nonnegative (or a
Value
error results).
If C colors and P planes are requested,
then C pixels and P masks are returned.
No mask will have any bits in common with any other mask
or with any of the pixels.
By ORing together masks and pixels,
C*%2 sup P% distinct pixels can be produced;
all of these are allocated writable by the request.
For
GrayScale
or
PseudoColor ,
each mask will have exactly one bit set to 1; for
DirectColor ,
each will have exactly three bits set to 1.
If contiguous is
True
and if all masks are ORed together,
a single contiguous set of bits will be formed for
GrayScale
or
PseudoColor ,
and three contiguous sets of bits (one within each pixel subfield) for
DirectColor .
The RGB values of the allocated entries are undefined.
AllocColorPlanes
AllocColorPlanes
cmap : COLORMAP
colors , reds , greens , blues : CARD16
contiguous : BOOL
â–¶
pixels: LISTofCARD32
red-mask, green-mask, blue-mask: CARD32
Errors:
Alloc ,
Colormap ,
Value
The number of colors must be positive,
and the reds, greens, and blues must be nonnegative (or a
Value
error results).
If C colors, R reds, G greens, and B blues are requested,
then C pixels are returned, and the masks have R, G, and B bits set,
respectively.
If contiguous is
True ,
then each mask will have a contiguous set of bits.
No mask will have any bits in common with any other mask
or with any of the pixels.
For
DirectColor ,
each mask will lie within the corresponding pixel subfield.
By ORing together subsets of masks with pixels,
C*%2 sup R+G+B% distinct pixels can be produced;
all of these are allocated writable by the request.
The initial RGB values of the allocated entries are undefined.
In the colormap,
there are only C*%2 sup R% independent red entries,
C*%2 sup G% independent green entries,
and C*%2 sup B% independent blue entries.
This is true even for
PseudoColor .
When the colormap entry for a pixel value is changed using
StoreColors
or
StoreNamedColor ,
the pixel is decomposed according to the masks and the
corresponding independent entries are updated.
FreeColors
FreeColors
cmap : COLORMAP
pixels : LISTofCARD32
plane-mask : CARD32
Errors:
Access ,
Colormap ,
Value
The plane-mask should not have any bits in common with any of the
pixels.
The set of all pixels is produced by ORing together subsets of
plane-mask with the pixels.
The request frees all of these pixels that
were allocated by the client (using
AllocColor ,
AllocNamedColor ,
AllocColorCells ,
and
AllocColorPlanes ).
Note that freeing an
individual pixel obtained from
AllocColorPlanes
may not actually allow it to be reused until all of its related pixels
are also freed.
Similarly, a read-only entry is not actually freed until it has been
freed by all clients, and if a client allocates the same read-only entry
multiple times, it must free the entry that many times before the
entry is actually freed.
All specified pixels that are allocated by the client in cmap are freed,
even if one or more pixels produce an error.
A
Value
error is generated if a specified pixel is not a valid index into cmap.
An
Access
error is generated if a specified pixel is not allocated by the
client (that is, is unallocated or is only allocated by another client)
or if the colormap was created with all entries writable (using an alloc
value of
All
in
CreateColormap ).
If more than one pixel is in error,
it is arbitrary as to which pixel is reported.
StoreColors
StoreColors
cmap : COLORMAP
items : LISTofCOLORITEM
where:
COLORITEM:
[pixel: CARD32
do-red, do-green, do-blue: BOOL
red, green, blue: CARD16]
Errors:
Access ,
Colormap ,
Value
This request changes the colormap entries of the specified pixels.
The do-red, do-green, and do-blue fields indicate which components
should actually be changed.
If the colormap is an installed map for its screen,
the changes are visible immediately.
All specified pixels that are allocated writable in cmap (by any client)
are changed, even if one or more pixels produce an error.
A
Value
error is generated if a specified pixel is not a valid index into cmap, and an
Access
error is generated if a specified pixel is unallocated or is allocated
read-only.
If more than one pixel is in error,
it is arbitrary as to which pixel is reported.
StoreNamedColor
StoreNamedColor
cmap : COLORMAP
pixel : CARD32
name : STRING8
do-red , do-green , do-blue : BOOL
Errors:
Access ,
Colormap ,
Name ,
Value
This request looks up the named color with respect to the screen associated
with cmap and then does a
StoreColors
in cmap.
The name should use the ISO Latin-1 encoding,
and uppercase and lowercase do not matter.
The
Access
and
Value
errors are the same as in
StoreColors .
QueryColors
QueryColors
cmap : COLORMAP
pixels : LISTofCARD32
â–¶
colors: LISTofRGB
where:
RGB: [red, green, blue: CARD16]
Errors:
Colormap ,
Value
This request returns the hardware-specific color values stored in cmap for
the specified pixels.
The values returned for an unallocated entry are undefined.
A
Value
error is generated if a pixel is not a valid index into cmap.
If more than one pixel is in error,
it is arbitrary as to which pixel is reported.
LookupColor
LookupColor
cmap : COLORMAP
name : STRING8
â–¶
exact-red, exact-green, exact-blue: CARD16
visual-red, visual-green, visual-blue: CARD16
Errors:
Colormap ,
Name
This request looks up the string name of a color with respect to the screen
associated with cmap and returns both the exact color values and
the closest values provided by the hardware with respect to the visual
type of cmap.
The name should use the ISO Latin-1 encoding,
and uppercase and lowercase do not matter.
CreateCursor
CreateCursor Cursor
cid : CURSOR
source : PIXMAP
mask : PIXMAP or
None
fore-red , fore-green , fore-blue : CARD16
back-red , back-green , back-blue : CARD16
x , y : CARD16
Errors:
Alloc ,
IDChoice ,
Match ,
Pixmap
This request creates a cursor and associates identifier cid with it.
The foreground and background RGB values must be specified,
even if the server only has a
StaticGray
or
GrayScale
screen.
The foreground is used for the bits set to 1 in the source,
and the background is used for the bits set to 0.
Both source and mask (if specified) must have depth one (or a
Match
error results), but they can have any root.
The mask pixmap defines the shape of the cursor.
That is,
the bits set to 1 in the mask define which source pixels will be displayed,
and where the mask has bits set to 0,
the corresponding bits of the source pixmap are ignored.
If no mask is given,
all pixels of the source are displayed.
The mask, if present, must be the same size as the source (or a
Match
error results).
The x and y coordinates define the hotspot relative to the source's origin
and must be a point within the source (or a
Match
error results).
The components of the cursor may be transformed arbitrarily to meet
display limitations.
The pixmaps can be freed immediately if no further explicit references
to them are to be made.
Subsequent drawing in the source or mask pixmap has an undefined effect
on the cursor.
The server might or might not make a copy of the pixmap.
CreateGlyphCursor
CreateGlyphCursor
cid : CURSOR
source-font : FONT
mask-font : FONT or
None
source-char , mask-char : CARD16
fore-red , fore-green , fore-blue : CARD16
back-red , back-green , back-blue : CARD16
Errors:
Alloc ,
Font ,
IDChoice ,
Value
This request is similar to
CreateCursor ,
except the source and mask bitmaps are obtained from the specified font glyphs.
The source-char must be a defined glyph in source-font,
and if mask-font is given, mask-char must be a defined glyph in mask-font
(or a
Value
error results).
The mask font and character are optional.
The origins of the source and mask (if it is defined) glyphs
are positioned coincidently and define the hotspot.
The source and mask need not have the same bounding box metrics,
and there is no restriction on the placement of the hotspot relative
to the bounding boxes.
If no mask is given,
all pixels of the source are displayed.
Note that source-char and mask-char are CARD16, not CHAR2B.
For 2-byte matrix fonts,
the 16-bit value should be formed with byte1 in the most significant byte
and byte2 in the least significant byte.
The components of the cursor may be transformed arbitrarily to meet
display limitations.
The fonts can be freed immediately if no further explicit references to
them are to be made.
FreeCursor
FreeCursor
cursor : CURSOR
Errors:
Cursor
This request deletes the association between the resource ID and the cursor.
The cursor storage will be freed when no other resource references it.
RecolorCursor
RecolorCursor
cursor : CURSOR
fore-red , fore-green , fore-blue : CARD16
back-red , back-green , back-blue : CARD16
Errors:
Cursor
This request changes the color of a cursor.
If the cursor is being displayed on a screen,
the change is visible immediately.
QueryBestSize
QueryBestSize
class :
{ Cursor ,
Tile ,
Stipple }
drawable : DRAWABLE
width , height : CARD16
â–¶
width, height: CARD16
Errors:
Drawable ,
Match ,
Value
This request returns the best size that is closest to the argument size.
For
Cursor ,
this is the largest size that can be fully displayed.
For
Tile ,
this is the size that can be tiled fastest.
For
Stipple ,
this is the size that can be stippled fastest.
For
Cursor ,
the drawable indicates the desired screen.
For
Tile
and
Stipple ,
the drawable indicates the screen and also possibly the window class and depth.
An
InputOnly
window cannot be used as the drawable for
Tile
or
Stipple
(or a
Match
error results).
QueryExtension
QueryExtension Extension querying
name : STRING8
â–¶
present: BOOL
major-opcode: CARD8
first-event: CARD8
first-error: CARD8
This request determines if the named extension is present.
If so,
the major opcode for the extension is returned, if it has one.
Otherwise, zero is returned.
Any minor opcode and the request formats are specific to the extension.
If the extension involves additional event types,
the base event type code is returned.
Otherwise, zero is returned.
The format of the events is specific to the extension.
If the extension involves additional error codes,
the base error code is returned.
Otherwise, zero is returned.
The format of additional data in the errors is specific to the extension.
The extension name should use the ISO Latin-1 encoding,
and uppercase and lowercase matter.
ListExtensions
ListExtensions Extension listing
â–¶
names: LISTofSTRING8
This request returns a list of all extensions supported by the server.
SetModifierMapping
SetModifierMapping Modifier keys
keycodes-per-modifier : CARD8
keycodes : LISTofKEYCODE
â–¶
status:
{ Success ,
Busy ,
Failed }
Errors:
Alloc ,
Value
This request specifies the keycodes (if any) of the keys to be used as
modifiers.
The number of keycodes in the list must be 8*keycodes-per-modifier (or a
Length
error results).
The keycodes are divided into eight sets,
with each set containing keycodes-per-modifier elements.
The sets are assigned to the modifiers
Shift ,
Lock ,
Control ,
Mod1 ,
Mod2 ,
Mod3 ,
Mod4 ,
and
Mod5 ,
in order.
Only nonzero keycode values are used within each set;
zero values are ignored.
All of the nonzero keycodes must be in the range specified by min-keycode
and max-keycode in the connection setup (or a
Value
error results).
The order of keycodes within a set does not matter.
If no nonzero values are specified in a set,
the use of the corresponding modifier is disabled,
and the modifier bit will always be zero.
Otherwise, the modifier bit will be one whenever
at least one of the keys in the corresponding set is in the down
position.
A server can impose restrictions on how modifiers can be changed (for example,
if certain keys do not generate up transitions in hardware,
if auto-repeat cannot be disabled on certain keys,
or if multiple keys per modifier are not supported).
The status reply is
Failed
if some such restriction is violated,
and none of the modifiers is changed.
If the new nonzero keycodes specified for a modifier differ from those
currently defined and any (current or new) keys for that modifier are
logically in the down state, then the status reply is
Busy ,
and none of the modifiers is changed.
This request generates a
MappingNotify
event on a
Success
status.
GetModifierMapping
GetModifierMapping Modifier keys
â–¶
keycodes-per-modifier: CARD8
keycodes: LISTofKEYCODE
This request returns the keycodes of the keys being used as modifiers.
The number of keycodes in the list is 8*keycodes-per-modifier.
The keycodes are divided into eight sets,
with each set containing keycodes-per-modifier elements.
The sets are assigned to the modifiers
Shift ,
Lock ,
Control ,
Mod1 ,
Mod2 ,
Mod3 ,
Mod4 ,
and
Mod5 ,
in order.
The keycodes-per-modifier value is chosen arbitrarily by the server;
zeroes are used to fill in unused elements within each set.
If only zero values are given in a set,
the use of the corresponding modifier has been disabled.
The order of keycodes within each set is chosen arbitrarily by the server.
ChangeKeyboardMapping
ChangeKeyboardMapping Keysym
first-keycode : KEYCODE
keysyms-per-keycode : CARD8
keysyms : LISTofKEYSYM
Errors:
Alloc ,
Value
This request defines the symbols for the specified number of keycodes,
starting with the specified keycode.
The symbols for keycodes outside this range remained unchanged.
The number of elements in the keysyms list must be a multiple of
keysyms-per-keycode (or a
Length
error results).
The first-keycode must be greater than or equal to min-keycode as returned
in the connection setup (or a
Value
error results) and:
first-keycode + (keysyms-length / keysyms-per-keycode) - 1
must be less than or equal to max-keycode as returned in the connection
setup (or a
Value
error results).
KEYSYM number N (counting from zero) for keycode K has an index
(counting from zero) of:
(K - first-keycode) * keysyms-per-keycode + N
in keysyms.
The keysyms-per-keycode can be chosen arbitrarily by the client
to be large enough to hold all desired symbols.
A special KEYSYM value of
NoSymbol
should be used to fill in unused elements for individual keycodes.
It is legal for
NoSymbol
to appear in nontrailing positions of the effective list for a keycode.
This request generates a
MappingNotify
event.
There is no requirement that the server interpret this mapping;
it is merely stored for reading and writing by clients
(see
GetKeyboardMapping
GetKeyboardMapping Keysym
first-keycode : KEYCODE
count : CARD8
â–¶
keysyms-per-keycode: CARD8
keysyms: LISTofKEYSYM
Errors:
Value
This request returns the symbols for the specified number of keycodes,
starting with the specified keycode.
The first-keycode must be greater than or equal to
min-keycode as returned in the connection setup (or a
Value
error results), and:
first-keycode + count - 1
must be less than or equal to max-keycode as returned in the connection setup
(or a
Value
error results).
The number of elements in the keysyms list is:
count * keysyms-per-keycode
and KEYSYM number N (counting from zero) for keycode K has an index
(counting from zero) of:
(K - first-keycode) * keysyms-per-keycode + N
in keysyms.
The keysyms-per-keycode value is chosen arbitrarily by the server
to be large enough to report all requested symbols.
A special KEYSYM value of
NoSymbol
is used to fill in unused elements for individual keycodes.
ChangeKeyboardControl
ChangeKeyboardControl
value-mask : BITMASK
value-list : LISTofVALUE
Errors:
Match ,
Value
This request controls various aspects of the keyboard.
The value-mask and value-list specify which controls are to be changed.
The possible values are:
Control
Type
key-click-percent
INT8
bell-percent
INT8
bell-pitch
INT16
bell-duration
INT16
led
CARD8
led-mode
{ On ,
Off }
key
KEYCODE
auto-repeat-mode
{ On ,
Off ,
Default }
The key-click-percent sets the volume for key clicks between 0 (off) and
100 (loud) inclusive, if possible.
Setting to -1 restores the default.
Other negative values generate a
Value
error.
The bell-percent sets the base volume for the bell between 0 (off) and 100
(loud) inclusive, if possible.
Setting to -1 restores the default.
Other negative values generate a
Value
error.
The bell-pitch sets the pitch (specified in Hz) of the bell, if possible.
Setting to -1 restores the default.
Other negative values generate a
Value
error.
The bell-duration sets the duration of the bell (specified in milliseconds),
if possible.
Setting to -1 restores the default.
Other negative values generate a
Value
error.
If both led-mode and led are specified,
then the state of that LED is changed, if possible.
If only led-mode is specified,
then the state of all LEDs are changed, if possible.
At most 32 LEDs, numbered from one, are supported.
No standard interpretation of LEDs is defined.
It is a
Match
error if an led is specified without an led-mode.
If both auto-repeat-mode and key are specified,
then the auto-repeat mode of that key is changed, if possible.
If only auto-repeat-mode is specified,
then the global auto-repeat mode for the entire keyboard is changed,
if possible, without affecting the per-key settings.
It is a
Match
error if a key is specified without an auto-repeat-mode.
Each key has an individual mode of whether or not it should auto-repeat
and a default setting for that mode.
In addition, there is a global mode of whether auto-repeat should be
enabled or not and a default setting for that mode.
When the global mode is
On ,
keys should obey their individual auto-repeat modes.
When the global mode is
Off ,
no keys should auto-repeat.
An auto-repeating key generates alternating
KeyPress
and
KeyRelease
events.
When a key is used as a modifier,
it is desirable for the key not to auto-repeat,
regardless of the auto-repeat setting for that key.
A bell generator connected with the console but not directly on the
keyboard is treated as if it were part of the keyboard.
The order in which controls are verified and altered is server-dependent.
If an error is generated,
a subset of the controls may have been altered.
GetKeyboardControl
GetKeyboardControl
â–¶
key-click-percent: CARD8
bell-percent: CARD8
bell-pitch: CARD16
bell-duration: CARD16
led-mask: CARD32
global-auto-repeat:
{ On ,
Off }
auto-repeats: LISTofCARD8
This request returns the current control values for the keyboard.
For the LEDs,
the least significant bit of led-mask corresponds to LED one,
and each one bit in led-mask indicates an LED that is lit.
The auto-repeats is a bit vector;
each one bit indicates that auto-repeat is enabled for the corresponding key.
The vector is represented as 32 bytes.
Byte N (from 0) contains the bits for keys 8N to 8N + 7,
with the least significant bit in the byte representing key 8N.
Bell
Bell
percent : INT8
Errors:
Value
This request rings the bell on the keyboard at a volume relative to the
base volume for the keyboard, if possible.
Percent can range from -100 to 100 inclusive (or a
Value
error results).
The volume at which the bell is rung when percent is nonnegative is:
base - [(base * percent) / 100] + percent
When percent is negative, it is:
base + [(base * percent) / 100]
SetPointerMapping
SetPointerMapping
map : LISTofCARD8
â–¶
status:
{ Success ,
Busy }
Errors:
Value
This request sets the mapping of the pointer.
Elements of the list are indexed starting from one.
The length of the list must be the same as
GetPointerMapping
would return (or a
Value
error results).
The index is a core button number,
and the element of the list defines the effective number.
A zero element disables a button.
Elements are not restricted in value by the number of physical buttons,
but no two elements can have the same nonzero value (or a
Value
error results).
If any of the buttons to be altered are logically in the down state,
the status reply is
Busy ,
and the mapping is not changed.
This request generates a
MappingNotify
event on a
Success
status.
GetPointerMapping
GetPointerMapping
â–¶
map: LISTofCARD8
This request returns the current mapping of the pointer.
Elements of the list are indexed starting from one.
The length of the list indicates the number of physical buttons.
The nominal mapping for a pointer is the identity mapping: map[i]=i.
ChangePointerControl
ChangePointerControl
do-acceleration , do-threshold : BOOL
acceleration-numerator , acceleration-denominator : INT16
threshold : INT16
Errors:
Value
This request defines how the pointer moves.
The acceleration is a multiplier for movement expressed as a fraction.
For example,
specifying 3/1 means the pointer moves three times as fast as normal.
The fraction can be rounded arbitrarily by the server.
Acceleration only takes effect if the pointer moves more than threshold
number of pixels at once and only applies to the amount beyond the threshold.
Setting a value to -1 restores the default.
Other negative values generate a
Value
error, as does a zero value for acceleration-denominator.
GetPointerControl
GetPointerControl
â–¶
acceleration-numerator, acceleration-denominator: CARD16
threshold: CARD16
This request returns the current acceleration and threshold for the pointer.
SetScreenSaver
SetScreenSaver
timeout , interval : INT16
prefer-blanking :
{ Yes ,
No ,
Default }
allow-exposures :
{ Yes ,
No ,
Default }
Errors:
Value
The timeout and interval are specified in seconds;
setting a value to -1 restores the default.
Other negative values generate a
Value
error.
If the timeout value is zero,
screen-saver is disabled (but an activated screen-saver is not deactivated).
If the timeout value is nonzero,
screen-saver is enabled.
Once screen-saver is enabled,
if no input from the keyboard or pointer is generated for timeout seconds,
screen-saver is activated.
For each screen,
if blanking is preferred and the hardware supports video blanking,
the screen will simply go blank.
Otherwise,
if either exposures are allowed or the screen can be regenerated without
sending exposure events to clients,
the screen is changed in a server-dependent fashion to avoid phosphor burn.
Otherwise,
the state of the screens does not change, and screen-saver is not activated.
At the next keyboard or pointer input or at the next
ForceScreenSaver
with mode
Reset ,
screen-saver is deactivated, and all screen states are restored.
If the server-dependent screen-saver method is amenable to periodic change,
interval serves as a hint about how long the change period should be,
with zero hinting that no periodic change should be made.
Examples of ways to change the screen include scrambling the color map
periodically, moving an icon image about the screen periodically, or
tiling the screen with the root window background tile,
randomly reorigined periodically.
GetScreenSaver
GetScreenSaver
â–¶
timeout, interval: CARD16
prefer-blanking:
{ Yes ,
No }
allow-exposures:
{ Yes ,
No }
This request returns the current screen-saver control values.
ForceScreenSaver
ForceScreenSaver
mode :
{ Activate ,
Reset }
Errors:
Value
If the mode is
Activate
and screen-saver is currently deactivated,
then screen-saver is activated (even if screen-saver has been disabled with
a timeout value of zero).
If the mode is
Reset
and screen-saver is currently enabled,
then screen-saver is deactivated (if it was activated),
and the activation timer is reset to its initial state
as if device input had just been received.
ChangeHosts
ChangeHosts
mode :
{ Insert ,
Delete }
host : HOST
Errors:
Access ,
Value
This request adds or removes the specified host from the access control list.
Access control list
The client must reside on the same host as the server and/or have been granted
permission by a server-dependent method to execute this request (or an
Access
error results).
An initial access control list can usually be specified,
typically by naming a file that the server reads at startup and reset.
The following address families are defined.
Types HOST Value
error.
For the Internet family,
the address must be four bytes long.
The address bytes are in standard IP order;
the server performs no automatic swapping on the address bytes.
The Internet family supports IP version 4 addresses only.
For the InternetV6 family, the address must be sixteen bytes
long. The address bytes are in standard IP order; the
server performs no automatic swapping on the address bytes.
The InternetV6 family supports IP version 6 addresses only.
For the DECnet family,
the server performs no automatic swapping on the address bytes.
A Phase IV address is two bytes long:
the first byte contains the least significant eight bits of the node number,
and the second byte contains the most significant two bits of the node number in
the least significant two bits of the byte and the area in the most
significant six bits of the byte.
For the Chaos family,
the address must be two bytes long.
The host number is always the first byte in the address,
and the subnet number is always the second byte.
The server performs no automatic swapping on the address bytes.
For the ServerInterpreted family, the address may be of any
length up to 65535 bytes. The address consists of two strings
of ASCII characters, separated by a byte with a value of 0.
The first string represents the type of address, and the second
string contains the address value. Address types and the syntax
for their associated values will be registered via the X.Org Registry.
Implementors who wish to add implementation specific types may register
a unique prefix with the X.Org registry to prevent namespace
collisions.
Use of a host address in the ChangeHosts request is deprecated. It is
only useful when a host has a unique, constant address, a requirement
that is increasingly unmet as sites adopt dynamically assigned
addresses, network address translation gateways, IPv6 link local
addresses, and various other technologies. It also assumes all users of
a host share equivalent access rights, and as such has never been
suitable for many multi-user machine environments. Instead, more
secure forms of authentication, such as those based on shared secrets
or public key encryption, are recommended.
ListHosts
ListHosts
â–¶
mode:
{ Enabled ,
Disabled }
hosts: LISTofHOST
This request returns the hosts on the access control list
and whether use of the list at connection setup is currently
enabled or disabled.
Each HOST is padded to a multiple of four bytes.
SetAccessControl
SetAccessControl
mode :
{ Enable ,
Disable }
Errors:
Access ,
Value
This request enables or disables the use of the access control list
at connection setups.
The client must reside on the same host as the server
and/or have been granted permission by a server-dependent method
to execute this request (or an
Access
error results).
SetCloseDownMode
SetCloseDownMode
mode :
{ Destroy ,
RetainPermanent ,
RetainTemporary }
Errors:
Value
This request defines what will happen to the client's resources
at connection close.
A connection starts in
Destroy
mode.
The meaning of the close-down mode is described
in
KillClient
KillClient
resource : CARD32 or
AllTemporary
Errors:
Value
If a valid resource is specified,
KillClient
forces a close-down of the client that created the resource.
If the client has already terminated in either
RetainPermanent
or
RetainTemporary
mode, all of the client's resources are destroyed
(see AllTemporary
is specified,
then the resources of all clients that have terminated in
RetainTemporary
are destroyed.
NoOperation
NoOperation
This request has no arguments and no results,
but the request length field
allows the request to be any multiple of four bytes in length.
The bytes contained in the request are uninterpreted by the server.
This request can be used in its minimum four byte form as padding where
necessary by client libraries that find it convenient to force requests
to begin on 64-bit boundaries.
Connection Close
Connection closing
At connection close,
all event selections made by the client are discarded.
If the client has the pointer actively grabbed, an
UngrabPointer
is performed.
If the client has the keyboard actively grabbed, an
UngrabKeyboard
is performed.
All passive grabs by the client are released.
If the client has the server grabbed, an
UngrabServer
is performed.
All selections (see
SetSelectionOwner
request)
owned by the client are disowned.
If close-down mode (see
SetCloseDownMode
request) is
RetainPermanent
or
RetainTemporary ,
then all resources (including colormap entries)
allocated by the client are marked as permanent or temporary,
respectively (but this does not prevent other clients from explicitly
destroying them).
If the mode is
Destroy ,
all of the client's resources are destroyed.
When a client's resources are destroyed,
for each window in the client's save-set,
if the window is an inferior of a window created by the client,
the save-set window is reparented to the closest ancestor such that
the save-set window is not an inferior of a window created by the client.
If the save-set window is unmapped, a
MapWindow
request is performed on it (even if it was not an inferior
of a window created by the client).
The reparenting leaves unchanged the absolute coordinates
(with respect to the root window) of the upper-left outer corner of the
save-set window.
After save-set processing,
all windows created by the client are destroyed.
For each nonwindow resource created by the client,
the appropriate
Free
request is performed.
All colors and colormap entries allocated by the client are freed.
A server goes through a cycle of having no connections and having some
connections.
At every transition to the state of having no connections
as a result of a connection closing with a
Destroy
close-down mode,
the server resets its state as if it had just been started.
This starts by destroying all lingering resources from clients
that have terminated in
RetainPermanent
or
RetainTemporary
mode.
It additionally includes deleting all but the predefined atom identifiers,
deleting all properties on all root windows, resetting all device maps and
attributes (key click, bell volume, acceleration), resetting the access
control list, restoring the standard root tiles and cursors, restoring
the default font path, and restoring the input focus to state
PointerRoot .
Note that closing a connection with a close-down mode of
RetainPermanent
or
RetainTemporary
will not cause the server to reset.
Events
Event GrabButton
with arguments:
Argument
Value
event-window
Event window
event-mask
Client's selected pointer events on the event window
pointer-mode and keyboard-mode
Asynchronous
owner-events
True
if the client has
OwnerGrabButton
selected on the event window, otherwise
False
confine-to
None
cursor
None
The grab is terminated automatically when the logical state of the pointer
has all buttons released.
UngrabPointer
and
ChangeActivePointerGrab
can both be used to modify the active grab.
Pointer Window events
EnterNotify EnterNotify
LeaveNotify LeaveNotify
root , event : WINDOW
child : WINDOW or
None
same-screen : BOOL
root-x , root-y , event-x , event-y : INT16
mode :
{ Normal ,
Grab ,
Ungrab }
detail :
{ Ancestor ,
Virtual ,
Inferior ,
Nonlinear ,
NonlinearVirtual }
focus : BOOL
state : SETofKEYBUTMASK
time : TIMESTAMP
If pointer motion or window hierarchy change causes the pointer to be
in a different window than before,
EnterNotify
and
LeaveNotify
events are generated instead of a
MotionNotify
event.
Only clients selecting
EnterWindow
on a window receive
EnterNotify
events, and only clients selecting
LeaveWindow
receive
LeaveNotify
events.
The pointer position reported in the event is always the final position,
not the initial position of the pointer.
The root is the root window for this position,
and root-x and root-y are the pointer coordinates relative to root's
origin at the time of the event.
Event is the event window.
If the event window is on the same screen as root,
then event-x and event-y are the pointer coordinates relative
to the event window's origin.
Otherwise, event-x and event-y are zero.
In a
LeaveNotify
event, if a child of the event window contains the initial position of the
pointer, then the child component is set to that child.
Otherwise, it is
None .
For an
EnterNotify
event, if a child of the event window contains the final pointer position,
then the child component is set to that child.
Otherwise, it is
None .
If the event window is the focus window or an inferior of the focus window,
then focus is
True .
Otherwise, focus is
False .
Normal pointer motion events have mode
Normal .
Pseudo-motion events when a grab activates have mode
Grab ,
and pseudo-motion events when a grab deactivates have mode
Ungrab .
All
EnterNotify
and
LeaveNotify
events caused by a hierarchy change are generated after any hierarchy event
caused by that change (that is,
UnmapNotify ,
MapNotify ,
ConfigureNotify ,
GravityNotify ,
CirculateNotify ),
but the ordering of
EnterNotify
and
LeaveNotify
events with respect to
FocusOut ,
VisibilityNotify ,
and
Expose
events is not constrained.
Normal events are generated as follows:
When the pointer moves from window A to window B and A is an inferior
of B:
LeaveNotify
with detail
Ancestor
is generated on A.
LeaveNotify
with detail
Virtual
is generated on each window between A and B exclusive (in that order).
EnterNotify
with detail
Inferior
is generated on B.
When the pointer moves from window A to window B and B is an inferior
of A:
LeaveNotify
with detail
Inferior
is generated on A.
EnterNotify
with detail
Virtual
is generated on each window between A and B exclusive (in that order).
EnterNotify
with detail
Ancestor
is generated on B.
When the pointer moves from window A to window B and window C is
their least common ancestor:
LeaveNotify
with detail
Nonlinear
is generated on A.
LeaveNotify
with detail
NonlinearVirtual
is generated on each window between A and C exclusive (in that order).
EnterNotify
with detail
NonlinearVirtual
is generated on each window between C and B exclusive (in that order).
EnterNotify
with detail
Nonlinear
is generated on B.
When the pointer moves from window A to window B on different screens:
LeaveNotify
with detail
Nonlinear
is generated on A.
If A is not a root window,
LeaveNotify
with detail
NonlinearVirtual
is generated on each window above A up to and including its root (in order).
If B is not a root window,
EnterNotify
with detail
NonlinearVirtual
is generated on each window from B's root down to but not including B
(in order).
EnterNotify
with detail
Nonlinear
is generated on B.
When a pointer grab activates (but after any initial warp into a confine-to
window and before generating any actual
ButtonPress
event that activates the grab),
G is the grab-window for the grab, and P is the window the pointer is in:
EnterNotify
and
LeaveNotify
events with mode
Grab
are generated (as for
Normal
above) as if the pointer were to suddenly warp from its current
position in P to some position in G.
However, the pointer does not warp,
and the pointer position is used as both the initial
and final positions for the events.
When a pointer grab deactivates (but after generating any actual
ButtonRelease
event that deactivates the grab), G is the grab-window for
the grab, and P is the window the pointer is in:
EnterNotify
and
LeaveNotify
events with mode
Ungrab
are generated (as for
Normal
above) as if the pointer were to suddenly warp from
some position in G to its current position in P.
However, the pointer does not warp,
and the current pointer position is used as both the initial
and final positions for the events.
KeymapNotify
KeymapNotify
KeymapNotify
keys : LISTofCARD8
The value is a bit vector as described in
QueryKeymap .
This event is reported to clients selecting
KeymapState
on a window and is generated immediately after every
EnterNotify
and
FocusIn .
Expose
Expose Event Exposure
Expose
window : WINDOW
x ,
y ,
width ,
height : CARD16
count : CARD16
This event is reported to clients selecting
Exposure
on the window.
It is generated when no valid contents are available for regions of a window,
and either the regions are visible, the regions are viewable
and the server is (perhaps newly) maintaining backing store on the window,
or the window is not viewable but the server is (perhaps newly) honoring
window's backing-store attribute of
Always
or
WhenMapped .
The regions are decomposed into an arbitrary set of rectangles,
and an
Expose
event is generated for each rectangle.
For a given action causing exposure events,
the set of events for a given window are guaranteed to be reported contiguously.
If count is zero,
then no more
Expose
events for this window follow.
If count is nonzero,
then at least that many more
Expose
events for this window follow (and possibly more).
The x and y coordinates are relative to window's origin
and specify the upper-left corner of a rectangle.
The width and height specify the extent of the rectangle.
Expose
events are never generated on
InputOnly
windows.
All
Expose
events caused by a hierarchy change are generated after any
hierarchy event caused by that change (for example,
UnmapNotify ,
MapNotify ,
ConfigureNotify ,
GravityNotify ,
CirculateNotify ).
All
Expose
events on a given window are generated after any
VisibilityNotify
event on that window,
but it is not required that all
Expose
events on all windows be generated after all
Visibilitity
events on all windows.
The ordering of
Expose
events with respect to
FocusOut ,
EnterNotify ,
and
LeaveNotify
events is not constrained.
GraphicsExposure
GraphicsExposure
GraphicsExposure
drawable : DRAWABLE
x , y , width , height : CARD16
count : CARD16
major-opcode : CARD8
minor-opcode : CARD16
This event is reported to a client using a graphics context
with graphics-exposures selected
and is generated when a destination region could not be computed due
to an obscured or out-of-bounds source region.
All of the regions exposed by a given graphics request
are guaranteed to be reported contiguously.
If count is zero then no more
GraphicsExposure
events for this window follow.
If count is nonzero,
then at least that many more
GraphicsExposure
events for this window follow (and possibly more).
The x and y coordinates are relative to drawable's origin
and specify the upper-left corner of a rectangle.
The width and height specify the extent of the rectangle.
The major and minor opcodes identify the graphics request used.
For the core protocol,
major-opcode is always
CopyArea
or
CopyPlane ,
and minor-opcode is always zero.
NoExposure
NoExposure
NoExposure
drawable : DRAWABLE
major-opcode : CARD8
minor-opcode: CARD16
This event is reported to a client using a graphics context
with graphics-exposures selected
and is generated when a graphics request
that might produce
GraphicsExposure
events does not produce any.
The drawable specifies the destination used for the graphics request.
The major and minor opcodes identify the graphics request used.
For the core protocol,
major-opcode is always
CopyArea
or
CopyPlane ,
and the minor-opcode is always zero.
VisibilityNotify
VisibilityNotify
VisibilityNotify
window : WINDOW
state :
{ Unobscured ,
PartiallyObscured ,
FullyObscured }
This event is reported to clients selecting
VisibilityChange
on the window.
In the following,
the state of the window is calculated ignoring all of the window's subwindows.
When a window changes state from partially or fully obscured or
not viewable to viewable and completely unobscured,
an event with
Unobscured
is generated.
When a window changes state from viewable and completely unobscured,
from viewable and completely obscured,
or from not viewable, to viewable and partially obscured,
an event with
PartiallyObscured
is generated.
When a window changes state from viewable and completely unobscured,
from viewable and partially obscured,
or from not viewable to viewable and fully obscured,
an event with
FullyObscured
is generated.
VisibilityNotify
events are never generated on
InputOnly
windows.
All
VisibilityNotify
events caused by a hierarchy change are generated after any hierarchy event
caused by that change (for example,
UnmapNotify ,
MapNotify ,
ConfigureNotify ,
GravityNotify ,
CirculateNotify ).
Any
VisibilityNotify
event on a given window is generated before any
Expose
events on that window,
but it is not required that all
VisibilityNotify
events on all windows be generated before all
Expose
events on all windows.
The ordering of
VisibilityNotify
events with respect to
FocusOut ,
EnterNotify ,
and
LeaveNotify
events is not constrained.
CreateNotify
CreateNotify
CreateNotify
parent , window : WINDOW
x , y : INT16
width , height , border-width : CARD16
override-redirect : BOOL
This event is reported to clients selecting
SubstructureNotify
on the parent
and is generated when the window is created.
The arguments are as in the
CreateWindow
request.
DestroyNotify
DestroyNotify
DestroyNotify
event , window : WINDOW
This event is reported to clients selecting
StructureNotify
on the window and to clients selecting
SubstructureNotify
on the parent.
It is generated when the window is destroyed.
The event is the window on which the event was generated,
and the window is the window that is destroyed.
The ordering of the
DestroyNotify
events is such that for any given window,
DestroyNotify
is generated on all inferiors of the window
before being generated on the window itself.
The ordering among siblings and across subhierarchies is not
otherwise constrained.
UnmapNotify
UnmapNotify
UnmapNotify
event , window : WINDOW
from-configure : BOOL
This event is reported to clients selecting
StructureNotify
on the window and to clients selecting
SubstructureNotify
on the parent.
It is generated when the window changes state from mapped to unmapped.
The event is the window on which the event was generated,
and the window is the window that is unmapped.
The from-configure flag is
True
if the event was generated as a result of the window's parent being resized
when the window itself had a win-gravity of
Unmap .
MapNotify
MapNotify Mapped window
MapNotify
event , window : WINDOW
override-redirect : BOOL
This event is reported to clients selecting
StructureNotify
on the window and to clients selecting
SubstructureNotify
on the parent.
It is generated when the window changes state from unmapped to mapped.
The event is the window on which the event was generated,
and the window is the window that is mapped.
The override-redirect flag is from the window's attribute.
MapRequest
MapRequest
MapRequest
parent , window : WINDOW
This event is reported to the client selecting
SubstructureRedirect
on the parent and is generated when a
MapWindow
request is issued on an unmapped window with an override-redirect attribute of
False .
ReparentNotify
ReparentNotify
ReparentNotify
event , window , parent : WINDOW
x , y : INT16
override-redirect : BOOL
This event is reported to clients selecting
SubstructureNotify
on either the old or the new parent and to clients selecting
StructureNotify
on the window.
It is generated when the window is reparented.
The event is the window on which the event was generated.
The window is the window that has been rerooted.
The parent specifies the new parent.
The x and y coordinates are relative to the new parent's origin
and specify the position of the upper-left outer corner of the window.
The override-redirect flag is from the window's attribute.
GravityNotify
GravityNotify
GravityNotify
event , window : WINDOW
x , y : INT16
This event is reported to clients selecting
SubstructureNotify
on the parent and to clients selecting
StructureNotify
on the window.
It is generated when a window is moved because of a change in size
of the parent.
The event is the window on which the event was generated,
and the window is the window that is moved.
The x and y coordinates are relative to the new parent's origin
and specify the position of the upper-left outer corner of the window.
ResizeRequest
ResizeRequest
ResizeRequest
window : WINDOW
width , height : CARD16
This event is reported to the client selecting
ResizeRedirect
on the window and is generated when a
ConfigureWindow
request by some other client on the window attempts to change the size
of the window.
The width and height are the requested inside size, not including the border.
CirculateNotify
CirculateNotify
CirculateNotify
event , window : WINDOW
place :
{ Top ,
Bottom }
This event is reported to clients selecting
StructureNotify
on the window and to clients selecting
SubstructureNotify
on the parent.
It is generated when the window is actually restacked from a
CirculateWindow
request.
The event is the window on which the event was generated,
and the window is the window that is restacked.
If place is
Top ,
the window is now on top of all siblings.
Otherwise, it is below all siblings.
CirculateRequest
CirculateRequest
CirculateRequest
parent , window : WINDOW
place :
{ Top ,
Bottom }
This event is reported to the client selecting
SubstructureRedirect
on the parent and is generated when a
CirculateWindow
request is issued on the parent and a window actually needs to be restacked.
The window specifies the window to be restacked,
and the place specifies what the new position in the stacking order should be.
PropertyNotify
PropertyNotify
PropertyNotify
window : WINDOW
atom : ATOM
state :
{ NewValue ,
Deleted }
time : TIMESTAMP
This event is reported to clients selecting
PropertyChange
on the window and is generated with state
NewValue
when a property of the window is changed using
ChangeProperty
or
RotateProperties ,
even when adding zero-length data using
ChangeProperty
and when replacing all or part of a property with identical data using
ChangeProperty
or
RotateProperties .
It is generated with state
Deleted
when a property of the
window is deleted using request
DeleteProperty
or
GetProperty .
The timestamp indicates the server time when the property was changed.
SelectionClear
SelectionClear
SelectionClear
owner : WINDOW
selection : ATOM
time : TIMESTAMP
This event is reported to the current owner of a selection
and is generated when a new owner is being defined by means of
SetSelectionOwner .
The timestamp is the last-change time recorded for the selection.
The owner argument is the window that was specified by the current owner in its
SetSelectionOwner
request.
SelectionRequest
SelectionRequest
SelectionRequest
owner : WINDOW
selection : ATOM
target : ATOM
property : ATOM or
None
requestor : WINDOW
time : TIMESTAMP or
CurrentTime
This event is reported to the owner of a selection
and is generated when a client issues a
ConvertSelection
request.
The owner argument is the window that was specified in the
SetSelectionOwner
request.
The remaining arguments are as in the
ConvertSelection
request.
The owner should convert the selection based on the specified target type
and send a
SelectionNotify
back to the requestor.
A complete specification for using selections is given in the X.Org
standard Inter-Client Communication Conventions Manual .
SelectionNotify
SelectionNotify
SelectionNotify
requestor : WINDOW
selection , target : ATOM
property : ATOM or
None
time : TIMESTAMP or
CurrentTime
This event is generated by the server in response to a
ConvertSelection
request when there is no owner for the selection.
When there is an owner,
it should be generated by the owner using
SendEvent .
The owner of a selection should send this event to a requestor either
when a selection has been converted and stored as a property
or when a selection conversion could not be performed (indicated with property
None ).
ColormapNotify
ColormapNotify
ColormapNotify
window : WINDOW
colormap : COLORMAP or
None
new : BOOL
state :
{ Installed ,
Uninstalled }
This event is reported to clients selecting
ColormapChange
on the window.
It is generated with value
True
for new when the colormap attribute of the window is changed
and is generated with value
False
for new when the colormap of a window is installed or uninstalled.
In either case,
the state indicates whether the colormap is currently installed.
MappingNotify
MappingNotify
MappingNotify
request :
{ Modifier ,
Keyboard ,
Pointer }
first-keycode , count : CARD8
This event is sent to all clients.
There is no mechanism to express disinterest in this event.
The detail indicates the kind of change that occurred:
Modifiers
for a successful
SetModifierMapping ,
Keyboard
for a successful
ChangeKeyboardMapping ,
and
Pointer
for a successful
SetPointerMapping .
If the detail is
Keyboard ,
then first-keycode and count indicate the range of altered keycodes.
ClientMessage
ClientMessage
ClientMessage
window : WINDOW
type : ATOM
format : {8, 16, 32}
data : LISTofINT8 or LISTofINT16 or LISTofINT32
This event is only generated by clients using
SendEvent .
The type specifies how the data is to be interpreted by the receiving client;
the server places no interpretation on the type or the data.
The format specifies whether the data should be viewed as a list of 8-bit,
16-bit, or 32-bit quantities, so that the server can correctly
byte-swap, as necessary.
The data always consists of either 20 8-bit values or 10 16-bit values
or 5 32-bit values, although particular message types might not make use
of all of these values.
Flow Control and Concurrency
Whenever the server is writing to a given connection,
it is permissible for the server to stop reading from that connection
(but if the writing would block, it must continue to service other connections).
The server is not required to buffer more than a single request per connection
at one time.
For a given connection to the server,
a client can block while reading from the connection
but should undertake to read (events and errors) when writing would block.
Failure on the part of a client to obey this rule could result
in a deadlocked connection,
although deadlock is probably unlikely unless either
the transport layer has very little buffering or the client attempts to
send large numbers of requests without ever reading replies or checking for
errors and events.
Whether or not a server is implemented with internal concurrency,
the overall effect must be as if individual requests are executed to completion
in some serial order,
and requests from a given connection must be executed in delivery order
(that is, the total execution order is a shuffle of the individual streams).
The execution of a request includes validating all arguments,
collecting all data for any reply,
and generating and queueing all required events.
However,
it does not include the actual transmission of the reply and the events.
In addition, the effect of any other cause that can generate multiple events
(for example, activation of a grab or pointer motion) must effectively generate
and queue all required events indivisibly with respect to all other causes
and requests.
For a request from a given client,
any events destined for that client that are caused by executing the request
must be sent to the client before any reply or error is sent.
xorgproto-2023.2/specs/xproto/Makefile.am 0000644 0001750 0001750 00000000670 14443010026 015267 0000000 0000000 if ENABLE_SPECS
# Main DocBook/XML files (DOCTYPE book)
docbook = x11protocol.xml
# Included chapters, appendix, images
chapters = \
encoding.xml \
glossary.xml \
keysyms.xml \
sect1-9.xml
# The location where the DocBook/XML files and their generated formats are installed
shelfdir = $(datarootdir)/doc/xproto
# Generate DocBook/XML output formats with or without stylesheets
include $(top_srcdir)/docbook.am
endif ENABLE_SPECS
xorgproto-2023.2/specs/xproto/Makefile.in 0000644 0001750 0001750 00000056040 14443010031 015276 0000000 0000000 # Makefile.in generated by automake 1.16.5 from Makefile.am.
# @configure_input@
# Copyright (C) 1994-2021 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
@SET_MAKE@
#
# Generate output formats for a single DocBook/XML with/without chapters
#
# Variables set by the calling Makefile:
# shelfdir: the location where the docs/specs are installed. Typically $(docdir)
# docbook: the main DocBook/XML file, no chapters, appendix or image files
# chapters: all files pulled in by an XInclude statement and images.
#
#
# This makefile is intended for Users Documentation and Functional Specifications.
# Do not use for Developer Documentation which is not installed and does not require olink.
# Refer to http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html#id2584393
# for an explanation on documents classification.
#
VPATH = @srcdir@
am__is_gnu_make = { \
if test -z '$(MAKELEVEL)'; then \
false; \
elif test -n '$(MAKE_HOST)'; then \
true; \
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
else \
false; \
fi; \
}
am__make_running_with_option = \
case $${target_option-} in \
?) ;; \
*) echo "am__make_running_with_option: internal error: invalid" \
"target option '$${target_option-}' specified" >&2; \
exit 1;; \
esac; \
has_opt=no; \
sane_makeflags=$$MAKEFLAGS; \
if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
else \
case $$MAKEFLAGS in \
*\\[\ \ ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
esac; \
fi; \
skip_next=no; \
strip_trailopt () \
{ \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
}; \
for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
*=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
-*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
-*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
-*l?*) strip_trailopt 'l';; \
-[dEDm]) skip_next=yes;; \
-[JT]) skip_next=yes;; \
esac; \
case $$flg in \
*$$target_option*) has_opt=yes; break;; \
esac; \
done; \
test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_1 = $(docbook:.xml=.html)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@am__append_2 = $(docbook:.xml=.txt)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_3 = $(docbook:.xml=.pdf) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(docbook:.xml=.ps)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@am__append_4 = $(docbook:.xml=.html.db) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(docbook:.xml=.pdf.db)
subdir = specs/xproto
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(am__dist_shelf_DATA_DIST) \
$(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
AM_V_P = $(am__v_P_@AM_V@)
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
am__v_P_0 = false
am__v_P_1 = :
AM_V_GEN = $(am__v_GEN_@AM_V@)
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
am__v_GEN_0 = @echo " GEN " $@;
am__v_GEN_1 =
AM_V_at = $(am__v_at_@AM_V@)
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
am__v_at_0 = @
am__v_at_1 =
SOURCES =
DIST_SOURCES =
am__can_run_installinfo = \
case $$AM_UPDATE_INFO_DIR in \
n|no|NO) false;; \
*) (install-info --version) >/dev/null 2>&1;; \
esac
am__dist_shelf_DATA_DIST = x11protocol.xml encoding.xml glossary.xml \
keysyms.xml sect1-9.xml
am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
am__vpath_adj = case $$p in \
$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
*) f=$$p;; \
esac;
am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
am__install_max = 40
am__nobase_strip_setup = \
srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
am__nobase_strip = \
for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
am__nobase_list = $(am__nobase_strip_setup); \
for p in $$list; do echo "$$p $$p"; done | \
sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
$(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
if (++n[$$2] == $(am__install_max)) \
{ print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
END { for (dir in files) print dir, files[dir] }'
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
am__uninstall_files_from_dir = { \
test -z "$$files" \
|| { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
|| { echo " ( cd '$$dir' && rm -f" $$files ")"; \
$(am__cd) "$$dir" && rm -f $$files; }; \
}
am__installdirs = "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"
DATA = $(dist_shelf_DATA) $(shelf_DATA)
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
am__DIST_COMMON = $(srcdir)/Makefile.in $(top_srcdir)/docbook.am
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
ADMIN_MAN_DIR = @ADMIN_MAN_DIR@
ADMIN_MAN_SUFFIX = @ADMIN_MAN_SUFFIX@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
APP_MAN_DIR = @APP_MAN_DIR@
APP_MAN_SUFFIX = @APP_MAN_SUFFIX@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BASE_CFLAGS = @BASE_CFLAGS@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CHANGELOG_CMD = @CHANGELOG_CMD@
CPPFLAGS = @CPPFLAGS@
CSCOPE = @CSCOPE@
CTAGS = @CTAGS@
CWARNFLAGS = @CWARNFLAGS@
CYGPATH_W = @CYGPATH_W@
DEFS = @DEFS@
DEPDIR = @DEPDIR@
DRIVER_MAN_DIR = @DRIVER_MAN_DIR@
DRIVER_MAN_SUFFIX = @DRIVER_MAN_SUFFIX@
ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
ETAGS = @ETAGS@
EXEEXT = @EXEEXT@
FILE_MAN_DIR = @FILE_MAN_DIR@
FILE_MAN_SUFFIX = @FILE_MAN_SUFFIX@
FOP = @FOP@
INSTALL = @INSTALL@
INSTALL_CMD = @INSTALL_CMD@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIB_MAN_DIR = @LIB_MAN_DIR@
LIB_MAN_SUFFIX = @LIB_MAN_SUFFIX@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAN_SUBSTS = @MAN_SUBSTS@
MISC_MAN_DIR = @MISC_MAN_DIR@
MISC_MAN_SUFFIX = @MISC_MAN_SUFFIX@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
PKG_CONFIG = @PKG_CONFIG@
PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
PYTHON = @PYTHON@
PYTHON_EXEC_PREFIX = @PYTHON_EXEC_PREFIX@
PYTHON_PLATFORM = @PYTHON_PLATFORM@
PYTHON_PREFIX = @PYTHON_PREFIX@
PYTHON_VERSION = @PYTHON_VERSION@
SED = @SED@
SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
STRICT_CFLAGS = @STRICT_CFLAGS@
STRIP = @STRIP@
STYLESHEET_SRCDIR = @STYLESHEET_SRCDIR@
USE_FDS_BITS = @USE_FDS_BITS@
VERSION = @VERSION@
XMLTO = @XMLTO@
XORG_MAN_PAGE = @XORG_MAN_PAGE@
XORG_SGML_PATH = @XORG_SGML_PATH@
XSLTPROC = @XSLTPROC@
XSL_STYLESHEET = @XSL_STYLESHEET@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build = @build@
build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
pkgpyexecdir = @pkgpyexecdir@
pkgpythondir = @pkgpythondir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
pyexecdir = @pyexecdir@
pythondir = @pythondir@
runstatedir = @runstatedir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
# Main DocBook/XML files (DOCTYPE book)
@ENABLE_SPECS_TRUE@docbook = x11protocol.xml
# Included chapters, appendix, images
@ENABLE_SPECS_TRUE@chapters = \
@ENABLE_SPECS_TRUE@ encoding.xml \
@ENABLE_SPECS_TRUE@ glossary.xml \
@ENABLE_SPECS_TRUE@ keysyms.xml \
@ENABLE_SPECS_TRUE@ sect1-9.xml
# The location where the DocBook/XML files and their generated formats are installed
@ENABLE_SPECS_TRUE@shelfdir = $(datarootdir)/doc/xproto
# DocBook/XML generated output formats to be installed
@ENABLE_SPECS_TRUE@shelf_DATA = $(am__append_1) $(am__append_2) \
@ENABLE_SPECS_TRUE@ $(am__append_3) $(am__append_4)
# DocBook/XML file with chapters, appendix and images it includes
@ENABLE_SPECS_TRUE@dist_shelf_DATA = $(docbook) $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_OLINK_FLAGS)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_PDF_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_IMAGEPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_PDF_OLINK_FLAGS)
# Generate documents cross-reference target databases
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam targets.filename "$@" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam collect.xref.targets "only" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam olink.base.uri "$(@:.db=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_PDF_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@CLEANFILES = $(shelf_DATA)
all: all-am
.SUFFIXES:
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/docbook.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign specs/xproto/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign specs/xproto/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
*config.status*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
*) \
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \
esac;
$(top_srcdir)/docbook.am $(am__empty):
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(top_srcdir)/configure: $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
install-dist_shelfDATA: $(dist_shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-dist_shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
install-shelfDATA: $(shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
tags TAGS:
ctags CTAGS:
cscope cscopelist:
distdir: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) distdir-am
distdir-am: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
all-am: Makefile $(DATA)
installdirs:
for dir in "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"; do \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-am
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
mostlyclean-generic:
clean-generic:
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
clean: clean-am
clean-am: clean-generic mostlyclean-am
distclean: distclean-am
-rm -f Makefile
distclean-am: clean-am distclean-generic
dvi: dvi-am
dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am: install-dist_shelfDATA install-shelfDATA
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
-rm -f Makefile
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-generic
pdf: pdf-am
pdf-am:
ps: ps-am
ps-am:
uninstall-am: uninstall-dist_shelfDATA uninstall-shelfDATA
.MAKE: install-am install-strip
.PHONY: all all-am check check-am clean clean-generic cscopelist-am \
ctags-am distclean distclean-generic distdir dvi dvi-am html \
html-am info info-am install install-am install-data \
install-data-am install-dist_shelfDATA install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-shelfDATA install-strip installcheck installcheck-am \
installdirs maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-generic pdf pdf-am ps ps-am tags-am \
uninstall uninstall-am uninstall-dist_shelfDATA \
uninstall-shelfDATA
.PRECIOUS: Makefile
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.html: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@%.txt: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.pdf: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.ps: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.html.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_HTML_FLAGS) $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.pdf.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_PDF_FLAGS) $<
# Generate DocBook/XML output formats with or without stylesheets
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
xorgproto-2023.2/specs/xproto/keysyms.xml 0000644 0001750 0001750 00000445253 14443010026 015473 0000000 0000000
KEYSYM Encoding
Types KEYSYM Keysym
KEYSYM values are 32-bit integers that encode the symbols on the
keycaps of a keyboard. The three most significant bits are always
zero, which leaves a 29-bit number space. For convenience, KEYSYM
values can be viewed as split into four bytes:
Byte 1 is the most significant eight bits (three zero bits and
the most-significant five bits of the 29-bit effective value)
Byte 2 is the next most-significant eight bits
Byte 3 is the next most-significant eight bits
Byte 4 is the least-significant eight bits
There are six categories of KEYSYM values.
Special KEYSYMs
There are two special values:
NoSymbol
and
VoidSymbol .
They are used to indicate the absence of symbols (see
Byte 1
Byte 2
Byte 3
Byte 4
Hex. value
Name
0
0
0
0
#x00000000
NoSymbol
0
255
255
255
#x00FFFFFF
VoidSymbol
Latin-1 KEYSYMs
The Latin-1 KEYSYMs occupy the range #x0020 to #x007E and #x00A0 to
#00FF and represent the ISO 10646 / Unicode characters U+0020 to
U+007E and U+00A0 to U+00FF, respectively.
Unicode KEYSYMs
Keysym Unicode
These occupy the range #x01000100 to #x0110FFFF and represent the ISO
10646 / Unicode characters U+0100 to U+10FFFF, respectively. The
numeric value of a Unicode KEYSYM is the Unicode position of the
corresponding character plus #x01000000. In the interest of backwards
compatibility, clients should be able to process both the Unicode
KEYSYM and the Legacy KEYSYM for those characters where both exist.
Dead keys, which place an accent on the next character entered, shall
be encoded as Function KEYSYMs, and not as the Unicode KEYSYM
corresponding to an equivalent combining character. Where a keycap
indicates a specific function with a graphical symbol that is also
available in Unicode (e.g., an upwards arrow for the cursor up
function), the appropriate Function KEYSYM should be used, and not
the Unicode KEYSYM corresponding to the depicted symbol.
Function KEYSYMs
These represent keycap symbols that do not directly represent elements
of a coded character set. Instead, they typically identify a software
function, mode, or operation (e.g., cursor up, caps lock, insert) that
can be activated using a dedicated key. Function KEYSYMs have zero
values for bytes 1 and 2. Byte 3 distinguishes between several 8-bit
sets within which byte 4 identifies the individual function key.
Byte 3
Byte 4
255
Keyboard
254
Keyboard (XKB) Extension
253
3270
Within a national market, keyboards tend to be comparatively standard
with respect to the character keys, but they can differ significantly
on the miscellaneous function keys. Some have function keys left over
from early timesharing days, others were designed for a specific
application, such as text processing, web browsing, or accessing
audiovisual data. The symbols on the keycaps can differ significantly
between manufacturers and national markets, even where they denote the
same software function (e.g., Ctrl in the U.S. versus Strg in Germany)
There are two ways of thinking about how to define KEYSYMs for such a
world:
The Engraving approach
The Common approach
The Engraving approach is to create a KEYSYM for every unique key
engraving. This is effectively taking the union of all key engravings
on all keyboards. For example, some keyboards label function keys
across the top as F1 through Fn, and others label them as PF1 through
PFn. These would be different keys under the Engraving
approach. Likewise, Lock would differ from Shift Lock, which is
different from the up-arrow symbol that has the effect of changing
lowercase to uppercase. There are lots of other aliases such as Del,
DEL, Delete, Remove, and so forth. The Engraving approach makes it
easy to decide if a new entry should be added to the KEYSYM set: if it
does not exactly match an existing one, then a new one is created.
The Common approach tries to capture all of the keys present on an
interesting number of keyboards, folding likely aliases into the same
KEYSYM. For example, Del, DEL, and Delete are all merged into a single
KEYSYM. Vendors can augment the KEYSYM set (using the vendor-specific
encoding space) to include all of their unique keys that were not
included in the standard set. Each vendor decides which of its keys
map into the standard KEYSYMs, which presumably can be overridden by a
user. It is more difficult to implement this approach, because
judgment is required about when a sufficient set of keyboards
implements an engraving to justify making it a KEYSYM in the standard
set and about which engravings should be merged into a single
KEYSYM.
Although neither scheme is perfect or elegant, the Common approach has
been selected because it makes it easier to write a portable
application. Having the Delete functionality merged into a single
KEYSYM allows an application to implement a deletion function and
expect reasonable bindings on a wide set of workstations. Under the
Common approach, application writers are still free to look for and
interpret vendor-specific KEYSYMs, but because they are in the
extended set, the application developer is more conscious that they
are writing the application in a nonportable fashion.
The Keyboard set is a miscellaneous collection of commonly occurring
keys on keyboards. Within this set, the numeric keypad symbols are
generally duplicates of symbols found on keys on the main part of the
keyboard, but they are distinguished here because they often have a
distinguishable semantics associated with them.
KEYSYM value
Name
Set
#xFF08
BACKSPACE, BACK SPACE, BACK CHAR
Keyboard
#xFF09
TAB
Keyboard
#xFF0A
LINEFEED, LF
Keyboard
#xFF0B
CLEAR
Keyboard
#xFF0D
RETURN, ENTER
Keyboard
#xFF13
PAUSE, HOLD
Keyboard
#xFF14
SCROLL LOCK
Keyboard
#xFF15
SYS REQ, SYSTEM REQUEST
Keyboard
#xFF1B
ESCAPE
Keyboard
#xFF20
MULTI-KEY CHARACTER PREFACE
Keyboard
#xFF21
KANJI, KANJI CONVERT
Keyboard
#xFF22
MUHENKAN
Keyboard
#xFF23
HENKAN MODE
Keyboard
#xFF24
ROMAJI
Keyboard
#xFF25
HIRAGANA
Keyboard
#xFF26
KATAKANA
Keyboard
#xFF27
HIRAGANA/KATAKANA TOGGLE
Keyboard
#xFF28
ZENKAKU
Keyboard
#xFF29
HANKAKU
Keyboard
#xFF2A
ZENKAKU/HANKAKU TOGGLE
Keyboard
#xFF2B
TOUROKU
Keyboard
#xFF2C
MASSYO
Keyboard
#xFF2D
KANA LOCK
Keyboard
#xFF2E
KANA SHIFT
Keyboard
#xFF2F
EISU SHIFT
Keyboard
#xFF30
EISU TOGGLE
Keyboard
#xFF31
HANGUL START/STOP (TOGGLE)
Keyboard
#xFF32
HANGUL START
Keyboard
#xFF33
HANGUL END, ENGLISH START
Keyboard
#xFF34
START HANGUL/HANJA CONVERSION
Keyboard
#xFF35
HANGUL JAMO MODE
Keyboard
#xFF36
HANGUL ROMAJA MODE
Keyboard
#xFF37
HANGUL CODE INPUT
Keyboard
#xFF38
HANGUL JEONJA MODE
Keyboard
#xFF39
HANGUL BANJA MODE
Keyboard
#xFF3A
HANGUL PREHANJA CONVERSION
Keyboard
#xFF3B
HANGUL POSTHANJA CONVERSION
Keyboard
#xFF3C
HANGUL SINGLE CANDIDATE
Keyboard
#xFF3D
HANGUL MULTIPLE CANDIDATE
Keyboard
#xFF3E
HANGUL PREVIOUS CANDIDATE
Keyboard
#xFF3F
HANGUL SPECIAL SYMBOLS
Keyboard
#xFF50
HOME
Keyboard
#xFF51
LEFT, MOVE LEFT, LEFT ARROW
Keyboard
#xFF52
UP, MOVE UP, UP ARROW
Keyboard
#xFF53
RIGHT, MOVE RIGHT, RIGHT ARROW
Keyboard
#xFF54
DOWN, MOVE DOWN, DOWN ARROW
Keyboard
#xFF55
PRIOR, PREVIOUS, PAGE UP
Keyboard
#xFF56
NEXT, PAGE DOWN
Keyboard
#xFF57
END, EOL
Keyboard
#xFF58
BEGIN, BOL
Keyboard
#xFF60
SELECT, MARK
Keyboard
#xFF61
PRINT
Keyboard
#xFF62
EXECUTE, RUN, DO
Keyboard
#xFF63
INSERT, INSERT HERE
Keyboard
#xFF65
UNDO, OOPS
Keyboard
#xFF66
REDO, AGAIN
Keyboard
#xFF67
MENU
Keyboard
#xFF68
FIND, SEARCH
Keyboard
#xFF69
CANCEL, STOP, ABORT, EXIT
Keyboard
#xFF6A
HELP
Keyboard
#xFF6B
BREAK
Keyboard
#xFF7E
MODE SWITCH, SCRIPT SWITCH, CHARACTER SET SWITCH
Keyboard
#xFF7F
NUM LOCK
Keyboard
#xFF80
KEYPAD SPACE
Keyboard
#xFF89
KEYPAD TAB
Keyboard
#xFF8D
KEYPAD ENTER
Keyboard
#xFF91
KEYPAD F1, PF1, A
Keyboard
#xFF92
KEYPAD F2, PF2, B
Keyboard
#xFF93
KEYPAD F3, PF3, C
Keyboard
#xFF94
KEYPAD F4, PF4, D
Keyboard
#xFF95
KEYPAD HOME
Keyboard
#xFF96
KEYPAD LEFT
Keyboard
#xFF97
KEYPAD UP
Keyboard
#xFF98
KEYPAD RIGHT
Keyboard
#xFF99
KEYPAD DOWN
Keyboard
#xFF9A
KEYPAD PRIOR, PAGE UP
Keyboard
#xFF9B
KEYPAD NEXT, PAGE DOWN
Keyboard
#xFF9C
KEYPAD END
Keyboard
#xFF9D
KEYPAD BEGIN
Keyboard
#xFF9E
KEYPAD INSERT
Keyboard
#xFF9F
KEYPAD DELETE
Keyboard
#xFFAA
KEYPAD MULTIPLICATION SIGN, ASTERISK
Keyboard
#xFFAB
KEYPAD PLUS SIGN
Keyboard
#xFFAC
KEYPAD SEPARATOR, COMMA
Keyboard
#xFFAD
KEYPAD MINUS SIGN, HYPHEN
Keyboard
#xFFAE
KEYPAD DECIMAL POINT, FULL STOP
Keyboard
#xFFAF
KEYPAD DIVISION SIGN, SOLIDUS
Keyboard
#xFFB0
KEYPAD DIGIT ZERO
Keyboard
#xFFB1
KEYPAD DIGIT ONE
Keyboard
#xFFB2
KEYPAD DIGIT TWO
Keyboard
#xFFB3
KEYPAD DIGIT THREE
Keyboard
#xFFB4
KEYPAD DIGIT FOUR
Keyboard
#xFFB5
KEYPAD DIGIT FIVE
Keyboard
#xFFB6
KEYPAD DIGIT SIX
Keyboard
#xFFB7
KEYPAD DIGIT SEVEN
Keyboard
#xFFB8
KEYPAD DIGIT EIGHT
Keyboard
#xFFB9
KEYPAD DIGIT NINE
Keyboard
#xFFBD
KEYPAD EQUALS SIGN
Keyboard
#xFFBE
F1
Keyboard
#xFFBF
F2
Keyboard
#xFFC0
F3
Keyboard
#xFFC1
F4
Keyboard
#xFFC2
F5
Keyboard
#xFFC3
F6
Keyboard
#xFFC4
F7
Keyboard
#xFFC5
F8
Keyboard
#xFFC6
F9
Keyboard
#xFFC7
F10
Keyboard
#xFFC8
F11, L1
Keyboard
#xFFC9
F12, L2
Keyboard
#xFFCA
F13, L3
Keyboard
#xFFCB
F14, L4
Keyboard
#xFFCC
F15, L5
Keyboard
#xFFCD
F16, L6
Keyboard
#xFFCE
F17, L7
Keyboard
#xFFCF
F18, L8
Keyboard
#xFFD0
F19, L9
Keyboard
#xFFD1
F20, L10
Keyboard
#xFFD2
F21, R1
Keyboard
#xFFD3
F22, R2
Keyboard
#xFFD4
F23, R3
Keyboard
#xFFD5
F24, R4
Keyboard
#xFFD6
F25, R5
Keyboard
#xFFD7
F26, R6
Keyboard
#xFFD8
F27, R7
Keyboard
#xFFD9
F28, R8
Keyboard
#xFFDA
F29, R9
Keyboard
#xFFDB
F30, R10
Keyboard
#xFFDC
F31, R11
Keyboard
#xFFDD
F32, R12
Keyboard
#xFFDE
F33, R13
Keyboard
#xFFDF
F34, R14
Keyboard
#xFFE0
F35, R15
Keyboard
#xFFE1
LEFT SHIFT
Keyboard
#xFFE2
RIGHT SHIFT
Keyboard
#xFFE3
LEFT CONTROL
Keyboard
#xFFE4
RIGHT CONTROL
Keyboard
#xFFE5
CAPS LOCK
Keyboard
#xFFE6
SHIFT LOCK
Keyboard
#xFFE7
LEFT META
Keyboard
#xFFE8
RIGHT META
Keyboard
#xFFE9
LEFT ALT
Keyboard
#xFFEA
RIGHT ALT
Keyboard
#xFFEB
LEFT SUPER
Keyboard
#xFFEC
RIGHT SUPER
Keyboard
#xFFED
LEFT HYPER
Keyboard
#xFFEE
RIGHT HYPER
Keyboard
#xFFFF
DELETE, RUBOUT
Keyboard
The Keyboard (XKB) Extension set, which provides among other things
a range of dead keys, is defined in "The X Keyboard Extension:
Protocol Specification", Appendix C.
The 3270 set defines additional keys that are specific to IBM 3270
terminals.
KEYSYM value
Name
Set
#xFD01
3270 DUPLICATE
3270
#xFD02
3270 FIELDMARK
3270
#xFD03
3270 RIGHT2
3270
#xFD04
3270 LEFT2
3270
#xFD05
3270 BACKTAB
3270
#xFD06
3270 ERASEEOF
3270
#xFD07
3270 ERASEINPUT
3270
#xFD08
3270 RESET
3270
#xFD09
3270 QUIT
3270
#xFD0A
3270 PA1
3270
#xFD0B
3270 PA2
3270
#xFD0C
3270 PA3
3270
#xFD0D
3270 TEST
3270
#xFD0E
3270 ATTN
3270
#xFD0F
3270 CURSORBLINK
3270
#xFD10
3270 ALTCURSOR
3270
#xFD11
3270 KEYCLICK
3270
#xFD12
3270 JUMP
3270
#xFD13
3270 IDENT
3270
#xFD14
3270 RULE
3270
#xFD15
3270 COPY
3270
#xFD16
3270 PLAY
3270
#xFD17
3270 SETUP
3270
#xFD18
3270 RECORD
3270
#xFD19
3270 CHANGESCREEN
3270
#xFD1A
3270 DELETEWORD
3270
#xFD1B
3270 EXSELECT
3270
#xFD1C
3270 CURSORSELECT
3270
#xFD1D
3270 PRINTSCREEN
3270
#xFD1E
3270 ENTER
3270
Vendor KEYSYMs
The KEYSYM number range #x10000000 to #x1FFFFFFF is available for
vendor-specific extensions. Among these, the range #x11000000 to
#x1100FFFF is designated for keypad KEYSYMs.
Legacy KEYSYMs
These date from the time before ISO 10646 / Unicode was
available. They represent characters from a number of different older
8-bit coded character sets and have zero values for bytes 1 and
2. Byte 3 indicates a coded character set and byte 4 is the 8-bit
value of the particular character within that set.
Byte 3
Byte 4
Byte 3
Byte 4
1
Latin-2
11
APL
2
Latin-3
12
Hebrew
3
Latin-4
13
Thai
4
Kana
14
Korean
5
Arabic
15
Latin-5
6
Cyrillic
16
Latin-6
7
Greek
17
Latin-7
8
Technical
18
Latin-8
9
Special
19
Latin-9
10
Publishing
32
Currency
Each character set contains gaps where codes have been removed that
were duplicates with codes in previous character sets (that is,
character sets with lesser byte 3 value).
The Latin, Arabic, Cyrillic, Greek, Hebrew, and Thai sets were taken
from the early drafts of the relevant ISO 8859 parts available at the
time. However, in the case of the Cyrillic and Greek sets, these
turned out differently in the final versions of the ISO standard. The
Technical, Special, and Publishing sets are based on Digital Equipment
Corporation standards, as no equivalent international standards were
available at the time.
The table below lists all standardized Legacy KEYSYMs, along with the
name used in the source document. Where there exists an unambiguous
equivalent in Unicode, as it is the case with all ISO 8859 characters,
it is given in the second column as a cross reference. Where there is
no Unicode number provided, the exact semantics of the KEYSYM may have
been lost and a Unicode KEYSYM should be used instead, if available.
As support of Unicode KEYSYMs increases, some or all of the Legacy
KEYSYMs may be phased out and withdrawn in future versions of this
standard. Most KEYSYMs in the sets Technical, Special, Publishing, APL
and Currency (with the exception of #x20AC) were probably never used
in practice, and were not supported by pre-Unicode fonts. In
particular, the Currency set, which was copied from Unicode, has
already been deprecated by the introduction of the Unicode KEYSYMs.
KEYSYM value
Unicode value
Name
Set
#x01A1
U+0104
LATIN CAPITAL LETTER A WITH OGONEK
Latin-2
#x01A2
U+02D8
BREVE
Latin-2
#x01A3
U+0141
LATIN CAPITAL LETTER L WITH STROKE
Latin-2
#x01A5
U+013D
LATIN CAPITAL LETTER L WITH CARON
Latin-2
#x01A6
U+015A
LATIN CAPITAL LETTER S WITH ACUTE
Latin-2
#x01A9
U+0160
LATIN CAPITAL LETTER S WITH CARON
Latin-2
#x01AA
U+015E
LATIN CAPITAL LETTER S WITH CEDILLA
Latin-2
#x01AB
U+0164
LATIN CAPITAL LETTER T WITH CARON
Latin-2
#x01AC
U+0179
LATIN CAPITAL LETTER Z WITH ACUTE
Latin-2
#x01AE
U+017D
LATIN CAPITAL LETTER Z WITH CARON
Latin-2
#x01AF
U+017B
LATIN CAPITAL LETTER Z WITH DOT ABOVE
Latin-2
#x01B1
U+0105
LATIN SMALL LETTER A WITH OGONEK
Latin-2
#x01B2
U+02DB
OGONEK
Latin-2
#x01B3
U+0142
LATIN SMALL LETTER L WITH STROKE
Latin-2
#x01B5
U+013E
LATIN SMALL LETTER L WITH CARON
Latin-2
#x01B6
U+015B
LATIN SMALL LETTER S WITH ACUTE
Latin-2
#x01B7
U+02C7
CARON
Latin-2
#x01B9
U+0161
LATIN SMALL LETTER S WITH CARON
Latin-2
#x01BA
U+015F
LATIN SMALL LETTER S WITH CEDILLA
Latin-2
#x01BB
U+0165
LATIN SMALL LETTER T WITH CARON
Latin-2
#x01BC
U+017A
LATIN SMALL LETTER Z WITH ACUTE
Latin-2
#x01BD
U+02DD
DOUBLE ACUTE ACCENT
Latin-2
#x01BE
U+017E
LATIN SMALL LETTER Z WITH CARON
Latin-2
#x01BF
U+017C
LATIN SMALL LETTER Z WITH DOT ABOVE
Latin-2
#x01C0
U+0154
LATIN CAPITAL LETTER R WITH ACUTE
Latin-2
#x01C3
U+0102
LATIN CAPITAL LETTER A WITH BREVE
Latin-2
#x01C5
U+0139
LATIN CAPITAL LETTER L WITH ACUTE
Latin-2
#x01C6
U+0106
LATIN CAPITAL LETTER C WITH ACUTE
Latin-2
#x01C8
U+010C
LATIN CAPITAL LETTER C WITH CARON
Latin-2
#x01CA
U+0118
LATIN CAPITAL LETTER E WITH OGONEK
Latin-2
#x01CC
U+011A
LATIN CAPITAL LETTER E WITH CARON
Latin-2
#x01CF
U+010E
LATIN CAPITAL LETTER D WITH CARON
Latin-2
#x01D0
U+0110
LATIN CAPITAL LETTER D WITH STROKE
Latin-2
#x01D1
U+0143
LATIN CAPITAL LETTER N WITH ACUTE
Latin-2
#x01D2
U+0147
LATIN CAPITAL LETTER N WITH CARON
Latin-2
#x01D5
U+0150
LATIN CAPITAL LETTER O WITH DOUBLE ACUTE
Latin-2
#x01D8
U+0158
LATIN CAPITAL LETTER R WITH CARON
Latin-2
#x01D9
U+016E
LATIN CAPITAL LETTER U WITH RING ABOVE
Latin-2
#x01DB
U+0170
LATIN CAPITAL LETTER U WITH DOUBLE ACUTE
Latin-2
#x01DE
U+0162
LATIN CAPITAL LETTER T WITH CEDILLA
Latin-2
#x01E0
U+0155
LATIN SMALL LETTER R WITH ACUTE
Latin-2
#x01E3
U+0103
LATIN SMALL LETTER A WITH BREVE
Latin-2
#x01E5
U+013A
LATIN SMALL LETTER L WITH ACUTE
Latin-2
#x01E6
U+0107
LATIN SMALL LETTER C WITH ACUTE
Latin-2
#x01E8
U+010D
LATIN SMALL LETTER C WITH CARON
Latin-2
#x01EA
U+0119
LATIN SMALL LETTER E WITH OGONEK
Latin-2
#x01EC
U+011B
LATIN SMALL LETTER E WITH CARON
Latin-2
#x01EF
U+010F
LATIN SMALL LETTER D WITH CARON
Latin-2
#x01F0
U+0111
LATIN SMALL LETTER D WITH STROKE
Latin-2
#x01F1
U+0144
LATIN SMALL LETTER N WITH ACUTE
Latin-2
#x01F2
U+0148
LATIN SMALL LETTER N WITH CARON
Latin-2
#x01F5
U+0151
LATIN SMALL LETTER O WITH DOUBLE ACUTE
Latin-2
#x01F8
U+0159
LATIN SMALL LETTER R WITH CARON
Latin-2
#x01F9
U+016F
LATIN SMALL LETTER U WITH RING ABOVE
Latin-2
#x01FB
U+0171
LATIN SMALL LETTER U WITH DOUBLE ACUTE
Latin-2
#x01FE
U+0163
LATIN SMALL LETTER T WITH CEDILLA
Latin-2
#x01FF
U+02D9
DOT ABOVE
Latin-2
#x02A1
U+0126
LATIN CAPITAL LETTER H WITH STROKE
Latin-3
#x02A6
U+0124
LATIN CAPITAL LETTER H WITH CIRCUMFLEX
Latin-3
#x02A9
U+0130
LATIN CAPITAL LETTER I WITH DOT ABOVE
Latin-3
#x02AB
U+011E
LATIN CAPITAL LETTER G WITH BREVE
Latin-3
#x02AC
U+0134
LATIN CAPITAL LETTER J WITH CIRCUMFLEX
Latin-3
#x02B1
U+0127
LATIN SMALL LETTER H WITH STROKE
Latin-3
#x02B6
U+0125
LATIN SMALL LETTER H WITH CIRCUMFLEX
Latin-3
#x02B9
U+0131
LATIN SMALL LETTER DOTLESS I
Latin-3
#x02BB
U+011F
LATIN SMALL LETTER G WITH BREVE
Latin-3
#x02BC
U+0135
LATIN SMALL LETTER J WITH CIRCUMFLEX
Latin-3
#x02C5
U+010A
LATIN CAPITAL LETTER C WITH DOT ABOVE
Latin-3
#x02C6
U+0108
LATIN CAPITAL LETTER C WITH CIRCUMFLEX
Latin-3
#x02D5
U+0120
LATIN CAPITAL LETTER G WITH DOT ABOVE
Latin-3
#x02D8
U+011C
LATIN CAPITAL LETTER G WITH CIRCUMFLEX
Latin-3
#x02DD
U+016C
LATIN CAPITAL LETTER U WITH BREVE
Latin-3
#x02DE
U+015C
LATIN CAPITAL LETTER S WITH CIRCUMFLEX
Latin-3
#x02E5
U+010B
LATIN SMALL LETTER C WITH DOT ABOVE
Latin-3
#x02E6
U+0109
LATIN SMALL LETTER C WITH CIRCUMFLEX
Latin-3
#x02F5
U+0121
LATIN SMALL LETTER G WITH DOT ABOVE
Latin-3
#x02F8
U+011D
LATIN SMALL LETTER G WITH CIRCUMFLEX
Latin-3
#x02FD
U+016D
LATIN SMALL LETTER U WITH BREVE
Latin-3
#x02FE
U+015D
LATIN SMALL LETTER S WITH CIRCUMFLEX
Latin-3
#x03A2
U+0138
LATIN SMALL LETTER KRA
Latin-4
#x03A3
U+0156
LATIN CAPITAL LETTER R WITH CEDILLA
Latin-4
#x03A5
U+0128
LATIN CAPITAL LETTER I WITH TILDE
Latin-4
#x03A6
U+013B
LATIN CAPITAL LETTER L WITH CEDILLA
Latin-4
#x03AA
U+0112
LATIN CAPITAL LETTER E WITH MACRON
Latin-4
#x03AB
U+0122
LATIN CAPITAL LETTER G WITH CEDILLA
Latin-4
#x03AC
U+0166
LATIN CAPITAL LETTER T WITH STROKE
Latin-4
#x03B3
U+0157
LATIN SMALL LETTER R WITH CEDILLA
Latin-4
#x03B5
U+0129
LATIN SMALL LETTER I WITH TILDE
Latin-4
#x03B6
U+013C
LATIN SMALL LETTER L WITH CEDILLA
Latin-4
#x03BA
U+0113
LATIN SMALL LETTER E WITH MACRON
Latin-4
#x03BB
U+0123
LATIN SMALL LETTER G WITH CEDILLA
Latin-4
#x03BC
U+0167
LATIN SMALL LETTER T WITH STROKE
Latin-4
#x03BD
U+014A
LATIN CAPITAL LETTER ENG
Latin-4
#x03BF
U+014B
LATIN SMALL LETTER ENG
Latin-4
#x03C0
U+0100
LATIN CAPITAL LETTER A WITH MACRON
Latin-4
#x03C7
U+012E
LATIN CAPITAL LETTER I WITH OGONEK
Latin-4
#x03CC
U+0116
LATIN CAPITAL LETTER E WITH DOT ABOVE
Latin-4
#x03CF
U+012A
LATIN CAPITAL LETTER I WITH MACRON
Latin-4
#x03D1
U+0145
LATIN CAPITAL LETTER N WITH CEDILLA
Latin-4
#x03D2
U+014C
LATIN CAPITAL LETTER O WITH MACRON
Latin-4
#x03D3
U+0136
LATIN CAPITAL LETTER K WITH CEDILLA
Latin-4
#x03D9
U+0172
LATIN CAPITAL LETTER U WITH OGONEK
Latin-4
#x03DD
U+0168
LATIN CAPITAL LETTER U WITH TILDE
Latin-4
#x03DE
U+016A
LATIN CAPITAL LETTER U WITH MACRON
Latin-4
#x03E0
U+0101
LATIN SMALL LETTER A WITH MACRON
Latin-4
#x03E7
U+012F
LATIN SMALL LETTER I WITH OGONEK
Latin-4
#x03EC
U+0117
LATIN SMALL LETTER E WITH DOT ABOVE
Latin-4
#x03EF
U+012B
LATIN SMALL LETTER I WITH MACRON
Latin-4
#x03F1
U+0146
LATIN SMALL LETTER N WITH CEDILLA
Latin-4
#x03F2
U+014D
LATIN SMALL LETTER O WITH MACRON
Latin-4
#x03F3
U+0137
LATIN SMALL LETTER K WITH CEDILLA
Latin-4
#x03F9
U+0173
LATIN SMALL LETTER U WITH OGONEK
Latin-4
#x03FD
U+0169
LATIN SMALL LETTER U WITH TILDE
Latin-4
#x03FE
U+016B
LATIN SMALL LETTER U WITH MACRON
Latin-4
#x047E
U+203E
OVERLINE
Kana
#x04A1
U+3002
KANA FULL STOP
Kana
#x04A2
U+300C
KANA OPENING BRACKET
Kana
#x04A3
U+300D
KANA CLOSING BRACKET
Kana
#x04A4
U+3001
KANA COMMA
Kana
#x04A5
U+30FB
KANA CONJUNCTIVE
Kana
#x04A6
U+30F2
KANA LETTER WO
Kana
#x04A7
U+30A1
KANA LETTER SMALL A
Kana
#x04A8
U+30A3
KANA LETTER SMALL I
Kana
#x04A9
U+30A5
KANA LETTER SMALL U
Kana
#x04AA
U+30A7
KANA LETTER SMALL E
Kana
#x04AB
U+30A9
KANA LETTER SMALL O
Kana
#x04AC
U+30E3
KANA LETTER SMALL YA
Kana
#x04AD
U+30E5
KANA LETTER SMALL YU
Kana
#x04AE
U+30E7
KANA LETTER SMALL YO
Kana
#x04AF
U+30C3
KANA LETTER SMALL TSU
Kana
#x04B0
U+30FC
PROLONGED SOUND SYMBOL
Kana
#x04B1
U+30A2
KANA LETTER A
Kana
#x04B2
U+30A4
KANA LETTER I
Kana
#x04B3
U+30A6
KANA LETTER U
Kana
#x04B4
U+30A8
KANA LETTER E
Kana
#x04B5
U+30AA
KANA LETTER O
Kana
#x04B6
U+30AB
KANA LETTER KA
Kana
#x04B7
U+30AD
KANA LETTER KI
Kana
#x04B8
U+30AF
KANA LETTER KU
Kana
#x04B9
U+30B1
KANA LETTER KE
Kana
#x04BA
U+30B3
KANA LETTER KO
Kana
#x04BB
U+30B5
KANA LETTER SA
Kana
#x04BC
U+30B7
KANA LETTER SHI
Kana
#x04BD
U+30B9
KANA LETTER SU
Kana
#x04BE
U+30BB
KANA LETTER SE
Kana
#x04BF
U+30BD
KANA LETTER SO
Kana
#x04C0
U+30BF
KANA LETTER TA
Kana
#x04C1
U+30C1
KANA LETTER CHI
Kana
#x04C2
U+30C4
KANA LETTER TSU
Kana
#x04C3
U+30C6
KANA LETTER TE
Kana
#x04C4
U+30C8
KANA LETTER TO
Kana
#x04C5
U+30CA
KANA LETTER NA
Kana
#x04C6
U+30CB
KANA LETTER NI
Kana
#x04C7
U+30CC
KANA LETTER NU
Kana
#x04C8
U+30CD
KANA LETTER NE
Kana
#x04C9
U+30CE
KANA LETTER NO
Kana
#x04CA
U+30CF
KANA LETTER HA
Kana
#x04CB
U+30D2
KANA LETTER HI
Kana
#x04CC
U+30D5
KANA LETTER FU
Kana
#x04CD
U+30D8
KANA LETTER HE
Kana
#x04CE
U+30DB
KANA LETTER HO
Kana
#x04CF
U+30DE
KANA LETTER MA
Kana
#x04D0
U+30DF
KANA LETTER MI
Kana
#x04D1
U+30E0
KANA LETTER MU
Kana
#x04D2
U+30E1
KANA LETTER ME
Kana
#x04D3
U+30E2
KANA LETTER MO
Kana
#x04D4
U+30E4
KANA LETTER YA
Kana
#x04D5
U+30E6
KANA LETTER YU
Kana
#x04D6
U+30E8
KANA LETTER YO
Kana
#x04D7
U+30E9
KANA LETTER RA
Kana
#x04D8
U+30EA
KANA LETTER RI
Kana
#x04D9
U+30EB
KANA LETTER RU
Kana
#x04DA
U+30EC
KANA LETTER RE
Kana
#x04DB
U+30ED
KANA LETTER RO
Kana
#x04DC
U+30EF
KANA LETTER WA
Kana
#x04DD
U+30F3
KANA LETTER N
Kana
#x04DE
U+309B
VOICED SOUND SYMBOL
Kana
#x04DF
U+309C
SEMIVOICED SOUND SYMBOL
Kana
#x05AC
U+060C
ARABIC COMMA
Arabic
#x05BB
U+061B
ARABIC SEMICOLON
Arabic
#x05BF
U+061F
ARABIC QUESTION MARK
Arabic
#x05C1
U+0621
ARABIC LETTER HAMZA
Arabic
#x05C2
U+0622
ARABIC LETTER ALEF WITH MADDA ABOVE
Arabic
#x05C3
U+0623
ARABIC LETTER ALEF WITH HAMZA ABOVE
Arabic
#x05C4
U+0624
ARABIC LETTER WAW WITH HAMZA ABOVE
Arabic
#x05C5
U+0625
ARABIC LETTER ALEF WITH HAMZA BELOW
Arabic
#x05C6
U+0626
ARABIC LETTER YEH WITH HAMZA ABOVE
Arabic
#x05C7
U+0627
ARABIC LETTER ALEF
Arabic
#x05C8
U+0628
ARABIC LETTER BEH
Arabic
#x05C9
U+0629
ARABIC LETTER TEH MARBUTA
Arabic
#x05CA
U+062A
ARABIC LETTER TEH
Arabic
#x05CB
U+062B
ARABIC LETTER THEH
Arabic
#x05CC
U+062C
ARABIC LETTER JEEM
Arabic
#x05CD
U+062D
ARABIC LETTER HAH
Arabic
#x05CE
U+062E
ARABIC LETTER KHAH
Arabic
#x05CF
U+062F
ARABIC LETTER DAL
Arabic
#x05D0
U+0630
ARABIC LETTER THAL
Arabic
#x05D1
U+0631
ARABIC LETTER REH
Arabic
#x05D2
U+0632
ARABIC LETTER ZAIN
Arabic
#x05D3
U+0633
ARABIC LETTER SEEN
Arabic
#x05D4
U+0634
ARABIC LETTER SHEEN
Arabic
#x05D5
U+0635
ARABIC LETTER SAD
Arabic
#x05D6
U+0636
ARABIC LETTER DAD
Arabic
#x05D7
U+0637
ARABIC LETTER TAH
Arabic
#x05D8
U+0638
ARABIC LETTER ZAH
Arabic
#x05D9
U+0639
ARABIC LETTER AIN
Arabic
#x05DA
U+063A
ARABIC LETTER GHAIN
Arabic
#x05E0
U+0640
ARABIC TATWEEL
Arabic
#x05E1
U+0641
ARABIC LETTER FEH
Arabic
#x05E2
U+0642
ARABIC LETTER QAF
Arabic
#x05E3
U+0643
ARABIC LETTER KAF
Arabic
#x05E4
U+0644
ARABIC LETTER LAM
Arabic
#x05E5
U+0645
ARABIC LETTER MEEM
Arabic
#x05E6
U+0646
ARABIC LETTER NOON
Arabic
#x05E7
U+0647
ARABIC LETTER HEH
Arabic
#x05E8
U+0648
ARABIC LETTER WAW
Arabic
#x05E9
U+0649
ARABIC LETTER ALEF MAKSURA
Arabic
#x05EA
U+064A
ARABIC LETTER YEH
Arabic
#x05EB
U+064B
ARABIC FATHATAN
Arabic
#x05EC
U+064C
ARABIC DAMMATAN
Arabic
#x05ED
U+064D
ARABIC KASRATAN
Arabic
#x05EE
U+064E
ARABIC FATHA
Arabic
#x05EF
U+064F
ARABIC DAMMA
Arabic
#x05F0
U+0650
ARABIC KASRA
Arabic
#x05F1
U+0651
ARABIC SHADDA
Arabic
#x05F2
U+0652
ARABIC SUKUN
Arabic
#x06A1
U+0452
CYRILLIC SMALL LETTER DJE
Cyrillic
#x06A2
U+0453
CYRILLIC SMALL LETTER GJE
Cyrillic
#x06A3
U+0451
CYRILLIC SMALL LETTER IO
Cyrillic
#x06A4
U+0454
CYRILLIC SMALL LETTER UKRAINIAN IE
Cyrillic
#x06A5
U+0455
CYRILLIC SMALL LETTER DZE
Cyrillic
#x06A6
U+0456
CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I
Cyrillic
#x06A7
U+0457
CYRILLIC SMALL LETTER YI
Cyrillic
#x06A8
U+0458
CYRILLIC SMALL LETTER JE
Cyrillic
#x06A9
U+0459
CYRILLIC SMALL LETTER LJE
Cyrillic
#x06AA
U+045A
CYRILLIC SMALL LETTER NJE
Cyrillic
#x06AB
U+045B
CYRILLIC SMALL LETTER TSHE
Cyrillic
#x06AC
U+045C
CYRILLIC SMALL LETTER KJE
Cyrillic
#x06AD
U+0491
CYRILLIC SMALL LETTER GHE WITH UPTURN
Cyrillic
#x06AE
U+045E
CYRILLIC SMALL LETTER SHORT U
Cyrillic
#x06AF
U+045F
CYRILLIC SMALL LETTER DZHE
Cyrillic
#x06B0
U+2116
NUMERO SIGN
Cyrillic
#x06B1
U+0402
CYRILLIC CAPITAL LETTER DJE
Cyrillic
#x06B2
U+0403
CYRILLIC CAPITAL LETTER GJE
Cyrillic
#x06B3
U+0401
CYRILLIC CAPITAL LETTER IO
Cyrillic
#x06B4
U+0404
CYRILLIC CAPITAL LETTER UKRAINIAN IE
Cyrillic
#x06B5
U+0405
CYRILLIC CAPITAL LETTER DZE
Cyrillic
#x06B6
U+0406
CYRILLIC CAPITAL LETTER BYELORUSSIAN-UKRAINIAN I
Cyrillic
#x06B7
U+0407
CYRILLIC CAPITAL LETTER YI
Cyrillic
#x06B8
U+0408
CYRILLIC CAPITAL LETTER JE
Cyrillic
#x06B9
U+0409
CYRILLIC CAPITAL LETTER LJE
Cyrillic
#x06BA
U+040A
CYRILLIC CAPITAL LETTER NJE
Cyrillic
#x06BB
U+040B
CYRILLIC CAPITAL LETTER TSHE
Cyrillic
#x06BC
U+040C
CYRILLIC CAPITAL LETTER KJE
Cyrillic
#x06BD
U+0490
CYRILLIC CAPITAL LETTER GHE WITH UPTURN
Cyrillic
#x06BE
U+040E
CYRILLIC CAPITAL LETTER SHORT U
Cyrillic
#x06BF
U+040F
CYRILLIC CAPITAL LETTER DZHE
Cyrillic
#x06C0
U+044E
CYRILLIC SMALL LETTER YU
Cyrillic
#x06C1
U+0430
CYRILLIC SMALL LETTER A
Cyrillic
#x06C2
U+0431
CYRILLIC SMALL LETTER BE
Cyrillic
#x06C3
U+0446
CYRILLIC SMALL LETTER TSE
Cyrillic
#x06C4
U+0434
CYRILLIC SMALL LETTER DE
Cyrillic
#x06C5
U+0435
CYRILLIC SMALL LETTER IE
Cyrillic
#x06C6
U+0444
CYRILLIC SMALL LETTER EF
Cyrillic
#x06C7
U+0433
CYRILLIC SMALL LETTER GHE
Cyrillic
#x06C8
U+0445
CYRILLIC SMALL LETTER HA
Cyrillic
#x06C9
U+0438
CYRILLIC SMALL LETTER I
Cyrillic
#x06CA
U+0439
CYRILLIC SMALL LETTER SHORT I
Cyrillic
#x06CB
U+043A
CYRILLIC SMALL LETTER KA
Cyrillic
#x06CC
U+043B
CYRILLIC SMALL LETTER EL
Cyrillic
#x06CD
U+043C
CYRILLIC SMALL LETTER EM
Cyrillic
#x06CE
U+043D
CYRILLIC SMALL LETTER EN
Cyrillic
#x06CF
U+043E
CYRILLIC SMALL LETTER O
Cyrillic
#x06D0
U+043F
CYRILLIC SMALL LETTER PE
Cyrillic
#x06D1
U+044F
CYRILLIC SMALL LETTER YA
Cyrillic
#x06D2
U+0440
CYRILLIC SMALL LETTER ER
Cyrillic
#x06D3
U+0441
CYRILLIC SMALL LETTER ES
Cyrillic
#x06D4
U+0442
CYRILLIC SMALL LETTER TE
Cyrillic
#x06D5
U+0443
CYRILLIC SMALL LETTER U
Cyrillic
#x06D6
U+0436
CYRILLIC SMALL LETTER ZHE
Cyrillic
#x06D7
U+0432
CYRILLIC SMALL LETTER VE
Cyrillic
#x06D8
U+044C
CYRILLIC SMALL LETTER SOFT SIGN
Cyrillic
#x06D9
U+044B
CYRILLIC SMALL LETTER YERU
Cyrillic
#x06DA
U+0437
CYRILLIC SMALL LETTER ZE
Cyrillic
#x06DB
U+0448
CYRILLIC SMALL LETTER SHA
Cyrillic
#x06DC
U+044D
CYRILLIC SMALL LETTER E
Cyrillic
#x06DD
U+0449
CYRILLIC SMALL LETTER SHCHA
Cyrillic
#x06DE
U+0447
CYRILLIC SMALL LETTER CHE
Cyrillic
#x06DF
U+044A
CYRILLIC SMALL LETTER HARD SIGN
Cyrillic
#x06E0
U+042E
CYRILLIC CAPITAL LETTER YU
Cyrillic
#x06E1
U+0410
CYRILLIC CAPITAL LETTER A
Cyrillic
#x06E2
U+0411
CYRILLIC CAPITAL LETTER BE
Cyrillic
#x06E3
U+0426
CYRILLIC CAPITAL LETTER TSE
Cyrillic
#x06E4
U+0414
CYRILLIC CAPITAL LETTER DE
Cyrillic
#x06E5
U+0415
CYRILLIC CAPITAL LETTER IE
Cyrillic
#x06E6
U+0424
CYRILLIC CAPITAL LETTER EF
Cyrillic
#x06E7
U+0413
CYRILLIC CAPITAL LETTER GHE
Cyrillic
#x06E8
U+0425
CYRILLIC CAPITAL LETTER HA
Cyrillic
#x06E9
U+0418
CYRILLIC CAPITAL LETTER I
Cyrillic
#x06EA
U+0419
CYRILLIC CAPITAL LETTER SHORT I
Cyrillic
#x06EB
U+041A
CYRILLIC CAPITAL LETTER KA
Cyrillic
#x06EC
U+041B
CYRILLIC CAPITAL LETTER EL
Cyrillic
#x06ED
U+041C
CYRILLIC CAPITAL LETTER EM
Cyrillic
#x06EE
U+041D
CYRILLIC CAPITAL LETTER EN
Cyrillic
#x06EF
U+041E
CYRILLIC CAPITAL LETTER O
Cyrillic
#x06F0
U+041F
CYRILLIC CAPITAL LETTER PE
Cyrillic
#x06F1
U+042F
CYRILLIC CAPITAL LETTER YA
Cyrillic
#x06F2
U+0420
CYRILLIC CAPITAL LETTER ER
Cyrillic
#x06F3
U+0421
CYRILLIC CAPITAL LETTER ES
Cyrillic
#x06F4
U+0422
CYRILLIC CAPITAL LETTER TE
Cyrillic
#x06F5
U+0423
CYRILLIC CAPITAL LETTER U
Cyrillic
#x06F6
U+0416
CYRILLIC CAPITAL LETTER ZHE
Cyrillic
#x06F7
U+0412
CYRILLIC CAPITAL LETTER VE
Cyrillic
#x06F8
U+042C
CYRILLIC CAPITAL LETTER SOFT SIGN
Cyrillic
#x06F9
U+042B
CYRILLIC CAPITAL LETTER YERU
Cyrillic
#x06FA
U+0417
CYRILLIC CAPITAL LETTER ZE
Cyrillic
#x06FB
U+0428
CYRILLIC CAPITAL LETTER SHA
Cyrillic
#x06FC
U+042D
CYRILLIC CAPITAL LETTER E
Cyrillic
#x06FD
U+0429
CYRILLIC CAPITAL LETTER SHCHA
Cyrillic
#x06FE
U+0427
CYRILLIC CAPITAL LETTER CHE
Cyrillic
#x06FF
U+042A
CYRILLIC CAPITAL LETTER HARD SIGN
Cyrillic
#x07A1
U+0386
GREEK CAPITAL LETTER ALPHA WITH TONOS
Greek
#x07A2
U+0388
GREEK CAPITAL LETTER EPSILON WITH TONOS
Greek
#x07A3
U+0389
GREEK CAPITAL LETTER ETA WITH TONOS
Greek
#x07A4
U+038A
GREEK CAPITAL LETTER IOTA WITH TONOS
Greek
#x07A5
U+03AA
GREEK CAPITAL LETTER IOTA WITH DIALYTIKA
Greek
#x07A7
U+038C
GREEK CAPITAL LETTER OMICRON WITH TONOS
Greek
#x07A8
U+038E
GREEK CAPITAL LETTER UPSILON WITH TONOS
Greek
#x07A9
U+03AB
GREEK CAPITAL LETTER UPSILON WITH DIALYTIKA
Greek
#x07AB
U+038F
GREEK CAPITAL LETTER OMEGA WITH TONOS
Greek
#x07AE
U+0385
GREEK DIALYTIKA TONOS
Greek
#x07AF
U+2015
HORIZONTAL BAR
Greek
#x07B1
U+03AC
GREEK SMALL LETTER ALPHA WITH TONOS
Greek
#x07B2
U+03AD
GREEK SMALL LETTER EPSILON WITH TONOS
Greek
#x07B3
U+03AE
GREEK SMALL LETTER ETA WITH TONOS
Greek
#x07B4
U+03AF
GREEK SMALL LETTER IOTA WITH TONOS
Greek
#x07B5
U+03CA
GREEK SMALL LETTER IOTA WITH DIALYTIKA
Greek
#x07B6
U+0390
GREEK SMALL LETTER IOTA WITH DIALYTIKA AND TONOS
Greek
#x07B7
U+03CC
GREEK SMALL LETTER OMICRON WITH TONOS
Greek
#x07B8
U+03CD
GREEK SMALL LETTER UPSILON WITH TONOS
Greek
#x07B9
U+03CB
GREEK SMALL LETTER UPSILON WITH DIALYTIKA
Greek
#x07BA
U+03B0
GREEK SMALL LETTER UPSILON WITH DIALYTIKA AND TONOS
Greek
#x07BB
U+03CE
GREEK SMALL LETTER OMEGA WITH TONOS
Greek
#x07C1
U+0391
GREEK CAPITAL LETTER ALPHA
Greek
#x07C2
U+0392
GREEK CAPITAL LETTER BETA
Greek
#x07C3
U+0393
GREEK CAPITAL LETTER GAMMA
Greek
#x07C4
U+0394
GREEK CAPITAL LETTER DELTA
Greek
#x07C5
U+0395
GREEK CAPITAL LETTER EPSILON
Greek
#x07C6
U+0396
GREEK CAPITAL LETTER ZETA
Greek
#x07C7
U+0397
GREEK CAPITAL LETTER ETA
Greek
#x07C8
U+0398
GREEK CAPITAL LETTER THETA
Greek
#x07C9
U+0399
GREEK CAPITAL LETTER IOTA
Greek
#x07CA
U+039A
GREEK CAPITAL LETTER KAPPA
Greek
#x07CB
U+039B
GREEK CAPITAL LETTER LAMDA
Greek
#x07CC
U+039C
GREEK CAPITAL LETTER MU
Greek
#x07CD
U+039D
GREEK CAPITAL LETTER NU
Greek
#x07CE
U+039E
GREEK CAPITAL LETTER XI
Greek
#x07CF
U+039F
GREEK CAPITAL LETTER OMICRON
Greek
#x07D0
U+03A0
GREEK CAPITAL LETTER PI
Greek
#x07D1
U+03A1
GREEK CAPITAL LETTER RHO
Greek
#x07D2
U+03A3
GREEK CAPITAL LETTER SIGMA
Greek
#x07D4
U+03A4
GREEK CAPITAL LETTER TAU
Greek
#x07D5
U+03A5
GREEK CAPITAL LETTER UPSILON
Greek
#x07D6
U+03A6
GREEK CAPITAL LETTER PHI
Greek
#x07D7
U+03A7
GREEK CAPITAL LETTER CHI
Greek
#x07D8
U+03A8
GREEK CAPITAL LETTER PSI
Greek
#x07D9
U+03A9
GREEK CAPITAL LETTER OMEGA
Greek
#x07E1
U+03B1
GREEK SMALL LETTER ALPHA
Greek
#x07E2
U+03B2
GREEK SMALL LETTER BETA
Greek
#x07E3
U+03B3
GREEK SMALL LETTER GAMMA
Greek
#x07E4
U+03B4
GREEK SMALL LETTER DELTA
Greek
#x07E5
U+03B5
GREEK SMALL LETTER EPSILON
Greek
#x07E6
U+03B6
GREEK SMALL LETTER ZETA
Greek
#x07E7
U+03B7
GREEK SMALL LETTER ETA
Greek
#x07E8
U+03B8
GREEK SMALL LETTER THETA
Greek
#x07E9
U+03B9
GREEK SMALL LETTER IOTA
Greek
#x07EA
U+03BA
GREEK SMALL LETTER KAPPA
Greek
#x07EB
U+03BB
GREEK SMALL LETTER LAMDA
Greek
#x07EC
U+03BC
GREEK SMALL LETTER MU
Greek
#x07ED
U+03BD
GREEK SMALL LETTER NU
Greek
#x07EE
U+03BE
GREEK SMALL LETTER XI
Greek
#x07EF
U+03BF
GREEK SMALL LETTER OMICRON
Greek
#x07F0
U+03C0
GREEK SMALL LETTER PI
Greek
#x07F1
U+03C1
GREEK SMALL LETTER RHO
Greek
#x07F2
U+03C3
GREEK SMALL LETTER SIGMA
Greek
#x07F3
U+03C2
GREEK SMALL LETTER FINAL SIGMA
Greek
#x07F4
U+03C4
GREEK SMALL LETTER TAU
Greek
#x07F5
U+03C5
GREEK SMALL LETTER UPSILON
Greek
#x07F6
U+03C6
GREEK SMALL LETTER PHI
Greek
#x07F7
U+03C7
GREEK SMALL LETTER CHI
Greek
#x07F8
U+03C8
GREEK SMALL LETTER PSI
Greek
#x07F9
U+03C9
GREEK SMALL LETTER OMEGA
Greek
#x08A1
U+23B7
LEFT RADICAL
Technical
#x08A2
-
TOP LEFT RADICAL
Technical
#x08A3
-
HORIZONTAL CONNECTOR
Technical
#x08A4
U+2320
TOP INTEGRAL
Technical
#x08A5
U+2321
BOTTOM INTEGRAL
Technical
#x08A6
-
VERTICAL CONNECTOR
Technical
#x08A7
U+23A1
TOP LEFT SQUARE BRACKET
Technical
#x08A8
U+23A3
BOTTOM LEFT SQUARE BRACKET
Technical
#x08A9
U+23A4
TOP RIGHT SQUARE BRACKET
Technical
#x08AA
U+23A6
BOTTOM RIGHT SQUARE BRACKET
Technical
#x08AB
U+239B
TOP LEFT PARENTHESIS
Technical
#x08AC
U+239D
BOTTOM LEFT PARENTHESIS
Technical
#x08AD
U+239E
TOP RIGHT PARENTHESIS
Technical
#x08AE
U+23A0
BOTTOM RIGHT PARENTHESIS
Technical
#x08AF
U+23A8
LEFT MIDDLE CURLY BRACE
Technical
#x08B0
U+23AC
RIGHT MIDDLE CURLY BRACE
Technical
#x08B1
-
TOP LEFT SUMMATION
Technical
#x08B2
-
BOTTOM LEFT SUMMATION
Technical
#x08B3
-
TOP VERTICAL SUMMATION CONNECTOR
Technical
#x08B4
-
BOTTOM VERTICAL SUMMATION CONNECTOR
Technical
#x08B5
-
TOP RIGHT SUMMATION
Technical
#x08B6
-
BOTTOM RIGHT SUMMATION
Technical
#x08B7
-
RIGHT MIDDLE SUMMATION
Technical
#x08BC
U+2264
LESS THAN OR EQUAL SIGN
Technical
#x08BD
U+2260
NOT EQUAL SIGN
Technical
#x08BE
U+2265
GREATER THAN OR EQUAL SIGN
Technical
#x08BF
U+222B
INTEGRAL
Technical
#x08C0
U+2234
THEREFORE
Technical
#x08C1
U+221D
VARIATION, PROPORTIONAL TO
Technical
#x08C2
U+221E
INFINITY
Technical
#x08C5
U+2207
NABLA, DEL
Technical
#x08C8
U+223C
IS APPROXIMATE TO
Technical
#x08C9
U+2243
SIMILAR OR EQUAL TO
Technical
#x08CD
U+21D4
IF AND ONLY IF
Technical
#x08CE
U+21D2
IMPLIES
Technical
#x08CF
U+2261
IDENTICAL TO
Technical
#x08D6
U+221A
RADICAL
Technical
#x08DA
U+2282
IS INCLUDED IN
Technical
#x08DB
U+2283
INCLUDES
Technical
#x08DC
U+2229
INTERSECTION
Technical
#x08DD
U+222A
UNION
Technical
#x08DE
U+2227
LOGICAL AND
Technical
#x08DF
U+2228
LOGICAL OR
Technical
#x08EF
U+2202
PARTIAL DERIVATIVE
Technical
#x08F6
U+0192
FUNCTION
Technical
#x08FB
U+2190
LEFT ARROW
Technical
#x08FC
U+2191
UPWARD ARROW
Technical
#x08FD
U+2192
RIGHT ARROW
Technical
#x08FE
U+2193
DOWNWARD ARROW
Technical
#x09DF
-
BLANK
Special
#x09E0
U+25C6
SOLID DIAMOND
Special
#x09E1
U+2592
CHECKERBOARD
Special
#x09E2
U+2409
"HT"
Special
#x09E3
U+240C
"FF"
Special
#x09E4
U+240D
"CR"
Special
#x09E5
U+240A
"LF"
Special
#x09E8
U+2424
"NL"
Special
#x09E9
U+240B
"VT"
Special
#x09EA
U+2518
LOWER-RIGHT CORNER
Special
#x09EB
U+2510
UPPER-RIGHT CORNER
Special
#x09EC
U+250C
UPPER-LEFT CORNER
Special
#x09ED
U+2514
LOWER-LEFT CORNER
Special
#x09EE
U+253C
CROSSING-LINES
Special
#x09EF
U+23BA
HORIZONTAL LINE, SCAN 1
Special
#x09F0
U+23BB
HORIZONTAL LINE, SCAN 3
Special
#x09F1
U+2500
HORIZONTAL LINE, SCAN 5
Special
#x09F2
U+23BC
HORIZONTAL LINE, SCAN 7
Special
#x09F3
U+23BD
HORIZONTAL LINE, SCAN 9
Special
#x09F4
U+251C
LEFT "T"
Special
#x09F5
U+2524
RIGHT "T"
Special
#x09F6
U+2534
BOTTOM "T"
Special
#x09F7
U+252C
TOP "T"
Special
#x09F8
U+2502
VERTICAL BAR
Special
#x0AA1
U+2003
EM SPACE
Publish
#x0AA2
U+2002
EN SPACE
Publish
#x0AA3
U+2004
3/EM SPACE
Publish
#x0AA4
U+2005
4/EM SPACE
Publish
#x0AA5
U+2007
DIGIT SPACE
Publish
#x0AA6
U+2008
PUNCTUATION SPACE
Publish
#x0AA7
U+2009
THIN SPACE
Publish
#x0AA8
U+200A
HAIR SPACE
Publish
#x0AA9
U+2014
EM DASH
Publish
#x0AAA
U+2013
EN DASH
Publish
#x0AAC
-
SIGNIFICANT BLANK SYMBOL
Publish
#x0AAE
U+2026
ELLIPSIS
Publish
#x0AAF
U+2025
DOUBLE BASELINE DOT
Publish
#x0AB0
U+2153
VULGAR FRACTION ONE THIRD
Publish
#x0AB1
U+2154
VULGAR FRACTION TWO THIRDS
Publish
#x0AB2
U+2155
VULGAR FRACTION ONE FIFTH
Publish
#x0AB3
U+2156
VULGAR FRACTION TWO FIFTHS
Publish
#x0AB4
U+2157
VULGAR FRACTION THREE FIFTHS
Publish
#x0AB5
U+2158
VULGAR FRACTION FOUR FIFTHS
Publish
#x0AB6
U+2159
VULGAR FRACTION ONE SIXTH
Publish
#x0AB7
U+215A
VULGAR FRACTION FIVE SIXTHS
Publish
#x0AB8
U+2105
CARE OF
Publish
#x0ABB
U+2012
FIGURE DASH
Publish
#x0ABC
-
LEFT ANGLE BRACKET
Publish
#x0ABD
-
DECIMAL POINT
Publish
#x0ABE
-
RIGHT ANGLE BRACKET
Publish
#x0ABF
-
MARKER
Publish
#x0AC3
U+215B
VULGAR FRACTION ONE EIGHTH
Publish
#x0AC4
U+215C
VULGAR FRACTION THREE EIGHTHS
Publish
#x0AC5
U+215D
VULGAR FRACTION FIVE EIGHTHS
Publish
#x0AC6
U+215E
VULGAR FRACTION SEVEN EIGHTHS
Publish
#x0AC9
U+2122
TRADEMARK SIGN
Publish
#x0ACA
-
SIGNATURE MARK
Publish
#x0ACB
-
TRADEMARK SIGN IN CIRCLE
Publish
#x0ACC
-
LEFT OPEN TRIANGLE
Publish
#x0ACD
-
RIGHT OPEN TRIANGLE
Publish
#x0ACE
-
EM OPEN CIRCLE
Publish
#x0ACF
-
EM OPEN RECTANGLE
Publish
#x0AD0
U+2018
LEFT SINGLE QUOTATION MARK
Publish
#x0AD1
U+2019
RIGHT SINGLE QUOTATION MARK
Publish
#x0AD2
U+201C
LEFT DOUBLE QUOTATION MARK
Publish
#x0AD3
U+201D
RIGHT DOUBLE QUOTATION MARK
Publish
#x0AD4
U+211E
PRESCRIPTION, TAKE, RECIPE
Publish
#x0AD5
U+2030
PER MILLE SIGN
Publish
#x0AD6
U+2032
MINUTES
Publish
#x0AD7
U+2033
SECONDS
Publish
#x0AD9
U+271D
LATIN CROSS
Publish
#x0ADA
-
HEXAGRAM
Publish
#x0ADB
-
FILLED RECTANGLE BULLET
Publish
#x0ADC
-
FILLED LEFT TRIANGLE BULLET
Publish
#x0ADD
-
FILLED RIGHT TRIANGLE BULLET
Publish
#x0ADE
-
EM FILLED CIRCLE
Publish
#x0ADF
-
EM FILLED RECTANGLE
Publish
#x0AE0
-
EN OPEN CIRCLE BULLET
Publish
#x0AE1
-
EN OPEN SQUARE BULLET
Publish
#x0AE2
-
OPEN RECTANGULAR BULLET
Publish
#x0AE3
-
OPEN TRIANGULAR BULLET UP
Publish
#x0AE4
-
OPEN TRIANGULAR BULLET DOWN
Publish
#x0AE5
-
OPEN STAR
Publish
#x0AE6
-
EN FILLED CIRCLE BULLET
Publish
#x0AE7
-
EN FILLED SQUARE BULLET
Publish
#x0AE8
-
FILLED TRIANGULAR BULLET UP
Publish
#x0AE9
-
FILLED TRIANGULAR BULLET DOWN
Publish
#x0AEA
-
LEFT POINTER
Publish
#x0AEB
-
RIGHT POINTER
Publish
#x0AEC
U+2663
CLUB
Publish
#x0AED
U+2666
DIAMOND
Publish
#x0AEE
U+2665
HEART
Publish
#x0AF0
U+2720
MALTESE CROSS
Publish
#x0AF1
U+2020
DAGGER
Publish
#x0AF2
U+2021
DOUBLE DAGGER
Publish
#x0AF3
U+2713
CHECK MARK, TICK
Publish
#x0AF4
U+2717
BALLOT CROSS
Publish
#x0AF5
U+266F
MUSICAL SHARP
Publish
#x0AF6
U+266D
MUSICAL FLAT
Publish
#x0AF7
U+2642
MALE SYMBOL
Publish
#x0AF8
U+2640
FEMALE SYMBOL
Publish
#x0AF9
U+260E
TELEPHONE SYMBOL
Publish
#x0AFA
U+2315
TELEPHONE RECORDER SYMBOL
Publish
#x0AFB
U+2117
PHONOGRAPH COPYRIGHT SIGN
Publish
#x0AFC
U+2038
CARET
Publish
#x0AFD
U+201A
SINGLE LOW QUOTATION MARK
Publish
#x0AFE
U+201E
DOUBLE LOW QUOTATION MARK
Publish
#x0AFF
-
CURSOR
Publish
#x0BA3
-
LEFT CARET
APL
#x0BA6
-
RIGHT CARET
APL
#x0BA8
-
DOWN CARET
APL
#x0BA9
-
UP CARET
APL
#x0BC0
-
OVERBAR
APL
#x0BC2
U+22A5
DOWN TACK
APL
#x0BC3
-
UP SHOE (CAP)
APL
#x0BC4
U+230A
DOWN STILE
APL
#x0BC6
-
UNDERBAR
APL
#x0BCA
U+2218
JOT
APL
#x0BCC
U+2395
QUAD
APL
#x0BCE
U+22A4
UP TACK
APL
#x0BCF
U+25CB
CIRCLE
APL
#x0BD3
U+2308
UP STILE
APL
#x0BD6
-
DOWN SHOE (CUP)
APL
#x0BD8
-
RIGHT SHOE
APL
#x0BDA
-
LEFT SHOE
APL
#x0BDC
U+22A2
LEFT TACK
APL
#x0BFC
U+22A3
RIGHT TACK
APL
#x0CDF
U+2017
DOUBLE LOW LINE
Hebrew
#x0CE0
U+05D0
HEBREW LETTER ALEF
Hebrew
#x0CE1
U+05D1
HEBREW LETTER BET
Hebrew
#x0CE2
U+05D2
HEBREW LETTER GIMEL
Hebrew
#x0CE3
U+05D3
HEBREW LETTER DALET
Hebrew
#x0CE4
U+05D4
HEBREW LETTER HE
Hebrew
#x0CE5
U+05D5
HEBREW LETTER VAV
Hebrew
#x0CE6
U+05D6
HEBREW LETTER ZAYIN
Hebrew
#x0CE7
U+05D7
HEBREW LETTER HET
Hebrew
#x0CE8
U+05D8
HEBREW LETTER TET
Hebrew
#x0CE9
U+05D9
HEBREW LETTER YOD
Hebrew
#x0CEA
U+05DA
HEBREW LETTER FINAL KAF
Hebrew
#x0CEB
U+05DB
HEBREW LETTER KAF
Hebrew
#x0CEC
U+05DC
HEBREW LETTER LAMED
Hebrew
#x0CED
U+05DD
HEBREW LETTER FINAL MEM
Hebrew
#x0CEE
U+05DE
HEBREW LETTER MEM
Hebrew
#x0CEF
U+05DF
HEBREW LETTER FINAL NUN
Hebrew
#x0CF0
U+05E0
HEBREW LETTER NUN
Hebrew
#x0CF1
U+05E1
HEBREW LETTER SAMEKH
Hebrew
#x0CF2
U+05E2
HEBREW LETTER AYIN
Hebrew
#x0CF3
U+05E3
HEBREW LETTER FINAL PE
Hebrew
#x0CF4
U+05E4
HEBREW LETTER PE
Hebrew
#x0CF5
U+05E5
HEBREW LETTER FINAL TSADI
Hebrew
#x0CF6
U+05E6
HEBREW LETTER TSADI
Hebrew
#x0CF7
U+05E7
HEBREW LETTER QOF
Hebrew
#x0CF8
U+05E8
HEBREW LETTER RESH
Hebrew
#x0CF9
U+05E9
HEBREW LETTER SHIN
Hebrew
#x0CFA
U+05EA
HEBREW LETTER TAV
Hebrew
#x0DA1
U+0E01
THAI CHARACTER KO KAI
Thai
#x0DA2
U+0E02
THAI CHARACTER KHO KHAI
Thai
#x0DA3
U+0E03
THAI CHARACTER KHO KHUAT
Thai
#x0DA4
U+0E04
THAI CHARACTER KHO KHWAI
Thai
#x0DA5
U+0E05
THAI CHARACTER KHO KHON
Thai
#x0DA6
U+0E06
THAI CHARACTER KHO RAKHANG
Thai
#x0DA7
U+0E07
THAI CHARACTER NGO NGU
Thai
#x0DA8
U+0E08
THAI CHARACTER CHO CHAN
Thai
#x0DA9
U+0E09
THAI CHARACTER CHO CHING
Thai
#x0DAA
U+0E0A
THAI CHARACTER CHO CHANG
Thai
#x0DAB
U+0E0B
THAI CHARACTER SO SO
Thai
#x0DAC
U+0E0C
THAI CHARACTER CHO CHOE
Thai
#x0DAD
U+0E0D
THAI CHARACTER YO YING
Thai
#x0DAE
U+0E0E
THAI CHARACTER DO CHADA
Thai
#x0DAF
U+0E0F
THAI CHARACTER TO PATAK
Thai
#x0DB0
U+0E10
THAI CHARACTER THO THAN
Thai
#x0DB1
U+0E11
THAI CHARACTER THO NANGMONTHO
Thai
#x0DB2
U+0E12
THAI CHARACTER THO PHUTHAO
Thai
#x0DB3
U+0E13
THAI CHARACTER NO NEN
Thai
#x0DB4
U+0E14
THAI CHARACTER DO DEK
Thai
#x0DB5
U+0E15
THAI CHARACTER TO TAO
Thai
#x0DB6
U+0E16
THAI CHARACTER THO THUNG
Thai
#x0DB7
U+0E17
THAI CHARACTER THO THAHAN
Thai
#x0DB8
U+0E18
THAI CHARACTER THO THONG
Thai
#x0DB9
U+0E19
THAI CHARACTER NO NU
Thai
#x0DBA
U+0E1A
THAI CHARACTER BO BAIMAI
Thai
#x0DBB
U+0E1B
THAI CHARACTER PO PLA
Thai
#x0DBC
U+0E1C
THAI CHARACTER PHO PHUNG
Thai
#x0DBD
U+0E1D
THAI CHARACTER FO FA
Thai
#x0DBE
U+0E1E
THAI CHARACTER PHO PHAN
Thai
#x0DBF
U+0E1F
THAI CHARACTER FO FAN
Thai
#x0DC0
U+0E20
THAI CHARACTER PHO SAMPHAO
Thai
#x0DC1
U+0E21
THAI CHARACTER MO MA
Thai
#x0DC2
U+0E22
THAI CHARACTER YO YAK
Thai
#x0DC3
U+0E23
THAI CHARACTER RO RUA
Thai
#x0DC4
U+0E24
THAI CHARACTER RU
Thai
#x0DC5
U+0E25
THAI CHARACTER LO LING
Thai
#x0DC6
U+0E26
THAI CHARACTER LU
Thai
#x0DC7
U+0E27
THAI CHARACTER WO WAEN
Thai
#x0DC8
U+0E28
THAI CHARACTER SO SALA
Thai
#x0DC9
U+0E29
THAI CHARACTER SO RUSI
Thai
#x0DCA
U+0E2A
THAI CHARACTER SO SUA
Thai
#x0DCB
U+0E2B
THAI CHARACTER HO HIP
Thai
#x0DCC
U+0E2C
THAI CHARACTER LO CHULA
Thai
#x0DCD
U+0E2D
THAI CHARACTER O ANG
Thai
#x0DCE
U+0E2E
THAI CHARACTER HO NOKHUK
Thai
#x0DCF
U+0E2F
THAI CHARACTER PAIYANNOI
Thai
#x0DD0
U+0E30
THAI CHARACTER SARA A
Thai
#x0DD1
U+0E31
THAI CHARACTER MAI HAN-AKAT
Thai
#x0DD2
U+0E32
THAI CHARACTER SARA AA
Thai
#x0DD3
U+0E33
THAI CHARACTER SARA AM
Thai
#x0DD4
U+0E34
THAI CHARACTER SARA I
Thai
#x0DD5
U+0E35
THAI CHARACTER SARA II
Thai
#x0DD6
U+0E36
THAI CHARACTER SARA UE
Thai
#x0DD7
U+0E37
THAI CHARACTER SARA UEE
Thai
#x0DD8
U+0E38
THAI CHARACTER SARA U
Thai
#x0DD9
U+0E39
THAI CHARACTER SARA UU
Thai
#x0DDA
U+0E3A
THAI CHARACTER PHINTHU
Thai
#x0DDF
U+0E3F
THAI CURRENCY SYMBOL BAHT
Thai
#x0DE0
U+0E40
THAI CHARACTER SARA E
Thai
#x0DE1
U+0E41
THAI CHARACTER SARA AE
Thai
#x0DE2
U+0E42
THAI CHARACTER SARA O
Thai
#x0DE3
U+0E43
THAI CHARACTER SARA AI MAIMUAN
Thai
#x0DE4
U+0E44
THAI CHARACTER SARA AI MAIMALAI
Thai
#x0DE5
U+0E45
THAI CHARACTER LAKKHANGYAO
Thai
#x0DE6
U+0E46
THAI CHARACTER MAIYAMOK
Thai
#x0DE7
U+0E47
THAI CHARACTER MAITAIKHU
Thai
#x0DE8
U+0E48
THAI CHARACTER MAI EK
Thai
#x0DE9
U+0E49
THAI CHARACTER MAI THO
Thai
#x0DEA
U+0E4A
THAI CHARACTER MAI TRI
Thai
#x0DEB
U+0E4B
THAI CHARACTER MAI CHATTAWA
Thai
#x0DEC
U+0E4C
THAI CHARACTER THANTHAKHAT
Thai
#x0DED
U+0E4D
THAI CHARACTER NIKHAHIT
Thai
#x0DF0
U+0E50
THAI DIGIT ZERO
Thai
#x0DF1
U+0E51
THAI DIGIT ONE
Thai
#x0DF2
U+0E52
THAI DIGIT TWO
Thai
#x0DF3
U+0E53
THAI DIGIT THREE
Thai
#x0DF4
U+0E54
THAI DIGIT FOUR
Thai
#x0DF5
U+0E55
THAI DIGIT FIVE
Thai
#x0DF6
U+0E56
THAI DIGIT SIX
Thai
#x0DF7
U+0E57
THAI DIGIT SEVEN
Thai
#x0DF8
U+0E58
THAI DIGIT EIGHT
Thai
#x0DF9
U+0E59
THAI DIGIT NINE
Thai
#x0EA1
-
HANGUL KIYEOG
Korean
#x0EA2
-
HANGUL SSANG KIYEOG
Korean
#x0EA3
-
HANGUL KIYEOG SIOS
Korean
#x0EA4
-
HANGUL NIEUN
Korean
#x0EA5
-
HANGUL NIEUN JIEUJ
Korean
#x0EA6
-
HANGUL NIEUN HIEUH
Korean
#x0EA7
-
HANGUL DIKEUD
Korean
#x0EA8
-
HANGUL SSANG DIKEUD
Korean
#x0EA9
-
HANGUL RIEUL
Korean
#x0EAA
-
HANGUL RIEUL KIYEOG
Korean
#x0EAB
-
HANGUL RIEUL MIEUM
Korean
#x0EAC
-
HANGUL RIEUL PIEUB
Korean
#x0EAD
-
HANGUL RIEUL SIOS
Korean
#x0EAE
-
HANGUL RIEUL TIEUT
Korean
#x0EAF
-
HANGUL RIEUL PHIEUF
Korean
#x0EB0
-
HANGUL RIEUL HIEUH
Korean
#x0EB1
-
HANGUL MIEUM
Korean
#x0EB2
-
HANGUL PIEUB
Korean
#x0EB3
-
HANGUL SSANG PIEUB
Korean
#x0EB4
-
HANGUL PIEUB SIOS
Korean
#x0EB5
-
HANGUL SIOS
Korean
#x0EB6
-
HANGUL SSANG SIOS
Korean
#x0EB7
-
HANGUL IEUNG
Korean
#x0EB8
-
HANGUL JIEUJ
Korean
#x0EB9
-
HANGUL SSANG JIEUJ
Korean
#x0EBA
-
HANGUL CIEUC
Korean
#x0EBB
-
HANGUL KHIEUQ
Korean
#x0EBC
-
HANGUL TIEUT
Korean
#x0EBD
-
HANGUL PHIEUF
Korean
#x0EBE
-
HANGUL HIEUH
Korean
#x0EBF
-
HANGUL A
Korean
#x0EC0
-
HANGUL AE
Korean
#x0EC1
-
HANGUL YA
Korean
#x0EC2
-
HANGUL YAE
Korean
#x0EC3
-
HANGUL EO
Korean
#x0EC4
-
HANGUL E
Korean
#x0EC5
-
HANGUL YEO
Korean
#x0EC6
-
HANGUL YE
Korean
#x0EC7
-
HANGUL O
Korean
#x0EC8
-
HANGUL WA
Korean
#x0EC9
-
HANGUL WAE
Korean
#x0ECA
-
HANGUL OE
Korean
#x0ECB
-
HANGUL YO
Korean
#x0ECC
-
HANGUL U
Korean
#x0ECD
-
HANGUL WEO
Korean
#x0ECE
-
HANGUL WE
Korean
#x0ECF
-
HANGUL WI
Korean
#x0ED0
-
HANGUL YU
Korean
#x0ED1
-
HANGUL EU
Korean
#x0ED2
-
HANGUL YI
Korean
#x0ED3
-
HANGUL I
Korean
#x0ED4
-
HANGUL JONG SEONG KIYEOG
Korean
#x0ED5
-
HANGUL JONG SEONG SSANG KIYEOG
Korean
#x0ED6
-
HANGUL JONG SEONG KIYEOG SIOS
Korean
#x0ED7
-
HANGUL JONG SEONG NIEUN
Korean
#x0ED8
-
HANGUL JONG SEONG NIEUN JIEUJ
Korean
#x0ED9
-
HANGUL JONG SEONG NIEUN HIEUH
Korean
#x0EDA
-
HANGUL JONG SEONG DIKEUD
Korean
#x0EDB
-
HANGUL JONG SEONG RIEUL
Korean
#x0EDC
-
HANGUL JONG SEONG RIEUL KIYEOG
Korean
#x0EDD
-
HANGUL JONG SEONG RIEUL MIEUM
Korean
#x0EDE
-
HANGUL JONG SEONG RIEUL PIEUB
Korean
#x0EDF
-
HANGUL JONG SEONG RIEUL SIOS
Korean
#x0EE0
-
HANGUL JONG SEONG RIEUL TIEUT
Korean
#x0EE1
-
HANGUL JONG SEONG RIEUL PHIEUF
Korean
#x0EE2
-
HANGUL JONG SEONG RIEUL HIEUH
Korean
#x0EE3
-
HANGUL JONG SEONG MIEUM
Korean
#x0EE4
-
HANGUL JONG SEONG PIEUB
Korean
#x0EE5
-
HANGUL JONG SEONG PIEUB SIOS
Korean
#x0EE6
-
HANGUL JONG SEONG SIOS
Korean
#x0EE7
-
HANGUL JONG SEONG SSANG SIOS
Korean
#x0EE8
-
HANGUL JONG SEONG IEUNG
Korean
#x0EE9
-
HANGUL JONG SEONG JIEUJ
Korean
#x0EEA
-
HANGUL JONG SEONG CIEUC
Korean
#x0EEB
-
HANGUL JONG SEONG KHIEUQ
Korean
#x0EEC
-
HANGUL JONG SEONG TIEUT
Korean
#x0EED
-
HANGUL JONG SEONG PHIEUF
Korean
#x0EEE
-
HANGUL JONG SEONG HIEUH
Korean
#x0EEF
-
HANGUL RIEUL YEORIN HIEUH
Korean
#x0EF0
-
HANGUL SUNKYEONGEUM MIEUM
Korean
#x0EF1
-
HANGUL SUNKYEONGEUM PIEUB
Korean
#x0EF2
-
HANGUL PAN SIOS
Korean
#x0EF3
-
HANGUL KKOGJI DALRIN IEUNG
Korean
#x0EF4
-
HANGUL SUNKYEONGEUM PHIEUF
Korean
#x0EF5
-
HANGUL YEORIN HIEUH
Korean
#x0EF6
-
HANGUL ARAE A
Korean
#x0EF7
-
HANGUL ARAE AE
Korean
#x0EF8
-
HANGUL JONG SEONG PAN SIOS
Korean
#x0EF9
-
HANGUL JONG SEONG KKOGJI DALRIN IEUNG
Korean
#x0EFA
-
HANGUL JONG SEONG YEORIN HIEUH
Korean
#x0EFF
-
KOREAN WON
Korean
#x13BC
U+0152
LATIN CAPITAL LIGATURE OE
Latin-9
#x13BD
U+0153
LATIN SMALL LIGATURE OE
Latin-9
#x13BE
U+0178
LATIN CAPITAL LETTER Y WITH DIAERESIS
Latin-9
#x20A0
-
CURRENCY ECU SIGN
Currency
#x20A1
-
CURRENCY COLON SIGN
Currency
#x20A2
-
CURRENCY CRUZEIRO SIGN
Currency
#x20A3
-
CURRENCY FRENCH FRANC SIGN
Currency
#x20A4
-
CURRENCY LIRA SIGN
Currency
#x20A5
-
CURRENCY MILL SIGN
Currency
#x20A6
-
CURRENCY NAIRA SIGN
Currency
#x20A7
-
CURRENCY PESETA SIGN
Currency
#x20A8
-
CURRENCY RUPEE SIGN
Currency
#x20A9
-
CURRENCY WON SIGN
Currency
#x20AA
-
CURRENCY NEW SHEQEL SIGN
Currency
#x20AB
-
CURRENCY DONG SIGN
Currency
#x20AC
U+20AC
CURRENCY EURO SIGN
Currency
xorgproto-2023.2/specs/scrnsaverproto/ 0000755 0001750 0001750 00000000000 14443010036 015050 5 0000000 0000000 xorgproto-2023.2/specs/scrnsaverproto/saver.xml 0000644 0001750 0001750 00000104643 14443010026 016641 0000000 0000000
%defs;
]>
X11 Screen Saver Extension
MIT X Consortium Proposed Standard
X Version 11, Release &fullrelvers;
Version 1.0
Jim Fulton
Network Computing Devices, Inc
Keith Packard
X Consortium, Laboratory for Computer Science, Massachusetts Institute of Technology
1992
Massachusetts Institute of Technology
Network Computing Devices, Inc
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. MIT and
Network Computing Devices, Inc. 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.
Introduction
The X Window System provides support for changing the image on a display screen
after a user-settable period of inactivity to avoid burning the cathode ray
tube phosphors. However, no interfaces are provided for the user to control
the image that is drawn. This extension allows an external "screen saver"
client to detect when the alternate image is to be displayed and to provide the
graphics.
Current X server implementations typically provide at least one form of
"screen saver" image. Historically, this has been a copy of the X logo
drawn against the root background pattern. However, many users have asked
for the mechanism to allow them to write screen saver programs that provide
capabilities similar to those provided by other window systems. In
particular, such users often wish to be able to display corporate logos,
instructions on how to reactivate the screen, and automatic screen-locking
utilities. This extension provides a means for writing such clients.
Assumptions
This extension exports the notion of a special screen saver window that is
mapped above all other windows on a display. This window has the
override-redirect attribute set so that it is not subject to manipulation by
the window manager. Furthermore, the X identifier for the window is never
returned by QueryTree requests on the root window, so it is typically
not visible to other clients.
Overview
The core
SetScreenSaver
request can be used to set the length of time without
activity on any input devices after which the screen saver should "activate"
and alter the image on the screen. This image periodically "cycles" to
reduce
the length of time that any particular pixel is illuminated. Finally, the
screen saver is "deactivated" in response to activity on any of the input
devices
or particular X requests.
Screen saving is typically done by disabling video output to the display tube
or by drawing a changing pattern onto the display. If the server chooses the
latter approach, a window with a special identifier is created and mapped at
the top of the stacking order where it remains until the screen saver
deactivates. At this time, the window is unmapped and is not accessible to any
client requests.
The server's default mechanism is referred to as the internal screen
saver. An external
screen saver client requires a means of determining the window
id for the screen saver window and setting the attributes (e.g. size,
location, visual, colormap) to be used when the window is mapped. These
requirements form the basis of this extension.
Issues
This extension raises several interesting issues. First is the question of
what should be done if some other client has the server grabbed when the screen
saver is supposed to activate? This commonly occurs with window managers that
automatically ask the user to position a window when it is first mapped by
grabbing the server and drawing XORed lines on the root window.
Second, a screen saver program must control the actual RGB values sent to the
display tube to ensure that the values change periodically to avoid phosphor
burn in. Thus, the client must have a known colormap installed whenever the
screen saver window is displayed. To prevent screen flashing, the visual type
of the screen saver window should also be controllable.
Third, some implementations may wish to destroy the screen saver window when
it is not mapped so that it need not be avoided during event delivery. Thus,
screen saver clients may find that the requests that reference the screen
saver window may fail when the window is not displayed.
Protocol
The Screen Saver extension is as follows:
Types
In addition to the common types described in the core protocol, the following
type is used in the request and event definitions in subsequent sections.
Name
Value
SCREENSAVEREVENT
ScreenSaverNotify ,
ScreenSaverCycle
Errors
The Screen Saver extension adds no errors beyond the core protocol.
Requests
The Screen Saver extension adds the following requests:
ScreenSaverQueryVersion
client-major-version: CARD8
client-minor-version: CARD8
->
server-major-version: CARD8
server-minor-version: CARD8
This request allows the client and server to determine which version of
the protocol should be used. The client sends the version that it
prefers; if the server understands that
version, it returns the same values and interprets subsequent requests
for this extension according to the specified version. Otherwise,
the server returns the closest version of the protocol that it can
support and interprets subsequent requests according to that version.
This document describes major version 1, minor version 0; the major
and minor revision numbers should only be incremented in response to
incompatible and compatible changes, respectively.
ScreenSaverQueryInfo
drawable DRAWABLE
saver-window: WINDOW
state: {Disabled , Off , On }
kind: {Blanked , Internal , External }
til-or-since: CARD32
idle: CARD32
event-mask: SETofSCREENSAVEREVENT
Errors: Drawable
This request returns information about the state of the screen
saver on the screen associated with drawable . The saver-window
is the XID that is associated with the screen saver window. This
window is not guaranteed to exist
except when external screen saver is active. Although it is a
child of the root, this window is not returned by
QueryTree
requests on the root. Whenever this window is mapped, it is always above
any of its siblings in the stacking order. XXX - TranslateCoords?
The state field specifies whether or not the screen saver is currently
active and how the til-or-since value should be interpreted:
Off
The screen is not currently being saved;
til-or-since
specifies the number of milliseconds until the screen saver is expected to
activate.
On
The screen is currently being saved;
til-or-since specifies
the number of milliseconds since the screen saver activated.
Disabled
The screen saver is currently disabled;
til-or-since is zero.
The kind field specifies the mechanism that either is currently being
used or would have been were the screen being saved:
Blanked The video signal to the display monitor was disabled.
Internal A server-dependent, built-in screen saver image was displayed; either no
client had set the screen saver window attributes or a different client
had the server grabbed when the screen saver activated.
External The screen saver window was mapped with attributes set by a
client using the ScreenSaverSetAttributes request.
The idle field specifies the number of milliseconds since the last
input was received from the user on any of the input devices.
The event-mask field specifies which, if any, screen saver
events this client has requested using ScreenSaverSelectInput .
If drawable is not a valid drawable identifier, a Drawable
error is returned and the request is ignored.
ScreenSaverSelectInput
drawable: DRAWABLE
event-mask: SETofSCREENSAVEREVENT
Errors:
Drawable ,
Match
This request specifies which Screen Saver extension events on the screen
associated with drawable should be generated for this client. If
no bits are set in event-mask , then no events will be generated.
Otherwise, any combination of the following bits may be set:
ScreenSaverNotify
If this bit is set, ScreenSaverNotify events are generated whenever
the screen saver is activated or deactivated.
ScreenSaverCycle
If this bit is set, ScreenSaverNotify events are generated whenever
the screen saver cycle interval passes.
If drawable is not a valid drawable identifier, a Drawable
error is returned. If any undefined bits are set in event-mask ,
a Value error is returned. If an error is returned,
the request is ignored.
ScreenSaverSetAttributes
drawable: DRAWABLE
class:
{InputOutput , InputOnly , CopyFromParent }
depth: CARD8
visual: VISUALID or CopyFromParent
x, y: INT16
width, height, border-width: CARD16
value-mask: BITMASK
value-list: LISTofVALUE
Access , Window , Pixmap , Colormap , Cursor , Match , Value , Alloc
This request sets the attributes that this client would like to see
used in creating the screen saver window on the screen associated
with drawable . If another client currently has the attributes set,
an Access error is generated and the request is ignored.
Otherwise, the specified window attributes are checked as if
they were used in a core CreateWindow request whose
parent is the root. The override-redirect field is ignored as
it is implicitly set to True. If the window attributes result in an
error according to the rules for CreateWindow , the request is ignored.
Otherwise, the attributes are stored and will take effect on the next
activation that occurs when the server is not grabbed by another client.
Any resources specified for the
background-pixmap or cursor attributes may be
freed immediately. The server is free to copy the background-pixmap
or cursor resources or to use them in place; therefore, the effect of
changing the contents of those resources is undefined. If the
specified colormap no longer exists when the screen saver activates,
the parent's colormap is used instead. If no errors are generated by this
request, any previous
screen saver window attributes set by this client are released.
When the screen saver next activates and the server is not grabbed by
another client, the screen saver window is
created, if necessary, and set to the specified attributes and events
are generated as usual. The colormap
associated with the screen saver window is
installed. Finally, the screen saver window is mapped.
The window remains mapped and at the top of the stacking order
until the screen saver is deactivated in response to activity on
any of the user input devices, a ForceScreenSaver request with
a value of Reset, or any request that would cause the window to be
unmapped.
If the screen saver activates while the server is grabbed by another
client, the internal saver mechanism is used. The ForceScreenSaver
request may be used with a value of Active to
deactivate the internal saver and activate the external saver.
If the screen saver client's connection to the server is broken
while the screen saver is activated and the client's close down mode has not
been RetainPermanent or RetainTemporary, the current screen saver
is deactivated and the internal screen saver is immediately activated.
When the screen saver deactivates, the screen saver window's colormap
is uninstalled and the window is unmapped (except as described below).
The screen saver XID is disassociated
with the window and the server may, but is not required to,
destroy the window along with any children.
When the screen saver is being deactivated and then immediately
reactivated (such as when switching screen savers), the server
may leave the screen saver window mapped (typically to avoid
generating exposures).
ScreenSaverUnsetAttributes
drawble : DRAWABLE
Errors: Drawable
This request notifies the server that this client no longer
wishes to control the screen saver window. Any screen saver
attributes set by this client and any descendents of the screen
saver window created by this client should be released
immediately if the screen saver is not active, else upon
deactivation.
This request is ignored if the client has not previously set the screen saver
window attributes.
Events
The Screen Saver extension adds one event:
ScreenSaverNotify
root : WINDOW
window : WINDOW
state : {Off , On , Cycle }
kind : { Blanked , Internal , External }
forced : BOOL
time : TIMESTAMP
This event is delivered to clients that have requested
ScreenSaverNotify events using the ScreenSaverSelectInput request
whenever the screen saver activates or deactivates.
The root field specifies root window of the screen for
which the event was generated. The window field specifies
the value that is returned by ScreenSaverQueryInfo as
the identifier for the screen saver window. This window is not
required to exist if the external screen saver is not active.
The state field specifies the cause of the event:
Off
The screen saver deactivated; this event is sent if the client has set the
ScreenSaverNotify bit in its event mask.
On
The screen saver activated. This event is sent if the client has set the
ScreenSaverNotify bit in its event mask.
Cycle
The cycle interval passed and the client is expected to change the image on
the screen. This event is sent if the client has set the
ScreenSaverCycle bit in its event mask.
If state is set to
On or
Off
then forced indicates whether or not
activation or deactivation was caused by a core
ForceScreenSaver
request; otherwise, forced is set to False.
The kind field specifies mechanism that was used to save the screen
when the screen saver was activated, as described in
ScreenSaverQueryInfo .
The time field indicates the server time
when the event was generated.
Encoding
Please refer to the X11 Protocol Encoding document as this document uses
conventions established there.
The name of this extension is "SCREEN-SAVER".
Common Types
SETofSCREENSAVEREVENT
#x00000001 ScreenSaverNotifyMask
#x00000002 ScreenSaverCycleMask
Requests
ScreenSaverQueryVersion
1 CARD8 screen saver opcode
1 0 minor opcode
2 2 request length
1 CARD8 client major version
1 CARD8 client minor version
2 unused
->
1 1 Reply
1 unused
2 CARD16 sequence number
4 0 reply length
1 CARD8 server major version
1 CARD8 server minor version
22 unused
ScreenSaverQueryInfo
1 CARD8 screen saver opcode
1 1 minor opcode
2 2 request length
4 DRAWABLE drawable associated with screen
->
1 1 Reply
1 CARD8 state
0 Off
1 On
3 Disabled
2 CARD16 sequence number
4 0 reply length
4 WINDOW saver window
4 CARD32 milliseconds until saver or since saver
4 CARD32 milliseconds since last user device input
4 SETofSCREENSAVEREVENT event mask
1 CARD8 kind
0 Blanked
1 Internal
2 External
10 unused
ScreenSaverSelectInput
1 CARD8 screen saver opcode
1 2 minor opcode
2 3 request length
4 DRAWABLE drawable associated with screen
4 SETofSCREENSAVEREVENT event mask
ScreenSaverSetAttributes
1 CARD8 screen saver opcode
1 3 minor opcode
2 6+n request length
4 DRAWABLE drawable associated with screen
2 INT16 x
2 INT16 y
2 CARD16 width
2 CARD16 height
2 CARD16 border-width
1 class
0 CopyFromParent
1 InputOutput
2 InputOnly
1 CARD8 depth
4 VISUALID visual
0 CopyFromParent
4 BITMASK value-mask (has n bits set to 1)
encodings are the same as for core CreateWindow
4n LISTofVALUE value-list
encodings are the same as for core CreateWindow
ScreenSaverUnsetAttributes
1 CARD8 screen saver opcode
1 4 minor opcode
2 3 request length
4 DRAWABLE drawable associated with screen
Events
ScreenSaverNotify
1 CARD8 code assigned by core
1 CARD8 state
0 Off
1 On
2 Cycle
2 CARD16 sequence number
4 TIMESTAMP time
4 WINDOW root
4 WINDOW screen saver window
1 CARD8 kind
0 Blanked
1 Internal
2 External
1 BOOL forced
14 unused
Inter-Client Communications Conventions
Screen saver clients should create at least one resource value whose
identifier can be stored in a property named
_SCREEN_SAVER_ID
on the root of each screen it is managing.
This property should have one 32-bit value corresponding to the resource
identifier; the type of the property should indicate the type of the
resource and should be one of the following:
WINDOW ,
PIXMAP ,
CURSOR ,
FONT , or
COLORMAP .
C language binding
The C binding for this extension simply provide access to the protocol; they
add no semantics beyond what is described above.
The include file for this extension is
<X11/extensions/scrnsaver.h> .
Bool XScreenSaverQueryExtension
Display *display
int *event_base
int *error_base
This routine returns
True
if the specified display supports the
SCREEN-SAVER extension; otherwise it returns
False .
If the extension is supported, the event number for
ScreenSaverNotify
events is returned in the value pointed to by
event_base . Since
no additional errors are defined by this extension, the results
of error_base are not defined.
Status XScreenSaverQueryVersion
Display *display
int *major
int *minor
If the specified display supports the
extension, the version numbers of the protocol
expected by the server are returned in
major and
minor and
a non-zero value is returned. Otherwise, the arguments are not
set and 0 is returned.
XScreenSaverInfo *
XScreenSaverAllocInfo()
This routine allocates and returns an
XScreenSaverInfo structure
for use in calls to XFree
Status XScreenSaverQueryInfo
Display *display
Drawable drawable
XScreenSaverInfo *saver_info
If the specified display supports the extension,
information about the current state of the
screen server is returned in saver_info and a non-zero value is
returned. The XScreenSaverInfo structure is
defined as follows:
typedef struct {
Window window; /* screen saver window */
int state; /* ScreenSaver{Off,On,Disabled} */
int kind; /* ScreenSaver{Blanked,Internal,External} */
unsigned long til_or_since; /* milliseconds */
unsigned long idle; /* milliseconds */
unsigned long event_mask; /* events */
} XScreenSaverInfo;
See the ScreenSaverQueryInfo request for a
description of the fields. If the extension is not supported,
saver_info is not changed and 0
is returned.
void XScreenSaverSelectInput
Display *display
Drawable drawable
unsigned long event_mask
If the specified display supports the extension,
this routine asks that events related to
the screen saver be generated for this client.
The format of the events generated is:
typedef struct {
int type; /* of event */
unsigned long serial; /* # of last request processed by server */
Bool send_event; /* true if this came from a SendEvent request */
Display *display; /* Display the event was read from */
Window window; /* screen saver window */
Window root; /* root window of event screen */
int state; /* ScreenSaver{Off,On,Cycle} */
int kind; /* ScreenSaver{Blanked,Internal,External} */
Bool forced; /* extents of new region */
Time time; /* event timestamp */
} XScreenSaverNotifyEvent;
See the definition of the
ScreenSaverSelectInput request for descriptions
of the allowed event masks.
void XScreenSaverSetAttributes
Display *dpy
Drawable drawable
int x
int y
unsigned int width
unsigned int height
unsigned int border_width
int depth
unsigned int class
Visual *visual
unsigned long valuemask
XSetWindowAttributes *attributes
If the specified display supports the
extension, this routine sets the attributes to be used
the next time the external screen saver is activated. See the definition
of the ScreenSaverSetAttributes request for a
description of each of the arguments.
void XScreenSaverUnsetAttributes
Display *display
Drawable drawable
If the specified display supports the
extension, this routine instructs the server to discard
any previous screen saver window attributes set by this client.
Status XScreenSaverRegister
Display *display
int screen
XID xid
Atom type
This routine stores the given XID in the
_SCREEN_SAVER_ID property (of the given
type ) on the root window of the specified
screen . It returns zero if an error
is encountered and the property is not changed, otherwise it returns
non-zero.
Status XScreenSaverUnregister
Display *display
int screen
This routine removes any _SCREEN_SAVER_ID from the
root window of the specified screen .
It returns zero if an error is encountered and the property is changed,
otherwise it returns non-zero.
Status XScreenSaverGetRegistered
Display *display
int screen
XID *xid
ATOM *type
This routine returns the
XID and
type stored in the
_SCREEN_SAVER_ID property on the
root window of the specified screen .
It returns zero if an error
is encountered or if the property does not exist or is not of the correct
format; otherwise it returns non-zero.
xorgproto-2023.2/specs/scrnsaverproto/Makefile.am 0000644 0001750 0001750 00000000511 14443010026 017020 0000000 0000000
if ENABLE_SPECS
# Main DocBook/XML files (DOCTYPE book)
docbook = saver.xml
# The location where the DocBook/XML files and their generated formats are installed
shelfdir = $(datarootdir)/doc/scrnsaverproto
# Generate DocBook/XML output formats with or without stylesheets
include $(top_srcdir)/docbook.am
endif ENABLE_SPECS
xorgproto-2023.2/specs/scrnsaverproto/Makefile.in 0000644 0001750 0001750 00000055457 14443010031 017050 0000000 0000000 # Makefile.in generated by automake 1.16.5 from Makefile.am.
# @configure_input@
# Copyright (C) 1994-2021 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
@SET_MAKE@
#
# Generate output formats for a single DocBook/XML with/without chapters
#
# Variables set by the calling Makefile:
# shelfdir: the location where the docs/specs are installed. Typically $(docdir)
# docbook: the main DocBook/XML file, no chapters, appendix or image files
# chapters: all files pulled in by an XInclude statement and images.
#
#
# This makefile is intended for Users Documentation and Functional Specifications.
# Do not use for Developer Documentation which is not installed and does not require olink.
# Refer to http://www.x.org/releases/X11R7.6/doc/xorg-docs/ReleaseNotes.html#id2584393
# for an explanation on documents classification.
#
VPATH = @srcdir@
am__is_gnu_make = { \
if test -z '$(MAKELEVEL)'; then \
false; \
elif test -n '$(MAKE_HOST)'; then \
true; \
elif test -n '$(MAKE_VERSION)' && test -n '$(CURDIR)'; then \
true; \
else \
false; \
fi; \
}
am__make_running_with_option = \
case $${target_option-} in \
?) ;; \
*) echo "am__make_running_with_option: internal error: invalid" \
"target option '$${target_option-}' specified" >&2; \
exit 1;; \
esac; \
has_opt=no; \
sane_makeflags=$$MAKEFLAGS; \
if $(am__is_gnu_make); then \
sane_makeflags=$$MFLAGS; \
else \
case $$MAKEFLAGS in \
*\\[\ \ ]*) \
bs=\\; \
sane_makeflags=`printf '%s\n' "$$MAKEFLAGS" \
| sed "s/$$bs$$bs[$$bs $$bs ]*//g"`;; \
esac; \
fi; \
skip_next=no; \
strip_trailopt () \
{ \
flg=`printf '%s\n' "$$flg" | sed "s/$$1.*$$//"`; \
}; \
for flg in $$sane_makeflags; do \
test $$skip_next = yes && { skip_next=no; continue; }; \
case $$flg in \
*=*|--*) continue;; \
-*I) strip_trailopt 'I'; skip_next=yes;; \
-*I?*) strip_trailopt 'I';; \
-*O) strip_trailopt 'O'; skip_next=yes;; \
-*O?*) strip_trailopt 'O';; \
-*l) strip_trailopt 'l'; skip_next=yes;; \
-*l?*) strip_trailopt 'l';; \
-[dEDm]) skip_next=yes;; \
-[JT]) skip_next=yes;; \
esac; \
case $$flg in \
*$$target_option*) has_opt=yes; break;; \
esac; \
done; \
test $$has_opt = yes
am__make_dryrun = (target_option=n; $(am__make_running_with_option))
am__make_keepgoing = (target_option=k; $(am__make_running_with_option))
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
pkglibexecdir = $(libexecdir)/@PACKAGE@
am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
INSTALL_HEADER = $(INSTALL_DATA)
transform = $(program_transform_name)
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
build_triplet = @build@
host_triplet = @host@
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_1 = $(docbook:.xml=.html)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@am__append_2 = $(docbook:.xml=.txt)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@am__append_3 = $(docbook:.xml=.pdf) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(docbook:.xml=.ps)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@am__append_4 = $(docbook:.xml=.html.db) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(docbook:.xml=.pdf.db)
subdir = specs/scrnsaverproto
ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
am__aclocal_m4_deps = $(top_srcdir)/configure.ac
am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
$(ACLOCAL_M4)
DIST_COMMON = $(srcdir)/Makefile.am $(am__dist_shelf_DATA_DIST) \
$(am__DIST_COMMON)
mkinstalldirs = $(install_sh) -d
CONFIG_CLEAN_FILES =
CONFIG_CLEAN_VPATH_FILES =
AM_V_P = $(am__v_P_@AM_V@)
am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
am__v_P_0 = false
am__v_P_1 = :
AM_V_GEN = $(am__v_GEN_@AM_V@)
am__v_GEN_ = $(am__v_GEN_@AM_DEFAULT_V@)
am__v_GEN_0 = @echo " GEN " $@;
am__v_GEN_1 =
AM_V_at = $(am__v_at_@AM_V@)
am__v_at_ = $(am__v_at_@AM_DEFAULT_V@)
am__v_at_0 = @
am__v_at_1 =
SOURCES =
DIST_SOURCES =
am__can_run_installinfo = \
case $$AM_UPDATE_INFO_DIR in \
n|no|NO) false;; \
*) (install-info --version) >/dev/null 2>&1;; \
esac
am__dist_shelf_DATA_DIST = saver.xml
am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
am__vpath_adj = case $$p in \
$(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
*) f=$$p;; \
esac;
am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`;
am__install_max = 40
am__nobase_strip_setup = \
srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'`
am__nobase_strip = \
for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||"
am__nobase_list = $(am__nobase_strip_setup); \
for p in $$list; do echo "$$p $$p"; done | \
sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \
$(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \
if (++n[$$2] == $(am__install_max)) \
{ print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \
END { for (dir in files) print dir, files[dir] }'
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
am__uninstall_files_from_dir = { \
test -z "$$files" \
|| { test ! -d "$$dir" && test ! -f "$$dir" && test ! -r "$$dir"; } \
|| { echo " ( cd '$$dir' && rm -f" $$files ")"; \
$(am__cd) "$$dir" && rm -f $$files; }; \
}
am__installdirs = "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"
DATA = $(dist_shelf_DATA) $(shelf_DATA)
am__tagged_files = $(HEADERS) $(SOURCES) $(TAGS_FILES) $(LISP)
am__DIST_COMMON = $(srcdir)/Makefile.in $(top_srcdir)/docbook.am
DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST)
ACLOCAL = @ACLOCAL@
ADMIN_MAN_DIR = @ADMIN_MAN_DIR@
ADMIN_MAN_SUFFIX = @ADMIN_MAN_SUFFIX@
AMTAR = @AMTAR@
AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@
APP_MAN_DIR = @APP_MAN_DIR@
APP_MAN_SUFFIX = @APP_MAN_SUFFIX@
AUTOCONF = @AUTOCONF@
AUTOHEADER = @AUTOHEADER@
AUTOMAKE = @AUTOMAKE@
AWK = @AWK@
BASE_CFLAGS = @BASE_CFLAGS@
CC = @CC@
CCDEPMODE = @CCDEPMODE@
CFLAGS = @CFLAGS@
CHANGELOG_CMD = @CHANGELOG_CMD@
CPPFLAGS = @CPPFLAGS@
CSCOPE = @CSCOPE@
CTAGS = @CTAGS@
CWARNFLAGS = @CWARNFLAGS@
CYGPATH_W = @CYGPATH_W@
DEFS = @DEFS@
DEPDIR = @DEPDIR@
DRIVER_MAN_DIR = @DRIVER_MAN_DIR@
DRIVER_MAN_SUFFIX = @DRIVER_MAN_SUFFIX@
ECHO_C = @ECHO_C@
ECHO_N = @ECHO_N@
ECHO_T = @ECHO_T@
ETAGS = @ETAGS@
EXEEXT = @EXEEXT@
FILE_MAN_DIR = @FILE_MAN_DIR@
FILE_MAN_SUFFIX = @FILE_MAN_SUFFIX@
FOP = @FOP@
INSTALL = @INSTALL@
INSTALL_CMD = @INSTALL_CMD@
INSTALL_DATA = @INSTALL_DATA@
INSTALL_PROGRAM = @INSTALL_PROGRAM@
INSTALL_SCRIPT = @INSTALL_SCRIPT@
INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
LDFLAGS = @LDFLAGS@
LIBOBJS = @LIBOBJS@
LIBS = @LIBS@
LIB_MAN_DIR = @LIB_MAN_DIR@
LIB_MAN_SUFFIX = @LIB_MAN_SUFFIX@
LTLIBOBJS = @LTLIBOBJS@
MAKEINFO = @MAKEINFO@
MAN_SUBSTS = @MAN_SUBSTS@
MISC_MAN_DIR = @MISC_MAN_DIR@
MISC_MAN_SUFFIX = @MISC_MAN_SUFFIX@
MKDIR_P = @MKDIR_P@
OBJEXT = @OBJEXT@
PACKAGE = @PACKAGE@
PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
PACKAGE_NAME = @PACKAGE_NAME@
PACKAGE_STRING = @PACKAGE_STRING@
PACKAGE_TARNAME = @PACKAGE_TARNAME@
PACKAGE_URL = @PACKAGE_URL@
PACKAGE_VERSION = @PACKAGE_VERSION@
PATH_SEPARATOR = @PATH_SEPARATOR@
PKG_CONFIG = @PKG_CONFIG@
PKG_CONFIG_LIBDIR = @PKG_CONFIG_LIBDIR@
PKG_CONFIG_PATH = @PKG_CONFIG_PATH@
PYTHON = @PYTHON@
PYTHON_EXEC_PREFIX = @PYTHON_EXEC_PREFIX@
PYTHON_PLATFORM = @PYTHON_PLATFORM@
PYTHON_PREFIX = @PYTHON_PREFIX@
PYTHON_VERSION = @PYTHON_VERSION@
SED = @SED@
SET_MAKE = @SET_MAKE@
SHELL = @SHELL@
STRICT_CFLAGS = @STRICT_CFLAGS@
STRIP = @STRIP@
STYLESHEET_SRCDIR = @STYLESHEET_SRCDIR@
USE_FDS_BITS = @USE_FDS_BITS@
VERSION = @VERSION@
XMLTO = @XMLTO@
XORG_MAN_PAGE = @XORG_MAN_PAGE@
XORG_SGML_PATH = @XORG_SGML_PATH@
XSLTPROC = @XSLTPROC@
XSL_STYLESHEET = @XSL_STYLESHEET@
abs_builddir = @abs_builddir@
abs_srcdir = @abs_srcdir@
abs_top_builddir = @abs_top_builddir@
abs_top_srcdir = @abs_top_srcdir@
ac_ct_CC = @ac_ct_CC@
am__include = @am__include@
am__leading_dot = @am__leading_dot@
am__quote = @am__quote@
am__tar = @am__tar@
am__untar = @am__untar@
bindir = @bindir@
build = @build@
build_alias = @build_alias@
build_cpu = @build_cpu@
build_os = @build_os@
build_vendor = @build_vendor@
builddir = @builddir@
datadir = @datadir@
datarootdir = @datarootdir@
docdir = @docdir@
dvidir = @dvidir@
exec_prefix = @exec_prefix@
host = @host@
host_alias = @host_alias@
host_cpu = @host_cpu@
host_os = @host_os@
host_vendor = @host_vendor@
htmldir = @htmldir@
includedir = @includedir@
infodir = @infodir@
install_sh = @install_sh@
libdir = @libdir@
libexecdir = @libexecdir@
localedir = @localedir@
localstatedir = @localstatedir@
mandir = @mandir@
mkdir_p = @mkdir_p@
oldincludedir = @oldincludedir@
pdfdir = @pdfdir@
pkgpyexecdir = @pkgpyexecdir@
pkgpythondir = @pkgpythondir@
prefix = @prefix@
program_transform_name = @program_transform_name@
psdir = @psdir@
pyexecdir = @pyexecdir@
pythondir = @pythondir@
runstatedir = @runstatedir@
sbindir = @sbindir@
sharedstatedir = @sharedstatedir@
srcdir = @srcdir@
sysconfdir = @sysconfdir@
target_alias = @target_alias@
top_build_prefix = @top_build_prefix@
top_builddir = @top_builddir@
top_srcdir = @top_srcdir@
# Main DocBook/XML files (DOCTYPE book)
@ENABLE_SPECS_TRUE@docbook = saver.xml
# The location where the DocBook/XML files and their generated formats are installed
@ENABLE_SPECS_TRUE@shelfdir = $(datarootdir)/doc/scrnsaverproto
# DocBook/XML generated output formats to be installed
@ENABLE_SPECS_TRUE@shelf_DATA = $(am__append_1) $(am__append_2) \
@ENABLE_SPECS_TRUE@ $(am__append_3) $(am__append_4)
# DocBook/XML file with chapters, appendix and images it includes
@ENABLE_SPECS_TRUE@dist_shelf_DATA = $(docbook) $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --searchpath "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.html.xml \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_HTML_OLINK_FLAGS)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_IMAGEPATH_FLAGS = --stringparam img.src.path=$(abs_builddir)/
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_PDF_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam target.database.document=$(XORG_SGML_PATH)/X11/dbs/masterdb.pdf.xml \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ --stringparam current.docid="$(<:.xml=)"
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_STYLESHEET_FLAGS = -x $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@XMLTO_FO_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_STYLESHEET_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_FO_IMAGEPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(XMLTO_PDF_OLINK_FLAGS)
# Generate documents cross-reference target databases
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_SEARCHPATH_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(XORG_SGML_PATH)/X11" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --path "$(abs_top_builddir)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_OLINK_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam targets.filename "$@" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam collect.xref.targets "only" \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --stringparam olink.base.uri "$(@:.db=)"
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_HTML_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-xhtml.xsl
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@XSLT_PDF_FLAGS = \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_SEARCHPATH_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(XSLT_OLINK_FLAGS) \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ --nonet --xinclude \
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(STYLESHEET_SRCDIR)/xorg-fo.xsl
@ENABLE_SPECS_TRUE@CLEANFILES = $(shelf_DATA)
all: all-am
.SUFFIXES:
$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(top_srcdir)/docbook.am $(am__configure_deps)
@for dep in $?; do \
case '$(am__configure_deps)' in \
*$$dep*) \
( cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh ) \
&& { if test -f $@; then exit 0; else break; fi; }; \
exit 1;; \
esac; \
done; \
echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign specs/scrnsaverproto/Makefile'; \
$(am__cd) $(top_srcdir) && \
$(AUTOMAKE) --foreign specs/scrnsaverproto/Makefile
Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
@case '$?' in \
*config.status*) \
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
*) \
echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles)'; \
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__maybe_remake_depfiles);; \
esac;
$(top_srcdir)/docbook.am $(am__empty):
$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(top_srcdir)/configure: $(am__configure_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(ACLOCAL_M4): $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
$(am__aclocal_m4_deps):
install-dist_shelfDATA: $(dist_shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-dist_shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(dist_shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
install-shelfDATA: $(shelf_DATA)
@$(NORMAL_INSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
if test -n "$$list"; then \
echo " $(MKDIR_P) '$(DESTDIR)$(shelfdir)'"; \
$(MKDIR_P) "$(DESTDIR)$(shelfdir)" || exit 1; \
fi; \
for p in $$list; do \
if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
echo "$$d$$p"; \
done | $(am__base_list) | \
while read files; do \
echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(shelfdir)'"; \
$(INSTALL_DATA) $$files "$(DESTDIR)$(shelfdir)" || exit $$?; \
done
uninstall-shelfDATA:
@$(NORMAL_UNINSTALL)
@list='$(shelf_DATA)'; test -n "$(shelfdir)" || list=; \
files=`for p in $$list; do echo $$p; done | sed -e 's|^.*/||'`; \
dir='$(DESTDIR)$(shelfdir)'; $(am__uninstall_files_from_dir)
tags TAGS:
ctags CTAGS:
cscope cscopelist:
distdir: $(BUILT_SOURCES)
$(MAKE) $(AM_MAKEFLAGS) distdir-am
distdir-am: $(DISTFILES)
@srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
topsrcdirstrip=`echo "$(top_srcdir)" | sed 's/[].[^$$\\*]/\\\\&/g'`; \
list='$(DISTFILES)'; \
dist_files=`for file in $$list; do echo $$file; done | \
sed -e "s|^$$srcdirstrip/||;t" \
-e "s|^$$topsrcdirstrip/|$(top_builddir)/|;t"`; \
case $$dist_files in \
*/*) $(MKDIR_P) `echo "$$dist_files" | \
sed '/\//!d;s|^|$(distdir)/|;s,/[^/]*$$,,' | \
sort -u` ;; \
esac; \
for file in $$dist_files; do \
if test -f $$file || test -d $$file; then d=.; else d=$(srcdir); fi; \
if test -d $$d/$$file; then \
dir=`echo "/$$file" | sed -e 's,/[^/]*$$,,'`; \
if test -d "$(distdir)/$$file"; then \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
if test -d $(srcdir)/$$file && test $$d != $(srcdir); then \
cp -fpR $(srcdir)/$$file "$(distdir)$$dir" || exit 1; \
find "$(distdir)/$$file" -type d ! -perm -700 -exec chmod u+rwx {} \;; \
fi; \
cp -fpR $$d/$$file "$(distdir)$$dir" || exit 1; \
else \
test -f "$(distdir)/$$file" \
|| cp -p $$d/$$file "$(distdir)/$$file" \
|| exit 1; \
fi; \
done
check-am: all-am
check: check-am
all-am: Makefile $(DATA)
installdirs:
for dir in "$(DESTDIR)$(shelfdir)" "$(DESTDIR)$(shelfdir)"; do \
test -z "$$dir" || $(MKDIR_P) "$$dir"; \
done
install: install-am
install-exec: install-exec-am
install-data: install-data-am
uninstall: uninstall-am
install-am: all-am
@$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
installcheck: installcheck-am
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
mostlyclean-generic:
clean-generic:
-test -z "$(CLEANFILES)" || rm -f $(CLEANFILES)
distclean-generic:
-test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
-test . = "$(srcdir)" || test -z "$(CONFIG_CLEAN_VPATH_FILES)" || rm -f $(CONFIG_CLEAN_VPATH_FILES)
maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
@echo "it deletes files that may require special tools to rebuild."
clean: clean-am
clean-am: clean-generic mostlyclean-am
distclean: distclean-am
-rm -f Makefile
distclean-am: clean-am distclean-generic
dvi: dvi-am
dvi-am:
html: html-am
html-am:
info: info-am
info-am:
install-data-am: install-dist_shelfDATA install-shelfDATA
install-dvi: install-dvi-am
install-dvi-am:
install-exec-am:
install-html: install-html-am
install-html-am:
install-info: install-info-am
install-info-am:
install-man:
install-pdf: install-pdf-am
install-pdf-am:
install-ps: install-ps-am
install-ps-am:
installcheck-am:
maintainer-clean: maintainer-clean-am
-rm -f Makefile
maintainer-clean-am: distclean-am maintainer-clean-generic
mostlyclean: mostlyclean-am
mostlyclean-am: mostlyclean-generic
pdf: pdf-am
pdf-am:
ps: ps-am
ps-am:
uninstall-am: uninstall-dist_shelfDATA uninstall-shelfDATA
.MAKE: install-am install-strip
.PHONY: all all-am check check-am clean clean-generic cscopelist-am \
ctags-am distclean distclean-generic distdir dvi dvi-am html \
html-am info info-am install install-am install-data \
install-data-am install-dist_shelfDATA install-dvi \
install-dvi-am install-exec install-exec-am install-html \
install-html-am install-info install-info-am install-man \
install-pdf install-pdf-am install-ps install-ps-am \
install-shelfDATA install-strip installcheck installcheck-am \
installdirs maintainer-clean maintainer-clean-generic \
mostlyclean mostlyclean-generic pdf pdf-am ps ps-am tags-am \
uninstall uninstall-am uninstall-dist_shelfDATA \
uninstall-shelfDATA
.PRECIOUS: Makefile
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.html: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) xhtml-nochunks $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@%.txt: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TEXT_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_HTML_FLAGS) txt $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.pdf: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop pdf $<
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@%.ps: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_FOP_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@ $(AM_V_GEN)$(XMLTO) $(XMLTO_FO_FLAGS) --with-fop ps $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.html.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_HTML_FLAGS) $<
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@%.pdf.db: %.xml $(chapters)
@ENABLE_SPECS_TRUE@@HAVE_STYLESHEETS_TRUE@@HAVE_XMLTO_TRUE@@HAVE_XSLTPROC_TRUE@ $(AM_V_GEN)$(XSLTPROC) $(XSLT_PDF_FLAGS) $<
# Generate DocBook/XML output formats with or without stylesheets
# Tell versions [3.59,3.63) of GNU make to not export all variables.
# Otherwise a system limit (for SysV at least) may be exceeded.
.NOEXPORT:
xorgproto-2023.2/specs/SIAddresses/ 0000755 0001750 0001750 00000000000 14443010036 014127 5 0000000 0000000 xorgproto-2023.2/specs/SIAddresses/IPv6.md 0000644 0001750 0001750 00000001025 14443010026 015152 0000000 0000000 ## ServerInterpreted address definition for type "IPv6"
The X.org Architecture Task Force reserves the ServerInterpreted
address type of "IPv6" for use with IPv6 literal address formats.
The syntax for the value will be defined as specified in RFC 3513
and the IETF RFC to be published based on the [current draft](http://www.ietf.org/internet-drafts/draft-ietf-ipv6-scoping-arch-00.txt).
This address type specification will be formally issued once the
IETF IPv6 Working Group issues the corresponding RFC.
Version 0.9, March 2004 xorgproto-2023.2/specs/SIAddresses/localuser.md 0000644 0001750 0001750 00000001623 14443010026 016363 0000000 0000000 ## Server-interpreted Authentication Types "localuser" and "localgroup"
On systems which can determine in a secure fashion the credentials of a client
process, the "localuser" and "localgroup" authentication methods provide access
based on those credentials. The format of the values provided is platform
specific. For POSIX & UNIX platforms, if the value starts with the character
'#', the rest of the string shall be treated as a decimal uid or gid, otherwise
the string is defined as a user name or group name.
Systems offering this MUST not simply trust a user supplied value (such as an
environment variable or IDENT protocol response). It is expected many systems
will only support this for clients running on the same host using a local IPC
transport.
Examples:
```
xhost +SI:localuser:alanc
```
```
xhost +SI:localuser:#1234
```
```
xhost +SI:localgroup:wheel
```
```
xhost +SI:localgroup:#0
```
xorgproto-2023.2/specs/SIAddresses/hostname.md 0000644 0001750 0001750 00000001130 14443010026 016201 0000000 0000000 ## ServerInterpreted address definition for type "hostname"
A ServerInterpreted address with type "hostname" shall have a value
representing a hostname as defined in [IETF RFC 2396](https://tools.ietf.org/html/rfc2396). Due to Mobile IP
and dynamic DNS, the name service should be consulted at connection
authentication time. Clients supporting Internationalized Domain
Names must convert to ASCII Compatible Encoding as specified in the
relevant IETF RFC's before use in the X11 protocol. Note that this
definition of hostname does not allow use of literal IP addresses.
Version 1.0, March 2004
xorgproto-2023.2/specs/SIAddresses/README 0000644 0001750 0001750 00000000346 14443010026 014731 0000000 0000000 This directory contains the specifications of address types for the
ServerInterpreted address family used in the ChangeHost and ListHosts
requests in the X11 Protocol. See Chapter 9 of the X11 Protocol spec
for more information.
xorgproto-2023.2/specs/Makefile.am 0000644 0001750 0001750 00000000715 14443010026 013734 0000000 0000000 SUBDIRS = \
bigreqsproto \
fontsproto \
kbproto \
recordproto \
scrnsaverproto \
xcmiscproto \
xextproto \
xproto
EXTRA_DIST = \
printproto/xp_proto.book \
printproto/xp_proto.mif \
printproto/xp_proto.ps \
printproto/xp_protoIX.doc \
printproto/xp_protoTOC.doc \
printproto/xp_proto_cov.mif \
SIAddresses/hostname.md \
SIAddresses/IPv6.md \
SIAddresses/localuser.md \
SIAddresses/README
xorgproto-2023.2/specs/printproto/ 0000755 0001750 0001750 00000000000 14443010036 014176 5 0000000 0000000 xorgproto-2023.2/specs/printproto/xp_proto.mif 0000644 0001750 0001750 00006176503 14443010026 016506 0000000 0000000 # Generated by FrameMaker xm5.0P3f
# Options:
# Paragraph Text
# Paragraph Tags
# Paragraph Formats
# Font Information
# Markers
# Anchored Frames
# Tables
# Graphics and TextRect Layout
# Master Page Items
# Condition Catalog
# Table Catalogs
# Font Catalog
# Paragraph Catalog
# Document Template
# Document Dictionary
# Variables
#
> # end of Color
> # end of Color
> # end of Color
> # end of Color
> # end of Color
> # end of Color
> # end of Color
> # end of Color
> # end of Color
> # end of Color
> # end of ColorCatalog
> # end of Condition
> # end of Condition
> # end of Condition
> # end of ConditionCatalog
> # end of PgfFont
> # end of TabStop
> # end of TabStop
> # end of TabStop
> # end of Pgf
> # end of PgfFont
\\t'>
> # end of TabStop
> # end of Pgf