Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://crydee.sai.msu.ru/ftproot/pub/comp/os/os2/xfree86os2/docs/Xprotocol.PS.gz Äàòà èçìåíåíèÿ: Thu Apr 13 00:00:00 2000 Äàòà èíäåêñèðîâàíèÿ: Mon Dec 24 11:43:15 2007 Êîäèðîâêà: IBM-866 Ïîèñêîâûå ñëîâà: î íí

íí íí
X Window System Protocol
X Consortium Standard
X Version 11, Release 6.4
Robert W. Scheifler
X Consortium, Inc.

íí íí
X Window System is a trademark of X Consortium, Inc.
Copyright é 1986, 1987, 1988, 1994 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentaí
tion 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 Softí
ware.
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 PARTICí
ULAR 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 OTHí
ERWISE, 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 proí
mote the sale, use or other dealings in this Software without prior written authorization from the X Consortium.

íí íí
Acknowledgments
The primary contributers 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 underí
stand the protocol or to place it in perspective within a complete system.
The protocol contains many management mechanisms that are not intended for normal applicaí
tions. 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.

íí íí
1. Protocol Formats
Request Format
Every request contains an 8íbit major opcode and a 16íbit length field expressed in units of four
bytes. Every request consists of four bytes of a header (containing the major opcode, the length
field, and a data byte) followed by zero or more additional bytes of data. The length field defines
the total length of the request, including the header. The length field in a request must equal the
minimum length required to contain the request. If the specified length is smaller or larger than
the required length, an error is generated. Unused bytes in a request are not required to be zero.
Major opcodes 128 through 255 are reserved for extensions. Extensions are intended to contain
multiple requests, so extension requests typically have an additional minor opcode encoded in the
second data byte in the request header. However, the placement and interpretation of this minor
opcode and of all other fields in extension requests are not defined by the core protocol. Every
request on a given connection is implicitly assigned a sequence number, starting with one, that is
used in replies, errors, and events.
Reply Format
Every reply contains a 32íbit length field expressed in units of four bytes. Every reply consists of
32 bytes followed by zero or more additional bytes of data, as specified in the length field.
Unused bytes within a reply are not guaranteed to be zero. Every reply also contains the least sigí
nificant 16 bits of the sequence number of the corresponding request.
Error Format
Error reports are 32 bytes long. Every error includes an 8íbit error code. Error codes 128
through 255 are reserved for extensions. Every error also includes the major and minor opcodes
of the failed request and the least significant 16 bits of the sequence number of the request. For
the following errors (see section 4), the failing resource ID is also returned: Colormap , Cursor ,
Drawable , Font , GContext , IDChoice , Pixmap , and Window . For Atom errors, the failing
atom is returned. For Value errors, the failing value is returned. Other core errors return no addií
tional data. Unused bytes within an error are not guaranteed to be zero.
Event Format
Events are 32 bytes long. Unused bytes within an event are not guaranteed to be zero. Every
event contains an 8íbit type code. The most significant bit in this code is set if the event was gení
erated from a SendEvent request. Event codes 64 through 127 are reserved for extensions,
although the core protocol does not define a mechanism for selecting interest in such events.
Every core event (with the exception of KeymapNotify) also contains the least significant 16 bits
of the sequence number of the last request issued by the client that was (or is currently being) proí
cessed by the server.
2. 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 section 9 are described in the following format:
RequestName
arg1 : type1
...
argN: typeN
î
1

íí íí
X Protocol X11, Release 6.4
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 generí
ated for a single request.
. Events in section 11 are described in the following format:
EventName
value1: type1
...
valueN: typeN
Description.
3. Common Types
Name Value
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.
BITMASK
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 arguí
ments 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.
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.
WINDOW 32íbit value (top three bits guaranteed to be zero)
PIXMAP 32íbit value (top three bits guaranteed to be zero)
CURSOR 32íbit value (top three bits guaranteed to be zero)
FONT 32íbit value (top three bits guaranteed to be zero)
GCONTEXT 32íbit value (top three bits guaranteed to be zero)
COLORMAP 32íbit value (top three bits guaranteed to be zero)
2

íí íí
X Protocol X11, Release 6.4
Name Value
DRAWABLE WINDOW or PIXMAP
FONTABLE FONT or GCONTEXT
ATOM 32íbit value (top three bits guaranteed to be zero)
VISUALID 32íbit value (top three bits guaranteed to be zero)
VALUE 32íbit quantity (used only in LISTofVALUE)
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 {Forget , Static , NorthWest , North , NorthEast , West , Center ,
East , SouthWest , South , SouthEast}
WINGRAVITY {Unmap , Static , NorthWest , North , NorthEast , West , Center ,
East , SouthWest , South , SouthEast}
BOOL {True , False}
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}
POINTEREVENT {ButtonPress , ButtonRelease , EnterWindow , LeaveWindow ,
PointerMotion , PointerMotionHint , Button1Motion ,
Button2Motion , Button3Motion , Button4Motion , Button5Motion ,
ButtonMotion , KeymapState}
DEVICEEVENT {KeyPress , KeyRelease , ButtonPress , ButtonRelease ,
PointerMotion , Button1Motion , Button2Motion , Button3Motion ,
Button4Motion , Button5Motion , ButtonMotion}
KEYSYM 32íbit value (top three bits guaranteed to be zero)
KEYCODE CARD8
BUTTON CARD8
KEYMASK {Shift , Lock , Control , Mod1 , Mod2 , Mod3 , Mod4 , Mod5}
BUTMASK {Button1 , Button2 , Button3 , Button4 , Button5}
KEYBUTMASK KEYMASK or BUTMASK
STRING8 LISTofCARD8
STRING16 LISTofCHAR2B
CHAR2B [byte1, byte2: CARD8]
POINT [x, y: INT16]
RECTANGLE [x, y: INT16,
width, height: CARD16]
ARC [x, y: INT16,
width, height: CARD16,
angle1, angle2: INT16]
HOST [family: {Internet , DECnet , Chaos}
address: LISTofBYTE]
The [x,y] coordinates of a RECTANGLE specify the upperíleft corner.
3

íí íí
X Protocol X11, Release 6.4
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 signifií
cant byte. This means that clients should always transmit such 16íbit character values most sigí
nificant 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 Changeí
Hosts request).
4. 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 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 colí
ormap 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 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 unspecií
fied, but a server may generate an Alloc error on any request for this
reason, and clients should be prepared to receive such errors and haní
dle or discard them.
Atom A value for an ATOM argument does not name a defined ATOM.
Colormap A value for a COLORMAP argument does not name a defined COLí
ORMAP.
Cursor A value for a CURSOR argument does not name a defined CURí
SOR.
Drawable A value for a DRAWABLE argument does not name a defined WINí
DOW or PIXMAP.
4

íí íí
X Protocol X11, Release 6.4
Error Description
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 A value for a GCONTEXT argument does not name a defined
GCONTEXT.
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 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 preí
pared to receive such errors and handle or discard them.
Length The length of a request is shorter or longer than that required to minií
mally contain the arguments.
The length of a request exceeds the maximum length accepted by the
server.
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 A font or color of the specified name does not exist.
Pixmap A value for a PIXMAP argument does not name a defined PIXMAP.
Request The major or minor opcode does not specify a valid request.
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 A value for a WINDOW argument does not name a defined WINí
DOW.
Note
The Atom , Colormap , Cursor , Drawable , Font , GContext , Pixmap , and Winí
dow errors are also used when the argument type is extended by union with a set of
fixed alternatives, for example, .
5. Keyboards
A KEYCODE represents a physical (or logical) key. Keycodes lie in the inclusive range [8,255].
A keycode value carries no intrinsic information, although server implementors may attempt to
encode geometry information (for example, matrix) to be interpreted in a serverídependent fashí
ion. The mapping between keys and keycodes cannot be changed using the protocol.
5

íí íí
X Protocol X11, Release 6.4
A KEYSYM is an encoding of a symbol on the cap of a key. The set of defined KEYSYMs
include the character sets Latiní1, Latiní2, Latiní3, Latiní4, Kana, Arabic, Cyrillic, Greek, Tech,
Special, Publish, APL, Hebrew, Thai, and Korean as well as a set of symbols common on
keyboards (Return, Help, Tab, and so on). KEYSYMs with the most significant bit (of the 29
bits) set are reserved as vendoríspecific.
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 eleí
ment were the uppercase form of ``K''.
The standard rules for obtaining a KEYSYM from a KeyPress event make use of only the Group
1 and Group 2 KEYSYMs; no interpretation of other KEYSYMs in the list is defined. The modií
fier state determines which group to use. Switching between groups is controlled by the
KEYSYM named MODE SWITCH, by attaching that KEYSYM to some KEYCODE and attachí
ing that KEYCODE to any one of the modifiers Mod1 through Mod5 . This modifier is called
the ``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 is interpreted as CapsLock when the KEYSYM named CAPS LOCK is
attached to some KEYCODE and that KEYCODE is attached to the 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 attachí
ing that KEYSYM to some KEYCODE and attaching that KEYCODE to any one of the modií
fiers Mod1 through Mod5 . This modifier is called the ``numlock modifier''. The standard
KEYSYMs with the prefix KEYPAD in their name are called ``keypad'' KEYSYMs; these are
KEYSYMS with numeric value in the hexadecimal range #xFF80 to #xFFBD inclusive. In addií
tion, vendoríspecific KEYSYMS in the hexadecimal range #x11000000 to #x1100FFFF are also
keypad KEYSYMs.
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.
6

íí íí
X Protocol X11, Release 6.4
. 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.
6. Pointers
Buttons are always numbered starting with one.
7. Predefined Atoms
Predefined atoms are not strictly necessary and may not be useful in all environments, but they
will eliminate many 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 Coní
sortium standards, such as the InteríClient Communication Conventions Manual and the X Logií
cal Font Description Conventions.
The following names have predefined atom values. Note that uppercase and lowercase matter.
ARC ITALIC_ANGLE STRING
ATOM MAX_SPACE SUBSCRIPT_X
BITMAP MIN_SPACE SUBSCRIPT_Y
CAP_HEIGHT NORM_SPACE SUPERSCRIPT_X
CARDINAL NOTICE SUPERSCRIPT_Y
COLORMAP PIXMAP UNDERLINE_POSITION
COPYRIGHT POINT UNDERLINE_THICKNESS
CURSOR POINT_SIZE VISUALID
CUT_BUFFER0 PRIMARY WEIGHT
CUT_BUFFER1 QUAD_WIDTH WINDOW
CUT_BUFFER2 RECTANGLE WM_CLASS
CUT_BUFFER3 RESOLUTION WM_CLIENT_MACHINE
CUT_BUFFER4 RESOURCE_MANAGER WM_COMMAND
CUT_BUFFER5 RGB_BEST_MAP WM_HINTS
CUT_BUFFER6 RGB_BLUE_MAP WM_ICON_NAME
CUT_BUFFER7 RGB_COLOR_MAP WM_ICON_SIZE
DRAWABLE RGB_DEFAULT_MAP WM_NAME
END_SPACE RGB_GRAY_MAP WM_NORMAL_HINTS
FAMILY_NAME RGB_GREEN_MAP WM_SIZE_HINTS
FONT RGB_RED_MAP WM_TRANSIENT_FOR
FONT_NAME SECONDARY WM_ZOOM_HINTS
FULL_NAME STRIKEOUT_ASCENT X_HEIGHT
INTEGER STRIKEOUT_DESCENT
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 underí
score should be used for atoms that are private to a particular vendor or organization. To guaraní
tee 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.
8. Connection Setup
For remote clients, the X protocol can be built on top of any reliable byte stream.
7

íí íí
X Protocol X11, Release 6.4
Connection Initiation
The client must send an initial byte of data to identify the byte order to be employed. The value
of the byte must be octal 102 or 154. The value 102 (ASCII uppercase B) means values are transí
mitted most significant byte first, and value 154 (ASCII lowercase l) means values are transmitted
least significant byte first. Except where explicitly noted in the protocol, all 16íbit and 32íbit
quantities sent by the client must be transmitted with this byte order, and all 16íbit and 32íbit
quantities returned by the server will be transmitted with this 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 impleí
ment.
The authorization name indicates what authorization (and authentication) protocol the client
expects the server to use, and the data is specific to that protocol. Specification of valid authorizaí
tion mechanisms is not part of the core X protocol. A server that does not implement the protocol
the client expects or that only implements the hostíbased mechanism may simply ignore this
information. If both name and data strings are empty, this is to be interpreted as ``no explicit
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
8

íí íí
X Protocol X11, Release 6.4
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]
Server Information
The information that is global to the server is:
The protocol version numbers are an escape hatch in case future revisions of the protocol are necí
essary. 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 verí
sion will be 11, and the minor version will be 0. The protocol version numbers returned indicate
the protocol the server actually supports. This might not equal the version sent by the client. The
server can (but need not) refuse connections from clients that offer a different version than the
server supports. A server can (but need not) support more than one version simultaneously.
The vendor string gives some identification of the owner of the server implementation. The vení
dor controls the semantics of the release number.
The resourceíidímask contains a single contiguous set of bits (at least 18). The client allocates
resource IDs for types WINDOW, PIXMAP, CURSOR, FONT, GCONTEXT, and COLORMAP
by choosing a value with only some subset of these bits set and ORing it with resourceíidíbase.
Only values constructed in this way can be used to name newly created resources over this coní
nection. Resource IDs never have the top three bits set. The client is not restricted to linear or
contiguous allocation of resource IDs. Once an ID has been freed, it can be reused. An ID must
be unique with respect to the IDs of all other resources, not just other resources of the same type.
However, note that the value spaces of resource identifiers, atoms, visualids, and keysyms are disí
tinguished by context, and as such, are not required to be disjoint; for example, a given numeric
value might be both a valid window ID, a valid atom, and a valid keysym.
Although the server is in general responsible for byteíswapping data to match the client, images
are always transmitted and received in formats (including byte order) specified by the server. The
9

íí íí
X Protocol X11, Release 6.4
byte order for images is given by imageíbyteíorder and applies to each scanline unit in XY format
(bitmap format) and to each pixel value in Z format.
A bitmap is represented in scanline order. Each scanline is padded to a multiple of bits as given
by bitmapíscanlineípad. The pad bits are of arbitrary value. The scanline is quantized in multií
ples of bits as given by bitmapíscanlineíunit. The bitmapíscanlineíunit is always less than or
equal to the bitmapíscanlineípad. Within each unit, the leftmost bit in the bitmap is either the
least significant or most significant bit in the unit, as given by bitmapíbitíorder. If a pixmap is
represented in XY format, each plane is represented as a bitmap, and the planes appear from most
significant to least significant in bit order with no padding between planes.
Pixmapíformats contains one entry for each depth value. The entry describes the Z format used
to represent images of that depth. An entry for a depth is included if any screen supports that
depth, and all screens supporting that depth must support only that Z format for that depth. In Z
format, the pixels are in scanline order, left to right within a scanline. The number of bits used to
hold each pixel is given by bitsíperípixel. Bitsíperípixel may be larger than strictly required by
the depth, in which case the least significant bits are used to hold the pixmap data, and the values
of the unused highíorder bits are undefined. When the bitsíperípixel is 4, the order of nibbles in
the byte is the same as the image byteíorder. When the bitsíperípixel is 1, the format is identical
for bitmap format. Each scanline is padded to a multiple of bits as given by scanlineípad. When
bitsíperípixel is 1, this will be identical to bitmapíscanlineípad.
How a pointing device roams the screens is up to the server implementation and is transparent to
the protocol. No geometry is defined among screens.
The server may retain the recent history of pointer motion and do so to a finer granularity than is
reported by MotionNotify events. The GetMotionEvents request makes such history available.
The motioníbufferísize gives the approximate maximum number of elements in the history buffer.
Maximumírequestílength specifies the maximum length of a request accepted by the server, in
4íbyte units. That is, length is the maximum value that can appear in the length field of a request.
Requests larger than this maximum generate a Length error, and the server will read and simply
discard the entire request. Maximumírequestílength will always be at least 4096 (that is, requests
of length up to and including 16384 bytes will be accepted by all servers).
Miníkeycode and maxíkeycode specify the smallest and largest keycode values transmitted by the
server. Miníkeycode is never less than 8, and maxíkeycode is never greater than 255. Not all
keycodes in this range are required to have corresponding keys.
Screen Information
The information that applies per screen is:
The allowedídepths specifies what pixmap and window depths are supported. Pixmaps are supí
ported for each depth listed, and windows of that depth are supported if at least one visual type is
listed for the depth. A pixmap depth of one is always supported and listed, but windows of depth
one might not be supported. A depth of zero is never listed, but zeroídepth InputOnly windows
are always supported.
Rootídepth and rootívisual specify the depth and visual type of the root window. Widthíinípixels
and heightíinípixels specify the size of the root window (which cannot be changed). The class of
the root window is always InputOutput . Widthíinímillimeters and heightíinímillimeters can be
used to determine the physical size and the aspect ratio.
The defaultícolormap is the one initially associated with the root window. Clients with minimal
color requirements creating windows of the same depth as the root may want to allocate from this
map by default.
Blackípixel and whiteípixel can be used in implementing a monochrome application. These pixel
values are for permanently allocated entries in the defaultícolormap. The actual RGB values may
be settable on some screens and, in any case, may not actually be black and white. The names are
intended to convey the expected relative intensity of the colors.
10

