1. Protocol FormatsRequest Format
Reply Format
Error Format
Event Format
2. Syntactic ConventionsThe rest of this document uses the following syntacticconventions.• The syntax {...} encloses a set of alternatives.• The syntax [...] encloses a set of structurecomponents.• In general, TYPEs are in uppercase andAlternativeValues are capitalized.• Requests in section 9 are described in the followingformat:RequestNamearg1: type1...argN: typeN→ result1: type1...resultM: typeMErrors: kind1, ..., kindKDescription.If no → is present in the description, then the requesthas no reply (it is asynchronous), although errors maystill be reported. If →+ is used, then one or morereplies can be generated for a single request.• Events in section 11 are described in the followingformat:EventNamevalue1: type1...valueN: typeNDescription.3. Common Types                 The [x,y] coordinates of a RECTANGLE specify the upper-leftcorner.The primary interpretation of large characters in a STRING16is that they are composed of two bytes used to index atwo-dimensional matrix, hence, the use of CHAR2B rather thanCARD16. This corresponds to the JIS/ISO method of indexing2-byte characters. It is expected that most large fontswill be defined with 2-byte matrix indexing. For largefonts constructed with linear indexing, a CHAR2B can beinterpreted as a 16-bit number by treating byte1 as the mostsignificant byte. This means that clients should alwaystransmit such 16-bit character values most significant bytefirst, as the server will never byte-swap CHAR2B quantities.The length, format, and interpretation of a HOST address arespecific to the family (see ChangeHosts request).4. ErrorsIn general, when a request terminates with an error, therequest has no side effects (that is, there is no partialexecution). The only requests for which this is not trueare ChangeWindowAttributes, ChangeGC, PolyText8, PolyText16,FreeColors, StoreColors, and ChangeKeyboardControl.The following error codes result from various requests asfollows: NoteThe Atom, Colormap, Cursor, Drawable, Font,GContext, Pixmap, and Window errors are also usedwhen the argument type is extended by union with aset of fixed alternatives, for example, <WINDOW orPointerRoot or None>.5. KeyboardsA KEYCODE represents a physical (or logical) key. Keycodeslie in the inclusive range [8,255]. A keycode value carriesno intrinsic information, although server implementors mayattempt to encode geometry information (for example, matrix)to be interpreted in a server-dependent fashion. Themapping between keys and keycodes cannot be changed usingthe protocol.A KEYSYM is an encoding of a symbol on the cap of a key.The set of defined KEYSYMs include the character setsLatin-1, Latin-2, Latin-3, Latin-4, Kana, Arabic, Cyrillic,Greek, Tech, Special, Publish, APL, Hebrew, Thai, and Koreanas well as a set of symbols common on keyboards (Return,Help, Tab, and so on). KEYSYMs with the most significantbit (of the 29 bits) set are reserved as vendor-specific.A list of KEYSYMs is associated with each KEYCODE. The listis intended to convey the set of symbols on thecorresponding key. If the list (ignoring trailing NoSymbolentries) is a single KEYSYM ‘‘K’’, then the list is treatedas if it were the list ‘‘K NoSymbol K NoSymbol’’. If thelist (ignoring trailing NoSymbol entries) is a pair ofKEYSYMs ‘‘K1 K2’’, then the list is treated as if it werethe list ‘‘K1 K2 K1 K2’’. If the list (ignoring trailingNoSymbol entries) is a triple of KEYSYMs ‘‘K1 K2 K3’’, thenthe list is treated as if it were the list ‘‘K1 K2 K3NoSymbol’’. When an explicit ‘‘void’’ element is desired inthe list, the value VoidSymbol can be used.The first four elements of the list are split into twogroups of KEYSYMs. Group 1 contains the first and secondKEYSYMs, Group 2 contains the third and fourth KEYSYMs.Within each group, if the second element of the group isNoSymbol, then the group should be treated as if the secondelement were the same as the first element, except when thefirst element is an alphabetic KEYSYM ‘‘K’’ for which bothlowercase and uppercase forms are defined. In that case,the group should be treated as if the first element were thelowercase form of ‘‘K’’ and the second element were theuppercase form of ‘‘K’’.The standard rules for obtaining a KEYSYM from a KeyPressevent make use of only the Group 1 and Group 2 KEYSYMs; nointerpretation of other KEYSYMs in the list is defined. Themodifier state determines which group to use. Switchingbetween groups is controlled by the KEYSYM named MODESWITCH, by attaching that KEYSYM to some KEYCODE andattaching that KEYCODE to any one of the modifiers Mod1through Mod5. This modifier is called the ‘‘groupmodifier’’. For any KEYCODE, Group 1 is used when the groupmodifier is off, and Group 2 is used when the group modifieris on.The Lock modifier is interpreted as CapsLock when the KEYSYMnamed CAPS LOCK is attached to some KEYCODE and that KEYCODEis attached to the Lock modifier. The Lock modifier isinterpreted as ShiftLock when the KEYSYM named SHIFT LOCK isattached to some KEYCODE and that KEYCODE is attached to theLock modifier. If the Lock modifier could be interpreted asboth CapsLock and ShiftLock, the CapsLock interpretation isused.The operation of ‘‘keypad’’ keys is controlled by the KEYSYMnamed NUM LOCK, by attaching that KEYSYM to some KEYCODE andattaching that KEYCODE to any one of the modifiers Mod1through Mod5. This modifier is called the ‘‘numlockmodifier’’. The standard KEYSYMs with the prefix KEYPAD intheir name are called ‘‘keypad’’ KEYSYMs; these are KEYSYMSwith numeric value in the hexadecimal range #xFF80 to #xFFBDinclusive. In addition, vendor-specific KEYSYMS in thehexadecimal range #x11000000 to #x1100FFFF are also keypadKEYSYMs.Within a group, the choice of KEYSYM is determined byapplying the first rule that is satisfied from the followinglist:• The numlock modifier is on and the second KEYSYM is akeypad KEYSYM. In this case, if the Shift modifier ison, or if the Lock modifier is on and is interpreted asShiftLock, then the first KEYSYM is used; otherwise,the second KEYSYM is used.• The Shift and Lock modifiers are both off. In thiscase, the first KEYSYM is used.• The Shift modifier is off, and the Lock modifier is onand is interpreted as CapsLock. In this case, thefirst KEYSYM is used, but if that KEYSYM is lowercasealphabetic, then the corresponding uppercase KEYSYM isused instead.• The Shift modifier is on, and the Lock modifier is onand is interpreted as CapsLock. In this case, thesecond KEYSYM is used, but if that KEYSYM is lowercasealphabetic, then the corresponding uppercase KEYSYM isused instead.• The Shift modifier is on, or the Lock modifier is onand is interpreted as ShiftLock, or both. In thiscase, the second KEYSYM is used.The mapping between KEYCODEs and KEYSYMs is not useddirectly by the server; it is merely stored for reading andwriting by clients.6. PointersButtons are always numbered starting with one.7. Predefined AtomsPredefined atoms are not strictly necessary and may not beuseful in all environments, but they will eliminate manyInternAtom requests in most applications. Note that theyare predefined only in the sense of having numeric values,not in the sense of having required semantics. The coreprotocol imposes no semantics on these names, but semanticsare specified in other X.Org standards, such as theInter-Client Communication Conventions Manual and the XLogical Font Description Conventions.The following names have predefined atom values. Note thatuppercase and lowercase matter.To avoid conflicts with possible future names for whichsemantics might be imposed (either at the protocol level orin terms of higher level user interface models), namesbeginning with an underscore should be used for atoms thatare private to a particular vendor or organization. Toguarantee no conflicts between vendors and organizations,additional prefixes need to be used. However, the protocoldoes not define the mechanism for choosing such prefixes.For names private to a single application or end user butstored in globally accessible locations, it is suggestedthat two leading underscores be used to avoid conflicts withother names.8. Connection SetupFor remote clients, the X protocol can be built on top ofany reliable byte stream.Connection Initiation
Server Response
Server Information
Screen Information
Visual Information