X Window System Protocol X Consortium Standard Robert W. Scheifler X Consortium, Inc. X Version 11, Release 7.7 Version 1.0 Copyright © 1986, 1987, 1988, 1994, 2004 The Open Group Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED “AS ISâ€, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of the Open Group shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization from the Open Group. X Window System is a trademark of The Open Group. â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â” Table of Contents Acknowledgements 1. Protocol Formats Request Format Reply Format Error Format Event Format 2. Syntactic Conventions 3. Common Types 4. Errors 5. Keyboards 6. Pointers 7. Predefined Atoms 8. Connection Setup Connection Initiation Server Response Server Information Screen Information Visual Information 9. Requests CreateWindow ChangeWindowAttributes GetWindowAttributes DestroyWindow DestroySubwindows ChangeSaveSet ReparentWindow MapWindow MapSubwindows UnmapWindow UnmapSubwindows ConfigureWindow CirculateWindow GetGeometry QueryTree InternAtom GetAtomName ChangeProperty DeleteProperty GetProperty RotateProperties ListProperties SetSelectionOwner GetSelectionOwner ConvertSelection SendEvent GrabPointer UngrabPointer GrabButton UngrabButton ChangeActivePointerGrab GrabKeyboard UngrabKeyboard GrabKey UngrabKey AllowEvents GrabServer UngrabServer QueryPointer GetMotionEvents TranslateCoordinates WarpPointer SetInputFocus GetInputFocus QueryKeymap OpenFont CloseFont QueryFont QueryTextExtents ListFonts ListFontsWithInfo SetFontPath GetFontPath CreatePixmap FreePixmap CreateGC ChangeGC CopyGC SetDashes SetClipRectangles FreeGC ClearArea CopyArea CopyPlane PolyPoint PolyLine PolySegment PolyRectangle PolyArc FillPoly PolyFillRectangle PolyFillArc PutImage GetImage PolyText8 PolyText16 ImageText8 ImageText16 CreateColormap FreeColormap CopyColormapAndFree InstallColormap UninstallColormap ListInstalledColormaps AllocColor AllocNamedColor AllocColorCells AllocColorPlanes FreeColors StoreColors StoreNamedColor QueryColors LookupColor CreateCursor CreateGlyphCursor FreeCursor RecolorCursor QueryBestSize QueryExtension ListExtensions SetModifierMapping GetModifierMapping ChangeKeyboardMapping GetKeyboardMapping ChangeKeyboardControl GetKeyboardControl Bell SetPointerMapping GetPointerMapping ChangePointerControl GetPointerControl SetScreenSaver GetScreenSaver ForceScreenSaver ChangeHosts ListHosts SetAccessControl SetCloseDownMode KillClient NoOperation 10. Connection Close 11. Events Input Device events Pointer Window events Input Focus events KeymapNotify Expose GraphicsExposure NoExposure VisibilityNotify CreateNotify DestroyNotify UnmapNotify MapNotify MapRequest ReparentNotify ConfigureNotify GravityNotify ResizeRequest ConfigureRequest CirculateNotify CirculateRequest PropertyNotify SelectionClear SelectionRequest SelectionNotify ColormapNotify MappingNotify ClientMessage 12. Flow Control and Concurrency A. KEYSYM Encoding Special KEYSYMs Latin-1 KEYSYMs Unicode KEYSYMs Function KEYSYMs Vendor KEYSYMs Legacy KEYSYMs B. Protocol Encoding Syntactic Conventions Common Types Errors Keyboards Pointers Predefined Atoms Connection Setup Requests Events Glossary Index Acknowledgements 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 understand the protocol or to place it in perspective within a complete system. The protocol contains many management mechanisms that are not intended for normal applications. Not all mechanisms are needed to build a particular user interface. It is important to keep in mind that the protocol is intended to provide mechanism, not policy. Robert W. Scheifler X Consortium, Inc. Chapter 1. Protocol Formats Table of Contents Request Format Reply Format Error Format Event Format 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 significant 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 additional 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 generated 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) processed by the server. Chapter 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 sectio...
Adi67