íí íí
X Protocol X11, Release 6.4
The border of the root window is initially a pixmap filled with the blackípixel. The initial backí
ground of the root window is a pixmap filled with some unspecified twoícolor pattern using
blackípixel and whiteípixel.
Miníinstalledímaps specifies the number of maps that can be guaranteed to be installed simultaí
neously (with InstallColormap), regardless of the number of entries allocated in each map.
Maxíinstalledímaps specifies the maximum number of maps that might possibly be installed
simultaneously, depending on their allocations. Multiple staticívisual colormaps with identical
contents but differing in resource ID should be considered as a single map for the purposes of this
number. For the typical case of a single hardware colormap, both values will be 1.
Backingístores indicates when the server supports backing stores for this screen, although it may
be storage limited in the number of windows it can support at once. If saveíunders is True , the
server can support the saveíunder mode in CreateWindow and ChangeWindowAttributes ,
although again it may be storage limited.
The currentíinputíevents is what GetWindowAttributes would return for the allíeventímasks for
the root window.
Visual Information
The information that applies per visualítype is:
A given visual type might be listed for more than one depth or for more than one screen.
For PseudoColor , a pixel value indexes a colormap to produce independent RGB values; the
RGB values can be changed dynamically. GrayScale is treated in the same way as Pseudoí
Color except which primary drives the screen is undefined; thus, the client should always store
the same value for red, green, and blue in colormaps. For DirectColor , a pixel value is decomí
posed into separate RGB subfields, and each subfield separately indexes the colormap for the corí
responding value. The RGB values can be changed dynamically. TrueColor is treated in the
same way as DirectColor except the colormap has predefined readíonly RGB values. These valí
ues are serverídependent but provide linear or nearílinear increasing ramps in each primary.
StaticColor is treated in the same way as PseudoColor except the colormap has predefined
readíonly RGB values, which are serverídependent. StaticGray is treated in the same way as
StaticColor except the red, green, and blue values are equal for any single pixel value, resulting
in shades of gray. StaticGray with a twoíentry colormap can be thought of as monochrome.
The redímask, greenímask, and blueímask are only defined for DirectColor and TrueColor .
Each has one contiguous set of bits set to 1 with no intersections. Usually each mask has the
same number of bits set to 1.
The bitsíperírgbívalue specifies the log base 2 of the number of distinct color intensity values
(individually) of red, green, and blue. This number need not bear any relation to the number of
colormap entries. Actual RGB values are always passed in the protocol within a 16íbit spectrum,
with 0 being minimum intensity and 65535 being the maximum intensity. On hardware that proí
vides a linear zeroíbased intensity ramp, the following relationship exists:
hwíintensity = protocolíintensity / (65536 / totalíhwíintensities)
Colormap entries are indexed from 0. The colormapíentries defines the number of available colí
ormap entries in a newly created colormap. For DirectColor and TrueColor , this will usually
be 2 to the power of the maximum number of bits set to 1 in redímask, greenímask, and blueí
mask.
9. Requests
11

íí íí
X Protocol X11, Release 6.4
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 parí
ent 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 InputOutí
put 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
12

íí íí
X Protocol X11, Release 6.4
Attribute Type
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.
If backgroundípixmap is given, it overrides the default backgroundípixmap. The background
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 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 overí
rides 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 winí
dow'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,
13

íí íí
X Protocol X11, Release 6.4
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 winí
dow 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 truní
cated 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 Coní
figureWindow 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 NotUseí
ful 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 specií
fies 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.
The eventímask defines which events the client is interested in for this window (or for some event
types, inferiors of the window). The doínotípropagateímask defines which events should not be
propagated to ancestor windows when no client has the event type selected in this window.
The overrideíredirect specifies whether map and configure requests on this window should overí
ride 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 maní
agers 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
14

íí íí
X Protocol X11, Release 6.4
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 specií
fied, 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
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 restricí
tions 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.
15

íí íí
X Protocol X11, Release 6.4
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
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
window: WINDOW
Errors: Window
This request performs a DestroyWindow request on all children of the window, in bottomítoítop
stacking order.
16

íí íí
X Protocol X11, Release 6.4
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 section 10.
When windows are destroyed, the server automatically removes them from the saveíset.
ReparentWindow
window , parent: WINDOW
x , y: INT16
Errors: Match , Window
If the window is mapped, an UnmapWindow request is performed automatically first. The winí
dow 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 stackí
ing order with respect to siblings. A ReparentNotify event is then generated. The overrideíredií
rect 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
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 Subí
structureRedirect 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
17

íí íí
X Protocol X11, Release 6.4
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
window: WINDOW
Errors: Window
This request performs a MapWindow request on all unmapped children of the window, in topítoí
bottom stacking order.
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
window: WINDOW
Errors: Window
This request performs an UnmapWindow request on all mapped children of the window, in botí
tomítoítop stacking order.
ConfigureWindow
window: WINDOW
valueímask: BITMASK
valueílist: LISTofVALUE
Errors: Match , Value , Window
This request changes the configuration of the window. The valueímask and valueílist specify
which values are to be given. The possible values are:
Attribute Type
x INT16
y INT16
width CARD16
height CARD16
borderíwidth CARD16
sibling WINDOW
stackímode {Above , Below , TopIf , BottomIf , Opposite}
18

íí íí
X Protocol X11, Release 6.4
The x and y coordinates are relative to the parent's origin and specify the position of the upperí
left outer corner of the window. The width and height specify the inside size, not including the
border, and must be nonzero (or a Value error results). Those values not specified are taken from
the existing geometry of the window. Note that changing just the borderíwidth leaves the outerí
left corner of the window in a fixed position but moves the absolute position of the window's orií
gin. It is a Match error to attempt to make the borderíwidth of an InputOnly window nonzero.
If the overrideíredirect attribute of the window is False and some other client has selected Subí
structureRedirect on the parent, a ConfigureRequest event is generated, and no further proí
cessing is performed. Otherwise, the following is performed:
If some other client has selected ResizeRedirect on the window and the inside width or height of
the window is being changed, a ResizeRequest event is generated, and the current inside width
and height are used instead. Note that the overrideíredirect attribute of the window has no effect
on ResizeRedirect and that SubstructureRedirect on the parent has precedence over Resizí
eRedirect on the window.
The geometry of the window is changed as specified, the window is restacked among siblings,
and a ConfigureNotify event is generated if the state of the window actually changes. If the
inside width or height of the window has actually changed, then children of the window are
affected, according to their winígravity. Exposure processing is performed on formerly obscured
windows (including the window itself and its inferiors if regions of them were obscured but now
are not). Exposure processing is also performed on any new regions of the window (as a result of
increasing the width or height) and on any regions where window contents are lost.
If the inside width or height of a window is not changed but the window is moved or its border is
changed, then the contents of the window are not lost but move with the window. Changing the
inside width or height of the window causes its contents to be moved or lost, depending on the
bitígravity of the window. It also causes children to be reconfigured, depending on their winí
gravity. For a change of width and height of W and H, we define the [x, y] pairs as:
Direction Deltas
NorthWest [0, 0]
North [W/2, 0]
NorthEast [W, 0]
West [0, H/2 ]
Center [W/2, H/2]
East [W, H/2 ]
SouthWest [0, H]
South [W/2, H]
SouthEast [W, H]
When a window with one of these bitígravities is resized, the corresponding pair defines the
change in position of each pixel in the window. When a window with one of these winígravities
has its parent window resized, the corresponding pair defines the change in position of the winí
dow within the parent. This repositioning generates a GravityNotify event. GravityNotify
events are generated after the ConfigureNotify event is generated.
A gravity of Static indicates that the contents or origin should not move relative to the origin of
the root window. If the change in size of the window is coupled with a change in position of [X,
Y], then for bitígravity the change in position of each pixel is [-X, -Y] and for winígravity the
change in position of a child when its parent is so resized is [-X, -Y]. Note that Static gravity
still only takes effect when the width or height of the window is changed, not when the window is
simply moved.
A bitígravity of Forget indicates that the window contents are always discarded after a size
change, even if backingístore or saveíunder has been requested. The window is tiled with its
19

íí íí
X Protocol X11, Release 6.4
background (except, if no background is defined, the existing screen contents are not altered) and
zero or more exposure events are generated.
The contents and borders of inferiors are not affected by their parent's bitígravity. A server is
permitted to ignore the specified bitígravity and use Forget instead.
A winígravity of Unmap is like NorthWest , but the child is also unmapped when the parent is
resized, and an UnmapNotify event is generated. UnmapNotify events are generated after the
ConfigureNotify event is generated.
If a sibling and a stackímode are specified, the window is restacked as follows:
Above The window is placed just above the sibling.
Below The window is placed just below the sibling.
TopIf If the sibling occludes the window, then the window is placed at the top of
the stack.
BottomIf If the window occludes the sibling, then the window is placed at the bottom
of the stack.
Opposite If the sibling occludes the window, then the window is placed at the top of
the stack. Otherwise, if the window occludes the sibling, then the window is
placed at the bottom of the stack.
If a stackímode is specified but no sibling is specified, the window is restacked as follows:
Above The window is placed at the top of the stack.
Below The window is placed at the bottom of the stack.
TopIf If any sibling occludes the window, then the window is placed at the top of
the stack.
BottomIf If the window occludes any sibling, then the window is placed at the bottom
of the stack.
Opposite If any sibling occludes the window, then the window is placed at the top of
the stack. Otherwise, if the window occludes any sibling, then the window is
placed at the bottom of the stack.
It is a Match error if a sibling is specified without a stackímode or if the window is not actually a
sibling.
Note that the computations for BottomIf , TopIf , and Opposite are performed with respect to the
window's final geometry (as controlled by the other arguments to the request), not to its initial
geometry.
Attempts to configure a root window have no effect.
CirculateWindow
window: WINDOW
direction: {RaiseLowest , LowerHighest}
Errors: Value , Window
If some other client has selected SubstructureRedirect on the window, then a Circuí
lateRequest 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
20

íí íí
X Protocol X11, Release 6.4
mapped child (if any) that occludes another child to the bottom of the stack. Exposure processing
is performed on formerly obscured windows.
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
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
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 creí
ated if it does not exist. The string should use the ISO Latiní1 encoding. Uppercase and lowerí
case matter.
The lifetime of an atom is not tied to the interning client. Atoms remain defined until server reset
(see section 10).
21

íí íí
X Protocol X11, Release 6.4
GetAtomName
atom : ATOM
î
name: STRING8
Errors: Atom
This request returns the name for the given atom.
ChangeProperty
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 quantií
ties 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 section 10).
The maximum size of a property is serverídependent and may vary dynamically.
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.
22

íí íí
X Protocol X11, Release 6.4
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 Properí
tyNotify event is generated on the window.
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 assoí
ciated 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.
23

íí íí
X Protocol X11, Release 6.4
If an atom occurs more than once in the list or no property with that name is defined for the winí
dow, a Match error is generated. If an Atom or Match error is generated, no properties are
changed.
ListProperties
window: WINDOW
î
atoms: LISTofATOM
Errors: Window
This request returns the atoms of properties currently defined on the window.
SetSelectionOwner
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 winí
dow 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 selecí
tion 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 GetSeí
lectionOwner request and is reported in SelectionRequest and SelectionClear events.
Selections are global to the server.
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.
24

íí íí
X Protocol X11, Release 6.4
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
destination: WINDOW or PointerWindow or InputFocus
propagate : BOOL
eventímask: SETofEVENT
event:
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ípropaí
gateí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.
25

íí íí
X Protocol X11, Release 6.4
GrabPointer
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 proí
tocol) appears to freeze, and no further keyboard events are generated by the server until the grabí
bing 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 proí
cessing.
If a cursor is specified, then it is displayed regardless of what window the pointer is in. If no curí
sor 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 specií
fied time, with CurrentTime replaced by the current server time.
26

íí íí
X Protocol X11, Release 6.4
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.
GrabButton
modifiers : SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grabíwindow: WINDOW
owneríevents : BOOL
eventímask: SETofPOINTEREVENT
pointerímode, keyboardímode: {Synchronous , Asynchronous}
confineíto: WINDOW or None
cursor : CURSOR or None
Errors: Access , Cursor , Value , Window
This request establishes a passive grab. In the future, the pointer is actively grabbed as described
in GrabPointer , the lastípointerígrab time is set to the time at which the button was pressed (as
transmitted in the ButtonPress event), and the ButtonPress event is reported if all of the followí
ing conditions are true:
. The pointer is not grabbed and the specified button is logically pressed when the specified
modifier keys are logically down, and no other buttons or modifier keys are logically down.
. The grabíwindow contains the pointer.
. The confineíto window (if any) is viewable.
. A passive grab on the same button/key combination does not exist on any ancestor of grabí
window.
The interpretation of the remaining arguments is the same as for GrabPointer . The active grab
is terminated automatically when the logical state of the pointer has all buttons released, indepení
dent 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 button/key comí
binations 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 specified modifiers have currently assigned keycodes. A button of AnyButton is
equivalent to issuing the request for all possible buttons. Otherwise, it is not required that the butí
ton specified currently be assigned to a physical button.
An Access error is generated if some other client has already issued a GrabButton request with
the same button/key combination on the same window. When using AnyModifier or
AnyButton , the request fails completely (no grabs are established), and an Access error is generí
ated if there is a conflicting grab for any combination. The request has no effect on an active
grab.
27

íí íí
X Protocol X11, Release 6.4
UngrabButton
modifiers : SETofKEYMASK or AnyModifier
button: BUTTON or AnyButton
grabíwindow: WINDOW
Errors: Value , Window
This request releases the passive button/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 button of
AnyButton is equivalent to issuing the request for all possible buttons. The request has no effect
on an active grab.
ChangeActivePointerGrab
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 curí
rent 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
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 Keyí
Press 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)
28

íí íí
X Protocol X11, Release 6.4
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
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
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. In the future, the keyboard is actively
grabbed as described in 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 modií
fier 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íwiní
dow.
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 posí
sible 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
29

íí íí
X Protocol X11, Release 6.4
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 comí
bination on the same window. When using AnyModifier or AnyKey , the request fails comí
pletely (no grabs are established), and an Access error is generated if there is a conflicting grab
for any combination.
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 equiví
alent to issuing the request for all possible keycodes. This request has no effect on an active grab.
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 norí
mally. 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 proí
cessing 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 preí
vious 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 continí
ues 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
30

íí íí
X Protocol X11, Release 6.4
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 preí
vious 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 KeyReí
lease 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 subseí
quent 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 sepaí
rate 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 perí
formed 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
This request disables processing of requests and closeídowns on all connections other than the
one this request arrived on.
UngrabServer
This request restarts processing of requests and closeídowns on other connections.
31

íí íí
X Protocol X11, Release 6.4
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 orií
gin are returned. If sameíscreen is False , then the pointer is not on the same screen as the arguí
ment 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
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
srcíwindow, dstíwindow: WINDOW
srcíx, srcíy: INT16
î
sameíscreen: BOOL
child: WINDOW or None
dstíx, dstíy: INT16
Errors: Window
32

íí íí
X Protocol X11, Release 6.4
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 coní
tained in a mapped child of dstíwindow, then that child is returned.
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 curí
rent 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.
SetInputFocus
focus : WINDOW or PointerRoot or None
revertíto : {Parent , PointerRoot , None}
time : TIMESTAMP or CurrentTime
Errors: Match , Value , Window
This request changes the input focus and the lastífocusíchange time. The request has no effect if
the specified time is earlier than the current lastífocusíchange time or is later than the current
server time. Otherwise, the lastífocusíchange time is set to the specified time with CurrentTime
replaced by the current server time.
If None is specified as the focus, all keyboard events are discarded until a new focus window is
set. In this case, the revertíto argument is ignored.
If a window is specified as the focus, it becomes the keyboard's focus window. 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.
If PointerRoot is specified as the focus, the focus window is dynamically taken to be the root
window of whatever screen the pointer is on at each keyboard event. In this case, the revertíto
argument is ignored.
This request generates FocusIn and FocusOut events.
The specified focus window must be viewable at the time of the request (or a Match error
results). If the focus window later becomes not viewable, the new focus window depends on the
revertíto argument. If revertíto is Parent , the focus reverts to the parent (or the closest viewable
33

íí íí
X Protocol X11, Release 6.4
ancestor) and the new revertíto value is taken to be None . If revertíto is PointerRoot or None ,
the focus reverts to that value. When the focus reverts, FocusIn and FocusOut events are generí
ated, but the lastífocusíchange time is not affected.
GetInputFocus
î
focus: WINDOW or PointerRoot or None
revertíto: {Parent , PointerRoot , None}
This request returns the current focus state.
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 representí
ing 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
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 matchí
ing 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 Consortium 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
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.
34

íí íí
X Protocol X11, Release 6.4
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)
35

íí íí
X Protocol X11, Release 6.4
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 charí
acter 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 charí
acters 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 incluí
sive 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 Consortium standard X Logical Font Description Convení
tions.
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 logií
cally viewed as being coincident with the left edge of a nonkerned character (when leftísideíbearí
ing 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.
36

íí íí
X Protocol X11, Release 6.4
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 maxí
imum 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 charací
ters 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 undeí
fined characters in the string are also ignored.
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 Setí
FontPath request) that match the pattern. At most, maxínames names will be returned. The patí
tern should use the ISO Latiní1 encoding, and uppercase and lowercase do not matter. In the patí
tern, 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.
37

íí íí
X Protocol X11, Release 6.4
ListFontsWithInfo
pattern: STRING8
maxínames : CARD16
î+
name: STRING8
info: FONTINFO
repliesíhint: CARD32
where:
FONTINFO:
This request is similar to ListFonts , but it also returns information about each font. The informaí
tion returned for each font is identical to what QueryFont would return except that the perícharí
acter 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 numí
ber 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
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
î
path: LISTofSTRING8
This request returns the current search path for fonts.
CreatePixmap
pid : PIXMAP
drawable: DRAWABLE
depth: CARD8
width, height: CARD16
Errors: Alloc , Drawable , IDChoice , Value
38

íí íí
X Protocol X11, Release 6.4
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 undeí
fined.
It is legal to pass an InputOnly window as a drawable to this request.
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
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 coní
text 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
39

íí íí
X Protocol X11, Release 6.4
Component Type
clipíxíorigin INT16
clipíyíorigin INT16
clipímask PIXMAP or None
dashíoffset CARD16
dashes CARD8
In graphics operations, given a source and destination pixel, the result is computed bitwise on corí
responding bits of the pixels; that is, a Boolean operation is performed in each bit plane. The
planeímask restricts the operation to a subset of planes, so the result is:
((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
The lineíwidth is measured in pixels and can be greater than or equal to one, a wide line, or the
special value zero, a thin line.
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
40

íí íí
X Protocol X11, Release 6.4
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 recomí
mended 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 comprisí
ing 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 encourí
aged to make this property true for thin lines, but it is not required. A lineíwidth of zero may difí
fer 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 unií
form 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 endí
points, the semantics depends on the lineíwidth and the capístyle:
41

íí íí
X Protocol X11, Release 6.4
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 diamí
eter equal to the lineíwidth.
Projecting wide The closed path is a square, aligned with the coordinate axes, cení
tered 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 patí
tern 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
42

íí íí
X Protocol X11, Release 6.4
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.
The clipímask restricts writes to the destination drawable. Only pixels where the clipímask has
bits set to 1 are drawn. Pixels are not drawn outside the area covered by the clipímask or where
the clipímask has bits set to 0. The clipímask affects all graphics requests, but it does not clip
sources. The clipímask origin is interpreted relative to the origin of whatever destination drawí
able is specified in a graphics request. If a pixmap is specified as the clipímask, it must have
depth 1 and have the same root as the gcontext (or a 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 viewí
able 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.
The fillírule defines what pixels are inside (that is, are drawn) for paths given in 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 immedií
ately 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 direcí
tion).
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)
43

íí íí
X Protocol X11, Release 6.4
Component Default
stipple Pixmap of unspecified size filled with ones
tileístippleíxíorigin 0
tileístippleíyíorigin 0
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 complexí
ity 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
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 compoí
nents 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 generí
ated, a subset of the components may have been altered.
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 compoí
nents to copy, as for CreateGC . The two gcontexts must have the same root and the same depth
(or a Match error results).
44

íí íí
X Protocol X11, Release 6.4
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 coní
catenated 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 rení
der 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 secí
ond instance. In addition, the effective set of points comprising a dash cannot be affected by clipí
ping. 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
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 rectí
angle coordinates are interpreted relative to the clip origin. The rectangles should be noninterí
secting, 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,
45

íí íí
X Protocol X11, Release 6.4
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
gc : GCONTEXT
Errors: GContext
This request deletes the association between the resource ID and the gcontext and destroys the
gcontext.
ClearArea
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
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 rectaní
gle. 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
46

íí íí
X Protocol X11, Release 6.4
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 correspondí
ing destination regions are generated.
If graphicsíexposures is True but no GraphicsExposure events are generated, then a NoExpoí
sure event is generated.
GC components: function, planeímask, subwindowímode, graphicsíexposures, clipíxíorigin, clipí
yíorigin, clipímask
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 n where n is the depth of srcídrawable (or a Value error results). Effecí
tively, 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
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íorií
gin, clipímask
47

íí íí
X Protocol X11, Release 6.4
PolyLine
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, subí
windowí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
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
48

íí íí
X Protocol X11, Release 6.4
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 specií
fied 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, subí
windowí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
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 relaí
tive 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 impleí
mentation dependent. However, the computation of the shape and position of the bounding outí
lines (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
49

íí íí
X Protocol X11, Release 6.4
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 direcí
tion (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 cirí
cles/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 implemení
tation 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, subí
windowí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
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.
50

íí íí
X Protocol X11, Release 6.4
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íintersecí
tion.
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
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 rectí
angle:
[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
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 specií
fied 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
51

íí íí
X Protocol X11, Release 6.4
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
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 coordií
nates 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 connecí
tion 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 arguí
ment 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
52

íí íí
X Protocol X11, Release 6.4
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 rectí
angle. 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 checkí
ing 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 coní
tents of visible regions of inferiors of different depth than the specified window. The pointer curí
sor 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
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
53

íí íí
X Protocol X11, Release 6.4
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 charí
acter 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íorií
gin, clipímask
GC modeídependent components: foreground, background, tile, stipple, tileístippleíxíorigin, tileí
stippleíyíorigin
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
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:
54

íí íí
X Protocol X11, Release 6.4
fontíascent + fontídescent
The overallíwidth, fontíascent, and fontídescent are as they would be returned by a QueryTexí
tExtents 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
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
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 colí
ormap 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 .
55

íí íí
X Protocol X11, Release 6.4
FreeColormap
cmap : COLORMAP
Errors: Colormap
This request deletes the association between the resource ID and the colormap and frees the colí
ormap storage. If the colormap is an installed map for a screen, it is uninstalled (see Uninstallí
Colormap request). If the colormap is defined as the colormap for a window (by means of Creí
ateWindow 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
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 characterí
istics intact, and it frees those entries in srcícmap. Color values in other entries in the new colí
ormap 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
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 uniní
stalled 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 colí
ormap 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.
56

íí íí
X Protocol X11, Release 6.4
Initially the default colormap for a screen is installed (but is not in the required list).
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 colí
ormap as an attribute.
ListInstalledColormaps
window: WINDOW
î
cmaps: LISTofCOLORMAP
Errors: Window
This request returns a list of the currently installed colormaps for the screen of the specified winí
dow. The order of colormaps is not significant, and there is no explicit indication of the required
list (see InstallColormap request).
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 proí
vided 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, allowí
ing entries to be shared.
57

íí íí
X Protocol X11, Release 6.4
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
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 P distinct pixels can be produced; all of these are alloí
cated 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
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
58

íí íí
X Protocol X11, Release 6.4
pixel subfield. By ORing together subsets of masks with pixels, C*2 R+G+B distinct pixels can be
produced; all of these are allocated writable by the request. The initial RGB values of the alloí
cated entries are undefined. In the colormap, there are only C*2 R independent red entries, C*2 G
independent green entries, and C*2 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 indeí
pendent entries are updated.
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 unalloí
cated 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
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.
59

íí íí
X Protocol X11, Release 6.4
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
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
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 upperí
case and lowercase do not matter.
60

íí íí
X Protocol X11, Release 6.4
CreateCursor
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
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.
61

íí íí
X Protocol X11, Release 6.4
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
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
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 indií
cates 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
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 extení
sion is returned, if it has one. Otherwise, zero is returned. Any minor opcode and the request forí
mats 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. Otherí
wise, zero is returned. The format of additional data in the errors is specific to the extension.
62

íí íí
X Protocol X11, Release 6.4
The extension name should use the ISO Latiní1 encoding, and uppercase and lowercase matter.
ListExtensions
î
names: LISTofSTRING8
This request returns a list of all extensions supported by the server.
SetModifierMapping
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 connecí
tion 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
î
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.
63

íí íí
X Protocol X11, Release 6.4
ChangeKeyboardMapping
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 eleí
ments 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 posií
tions 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 section 5).
GetKeyboardMapping
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 coní
nection 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
64

íí íí
X Protocol X11, Release 6.4
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
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 posí
sible. 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.
65

íí íí
X Protocol X11, Release 6.4
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 signifií
cant 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
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
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 numí
ber.
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.
66

íí íí
X Protocol X11, Release 6.4
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
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
î
accelerationínumerator, accelerationídenominator: CARD16
threshold: CARD16
This request returns the current acceleration and threshold for the pointer.
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 hardí
ware 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.
67

íí íí
X Protocol X11, Release 6.4
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 perií
odically, moving an icon image about the screen periodically, or tiling the screen with the root
window background tile, randomly reorigined periodically.
GetScreenSaver
î
timeout, interval: CARD16
preferíblanking: {Yes , No}
allowíexposures: {Yes , No}
This request returns the current screenísaver control values.
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
mode : {Insert , Delete}
host: HOST
Errors: Access , Value
This request adds or removes the specified host from the access control list. When the access
control mechanism is enabled and a client attempts to establish a connection to the server, the
host on which the client resides must be in the access control list, or the client must have been
granted permission by a serverídependent method, or the server will refuse the connection.
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. A server is not required to support these families and
may support families not listed here. Use of an unsupported family, an improper address format,
or an improper address length within a supported family results in a 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. For a Class A address,
the network number is the first byte in the address, and the host number is the remaining three
bytes, most significant byte first. For a Class B address, the network number is the first two bytes
and the host number is the last two bytes, each most significant byte first. For a Class C address,
the network number is the first three bytes, most significant byte first, and the last byte is the host
number.
68

íí íí
X Protocol X11, Release 6.4
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.
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
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
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 section 10.
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 section 10). If AllTemporary is specified,
then the resources of all clients that have terminated in RetainTemporary are destroyed.
NoOperation
69

íí íí
X Protocol X11, Release 6.4
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.
10. Connection Close
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 SetSelecí
tionOwner request) owned by the client are disowned. If closeídown mode (see SetCloseDowní
Mode request) is RetainPermanent or RetainTemporary , then all resources (including colí
ormap 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 coorí
dinates (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 colí
ormap 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 RetainTempoí
rary 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, restorí
ing 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 RetainTempoí
rary will not cause the server to reset.
11. Events
When a button press is processed with the pointer in some window W and no active pointer grab
is in progress, the ancestors of W are searched from the root down, looking for a passive grab to
activate. If no matching passive grab on the button exists, then an active grab is started automatií
cally for the client receiving the event, and the lastípointerígrab time is set to the current server
time. The effect is essentially equivalent to a 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
70

íí íí
X Protocol X11, Release 6.4
Argument Value
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.
KeyPress
KeyRelease
ButtonPress
ButtonRelease
MotionNotify
root, event: WINDOW
child: WINDOW or None
sameíscreen: BOOL
rootíx, rootíy, eventíx, eventíy: INT16
detail:
state: SETofKEYBUTMASK
time : TIMESTAMP
These events are generated either when a key or button logically changes state or when the
pointer logically moves. The generation of these logical changes may lag the physical changes if
device event processing is frozen. Note that KeyPress and KeyRelease are generated for all
keys, even those mapped to modifier bits. The source of the event is the window the pointer is in.
The window the event is reported with respect to is called the event window. The event window
is found by starting with the source window and looking up the hierarchy for the first window on
which any client has selected interest in the event (provided no intervening window prohibits
event generation by including the event type in its doínotípropagateímask). The actual window
used for reporting can be modified by active grabs and, in the case of keyboard events, can be
modified by the focus window.
The root is the root window of the source window, and rootíx and rootíy are the pointer coordií
nates 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 relaí
tive to the event window's origin. Otherwise, eventíx and eventíy are zero. If the source window
is an inferior of the event window, then child is set to the child of the event window that is an
ancestor of (or is) the source window. Otherwise, it is set to None . The state component gives
the logical state of the buttons and modifier keys just before the event. The detail component type
varies with the event type:
Event Component
KeyPress , KeyRelease KEYCODE
ButtonPress , ButtonRelease BUTTON
MotionNotify {Normal , Hint}
MotionNotify events are only generated when the motion begins and ends in the window. The
granularity of motion events is not guaranteed, but a client selecting for motion events is guaraní
teed to get at least one event when the pointer moves and comes to rest. Selecting PointerMoí
tion receives events independent of the state of the pointer buttons. By selecting some subset of
Button[1í5]Motion instead, MotionNotify events will only be received when one or more of the
specified buttons are pressed. By selecting ButtonMotion , MotionNotify events will be
71

íí íí
X Protocol X11, Release 6.4
received only when at least one button is pressed. The events are always of type MotionNotify ,
independent of the selection. If PointerMotionHint is selected, the server is free to send only
one MotionNotify event (with detail Hint) to the client for the event window until either the key
or button state changes, the pointer leaves the event window, or the client issues a QueryPointer
or GetMotionEvents request.
EnterNotify
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.
72

íí íí
X Protocol X11, Release 6.4
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 gení
erating 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 posií
tion 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 deactií
vates 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 posií
tion 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.
FocusIn
FocusOut
event: WINDOW
mode : {Normal , WhileGrabbed , Grab , Ungrab}
detail: {Ancestor , Virtual , Inferior , Nonlinear , NonlinearVirtual , Pointer ,
PointerRoot , None}
These events are generated when the input focus changes and are reported to clients selecting
FocusChange on the window. Events generated by SetInputFocus when the keyboard is not
grabbed have mode Normal . Events generated by SetInputFocus when the keyboard is grabbed
have mode WhileGrabbed . Events generated when a keyboard grab activates have mode Grab ,
and events generated when a keyboard grab deactivates have mode Ungrab .
All FocusOut events caused by a window unmap are generated after any UnmapNotify event,
but the ordering of FocusOut with respect to generated EnterNotify , LeaveNotify ,
VisibilityNotify , and Expose events is not constrained.
Normal and WhileGrabbed events are generated as follows:
When the focus moves from window A to window B, A is an inferior of B, and the pointer is in
window P:
73

íí íí
X Protocol X11, Release 6.4
. FocusOut with detail Ancestor is generated on A.
. FocusOut with detail Virtual is generated on each window between A and B exclusive (in
order).
. FocusIn with detail Inferior is generated on B.
. If P is an inferior of B but P is not A or an inferior of A or an ancestor of A, FocusIn with
detail Pointer is generated on each window below B down to and including P (in order).
When the focus moves from window A to window B, B is an inferior of A, and the pointer is in
window P:
. If P is an inferior of A but P is not an inferior of B or an ancestor of B, FocusOut with
detail Pointer is generated on each window from P up to but not including A (in order).
. FocusOut with detail Inferior is generated on A.
. FocusIn with detail Virtual is generated on each window between A and B exclusive (in
order).
. FocusIn with detail Ancestor is generated on B.
When the focus moves from window A to window B, window C is their least common ancestor,
and the pointer is in window P:
. If P is an inferior of A, FocusOut with detail Pointer is generated on each window from P
up to but not including A (in order).
. FocusOut with detail Nonlinear is generated on A.
. FocusOut with detail NonlinearVirtual is generated on each window between A and C
exclusive (in order).
. FocusIn with detail NonlinearVirtual is generated on each window between C and B
exclusive (in order).
. FocusIn with detail Nonlinear is generated on B.
. If P is an inferior of B, FocusIn with detail Pointer is generated on each window below B
down to and including P (in order).
When the focus moves from window A to window B on different screens and the pointer is in
window P:
. If P is an inferior of A, FocusOut with detail Pointer is generated on each window from P
up to but not including A (in order).
. FocusOut with detail Nonlinear is generated on A.
. If A is not a root window, FocusOut 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, FocusIn with detail NonlinearVirtual is generated on each
window from B's root down to but not including B (in order).
. FocusIn with detail Nonlinear is generated on B.
. If P is an inferior of B, FocusIn with detail Pointer is generated on each window below B
down to and including P (in order).
When the focus moves from window A to PointerRoot (or None) and the pointer is in window
P:
. If P is an inferior of A, FocusOut with detail Pointer is generated on each window from P
up to but not including A (in order).
. FocusOut with detail Nonlinear is generated on A.
. If A is not a root window, FocusOut with detail NonlinearVirtual is generated on each
window above A up to and including its root (in order).
74

íí íí
X Protocol X11, Release 6.4
. FocusIn with detail PointerRoot (or None) is generated on all root windows.
. If the new focus is PointerRoot , FocusIn with detail Pointer is generated on each winí
dow from P's root down to and including P (in order).
When the focus moves from PointerRoot (or None) to window A and the pointer is in window
P:
. If the old focus is PointerRoot , FocusOut with detail Pointer is generated on each winí
dow from P up to and including P's root (in order).
. FocusOut with detail PointerRoot (or None) is generated on all root windows.
. If A is not a root window, FocusIn with detail NonlinearVirtual is generated on each
window from A's root down to but not including A (in order).
. FocusIn with detail Nonlinear is generated on A.
. If P is an inferior of A, FocusIn with detail Pointer is generated on each window below A
down to and including P (in order).
When the focus moves from PointerRoot to None (or vice versa) and the pointer is in window
P:
. If the old focus is PointerRoot , FocusOut with detail Pointer is generated on each winí
dow from P up to and including P's root (in order).
. FocusOut with detail PointerRoot (or None) is generated on all root windows.
. FocusIn with detail None (or PointerRoot) is generated on all root windows.
. If the new focus is PointerRoot , FocusIn with detail Pointer is generated on each winí
dow from P's root down to and including P (in order).
When a keyboard grab activates (but before generating any actual KeyPress event that activates
the grab), G is the grabíwindow for the grab, and F is the current focus:
. FocusIn and FocusOut events with mode Grab are generated (as for Normal above) as
if the focus were to change from F to G.
When a keyboard grab deactivates (but after generating any actual KeyRelease event that deactií
vates the grab), G is the grabíwindow for the grab, and F is the current focus:
. FocusIn and FocusOut events with mode Ungrab are generated (as for Normal above)
as if the focus were to change from G to F.
KeymapNotify
keys: LISTofCARD8
The value is a bit vector as described in QueryKeymap . This event is reported to clients selectí
ing KeymapState on a window and is generated immediately after every EnterNotify and
FocusIn .
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 winí
dow is not viewable but the server is (perhaps newly) honoring window's backingístore attribute
75

íí íí
X Protocol X11, Release 6.4
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 posí
sibly more).
The x and y coordinates are relative to window's origin and specify the upperíleft corner of a rectí
angle. 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 VisibilityNoí
tify event on that window, but it is not required that all Expose events on all windows be generí
ated after all Visibilitity events on all windows. The ordering of Expose events with respect to
FocusOut , EnterNotify , and LeaveNotify events is not constrained.
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 winí
dow 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
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 proí
duce 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.
76

íí íí
X Protocol X11, Release 6.4
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 unobí
scured, 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 Visibilií
tyNotify events with respect to FocusOut , EnterNotify , and LeaveNotify events is not coní
strained.
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
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 orderí
ing among siblings and across subhierarchies is not otherwise constrained.
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
77

íí íí
X Protocol X11, Release 6.4
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
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 winí
dow is the window that is mapped. The overrideíredirect flag is from the window's attribute.
MapRequest
parent, window : WINDOW
This event is reported to the client selecting SubstructureRedirect on the parent and is generí
ated when a MapWindow request is issued on an unmapped window with an overrideíredirect
attribute of False .
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 winí
dow that has been rerooted. The parent specifies the new parent. The x and y coordinates are relí
ative to the new parent's origin and specify the position of the upperíleft outer corner of the winí
dow. The overrideíredirect flag is from the window's attribute.
ConfigureNotify
event, window : WINDOW
x, y : INT16
width, height, borderíwidth : CARD16
aboveísibling: WINDOW or None
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 a ConfigureWindow request actually
changes the state of the window. The event is the window on which the event was generated, and
the window is the window that is changed. The x and y coordinates are relative to the new parí
ent's origin and specify the position of the upperíleft outer corner of the window. The width and
height specify the inside size, not including the border. If aboveísibling is None , then the winí
dow is on the bottom of the stack with respect to siblings. Otherwise, the window is immediately
on top of the specified sibling. The overrideíredirect flag is from the window's attribute.
78

íí íí
X Protocol X11, Release 6.4
GravityNotify
event, window : WINDOW
x, y : INT16
This event is reported to clients selecting SubstructureNotify on the parent and to clients selectí
ing 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 orií
gin and specify the position of the upperíleft outer corner of the window.
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.
ConfigureRequest
parent, window : WINDOW
x, y : INT16
width, height, borderíwidth : CARD16
sibling: WINDOW or None
stackímode : {Above , Below , TopIf , BottomIf , Opposite}
valueímask: BITMASK
This event is reported to the client selecting SubstructureRedirect on the parent and is generí
ated when a ConfigureWindow request is issued on the window by some other client. The
valueímask indicates which components were specified in the request. The valueímask and the
corresponding values are reported as given in the request. The remaining values are filled in from
the current geometry of the window, except in the case of sibling and stackímode, which are
reported as None and Above (respectively) if not given in the request.
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.
79

íí íí
X Protocol X11, Release 6.4
CirculateRequest
parent, window : WINDOW
place: {Top , Bottom}
This event is reported to the client selecting SubstructureRedirect on the parent and is generí
ated 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
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 replací
ing 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
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
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 Convertí
Selection request. The owner argument is the window that was specified in the SetSelecí
tionOwner 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 Selectioní
Notify back to the requestor. A complete specification for using selections is given in the X Coní
sortium standard InteríClient Communication Conventions Manual.
80

íí íí
X Protocol X11, Release 6.4
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 selecí
tion has been converted and stored as a property or when a selection conversion could not be perí
formed (indicated with property None).
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
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 indií
cate the range of altered keycodes.
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.
81

íí íí
X Protocol X11, Release 6.4
12. Flow Control and Concurrency
Whenever the server is writing to a given connection, it is permissible for the server to stop readí
ing from that connection (but if the writing would block, it must continue to service other connecí
tions). 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.
82

íí íí
X Protocol X11, Release 6.4
Appendix A
KEYSYM Encoding
For convenience, KEYSYM values are viewed as split into four bytes:
. Byte 1 (for the purposes of this encoding) is the mostísignificant 5 bits (because of the
29íbit effective values)
. Byte 2 is the next mostísignificant 8 bits
. Byte 3 is the next mostísignificant 8 bits
. Byte 4 is the leastísignificant 8 bits
There are two special KEYSYM values: NoSymbol and VoidSymbol . They are used to indicate
the absence of symbols (see section 5).
Byte 1 Byte 2 Byte 3 Byte 4 Name
0 0 0 0 NoSymbol
0 255 255 255 VoidSymbol
All other standard KEYSYM values have zero values for bytes 1 and 2. Byte 3 indicates a charí
acter code set, and byte 4 indicates a particular character within that set.
Byte 3 Byte 4
0 Latiní1
1 Latiní2
2 Latiní3
3 Latiní4
4 Kana
5 Arabic
6 Cyrillic
7 Greek
8 Technical
9 Special
10 Publishing
11 APL
12 Hebrew
13 Thai
14 Korean
255 Keyboard
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 94 and 96 character code sets have been moved to occupy the rightíhand quadrant (decimal
129 through 256), so the ASCII subset has a unique encoding across byte 4, which corresponds to
the ASCII character code. However, this cannot be guaranteed with future registrations and does
not apply to all of the Keyboard set.
To the best of our knowledge, the Latin, Kana, Arabic, Cyrillic, Greek, APL, and Hebrew sets are
from the appropriate ISO and/or ECMA international standards. There are no Technical, Special,
83

íí íí
X Protocol X11, Release 6.4
or Publishing international standards, so these sets are based on Digital Equipment Corporation
standards.
The ordering between the sets (byte 3) is essentially arbitrary. National and international staní
dards bodies were commencing deliberations regarding international 2íbyte and 4íbyte character
sets at the time these keysyms were developed, but we did not know of any proposed layouts.
The order may be arbitrary, but it is important in dealing with duplicate coding. As far as possií
ble, keysym values (byte 4) follow the character set encoding standards, except for the Greek and
Cyrillic keysyms which are based on early draft standards. In the Latiní1 to Latiní4 sets, all
duplicate glyphs occupy the same code position. However, duplicates between Greek and Technií
cal do not occupy the same code position. Applications that wish to use the Latiní2, Latiní3,
Latiní4, Greek, Cyrillic, or Technical sets may find it convenient to use arrays to transform the
keysyms.
There is a difference between European and US usage of the names Pilcrow, Paragraph, and Secí
tion, as follows:
US name European name code position in Latiní1
Section sign Paragraph sign 10/07
Paragraph sign Pilcrow sign 11/06
We have adopted the US names (by accident rather than by design).
The Keyboard set is a miscellaneous collection of commonly occurring keys on keyboards.
Within this set, the 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 distinguishí
able semantics associated with them.
Keyboards tend to be comparatively standard with respect to the alphanumeric keys, but they difí
fer radically on the miscellaneous function keys. Many function keys are left over from early
timesharing days or are designed for a specific application. Keyboard layouts from large manuí
facturers tend to have lots of keys for every conceivable purpose, whereas small workstation maní
ufacturers often add keys that are solely for support of some of their unique functionality. 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 funcí
tion 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. One estimate is that there
would be on the order of 300-500 Keyboard keysyms using this approach, without counting forí
eign translations and variations.
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 would be expected to 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
84

íí íí
X Protocol X11, Release 6.4
single keysym. Under this scheme there are an estimated 100-150 keysyms.
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 siní
gle keysym allows an application to implement a deletion function and expect reasonable bindí
ings 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.
In the listings below, Code Pos is a representation of byte 4 of the KEYSYM value, expressed as
mostísignificant/leastísignificant 4íbit values. The Code Pos numbers are for reference only and
do not affect the KEYSYM value. In all cases, the KEYSYM value is:
byte3 * 256 + byte4
Byte Byte Code Name Set
3 4 Pos
000 032 02/00 SPACE Latiní1
000 033 02/01 EXCLAMATION POINT Latiní1
000 034 02/02 QUOTATION MARK Latiní1
000 035 02/03 NUMBER SIGN Latiní1
000 036 02/04 DOLLAR SIGN Latiní1
000 037 02/05 PERCENT SIGN Latiní1
000 038 02/06 AMPERSAND Latiní1
000 039 02/07 APOSTROPHE Latiní1
000 040 02/08 LEFT PARENTHESIS Latiní1
000 041 02/09 RIGHT PARENTHESIS Latiní1
000 042 02/10 ASTERISK Latiní1
000 043 02/11 PLUS SIGN Latiní1
000 044 02/12 COMMA Latiní1
000 045 02/13 MINUS SIGN Latiní1
000 046 02/14 FULL STOP Latiní1
000 047 02/15 SOLIDUS Latiní1
000 048 03/00 DIGIT ZERO Latiní1
000 049 03/01 DIGIT ONE Latiní1
000 050 03/02 DIGIT TWO Latiní1
000 051 03/03 DIGIT THREE Latiní1
000 052 03/04 DIGIT FOUR Latiní1
000 053 03/05 DIGIT FIVE Latiní1
000 054 03/06 DIGIT SIX Latiní1
000 055 03/07 DIGIT SEVEN Latiní1
000 056 03/08 DIGIT EIGHT Latiní1
000 057 03/09 DIGIT NINE Latiní1
000 058 03/10 COLON Latiní1
000 059 03/11 SEMICOLON Latiní1
000 060 03/12 LESS THAN SIGN Latiní1
000 061 03/13 EQUALS SIGN Latiní1
000 062 03/14 GREATER THAN SIGN Latiní1
000 063 03/15 QUESTION MARK Latiní1
000 064 04/00 COMMERCIAL AT Latiní1
000 065 04/01 LATIN CAPITAL LETTER A Latiní1
000 066 04/02 LATIN CAPITAL LETTER B Latiní1
000 067 04/03 LATIN CAPITAL LETTER C Latiní1
000 068 04/04 LATIN CAPITAL LETTER D Latiní1
000 069 04/05 LATIN CAPITAL LETTER E Latiní1
000 070 04/06 LATIN CAPITAL LETTER F Latiní1
000 071 04/07 LATIN CAPITAL LETTER G Latiní1
000 072 04/08 LATIN CAPITAL LETTER H Latiní1
000 073 04/09 LATIN CAPITAL LETTER I Latiní1
000 074 04/10 LATIN CAPITAL LETTER J Latiní1
85

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
000 075 04/11 LATIN CAPITAL LETTER K Latiní1
000 076 04/12 LATIN CAPITAL LETTER L Latiní1
000 077 04/13 LATIN CAPITAL LETTER M Latiní1
000 078 04/14 LATIN CAPITAL LETTER N Latiní1
000 079 04/15 LATIN CAPITAL LETTER O Latiní1
000 080 05/00 LATIN CAPITAL LETTER P Latiní1
000 081 05/01 LATIN CAPITAL LETTER Q Latiní1
000 082 05/02 LATIN CAPITAL LETTER R Latiní1
000 083 05/03 LATIN CAPITAL LETTER S Latiní1
000 084 05/04 LATIN CAPITAL LETTER T Latiní1
000 085 05/05 LATIN CAPITAL LETTER U Latiní1
000 086 05/06 LATIN CAPITAL LETTER V Latiní1
000 087 05/07 LATIN CAPITAL LETTER W Latiní1
000 088 05/08 LATIN CAPITAL LETTER X Latiní1
000 089 05/09 LATIN CAPITAL LETTER Y Latiní1
000 090 05/10 LATIN CAPITAL LETTER Z Latiní1
000 091 05/11 LEFT SQUARE BRACKET Latiní1
000 092 05/12 REVERSE SOLIDUS Latiní1
000 093 05/13 RIGHT SQUARE BRACKET Latiní1
000 094 05/14 CIRCUMFLEX ACCENT Latiní1
000 095 05/15 LOW LINE Latiní1
000 096 06/00 GRAVE ACCENT Latiní1
000 097 06/01 LATIN SMALL LETTER a Latiní1
000 098 06/02 LATIN SMALL LETTER b Latiní1
000 099 06/03 LATIN SMALL LETTER c Latiní1
000 100 06/04 LATIN SMALL LETTER d Latiní1
000 101 06/05 LATIN SMALL LETTER e Latiní1
000 102 06/06 LATIN SMALL LETTER f Latiní1
000 103 06/07 LATIN SMALL LETTER g Latiní1
000 104 06/08 LATIN SMALL LETTER h Latiní1
000 105 06/09 LATIN SMALL LETTER i Latiní1
000 106 06/10 LATIN SMALL LETTER j Latiní1
000 107 06/11 LATIN SMALL LETTER k Latiní1
000 108 06/12 LATIN SMALL LETTER l Latiní1
000 109 06/13 LATIN SMALL LETTER m Latiní1
000 110 06/14 LATIN SMALL LETTER n Latiní1
000 111 06/15 LATIN SMALL LETTER o Latiní1
000 112 07/00 LATIN SMALL LETTER p Latiní1
000 113 07/01 LATIN SMALL LETTER q Latiní1
000 114 07/02 LATIN SMALL LETTER r Latiní1
000 115 07/03 LATIN SMALL LETTER s Latiní1
000 116 07/04 LATIN SMALL LETTER t Latiní1
000 117 07/05 LATIN SMALL LETTER u Latiní1
000 118 07/06 LATIN SMALL LETTER v Latiní1
000 119 07/07 LATIN SMALL LETTER w Latiní1
000 120 07/08 LATIN SMALL LETTER x Latiní1
000 121 07/09 LATIN SMALL LETTER y Latiní1
000 122 07/10 LATIN SMALL LETTER z Latiní1
000 123 07/11 LEFT CURLY BRACKET Latiní1
000 124 07/12 VERTICAL LINE Latiní1
000 125 07/13 RIGHT CURLY BRACKET Latiní1
000 126 07/14 TILDE Latiní1
000 160 10/00 NOíBREAK SPACE Latiní1
000 161 10/01 INVERTED EXCLAMATION MARK Latiní1
000 162 10/02 CENT SIGN Latiní1
000 163 10/03 POUND SIGN Latiní1
000 164 10/04 CURRENCY SIGN Latiní1
000 165 10/05 YEN SIGN Latiní1
000 166 10/06 BROKEN VERTICAL BAR Latiní1
000 167 10/07 SECTION SIGN Latiní1
86

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
000 168 10/08 DIAERESIS Latiní1
000 169 10/09 COPYRIGHT SIGN Latiní1
000 170 10/10 FEMININE ORDINAL INDICATOR Latiní1
000 171 10/11 LEFT ANGLE QUOTATION MARK Latiní1
000 172 10/12 NOT SIGN Latiní1
000 173 10/13 HYPHEN Latiní1
000 174 10/14 REGISTERED TRADEMARK SIGN Latiní1
000 175 10/15 MACRON Latiní1
000 176 11/00 DEGREE SIGN, RING ABOVE Latiní1
000 177 11/01 PLUSíMINUS SIGN Latiní1
000 178 11/02 SUPERSCRIPT TWO Latiní1
000 179 11/03 SUPERSCRIPT THREE Latiní1
000 180 11/04 ACUTE ACCENT Latiní1
000 181 11/05 MICRO SIGN Latiní1
000 182 11/06 PARAGRAPH SIGN Latiní1
000 183 11/07 MIDDLE DOT Latiní1
000 184 11/08 CEDILLA Latiní1
000 185 11/09 SUPERSCRIPT ONE Latiní1
000 186 11/10 MASCULINE ORDINAL INDICATOR Latiní1
000 187 11/11 RIGHT ANGLE QUOTATION MARK Latiní1
000 188 11/12 VULGAR FRACTION ONE QUARTER Latiní1
000 189 11/13 VULGAR FRACTION ONE HALF Latiní1
000 190 11/14 VULGAR FRACTION THREE QUARTERS Latiní1
000 191 11/15 INVERTED QUESTION MARK Latiní1
000 192 12/00 LATIN CAPITAL LETTER A WITH GRAVE ACCENT Latiní1
000 193 12/01 LATIN CAPITAL LETTER A WITH ACUTE ACCENT Latiní1
000 194 12/02 LATIN CAPITAL LETTER A WITH CIRCUMFLEX ACCENT Latiní1
000 195 12/03 LATIN CAPITAL LETTER A WITH TILDE Latiní1
000 196 12/04 LATIN CAPITAL LETTER A WITH DIAERESIS Latiní1
000 197 12/05 LATIN CAPITAL LETTER A WITH RING ABOVE Latiní1
000 198 12/06 LATIN CAPITAL DIPHTHONG AE Latiní1
000 199 12/07 LATIN CAPITAL LETTER C WITH CEDILLA Latiní1
000 200 12/08 LATIN CAPITAL LETTER E WITH GRAVE ACCENT Latiní1
000 201 12/09 LATIN CAPITAL LETTER E WITH ACUTE ACCENT Latiní1
000 202 12/10 LATIN CAPITAL LETTER E WITH CIRCUMFLEX ACCENT Latiní1
000 203 12/11 LATIN CAPITAL LETTER E WITH DIAERESIS Latiní1
000 204 12/12 LATIN CAPITAL LETTER I WITH GRAVE ACCENT Latiní1
000 205 12/13 LATIN CAPITAL LETTER I WITH ACUTE ACCENT Latiní1
000 206 12/14 LATIN CAPITAL LETTER I WITH CIRCUMFLEX ACCENT Latiní1
000 207 12/15 LATIN CAPITAL LETTER I WITH DIAERESIS Latiní1
000 208 13/00 ICELANDIC CAPITAL LETTER ETH Latiní1
000 209 13/01 LATIN CAPITAL LETTER N WITH TILDE Latiní1
000 210 13/02 LATIN CAPITAL LETTER O WITH GRAVE ACCENT Latiní1
000 211 13/03 LATIN CAPITAL LETTER O WITH ACUTE ACCENT Latiní1
000 212 13/04 LATIN CAPITAL LETTER O WITH CIRCUMFLEX ACCENT Latiní1
000 213 13/05 LATIN CAPITAL LETTER O WITH TILDE Latiní1
000 214 13/06 LATIN CAPITAL LETTER O WITH DIAERESIS Latiní1
000 215 13/07 MULTIPLICATION SIGN Latiní1
000 216 13/08 LATIN CAPITAL LETTER O WITH OBLIQUE STROKE Latiní1
000 217 13/09 LATIN CAPITAL LETTER U WITH GRAVE ACCENT Latiní1
000 218 13/10 LATIN CAPITAL LETTER U WITH ACUTE ACCENT Latiní1
000 219 13/11 LATIN CAPITAL LETTER U WITH CIRCUMFLEX ACCENT Latiní1
000 220 13/12 LATIN CAPITAL LETTER U WITH DIAERESIS Latiní1
000 221 13/13 LATIN CAPITAL LETTER Y WITH ACUTE ACCENT Latiní1
000 222 13/14 ICELANDIC CAPITAL LETTER THORN Latiní1
000 223 13/15 GERMAN SMALL LETTER SHARP s Latiní1
000 224 14/00 LATIN SMALL LETTER a WITH GRAVE ACCENT Latiní1
000 225 14/01 LATIN SMALL LETTER a WITH ACUTE ACCENT Latiní1
000 226 14/02 LATIN SMALL LETTER a WITH CIRCUMFLEX ACCENT Latiní1
000 227 14/03 LATIN SMALL LETTER a WITH TILDE Latiní1
87

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
000 228 14/04 LATIN SMALL LETTER a WITH DIAERESIS Latiní1
000 229 14/05 LATIN SMALL LETTER a WITH RING ABOVE Latiní1
000 230 14/06 LATIN SMALL DIPHTHONG ae Latiní1
000 231 14/07 LATIN SMALL LETTER c WITH CEDILLA Latiní1
000 232 14/08 LATIN SMALL LETTER e WITH GRAVE ACCENT Latiní1
000 233 14/09 LATIN SMALL LETTER e WITH ACUTE ACCENT Latiní1
000 234 14/10 LATIN SMALL LETTER e WITH CIRCUMFLEX ACCENT Latiní1
000 235 14/11 LATIN SMALL LETTER e WITH DIAERESIS Latiní1
000 236 14/12 LATIN SMALL LETTER i WITH GRAVE ACCENT Latiní1
000 237 14/13 LATIN SMALL LETTER i WITH ACUTE ACCENT Latiní1
000 238 14/14 LATIN SMALL LETTER i WITH CIRCUMFLEX ACCENT Latiní1
000 239 14/15 LATIN SMALL LETTER i WITH DIAERESIS Latiní1
000 240 15/00 ICELANDIC SMALL LETTER ETH Latiní1
000 241 15/01 LATIN SMALL LETTER n WITH TILDE Latiní1
000 242 15/02 LATIN SMALL LETTER o WITH GRAVE ACCENT Latiní1
000 243 15/03 LATIN SMALL LETTER o WITH ACUTE ACCENT Latiní1
000 244 15/04 LATIN SMALL LETTER o WITH CIRCUMFLEX ACCENT Latiní1
000 245 15/05 LATIN SMALL LETTER o WITH TILDE Latiní1
000 246 15/06 LATIN SMALL LETTER o WITH DIAERESIS Latiní1
000 247 15/07 DIVISION SIGN Latiní1
000 248 15/08 LATIN SMALL LETTER o WITH OBLIQUE STROKE Latiní1
000 249 15/09 LATIN SMALL LETTER u WITH GRAVE ACCENT Latiní1
000 250 15/10 LATIN SMALL LETTER u WITH ACUTE ACCENT Latiní1
000 251 15/11 LATIN SMALL LETTER u WITH CIRCUMFLEX ACCENT Latiní1
000 252 15/12 LATIN SMALL LETTER u WITH DIAERESIS Latiní1
000 253 15/13 LATIN SMALL LETTER y WITH ACUTE ACCENT Latiní1
000 254 15/14 ICELANDIC SMALL LETTER THORN Latiní1
000 255 15/15 LATIN SMALL LETTER y WITH DIAERESIS Latiní1
001 161 10/01 LATIN CAPITAL LETTER A WITH OGONEK Latiní2
001 162 10/02 BREVE Latiní2
001 163 10/03 LATIN CAPITAL LETTER L WITH STROKE Latiní2
001 165 10/05 LATIN CAPITAL LETTER L WITH CARON Latiní2
001 166 10/06 LATIN CAPITAL LETTER S WITH ACUTE ACCENT Latiní2
001 169 10/09 LATIN CAPITAL LETTER S WITH CARON Latiní2
001 170 10/10 LATIN CAPITAL LETTER S WITH CEDILLA Latiní2
001 171 10/11 LATIN CAPITAL LETTER T WITH CARON Latiní2
001 172 10/12 LATIN CAPITAL LETTER Z WITH ACUTE ACCENT Latiní2
001 174 10/14 LATIN CAPITAL LETTER Z WITH CARON Latiní2
001 175 10/15 LATIN CAPITAL LETTER Z WITH DOT ABOVE Latiní2
001 177 11/01 LATIN SMALL LETTER a WITH OGONEK Latiní2
001 178 11/02 OGONEK Latiní2
001 179 11/03 LATIN SMALL LETTER l WITH STROKE Latiní2
001 181 11/05 LATIN SMALL LETTER l WITH CARON Latiní2
001 182 11/06 LATIN SMALL LETTER s WITH ACUTE ACCENT Latiní2
001 183 11/07 CARON Latiní2
001 185 11/09 LATIN SMALL LETTER s WITH CARON Latiní2
001 186 11/10 LATIN SMALL LETTER s WITH CEDILLA Latiní2
001 187 11/11 LATIN SMALL LETTER t WITH CARON Latiní2
001 188 11/12 LATIN SMALL LETTER z WITH ACUTE ACCENT Latiní2
001 189 11/13 DOUBLE ACUTE ACCENT Latiní2
001 190 11/14 LATIN SMALL LETTER z WITH CARON Latiní2
001 191 11/15 LATIN SMALL LETTER z WITH DOT ABOVE Latiní2
001 192 12/00 LATIN CAPITAL LETTER R WITH ACUTE ACCENT Latiní2
001 195 12/03 LATIN CAPITAL LETTER A WITH BREVE Latiní2
001 197 12/05 LATIN CAPITAL LETTER L WITH ACUTE ACCENT Latiní2
001 198 12/06 LATIN CAPITAL LETTER C WITH ACUTE ACCENT Latiní2
001 200 12/08 LATIN CAPITAL LETTER C WITH CARON Latiní2
001 202 12/10 LATIN CAPITAL LETTER E WITH OGONEK Latiní2
88

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
001 204 12/12 LATIN CAPITAL LETTER E WITH CARON Latiní2
001 207 12/15 LATIN CAPITAL LETTER D WITH CARON Latiní2
001 208 13/00 LATIN CAPITAL LETTER D WITH STROKE Latiní2
001 209 13/01 LATIN CAPITAL LETTER N WITH ACUTE ACCENT Latiní2
001 210 13/02 LATIN CAPITAL LETTER N WITH CARON Latiní2
001 213 13/05 LATIN CAPITAL LETTER O WITH DOUBLE ACUTE ACCENT Latiní2
001 216 13/08 LATIN CAPITAL LETTER R WITH CARON Latiní2
001 217 13/09 LATIN CAPITAL LETTER U WITH RING ABOVE Latiní2
001 219 13/11 LATIN CAPITAL LETTER U WITH DOUBLE ACUTE ACCENT Latiní2
001 222 13/14 LATIN CAPITAL LETTER T WITH CEDILLA Latiní2
001 224 14/00 LATIN SMALL LETTER r WITH ACUTE ACCENT Latiní2
001 227 14/03 LATIN SMALL LETTER a WITH BREVE Latiní2
001 229 14/05 LATIN SMALL LETTER l WITH ACUTE ACCENT Latiní2
001 230 14/06 LATIN SMALL LETTER c WITH ACUTE ACCENT Latiní2
001 232 14/08 LATIN SMALL LETTER c WITH CARON Latiní2
001 234 14/10 LATIN SMALL LETTER e WITH OGONEK Latiní2
001 236 14/12 LATIN SMALL LETTER e WITH CARON Latiní2
001 239 14/15 LATIN SMALL LETTER d WITH CARON Latiní2
001 240 15/00 LATIN SMALL LETTER d WITH STROKE Latiní2
001 241 15/01 LATIN SMALL LETTER n WITH ACUTE ACCENT Latiní2
001 242 15/02 LATIN SMALL LETTER n WITH CARON Latiní2
001 245 15/05 LATIN SMALL LETTER o WITH DOUBLE ACUTE ACCENT Latiní2
001 248 15/08 LATIN SMALL LETTER r WITH CARON Latiní2
001 249 15/09 LATIN SMALL LETTER u WITH RING ABOVE Latiní2
001 251 15/11 LATIN SMALL LETTER u WITH DOUBLE ACUTE ACCENT Latiní2
001 254 15/14 LATIN SMALL LETTER t WITH CEDILLA Latiní2
001 255 15/15 DOT ABOVE Latiní2
002 161 10/01 LATIN CAPITAL LETTER H WITH STROKE Latiní3
002 166 10/06 LATIN CAPITAL LETTER H WITH CIRCUMFLEX ACCENT Latiní3
002 169 10/09 LATIN CAPITAL LETTER I WITH DOT ABOVE Latiní3
002 171 10/11 LATIN CAPITAL LETTER G WITH BREVE Latiní3
002 172 10/12 LATIN CAPITAL LETTER J WITH CIRCUMFLEX ACCENT Latiní3
002 177 11/01 LATIN SMALL LETTER h WITH STROKE Latiní3
002 182 11/06 LATIN SMALL LETTER h WITH CIRCUMFLEX ACCENT Latiní3
002 185 11/09 SMALL DOTLESS LETTER i Latiní3
002 187 11/11 LATIN SMALL LETTER g WITH BREVE Latiní3
002 188 11/12 LATIN SMALL LETTER j WITH CIRCUMFLEX ACCENT Latiní3
002 197 12/05 LATIN CAPITAL LETTER C WITH DOT ABOVE Latiní3
002 198 12/06 LATIN CAPITAL LETTER C WITH CIRCUMFLEX ACCENT Latiní3
002 213 13/05 LATIN CAPITAL LETTER G WITH DOT ABOVE Latiní3
002 216 13/08 LATIN CAPITAL LETTER G WITH CIRCUMFLEX ACCENT Latiní3
002 221 13/13 LATIN CAPITAL LETTER U WITH BREVE Latiní3
002 222 13/14 LATIN CAPITAL LETTER S WITH CIRCUMFLEX ACCENT Latiní3
002 229 14/05 LATIN SMALL LETTER c WITH DOT ABOVE Latiní3
002 230 14/06 LATIN SMALL LETTER c WITH CIRCUMFLEX ACCENT Latiní3
002 245 15/05 LATIN SMALL LETTER g WITH DOT ABOVE Latiní3
002 248 15/08 LATIN SMALL LETTER g WITH CIRCUMFLEX ACCENT Latiní3
002 253 15/13 LATIN SMALL LETTER u WITH BREVE Latiní3
002 254 15/14 LATIN SMALL LETTER s WITH CIRCUMFLEX ACCENT Latiní3
003 162 10/02 SMALL GREENLANDIC LETTER KRA Latiní4
003 163 10/03 LATIN CAPITAL LETTER R WITH CEDILLA Latiní4
003 165 10/05 LATIN CAPITAL LETTER I WITH TILDE Latiní4
003 166 10/06 LATIN CAPITAL LETTER L WITH CEDILLA Latiní4
003 170 10/10 LATIN CAPITAL LETTER E WITH MACRON Latiní4
003 171 10/11 LATIN CAPITAL LETTER G WITH CEDILLA Latiní4
003 172 10/12 LATIN CAPITAL LETTER T WITH OBLIQUE STROKE Latiní4
89

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
003 179 11/03 LATIN SMALL LETTER r WITH CEDILLA Latiní4
003 181 11/05 LATIN SMALL LETTER i WITH TILDE Latiní4
003 182 11/06 LATIN SMALL LETTER l WITH CEDILLA Latiní4
003 186 11/10 LATIN SMALL LETTER e WITH MACRON Latiní4
003 187 11/11 LATIN SMALL LETTER g WITH CEDILLA ABOVE Latiní4
003 188 11/12 LATIN SMALL LETTER t WITH OBLIQUE STROKE Latiní4
003 189 11/13 LAPPISH CAPITAL LETTER ENG Latiní4
003 191 11/15 LAPPISH SMALL LETTER ENG Latiní4
003 192 12/00 LATIN CAPITAL LETTER A WITH MACRON Latiní4
003 199 12/07 LATIN CAPITAL LETTER I WITH OGONEK Latiní4
003 204 12/12 LATIN CAPITAL LETTER E WITH DOT ABOVE Latiní4
003 207 12/15 LATIN CAPITAL LETTER I WITH MACRON Latiní4
003 209 13/01 LATIN CAPITAL LETTER N WITH CEDILLA Latiní4
003 210 13/02 LATIN CAPITAL LETTER O WITH MACRON Latiní4
003 211 13/03 LATIN CAPITAL LETTER K WITH CEDILLA Latiní4
003 217 13/09 LATIN CAPITAL LETTER U WITH OGONEK Latiní4
003 221 13/13 LATIN CAPITAL LETTER U WITH TILDE Latiní4
003 222 13/14 LATIN CAPITAL LETTER U WITH MACRON Latiní4
003 224 14/00 LATIN SMALL LETTER a WITH MACRON Latiní4
003 231 14/07 LATIN SMALL LETTER i WITH OGONEK Latiní4
003 236 14/12 LATIN SMALL LETTER e WITH DOT ABOVE Latiní4
003 239 14/15 LATIN SMALL LETTER i WITH MACRON Latiní4
003 241 15/01 LATIN SMALL LETTER n WITH CEDILLA Latiní4
003 242 15/02 LATIN SMALL LETTER o WITH MACRON Latiní4
003 243 15/03 LATIN SMALL LETTER k WITH CEDILLA Latiní4
003 249 15/09 LATIN SMALL LETTER u WITH OGONEK Latiní4
003 253 15/13 LATIN SMALL LETTER u WITH TILDE Latiní4
003 254 15/14 LATIN SMALL LETTER u WITH MACRON Latiní4
004 126 07/14 OVERLINE Kana
004 161 10/01 KANA FULL STOP Kana
004 162 10/02 KANA OPENING BRACKET Kana
004 163 10/03 KANA CLOSING BRACKET Kana
004 164 10/04 KANA COMMA Kana
004 165 10/05 KANA CONJUNCTIVE Kana
004 166 10/06 KANA LETTER WO Kana
004 167 10/07 KANA LETTER SMALL A Kana
004 168 10/08 KANA LETTER SMALL I Kana
004 169 10/09 KANA LETTER SMALL U Kana
004 170 10/10 KANA LETTER SMALL E Kana
004 171 10/11 KANA LETTER SMALL O Kana
004 172 10/12 KANA LETTER SMALL YA Kana
004 173 10/13 KANA LETTER SMALL YU Kana
004 174 10/14 KANA LETTER SMALL YO Kana
004 175 10/15 KANA LETTER SMALL TSU Kana
004 176 11/00 PROLONGED SOUND SYMBOL Kana
004 177 11/01 KANA LETTER A Kana
004 178 11/02 KANA LETTER I Kana
004 179 11/03 KANA LETTER U Kana
004 180 11/04 KANA LETTER E Kana
004 181 11/05 KANA LETTER O Kana
004 182 11/06 KANA LETTER KA Kana
004 183 11/07 KANA LETTER KI Kana
004 184 11/08 KANA LETTER KU Kana
004 185 11/09 KANA LETTER KE Kana
004 186 11/10 KANA LETTER KO Kana
004 187 11/11 KANA LETTER SA Kana
004 188 11/12 KANA LETTER SHI Kana
004 189 11/13 KANA LETTER SU Kana
90

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
004 190 11/14 KANA LETTER SE Kana
004 191 11/15 KANA LETTER SO Kana
004 192 12/00 KANA LETTER TA Kana
004 193 12/01 KANA LETTER CHI Kana
004 194 12/02 KANA LETTER TSU Kana
004 195 12/03 KANA LETTER TE Kana
004 196 12/04 KANA LETTER TO Kana
004 197 12/05 KANA LETTER NA Kana
004 198 12/06 KANA LETTER NI Kana
004 199 12/07 KANA LETTER NU Kana
004 200 12/08 KANA LETTER NE Kana
004 201 12/09 KANA LETTER NO Kana
004 202 12/10 KANA LETTER HA Kana
004 203 12/11 KANA LETTER HI Kana
004 204 12/12 KANA LETTER FU Kana
004 205 12/13 KANA LETTER HE Kana
004 206 12/14 KANA LETTER HO Kana
004 207 12/15 KANA LETTER MA Kana
004 208 13/00 KANA LETTER MI Kana
004 209 13/01 KANA LETTER MU Kana
004 210 13/02 KANA LETTER ME Kana
004 211 13/03 KANA LETTER MO Kana
004 212 13/04 KANA LETTER YA Kana
004 213 13/05 KANA LETTER YU Kana
004 214 13/06 KANA LETTER YO Kana
004 215 13/07 KANA LETTER RA Kana
004 216 13/08 KANA LETTER RI Kana
004 217 13/09 KANA LETTER RU Kana
004 218 13/10 KANA LETTER RE Kana
004 219 13/11 KANA LETTER RO Kana
004 220 13/12 KANA LETTER WA Kana
004 221 13/13 KANA LETTER N Kana
004 222 13/14 VOICED SOUND SYMBOL Kana
004 223 13/15 SEMIVOICED SOUND SYMBOL Kana
005 172 10/12 ARABIC COMMA Arabic
005 187 11/11 ARABIC SEMICOLON Arabic
005 191 11/15 ARABIC QUESTION MARK Arabic
005 193 12/01 ARABIC LETTER HAMZA Arabic
005 194 12/02 ARABIC LETTER MADDA ON ALEF Arabic
005 195 12/03 ARABIC LETTER HAMZA ON ALEF Arabic
005 196 12/04 ARABIC LETTER HAMZA ON WAW Arabic
005 197 12/05 ARABIC LETTER HAMZA UNDER ALEF Arabic
005 198 12/06 ARABIC LETTER HAMZA ON YEH Arabic
005 199 12/07 ARABIC LETTER ALEF Arabic
005 200 12/08 ARABIC LETTER BEH Arabic
005 201 12/09 ARABIC LETTER TEH MARBUTA Arabic
005 202 12/10 ARABIC LETTER TEH Arabic
005 203 12/11 ARABIC LETTER THEH Arabic
005 204 12/12 ARABIC LETTER JEEM Arabic
005 205 12/13 ARABIC LETTER HAH Arabic
005 206 12/14 ARABIC LETTER KHAH Arabic
005 207 12/15 ARABIC LETTER DAL Arabic
005 208 13/00 ARABIC LETTER THAL Arabic
005 209 13/01 ARABIC LETTER RA Arabic
005 210 13/02 ARABIC LETTER ZAIN Arabic
005 211 13/03 ARABIC LETTER SEEN Arabic
005 212 13/04 ARABIC LETTER SHEEN Arabic
005 213 13/05 ARABIC LETTER SAD Arabic
91

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
005 214 13/06 ARABIC LETTER DAD Arabic
005 215 13/07 ARABIC LETTER TAH Arabic
005 216 13/08 ARABIC LETTER ZAH Arabic
005 217 13/09 ARABIC LETTER AIN Arabic
005 218 13/10 ARABIC LETTER GHAIN Arabic
005 224 14/00 ARABIC LETTER TATWEEL Arabic
005 225 14/01 ARABIC LETTER FEH Arabic
005 226 14/02 ARABIC LETTER QAF Arabic
005 227 14/03 ARABIC LETTER KAF Arabic
005 228 14/04 ARABIC LETTER LAM Arabic
005 229 14/05 ARABIC LETTER MEEM Arabic
005 230 14/06 ARABIC LETTER NOON Arabic
005 231 14/07 ARABIC LETTER HA Arabic
005 232 14/08 ARABIC LETTER WAW Arabic
005 233 14/09 ARABIC LETTER ALEF MAKSURA Arabic
005 234 14/10 ARABIC LETTER YEH Arabic
005 235 14/11 ARABIC LETTER FATHATAN Arabic
005 236 14/12 ARABIC LETTER DAMMATAN Arabic
005 237 14/13 ARABIC LETTER KASRATAN Arabic
005 238 14/14 ARABIC LETTER FATHA Arabic
005 239 14/15 ARABIC LETTER DAMMA Arabic
005 240 15/00 ARABIC LETTER KASRA Arabic
005 241 15/01 ARABIC LETTER SHADDA Arabic
005 242 15/02 ARABIC LETTER SUKUN Arabic
006 161 10/01 SERBOCROATION CYRILLIC SMALL LETTER DJE Cyrillic
006 162 10/02 MACEDONIAN CYRILLIC SMALL LETTER GJE Cyrillic
006 163 10/03 CYRILLIC SMALL LETTER IO Cyrillic
006 164 10/04 UKRAINIAN CYRILLIC SMALL LETTER IE Cyrillic
006 165 10/05 MACEDONIAN SMALL LETTER DSE Cyrillic
006 166 10/06 BYELORUSSIAN/UKRAINIAN CYRILLIC SMALL LETTER I Cyrillic
006 167 10/07 UKRAINIAN SMALL LETTER YI Cyrillic
006 168 10/08 CYRILLIC SMALL LETTER JE Cyrillic
006 169 10/09 CYRILLIC SMALL LETTER LJE Cyrillic
006 170 10/10 CYRILLIC SMALL LETTER NJE Cyrillic
006 171 10/11 SERBIAN SMALL LETTER TSHE Cyrillic
006 172 10/12 MACEDONIAN CYRILLIC SMALL LETTER KJE Cyrillic
006 174 10/14 BYELORUSSIAN SMALL LETTER SHORT U Cyrillic
006 175 10/15 CYRILLIC SMALL LETTER DZHE Cyrillic
006 176 11/00 NUMERO SIGN Cyrillic
006 177 11/01 SERBOCROATIAN CYRILLIC CAPITAL LETTER DJE Cyrillic
006 178 11/02 MACEDONIAN CYRILLIC CAPITAL LETTER GJE Cyrillic
006 179 11/03 CYRILLIC CAPITAL LETTER IO Cyrillic
006 180 11/04 UKRAINIAN CYRILLIC CAPITAL LETTER IE Cyrillic
006 181 11/05 MACEDONIAN CAPITAL LETTER DSE Cyrillic
006 182 11/06 BYELORUSSIAN/UKRAINIAN CYRILLIC CAPITAL LETTER I Cyrillic
006 183 11/07 UKRAINIAN CAPITAL LETTER YI Cyrillic
006 184 11/08 CYRILLIC CAPITAL LETTER JE Cyrillic
006 185 11/09 CYRILLIC CAPITAL LETTER LJE Cyrillic
006 186 11/10 CYRILLIC CAPITAL LETTER NJE Cyrillic
006 187 11/11 SERBIAN CAPITAL LETTER TSHE Cyrillic
006 188 11/12 MACEDONIAN CYRILLIC CAPITAL LETTER KJE Cyrillic
006 190 11/14 BYELORUSSIAN CAPITAL LETTER SHORT U Cyrillic
006 191 11/15 CYRILLIC CAPITAL LETTER DZHE Cyrillic
006 192 12/00 CYRILLIC SMALL LETTER YU Cyrillic
006 193 12/01 CYRILLIC SMALL LETTER A Cyrillic
006 194 12/02 CYRILLIC SMALL LETTER BE Cyrillic
006 195 12/03 CYRILLIC SMALL LETTER TSE Cyrillic
006 196 12/04 CYRILLIC SMALL LETTER DE Cyrillic
92

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
006 197 12/05 CYRILLIC SMALL LETTER IE Cyrillic
006 198 12/06 CYRILLIC SMALL LETTER EF Cyrillic
006 199 12/07 CYRILLIC SMALL LETTER GHE Cyrillic
006 200 12/08 CYRILLIC SMALL LETTER HA Cyrillic
006 201 12/09 CYRILLIC SMALL LETTER I Cyrillic
006 202 12/10 CYRILLIC SMALL LETTER SHORT I Cyrillic
006 203 12/11 CYRILLIC SMALL LETTER KA Cyrillic
006 204 12/12 CYRILLIC SMALL LETTER EL Cyrillic
006 205 12/13 CYRILLIC SMALL LETTER EM Cyrillic
006 206 12/14 CYRILLIC SMALL LETTER EN Cyrillic
006 207 12/15 CYRILLIC SMALL LETTER O Cyrillic
006 208 13/00 CYRILLIC SMALL LETTER PE Cyrillic
006 209 13/01 CYRILLIC SMALL LETTER YA Cyrillic
006 210 13/02 CYRILLIC SMALL LETTER ER Cyrillic
006 211 13/03 CYRILLIC SMALL LETTER ES Cyrillic
006 212 13/04 CYRILLIC SMALL LETTER TE Cyrillic
006 213 13/05 CYRILLIC SMALL LETTER U Cyrillic
006 214 13/06 CYRILLIC SMALL LETTER ZHE Cyrillic
006 215 13/07 CYRILLIC SMALL LETTER VE Cyrillic
006 216 13/08 CYRILLIC SMALL SOFT SIGN Cyrillic
006 217 13/09 CYRILLIC SMALL LETTER YERU Cyrillic
006 218 13/10 CYRILLIC SMALL LETTER ZE Cyrillic
006 219 13/11 CYRILLIC SMALL LETTER SHA Cyrillic
006 220 13/12 CYRILLIC SMALL LETTER E Cyrillic
006 221 13/13 CYRILLIC SMALL LETTER SHCHA Cyrillic
006 222 13/14 CYRILLIC SMALL LETTER CHE Cyrillic
006 223 13/15 CYRILLIC SMALL HARD SIGN Cyrillic
006 224 14/00 CYRILLIC CAPITAL LETTER YU Cyrillic
006 225 14/01 CYRILLIC CAPITAL LETTER A Cyrillic
006 226 14/02 CYRILLIC CAPITAL LETTER BE Cyrillic
006 227 14/03 CYRILLIC CAPITAL LETTER TSE Cyrillic
006 228 14/04 CYRILLIC CAPITAL LETTER DE Cyrillic
006 229 14/05 CYRILLIC CAPITAL LETTER IE Cyrillic
006 230 14/06 CYRILLIC CAPITAL LETTER EF Cyrillic
006 231 14/07 CYRILLIC CAPITAL LETTER GHE Cyrillic
006 232 14/08 CYRILLIC CAPITAL LETTER HA Cyrillic
006 233 14/09 CYRILLIC CAPITAL LETTER I Cyrillic
006 234 14/10 CYRILLIC CAPITAL LETTER SHORT I Cyrillic
006 235 14/11 CYRILLIC CAPITAL LETTER KA Cyrillic
006 236 14/12 CYRILLIC CAPITAL LETTER EL Cyrillic
006 237 14/13 CYRILLIC CAPITAL LETTER EM Cyrillic
006 238 14/14 CYRILLIC CAPITAL LETTER EN Cyrillic
006 239 14/15 CYRILLIC CAPITAL LETTER O Cyrillic
006 240 15/00 CYRILLIC CAPITAL LETTER PE Cyrillic
006 241 15/01 CYRILLIC CAPITAL LETTER YA Cyrillic
006 242 15/02 CYRILLIC CAPITAL LETTER ER Cyrillic
006 243 15/03 CYRILLIC CAPITAL LETTER ES Cyrillic
006 244 15/04 CYRILLIC CAPITAL LETTER TE Cyrillic
006 245 15/05 CYRILLIC CAPITAL LETTER U Cyrillic
006 246 15/06 CYRILLIC CAPITAL LETTER ZHE Cyrillic
006 247 15/07 CYRILLIC CAPITAL LETTER VE Cyrillic
006 248 15/08 CYRILLIC CAPITAL SOFT SIGN Cyrillic
006 249 15/09 CYRILLIC CAPITAL LETTER YERU Cyrillic
006 250 15/10 CYRILLIC CAPITAL LETTER ZE Cyrillic
006 251 15/11 CYRILLIC CAPITAL LETTER SHA Cyrillic
006 252 15/12 CYRILLIC CAPITAL LETTER E Cyrillic
006 253 15/13 CYRILLIC CAPITAL LETTER SHCHA Cyrillic
006 254 15/14 CYRILLIC CAPITAL LETTER CHE Cyrillic
006 255 15/15 CYRILLIC CAPITAL HARD SIGN Cyrillic
93

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
007 161 10/01 GREEK CAPITAL LETTER ALPHA WITH ACCENT Greek
007 162 10/02 GREEK CAPITAL LETTER EPSILON WITH ACCENT Greek
007 163 10/03 GREEK CAPITAL LETTER ETA WITH ACCENT Greek
007 164 10/04 GREEK CAPITAL LETTER IOTA WITH ACCENT Greek
007 165 10/05 GREEK CAPITAL LETTER IOTA WITH DIAERESIS Greek
007 167 10/07 GREEK CAPITAL LETTER OMICRON WITH ACCENT Greek
007 168 10/08 GREEK CAPITAL LETTER UPSILON WITH ACCENT Greek
007 169 10/09 GREEK CAPITAL LETTER UPSILON WITH DIAERESIS Greek
007 171 10/11 GREEK CAPITAL LETTER OMEGA WITH ACCENT Greek
007 174 10/14 DIAERESIS AND ACCENT Greek
007 175 10/15 HORIZONTAL BAR Greek
007 177 11/01 GREEK SMALL LETTER ALPHA WITH ACCENT Greek
007 178 11/02 GREEK SMALL LETTER EPSILON WITH ACCENT Greek
007 179 11/03 GREEK SMALL LETTER ETA WITH ACCENT Greek
007 180 11/04 GREEK SMALL LETTER IOTA WITH ACCENT Greek
007 181 11/05 GREEK SMALL LETTER IOTA WITH DIAERESIS Greek
007 182 11/06 GREEK SMALL LETTER IOTA WITH ACCENT+DIAERESIS Greek
007 183 11/07 GREEK SMALL LETTER OMICRON WITH ACCENT Greek
007 184 11/08 GREEK SMALL LETTER UPSILON WITH ACCENT Greek
007 185 11/09 GREEK SMALL LETTER UPSILON WITH DIAERESIS Greek
007 186 11/10 GREEK SMALL LETTER UPSILON WITH ACCENT+DIAERESIS Greek
007 187 11/11 GREEK SMALL LETTER OMEGA WITH ACCENT Greek
007 193 12/01 GREEK CAPITAL LETTER ALPHA Greek
007 194 12/02 GREEK CAPITAL LETTER BETA Greek
007 195 12/03 GREEK CAPITAL LETTER GAMMA Greek
007 196 12/04 GREEK CAPITAL LETTER DELTA Greek
007 197 12/05 GREEK CAPITAL LETTER EPSILON Greek
007 198 12/06 GREEK CAPITAL LETTER ZETA Greek
007 199 12/07 GREEK CAPITAL LETTER ETA Greek
007 200 12/08 GREEK CAPITAL LETTER THETA Greek
007 201 12/09 GREEK CAPITAL LETTER IOTA Greek
007 202 12/10 GREEK CAPITAL LETTER KAPPA Greek
007 203 12/11 GREEK CAPITAL LETTER LAMDA Greek
007 204 12/12 GREEK CAPITAL LETTER MU Greek
007 205 12/13 GREEK CAPITAL LETTER NU Greek
007 206 12/14 GREEK CAPITAL LETTER XI Greek
007 207 12/15 GREEK CAPITAL LETTER OMICRON Greek
007 208 13/00 GREEK CAPITAL LETTER PI Greek
007 209 13/01 GREEK CAPITAL LETTER RHO Greek
007 210 13/02 GREEK CAPITAL LETTER SIGMA Greek
007 212 13/04 GREEK CAPITAL LETTER TAU Greek
007 213 13/05 GREEK CAPITAL LETTER UPSILON Greek
007 214 13/06 GREEK CAPITAL LETTER PHI Greek
007 215 13/07 GREEK CAPITAL LETTER CHI Greek
007 216 13/08 GREEK CAPITAL LETTER PSI Greek
007 217 13/09 GREEK CAPITAL LETTER OMEGA Greek
007 225 14/01 GREEK SMALL LETTER ALPHA Greek
007 226 14/02 GREEK SMALL LETTER BETA Greek
007 227 14/03 GREEK SMALL LETTER GAMMA Greek
007 228 14/04 GREEK SMALL LETTER DELTA Greek
007 229 14/05 GREEK SMALL LETTER EPSILON Greek
007 230 14/06 GREEK SMALL LETTER ZETA Greek
007 231 14/07 GREEK SMALL LETTER ETA Greek
007 232 14/08 GREEK SMALL LETTER THETA Greek
007 233 14/09 GREEK SMALL LETTER IOTA Greek
007 234 14/10 GREEK SMALL LETTER KAPPA Greek
007 235 14/11 GREEK SMALL LETTER LAMDA Greek
007 236 14/12 GREEK SMALL LETTER MU Greek
007 237 14/13 GREEK SMALL LETTER NU Greek
007 238 14/14 GREEK SMALL LETTER XI Greek
94

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
007 239 14/15 GREEK SMALL LETTER OMICRON Greek
007 240 15/00 GREEK SMALL LETTER PI Greek
007 241 15/01 GREEK SMALL LETTER RHO Greek
007 242 15/02 GREEK SMALL LETTER SIGMA Greek
007 243 15/03 GREEK SMALL LETTER FINAL SMALL SIGMA Greek
007 244 15/04 GREEK SMALL LETTER TAU Greek
007 245 15/05 GREEK SMALL LETTER UPSILON Greek
007 246 15/06 GREEK SMALL LETTER PHI Greek
007 247 15/07 GREEK SMALL LETTER CHI Greek
007 248 15/08 GREEK SMALL LETTER PSI Greek
007 249 15/09 GREEK SMALL LETTER OMEGA Greek
008 161 10/01 LEFT RADICAL Technical
008 162 10/02 TOP LEFT RADICAL Technical
008 163 10/03 HORIZONTAL CONNECTOR Technical
008 164 10/04 TOP INTEGRAL Technical
008 165 10/05 BOTTOM INTEGRAL Technical
008 166 10/06 VERTICAL CONNECTOR Technical
008 167 10/07 TOP LEFT SQUARE BRACKET Technical
008 168 10/08 BOTTOM LEFT SQUARE BRACKET Technical
008 169 10/09 TOP RIGHT SQUARE BRACKET Technical
008 170 10/10 BOTTOM RIGHT SQUARE BRACKET Technical
008 171 10/11 TOP LEFT PARENTHESIS Technical
008 172 10/12 BOTTOM LEFT PARENTHESIS Technical
008 173 10/13 TOP RIGHT PARENTHESIS Technical
008 174 10/14 BOTTOM RIGHT PARENTHESIS Technical
008 175 10/15 LEFT MIDDLE CURLY BRACE Technical
008 176 11/00 RIGHT MIDDLE CURLY BRACE Technical
008 177 11/01 TOP LEFT SUMMATION Technical
008 178 11/02 BOTTOM LEFT SUMMATION Technical
008 179 11/03 TOP VERTICAL SUMMATION CONNECTOR Technical
008 180 11/04 BOTTOM VERTICAL SUMMATION CONNECTOR Technical
008 181 11/05 TOP RIGHT SUMMATION Technical
008 182 11/06 BOTTOM RIGHT SUMMATION Technical
008 183 11/07 RIGHT MIDDLE SUMMATION Technical
008 188 11/12 LESS THAN OR EQUAL SIGN Technical
008 189 11/13 NOT EQUAL SIGN Technical
008 190 11/14 GREATER THAN OR EQUAL SIGN Technical
008 191 11/15 INTEGRAL Technical
008 192 12/00 THEREFORE Technical
008 193 12/01 VARIATION, PROPORTIONAL TO Technical
008 194 12/02 INFINITY Technical
008 197 12/05 NABLA, DEL Technical
008 200 12/08 IS APPROXIMATE TO Technical
008 201 12/09 SIMILAR OR EQUAL TO Technical
008 205 12/13 IF AND ONLY IF Technical
008 206 12/14 IMPLIES Technical
008 207 12/15 IDENTICAL TO Technical
008 214 13/06 RADICAL Technical
008 218 13/10 IS INCLUDED IN Technical
008 219 13/11 INCLUDES Technical
008 220 13/12 INTERSECTION Technical
008 221 13/13 UNION Technical
008 222 13/14 LOGICAL AND Technical
008 223 13/15 LOGICAL OR Technical
008 239 14/15 PARTIAL DERIVATIVE Technical
008 246 15/06 FUNCTION Technical
008 251 15/11 LEFT ARROW Technical
008 252 15/12 UPWARD ARROW Technical
95

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
008 253 15/13 RIGHT ARROW Technical
008 254 15/14 DOWNWARD ARROW Technical
009 223 13/15 BLANK Special
009 224 14/00 SOLID DIAMOND Special
009 225 14/01 CHECKERBOARD Special
009 226 14/02 ``HT'' Special
009 227 14/03 ``FF'' Special
009 228 14/04 ``CR'' Special
009 229 14/05 ``LF'' Special
009 232 14/08 ``NL'' Special
009 233 14/09 ``VT'' Special
009 234 14/10 LOWERíRIGHT CORNER Special
009 235 14/11 UPPERíRIGHT CORNER Special
009 236 14/12 UPPERíLEFT CORNER Special
009 237 14/13 LOWERíLEFT CORNER Special
009 238 14/14 CROSSINGíLINES Special
009 239 14/15 HORIZONTAL LINE, SCAN 1 Special
009 240 15/00 HORIZONTAL LINE, SCAN 3 Special
009 241 15/01 HORIZONTAL LINE, SCAN 5 Special
009 242 15/02 HORIZONTAL LINE, SCAN 7 Special
009 243 15/03 HORIZONTAL LINE, SCAN 9 Special
009 244 15/04 LEFT ``T'' Special
009 245 15/05 RIGHT ``T'' Special
009 246 15/06 BOTTOM ``T'' Special
009 247 15/07 TOP ``T'' Special
009 248 15/08 VERTICAL BAR Special
010 161 10/01 EM SPACE Publish
010 162 10/02 EN SPACE Publish
010 163 10/03 3/EM SPACE Publish
010 164 10/04 4/EM SPACE Publish
010 165 10/05 DIGIT SPACE Publish
010 166 10/06 PUNCTUATION SPACE Publish
010 167 10/07 THIN SPACE Publish
010 168 10/08 HAIR SPACE Publish
010 169 10/09 EM DASH Publish
010 170 10/10 EN DASH Publish
010 172 10/12 SIGNIFICANT BLANK SYMBOL Publish
010 174 10/14 ELLIPSIS Publish
010 175 10/15 DOUBLE BASELINE DOT Publish
010 176 11/00 VULGAR FRACTION ONE THIRD Publish
010 177 11/01 VULGAR FRACTION TWO THIRDS Publish
010 178 11/02 VULGAR FRACTION ONE FIFTH Publish
010 179 11/03 VULGAR FRACTION TWO FIFTHS Publish
010 180 11/04 VULGAR FRACTION THREE FIFTHS Publish
010 181 11/05 VULGAR FRACTION FOUR FIFTHS Publish
010 182 11/06 VULGAR FRACTION ONE SIXTH Publish
010 183 11/07 VULGAR FRACTION FIVE SIXTHS Publish
010 184 11/08 CARE OF Publish
010 187 11/11 FIGURE DASH Publish
010 188 11/12 LEFT ANGLE BRACKET Publish
010 189 11/13 DECIMAL POINT Publish
010 190 11/14 RIGHT ANGLE BRACKET Publish
010 191 11/15 MARKER Publish
010 195 12/03 VULGAR FRACTION ONE EIGHTH Publish
010 196 12/04 VULGAR FRACTION THREE EIGHTHS Publish
010 197 12/05 VULGAR FRACTION FIVE EIGHTHS Publish
96

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
010 198 12/06 VULGAR FRACTION SEVEN EIGHTHS Publish
010 201 12/09 TRADEMARK SIGN Publish
010 202 12/10 SIGNATURE MARK Publish
010 203 12/11 TRADEMARK SIGN IN CIRCLE Publish
010 204 12/12 LEFT OPEN TRIANGLE Publish
010 205 12/13 RIGHT OPEN TRIANGLE Publish
010 206 12/14 EM OPEN CIRCLE Publish
010 207 12/15 EM OPEN RECTANGLE Publish
010 208 13/00 LEFT SINGLE QUOTATION MARK Publish
010 209 13/01 RIGHT SINGLE QUOTATION MARK Publish
010 210 13/02 LEFT DOUBLE QUOTATION MARK Publish
010 211 13/03 RIGHT DOUBLE QUOTATION MARK Publish
010 212 13/04 PRESCRIPTION, TAKE, RECIPE Publish
010 214 13/06 MINUTES Publish
010 215 13/07 SECONDS Publish
010 217 13/09 LATIN CROSS Publish
010 218 13/10 HEXAGRAM Publish
010 219 13/11 FILLED RECTANGLE BULLET Publish
010 220 13/12 FILLED LEFT TRIANGLE BULLET Publish
010 221 13/13 FILLED RIGHT TRIANGLE BULLET Publish
010 222 13/14 EM FILLED CIRCLE Publish
010 223 13/15 EM FILLED RECTANGLE Publish
010 224 14/00 EN OPEN CIRCLE BULLET Publish
010 225 14/01 EN OPEN SQUARE BULLET Publish
010 226 14/02 OPEN RECTANGULAR BULLET Publish
010 227 14/03 OPEN TRIANGULAR BULLET UP Publish
010 228 14/04 OPEN TRIANGULAR BULLET DOWN Publish
010 229 14/05 OPEN STAR Publish
010 230 14/06 EN FILLED CIRCLE BULLET Publish
010 231 14/07 EN FILLED SQUARE BULLET Publish
010 232 14/08 FILLED TRIANGULAR BULLET UP Publish
010 233 14/09 FILLED TRIANGULAR BULLET DOWN Publish
010 234 14/10 LEFT POINTER Publish
010 235 14/11 RIGHT POINTER Publish
010 236 14/12 CLUB Publish
010 237 14/13 DIAMOND Publish
010 238 14/14 HEART Publish
010 240 15/00 MALTESE CROSS Publish
010 241 15/01 DAGGER Publish
010 242 15/02 DOUBLE DAGGER Publish
010 243 15/03 CHECK MARK, TICK Publish
010 244 15/04 BALLOT CROSS Publish
010 245 15/05 MUSICAL SHARP Publish
010 246 15/06 MUSICAL FLAT Publish
010 247 15/07 MALE SYMBOL Publish
010 248 15/08 FEMALE SYMBOL Publish
010 249 15/09 TELEPHONE SYMBOL Publish
010 250 15/10 TELEPHONE RECORDER SYMBOL Publish
010 251 15/11 PHONOGRAPH COPYRIGHT SIGN Publish
010 252 15/12 CARET Publish
010 253 15/13 SINGLE LOW QUOTATION MARK Publish
010 254 15/14 DOUBLE LOW QUOTATION MARK Publish
010 255 15/15 CURSOR Publish
011 163 10/03 LEFT CARET APL
011 166 10/06 RIGHT CARET APL
011 168 10/08 DOWN CARET APL
011 169 10/09 UP CARET APL
011 192 12/00 OVERBAR APL
97

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
011 194 12/02 DOWN TACK APL
011 195 12/03 UP SHOE (CAP) APL
011 196 12/04 DOWN STILE APL
011 198 12/06 UNDERBAR APL
011 202 12/10 JOT APL
011 204 12/12 QUAD APL
011 206 12/14 UP TACK APL
011 207 12/15 CIRCLE APL
011 211 13/03 UP STILE APL
011 214 13/06 DOWN SHOE (CUP) APL
011 216 13/08 RIGHT SHOE APL
011 218 13/10 LEFT SHOE APL
011 220 13/12 LEFT TACK APL
011 252 15/12 RIGHT TACK APL
012 223 13/15 DOUBLE LOW LINE Hebrew
012 224 14/00 HEBREW LETTER ALEPH Hebrew
012 225 14/01 HEBREW LETTER BET Hebrew
012 226 14/02 HEBREW LETTER GIMEL Hebrew
012 227 14/03 HEBREW LETTER DALET Hebrew
012 228 14/04 HEBREW LETTER HE Hebrew
012 229 14/05 HEBREW LETTER WAW Hebrew
012 230 14/06 HEBREW LETTER ZAIN Hebrew
012 231 14/07 HEBREW LETTER CHET Hebrew
012 232 14/08 HEBREW LETTER TET Hebrew
012 233 14/09 HEBREW LETTER YOD Hebrew
012 234 14/10 HEBREW LETTER FINAL KAPH Hebrew
012 235 14/11 HEBREW LETTER KAPH Hebrew
012 236 14/12 HEBREW LETTER LAMED Hebrew
012 237 14/13 HEBREW LETTER FINAL MEM Hebrew
012 238 14/14 HEBREW LETTER MEM Hebrew
012 239 14/15 HEBREW LETTER FINAL NUN Hebrew
012 240 15/00 HEBREW LETTER NUN Hebrew
012 241 15/01 HEBREW LETTER SAMECH Hebrew
012 242 15/02 HEBREW LETTER A'YIN Hebrew
012 243 15/03 HEBREW LETTER FINAL PE Hebrew
012 244 15/04 HEBREW LETTER PE Hebrew
012 245 15/05 HEBREW LETTER FINAL ZADE Hebrew
012 246 15/06 HEBREW LETTER ZADE Hebrew
012 247 15/07 HEBREW QOPH Hebrew
012 248 15/08 HEBREW RESH Hebrew
012 249 15/09 HEBREW SHIN Hebrew
012 250 15/10 HEBREW TAW Hebrew
013 161 10/01 THAI KOKAI Thai
013 162 10/02 THAI KHOKHAI Thai
013 163 10/03 THAI KHOKHUAT Thai
013 164 10/04 THAI KHOKHWAI Thai
013 165 10/05 THAI KHOKHON Thai
013 166 10/06 THAI KHORAKHANG Thai
013 167 10/07 THAI NGONGU Thai
013 168 10/08 THAI CHOCHAN Thai
013 169 10/09 THAI CHOCHING Thai
013 170 10/10 THAI CHOCHANG Thai
013 171 10/11 THAI SOSO Thai
013 172 10/12 THAI CHOCHOE Thai
013 173 10/13 THAI YOYING Thai
013 174 10/14 THAI DOCHADA Thai
98

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
013 175 10/15 THAI TOPATAK Thai
013 176 11/00 THAI THOTHAN Thai
013 177 11/01 THAI THONANGMONTHO Thai
013 178 11/02 THAI THOPHUTHAO Thai
013 179 11/03 THAI NONEN Thai
013 180 11/04 THAI DODEK Thai
013 181 11/05 THAI TOTAO Thai
013 182 11/06 THAI THOTHUNG Thai
013 183 11/07 THAI THOTHAHAN Thai
013 184 11/08 THAI THOTHONG Thai
013 185 11/09 THAI NONU Thai
013 186 11/10 THAI BOBAIMAI Thai
013 187 11/11 THAI POPLA Thai
013 188 11/12 THAI PHOPHUNG Thai
013 189 11/13 THAI FOFA Thai
013 190 11/14 THAI PHOPHAN Thai
013 191 11/15 THAI FOFAN Thai
013 192 12/00 THAI PHOSAMPHAO Thai
013 193 12/01 THAI MOMA Thai
013 194 12/02 THAI YOYAK Thai
013 195 12/03 THAI RORUA Thai
013 196 12/04 THAI RU Thai
013 197 12/05 THAI LOLING Thai
013 198 12/06 THAI LU Thai
013 199 12/07 THAI WOWAEN Thai
013 200 12/08 THAI SOSALA Thai
013 201 12/09 THAI SORUSI Thai
013 202 12/10 THAI SOSUA Thai
013 203 12/11 THAI HOHIP Thai
013 204 12/12 THAI LOCHULA Thai
013 205 12/13 THAI OANG Thai
013 206 12/14 THAI HONOKHUK Thai
013 207 12/15 THAI PAIYANNOI Thai
013 208 13/00 THAI SARAA Thai
013 209 13/01 THAI MAIHANAKAT Thai
013 210 13/02 THAI SARAAA Thai
013 211 13/03 THAI SARAAM Thai
013 212 13/04 THAI SARAI Thai
013 213 13/05 THAI SARAII Thai
013 214 13/06 THAI SARAUE Thai
013 215 13/07 THAI SARAUEE Thai
013 216 13/08 THAI SARAU Thai
013 217 13/09 THAI SARAUU Thai
013 218 13/10 THAI PHINTHU Thai
013 222 13/14 THAI MAIHANAKAT Thai
013 223 13/15 THAI BAHT Thai
013 224 14/00 THAI SARAE Thai
013 225 14/01 THAI SARAAE Thai
013 226 14/02 THAI SARAO Thai
013 227 14/03 THAI SARAAIMAIMUAN Thai
013 228 14/04 THAI SARAAIMAIMALAI Thai
013 229 14/05 THAI LAKKHANGYAO Thai
013 230 14/06 THAI MAIYAMOK Thai
013 231 14/07 THAI MAITAIKHU Thai
013 232 14/08 THAI MAIEK Thai
013 233 14/09 THAI MAITHO Thai
013 234 14/10 THAI MAITRI Thai
013 235 14/11 THAI MAICHATTAWA Thai
013 236 14/12 THAI THANTHAKHAT Thai
013 237 14/13 THAI NIKHAHIT Thai
99

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
013 240 15/00 THAI LEKSUN Thai
013 241 15/01 THAI LEKNUNG Thai
013 242 15/02 THAI LEKSONG Thai
013 243 15/03 THAI LEKSAM Thai
013 244 15/04 THAI LEKSI Thai
013 245 15/05 THAI LEKHA Thai
013 246 15/06 THAI LEKHOK Thai
013 247 15/07 THAI LEKCHET Thai
013 248 15/08 THAI LEKPAET Thai
013 249 15/09 THAI LEKKAO Thai
014 161 10/01 HANGUL KIYEOG Korean
014 162 10/02 HANGUL SSANG KIYEOG Korean
014 163 10/03 HANGUL KIYEOG SIOS Korean
014 164 10/04 HANGUL NIEUN Korean
014 165 10/05 HANGUL NIEUN JIEUJ Korean
014 166 10/06 HANGUL NIEUN HIEUH Korean
014 167 10/07 HANGUL DIKEUD Korean
014 168 10/08 HANGUL SSANG DIKEUD Korean
014 169 10/09 HANGUL RIEUL Korean
014 170 10/10 HANGUL RIEUL KIYEOG Korean
014 171 10/11 HANGUL RIEUL MIEUM Korean
014 172 10/12 HANGUL RIEUL PIEUB Korean
014 173 10/13 HANGUL RIEUL SIOS Korean
014 174 10/14 HANGUL RIEUL TIEUT Korean
014 175 10/15 HANGUL RIEUL PHIEUF Korean
014 176 11/00 HANGUL RIEUL HIEUH Korean
014 177 11/01 HANGUL MIEUM Korean
014 178 11/02 HANGUL PIEUB Korean
014 179 11/03 HANGUL SSANG PIEUB Korean
014 180 11/04 HANGUL PIEUB SIOS Korean
014 181 11/05 HANGUL SIOS Korean
014 182 11/06 HANGUL SSANG SIOS Korean
014 183 11/07 HANGUL IEUNG Korean
014 184 11/08 HANGUL JIEUJ Korean
014 185 11/09 HANGUL SSANG JIEUJ Korean
014 186 11/10 HANGUL CIEUC Korean
014 187 11/11 HANGUL KHIEUQ Korean
014 188 11/12 HANGUL TIEUT Korean
014 189 11/13 HANGUL PHIEUF Korean
014 190 11/14 HANGUL HIEUH Korean
014 191 11/15 HANGUL A Korean
014 192 12/00 HANGUL AE Korean
014 193 12/01 HANGUL YA Korean
014 194 12/02 HANGUL YAE Korean
014 195 12/03 HANGUL EO Korean
014 196 12/04 HANGUL E Korean
014 197 12/05 HANGUL YEO Korean
014 198 12/06 HANGUL YE Korean
014 199 12/07 HANGUL O Korean
014 200 12/08 HANGUL WA Korean
014 201 12/09 HANGUL WAE Korean
014 202 12/10 HANGUL OE Korean
014 203 12/11 HANGUL YO Korean
014 204 12/12 HANGUL U Korean
014 205 12/13 HANGUL WEO Korean
014 206 12/14 HANGUL WE Korean
014 207 12/15 HANGUL WI Korean
014 208 13/00 HANGUL YU Korean
100

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
014 209 13/01 HANGUL EU Korean
014 210 13/02 HANGUL YI Korean
014 211 13/03 HANGUL I Korean
014 212 13/04 HANGUL JONG SEONG KIYEOG Korean
014 213 13/05 HANGUL JONG SEONG SSANG KIYEOG Korean
014 214 13/06 HANGUL JONG SEONG KIYEOG SIOS Korean
014 215 13/07 HANGUL JONG SEONG NIEUN Korean
014 216 13/08 HANGUL JONG SEONG NIEUN JIEUJ Korean
014 217 13/09 HANGUL JONG SEONG NIEUN HIEUH Korean
014 218 13/10 HANGUL JONG SEONG DIKEUD Korean
014 219 13/11 HANGUL JONG SEONG RIEUL Korean
014 220 13/12 HANGUL JONG SEONG RIEUL KIYEOG Korean
014 221 13/13 HANGUL JONG SEONG RIEUL MIEUM Korean
014 222 13/14 HANGUL JONG SEONG RIEUL PIEUB Korean
014 223 13/15 HANGUL JONG SEONG RIEUL SIOS Korean
014 224 14/00 HANGUL JONG SEONG RIEUL TIEUT Korean
014 225 14/01 HANGUL JONG SEONG RIEUL PHIEUF Korean
014 226 14/02 HANGUL JONG SEONG RIEUL HIEUH Korean
014 227 14/03 HANGUL JONG SEONG MIEUM Korean
014 228 14/04 HANGUL JONG SEONG PIEUB Korean
014 229 14/05 HANGUL JONG SEONG PIEUB SIOS Korean
014 230 14/06 HANGUL JONG SEONG SIOS Korean
014 231 14/07 HANGUL JONG SEONG SSANG SIOS Korean
014 232 14/08 HANGUL JONG SEONG IEUNG Korean
014 233 14/09 HANGUL JONG SEONG JIEUJ Korean
014 234 14/10 HANGUL JONG SEONG CIEUC Korean
014 235 14/11 HANGUL JONG SEONG KHIEUQ Korean
014 236 14/12 HANGUL JONG SEONG TIEUT Korean
014 237 14/13 HANGUL JONG SEONG PHIEUF Korean
014 238 14/14 HANGUL JONG SEONG HIEUH Korean
014 239 14/15 HANGUL RIEUL YEORIN HIEUH Korean
014 240 15/00 HANGUL SUNKYEONGEUM MIEUM Korean
014 241 15/01 HANGUL SUNKYEONGEUM PIEUB Korean
014 242 15/02 HANGUL PAN SIOS Korean
014 243 15/03 HANGUL KKOGJI DALRIN IEUNG Korean
014 244 15/04 HANGUL SUNKYEONGEUM PHIEUF Korean
014 245 15/05 HANGUL YEORIN HIEUH Korean
014 246 15/06 HANGUL ARAE A Korean
014 247 15/07 HANGUL ARAE AE Korean
014 248 15/08 HANGUL JONG SEONG PAN SIOS Korean
014 249 15/09 HANGUL JONG SEONG KKOGJI DALRIN IEUNG Korean
014 250 15/10 HANGUL JONG SEONG YEORIN HIEUH Korean
014 255 15/15 KOREAN WON Korean
255 008 00/08 BACKSPACE, BACK SPACE, BACK CHAR Keyboard
255 009 00/09 TAB Keyboard
255 010 00/10 LINEFEED, LF Keyboard
255 011 00/11 CLEAR Keyboard
255 013 00/13 RETURN, ENTER Keyboard
255 019 01/03 PAUSE, HOLD Keyboard
255 020 01/04 SCROLL LOCK Keyboard
255 021 01/05 SYS REQ, SYSTEM REQUEST Keyboard
255 027 01/11 ESCAPE Keyboard
255 032 02/00 MULTIíKEY CHARACTER PREFACE Keyboard
255 033 02/01 KANJI, KANJI CONVERT Keyboard
255 034 02/02 MUHENKAN Keyboard
255 035 02/03 HENKAN MODE Keyboard
255 036 02/04 ROMAJI Keyboard
255 037 02/05 HIRAGANA Keyboard
101

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
255 038 02/06 KATAKANA Keyboard
255 039 02/07 HIRAGANA/KATAKANA TOGGLE Keyboard
255 040 02/08 ZENKAKU Keyboard
255 041 02/09 HANKAKU Keyboard
255 042 02/10 ZENKAKU/HANKAKU TOGGLE Keyboard
255 043 02/11 TOUROKU Keyboard
255 044 02/12 MASSYO Keyboard
255 045 02/13 KANA LOCK Keyboard
255 046 02/14 KANA SHIFT Keyboard
255 047 02/15 EISU SHIFT Keyboard
255 048 03/00 EISU TOGGLE Keyboard
255 049 03/01 HANGUL START/STOP (TOGGLE) Keyboard
255 050 03/02 HANGUL START Keyboard
255 051 03/03 HANGUL END, ENGLISH START Keyboard
255 052 03/04 START HANGUL/HANJA CONVERSION Keyboard
255 053 03/05 HANGUL JAMO MODE Keyboard
255 054 03/06 HANGUL ROMAJA MODE Keyboard
255 055 03/07 HANGUL CODE INPUT Keyboard
255 056 03/08 HANGUL JEONJA MODE Keyboard
255 057 03/09 HANGUL BANJA MODE Keyboard
255 058 03/10 HANGUL PREHANJA CONVERSION Keyboard
255 059 03/11 HANGUL POSTHANJA CONVERSION Keyboard
255 060 03/12 HANGUL SINGLE CANDIDATE Keyboard
255 061 03/13 HANGUL MULTIPLE CANDIDATE Keyboard
255 062 03/14 HANGUL PREVIOUS CANDIDATE Keyboard
255 063 03/15 HANGUL SPECIAL SYMBOLS Keyboard
255 080 05/00 HOME Keyboard
255 081 05/01 LEFT, MOVE LEFT, LEFT ARROW Keyboard
255 082 05/02 UP, MOVE UP, UP ARROW Keyboard
255 083 05/03 RIGHT, MOVE RIGHT, RIGHT ARROW Keyboard
255 084 05/04 DOWN, MOVE DOWN, DOWN ARROW Keyboard
255 085 05/05 PRIOR, PREVIOUS, PAGE UP Keyboard
255 086 05/06 NEXT, PAGE DOWN Keyboard
255 087 05/07 END, EOL Keyboard
255 088 05/08 BEGIN, BOL Keyboard
255 096 06/00 SELECT, MARK Keyboard
255 097 06/01 PRINT Keyboard
255 098 06/02 EXECUTE, RUN, DO Keyboard
255 099 06/03 INSERT, INSERT HERE Keyboard
255 101 06/05 UNDO, OOPS Keyboard
255 102 06/06 REDO, AGAIN Keyboard
255 103 06/07 MENU Keyboard
255 104 06/08 FIND, SEARCH Keyboard
255 105 06/09 CANCEL, STOP, ABORT, EXIT Keyboard
255 106 06/10 HELP Keyboard
255 107 06/11 BREAK Keyboard
255 126 07/14 MODE SWITCH, SCRIPT SWITCH, CHARACTER SET SWITCH Keyboard
255 127 07/15 NUM LOCK Keyboard
255 128 08/00 KEYPAD SPACE Keyboard
255 137 08/09 KEYPAD TAB Keyboard
255 141 08/13 KEYPAD ENTER Keyboard
255 145 09/01 KEYPAD F1, PF1, A Keyboard
255 146 09/02 KEYPAD F2, PF2, B Keyboard
255 147 09/03 KEYPAD F3, PF3, C Keyboard
255 148 09/04 KEYPAD F4, PF4, D Keyboard
255 149 09/05 KEYPAD HOME Keyboard
255 150 09/06 KEYPAD LEFT Keyboard
255 151 09/07 KEYPAD UP Keyboard
255 152 09/08 KEYPAD RIGHT Keyboard
255 153 09/09 KEYPAD DOWN Keyboard
102

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
255 154 09/10 KEYPAD PRIOR, PAGE UP Keyboard
255 155 09/11 KEYPAD NEXT, PAGE DOWN Keyboard
255 156 09/12 KEYPAD END Keyboard
255 157 09/13 KEYPAD BEGIN Keyboard
255 158 09/14 KEYPAD INSERT Keyboard
255 159 09/15 KEYPAD DELETE Keyboard
255 170 10/10 KEYPAD MULTIPLICATION SIGN, ASTERISK Keyboard
255 171 10/11 KEYPAD PLUS SIGN Keyboard
255 172 10/12 KEYPAD SEPARATOR, COMMA Keyboard
255 173 10/13 KEYPAD MINUS SIGN, HYPHEN Keyboard
255 174 10/14 KEYPAD DECIMAL POINT, FULL STOP Keyboard
255 175 10/15 KEYPAD DIVISION SIGN, SOLIDUS Keyboard
255 176 11/00 KEYPAD DIGIT ZERO Keyboard
255 177 11/01 KEYPAD DIGIT ONE Keyboard
255 178 11/02 KEYPAD DIGIT TWO Keyboard
255 179 11/03 KEYPAD DIGIT THREE Keyboard
255 180 11/04 KEYPAD DIGIT FOUR Keyboard
255 181 11/05 KEYPAD DIGIT FIVE Keyboard
255 182 11/06 KEYPAD DIGIT SIX Keyboard
255 183 11/07 KEYPAD DIGIT SEVEN Keyboard
255 184 11/08 KEYPAD DIGIT EIGHT Keyboard
255 185 11/09 KEYPAD DIGIT NINE Keyboard
255 189 11/13 KEYPAD EQUALS SIGN Keyboard
255 190 11/14 F1 Keyboard
255 191 11/15 F2 Keyboard
255 192 12/00 F3 Keyboard
255 193 12/01 F4 Keyboard
255 194 12/02 F5 Keyboard
255 195 12/03 F6 Keyboard
255 196 12/04 F7 Keyboard
255 197 12/05 F8 Keyboard
255 198 12/06 F9 Keyboard
255 199 12/07 F10 Keyboard
255 200 12/08 F11, L1 Keyboard
255 201 12/09 F12, L2 Keyboard
255 202 12/10 F13, L3 Keyboard
255 203 12/11 F14, L4 Keyboard
255 204 12/12 F15, L5 Keyboard
255 205 12/13 F16, L6 Keyboard
255 206 12/14 F17, L7 Keyboard
255 207 12/15 F18, L8 Keyboard
255 208 13/00 F19, L9 Keyboard
255 209 13/01 F20, L10 Keyboard
255 210 13/02 F21, R1 Keyboard
255 211 13/03 F22, R2 Keyboard
255 212 13/04 F23, R3 Keyboard
255 213 13/05 F24, R4 Keyboard
255 214 13/06 F25, R5 Keyboard
255 215 13/07 F26, R6 Keyboard
255 216 13/08 F27, R7 Keyboard
255 217 13/09 F28, R8 Keyboard
255 218 13/10 F29, R9 Keyboard
255 219 13/11 F30, R10 Keyboard
255 220 13/12 F31, R11 Keyboard
255 221 13/13 F32, R12 Keyboard
255 222 13/14 F33, R13 Keyboard
255 223 13/15 F34, R14 Keyboard
255 224 14/00 F35, R15 Keyboard
255 225 14/01 LEFT SHIFT Keyboard
255 226 14/02 RIGHT SHIFT Keyboard
103

íí íí
X Protocol X11, Release 6.4
Byte Byte Code Name Set
3 4 Pos
255 227 14/03 LEFT CONTROL Keyboard
255 228 14/04 RIGHT CONTROL Keyboard
255 229 14/05 CAPS LOCK Keyboard
255 230 14/06 SHIFT LOCK Keyboard
255 231 14/07 LEFT META Keyboard
255 232 14/08 RIGHT META Keyboard
255 233 14/09 LEFT ALT Keyboard
255 234 14/10 RIGHT ALT Keyboard
255 235 14/11 LEFT SUPER Keyboard
255 236 14/12 RIGHT SUPER Keyboard
255 237 14/13 LEFT HYPER Keyboard
255 238 14/14 RIGHT HYPER Keyboard
255 255 15/15 DELETE, RUBOUT Keyboard
104

íí íí
X Protocol X11, Release 6.4
Appendix B
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 Winí
dow 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 someí
times larger than that strictly required to encode the values. For example:
class: {InputOutput , InputOnly , CopyFromParent}
becomes:
2 class
0 CopyFromParent
105

íí íí
X Protocol X11, Release 6.4
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 augí
ment 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 correí
sponding 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 actuí
ally 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. Compoí
nents 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 strucí
ture. 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
106

íí íí
X Protocol X11, Release 6.4
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
Common Types
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
107

íí íí
X Protocol X11, Release 6.4
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
108

íí íí
X Protocol X11, Release 6.4
#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
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
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
109

íí íí
X Protocol X11, Release 6.4
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
110

íí íí
X Protocol X11, Release 6.4
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
111

íí íí
X Protocol X11, Release 6.4
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 Appendix A,
Keysym Encoding.
Pointers
BUTTON values are numbered starting with one.
Predefined Atoms
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
112

íí íí
X Protocol X11, Release 6.4
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 representaí
tion 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
113

íí íí
X Protocol X11, Release 6.4
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
114

íí íí
X Protocol X11, Release 6.4
4 CARD32 blueímask
4 unused
Requests
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
115

íí íí
X Protocol X11, Release 6.4
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
116

íí íí
X Protocol X11, Release 6.4
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
117

íí íí
X Protocol X11, Release 6.4
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
118

íí íí
X Protocol X11, Release 6.4
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
119

íí íí
X Protocol X11, Release 6.4
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
120

íí íí
X Protocol X11, Release 6.4
4 ATOM target
4 ATOM property
0 None
4 TIMESTAMP time
0 CurrentTime
SendEvent
1 25 opcode
1 BOOL propagate
2 11 request length
4 WINDOW destination
0 PointerWindow
1 InputFocus
4 SETofEVENT eventímask
32 event
standard event format (see the Events section)
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
121

íí íí
X Protocol X11, Release 6.4
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
122

íí íí
X Protocol X11, Release 6.4
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
123

íí íí
X Protocol X11, Release 6.4
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
124

íí íí
X Protocol X11, Release 6.4
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
125

íí íí
X Protocol X11, Release 6.4
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)
126

íí íí
X Protocol X11, Release 6.4
î
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
127

íí íí
X Protocol X11, Release 6.4
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
128

íí íí
X Protocol X11, Release 6.4
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
129

íí íí
X Protocol X11, Release 6.4
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
130

íí íí
X Protocol X11, Release 6.4
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
131

íí íí
X Protocol X11, Release 6.4
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
132

íí íí
X Protocol X11, Release 6.4
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
133

íí íí
X Protocol X11, Release 6.4
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
134

íí íí
X Protocol X11, Release 6.4
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
135

íí íí
X Protocol X11, Release 6.4
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
136

íí íí
X Protocol X11, Release 6.4
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
137

íí íí
X Protocol X11, Release 6.4
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
138

íí íí
X Protocol X11, Release 6.4
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
î
139

íí íí
X Protocol X11, Release 6.4
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
140

íí íí
X Protocol X11, Release 6.4
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
141

íí íí
X Protocol X11, Release 6.4
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
142

íí íí
X Protocol X11, Release 6.4
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
143

íí íí
X Protocol X11, Release 6.4
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
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
144

íí íí
X Protocol X11, Release 6.4
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
145

íí íí
X Protocol X11, Release 6.4
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
146

íí íí
X Protocol X11, Release 6.4
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
147

íí íí
X Protocol X11, Release 6.4
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
148

íí íí
X Protocol X11, Release 6.4
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
149

íí íí
X Protocol X11, Release 6.4
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
150

íí íí
X Protocol X11, Release 6.4
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
151

íí íí
X Protocol X11, Release 6.4
Glossary
Access control list
X maintains a list of hosts from which client programs can be run. By default, only proí
grams 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 impleí
mentations 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 authorizaí
tion protocol name and data received by the server at connection setup.
Active grab
A grab is active when the pointer or keyboard is actually owned by the single grabbing
client.
Ancestors
If W is an inferior of A, then A is an ancestor of W.
Atom
An atom is a unique ID corresponding to a string name. Atoms are used to identify properí
ties, types, and selections.
Background
An InputOutput window can have a background, which is defined as a pixmap. When reí
gions of the window have their contents lost or invalidated, the server will automatically tile
those regions with the background.
Backing store
When a server maintains the contents of a window, the pixels saved off screen are known as
a backing store.
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 winí
dow (though no guarantees are made). This attraction of window contents for some location
of a window is known as bit gravity.
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
A bitmap is a pixmap of depth one.
Border
An InputOutput window can have a border of equal thickness on all four sides of the winí
dow. A pixmap defines the contents of the border, and the server automatically maintains
the contents of the border. Exposure events are never generated for border regions.
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
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
The children of a window are its firstílevel subwindows.
152

íí íí
X Protocol X11, Release 6.4
Client
An application program connects to the window system server by some interprocess comí
munication path, such as a TCP connection or a shared memory buffer. This program is reí
ferred to as a client of the window system server. More precisely, the client is the communií
cation 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
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
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 colí
ormap 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
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 serví
er over which requests and events are sent.
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
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
A cursor is the visible shape of the pointer on a screen. It consists of a hot spot, 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
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 graphí
ics output.
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 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 subí
field indexes a third array to produce green intensity values. The RGB values can be
changed dynamically.
Display
A server, together with its screens and input devices, is called a display.
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
window cannot be used as a source or destination in a graphics operation.
153

íí íí
X Protocol X11, Release 6.4
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
specificially 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
Events are requested relative to a window. The set of event types that a client requests relaí
tive to a window is described by using an event mask.
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 syní
chronous processing of device events.
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 exí
plicitly.
Event source
The window the pointer is in is the source of a deviceírelated event.
Exposure event
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 reí
gions of windows have been lost.
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
The focus window is another term for the input focus.
Font
A font is a matrix of glyphs (typically characters). The protocol does no translation or interí
pretation 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 and gcontext are abbreviations for graphics context.
Glyph
A glyph is an image, typically of a character, in a font.
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
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
See bit gravity and window gravity.
GrayScale
GrayScale can be viewed as a degenerate case of PseudoColor , in which the red, green,
and blue values in any given colormap entry are equal, thus producing shades of gray. The
gray values can be changed dynamically.
154

íí íí
X Protocol X11, Release 6.4
Hotspot
A cursor has an associated hotspot that defines the point in the cursor corresponding to the
coordinates reported for the pointer.
Identifier
An identifier is a unique value associated with a resource that clients use to name that reí
source. The identifier can be used over any connection.
Inferiors
The inferiors of a window are all of the subwindows nested below it: the children, the chilí
dren's children, and so on.
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 infeí
riors, the event is reported normally. Otherwise, the event is reported with respect to the foí
cus 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
Control over keyboard input is typically provided by an input manager client.
InputOnly window
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 generaí
tion, and grabbing. InputOnly windows cannot have InputOutput windows as inferiors.
InputOutput window
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
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
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
An encoding of a symbol on a keycap on a keyboard.
Mapped
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
Shift, Control, Meta, Super, Hyper, Alt, Compose, Apple, CapsLock, ShiftLock, and similar
keys are called modifier keys.
Monochrome
Monochrome is a special case of StaticGray in which there are only two colormap entries.
Obscure
A window is obscured if some other window obscures it. Window A obscures window B if
both are viewable InputOutput windows, 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 obscure and occludes. Also note that window
borders are included in the calculation and that a window can be obscured and yet still have
visible regions.
155

íí íí
X Protocol X11, Release 6.4
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 disí
tinction between occludes and obscures. Also note that window borders are included in the
calculation.
Padding
Some padding bytes are inserted in the data stream to maintain alignment of the protocol reí
quests on natural boundaries. This increases ease of portability to some machine architecí
tures.
Parent window
If C is a child of P, then P is the parent of C.
Passive grab
Grabbing a key or button is a passive grab. The grab activates when the key or button is ací
tually pressed.
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 iní
dexes a colormap to derive an actual color to be displayed.
Pixmap
A pixmap is a threeídimensional array of bits. A pixmap is normally thought of as a twoídií
mensional 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
When a pixmap or window is thought of as a stack of bitmaps, each bitmap is called a plane
or bit plane.
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
The pointer is the pointing device attached to the cursor and tracked on the screens.
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
A pointing device is typically a mouse, tablet, or some other device with effective dimení
sional motion. There is only one visible cursor defined by the core protocol, and it tracks
whatever pointing device is attached as the pointer.
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
The property list of a window is the list of properties that have been defined for the window.
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.
156

íí íí
X Protocol X11, Release 6.4
Redirecting control
Window managers (or client programs) may want to enforce window layout policy in varií
ous 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
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
A command to the server is called a request. It is a single block of data sent over a connecí
tion.
Resource
Windows, pixmaps, cursors, fonts, graphics contexts, and colormaps are known as reí
sources. 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
Red, green, and blue (RGB) intensity values are used to define color. These values are alí
ways 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 hardí
ware.
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
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
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
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
An image represented in scanline order contains scanlines ordered by increasing y coordií
nate.
Screen
A server can provide several independent screens, which typically have physically indepení
dent monitors. This would be the expected configuration when there is only a single
keyboard and pointer shared among the screens.
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 ``tarí
get type''. This target type can be used to control the transmitted representation of the coní
tents. For example, if the selection is ``the last thing the user clicked on'' and that is curí
rently 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.
157

íí íí
X Protocol X11, Release 6.4
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 approí
priate clients.
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 oní
ly a transient state for such things as rubberíbanding, popíup menus, or to execute requests
indivisibly.
Sibling
Children of the same parent window are known as sibling windows.
Stacking order
Sibling windows may stack on top of each other. Windows above other windows both obí
scure and occlude those lower windows. This is similar to paper on a desk. The relationí
ship between sibling windows is known as the stacking order.
StaticColor
StaticColor can be viewed as a degenerate case of PseudoColor in which the RGB values
are predefined and readíonly.
StaticGray
StaticGray can be viewed as a degenerate case of GrayScale in which the gray values are
predefined and readíonly. The values are typically linear or nearílinear increasing ramps.
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
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 incluí
sive (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
A pixmap can be replicated in two dimensions to tile a region. The pixmap itself is also
known as a tile.
Timestamp
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 timesí
tamp 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 curí
rent server time.
TrueColor
TrueColor can be viewed as a degenerate case of DirectColor in which the subfields in the
pixel value directly encode the corresponding RGB values; that is, the colormap has predeí
fined readíonly RGB values. The values are typically linear or nearílinear increasing ramps.
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.
158

íí íí
X Protocol X11, Release 6.4
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
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
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
Manipulation of windows on the screen and much of the user interface (policy) is typically
provided by a window manager client.
XYFormat
The data for a pixmap is said to be in XY format if it is organized as a set of bitmaps repreí
senting individual bit planes, with the planes appearing from mostísignificant to leastísignifí
icant in bit order.
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.
159

íí íí
X Protocol X11, Release 6.4
Table of Contents
Acknowledgments .................................................................................................................... iii
1. Protocol Formats .................................................................................................................. 1
2. Syntactic Conventions .......................................................................................................... 1
3. Common Types .................................................................................................................... 2
4. Errors .................................................................................................................................... 4
5. Keyboards ............................................................................................................................ 5
6. Pointers ................................................................................................................................ 7
7. Predefined Atoms ................................................................................................................. 7
8. Connection Setup ................................................................................................................. 7
9. Requests ............................................................................................................................... 11
10. Connection Close ............................................................................................................... 70
11. Events ................................................................................................................................. 70
12. Flow Control and Concurrency .......................................................................................... 82
Appendix A - KEYSYM Encoding ........................................................................................ 83
Appendix B - Protocol Encoding ............................................................................................ 105
Glossary ................................................................................................................................... 152
Index ......................................................................................................................................... 160
íí íí