From adeb8256da9b636648178f729d7b3316a0a8e990 Mon Sep 17 00:00:00 2001 From: marha Date: Wed, 8 Jun 2011 08:21:55 +0200 Subject: xserver libX11 mesa git update 8 Jun 2011 --- libX11/specs/libX11/AppC.xml | 39 +- libX11/specs/libX11/AppD.xml | 7 +- libX11/specs/libX11/CH01.xml | 1689 +++---- libX11/specs/libX11/CH02.xml | 35 +- libX11/specs/libX11/CH03.xml | 33 +- libX11/specs/libX11/CH04.xml | 18 +- libX11/specs/libX11/CH05.xml | 2 +- libX11/specs/libX11/CH06.xml | 6 +- libX11/specs/libX11/CH07.xml | 2 +- libX11/specs/libX11/CH08.xml | 2 +- libX11/specs/libX11/CH09.xml | 4 +- libX11/specs/libX11/CH10.xml | 9481 +++++++++++++++++++------------------ libX11/specs/libX11/CH11.xml | 7 +- libX11/specs/libX11/CH13.xml | 25 +- libX11/specs/libX11/CH14.xml | 45 +- libX11/specs/libX11/CH15.xml | 17 +- libX11/specs/libX11/CH16.xml | 8 +- mesalib/Makefile | 1 + mesalib/configs/darwin | 4 +- mesalib/src/mesa/main/fbobject.c | 45 +- mesalib/src/mesa/swrast/s_clear.c | 468 +- xorg-server/Xi/exevents.c | 4 +- xorg-server/dix/events.c | 6 +- xorg-server/dix/getevents.c | 43 +- xorg-server/test/input.c | 3 + xorg-server/xkb/xkbfmisc.c | 7 +- 26 files changed, 6057 insertions(+), 5944 deletions(-) diff --git a/libX11/specs/libX11/AppC.xml b/libX11/specs/libX11/AppC.xml index fb08f8592..da687ecbb 100644 --- a/libX11/specs/libX11/AppC.xml +++ b/libX11/specs/libX11/AppC.xml @@ -36,7 +36,7 @@ and should use minor opcodes to distinguish the requests. The symbols and macros used for writing stubs to Xlib are listed in -<X11/Xlibint.h> . +<X11/Xlibint.h>. Basic Protocol Support Routines @@ -236,7 +236,7 @@ The structure returns the information from XInitExtension and is defined in -<X11/Xlib.h> : +<X11/Xlib.h>: @@ -1262,7 +1262,8 @@ returned to. If your procedure returns a zero value, the error is not suppressed, and the client's error handler is called. -(For further information, see section 11.8.2.) +(For further information, +see section 11.8.2.) If your procedure returns nonzero, the error is suppressed, and _XReply @@ -1572,7 +1573,7 @@ on these lists. The following structure is used in the functions in this section and is defined in -<X11/Xlib.h> +<X11/Xlib.h> @@ -1743,7 +1744,7 @@ There is no way to find additional structures. The XAllocID macro, which allocates and returns a resource ID, is defined in -<X11/Xlib.h>. +<X11/Xlib.h>. XAllocID @@ -2020,7 +2021,7 @@ XDrawPoint(dpy, d, gc, x, y) To keep clients from generating very long requests that may monopolize the server, there is a symbol defined in -<X11/Xlibint.h> +<X11/Xlibint.h> of EPERBATCH on the number of requests batched. Most of the performance benefit occurs in the first few merged requests. Note that @@ -2047,7 +2048,7 @@ Requests, Replies, and Xproto.h The -<X11/Xproto.h> +<X11/Xproto.h> file contains three sets of definitions that are of interest to the stub implementor: request names, request structures, and reply structures. @@ -2055,10 +2056,10 @@ request names, request structures, and reply structures. You need to generate a file equivalent to -<X11/Xproto.h> +<X11/Xproto.h> for your extension and need to include it in your stub procedure. Each stub procedure also must include -<X11/Xlibint.h> . +<X11/Xlibint.h>. @@ -2066,14 +2067,14 @@ The identifiers are deliberately chosen in such a way that, if the request is called X_DoSomething, then its request structure is xDoSomethingReq, and its reply is xDoSomethingReply. The GetReq family of macros, defined in -<X11/Xlibint.h> , +<X11/Xlibint.h>, takes advantage of this naming scheme. For each X request, there is a definition in -<X11/Xproto.h> +<X11/Xproto.h> that looks similar to this: @@ -2134,7 +2135,7 @@ these should be used for all 16-bit and 32-bit quantities, as discussed below. Most protocol requests have a corresponding structure typedef in -<X11/Xproto.h>, +<X11/Xproto.h>, which looks like: @@ -2162,7 +2163,7 @@ you need not declare a request structure in your extension header file. Instead, such requests use the xResourceReq structure in -<X11/Xproto.h>. +<X11/Xproto.h>. This structure is used for any request whose single argument is a Window, Pixmap, @@ -2215,14 +2216,14 @@ A few protocol requests take no arguments at all. Instead, they use the xReq structure in -<X11/Xproto.h>, +<X11/Xproto.h>, which contains only a reqType and a length (and a pad byte). If the protocol request requires a reply, then -<X11/Xproto.h> +<X11/Xproto.h> also contains a reply structure typedef: @@ -2280,7 +2281,7 @@ have reply structures longer than 32 bytes in the core protocol. A few protocol requests return replies that contain no data. -<X11/Xproto.h> +<X11/Xproto.h> does not define reply structures for these. Instead, they use the xGenericReply @@ -2372,7 +2373,7 @@ Sending the Protocol Request and Arguments After the variable declarations, a stub procedure should call one of four macros defined in -<X11/Xlibint.h>: +<X11/Xlibint.h>: GetReq, GetReqExtra, GetResReq, @@ -2380,7 +2381,7 @@ or GetEmptyReq. All of these macros take, as their first argument, the name of the protocol request as declared in -<X11/Xproto.h> +<X11/Xproto.h> except with X_ removed. Each one declares a Display @@ -3297,7 +3298,7 @@ the simplest and fastest is outlined below. Declare an array of pointers, _NFILE long (this is normally found in -<stdio.h> +<stdio.h> and is the number of file descriptors supported on the system) of type XExtCodes. diff --git a/libX11/specs/libX11/AppD.xml b/libX11/specs/libX11/AppD.xml index afe65907d..3c8af3f6b 100644 --- a/libX11/specs/libX11/AppD.xml +++ b/libX11/specs/libX11/AppD.xml @@ -753,7 +753,8 @@ with the following syntax: XGetStandardColormap(dpy, DefaultRootWindow(dpy), &cmap, XA_RGB_GRAY_MAP); -See section 14.3 for the semantics of standard colormaps. +See section 14.3 for the +semantics of standard colormaps. @@ -1050,7 +1051,7 @@ geometry specifications. The XGetDefault function provides a primitive interface to the resource manager facilities -discussed in chapter 15. +discussed in chapter 15. It is only useful in very simple applications. @@ -1548,7 +1549,7 @@ dash-offset, dash-list, fill-style, and fill-rule. These functions have been superseded by the context management functions -(see section 16.10). +(see section 16.10). It is often necessary to associate arbitrary information with resource IDs. Xlib provides the XAssocTable diff --git a/libX11/specs/libX11/CH01.xml b/libX11/specs/libX11/CH01.xml index a401b9a5b..21750aba1 100644 --- a/libX11/specs/libX11/CH01.xml +++ b/libX11/specs/libX11/CH01.xml @@ -1,843 +1,846 @@ - - -Introduction to Xlib - - -The X Window System is a network-transparent window system that was -designed at MIT. X display servers run on computers with either -monochrome or color bitmap display hardware. The server distributes -user input to and accepts output requests from various client programs -located either on the same machine or elsewhere in the network. Xlib -is a C subroutine library that application programs (clients) use to -interface with the window system by means of a stream connection. -Although a client usually runs on the same machine as the X server -it is talking to, this need not be the case. - - -Xlib − C Language X Interface is a reference -guide to the low-level C language interface to the X Window System -protocol. It is neither a tutorial nor a user’s guide to programming -the X Window System. Rather, it provides a detailed description of -each function in the library as well as a discussion of the related -background information. Xlib − C Language X Interface -assumes a basic understanding of a graphics window system and of the C -programming language. Other higher-level abstractions (for example, -those provided by the toolkits for X) are built on top of the Xlib -library. For further information about these higher-level libraries, -see the appropriate toolkit documentation. -The X Window System Protocol provides the -definitive word on the behavior of X. -Although additional information appears here, the protocol document is -the ruling document. - - -To provide an introduction to X programming, this chapter discusses: - - - Overview of the X Window System - Errors - Standard header files - Generic values and types - Naming and argument conventions within Xlib - Programming considerations - Character sets and encodings - Formatting conventions - - - - - Overview of the X Window System - -Some of the terms used in this book are unique to X, -and other terms that are common to other window systems -have different meanings in X. You may find it helpful to refer to -the glossary, -which is located at the end of the book. - - -The X Window System supports one or more screens containing -overlapping windows or subwindows. -Screen -A screen is a physical monitor and hardware -that can be color, grayscale, or monochrome. -There can be multiple screens for each display or workstation. -A single X server can provide display services for any number of screens. -A set of screens for a single user with one keyboard and one pointer -(usually a mouse) is called a display. - - -All the windows in an X server are arranged in strict hierarchies. -At the top of each hierarchy is a root window, -which covers each of the display screens. -Each root window is partially or completely covered by child windows. -All windows, except for root windows, have parents. -There is usually at least one window for each application program. -Child window -Parent Window -Child windows may in turn have their own children. -In this way, -an application program can create an arbitrarily deep tree -on each screen. -X provides graphics, text, and raster operations for windows. - - -A child window can be larger than its parent. -That is, part or all of -the child window can extend beyond the boundaries of the parent, -but all output to a window is clipped by its parent. -Stacking order -If several children of a window have overlapping locations, -one of the children is considered to be on top of or raised over the -others, thus obscuring them. -Output to areas covered by other windows is suppressed by the window -system unless the window has backing store. -If a window is obscured by a second window, -the second window obscures only those ancestors of the second window -that are also ancestors of the first window. - - -Window -A window has a border zero or more pixels in width, which can -be any pattern (pixmap) or solid color you like. -A window usually but not always has a background pattern, -which will be repainted by the window system when uncovered. -Child windows obscure their parents, -and graphic operations in the parent window usually -are clipped by the children. - - -Each window and pixmap has its own coordinate system. -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. -For a window, -the origin is inside the border at the inside, upper-left corner. - - -X does not guarantee to preserve the contents of windows. -When part or all of a window is hidden and then brought back onto the screen, -its contents may be lost. -The server then sends the client program an -Expose -event to notify it that part or all of the window needs to be repainted. -Programs must be prepared to regenerate the contents of windows on demand. - - -Pixmap -Drawable -Tile -Bitmap -X also provides off-screen storage of graphics objects, -called pixmaps. -Single plane (depth 1) pixmaps are sometimes referred to as -bitmaps. -Pixmaps can be used in most graphics functions interchangeably with -windows and are used in various graphics operations to define patterns or tiles. -Windows and pixmaps together are referred to as drawables. - - -Most of the functions in Xlib just add requests to an output buffer. -These requests later execute asynchronously on the X server. -Functions that return values of information stored in -the server do not return (that is, they block) -until an explicit reply is received or an error occurs. -You can provide an error handler, -which will be called when the error is reported. - - -XSync -If a client does not want a request to execute asynchronously, -it can follow the request with a call to -XSync, -which blocks until all previously buffered -asynchronous events have been sent and acted on. -As an important side effect, -the output buffer in Xlib is always flushed by a call to any function -that returns a value from the server or waits for input. - - -Resource IDs -Resource IDsWindow -Resource IDsFont -Resource IDsPixmap -Resource IDsColormap -Resource IDsCursor -Resource IDsGContext -Many Xlib functions will return an integer resource ID, -which allows you to refer to objects stored on the X server. -These can be of type -Window, -Font, -Pixmap, -Colormap, -Cursor, -and -GContext, -as defined in the file -<X11/X.h>. -X11/X.h -Files<X11/X.h> -Headers<X11/X.h> -These resources are created by requests and are destroyed -(or freed) by requests or when connections are closed. -Most of these resources are potentially sharable between -applications, and in fact, windows are manipulated explicitly by -window manager programs. -Fonts and cursors are shared automatically across multiple screens. -Fonts are loaded and unloaded as needed and are shared by multiple clients. -Fonts are often cached in the server. -Xlib provides no support for sharing graphics contexts between applications. - - -Event -Client programs are informed of events. -Events may either be side effects of a request (for example, restacking windows -generates -Expose -events) or completely asynchronous (for example, from the keyboard). -A client program asks to be informed of events. -Because other applications can send events to your application, -programs must be prepared to handle (or ignore) events of all types. - - -Input events (for example, a key pressed or the pointer moved) -arrive asynchronously from the server and are queued until they are -requested by an explicit call (for example, -XNextEvent -or -XWindowEvent). -In addition, some library -functions (for example, -XRaiseWindow) -generate -Expose -and -ConfigureRequest -events. -These events also arrive asynchronously, but the client may -XSync -wish to explicitly wait for them by calling -XSync -after calling a function that can cause the server to generate events. - - - - - Errors - - -Some functions return -Status, -an integer error indication. -If the function fails, it returns a zero. -If the function returns a status of zero, -it has not updated the return arguments. -Status -Because C does not provide multiple return values, -many functions must return their results by writing into client-passed storage. -Errorhandling -By default, errors are handled either by a standard library function -or by one that you provide. -Functions that return pointers to strings return NULL pointers if -the string does not exist. - - -The X server reports protocol errors at the time that it detects them. -If more than one error could be generated for a given request, -the server can report any of them. - - -Because Xlib usually does not transmit requests to the server immediately -(that is, it buffers them), errors can be reported much later than they -actually occur. -For debugging purposes, however, -Xlib provides a mechanism for forcing synchronous behavior -(see section 11.8.1). -When synchronization is enabled, -errors are reported as they are generated. - - -When Xlib detects an error, -it calls an error handler, -which your program can provide. -If you do not provide an error handler, -the error is printed, and your program terminates. - - - - - Standard Header Files - - -The following include files are part of the Xlib standard: -Headers - - - - <X11/Xlib.h> - - X11/Xlib.h - Files<X11/Xlib.h> - Headers<X11/Xlib.h> - -This is the main header file for Xlib. -The majority of all Xlib symbols are declared by including this file. -This file also contains the preprocessor symbol -XlibSpecificationRelease. -XlibSpecificationRelease -This symbol is defined to have the 6 in this release of the standard. -(Release 5 of Xlib was the first release to have this symbol.) - - - - - <X11/X.h> - - X11/X.h - Files<X11/X.h> - Headers<X11/X.h> - -This file declares types and constants for the X protocol that are -to be used by applications. It is included automatically from -<X11/Xlib.h> -so application code should never need to -reference this file directly. - - - - - <X11/Xcms.h> - - X11/Xcms.h - Files<X11/Xcms.h> - Headers<X11/Xcms.h> - -This file contains symbols for much of the color management facilities -described in chapter 6. All functions, types, and symbols with the -prefix "Xcms", -plus the Color Conversion Contexts macros, are declared in this file. -<X11/Xlib.h> -must be included before including this file. - - - - - <X11/Xutil.h> - - X11/Xutil.h - Files<X11/Xutil.h> - Headers<X11/Xutil.h> - -This file declares various functions, types, and symbols used for -inter-client communication and application utility functions, -which are described in chapters 14 and 16. -<X11/Xlib.h> must be included before including this file. - - - - - <X11/Xresource.h> - - X11/Xresource.h - Files<X11/Xresource.h> - Headers<X11/Xresource.h> - -This file declares all functions, types, and symbols for the -resource manager facilities, which are described in chapter 15. -<X11/Xlib.h> -must be included before including this file. - - - - - <X11/Xatom.h> - - X11/Xatom.h - Files<X11/Xatom.h> - Headers<X11/Xatom.h> - -This file declares all predefined atoms, -which are symbols with the prefix "XA_". - - - - - <X11/cursorfont.h> - - X11/cursorfont.h - Files<X11/cursorfont.h> - Headers<X11/cursorfont.h> - -This file declares the cursor symbols for the standard cursor font, -which are listed in Appendix B. -All cursor symbols have the prefix "XC_". - - - - - <X11/keysymdef.h> - - X11/keysymdef.h - Files<X11/keysymdef.h> - Headers<X11/keysymdef.h> - -This file declares all standard KeySym values, -which are symbols with the prefix "XK_". -The KeySyms are arranged in groups, and a preprocessor symbol controls -inclusion of each group. The preprocessor symbol must be defined -prior to inclusion of the file to obtain the associated values. -The preprocessor symbols are -XK_MISCELLANY, -XK_XKB_KEYS, -XK_3270, -XK_LATIN1, -XK_LATIN2, -XK_LATIN3, -XK_LATIN4, -XK_KATAKANA, -XK_ARABIC, -XK_CYRILLIC, -XK_GREEK, -XK_TECHNICAL, -XK_SPECIAL, -XK_PUBLISHING, -XK_APL, -XK_HEBREW, -XK_THAI, and -XK_KOREAN. - - - - - <X11/keysym.h> - - X11/keysym.h - Files<X11/keysym.h> - Headers<X11/keysym.h> - -This file defines the preprocessor symbols -XK_MISCELLANY, -XK_XKB_KEYS, -XK_LATIN1, -XK_LATIN2, -XK_LATIN3, -XK_LATIN4, and -XK_GREEK -and then includes <X11/keysymdef.h>. - - - - - <X11/Xlibint.h> - - X11/Xlibint.h - Files<X11/Xlibint.h> - Headers<X11/Xlibint.h> - -This file declares all the functions, types, and symbols used for -extensions, which are described in Appendix C. -This file automatically includes -<X11/Xlib.h>. - - - - - <X11/Xproto.h> - - X11/Xproto.h - Files<X11/Xproto.h> - Headers<X11/Xproto.h> - -This file declares types and symbols for the basic X protocol, -for use in implementing extensions. -It is included automatically from -<X11/Xlibint.h>, -so application and extension code should never need to -reference this file directly. - - - - - <X11/Xprotostr.h> - - X11/Xprotostr.h - Files<X11/Xprotostr.h> - Headers<X11/Xprotostr.h> - -This file declares types and symbols for the basic X protocol, -for use in implementing extensions. -It is included automatically from -<X11/Xproto.h>, -so application and extension code should never need to -reference this file directly. - - - - - <X11/X10.h> - - X11/X10.h - Files<X11/X10.h> - Headers<X11/X10.h> - -This file declares all the functions, types, and symbols used for the -X10 compatibility functions, which are described in -Appendix D. - - - - - - - - - Generic Values and Types - - -The following symbols are defined by Xlib and used throughout the manual: - - - -Bool -True -False -Xlib defines the type -Bool -and the Boolean values -True -and -False. - - - - -None -None -is the universal null resource ID or atom. - - - - -XID -The type -XID -is used for generic resource IDs. - - - - -XPointer -The type XPointer is defined to be char * -and is used as a generic opaque pointer to data. - - - - - - - - Naming and Argument Conventions within Xlib - - -Xlib follows a number of conventions for the naming and syntax of the functions. -Given that you remember what information the function requires, -these conventions are intended to make the syntax of the functions more -predictable. - - -The major naming conventions are: - - - -To differentiate the X symbols from the other symbols, -the library uses mixed case for external symbols. -It leaves lowercase for variables and all uppercase for user macros, -as per existing convention. - - - - -All Xlib functions begin with a capital X. - - - - -The beginnings of all function names and symbols are capitalized. - - - - -All user-visible data structures begin with a capital X. -More generally, -anything that a user might dereference begins with a capital X. - - - - -Macros and other symbols do not begin with a capital X. -To distinguish them from all user symbols, -each word in the macro is capitalized. - - - - -All elements of or variables in a data structure are in lowercase. -Compound words, where needed, are constructed with underscores (_). - - - - -The display argument, where used, is always first in the argument list. - - - - -All resource objects, where used, occur at the beginning of the argument list -immediately after the display argument. - - - - -When a graphics context is present together with -another type of resource (most commonly, a drawable), the -graphics context occurs in the argument list after the other -resource. -Drawables outrank all other resources. - - - - -Source arguments always precede the destination arguments in the argument list. - - - - -The x argument always precedes the y argument in the argument list. - - - - -The width argument always precedes the height argument in the argument list. - - - - -Where the x, y, width, and height arguments are used together, -the x and y arguments always precede the width and height arguments. - - - - -Where a mask is accompanied with a structure, -the mask always precedes the pointer to the structure in the argument list. - - - - - - - - Programming Considerations - - -The major programming considerations are: - - - -Coordinates and sizes in X are actually 16-bit quantities. -This decision was made to minimize the bandwidth required for a -given level of performance. -Coordinates usually are declared as an -int -in the interface. -Values larger than 16 bits are truncated silently. -Sizes (width and height) are declared as unsigned quantities. - - - - -Keyboards are the greatest variable between different -manufacturers' workstations. -If you want your program to be portable, -you should be particularly conservative here. - - - - -Many display systems have limited amounts of off-screen memory. -If you can, you should minimize use of pixmaps and backing -store. - - - - -The user should have control of his screen real estate. -Therefore, you should write your applications to react to window management -rather than presume control of the entire screen. -What you do inside of your top-level window, however, -is up to your application. -For further information, -see chapter 14 -and the Inter-Client Communication Conventions Manual. - - - - - - - - Character Sets and Encodings - - -Some of the Xlib functions make reference to specific character sets -and character encodings. -The following are the most common: - - - - X Portable Character Set - -A basic set of 97 characters, -which are assumed to exist in all locales supported by Xlib. -This set contains the following characters: - -a..z A..Z 0..9 !"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~ <space>, <tab>, and <newline> - - - -This set is the left/lower half -of the graphic character set of ISO8859-1 plus space, tab, and newline. -It is also the set of graphic characters in 7-bit ASCII plus the same -three control characters. -The actual encoding of these characters on the host is system dependent. - - - - - Host Portable Character Encoding - - -The encoding of the X Portable Character Set on the host. -The encoding itself is not defined by this standard, -but the encoding must be the same in all locales supported by Xlib on the host. -If a string is said to be in the Host Portable Character Encoding, -then it only contains characters from the X Portable Character Set, -in the host encoding. - - - - - Latin-1 - - -The coded character set defined by the ISO8859-1 standard. - - - - - Latin Portable Character Encoding - - -The encoding of the X Portable Character Set using the Latin-1 codepoints -plus ASCII control characters. -If a string is said to be in the Latin Portable Character Encoding, -then it only contains characters from the X Portable Character Set, -not all of Latin-1. - - - - - STRING Encoding - - -Latin-1, plus tab and newline. - - - - - POSIX Portable Filename Character Set - - -The set of 65 characters, -which can be used in naming files on a POSIX-compliant host, -that are correctly processed in all locales. -The set is: - -a..z A..Z 0..9 ._- - - - - - - - - - - Formatting Conventions - - - Xlib − C Language X Interface uses the - following conventions: - - - - -Global symbols are printed in -this -special -font. -These can be either function names, -symbols defined in include files, or structure names. -When declared and defined, -function arguments are printed in italics. -In the explanatory text that follows, -they usually are printed in regular type. - - - - -Each function is introduced by a general discussion that -distinguishes it from other functions. -The function declaration itself follows, -and each argument is specifically explained. -Although ANSI C function prototype syntax is not used, -Xlib header files normally declare functions using function prototypes -in ANSI C environments. -General discussion of the function, if any is required, -follows the arguments. -Where applicable, -the last paragraph of the explanation lists the possible -Xlib error codes that the function can generate. -For a complete discussion of the Xlib error codes, -see section 11.8.2. - - - - -To eliminate any ambiguity between those arguments that you pass and those that -a function returns to you, -the explanations for all arguments that you pass start with the word -specifies or, in the case of multiple arguments, the word specify. -The explanations for all arguments that are returned to you start with the -word returns or, in the case of multiple arguments, the word return. -The explanations for all arguments that you can pass and are returned start -with the words specifies and returns. - - - - -Any pointer to a structure that is used to return a value is designated as -such by the _return suffix as part of its name. -All other pointers passed to these functions are -used for reading only. -A few arguments use pointers to structures that are used for -both input and output and are indicated by using the _in_out suffix. - - - - - - + + +Introduction to Xlib + + +The X Window System is a network-transparent window system that was +designed at MIT. X display servers run on computers with either +monochrome or color bitmap display hardware. The server distributes +user input to and accepts output requests from various client programs +located either on the same machine or elsewhere in the network. Xlib +is a C subroutine library that application programs (clients) use to +interface with the window system by means of a stream connection. +Although a client usually runs on the same machine as the X server +it is talking to, this need not be the case. + + +Xlib − C Language X Interface is a reference +guide to the low-level C language interface to the X Window System +protocol. It is neither a tutorial nor a user’s guide to programming +the X Window System. Rather, it provides a detailed description of +each function in the library as well as a discussion of the related +background information. Xlib − C Language X Interface +assumes a basic understanding of a graphics window system and of the C +programming language. Other higher-level abstractions (for example, +those provided by the toolkits for X) are built on top of the Xlib +library. For further information about these higher-level libraries, +see the appropriate toolkit documentation. +The X Window System Protocol provides the +definitive word on the behavior of X. +Although additional information appears here, the protocol document is +the ruling document. + + +To provide an introduction to X programming, this chapter discusses: + + + Overview of the X Window System + Errors + Standard header files + Generic values and types + Naming and argument conventions within Xlib + Programming considerations + Character sets and encodings + Formatting conventions + + + + + Overview of the X Window System + +Some of the terms used in this book are unique to X, +and other terms that are common to other window systems +have different meanings in X. You may find it helpful to refer to +the glossary, +which is located at the end of the book. + + +The X Window System supports one or more screens containing +overlapping windows or subwindows. +Screen +A screen is a physical monitor and hardware +that can be color, grayscale, or monochrome. +There can be multiple screens for each display or workstation. +A single X server can provide display services for any number of screens. +A set of screens for a single user with one keyboard and one pointer +(usually a mouse) is called a display. + + +All the windows in an X server are arranged in strict hierarchies. +At the top of each hierarchy is a root window, +which covers each of the display screens. +Each root window is partially or completely covered by child windows. +All windows, except for root windows, have parents. +There is usually at least one window for each application program. +Child window +Parent Window +Child windows may in turn have their own children. +In this way, +an application program can create an arbitrarily deep tree +on each screen. +X provides graphics, text, and raster operations for windows. + + +A child window can be larger than its parent. +That is, part or all of +the child window can extend beyond the boundaries of the parent, +but all output to a window is clipped by its parent. +Stacking order +If several children of a window have overlapping locations, +one of the children is considered to be on top of or raised over the +others, thus obscuring them. +Output to areas covered by other windows is suppressed by the window +system unless the window has backing store. +If a window is obscured by a second window, +the second window obscures only those ancestors of the second window +that are also ancestors of the first window. + + +Window +A window has a border zero or more pixels in width, which can +be any pattern (pixmap) or solid color you like. +A window usually but not always has a background pattern, +which will be repainted by the window system when uncovered. +Child windows obscure their parents, +and graphic operations in the parent window usually +are clipped by the children. + + +Each window and pixmap has its own coordinate system. +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. +For a window, +the origin is inside the border at the inside, upper-left corner. + + +X does not guarantee to preserve the contents of windows. +When part or all of a window is hidden and then brought back onto the screen, +its contents may be lost. +The server then sends the client program an +Expose +event to notify it that part or all of the window needs to be repainted. +Programs must be prepared to regenerate the contents of windows on demand. + + +Pixmap +Drawable +Tile +Bitmap +X also provides off-screen storage of graphics objects, +called pixmaps. +Single plane (depth 1) pixmaps are sometimes referred to as +bitmaps. +Pixmaps can be used in most graphics functions interchangeably with +windows and are used in various graphics operations to define patterns or tiles. +Windows and pixmaps together are referred to as drawables. + + +Most of the functions in Xlib just add requests to an output buffer. +These requests later execute asynchronously on the X server. +Functions that return values of information stored in +the server do not return (that is, they block) +until an explicit reply is received or an error occurs. +You can provide an error handler, +which will be called when the error is reported. + + +XSync +If a client does not want a request to execute asynchronously, +it can follow the request with a call to +XSync, +which blocks until all previously buffered +asynchronous events have been sent and acted on. +As an important side effect, +the output buffer in Xlib is always flushed by a call to any function +that returns a value from the server or waits for input. + + +Resource IDs +Resource IDsWindow +Resource IDsFont +Resource IDsPixmap +Resource IDsColormap +Resource IDsCursor +Resource IDsGContext +Many Xlib functions will return an integer resource ID, +which allows you to refer to objects stored on the X server. +These can be of type +Window, +Font, +Pixmap, +Colormap, +Cursor, +and +GContext, +as defined in the file +<X11/X.h>. +X11/X.h +Files<X11/X.h> +Headers<X11/X.h> +These resources are created by requests and are destroyed +(or freed) by requests or when connections are closed. +Most of these resources are potentially sharable between +applications, and in fact, windows are manipulated explicitly by +window manager programs. +Fonts and cursors are shared automatically across multiple screens. +Fonts are loaded and unloaded as needed and are shared by multiple clients. +Fonts are often cached in the server. +Xlib provides no support for sharing graphics contexts between applications. + + +Event +Client programs are informed of events. +Events may either be side effects of a request (for example, restacking windows +generates +Expose +events) or completely asynchronous (for example, from the keyboard). +A client program asks to be informed of events. +Because other applications can send events to your application, +programs must be prepared to handle (or ignore) events of all types. + + +Input events (for example, a key pressed or the pointer moved) +arrive asynchronously from the server and are queued until they are +requested by an explicit call (for example, +XNextEvent +or +XWindowEvent). +In addition, some library +functions (for example, +XRaiseWindow) +generate +Expose +and +ConfigureRequest +events. +These events also arrive asynchronously, but the client may +XSync +wish to explicitly wait for them by calling +XSync +after calling a function that can cause the server to generate events. + + + + + Errors + + +Some functions return +Status, +an integer error indication. +If the function fails, it returns a zero. +If the function returns a status of zero, +it has not updated the return arguments. +Status +Because C does not provide multiple return values, +many functions must return their results by writing into client-passed storage. +Errorhandling +By default, errors are handled either by a standard library function +or by one that you provide. +Functions that return pointers to strings return NULL pointers if +the string does not exist. + + +The X server reports protocol errors at the time that it detects them. +If more than one error could be generated for a given request, +the server can report any of them. + + +Because Xlib usually does not transmit requests to the server immediately +(that is, it buffers them), errors can be reported much later than they +actually occur. +For debugging purposes, however, +Xlib provides a mechanism for forcing synchronous behavior +(see section 11.8.1). +When synchronization is enabled, +errors are reported as they are generated. + + +When Xlib detects an error, +it calls an error handler, +which your program can provide. +If you do not provide an error handler, +the error is printed, and your program terminates. + + + + + Standard Header Files + + +The following include files are part of the Xlib standard: +Headers + + + + <X11/Xlib.h> + + X11/Xlib.h + Files<X11/Xlib.h> + Headers<X11/Xlib.h> + +This is the main header file for Xlib. +The majority of all Xlib symbols are declared by including this file. +This file also contains the preprocessor symbol +XlibSpecificationRelease. +XlibSpecificationRelease +This symbol is defined to have the 6 in this release of the standard. +(Release 5 of Xlib was the first release to have this symbol.) + + + + + <X11/X.h> + + X11/X.h + Files<X11/X.h> + Headers<X11/X.h> + +This file declares types and constants for the X protocol that are +to be used by applications. It is included automatically from +<X11/Xlib.h> +so application code should never need to +reference this file directly. + + + + + <X11/Xcms.h> + + X11/Xcms.h + Files<X11/Xcms.h> + Headers<X11/Xcms.h> + +This file contains symbols for much of the color management facilities +described in chapter 6. +All functions, types, and symbols with the prefix "Xcms", +plus the Color Conversion Contexts macros, are declared in this file. +<X11/Xlib.h> +must be included before including this file. + + + + + <X11/Xutil.h> + + X11/Xutil.h + Files<X11/Xutil.h> + Headers<X11/Xutil.h> + +This file declares various functions, types, and symbols used for +inter-client communication and application utility functions, +which are described in chapters +14 and +16. +<X11/Xlib.h> must be included before including this file. + + + + + <X11/Xresource.h> + + X11/Xresource.h + Files<X11/Xresource.h> + Headers<X11/Xresource.h> + +This file declares all functions, types, and symbols for the +resource manager facilities, which are described in +chapter 15. +<X11/Xlib.h> +must be included before including this file. + + + + + <X11/Xatom.h> + + X11/Xatom.h + Files<X11/Xatom.h> + Headers<X11/Xatom.h> + +This file declares all predefined atoms, +which are symbols with the prefix "XA_". + + + + + <X11/cursorfont.h> + + X11/cursorfont.h + Files<X11/cursorfont.h> + Headers<X11/cursorfont.h> + +This file declares the cursor symbols for the standard cursor font, +which are listed in Appendix B. +All cursor symbols have the prefix "XC_". + + + + + <X11/keysymdef.h> + + X11/keysymdef.h + Files<X11/keysymdef.h> + Headers<X11/keysymdef.h> + +This file declares all standard KeySym values, +which are symbols with the prefix "XK_". +The KeySyms are arranged in groups, and a preprocessor symbol controls +inclusion of each group. The preprocessor symbol must be defined +prior to inclusion of the file to obtain the associated values. +The preprocessor symbols are +XK_MISCELLANY, +XK_XKB_KEYS, +XK_3270, +XK_LATIN1, +XK_LATIN2, +XK_LATIN3, +XK_LATIN4, +XK_KATAKANA, +XK_ARABIC, +XK_CYRILLIC, +XK_GREEK, +XK_TECHNICAL, +XK_SPECIAL, +XK_PUBLISHING, +XK_APL, +XK_HEBREW, +XK_THAI, and +XK_KOREAN. + + + + + <X11/keysym.h> + + X11/keysym.h + Files<X11/keysym.h> + Headers<X11/keysym.h> + +This file defines the preprocessor symbols +XK_MISCELLANY, +XK_XKB_KEYS, +XK_LATIN1, +XK_LATIN2, +XK_LATIN3, +XK_LATIN4, and +XK_GREEK +and then includes <X11/keysymdef.h>. + + + + + <X11/Xlibint.h> + + X11/Xlibint.h + Files<X11/Xlibint.h> + Headers<X11/Xlibint.h> + +This file declares all the functions, types, and symbols used for +extensions, which are described in Appendix C. +This file automatically includes +<X11/Xlib.h>. + + + + + <X11/Xproto.h> + + X11/Xproto.h + Files<X11/Xproto.h> + Headers<X11/Xproto.h> + +This file declares types and symbols for the basic X protocol, +for use in implementing extensions. +It is included automatically from +<X11/Xlibint.h>, +so application and extension code should never need to +reference this file directly. + + + + + <X11/Xprotostr.h> + + X11/Xprotostr.h + Files<X11/Xprotostr.h> + Headers<X11/Xprotostr.h> + +This file declares types and symbols for the basic X protocol, +for use in implementing extensions. +It is included automatically from +<X11/Xproto.h>, +so application and extension code should never need to +reference this file directly. + + + + + <X11/X10.h> + + X11/X10.h + Files<X11/X10.h> + Headers<X11/X10.h> + +This file declares all the functions, types, and symbols used for the +X10 compatibility functions, which are described in +Appendix D. + + + + + + + + + Generic Values and Types + + +The following symbols are defined by Xlib and used throughout the manual: + + + +Bool +True +False +Xlib defines the type +Bool +and the Boolean values +True +and +False. + + + + +None +None +is the universal null resource ID or atom. + + + + +XID +The type +XID +is used for generic resource IDs. + + + + +XPointer +The type XPointer is defined to be char * +and is used as a generic opaque pointer to data. + + + + + + + + Naming and Argument Conventions within Xlib + + +Xlib follows a number of conventions for the naming and syntax of the functions. +Given that you remember what information the function requires, +these conventions are intended to make the syntax of the functions more +predictable. + + +The major naming conventions are: + + + +To differentiate the X symbols from the other symbols, +the library uses mixed case for external symbols. +It leaves lowercase for variables and all uppercase for user macros, +as per existing convention. + + + + +All Xlib functions begin with a capital X. + + + + +The beginnings of all function names and symbols are capitalized. + + + + +All user-visible data structures begin with a capital X. +More generally, +anything that a user might dereference begins with a capital X. + + + + +Macros and other symbols do not begin with a capital X. +To distinguish them from all user symbols, +each word in the macro is capitalized. + + + + +All elements of or variables in a data structure are in lowercase. +Compound words, where needed, are constructed with underscores (_). + + + + +The display argument, where used, is always first in the argument list. + + + + +All resource objects, where used, occur at the beginning of the argument list +immediately after the display argument. + + + + +When a graphics context is present together with +another type of resource (most commonly, a drawable), the +graphics context occurs in the argument list after the other +resource. +Drawables outrank all other resources. + + + + +Source arguments always precede the destination arguments in the argument list. + + + + +The x argument always precedes the y argument in the argument list. + + + + +The width argument always precedes the height argument in the argument list. + + + + +Where the x, y, width, and height arguments are used together, +the x and y arguments always precede the width and height arguments. + + + + +Where a mask is accompanied with a structure, +the mask always precedes the pointer to the structure in the argument list. + + + + + + + + Programming Considerations + + +The major programming considerations are: + + + +Coordinates and sizes in X are actually 16-bit quantities. +This decision was made to minimize the bandwidth required for a +given level of performance. +Coordinates usually are declared as an +int +in the interface. +Values larger than 16 bits are truncated silently. +Sizes (width and height) are declared as unsigned quantities. + + + + +Keyboards are the greatest variable between different +manufacturers' workstations. +If you want your program to be portable, +you should be particularly conservative here. + + + + +Many display systems have limited amounts of off-screen memory. +If you can, you should minimize use of pixmaps and backing +store. + + + + +The user should have control of his screen real estate. +Therefore, you should write your applications to react to window management +rather than presume control of the entire screen. +What you do inside of your top-level window, however, +is up to your application. +For further information, +see chapter 14 +and the Inter-Client Communication Conventions Manual. + + + + + + + + Character Sets and Encodings + + +Some of the Xlib functions make reference to specific character sets +and character encodings. +The following are the most common: + + + + X Portable Character Set + +A basic set of 97 characters, +which are assumed to exist in all locales supported by Xlib. +This set contains the following characters: + +a..z A..Z 0..9 !"#$%&'()*+,-./:;<=>?@[\\]^_`{|}~ <space>, <tab>, and <newline> + + + +This set is the left/lower half +of the graphic character set of ISO8859-1 plus space, tab, and newline. +It is also the set of graphic characters in 7-bit ASCII plus the same +three control characters. +The actual encoding of these characters on the host is system dependent. + + + + + Host Portable Character Encoding + + +The encoding of the X Portable Character Set on the host. +The encoding itself is not defined by this standard, +but the encoding must be the same in all locales supported by Xlib on the host. +If a string is said to be in the Host Portable Character Encoding, +then it only contains characters from the X Portable Character Set, +in the host encoding. + + + + + Latin-1 + + +The coded character set defined by the ISO8859-1 standard. + + + + + Latin Portable Character Encoding + + +The encoding of the X Portable Character Set using the Latin-1 codepoints +plus ASCII control characters. +If a string is said to be in the Latin Portable Character Encoding, +then it only contains characters from the X Portable Character Set, +not all of Latin-1. + + + + + STRING Encoding + + +Latin-1, plus tab and newline. + + + + + POSIX Portable Filename Character Set + + +The set of 65 characters, +which can be used in naming files on a POSIX-compliant host, +that are correctly processed in all locales. +The set is: + +a..z A..Z 0..9 ._- + + + + + + + + + + Formatting Conventions + + + Xlib − C Language X Interface uses the + following conventions: + + + + +Global symbols are printed in +this +special +font. +These can be either function names, +symbols defined in include files, or structure names. +When declared and defined, +function arguments are printed in italics. +In the explanatory text that follows, +they usually are printed in regular type. + + + + +Each function is introduced by a general discussion that +distinguishes it from other functions. +The function declaration itself follows, +and each argument is specifically explained. +Although ANSI C function prototype syntax is not used, +Xlib header files normally declare functions using function prototypes +in ANSI C environments. +General discussion of the function, if any is required, +follows the arguments. +Where applicable, +the last paragraph of the explanation lists the possible +Xlib error codes that the function can generate. +For a complete discussion of the Xlib error codes, +see section 11.8.2. + + + + +To eliminate any ambiguity between those arguments that you pass and those that +a function returns to you, +the explanations for all arguments that you pass start with the word +specifies or, in the case of multiple arguments, the word specify. +The explanations for all arguments that are returned to you start with the +word returns or, in the case of multiple arguments, the word return. +The explanations for all arguments that you can pass and are returned start +with the words specifies and returns. + + + + +Any pointer to a structure that is used to return a value is designated as +such by the _return suffix as part of its name. +All other pointers passed to these functions are +used for reading only. +A few arguments use pointers to structures that are used for +both input and output and are indicated by using the _in_out suffix. + + + + + + diff --git a/libX11/specs/libX11/CH02.xml b/libX11/specs/libX11/CH02.xml index 901a38503..4a57266bd 100644 --- a/libX11/specs/libX11/CH02.xml +++ b/libX11/specs/libX11/CH02.xml @@ -158,7 +158,8 @@ using the DefaultScreen macro or the XDefaultScreen -function if you are using languages other than C (see section 2.2.1). +function if you are using languages other than C +(see section 2.2.1). @@ -242,12 +243,12 @@ For information about using macros and functions to obtain information from the Display structure, -see section 2.2.1. +see section 2.2.1. X servers may implement various types of access control mechanisms -(see section 9.8). +(see section 9.8). @@ -886,7 +887,7 @@ Specifies the appropriate screen number on the host server. XDefaultVisual Both return the default visual type for the specified screen. For further information about visual types, -see section 3.1. +see section 3.1. @@ -1476,7 +1477,9 @@ Applications are required to present data to the X server in a format that the server demands. To help simplify applications, most of the work required to convert the data is provided by Xlib -(see sections 8.7 and 16.8). +(see sections +8.7 and +16.8). @@ -2166,7 +2169,7 @@ structure. XDefaultVisualOfScreen Both return the default visual of the specified screen. For information on visual types, -see section 3.1. +see section 3.1. @@ -2209,7 +2212,7 @@ The value returned can be one of NotUseful, or Always -(see section 3.2.4). +(see section 3.2.4). @@ -2252,7 +2255,8 @@ If the screen supports save unders. If False, -the screen does not support save unders (see section 3.2.5). +the screen does not support save unders +(see section 3.2.5). @@ -2543,7 +2547,8 @@ structure. MaxCmapsOfScreen XMaxCmapsOfScreen Both return the maximum number of installed colormaps supported -by the specified screen (see section 9.3). +by the specified screen +(see section 9.3). @@ -2580,7 +2585,8 @@ structure. MinCmapsOfScreen XMinCmapsOfScreen Both return the minimum number of installed colormaps supported -by the specified screen (see section 9.3). +by the specified screen +(see section 9.3). @@ -2871,7 +2877,7 @@ close_mode argument is RetainPermanent or RetainTemporary, -see section 2.6. +see section 2.6. @@ -3020,7 +3026,8 @@ It deletes all but the predefined atom identifiers. -It deletes all properties on all root windows (see section 4.3). +It deletes all properties on all root windows +(see section 4.3). @@ -3198,7 +3205,9 @@ for threads using In addition to the connection to the X server, an Xlib implementation may require connections to other kinds of servers (for example, to -input method servers as described in chapter 13). Toolkits and clients +input method servers as described in +chapter 13). +Toolkits and clients that use multiple displays, or that use displays in combination with other inputs, need to obtain these additional connections to correctly block until input is available and need to process that input diff --git a/libX11/specs/libX11/CH03.xml b/libX11/specs/libX11/CH03.xml index 9cbacd83b..d26a814c3 100644 --- a/libX11/specs/libX11/CH03.xml +++ b/libX11/specs/libX11/CH03.xml @@ -23,7 +23,8 @@ Because default windows and visual types are defined for each screen, most simple applications need not deal with this complexity. Xlib provides macros and functions that return the default root window, the default depth of the default root window, and the default visual type -(see sections 2.2.1 and 16.7). +(see sections 2.2.1 +and 16.7). @@ -31,7 +32,9 @@ Xlib uses an opaque Visual Visual structure that contains information about the possible color mapping. -The visual utility functions (see section 16.7) use an +The visual utility functions +(see section 16.7) +use an XVisualInfo structure to return this information to an application. The members of this structure pertinent to this discussion are class, red_mask, @@ -217,7 +220,8 @@ All InputOutput windows have a border width of zero or more pixels, an optional background, an event suppression mask (which suppresses propagation of events from -children), and a property list (see section 4.3). +children), and a property list +(see section 4.3). The window border and background can be a solid color or a pattern, called a tile. All windows except the root have a parent and are clipped by their parent. @@ -231,7 +235,8 @@ obscured area. -Windows also have associated property lists (see section 4.3). +Windows also have associated property lists +(see section 4.3). @@ -644,7 +649,7 @@ Otherwise, the initial contents of the exposed regions are undefined. events are then generated for the regions, even if the background-pixmap is None -(see section 10.9). +(see section 10.9). @@ -813,7 +818,8 @@ the corresponding pair defines the change in position of the window within the parent. When a window is so repositioned, a GravityNotify -event is generated (see section 10.10.5). +event is generated +(see section 10.10.5). @@ -1066,7 +1072,7 @@ or False (default). Window managers use this information to avoid tampering with pop-up windows -(see also chapter 14). +(see also chapter 14). @@ -1161,7 +1167,7 @@ which are discussed in the appropriate toolkit documentation. If you do not use a toolkit, however, you must provide some standard information or hints for the window manager by using the Xlib inter-client communication functions -(see chapter 14). +(see chapter 14). @@ -1205,7 +1211,8 @@ you should set these properties for top-level windows before mapping them. For further information, -see chapter 14 and the Inter-Client Communication Conventions Manual. +see chapter 14 and +the Inter-Client Communication Conventions Manual. @@ -1868,7 +1875,8 @@ windows and then decide to map the window to its final location. A window manager that wants to provide decoration might reparent the child into a frame first. For further information, -see sections 3.2.8 and 10.10. +see sections 3.2.8 +and 10.10. Only a single client at a time can select for SubstructureRedirectMask. @@ -2398,7 +2406,8 @@ children of the window are affected as specified. If a window's size actually changes, the window's subwindows move according to their window gravity. Depending on the window's bit gravity, -the contents of the window also may be moved (see section 3.2.3). +the contents of the window also may be moved +(see section 3.2.3). @@ -3558,7 +3567,7 @@ Specifies the structure from which the values (as specified by the value mask) are to be taken. The value mask should have the appropriate bits set to indicate which attributes have been set in the structure -(see section 3.2). +(see section 3.2). diff --git a/libX11/specs/libX11/CH04.xml b/libX11/specs/libX11/CH04.xml index d224216d3..79f8fa949 100644 --- a/libX11/specs/libX11/CH04.xml +++ b/libX11/specs/libX11/CH04.xml @@ -291,7 +291,7 @@ and can be one of the following: For additional information on gravity, -see section 3.2.3. +see section 3.2.3. @@ -817,7 +817,7 @@ the current state of the mouse buttons and the modifier keys. Note that the logical state of a device (as seen through Xlib) may lag the physical state if device event processing is frozen -(see section 12.1). +(see section 12.1). @@ -867,7 +867,7 @@ If you define further properties of complex type, you must encode and decode them yourself. These functions must be carefully written if they are to be portable. For further information about how to write a library extension, -see appendix C. +see appendix C. The type of a property is defined by an atom, which allows for arbitrary extension in this type scheme. @@ -887,7 +887,7 @@ To avoid name clashes with user symbols, the name for each atom has the XA_ prefix. For an explanation of the functions that let you get and set much of the information stored in these predefined properties, -see chapter 14. +see chapter 14. @@ -1040,7 +1040,7 @@ The built-in font property names are: For further information about font properties, -see section 8.5. +see section 8.5. @@ -1381,7 +1381,8 @@ error. You can attach a property list to every window. -Each property has a name, a type, and a value (see section 4.3). +Each property has a name, a type, and a value +(see section 4.3). The value is an array of 8-bit, 16-bit, or 32-bit quantities, whose interpretation is left to the clients. The type char @@ -1396,7 +1397,8 @@ is used to represent 32-bit quantities. Xlib provides functions that you can use to obtain, change, update, or interchange window properties. In addition, Xlib provides other utility functions for inter-client -communication (see chapter 14). +communication +(see chapter 14). @@ -1934,7 +1936,7 @@ The lifetime of a property is not tied to the storing client. Properties remain until explicitly deleted, until the window is destroyed, or until the server resets. For a discussion of what happens when the connection to the X server is closed, -see section 2.6. +see section 2.6. The maximum size of a property is server dependent and can vary dynamically depending on the amount of memory the server has available. (If there is insufficient space, a diff --git a/libX11/specs/libX11/CH05.xml b/libX11/specs/libX11/CH05.xml index 3ad7076ea..6df3509a6 100644 --- a/libX11/specs/libX11/CH05.xml +++ b/libX11/specs/libX11/CH05.xml @@ -277,7 +277,7 @@ The initial colors of a cursor are a black foreground and a white background (see XRecolorCursor). For further information about cursor shapes, -see appendix B. +see appendix B. diff --git a/libX11/specs/libX11/CH06.xml b/libX11/specs/libX11/CH06.xml index ab5cec031..bd3c1adc3 100644 --- a/libX11/specs/libX11/CH06.xml +++ b/libX11/specs/libX11/CH06.xml @@ -172,7 +172,7 @@ Possible visual types are TrueColor, or DirectColor -(see section 3.1). +(see section 3.1). Color Structures @@ -294,7 +294,7 @@ it indicates that the color specification is in a device-dependent form; otherwise, it is in a device-independent form. If the 31st bit is set, this indicates that the color space has been added to Xlib at run time -(see section 6.12.4). +(see section 6.12.4). The format value for a color space added at run time may be different each time the program is executed. If references to such a color space must be made outside the client @@ -917,7 +917,7 @@ if alloc is the colormap initially has no allocated entries, and clients can allocate them. For information about the visual types, -see section 3.1. +see section 3.1. diff --git a/libX11/specs/libX11/CH07.xml b/libX11/specs/libX11/CH07.xml index ff1a9d836..32c94f15a 100644 --- a/libX11/specs/libX11/CH07.xml +++ b/libX11/specs/libX11/CH07.xml @@ -3197,7 +3197,7 @@ errors. Xlib provides a set of basic functions for performing region arithmetic. For information about these functions, -see section 16.5. +see section 16.5. diff --git a/libX11/specs/libX11/CH08.xml b/libX11/specs/libX11/CH08.xml index 5f450fe9d..e6eae13be 100644 --- a/libX11/specs/libX11/CH08.xml +++ b/libX11/specs/libX11/CH08.xml @@ -5268,7 +5268,7 @@ frequently used data formats by replacing functions in the procedure vector with special case functions. Supported operations include destroying the image, getting a pixel, storing a pixel, extracting a subimage of an image, and adding a constant -to an image (see section 16.8). +to an image (see section 16.8). diff --git a/libX11/specs/libX11/CH09.xml b/libX11/specs/libX11/CH09.xml index eff97c39c..2389e824d 100644 --- a/libX11/specs/libX11/CH09.xml +++ b/libX11/specs/libX11/CH09.xml @@ -194,7 +194,7 @@ 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 should be remapped if they are unmapped. For further information about close-connection processing, -see section 2.6. +see section 2.6. To allow an application's window to survive when a window manager that has reparented a window fails, Xlib provides the save-set functions that you can @@ -992,7 +992,7 @@ If AllTemporary is specified, the resources of all clients that have terminated in RetainTemporary -are destroyed (see section 2.5). +are destroyed (see section 2.5). This permits implementation of window manager facilities that aid debugging. A client can set its close-down mode to RetainTemporary. diff --git a/libX11/specs/libX11/CH10.xml b/libX11/specs/libX11/CH10.xml index e7b945323..8a06a706f 100644 --- a/libX11/specs/libX11/CH10.xml +++ b/libX11/specs/libX11/CH10.xml @@ -1,4739 +1,4742 @@ - - - -Events - - -A client application communicates with the X server through the connection you establish with -the XOpenDisplay function. A client application sends requests to the X server over this -connection. These requests are made by the Xlib functions that are called in the client application. -Many Xlib functions cause the X server to generate events, and the user’s typing or moving the -pointer can generate events asynchronously. The X server returns events to the client on the same -connection. - - -This chapter discusses the following topics associated with events: - - - - Event types - Event structures - Event masks - Event processing - - - -Functions for handling events are dealt with in the next chapter. - - - -Event Types - - - - - -Eventtypes -An event is data generated asynchronously by the X server as a result of some -device activity or as side effects of a request sent by an Xlib function. -Event -Device-related events propagate from the source window to ancestor windows -until some client application has selected that event type -or until the event is explicitly discarded. -The X server generally sends an event to a client application -only if the client has specifically asked to be informed of that event type, -typically by setting the event-mask attribute of the window. -The mask can also be set when you create a window -or by changing the window's -event-mask. -You can also mask out events that would propagate to ancestor windows -by manipulating the -do-not-propagate mask of the window's attributes. -However, -MappingNotify -events are always sent to all clients. -Input Control -Output Control - - - -An event type describes a specific event generated by the X server. -For each event type, -a corresponding constant name is defined in -<X11/X.h>, -X11/X.h -Files<X11/X.h> -Headers<X11/X.h> -which is used when referring to an event type. -Eventcategories -The following table lists the event category -and its associated event type or types. -The processing associated with these events is discussed in section 10.5. - - - - - - - - - - - - - - - Event Category - Event Type - - - - - Keyboard events - KeyPress, - KeyRelease - - - Pointer events - ButtonPress, - ButtonRelease, - MotionNotify - - - Window crossing events - EnterNotify, - LeaveNotify - - - Input focus events - FocusIn, - FocusOut - - - Keymap state notification event - KeymapNotify - - - Exposure events - Expose, - GraphicsExpose, - NoExpose - - - Structure control events - CirculateRequest, - ConfigureRequest, - MapRequest, - ResizeRequest - - - Window state notification events - - CirculateNotify, - ConfigureNotify, - CreateNotify, - DestroyNotify, - GravityNotify, - MapNotify, - MappingNotify, - ReparentNotify, - UnmapNotify, - VisibilityNotify - - - Colormap state notification event - ColormapNotify - - - Client communication events - ClientMessage, - PropertyNotify, - SelectionClear, - SelectionNotify, - SelectionRequest - - - - - - - - - - - - - - - - - -Event Structures - - - - - -For each event type, -a corresponding structure is declared in -<X11/Xlib.h>. -X11/Xlib.h -Files<X11/Xlib.h> -Headers<X11/Xlib.h> -All the event structures have the following common members: - - - -XAnyEvent - - - - -typedef struct { - int type; - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; -} XAnyEvent; - - - - - -The type member is set to the event type constant name that uniquely identifies -it. -For example, when the X server reports a -GraphicsExpose -event to a client application, it sends an -XGraphicsExposeEvent -structure with the type member set to -GraphicsExpose. -The display member is set to a pointer to the display the event was read on. -The send_event member is set to -True -if the event came from a -SendEvent -protocol request. -The serial member is set from the serial number reported in the protocol -but expanded from the 16-bit least-significant bits to a full 32-bit value. -The window member is set to the window that is most useful to toolkit -dispatchers. - - - -The X server can send events at any time in the input stream. -Xlib stores any events received while waiting for a reply in an event queue -for later use. -Xlib also provides functions that allow you to check events -in the event queue (see section 11.3). - - - -In addition to the individual structures declared for each event type, the -XEvent -structure is a union of the individual structures declared for each event type. -Depending on the type, -you should access members of each event by using the -XEvent -union. - - - -XEvent - - - - - -typedef union _XEvent { - int type; /* must not be changed */ - XAnyEvent xany; - XKeyEvent xkey; - XButtonEvent xbutton; - XMotionEvent xmotion; - XCrossingEvent xcrossing; - XFocusChangeEvent xfocus; - XExposeEvent xexpose; - XGraphicsExposeEvent xgraphicsexpose; - XNoExposeEvent xnoexpose; - XVisibilityEvent xvisibility; - XCreateWindowEvent xcreatewindow; - XDestroyWindowEvent xdestroywindow; - XUnmapEvent xunmap; - XMapEvent xmap; - XMapRequestEvent xmaprequest; - XReparentEvent xreparent; - XConfigureEvent xconfigure; - XGravityEvent xgravity; - XResizeRequestEvent xresizerequest; - XConfigureRequestEvent xconfigurerequest; - XCirculateEvent xcirculate; - XCirculateRequestEvent xcirculaterequest; - XPropertyEvent xproperty; - XSelectionClearEvent xselectionclear; - XSelectionRequestEvent xselectionrequest; - XSelectionEvent xselection; - XColormapEvent xcolormap; - XClientMessageEvent xclient; - XMappingEvent xmapping; - XErrorEvent xerror; - XKeymapEvent xkeymap; - long pad[24]; -} XEvent; - - - - - -An -XEvent -structure's first entry always is the type member, -which is set to the event type. -The second member always is the serial number of the protocol request -that generated the event. -The third member always is send_event, -which is a -Bool -that indicates if the event was sent by a different client. -The fourth member always is a display, -which is the display that the event was read from. -Except for keymap events, -the fifth member always is a window, -which has been carefully selected to be useful to toolkit dispatchers. -To avoid breaking toolkits, -the order of these first five entries is not to change. -Most events also contain a time member, -which is the time at which an event occurred. -In addition, a pointer to the generic event must be cast before it -is used to access any other information in the structure. - - - -Event Masks - - - - - -Event mask -Clients select event reporting of most events relative to a window. -To do this, pass an event mask to an Xlib event-handling -function that takes an event_mask argument. -The bits of the event mask are defined in -<X11/X.h>. -X11/X.h -Files<X11/X.h> -Headers<X11/X.h> -Each bit in the event mask maps to an event mask name, -which describes the event or events you want the X server to -return to a client application. - - - -Unless the client has specifically asked for them, -most events are not reported to clients when they are generated. -Unless the client suppresses them by setting graphics-exposures in the GC to -False, -GraphicsExpose -and -NoExpose -are reported by default as a result of -XCopyPlane -and -XCopyArea. -SelectionClear, -SelectionRequest, -SelectionNotify, -or -ClientMessage -cannot be masked. -Selection-related events are only sent to clients cooperating -with selections (see section 4.5). -When the keyboard or pointer mapping is changed, -MappingNotify -is always sent to clients. - - - - -The following table -lists the event mask constants you can pass to -the event_mask argument and -the circumstances in which you would want to specify the -event mask: - - - - - - - - - - - Event Mask - Circumstances - - - - - NoEventMask - No events wanted - - - KeyPressMask - Keyboard down events wanted - - - KeyReleaseMask - Keyboard up events wanted - - - ButtonPressMask - Pointer button down events wanted - - - ButtonReleaseMask - Pointer button up events wanted - - - EnterWindowMask - Pointer window entry events wanted - - - LeaveWindowMask - Pointer window leave events wanted - - - PointerMotionMask - Pointer motion events wanted - - - PointerMotionHintMask - Pointer motion hints wanted - - - Button1MotionMask - Pointer motion while button 1 down - - - Button2MotionMask - Pointer motion while button 2 down - - - Button3MotionMask - Pointer motion while button 3 down - - - Button4MotionMask - Pointer motion while button 4 down - - - Button5MotionMask - Pointer motion while button 5 down - - - ButtonMotionMask - Pointer motion while any button down - - - KeymapStateMask - Keyboard state wanted at window entry and focus in - - - ExposureMask - Any exposure wanted - - - VisibilityChangeMask - Any change in visibility wanted - - - StructureNotifyMask - Any change in window structure wanted - - - ResizeRedirectMask - Redirect resize of this window - - - SubstructureNotifyMask - Substructure notification wanted - - - SubstructureRedirectMask - Redirect structure requests on children - - - FocusChangeMask - Any change in input focus wanted - - - PropertyChangeMask - Any change in property wanted - - - ColormapChangeMask - Any change in colormap wanted - - - OwnerGrabButtonMask - Automatic grabs should activate with owner_events set to True - - - - - - - - - - -Event Processing Overview - - - - - -The event reported to a client application during event processing -depends on which event masks you provide as the event-mask attribute -for a window. -For some event masks, there is a one-to-one correspondence between -the event mask constant and the event type constant. -For example, if you pass the event mask -ButtonPressMask, -the X server sends back only -ButtonPress -events. -CurrentTime -Most events contain a time member, -which is the time at which an event occurred. - - - -In other cases, one event mask constant can map to several event type constants. -For example, if you pass the event mask -SubstructureNotifyMask, -the X server can send back -CirculateNotify, -ConfigureNotify, -CreateNotify, -DestroyNotify, -GravityNotify, -MapNotify, -ReparentNotify, -or -UnmapNotify -events. - - - -In another case, -two event masks can map to one event type. -For example, -if you pass either -PointerMotionMask -or -ButtonMotionMask, -the X server sends back -a -MotionNotify -event. - - - -The following table -lists the event mask, -its associated event type or types, -and the structure name associated with the event type. -Some of these structures actually are typedefs to a generic structure -that is shared between two event types. -Note that N.A. appears in columns for which the information is not applicable. - - - - - - - - - - - - - Event Mask - Event Type - Structure - Generic Structure - - - - - ButtonMotionMask - MotionNotify - XPointerMovedEvent - XMotionEvent - - - Button1MotionMask - - - Button2MotionMask - - - Button3MotionMask - - - Button4MotionMask - - - Button5MotionMask - - - ButtonPressMask - ButtonPress - XButtonPressedEvent - XButtonEvent - - - ButtonReleaseMask - ButtonRelease - XButtonReleasedEvent - XButtonEvent - - - ColormapChangeMask - ColormapNotify - XColormapEvent - - - EnterWindowMask - EnterNotify - XEnterWindowEvent - XCrossingEvent - - - LeaveWindowMask - LeaveNotify - XLeaveWindowEvent - XCrossingEvent - - - ExposureMask - Expose - XExposeEvent - - - GCGraphicsExposures in GC - GraphicsExpose - XGraphicsExposeEvent - - - - NoExpose - XNoExposeEvent - - - FocusChangeMask - FocusIn - XFocusInEvent - XFocusChangeEvent - - - - FocusOut - XFocusOutEvent - XFocusChangeEvent - - - KeymapStateMask - KeymapNotify - XKeymapEvent - - - KeyPressMask - KeyPress - XKeyPressedEvent - XKeyEvent - - - KeyReleaseMask - KeyRelease - XKeyReleasedEvent - XKeyEvent - - - OwnerGrabButtonMask - N.A. - N.A. - - - PointerMotionMask - MotionNotify - XPointerMovedEvent - XMotionEvent - - - PointerMotionHintMask - N.A. - N.A. - - - PropertyChangeMask - PropertyNotify - XPropertyEvent - - - ResizeRedirectMask - ResizeRequest - XResizeRequestEvent - - - StructureNotifyMask - CirculateNotify - XCirculateEvent - - - - ConfigureNotify - XConfigureEvent - - - - DestroyNotify - XDestroyWindowEvent - - - - GravityNotify - XGravityEvent - - - - MapNotify - XMapEvent - - - - ReparentNotify - XReparentEvent - - - - UnmapNotify - XUnmapEvent - - - SubstructureNotifyMask - CirculateNotify - XCirculateEvent - - - - ConfigureNotify - XConfigureEvent - - - - CreateNotify - XCreateWindowEvent - - - - DestroyNotify - XDestroyWindowEvent - - - - GravityNotify - XGravityEvent - - - - MapNotify - XMapEvent - - - - ReparentNotify - XReparentEvent - - - - UnmapNotify - XUnmapEvent - - - SubstructureRedirectMask - CirculateRequest - XCirculateRequestEvent - - - - ConfigureRequest - XConfigureRequestEvent - - - - MapRequest - XMapRequestEvent - - - N.A. - ClientMessage - XClientMessageEvent - - - N.A. - MappingNotify - XMappingEvent - - - N.A. - SelectionClear - XSelectionClearEvent - - - N.A. - SelectionNotify - XSelectionEvent - - - N.A. - SelectionRequest - XSelectionRequestEvent - - - VisibilityChangeMask - VisibilityNotify - XVisibilityEvent - - - _ - - - - - - - -The sections that follow describe the processing that occurs -when you select the different event masks. -The sections are organized according to these processing categories: - - - - -Keyboard and pointer events - - - - -Window crossing events - - - - -Input focus events - - - - -Keymap state notification events - - - - -Exposure events - - - - -Window state notification events - - - - -Structure control events - - - - -Colormap state notification events - - - - -Client communication events - - - - - - - -Keyboard and Pointer Events - - - - - -This section discusses: - - - - -Pointer button events - - - - -Keyboard and pointer events - - - - -Pointer Button Events - - - - - -The following describes the event processing that occurs when a pointer button -press is processed with the pointer in some window w and -when no active pointer grab is in progress. - - - -The X server searches the ancestors of w from the root down, -looking for a passive grab to activate. -If no matching passive grab on the button exists, -the X server automatically starts an active grab for the client receiving -the event and sets the last-pointer-grab time to the current server time. -The effect is essentially equivalent to an -XGrabButton -with these client passed arguments: - - - - - - - - Argument - Value - - - - - w - The event window - - - event_mask - The client's selected pointer events on the event window - - - pointer_mode - GrabModeAsync - - - keyboard_mode - GrabModeAsync - - - owner_events - True, - if the client has selected - OwnerGrabButtonMask - on the event window, - otherwise - False - - - confine_to - None - - - cursor - None - - - - - - - -The active grab is automatically terminated when -the logical state of the pointer has all buttons released. -Clients can modify the active grab by calling -XUngrabPointer -and -XChangeActivePointerGrab. - - - - -Keyboard and Pointer Events - - - - - -EventsButtonPress -EventsButtonRelease -EventsKeyPress -EventsKeyRelease -EventsMotionNotify -This section discusses the processing that occurs for the -keyboard events -KeyPress -and -KeyRelease -and the pointer events -ButtonPress, -ButtonRelease, -and -MotionNotify. -For information about the keyboard event-handling utilities, -see chapter 11. - - - -KeyPress -KeyRelease -The X server reports -KeyPress -or -KeyRelease -events to clients wanting information about keys that logically change state. -Note that these events are generated for all keys, -even those mapped to modifier bits. -ButtonPress -ButtonRelease -The X server reports -ButtonPress -or -ButtonRelease -events to clients wanting information about buttons that logically change state. - - - -MotionNotify -The X server reports -MotionNotify -events to clients wanting information about when the pointer logically moves. -The X server generates this event whenever the pointer is moved -and the pointer motion begins and ends in the window. -The granularity of -MotionNotify -events is not guaranteed, -but a client that selects this event type is guaranteed -to receive at least one event when the pointer moves and then rests. - - - -The generation of the logical changes lags the physical changes -if device event processing is frozen. - - - -To receive -KeyPress, -KeyRelease, -ButtonPress, -and -ButtonRelease -events, set -KeyPressMask, -KeyReleaseMask, -ButtonPressMask, -and -ButtonReleaseMask -bits in the event-mask attribute of the window. - - - -To receive -MotionNotify -events, set one or more of the following event -masks bits in the event-mask attribute of the window. - - - - -Button1MotionMask - Button5MotionMask - - - - -The client application receives -MotionNotify -events only when one or more of the specified buttons is pressed. - - - - -ButtonMotionMask - - - - -The client application receives -MotionNotify -events only when at least one button is pressed. - - - - -PointerMotionMask - - - - -The client application receives -MotionNotify -events independent of the state of -the pointer buttons. - - - - -PointerMotionHintMask - - - - -If -PointerMotionHintMask -is selected in combination with one or more of the above masks, -the X server is free to send only one -MotionNotify -event (with the is_hint member of the -XPointerMovedEvent -structure set to -NotifyHint) -to the client for the event window, -until either the key or button state changes, -the pointer leaves the event window, or the client calls -XQueryPointer -or -XGetMotionEvents. -The server still may send -MotionNotify -events without is_hint set to -NotifyHint. - - - - - -The source of the event is the viewable window that the pointer is in. -The window used by the X server to report these events depends on -the window's position in the window hierarchy -and whether any intervening window prohibits the generation of these events. -Starting with the source window, -the X server searches up the window hierarchy until it locates the first -window specified by a client as having an interest in these events. -If one of the intervening windows has its do-not-propagate-mask -set to prohibit generation of the event type, -the events of those types will be suppressed. -Clients can modify the actual window used for reporting by performing -active grabs and, in the case of keyboard events, by using the focus window. - - - -The structures for these event types contain: - - -typedef struct { - int type; /* ButtonPress or ButtonRelease */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* ``event'' window it is reported relative to */ - Window root; /* root window that the event occurred on */ - Window subwindow; /* child window */ - Time time; /* milliseconds */ - int x, y; /* pointer x, y coordinates in event window */ - int x_root, y_root; /* coordinates relative to root */ - unsigned int state; /* key or button mask */ - unsigned int button; /* detail */ - Bool same_screen; /* same screen flag */ -} XButtonEvent; -typedef XButtonEvent XButtonPressedEvent; -typedef XButtonEvent XButtonReleasedEvent; - - - -typedef struct { - int type; /* KeyPress or KeyRelease */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* ``event'' window it is reported relative to */ - Window root; /* root window that the event occurred on */ - Window subwindow; /* child window */ - Time time; /* milliseconds */ - int x, y; /* pointer x, y coordinates in event window */ - int x_root, y_root; /* coordinates relative to root */ - unsigned int state; /* key or button mask */ - unsigned int keycode; /* detail */ - Bool same_screen; /* same screen flag */ -} XKeyEvent; -typedef XKeyEvent XKeyPressedEvent; -typedef XKeyEvent XKeyReleasedEvent; - - - -typedef struct { - int type; /* MotionNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* ``event'' window reported relative to */ - Window root; /* root window that the event occurred on */ - Window subwindow; /* child window */ - Time time; /* milliseconds */ - int x, y; /* pointer x, y coordinates in event window */ - int x_root, y_root; /* coordinates relative to root */ - unsigned int state; /* key or button mask */ - char is_hint; /* detail */ - Bool same_screen; /* same screen flag */ -} XMotionEvent; -typedef XMotionEvent XPointerMovedEvent; - - - -These structures have the following common members: -window, root, subwindow, time, x, y, x_root, y_root, state, and same_screen. -The window member is set to the window on which the -event was generated and is referred to as the event window. -As long as the conditions previously discussed are met, -this is the window used by the X server to report the event. -The root member is set to the source window's root window. -The x_root and y_root members are set to the pointer's coordinates -relative to the root window's origin at the time of the event. - - - - -The same_screen member is set to indicate whether the event -window is on the same screen -as the root window and can be either -True -or -False. -If -True, -the event and root windows are on the same screen. -If -False, -the event and root windows are not on the same screen. - - - -If the source window is an inferior of the event window, -the subwindow member of the structure is set to the child of the event window -that is the source window or the child of the event window that is -an ancestor of the source window. -Otherwise, the X server sets the subwindow member to -None. -The time member is set to the time when the event was generated -and is expressed in milliseconds. - - - -If the event window is on the same screen as the root window, -the x and y members -are set to the coordinates relative to the event window's origin. -Otherwise, these members are set to zero. - - - -The state member is set to indicate the logical state of the pointer buttons -and modifier keys just prior to the event, -which is the bitwise inclusive OR of one or more of the -button or modifier key masks: -Button1Mask, -Button2Mask, -Button3Mask, -Button4Mask, -Button5Mask, -ShiftMask, -LockMask, -ControlMask, -Mod1Mask, -Mod2Mask, -Mod3Mask, -Mod4Mask, -and -Mod5Mask. - - - -Each of these structures also has a member that indicates the detail. -For the -XKeyPressedEvent -and -XKeyReleasedEvent -structures, this member is called a keycode. -It is set to a number that represents a physical key on the keyboard. -The keycode is an arbitrary representation for any key on the keyboard -(see sections 12.7 and 16.1). - - - -For the -XButtonPressedEvent -and -XButtonReleasedEvent -structures, this member is called button. -It represents the pointer button that changed state and can be the -Button1, -Button2, -Button3, -Button4, -or -Button5 -value. -For the -XPointerMovedEvent -structure, this member is called is_hint. -It can be set to -NotifyNormal -or -NotifyHint. - - - -Some of the symbols mentioned in this section have fixed values, as -follows: - - - - - - - - Symbol - Value - - - - - Button1MotionMask - (1L<<8) - - - Button2MotionMask - (1L<<9) - - - Button3MotionMask - (1L<<10) - - - Button4MotionMask - (1L<<11) - - - Button5MotionMask - (1L<<12) - - - Button1Mask - (1<<8) - - - Button2Mask - (1<<9) - - - Button3Mask - (1<<10) - - - Button4Mask - (1<<11) - - - Button5Mask - (1<<12) - - - ShiftMask - (1<<0) - - - LockMask - (1<<1) - - - ControlMask - (1<<2) - - - Mod1Mask - (1<<3) - - - Mod2Mask - (1<<4) - - - Mod3Mask - (1<<5) - - - Mod4Mask - (1<<6) - - - Mod5Mask - (1<<7) - - - Button1 - 1 - - - Button2 - 2 - - - Button3 - 3 - - - Button4 - 4 - - - Button5 - 5 - - - - - - - - -Window Entry/Exit Events - - - - - -EventsEnterNotify -EventsLeaveNotify -This section describes the processing that -occurs for the window crossing events -EnterNotify -and -LeaveNotify. -EnterNotify -LeaveNotify -If a pointer motion or a window hierarchy change causes the -pointer to be in a different window than before, the X server reports -EnterNotify -or -LeaveNotify -events to clients who have selected for these events. -All -EnterNotify -and -LeaveNotify -events caused by a hierarchy change are -generated after any hierarchy event -(UnmapNotify, -MapNotify, -ConfigureNotify, -GravityNotify, -CirculateNotify) -caused by that change; -however, the X protocol does not constrain the ordering of -EnterNotify -and -LeaveNotify -events with respect to -FocusOut, -VisibilityNotify, -and -Expose -events. - - - -This contrasts with -MotionNotify -events, which are also generated when the pointer moves -but only when the pointer motion begins and ends in a single window. -An -EnterNotify -or -LeaveNotify -event also can be generated when some client application calls -XGrabPointer -and -XUngrabPointer. - - - -To receive -EnterNotify -or -LeaveNotify -events, set the -EnterWindowMask -or -LeaveWindowMask -bits of the event-mask attribute of the window. - - - -The structure for these event types contains: - - -XCrossingEvent -XEnterWindowEvent -XLeaveWindowEvent - - - - -typedef struct { - int type; /* EnterNotify or LeaveNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* ``event'' window reported relative to */ - Window root; /* root window that the event occurred on */ - Window subwindow; /* child window */ - Time time; /* milliseconds */ - int x, y; /* pointer x, y coordinates in event window */ - int x_root, y_root; /* coordinates relative to root */ - int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ - int detail; - /* - * NotifyAncestor, NotifyVirtual, NotifyInferior, - * NotifyNonlinear,NotifyNonlinearVirtual - */ - Bool same_screen; /* same screen flag */ - Bool focus; /* boolean focus */ - unsigned int state; /* key or button mask */ -} XCrossingEvent; -typedef XCrossingEvent XEnterWindowEvent; -typedef XCrossingEvent XLeaveWindowEvent; - - - - - -The window member is set to the window on which the -EnterNotify -or -LeaveNotify -event was generated and is referred to as the event window. -This is the window used by the X server to report the event, -and is relative to the root -window on which the event occurred. -The root member is set to the root window of the screen -on which the event occurred. - - - -For a -LeaveNotify -event, -if a child of the event window contains the initial position of the pointer, -the subwindow component is set to that child. -Otherwise, the X server sets the subwindow member to -None. -For an -EnterNotify -event, if a child of the event window contains the final pointer position, -the subwindow component is set to that child or -None. - - - -The time member is set to the time when the event was generated -and is expressed in milliseconds. -The x and y members are set to the coordinates of the pointer position in -the event window. -This position is always the pointer's final position, -not its initial position. -If the event window is on the same -screen as the root window, x and y are the pointer coordinates -relative to the event window's origin. -Otherwise, x and y are set to zero. -The x_root and y_root members are set to the pointer's coordinates relative to the -root window's origin at the time of the event. - - - -The same_screen member is set to indicate whether the event window is on the same screen -as the root window and can be either -True -or -False. -If -True, -the event and root windows are on the same screen. -If -False, -the event and root windows are not on the same screen. - - - -The focus member is set to indicate whether the event window is the focus window or an -inferior of the focus window. -The X server can set this member to either -True -or -False. -If -True, -the event window is the focus window or an inferior of the focus window. -If -False, -the event window is not the focus window or an inferior of the focus window. - - - -The state member is set to indicate the state of the pointer buttons and -modifier keys just prior to the -event. -The X server can set this member to the bitwise inclusive OR of one -or more of the button or modifier key masks: -Button1Mask, -Button2Mask, -Button3Mask, -Button4Mask, -Button5Mask, -ShiftMask, -LockMask, -ControlMask, -Mod1Mask, -Mod2Mask, -Mod3Mask, -Mod4Mask, -Mod5Mask. - - - -The mode member is set to indicate whether the events are normal events, -pseudo-motion events -when a grab activates, or pseudo-motion events when a grab deactivates. -The X server can set this member to -NotifyNormal, -NotifyGrab, -or -NotifyUngrab. - - - -The detail member is set to indicate the notify detail and can be -NotifyAncestor, -NotifyVirtual, -NotifyInferior, -NotifyNonlinear, -or -NotifyNonlinearVirtual. - - -Normal Entry/Exit Events - - - - - -EnterNotify -and -LeaveNotify -events are generated when the pointer moves from -one window to another window. -Normal events are identified by -XEnterWindowEvent -or -XLeaveWindowEvent -structures whose mode member is set to -NotifyNormal. - - - - -When the pointer moves from window A to window B and A is an inferior of B, -the X server does the following: - - - - - -It generates a -LeaveNotify -event on window A, with the detail member of the -XLeaveWindowEvent -structure set to -NotifyAncestor. - - - - -It generates a -LeaveNotify -event on each window between window A and window B, exclusive, -with the detail member of each -XLeaveWindowEvent -structure set to -NotifyVirtual. - - - - -It generates an -EnterNotify -event on window B, with the detail member of the -XEnterWindowEvent -structure set to -NotifyInferior. - - - - - -When the pointer moves from window A to window B and B is an inferior of A, -the X server does the following: - - - - - -It generates a -LeaveNotify -event on window A, -with the detail member of the -XLeaveWindowEvent -structure set to -NotifyInferior. - - - - -It generates an -EnterNotify -event on each window between window A and window B, exclusive, with the -detail member of each -XEnterWindowEvent -structure set to -NotifyVirtual. - - - - -It generates an -EnterNotify -event on window B, with the detail member of the -XEnterWindowEvent -structure set to -NotifyAncestor. - - - - - -When the pointer moves from window A to window B -and window C is their least common ancestor, -the X server does the following: - - - - - -It generates a -LeaveNotify -event on window A, -with the detail member of the -XLeaveWindowEvent -structure set to -NotifyNonlinear. - - - - -It generates a -LeaveNotify -event on each window between window A and window C, exclusive, -with the detail member of each -XLeaveWindowEvent -structure set to -NotifyNonlinearVirtual. - - - - -It generates an -EnterNotify -event on each window between window C and window B, exclusive, -with the detail member of each -XEnterWindowEvent -structure set to -NotifyNonlinearVirtual. - - - - -It generates an -EnterNotify -event on window B, with the detail member of the -XEnterWindowEvent -structure set to -NotifyNonlinear. - - - - - -When the pointer moves from window A to window B on different screens, -the X server does the following: - - - - - -It generates a -LeaveNotify -event on window A, -with the detail member of the -XLeaveWindowEvent -structure set to -NotifyNonlinear. - - - - -If window A is not a root window, -it generates a -LeaveNotify -event on each window above window A up to and including its root, -with the detail member of each -XLeaveWindowEvent -structure set to -NotifyNonlinearVirtual. - - - - -If window B is not a root window, -it generates an -EnterNotify -event on each window from window B's root down to but not including -window B, with the detail member of each -XEnterWindowEvent -structure set to -NotifyNonlinearVirtual. - - - - -It generates an -EnterNotify -event on window B, with the detail member of the -XEnterWindowEvent -structure set to -NotifyNonlinear. - - - - - - - -Grab and Ungrab Entry/Exit Events - - - - - -Pseudo-motion mode -EnterNotify -and -LeaveNotify -events are generated when a pointer grab activates or deactivates. -Events in which the pointer grab activates -are identified by -XEnterWindowEvent -or -XLeaveWindowEvent -structures whose mode member is set to -NotifyGrab. -Events in which the pointer grab deactivates -are identified by -XEnterWindowEvent -or -XLeaveWindowEvent -structures whose mode member is set to -NotifyUngrab -(see -XGrabPointer). - - - - -When a pointer grab activates after any initial warp into a confine_to -window and before generating any actual -ButtonPress -event that activates the grab, -G is the grab_window for the grab, -and P is the window the pointer is in, -the X server does the following: - - - - - -It generates -EnterNotify -and -LeaveNotify -events (see section 10.6.1) -with the mode members of the -XEnterWindowEvent -and -XLeaveWindowEvent -structures set to -NotifyGrab. -These events are generated -as if the pointer were to suddenly warp from -its current position in P to some position in G. -However, the pointer does not warp, and the X server uses the pointer position -as both the initial and final positions for the events. - - - - - -When a pointer grab deactivates after generating any actual -ButtonRelease -event that deactivates the grab, -G is the grab_window for the grab, -and P is the window the pointer is in, -the X server does the following: - - - - - -It generates -EnterNotify -and -LeaveNotify -events (see section 10.6.1) -with the mode members of the -XEnterWindowEvent -and -XLeaveWindowEvent -structures set to -NotifyUngrab. -These events are generated as if the pointer were to suddenly warp from -some position in G to its current position in P. -However, the pointer does not warp, and the X server uses the -current pointer position as both the -initial and final positions for the events. - - - - - - - -Input Focus Events - - - - - -EventsFocusIn -EventsFocusOut -This section describes the processing that occurs for the input focus events -FocusIn -and -FocusOut. -FocusIn -FocusOut -The X server can report -FocusIn -or -FocusOut -events to clients wanting information about when the input focus changes. -The keyboard is always attached to some window -(typically, the root window or a top-level window), -which is called the focus window. -The focus window and the position of the pointer determine the window that -receives keyboard input. -Clients may need to know when the input focus changes -to control highlighting of areas on the screen. - - - -To receive -FocusIn -or -FocusOut -events, set the -FocusChangeMask -bit in the event-mask attribute of the window. - - - -The structure for these event types contains: - - -XFocusChangeEvent -XFocusInEvent -XFocusOutEvent - - - - -typedef struct { - int type; /* FocusIn or FocusOut */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* window of event */ - int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ - int detail; - /* - * NotifyAncestor, NotifyVirtual, NotifyInferior, - * NotifyNonlinear,NotifyNonlinearVirtual, NotifyPointer, - * NotifyPointerRoot, NotifyDetailNone - */ -} XFocusChangeEvent; -typedef XFocusChangeEvent XFocusInEvent; -typedef XFocusChangeEvent XFocusOutEvent; - - - - -The window member is set to the window on which the -FocusIn -or -FocusOut -event was generated. -This is the window used by the X server to report the event. -The mode member is set to indicate whether the focus events -are normal focus events, -focus events while grabbed, -focus events -when a grab activates, or focus events when a grab deactivates. -The X server can set the mode member to -NotifyNormal, -NotifyWhileGrabbed, -NotifyGrab, -or -NotifyUngrab. - - - -All -FocusOut -events caused by a window unmap are generated after any -UnmapNotify -event; however, the X protocol does not constrain the ordering of -FocusOut -events with respect to -generated -EnterNotify, -LeaveNotify, -VisibilityNotify, -and -Expose -events. - - - -Depending on the event mode, -the detail member is set to indicate the notify detail and can be -NotifyAncestor, -NotifyVirtual, -NotifyInferior, -NotifyNonlinear, -NotifyNonlinearVirtual, -NotifyPointer, -NotifyPointerRoot, -or -NotifyDetailNone. - - -Normal Focus Events and Focus Events While Grabbed - - - - - -Normal focus events are identified by -XFocusInEvent -or -XFocusOutEvent -structures whose mode member is set to -NotifyNormal. -Focus events while grabbed are identified by -XFocusInEvent -or -XFocusOutEvent -structures whose mode member is set to -NotifyWhileGrabbed. -The X server processes normal focus and focus events while grabbed according to -the following: - - - - -When the focus moves from window A to window B, A is an inferior of B, -and the pointer is in window P, -the X server does the following: - - - - - -It generates a -FocusOut -event on window A, with the detail member of the -XFocusOutEvent -structure set to -NotifyAncestor. - - - - -It generates a -FocusOut -event on each window between window A and window B, exclusive, -with the detail member of each -XFocusOutEvent -structure set to -NotifyVirtual. - - - - -It generates a -FocusIn -event on window B, with the detail member of the -XFocusOutEvent -structure set to -NotifyInferior. - - - - -If window P is an inferior of window B -but window P is not window A or an inferior or ancestor of window A, -it generates a -FocusIn -event on each window below window B, down to and including window P, -with the detail member of each -XFocusInEvent -structure set to -NotifyPointer. - - - - - -When the focus moves from window A to window B, B is an inferior of A, -and the pointer is in window P, -the X server does the following: - - - - - -If window P is an inferior of window A -but P is not an inferior of window B or an ancestor of B, -it generates a -FocusOut -event on each window from window P up to but not including window A, -with the detail member of each -XFocusOutEvent -structure set to -NotifyPointer. - - - - -It generates a -FocusOut -event on window A, -with the detail member of the -XFocusOutEvent -structure set to -NotifyInferior. - - - - -It generates a -FocusIn -event on each window between window A and window B, exclusive, with the -detail member of each -XFocusInEvent -structure set to -NotifyVirtual. - - - - -It generates a -FocusIn -event on window B, with the detail member of the -XFocusInEvent -structure set to -NotifyAncestor. - - - - - -When the focus moves from window A to window B, -window C is their least common ancestor, -and the pointer is in window P, -the X server does the following: - - - - - -If window P is an inferior of window A, -it generates a -FocusOut -event on each window from window P up to but not including window A, -with the detail member of the -XFocusOutEvent -structure set to -NotifyPointer. - - - - -It generates a -FocusOut -event on window A, -with the detail member of the -XFocusOutEvent -structure set to -NotifyNonlinear. - - - - -It generates a -FocusOut -event on each window between window A and window C, exclusive, -with the detail member of each -XFocusOutEvent -structure set to -NotifyNonlinearVirtual. - - - - -It generates a -FocusIn -event on each window between C and B, exclusive, -with the detail member of each -XFocusInEvent -structure set to -NotifyNonlinearVirtual. - - - - -It generates a -FocusIn -event on window B, with the detail member of the -XFocusInEvent -structure set to -NotifyNonlinear. - - - - -If window P is an inferior of window B, it generates a -FocusIn -event on each window below window B down to and including window P, -with the detail member of the -XFocusInEvent -structure set to -NotifyPointer. - - - - - -When the focus moves from window A to window B on different screens -and the pointer is in window P, -the X server does the following: - - - - - -If window P is an inferior of window A, it generates a -FocusOut -event on each window from window P up to but not including window A, -with the detail member of each -XFocusOutEvent -structure set to -NotifyPointer. - - - - -It generates a -FocusOut -event on window A, -with the detail member of the -XFocusOutEvent -structure set to -NotifyNonlinear. - - - - -If window A is not a root window, -it generates a -FocusOut -event on each window above window A up to and including its root, -with the detail member of each -XFocusOutEvent -structure set to -NotifyNonlinearVirtual. - - - - -If window B is not a root window, -it generates a -FocusIn -event on each window from window B's root down to but not including -window B, with the detail member of each -XFocusInEvent -structure set to -NotifyNonlinearVirtual. - - - - -It generates a -FocusIn -event on window B, with the detail member of each -XFocusInEvent -structure set to -NotifyNonlinear. - - - - -If window P is an inferior of window B, it generates a -FocusIn -event on each window below window B down to and including window P, -with the detail member of each -XFocusInEvent -structure set to -NotifyPointer. - - - - - -When the focus moves from window A to -PointerRoot -(events sent to the window under the pointer) -or -None -(discard), and the pointer is in window P, -the X server does the following: - - - - - -If window P is an inferior of window A, it generates a -FocusOut -event on each window from window P up to but not including window A, -with the detail member of each -XFocusOutEvent -structure set to -NotifyPointer. - - - - -It generates a -FocusOut -event on window A, with the detail member of the -XFocusOutEvent -structure set to -NotifyNonlinear. - - - - -If window A is not a root window, -it generates a -FocusOut -event on each window above window A up to and including its root, -with the detail member of each -XFocusOutEvent -structure set to -NotifyNonlinearVirtual. - - - - -It generates a -FocusIn -event on the root window of all screens, with the detail member of each -XFocusInEvent -structure set to -NotifyPointerRoot -(or -NotifyDetailNone). - - - - -If the new focus is -PointerRoot, -it generates a -FocusIn -event on each window from window P's root down to and including window P, -with the detail member of each -XFocusInEvent -structure set to -NotifyPointer. - - - - - -When the focus moves from -PointerRoot -(events sent to the window under the pointer) -or -None -to window A, and the pointer is in window P, -the X server does the following: - - - - - -If the old focus is -PointerRoot, -it generates a -FocusOut -event on each window from window P up to and including window P's root, -with the detail member of each -XFocusOutEvent -structure set to -NotifyPointer. - - - - -It generates a -FocusOut -event on all root windows, -with the detail member of each -XFocusOutEvent -structure set to -NotifyPointerRoot -(or -NotifyDetailNone). - - - - -If window A is not a root window, -it generates a -FocusIn -event on each window from window A's root down to but not including window A, -with the detail member of each -XFocusInEvent -structure set to -NotifyNonlinearVirtual. - - - - -It generates a -FocusIn -event on window A, -with the detail member of the -XFocusInEvent -structure set to -NotifyNonlinear. - - - - -If window P is an inferior of window A, it generates a -FocusIn -event on each window below window A down to and including window P, -with the detail member of each -XFocusInEvent -structure set to -NotifyPointer. - - - - - -When the focus moves from -PointerRoot -(events sent to the window under the pointer) -to -None -(or vice versa), and the pointer is in window P, -the X server does the following: - - - - - -If the old focus is -PointerRoot, -it generates a -FocusOut -event on each window from window P up to and including window P's root, -with the detail member of each -XFocusOutEvent -structure set to -NotifyPointer. - - - - -It generates a -FocusOut -event on all root windows, -with the detail member of each -XFocusOutEvent -structure set to either -NotifyPointerRoot -or -NotifyDetailNone. - - - - -It generates a -FocusIn -event on all root windows, -with the detail member of each -XFocusInEvent -structure set to -NotifyDetailNone -or -NotifyPointerRoot. - - - - -If the new focus is -PointerRoot, -it generates a -FocusIn -event on each window from window P's root down to and including window P, -with the detail member of each -XFocusInEvent -structure set to -NotifyPointer. - - - - - - - -Focus Events Generated by Grabs - - - - - -Focus events in which the keyboard grab activates -are identified by -XFocusInEvent -or -XFocusOutEvent -structures whose mode member is set to -NotifyGrab. -Focus events in which the keyboard grab deactivates -are identified by -XFocusInEvent -or -XFocusOutEvent -structures whose mode member is set to -NotifyUngrab -(see -XGrabKeyboard). - - - - -When a keyboard grab activates before generating any actual -KeyPress -event that activates the grab, -G is the grab_window, and F is the current focus, -the X server does the following: - - - - - -It generates -FocusIn -and -FocusOut -events, with the mode members of the -XFocusInEvent -and -XFocusOutEvent -structures set to -NotifyGrab. -These events are generated -as if the focus were to change from -F to G. - - - - - -When a keyboard grab deactivates after generating any actual -KeyRelease -event that deactivates the grab, -G is the grab_window, and F is the current focus, -the X server does the following: - - - - - -It generates -FocusIn -and -FocusOut -events, with the mode members of the -XFocusInEvent -and -XFocusOutEvent -structures set to -NotifyUngrab. -These events are generated -as if the focus were to change from -G to F. - - - - - - - -Key Map State Notification Events - - - - - -EventsKeymapNotify -KeymapNotify -The X server can report -KeymapNotify -events to clients that want information about changes in their keyboard state. - - - -To receive -KeymapNotify -events, set the -KeymapStateMask -bit in the event-mask attribute of the window. -The X server generates this event immediately after every -EnterNotify -and -FocusIn -event. - - - -The structure for this event type contains: - - - -XKeymapEvent - - - - -/* generated on EnterWindow and FocusIn when KeymapState selected */ -typedef struct { - int type; /* KeymapNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - char key_vector[32]; -} XKeymapEvent; - - - - - -The window member is not used but is present to aid some toolkits. -The key_vector member is set to the bit vector of the keyboard. -Each bit set to 1 indicates that the corresponding key -is currently pressed. -The vector is represented as 32 bytes. -Byte N (from 0) contains the bits for keys 8N to 8N + 7 -with the least significant bit in the byte representing key 8N. - - - -Exposure Events - - - - - -The X protocol does not guarantee to preserve the contents of window -regions when -the windows are obscured or reconfigured. -Some implementations may preserve the contents of windows. -Other implementations are free to destroy the contents of windows -when exposed. -X expects client applications to assume the responsibility for -restoring the contents of an exposed window region. -(An exposed window region describes a formerly obscured window whose -region becomes visible.) -Therefore, the X server sends -Expose -events describing the window and the region of the window that has been exposed. -A naive client application usually redraws the entire window. -A more sophisticated client application redraws only the exposed region. - - -Expose Events - - - - - -EventsExpose -Expose -The X server can report -Expose -events to clients wanting information about when the contents of window regions -have been lost. -The circumstances in which the X server generates -Expose -events are not as definite as those for other events. -However, the X server never generates -Expose -events on windows whose class you specified as -InputOnly. -The X server can generate -Expose -events when no valid contents are available for regions of a window -and either the regions are visible, -the regions are viewable and the server is (perhaps newly) maintaining -backing store on the window, -or the window is not viewable but the server is (perhaps newly) honoring the -window's backing-store attribute of -Always -or -WhenMapped. -The regions decompose into an (arbitrary) set of rectangles, -and an -Expose -event is generated for each rectangle. -For any given window, -the X server guarantees to report contiguously -all of the regions exposed by some action that causes -Expose -events, such as raising a window. - - - -To receive -Expose -events, set the -ExposureMask -bit in the event-mask attribute of the window. - - - -The structure for this event type contains: - - - -XExposeEvent - - - - -typedef struct { - int type; /* Expose */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - int x, y; - int width, height; - int count; /* if nonzero, at least this many more */ -} XExposeEvent; - - - - - -The window member is set to the exposed (damaged) window. -The x and y members are set to the coordinates relative to the window's origin -and indicate the upper-left corner of the rectangle. -The width and height members are set to the size (extent) of the rectangle. -The count member is set to the number of -Expose -events that are to follow. -If count is zero, no more -Expose -events follow for this window. -However, if count is nonzero, at least that number of -Expose -events (and possibly more) follow for this window. -Simple applications that do not want to optimize redisplay by distinguishing -between subareas of its window can just ignore all -Expose -events with nonzero counts and perform full redisplays -on events with zero counts. - - - -GraphicsExpose and NoExpose Events - - - - - -EventsGraphicsExpose -EventsNoExpose -GraphicsExpose -The X server can report -GraphicsExpose -events to clients wanting information about when a destination region could not -be computed during certain graphics requests: -XCopyArea -or -XCopyPlane. -The X server generates this event whenever a destination region could not be -computed because of an obscured or out-of-bounds source region. -In addition, the X server guarantees to report contiguously all of the regions exposed by -some graphics request -(for example, copying an area of a drawable to a destination -drawable). - - - -NoExpose -The X server generates a -NoExpose -event whenever a graphics request that might -produce a -GraphicsExpose -event does not produce any. -In other words, the client is really asking for a -GraphicsExpose -event but instead receives a -NoExpose -event. - - - -To receive -GraphicsExpose -or -NoExpose -events, you must first set the graphics-exposure -attribute of the graphics context to -True. -You also can set the graphics-expose attribute when creating a graphics -context using -XCreateGC -or by calling -XSetGraphicsExposures. - - - -The structures for these event types contain: - - - -XGraphicsExposeEvent - - - - -typedef struct { - int type; /* GraphicsExpose */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Drawable drawable; - int x, y; - int width, height; - int count; /* if nonzero, at least this many more */ - int major_code; /* core is CopyArea or CopyPlane */ - int minor_code; /* not defined in the core */ -} XGraphicsExposeEvent; - - - - -XNoExposeEvent - - - -typedef struct { - int type; /* NoExpose */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Drawable drawable; - int major_code; /* core is CopyArea or CopyPlane */ - int minor_code; /* not defined in the core */ -} XNoExposeEvent; - - - - - -Both structures have these common members: drawable, major_code, and minor_code. -The drawable member is set to the drawable of the destination region on -which the graphics request was to be performed. -The major_code member is set to the graphics request initiated by the client -and can be either -X_CopyArea -or -X_CopyPlane. -If it is -X_CopyArea, -a call to -XCopyArea -initiated the request. -If it is -X_CopyPlane, -a call to -XCopyPlane -initiated the request. -These constants are defined in -<X11/Xproto.h>. -X11/Xproto.h -Files<X11/Xproto.h> -Headers<X11/Xproto.h> -The minor_code member, -like the major_code member, -indicates which graphics request was initiated by -the client. -However, the minor_code member is not defined by the core -X protocol and will be zero in these cases, -although it may be used by an extension. - - - -The -XGraphicsExposeEvent -structure has these additional members: x, y, width, height, and count. -The x and y members are set to the coordinates relative to the drawable's origin -and indicate the upper-left corner of the rectangle. -The width and height members are set to the size (extent) of the rectangle. -The count member is set to the number of -GraphicsExpose -events to follow. -If count is zero, no more -GraphicsExpose -events follow for this window. -However, if count is nonzero, at least that number of -GraphicsExpose -events (and possibly more) are to follow for this window. - - - - -Window State Change Events - - - - - -The following sections discuss: - - - - -CirculateNotify -events - - - - -ConfigureNotify -events - - - - -CreateNotify -events - - - - -DestroyNotify -events - - - - -GravityNotify -events - - - - -MapNotify -events - - - - -MappingNotify -events - - - - -ReparentNotify -events - - - - -UnmapNotify -events - - - - -VisibilityNotify -events - - - - - -CirculateNotify Events - - - - - -EventsCirculateNotify -CirculateNotify -The X server can report -CirculateNotify -events to clients wanting information about when a window changes -its position in the stack. -The X server generates this event type whenever a window is actually restacked -as a result of a client application calling -XCirculateSubwindows, -XCirculateSubwindowsUp, -or -XCirculateSubwindowsDown. - - - -To receive -CirculateNotify -events, set the -StructureNotifyMask -bit in the event-mask attribute of the window -or the -SubstructureNotifyMask -bit in the event-mask attribute of the parent window -(in which case, circulating any child generates an event). - - - -The structure for this event type contains: - - - -XCirculateEvent - - - - -typedef struct { - int type; /* CirculateNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window event; - Window window; - int place; /* PlaceOnTop, PlaceOnBottom */ -} XCirculateEvent; - - - - - -The event member is set either to the restacked window or to its parent, -depending on whether -StructureNotify -or -SubstructureNotify -was selected. -The window member is set to the window that was restacked. -The place member is set to the window's position after the restack occurs and -is either -PlaceOnTop -or -PlaceOnBottom. -If it is -PlaceOnTop, -the window is now on top of all siblings. -If it is -PlaceOnBottom, -the window is now below all siblings. - - - -ConfigureNotify Events - - - - - -EventsConfigureNotify -ConfigureNotify -The X server can report -ConfigureNotify -events to clients wanting information about actual changes to a window's -state, such as size, position, border, and stacking order. -The X server generates this event type whenever one of the following configure -window requests made by a client application actually completes: - - - - -A window's size, position, border, and/or stacking order is reconfigured -by calling -XConfigureWindow. - - - - -The window's position in the stacking order is changed by calling -XLowerWindow, -XRaiseWindow, -or -XRestackWindows. - - - - -A window is moved by calling -XMoveWindow. - - - - -A window's size is changed by calling -XResizeWindow. - - - - -A window's size and location is changed by calling -XMoveResizeWindow. - - - - -A window is mapped and its position in the stacking order is changed -by calling -XMapRaised. - - - - -A window's border width is changed by calling -XSetWindowBorderWidth. - - - - - -To receive -ConfigureNotify -events, set the -StructureNotifyMask -bit in the event-mask attribute of the window or the -SubstructureNotifyMask -bit in the event-mask attribute of the parent window -(in which case, configuring any child generates an event). - - - -The structure for this event type contains: - - -XConfigureEvent - - - - -typedef struct { - int type; /* ConfigureNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window event; - Window window; - int x, y; - int width, height; - int border_width; - Window above; - Bool override_redirect; -} XConfigureEvent; - - - - -The event member is set either to the reconfigured window or to its parent, -depending on whether -StructureNotify -or -SubstructureNotify -was selected. -The window member is set to the window whose size, position, -border, and/or stacking -order was changed. - - - -The x and y members are set to the coordinates relative to the parent window's -origin and indicate the position of the upper-left outside corner of the window. -The width and height members are set to the inside size of the window, -not including -the border. -The border_width member is set to the width of the window's border, in pixels. - - - -The above member is set to the sibling window and is used -for stacking operations. -If the X server sets this member to -None, -the window whose state was changed is on the bottom of the stack -with respect to sibling windows. -However, if this member is set to a sibling window, -the window whose state was changed is placed on top of this sibling window. - - - -The override_redirect member is set to the override-redirect attribute of the -window. -Window manager clients normally should ignore this window if the -override_redirect member -is -True. - - - -CreateNotify Events - - - - - -EventsCreateNotify -CreateNotify -The X server can report -CreateNotify -events to clients wanting information about creation of windows. -The X server generates this event whenever a client -application creates a window by calling -XCreateWindow -or -XCreateSimpleWindow. - - - -To receive -CreateNotify -events, set the -SubstructureNotifyMask -bit in the event-mask attribute of the window. -Creating any children then generates an event. - - - -The structure for the event type contains: - - - -XCreateWindowEvent - - - - -typedef struct { - int type; /* CreateNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window parent; /* parent of the window */ - Window window; /* window id of window created */ - int x, y; /* window location */ - int width, height; /* size of window */ - int border_width; /* border width */ - Bool override_redirect; /* creation should be overridden */ -} XCreateWindowEvent; - - - - - -The parent member is set to the created window's parent. -The window member specifies the created window. -The x and y members are set to the created window's coordinates relative -to the parent window's origin and indicate the position of the upper-left -outside corner of the created window. -The width and height members are set to the inside size of the created window -(not including the border) and are always nonzero. -The border_width member is set to the width of the created window's border, in pixels. -The override_redirect member is set to the override-redirect attribute of the -window. -Window manager clients normally should ignore this window -if the override_redirect member is -True. - - - -DestroyNotify Events - - - - - -EventsDestroyNotify -DestroyNotify -The X server can report -DestroyNotify -events to clients wanting information about which windows are destroyed. -The X server generates this event whenever a client application destroys a -window by calling -XDestroyWindow -or -XDestroySubwindows. - - - -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 X protocol does not constrain the ordering among -siblings and across subhierarchies. - - - -To receive -DestroyNotify -events, set the -StructureNotifyMask -bit in the event-mask attribute of the window or the -SubstructureNotifyMask -bit in the event-mask attribute of the parent window -(in which case, destroying any child generates an event). - - - -The structure for this event type contains: - - - -XDestroyWindowEvent - - - - -typedef struct { - int type; /* DestroyNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window event; - Window window; -} XDestroyWindowEvent; - - - - - -The event member is set either to the destroyed window or to its parent, -depending on whether -StructureNotify -or -SubstructureNotify -was selected. -The window member is set to the window that is destroyed. - - - -GravityNotify Events - - - - - -EventsGravityNotify -GravityNotify -The X server can report -GravityNotify -events to clients wanting information about when a window is moved because of a -change in the size of its parent. -The X server generates this event whenever a client -application actually moves a child window as a result of resizing its parent by calling -XConfigureWindow, -XMoveResizeWindow, -or -XResizeWindow. - - - -To receive -GravityNotify -events, set the -StructureNotifyMask -bit in the event-mask attribute of the window or the -SubstructureNotifyMask -bit in the event-mask attribute of the parent window -(in which case, any child that is moved because its parent has been resized -generates an event). - - - -The structure for this event type contains: - - - -XGravityEvent - - - - -typedef struct { - int type; /* GravityNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window event; - Window window; - int x, y; -} XGravityEvent; - - - - - -The event member is set either to the window that was moved or to its parent, -depending on whether -StructureNotify -or -SubstructureNotify -was selected. -The window member is set to the child window that was moved. -The x and y members are set to the coordinates relative to the -new parent window's origin -and indicate the position of the upper-left outside corner of the -window. - - - -MapNotify Events - - - - - -EventsMapNotify -MapNotify -The X server can report -MapNotify -events to clients wanting information about which windows are mapped. -The X server generates this event type whenever a client application changes the -window's state from unmapped to mapped by calling -XMapWindow, -XMapRaised, -XMapSubwindows, -XReparentWindow, -or as a result of save-set processing. - - - -To receive -MapNotify -events, set the -StructureNotifyMask -bit in the event-mask attribute of the window or the -SubstructureNotifyMask -bit in the event-mask attribute of the parent window -(in which case, mapping any child generates an event). - - - -The structure for this event type contains: - - - -XMapEvent - - - - -typedef struct { - int type; /* MapNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window event; - Window window; - Bool override_redirect; /* boolean, is override set... */ -} XMapEvent; - - - - - -The event member is set either to the window that was mapped or to its parent, -depending on whether -StructureNotify -or -SubstructureNotify -was selected. -The window member is set to the window that was mapped. -The override_redirect member is set to the override-redirect attribute -of the window. -Window manager clients normally should ignore this window -if the override-redirect attribute is -True, -because these events usually are generated from pop-ups, -which override structure control. - - - -MappingNotify Events - - - - - -EventsMappingNotify -MappingNotify -The X server reports -MappingNotify -events to all clients. -There is no mechanism to express disinterest in this event. -The X server generates this event type whenever a client application -successfully calls: - - - - -XSetModifierMapping -to indicate which KeyCodes are to be used as modifiers - - - - -XChangeKeyboardMapping -to change the keyboard mapping - - - - -XSetPointerMapping -to set the pointer mapping - - - - - -The structure for this event type contains: - - - -XMappingEvent - - - - -typedef struct { - int type; /* MappingNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; /* unused */ - int request; /* one of MappingModifier, MappingKeyboard, - MappingPointer */ - int first_keycode; /* first keycode */ - int count; /* defines range of change w. first_keycode*/ -} XMappingEvent; - - - - - -The request member is set to indicate the kind of mapping change that occurred -and can be -MappingModifier, -MappingKeyboard, -or -MappingPointer. -If it is -MappingModifier, -the modifier mapping was changed. -If it is -MappingKeyboard, -the keyboard mapping was changed. -If it is -MappingPointer, -the pointer button mapping was changed. -The first_keycode and count members are set only -if the request member was set to -MappingKeyboard. -The number in first_keycode represents the first number in the range -of the altered mapping, -and count represents the number of keycodes altered. - - - -To update the client application's knowledge of the keyboard, -you should call -XRefreshKeyboardMapping. - - - -ReparentNotify Events - - - - - -EventsReparentNotify -ReparentNotify -The X server can report -ReparentNotify -events to clients wanting information about changing a window's parent. -The X server generates this event whenever a client -application calls -XReparentWindow -and the window is actually reparented. - - - -To receive -ReparentNotify -events, set the -StructureNotifyMask -bit in the event-mask attribute of the window or the -SubstructureNotifyMask -bit in the event-mask attribute of either the old or the new parent window -(in which case, reparenting any child generates an event). - - - -The structure for this event type contains: - - - -XReparentEvent - - - - -typedef struct { - int type; /* ReparentNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window event; - Window window; - Window parent; - int x, y; - Bool override_redirect; -} XReparentEvent; - - - - - -The event member is set either to the reparented window -or to the old or the new parent, depending on whether -StructureNotify -or -SubstructureNotify -was selected. -The window member is set to the window that was reparented. -The parent member is set to the new parent window. -The x and y members are set to the reparented window's coordinates relative -to the new parent window's -origin and define the upper-left outer corner of the reparented window. -The override_redirect member is set to the override-redirect attribute of the -window specified by the window member. -Window manager clients normally should ignore this window -if the override_redirect member is -True. - - - -UnmapNotify Events - - - - - -EventsUnmapNotify -UnmapNotify -The X server can report -UnmapNotify -events to clients wanting information about which windows are unmapped. -The X server generates this event type whenever a client application changes the -window's state from mapped to unmapped. - - - -To receive -UnmapNotify -events, set the -StructureNotifyMask -bit in the event-mask attribute of the window or the -SubstructureNotifyMask -bit in the event-mask attribute of the parent window -(in which case, unmapping any child window generates an event). - - - -The structure for this event type contains: - - - -XUnmapEvent - - - - -typedef struct { - int type; /* UnmapNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window event; - Window window; - Bool from_configure; -} XUnmapEvent; - - - - - -The event member is set either to the unmapped window or to its parent, -depending on whether -StructureNotify -or -SubstructureNotify -was selected. -This is the window used by the X server to report the event. -The window member is set to the window that was unmapped. -The from_configure member is set to -True -if the event was generated as a result of a resizing of the window's parent when -the window itself had a win_gravity of -UnmapGravity. - - - -VisibilityNotify Events - - - - - -EventsVisibilityNotify -VisibilityNotify -The X server can report -VisibilityNotify -events to clients wanting any change in the visibility of the specified window. -A region of a window is visible if someone looking at the screen can -actually see it. -The X server generates this event whenever the visibility changes state. -However, this event is never generated for windows whose class is -InputOnly. - - - -All -VisibilityNotify -events caused by a hierarchy change are generated -after any hierarchy event -(UnmapNotify, -MapNotify, -ConfigureNotify, -GravityNotify, -CirculateNotify) -caused by that change. 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 X protocol does not constrain the ordering of -VisibilityNotify -events with -respect to -FocusOut, -EnterNotify, -and -LeaveNotify -events. - - - -To receive -VisibilityNotify -events, set the -VisibilityChangeMask -bit in the event-mask attribute of the window. - - - -The structure for this event type contains: - - - -XVisibilityEvent - - - - -typedef struct { - int type; /* VisibilityNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - int state; -} XVisibilityEvent; - - - - - -The window member is set to the window whose visibility state changes. -The state member is set to the state of the window's visibility and can be -VisibilityUnobscured, -VisibilityPartiallyObscured, -or -VisibilityFullyObscured. -The X server ignores all of a window's subwindows -when determining the visibility state of the window and processes -VisibilityNotify -events according to the following: - - - - -When the window changes state from partially obscured, fully obscured, -or not viewable to viewable and completely unobscured, -the X server generates the event with the state member of the -XVisibilityEvent -structure set to -VisibilityUnobscured. - - - - -When the window changes state from viewable and completely unobscured or -not viewable to viewable and partially obscured, -the X server generates the event with the state member of the -XVisibilityEvent -structure set to -VisibilityPartiallyObscured. - - - - -When the window changes state from viewable and completely unobscured, -viewable and partially obscured, or not viewable to viewable and -fully obscured, -the X server generates the event with the state member of the -XVisibilityEvent -structure set to -VisibilityFullyObscured. - - - - - - -Structure Control Events - - - - - -This section discusses: - - - - -CirculateRequest -events - - - - -ConfigureRequest -events - - - - -MapRequest -events - - - - -ResizeRequest -events - - - - -CirculateRequest Events - - - - - -EventsCirculateRequest -CirculateRequest -The X server can report -CirculateRequest -events to clients wanting information about -when another client initiates a circulate window request -on a specified window. -The X server generates this event type whenever a client initiates a circulate -window request on a window and a subwindow actually needs to be restacked. -The client initiates a circulate window request on the window by calling -XCirculateSubwindows, -XCirculateSubwindowsUp, -or -XCirculateSubwindowsDown. - - - -To receive -CirculateRequest -events, set the -SubstructureRedirectMask -in the event-mask attribute of the window. -Then, in the future, -the circulate window request for the specified window is not executed, -and thus, any subwindow's position in the stack is not changed. -For example, suppose a client application calls -XCirculateSubwindowsUp -to raise a subwindow to the top of the stack. -If you had selected -SubstructureRedirectMask -on the window, the X server reports to you a -CirculateRequest -event and does not raise the subwindow to the top of the stack. - - - -The structure for this event type contains: - - - -XCirculateRequestEvent - - - - -typedef struct { - int type; /* CirculateRequest */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window parent; - Window window; - int place; /* PlaceOnTop, PlaceOnBottom */ -} XCirculateRequestEvent; - - - - - -The parent member is set to the parent window. -The window member is set to the subwindow to be restacked. -The place member is set to what the new position in the stacking order should be -and is either -PlaceOnTop -or -PlaceOnBottom. -If it is -PlaceOnTop, -the subwindow should be on top of all siblings. -If it is -PlaceOnBottom, -the subwindow should be below all siblings. - - - -ConfigureRequest Events - - - - - -EventsConfigureRequest -ConfigureRequest -The X server can report -ConfigureRequest -events to clients wanting information about when a different client initiates -a configure window request on any child of a specified window. -The configure window request attempts to -reconfigure a window's size, position, border, and stacking order. -The X server generates this event whenever a different client initiates -a configure window request on a window by calling -XConfigureWindow, -XLowerWindow, -XRaiseWindow, -XMapRaised, -XMoveResizeWindow, -XMoveWindow, -XResizeWindow, -XRestackWindows, -or -XSetWindowBorderWidth. - - - -To receive -ConfigureRequest -events, set the -SubstructureRedirectMask -bit in the event-mask attribute of the window. -ConfigureRequest -events are generated when a -ConfigureWindow -protocol request is issued on a child window by another client. -For example, suppose a client application calls -XLowerWindow -to lower a window. -If you had selected -SubstructureRedirectMask -on the parent window and if the override-redirect attribute -of the window is set to -False, -the X server reports a -ConfigureRequest -event to you and does not lower the specified window. - - - -The structure for this event type contains: - - - -XConfigureRequestEvent - - - - -typedef struct { - int type; /* ConfigureRequest */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window parent; - Window window; - int x, y; - int width, height; - int border_width; - Window above; - int detail; /* Above, Below, TopIf, BottomIf, Opposite */ - unsigned long value_mask; -} XConfigureRequestEvent; - - - - - -The parent member is set to the parent window. -The window member is set to the window whose size, position, border width, -and/or stacking order is to be reconfigured. -The value_mask member indicates which components were specified in the -ConfigureWindow -protocol request. -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 above (sibling) and detail (stack-mode), -which are reported as -None -and -Above, -respectively, if they are not given in the request. - - - -MapRequest Events - - - - - -EventsMapRequest -MapRequest -The X server can report -MapRequest -events to clients wanting information about a different client's desire -to map windows. -A window is considered mapped when a map window request completes. -The X server generates this event whenever a different client initiates -a map window request on an unmapped window whose override_redirect member -is set to -False. -Clients initiate map window requests by calling -XMapWindow, -XMapRaised, -or -XMapSubwindows. - - - -To receive -MapRequest -events, set the -SubstructureRedirectMask -bit in the event-mask attribute of the window. -This means another client's attempts to map a child window by calling one of -the map window request functions is intercepted, and you are sent a -MapRequest -instead. -For example, suppose a client application calls -XMapWindow -to map a window. -If you (usually a window manager) had selected -SubstructureRedirectMask -on the parent window and if the override-redirect attribute -of the window is set to -False, -the X server reports a -MapRequest -event to you -and does not map the specified window. -Thus, this event gives your window manager client the ability -to control the placement of subwindows. - - - -The structure for this event type contains: - - - -XMapRequestEvent - - - - -typedef struct { - int type; /* MapRequest */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window parent; - Window window; -} XMapRequestEvent; - - - - - -The parent member is set to the parent window. -The window member is set to the window to be mapped. - - - -ResizeRequest Events - - - - - -EventsResizeRequest -ResizeRequest -The X server can report -ResizeRequest -events to clients wanting information about another client's attempts to change the -size of a window. -The X server generates this event whenever some other client attempts to change -the size of the specified window by calling -XConfigureWindow, -XResizeWindow, -or -XMoveResizeWindow. - - - -To receive -ResizeRequest -events, set the -ResizeRedirect -bit in the event-mask attribute of the window. -Any attempts to change the size by other clients are then redirected. - - - -The structure for this event type contains: - - - -XResizeRequestEvent - - - - -typedef struct { - int type; /* ResizeRequest */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - int width, height; -} XResizeRequestEvent; - - - - - -The window member is set to the window whose size another -client attempted to change. -The width and height members are set to the inside size of the window, -excluding the border. - - - - -Colormap State Change Events - - - - - -EventsColormapNotify -ColormapNotify -The X server can report -ColormapNotify -events to clients wanting information about when the colormap changes -and when a colormap is installed or uninstalled. -The X server generates this event type whenever a client application: - - - - -Changes the colormap member of the -XSetWindowAttributes -structure by -calling -XChangeWindowAttributes, -XFreeColormap, -or -XSetWindowColormap - - - - -Installs or uninstalls the colormap by calling -XInstallColormap -or -XUninstallColormap - - - - - -To receive -ColormapNotify -events, set the -ColormapChangeMask -bit in the event-mask attribute of the window. - - - -The structure for this event type contains: - - - -XColormapEvent - - - - -typedef struct { - int type; /* ColormapNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - Colormap colormap; /* colormap or None */ - Bool new; - int state; /* ColormapInstalled, ColormapUninstalled */ -} XColormapEvent; - - - - - -The window member is set to the window whose associated -colormap is changed, installed, or uninstalled. -For a colormap that is changed, installed, or uninstalled, -the colormap member is set to the colormap associated with the window. -For a colormap that is changed by a call to -XFreeColormap, -the colormap member is set to -None. -The new member is set to indicate whether the colormap -for the specified window was changed or installed or uninstalled -and can be -True -or -False. -If it is -True, -the colormap was changed. -If it is -False, -the colormap was installed or uninstalled. -The state member is always set to indicate whether the colormap is installed or -uninstalled and can be -ColormapInstalled -or -ColormapUninstalled. - - - -Client Communication Events - - - - - -This section discusses: - - - - -ClientMessage -events - - - - -PropertyNotify -events - - - - -SelectionClear -events - - - - -SelectionNotify -events - - - - -SelectionRequest -events - - - - -ClientMessage Events - - - - - -EventsClientMessage -ClientMessage -The X server generates -ClientMessage -events only when a client calls the function -XSendEvent. - - - -The structure for this event type contains: - - - -XClientMessageEvent - - - - -typedef struct { - int type; /* ClientMessage */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - Atom message_type; - int format; - union { - char b[20]; - short s[10]; - long l[5]; - } data; -} XClientMessageEvent; - - - - - -The message_type member is set to an atom that indicates how the data -should be interpreted by the receiving client. -The format member is set to 8, 16, or 32 and specifies whether the data -should be viewed as a list of bytes, shorts, or longs. -The data member is a union that contains the members b, s, and l. -The b, s, and l members represent data of twenty 8-bit values, -ten 16-bit values, and five 32-bit values. -Particular message types might not make use of all these values. -The X server places no interpretation on the values in the window, -message_type, or data members. - - - -PropertyNotify Events - - - - - -EventsPropertyNotify -PropertyNotify -The X server can report -PropertyNotify -events to clients wanting information about property changes -for a specified window. - - - -To receive -PropertyNotify -events, set the -PropertyChangeMask -bit in the event-mask attribute of the window. - - - -The structure for this event type contains: - - - -XPropertyEvent - - - - -typedef struct { - int type; /* PropertyNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - Atom atom; - Time time; - int state; /* PropertyNewValue or PropertyDelete */ -} XPropertyEvent; - - - - - -The window member is set to the window whose associated -property was changed. -The atom member is set to the property's atom and indicates which -property was changed or desired. -The time member is set to the server time when the property was changed. -The state member is set to indicate whether the property was changed -to a new value or deleted and can be -PropertyNewValue -or -PropertyDelete. -The state member is set to -PropertyNewValue -when a property of the window is changed using -XChangeProperty -or -XRotateWindowProperties -(even when adding zero-length data using -XChangeProperty) -and when replacing all or part of a property with identical data using -XChangeProperty -or -XRotateWindowProperties. -The state member is set to -PropertyDelete -when a property of the window is deleted using -XDeleteProperty -or, if the delete argument is -True, -XGetWindowProperty. - - - -SelectionClear Events - - - - - -EventsSelectionClear -SelectionClear -The X server reports -SelectionClear -events to the client losing ownership of a selection. -The X server generates this event type when another client -asserts ownership of the selection by calling -XSetSelectionOwner. - - - -The structure for this event type contains: - - - -XSelectionClearEvent - - - - -typedef struct { - int type; /* SelectionClear */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window window; - Atom selection; - Time time; -} XSelectionClearEvent; - - - - - -The selection member is set to the selection atom. -The time member is set to the last change time recorded for the -selection. -The window member is the window that was specified by the current owner -(the owner losing the selection) in its -XSetSelectionOwner -call. - - - -SelectionRequest Events - - - - - -EventsSelectionRequest -SelectionRequest -The X server reports -SelectionRequest -events to the owner of a selection. -The X server generates this event whenever a client -requests a selection conversion by calling -XConvertSelection -for the owned selection. - - - -The structure for this event type contains: - - - -XSelectionRequestEvent - - - - -typedef struct { - int type; /* SelectionRequest */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window owner; - Window requestor; - Atom selection; - Atom target; - Atom property; - Time time; -} XSelectionRequestEvent; - - - - - -The owner member is set to the window -that was specified by the current owner in its -XSetSelectionOwner -call. -The requestor member is set to the window requesting the selection. -The selection member is set to the atom that names the selection. -For example, PRIMARY is used to indicate the primary selection. -The target member is set to the atom that indicates the type -the selection is desired in. -The property member can be a property name or -None. -The time member is set to the timestamp or -CurrentTime -value from the -ConvertSelection -request. - - - -The owner should convert the selection based on the specified target type -and send a -SelectionNotify -event back to the requestor. -A complete specification for using selections is given in the X Consortium -standard Inter-Client Communication Conventions Manual. - - - -SelectionNotify Events - - - - - -EventsSelectionNotify -SelectionNotify -This event is generated by the X server in response to a -ConvertSelection -protocol request when there is no owner for the selection. -When there is an owner, it should be generated by the owner -of the selection by using -XSendEvent. -The owner of a selection should send this event to a requestor when a selection -has been converted and stored as a property -or when a selection conversion could -not be performed (which is indicated by setting the property member to -None). - - - -If -None -is specified as the property in the -ConvertSelection -protocol request, the owner should choose a property name, -store the result as that property on the requestor window, -and then send a -SelectionNotify -giving that actual property name. - - - -The structure for this event type contains: - - - -XSelectionEvent - - - - -typedef struct { - int type; /* SelectionNotify */ - unsigned long serial; /* # of last request processed by server */ - Bool send_event; /* true if this came from a SendEvent request */ - Display *display; /* Display the event was read from */ - Window requestor; - Atom selection; - Atom target; - Atom property; /* atom or None */ - Time time; -} XSelectionEvent; - - - - - -The requestor member is set to the window associated with -the requestor of the selection. -The selection member is set to the atom that indicates the selection. -For example, PRIMARY is used for the primary selection. -The target member is set to the atom that indicates the converted type. -For example, PIXMAP is used for a pixmap. -The property member is set to the atom that indicates which -property the result was stored on. -If the conversion failed, -the property member is set to -None. -The time member is set to the time the conversion took place and -can be a timestamp or -CurrentTime. - - - - - - - + + + +Events + + +A client application communicates with the X server through the connection you establish with +the XOpenDisplay function. A client application sends requests to the X server over this +connection. These requests are made by the Xlib functions that are called in the client application. +Many Xlib functions cause the X server to generate events, and the user’s typing or moving the +pointer can generate events asynchronously. The X server returns events to the client on the same +connection. + + +This chapter discusses the following topics associated with events: + + + + Event types + Event structures + Event masks + Event processing + + + +Functions for handling events are dealt with in +the next chapter. + + + +Event Types + + + + + +Eventtypes +An event is data generated asynchronously by the X server as a result of some +device activity or as side effects of a request sent by an Xlib function. +Event +Device-related events propagate from the source window to ancestor windows +until some client application has selected that event type +or until the event is explicitly discarded. +The X server generally sends an event to a client application +only if the client has specifically asked to be informed of that event type, +typically by setting the event-mask attribute of the window. +The mask can also be set when you create a window +or by changing the window's +event-mask. +You can also mask out events that would propagate to ancestor windows +by manipulating the +do-not-propagate mask of the window's attributes. +However, +MappingNotify +events are always sent to all clients. +Input Control +Output Control + + + +An event type describes a specific event generated by the X server. +For each event type, +a corresponding constant name is defined in +<X11/X.h>, +X11/X.h +Files<X11/X.h> +Headers<X11/X.h> +which is used when referring to an event type. +Eventcategories +The following table lists the event category +and its associated event type or types. +The processing associated with these events is discussed in section 10.5. + + + + + + + + + + + + + + + Event Category + Event Type + + + + + Keyboard events + KeyPress, + KeyRelease + + + Pointer events + ButtonPress, + ButtonRelease, + MotionNotify + + + Window crossing events + EnterNotify, + LeaveNotify + + + Input focus events + FocusIn, + FocusOut + + + Keymap state notification event + KeymapNotify + + + Exposure events + Expose, + GraphicsExpose, + NoExpose + + + Structure control events + CirculateRequest, + ConfigureRequest, + MapRequest, + ResizeRequest + + + Window state notification events + + CirculateNotify, + ConfigureNotify, + CreateNotify, + DestroyNotify, + GravityNotify, + MapNotify, + MappingNotify, + ReparentNotify, + UnmapNotify, + VisibilityNotify + + + Colormap state notification event + ColormapNotify + + + Client communication events + ClientMessage, + PropertyNotify, + SelectionClear, + SelectionNotify, + SelectionRequest + + + + + + + + + + + + + + + + + +Event Structures + + + + + +For each event type, +a corresponding structure is declared in +<X11/Xlib.h>. +X11/Xlib.h +Files<X11/Xlib.h> +Headers<X11/Xlib.h> +All the event structures have the following common members: + + + +XAnyEvent + + + + +typedef struct { + int type; + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; +} XAnyEvent; + + + + + +The type member is set to the event type constant name that uniquely identifies +it. +For example, when the X server reports a +GraphicsExpose +event to a client application, it sends an +XGraphicsExposeEvent +structure with the type member set to +GraphicsExpose. +The display member is set to a pointer to the display the event was read on. +The send_event member is set to +True +if the event came from a +SendEvent +protocol request. +The serial member is set from the serial number reported in the protocol +but expanded from the 16-bit least-significant bits to a full 32-bit value. +The window member is set to the window that is most useful to toolkit +dispatchers. + + + +The X server can send events at any time in the input stream. +Xlib stores any events received while waiting for a reply in an event queue +for later use. +Xlib also provides functions that allow you to check events in the event queue +(see section 11.3). + + + +In addition to the individual structures declared for each event type, the +XEvent +structure is a union of the individual structures declared for each event type. +Depending on the type, +you should access members of each event by using the +XEvent +union. + + + +XEvent + + + + + +typedef union _XEvent { + int type; /* must not be changed */ + XAnyEvent xany; + XKeyEvent xkey; + XButtonEvent xbutton; + XMotionEvent xmotion; + XCrossingEvent xcrossing; + XFocusChangeEvent xfocus; + XExposeEvent xexpose; + XGraphicsExposeEvent xgraphicsexpose; + XNoExposeEvent xnoexpose; + XVisibilityEvent xvisibility; + XCreateWindowEvent xcreatewindow; + XDestroyWindowEvent xdestroywindow; + XUnmapEvent xunmap; + XMapEvent xmap; + XMapRequestEvent xmaprequest; + XReparentEvent xreparent; + XConfigureEvent xconfigure; + XGravityEvent xgravity; + XResizeRequestEvent xresizerequest; + XConfigureRequestEvent xconfigurerequest; + XCirculateEvent xcirculate; + XCirculateRequestEvent xcirculaterequest; + XPropertyEvent xproperty; + XSelectionClearEvent xselectionclear; + XSelectionRequestEvent xselectionrequest; + XSelectionEvent xselection; + XColormapEvent xcolormap; + XClientMessageEvent xclient; + XMappingEvent xmapping; + XErrorEvent xerror; + XKeymapEvent xkeymap; + long pad[24]; +} XEvent; + + + + + +An +XEvent +structure's first entry always is the type member, +which is set to the event type. +The second member always is the serial number of the protocol request +that generated the event. +The third member always is send_event, +which is a +Bool +that indicates if the event was sent by a different client. +The fourth member always is a display, +which is the display that the event was read from. +Except for keymap events, +the fifth member always is a window, +which has been carefully selected to be useful to toolkit dispatchers. +To avoid breaking toolkits, +the order of these first five entries is not to change. +Most events also contain a time member, +which is the time at which an event occurred. +In addition, a pointer to the generic event must be cast before it +is used to access any other information in the structure. + + + +Event Masks + + + + + +Event mask +Clients select event reporting of most events relative to a window. +To do this, pass an event mask to an Xlib event-handling +function that takes an event_mask argument. +The bits of the event mask are defined in +<X11/X.h>. +X11/X.h +Files<X11/X.h> +Headers<X11/X.h> +Each bit in the event mask maps to an event mask name, +which describes the event or events you want the X server to +return to a client application. + + + +Unless the client has specifically asked for them, +most events are not reported to clients when they are generated. +Unless the client suppresses them by setting graphics-exposures in the GC to +False, +GraphicsExpose +and +NoExpose +are reported by default as a result of +XCopyPlane +and +XCopyArea. +SelectionClear, +SelectionRequest, +SelectionNotify, +or +ClientMessage +cannot be masked. +Selection-related events are only sent to clients cooperating +with selections +(see section 4.5). +When the keyboard or pointer mapping is changed, +MappingNotify +is always sent to clients. + + + + +The following table +lists the event mask constants you can pass to +the event_mask argument and +the circumstances in which you would want to specify the +event mask: + + + + + + + + + + + Event Mask + Circumstances + + + + + NoEventMask + No events wanted + + + KeyPressMask + Keyboard down events wanted + + + KeyReleaseMask + Keyboard up events wanted + + + ButtonPressMask + Pointer button down events wanted + + + ButtonReleaseMask + Pointer button up events wanted + + + EnterWindowMask + Pointer window entry events wanted + + + LeaveWindowMask + Pointer window leave events wanted + + + PointerMotionMask + Pointer motion events wanted + + + PointerMotionHintMask + Pointer motion hints wanted + + + Button1MotionMask + Pointer motion while button 1 down + + + Button2MotionMask + Pointer motion while button 2 down + + + Button3MotionMask + Pointer motion while button 3 down + + + Button4MotionMask + Pointer motion while button 4 down + + + Button5MotionMask + Pointer motion while button 5 down + + + ButtonMotionMask + Pointer motion while any button down + + + KeymapStateMask + Keyboard state wanted at window entry and focus in + + + ExposureMask + Any exposure wanted + + + VisibilityChangeMask + Any change in visibility wanted + + + StructureNotifyMask + Any change in window structure wanted + + + ResizeRedirectMask + Redirect resize of this window + + + SubstructureNotifyMask + Substructure notification wanted + + + SubstructureRedirectMask + Redirect structure requests on children + + + FocusChangeMask + Any change in input focus wanted + + + PropertyChangeMask + Any change in property wanted + + + ColormapChangeMask + Any change in colormap wanted + + + OwnerGrabButtonMask + Automatic grabs should activate with owner_events set to True + + + + + + + + + + +Event Processing Overview + + + + + +The event reported to a client application during event processing +depends on which event masks you provide as the event-mask attribute +for a window. +For some event masks, there is a one-to-one correspondence between +the event mask constant and the event type constant. +For example, if you pass the event mask +ButtonPressMask, +the X server sends back only +ButtonPress +events. +CurrentTime +Most events contain a time member, +which is the time at which an event occurred. + + + +In other cases, one event mask constant can map to several event type constants. +For example, if you pass the event mask +SubstructureNotifyMask, +the X server can send back +CirculateNotify, +ConfigureNotify, +CreateNotify, +DestroyNotify, +GravityNotify, +MapNotify, +ReparentNotify, +or +UnmapNotify +events. + + + +In another case, +two event masks can map to one event type. +For example, +if you pass either +PointerMotionMask +or +ButtonMotionMask, +the X server sends back +a +MotionNotify +event. + + + +The following table +lists the event mask, +its associated event type or types, +and the structure name associated with the event type. +Some of these structures actually are typedefs to a generic structure +that is shared between two event types. +Note that N.A. appears in columns for which the information is not applicable. + + + + + + + + + + + + + Event Mask + Event Type + Structure + Generic Structure + + + + + ButtonMotionMask + MotionNotify + XPointerMovedEvent + XMotionEvent + + + Button1MotionMask + + + Button2MotionMask + + + Button3MotionMask + + + Button4MotionMask + + + Button5MotionMask + + + ButtonPressMask + ButtonPress + XButtonPressedEvent + XButtonEvent + + + ButtonReleaseMask + ButtonRelease + XButtonReleasedEvent + XButtonEvent + + + ColormapChangeMask + ColormapNotify + XColormapEvent + + + EnterWindowMask + EnterNotify + XEnterWindowEvent + XCrossingEvent + + + LeaveWindowMask + LeaveNotify + XLeaveWindowEvent + XCrossingEvent + + + ExposureMask + Expose + XExposeEvent + + + GCGraphicsExposures in GC + GraphicsExpose + XGraphicsExposeEvent + + + + NoExpose + XNoExposeEvent + + + FocusChangeMask + FocusIn + XFocusInEvent + XFocusChangeEvent + + + + FocusOut + XFocusOutEvent + XFocusChangeEvent + + + KeymapStateMask + KeymapNotify + XKeymapEvent + + + KeyPressMask + KeyPress + XKeyPressedEvent + XKeyEvent + + + KeyReleaseMask + KeyRelease + XKeyReleasedEvent + XKeyEvent + + + OwnerGrabButtonMask + N.A. + N.A. + + + PointerMotionMask + MotionNotify + XPointerMovedEvent + XMotionEvent + + + PointerMotionHintMask + N.A. + N.A. + + + PropertyChangeMask + PropertyNotify + XPropertyEvent + + + ResizeRedirectMask + ResizeRequest + XResizeRequestEvent + + + StructureNotifyMask + CirculateNotify + XCirculateEvent + + + + ConfigureNotify + XConfigureEvent + + + + DestroyNotify + XDestroyWindowEvent + + + + GravityNotify + XGravityEvent + + + + MapNotify + XMapEvent + + + + ReparentNotify + XReparentEvent + + + + UnmapNotify + XUnmapEvent + + + SubstructureNotifyMask + CirculateNotify + XCirculateEvent + + + + ConfigureNotify + XConfigureEvent + + + + CreateNotify + XCreateWindowEvent + + + + DestroyNotify + XDestroyWindowEvent + + + + GravityNotify + XGravityEvent + + + + MapNotify + XMapEvent + + + + ReparentNotify + XReparentEvent + + + + UnmapNotify + XUnmapEvent + + + SubstructureRedirectMask + CirculateRequest + XCirculateRequestEvent + + + + ConfigureRequest + XConfigureRequestEvent + + + + MapRequest + XMapRequestEvent + + + N.A. + ClientMessage + XClientMessageEvent + + + N.A. + MappingNotify + XMappingEvent + + + N.A. + SelectionClear + XSelectionClearEvent + + + N.A. + SelectionNotify + XSelectionEvent + + + N.A. + SelectionRequest + XSelectionRequestEvent + + + VisibilityChangeMask + VisibilityNotify + XVisibilityEvent + + + _ + + + + + + + +The sections that follow describe the processing that occurs +when you select the different event masks. +The sections are organized according to these processing categories: + + + + +Keyboard and pointer events + + + + +Window crossing events + + + + +Input focus events + + + + +Keymap state notification events + + + + +Exposure events + + + + +Window state notification events + + + + +Structure control events + + + + +Colormap state notification events + + + + +Client communication events + + + + + + + +Keyboard and Pointer Events + + + + + +This section discusses: + + + + +Pointer button events + + + + +Keyboard and pointer events + + + + +Pointer Button Events + + + + + +The following describes the event processing that occurs when a pointer button +press is processed with the pointer in some window w and +when no active pointer grab is in progress. + + + +The X server searches the ancestors of w from the root down, +looking for a passive grab to activate. +If no matching passive grab on the button exists, +the X server automatically starts an active grab for the client receiving +the event and sets the last-pointer-grab time to the current server time. +The effect is essentially equivalent to an +XGrabButton +with these client passed arguments: + + + + + + + + Argument + Value + + + + + w + The event window + + + event_mask + The client's selected pointer events on the event window + + + pointer_mode + GrabModeAsync + + + keyboard_mode + GrabModeAsync + + + owner_events + True, + if the client has selected + OwnerGrabButtonMask + on the event window, + otherwise + False + + + confine_to + None + + + cursor + None + + + + + + + +The active grab is automatically terminated when +the logical state of the pointer has all buttons released. +Clients can modify the active grab by calling +XUngrabPointer +and +XChangeActivePointerGrab. + + + + +Keyboard and Pointer Events + + + + + +EventsButtonPress +EventsButtonRelease +EventsKeyPress +EventsKeyRelease +EventsMotionNotify +This section discusses the processing that occurs for the +keyboard events +KeyPress +and +KeyRelease +and the pointer events +ButtonPress, +ButtonRelease, +and +MotionNotify. +For information about the keyboard event-handling utilities, +see chapter 11. + + + +KeyPress +KeyRelease +The X server reports +KeyPress +or +KeyRelease +events to clients wanting information about keys that logically change state. +Note that these events are generated for all keys, +even those mapped to modifier bits. +ButtonPress +ButtonRelease +The X server reports +ButtonPress +or +ButtonRelease +events to clients wanting information about buttons that logically change state. + + + +MotionNotify +The X server reports +MotionNotify +events to clients wanting information about when the pointer logically moves. +The X server generates this event whenever the pointer is moved +and the pointer motion begins and ends in the window. +The granularity of +MotionNotify +events is not guaranteed, +but a client that selects this event type is guaranteed +to receive at least one event when the pointer moves and then rests. + + + +The generation of the logical changes lags the physical changes +if device event processing is frozen. + + + +To receive +KeyPress, +KeyRelease, +ButtonPress, +and +ButtonRelease +events, set +KeyPressMask, +KeyReleaseMask, +ButtonPressMask, +and +ButtonReleaseMask +bits in the event-mask attribute of the window. + + + +To receive +MotionNotify +events, set one or more of the following event +masks bits in the event-mask attribute of the window. + + + + +Button1MotionMask - Button5MotionMask + + + + +The client application receives +MotionNotify +events only when one or more of the specified buttons is pressed. + + + + +ButtonMotionMask + + + + +The client application receives +MotionNotify +events only when at least one button is pressed. + + + + +PointerMotionMask + + + + +The client application receives +MotionNotify +events independent of the state of +the pointer buttons. + + + + +PointerMotionHintMask + + + + +If +PointerMotionHintMask +is selected in combination with one or more of the above masks, +the X server is free to send only one +MotionNotify +event (with the is_hint member of the +XPointerMovedEvent +structure set to +NotifyHint) +to the client for the event window, +until either the key or button state changes, +the pointer leaves the event window, or the client calls +XQueryPointer +or +XGetMotionEvents. +The server still may send +MotionNotify +events without is_hint set to +NotifyHint. + + + + + +The source of the event is the viewable window that the pointer is in. +The window used by the X server to report these events depends on +the window's position in the window hierarchy +and whether any intervening window prohibits the generation of these events. +Starting with the source window, +the X server searches up the window hierarchy until it locates the first +window specified by a client as having an interest in these events. +If one of the intervening windows has its do-not-propagate-mask +set to prohibit generation of the event type, +the events of those types will be suppressed. +Clients can modify the actual window used for reporting by performing +active grabs and, in the case of keyboard events, by using the focus window. + + + +The structures for these event types contain: + + +typedef struct { + int type; /* ButtonPress or ButtonRelease */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* ``event'' window it is reported relative to */ + Window root; /* root window that the event occurred on */ + Window subwindow; /* child window */ + Time time; /* milliseconds */ + int x, y; /* pointer x, y coordinates in event window */ + int x_root, y_root; /* coordinates relative to root */ + unsigned int state; /* key or button mask */ + unsigned int button; /* detail */ + Bool same_screen; /* same screen flag */ +} XButtonEvent; +typedef XButtonEvent XButtonPressedEvent; +typedef XButtonEvent XButtonReleasedEvent; + + + +typedef struct { + int type; /* KeyPress or KeyRelease */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* ``event'' window it is reported relative to */ + Window root; /* root window that the event occurred on */ + Window subwindow; /* child window */ + Time time; /* milliseconds */ + int x, y; /* pointer x, y coordinates in event window */ + int x_root, y_root; /* coordinates relative to root */ + unsigned int state; /* key or button mask */ + unsigned int keycode; /* detail */ + Bool same_screen; /* same screen flag */ +} XKeyEvent; +typedef XKeyEvent XKeyPressedEvent; +typedef XKeyEvent XKeyReleasedEvent; + + + +typedef struct { + int type; /* MotionNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* ``event'' window reported relative to */ + Window root; /* root window that the event occurred on */ + Window subwindow; /* child window */ + Time time; /* milliseconds */ + int x, y; /* pointer x, y coordinates in event window */ + int x_root, y_root; /* coordinates relative to root */ + unsigned int state; /* key or button mask */ + char is_hint; /* detail */ + Bool same_screen; /* same screen flag */ +} XMotionEvent; +typedef XMotionEvent XPointerMovedEvent; + + + +These structures have the following common members: +window, root, subwindow, time, x, y, x_root, y_root, state, and same_screen. +The window member is set to the window on which the +event was generated and is referred to as the event window. +As long as the conditions previously discussed are met, +this is the window used by the X server to report the event. +The root member is set to the source window's root window. +The x_root and y_root members are set to the pointer's coordinates +relative to the root window's origin at the time of the event. + + + + +The same_screen member is set to indicate whether the event +window is on the same screen +as the root window and can be either +True +or +False. +If +True, +the event and root windows are on the same screen. +If +False, +the event and root windows are not on the same screen. + + + +If the source window is an inferior of the event window, +the subwindow member of the structure is set to the child of the event window +that is the source window or the child of the event window that is +an ancestor of the source window. +Otherwise, the X server sets the subwindow member to +None. +The time member is set to the time when the event was generated +and is expressed in milliseconds. + + + +If the event window is on the same screen as the root window, +the x and y members +are set to the coordinates relative to the event window's origin. +Otherwise, these members are set to zero. + + + +The state member is set to indicate the logical state of the pointer buttons +and modifier keys just prior to the event, +which is the bitwise inclusive OR of one or more of the +button or modifier key masks: +Button1Mask, +Button2Mask, +Button3Mask, +Button4Mask, +Button5Mask, +ShiftMask, +LockMask, +ControlMask, +Mod1Mask, +Mod2Mask, +Mod3Mask, +Mod4Mask, +and +Mod5Mask. + + + +Each of these structures also has a member that indicates the detail. +For the +XKeyPressedEvent +and +XKeyReleasedEvent +structures, this member is called a keycode. +It is set to a number that represents a physical key on the keyboard. +The keycode is an arbitrary representation for any key on the keyboard +(see sections 12.7 + and 16.1). + + + +For the +XButtonPressedEvent +and +XButtonReleasedEvent +structures, this member is called button. +It represents the pointer button that changed state and can be the +Button1, +Button2, +Button3, +Button4, +or +Button5 +value. +For the +XPointerMovedEvent +structure, this member is called is_hint. +It can be set to +NotifyNormal +or +NotifyHint. + + + +Some of the symbols mentioned in this section have fixed values, as +follows: + + + + + + + + Symbol + Value + + + + + Button1MotionMask + (1L<<8) + + + Button2MotionMask + (1L<<9) + + + Button3MotionMask + (1L<<10) + + + Button4MotionMask + (1L<<11) + + + Button5MotionMask + (1L<<12) + + + Button1Mask + (1<<8) + + + Button2Mask + (1<<9) + + + Button3Mask + (1<<10) + + + Button4Mask + (1<<11) + + + Button5Mask + (1<<12) + + + ShiftMask + (1<<0) + + + LockMask + (1<<1) + + + ControlMask + (1<<2) + + + Mod1Mask + (1<<3) + + + Mod2Mask + (1<<4) + + + Mod3Mask + (1<<5) + + + Mod4Mask + (1<<6) + + + Mod5Mask + (1<<7) + + + Button1 + 1 + + + Button2 + 2 + + + Button3 + 3 + + + Button4 + 4 + + + Button5 + 5 + + + + + + + + +Window Entry/Exit Events + + + + + +EventsEnterNotify +EventsLeaveNotify +This section describes the processing that +occurs for the window crossing events +EnterNotify +and +LeaveNotify. +EnterNotify +LeaveNotify +If a pointer motion or a window hierarchy change causes the +pointer to be in a different window than before, the X server reports +EnterNotify +or +LeaveNotify +events to clients who have selected for these events. +All +EnterNotify +and +LeaveNotify +events caused by a hierarchy change are +generated after any hierarchy event +(UnmapNotify, +MapNotify, +ConfigureNotify, +GravityNotify, +CirculateNotify) +caused by that change; +however, the X protocol does not constrain the ordering of +EnterNotify +and +LeaveNotify +events with respect to +FocusOut, +VisibilityNotify, +and +Expose +events. + + + +This contrasts with +MotionNotify +events, which are also generated when the pointer moves +but only when the pointer motion begins and ends in a single window. +An +EnterNotify +or +LeaveNotify +event also can be generated when some client application calls +XGrabPointer +and +XUngrabPointer. + + + +To receive +EnterNotify +or +LeaveNotify +events, set the +EnterWindowMask +or +LeaveWindowMask +bits of the event-mask attribute of the window. + + + +The structure for these event types contains: + + +XCrossingEvent +XEnterWindowEvent +XLeaveWindowEvent + + + + +typedef struct { + int type; /* EnterNotify or LeaveNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* ``event'' window reported relative to */ + Window root; /* root window that the event occurred on */ + Window subwindow; /* child window */ + Time time; /* milliseconds */ + int x, y; /* pointer x, y coordinates in event window */ + int x_root, y_root; /* coordinates relative to root */ + int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ + int detail; + /* + * NotifyAncestor, NotifyVirtual, NotifyInferior, + * NotifyNonlinear,NotifyNonlinearVirtual + */ + Bool same_screen; /* same screen flag */ + Bool focus; /* boolean focus */ + unsigned int state; /* key or button mask */ +} XCrossingEvent; +typedef XCrossingEvent XEnterWindowEvent; +typedef XCrossingEvent XLeaveWindowEvent; + + + + + +The window member is set to the window on which the +EnterNotify +or +LeaveNotify +event was generated and is referred to as the event window. +This is the window used by the X server to report the event, +and is relative to the root +window on which the event occurred. +The root member is set to the root window of the screen +on which the event occurred. + + + +For a +LeaveNotify +event, +if a child of the event window contains the initial position of the pointer, +the subwindow component is set to that child. +Otherwise, the X server sets the subwindow member to +None. +For an +EnterNotify +event, if a child of the event window contains the final pointer position, +the subwindow component is set to that child or +None. + + + +The time member is set to the time when the event was generated +and is expressed in milliseconds. +The x and y members are set to the coordinates of the pointer position in +the event window. +This position is always the pointer's final position, +not its initial position. +If the event window is on the same +screen as the root window, x and y are the pointer coordinates +relative to the event window's origin. +Otherwise, x and y are set to zero. +The x_root and y_root members are set to the pointer's coordinates relative to the +root window's origin at the time of the event. + + + +The same_screen member is set to indicate whether the event window is on the same screen +as the root window and can be either +True +or +False. +If +True, +the event and root windows are on the same screen. +If +False, +the event and root windows are not on the same screen. + + + +The focus member is set to indicate whether the event window is the focus window or an +inferior of the focus window. +The X server can set this member to either +True +or +False. +If +True, +the event window is the focus window or an inferior of the focus window. +If +False, +the event window is not the focus window or an inferior of the focus window. + + + +The state member is set to indicate the state of the pointer buttons and +modifier keys just prior to the +event. +The X server can set this member to the bitwise inclusive OR of one +or more of the button or modifier key masks: +Button1Mask, +Button2Mask, +Button3Mask, +Button4Mask, +Button5Mask, +ShiftMask, +LockMask, +ControlMask, +Mod1Mask, +Mod2Mask, +Mod3Mask, +Mod4Mask, +Mod5Mask. + + + +The mode member is set to indicate whether the events are normal events, +pseudo-motion events +when a grab activates, or pseudo-motion events when a grab deactivates. +The X server can set this member to +NotifyNormal, +NotifyGrab, +or +NotifyUngrab. + + + +The detail member is set to indicate the notify detail and can be +NotifyAncestor, +NotifyVirtual, +NotifyInferior, +NotifyNonlinear, +or +NotifyNonlinearVirtual. + + +Normal Entry/Exit Events + + + + + +EnterNotify +and +LeaveNotify +events are generated when the pointer moves from +one window to another window. +Normal events are identified by +XEnterWindowEvent +or +XLeaveWindowEvent +structures whose mode member is set to +NotifyNormal. + + + + +When the pointer moves from window A to window B and A is an inferior of B, +the X server does the following: + + + + + +It generates a +LeaveNotify +event on window A, with the detail member of the +XLeaveWindowEvent +structure set to +NotifyAncestor. + + + + +It generates a +LeaveNotify +event on each window between window A and window B, exclusive, +with the detail member of each +XLeaveWindowEvent +structure set to +NotifyVirtual. + + + + +It generates an +EnterNotify +event on window B, with the detail member of the +XEnterWindowEvent +structure set to +NotifyInferior. + + + + + +When the pointer moves from window A to window B and B is an inferior of A, +the X server does the following: + + + + + +It generates a +LeaveNotify +event on window A, +with the detail member of the +XLeaveWindowEvent +structure set to +NotifyInferior. + + + + +It generates an +EnterNotify +event on each window between window A and window B, exclusive, with the +detail member of each +XEnterWindowEvent +structure set to +NotifyVirtual. + + + + +It generates an +EnterNotify +event on window B, with the detail member of the +XEnterWindowEvent +structure set to +NotifyAncestor. + + + + + +When the pointer moves from window A to window B +and window C is their least common ancestor, +the X server does the following: + + + + + +It generates a +LeaveNotify +event on window A, +with the detail member of the +XLeaveWindowEvent +structure set to +NotifyNonlinear. + + + + +It generates a +LeaveNotify +event on each window between window A and window C, exclusive, +with the detail member of each +XLeaveWindowEvent +structure set to +NotifyNonlinearVirtual. + + + + +It generates an +EnterNotify +event on each window between window C and window B, exclusive, +with the detail member of each +XEnterWindowEvent +structure set to +NotifyNonlinearVirtual. + + + + +It generates an +EnterNotify +event on window B, with the detail member of the +XEnterWindowEvent +structure set to +NotifyNonlinear. + + + + + +When the pointer moves from window A to window B on different screens, +the X server does the following: + + + + + +It generates a +LeaveNotify +event on window A, +with the detail member of the +XLeaveWindowEvent +structure set to +NotifyNonlinear. + + + + +If window A is not a root window, +it generates a +LeaveNotify +event on each window above window A up to and including its root, +with the detail member of each +XLeaveWindowEvent +structure set to +NotifyNonlinearVirtual. + + + + +If window B is not a root window, +it generates an +EnterNotify +event on each window from window B's root down to but not including +window B, with the detail member of each +XEnterWindowEvent +structure set to +NotifyNonlinearVirtual. + + + + +It generates an +EnterNotify +event on window B, with the detail member of the +XEnterWindowEvent +structure set to +NotifyNonlinear. + + + + + + + +Grab and Ungrab Entry/Exit Events + + + + + +Pseudo-motion mode +EnterNotify +and +LeaveNotify +events are generated when a pointer grab activates or deactivates. +Events in which the pointer grab activates +are identified by +XEnterWindowEvent +or +XLeaveWindowEvent +structures whose mode member is set to +NotifyGrab. +Events in which the pointer grab deactivates +are identified by +XEnterWindowEvent +or +XLeaveWindowEvent +structures whose mode member is set to +NotifyUngrab +(see +XGrabPointer). + + + + +When a pointer grab activates after any initial warp into a confine_to +window and before generating any actual +ButtonPress +event that activates the grab, +G is the grab_window for the grab, +and P is the window the pointer is in, +the X server does the following: + + + + + +It generates +EnterNotify +and +LeaveNotify +events (see section 10.6.1) +with the mode members of the +XEnterWindowEvent +and +XLeaveWindowEvent +structures set to +NotifyGrab. +These events are generated +as if the pointer were to suddenly warp from +its current position in P to some position in G. +However, the pointer does not warp, and the X server uses the pointer position +as both the initial and final positions for the events. + + + + + +When a pointer grab deactivates after generating any actual +ButtonRelease +event that deactivates the grab, +G is the grab_window for the grab, +and P is the window the pointer is in, +the X server does the following: + + + + + +It generates +EnterNotify +and +LeaveNotify +events (see section 10.6.1) +with the mode members of the +XEnterWindowEvent +and +XLeaveWindowEvent +structures set to +NotifyUngrab. +These events are generated as if the pointer were to suddenly warp from +some position in G to its current position in P. +However, the pointer does not warp, and the X server uses the +current pointer position as both the +initial and final positions for the events. + + + + + + + +Input Focus Events + + + + + +EventsFocusIn +EventsFocusOut +This section describes the processing that occurs for the input focus events +FocusIn +and +FocusOut. +FocusIn +FocusOut +The X server can report +FocusIn +or +FocusOut +events to clients wanting information about when the input focus changes. +The keyboard is always attached to some window +(typically, the root window or a top-level window), +which is called the focus window. +The focus window and the position of the pointer determine the window that +receives keyboard input. +Clients may need to know when the input focus changes +to control highlighting of areas on the screen. + + + +To receive +FocusIn +or +FocusOut +events, set the +FocusChangeMask +bit in the event-mask attribute of the window. + + + +The structure for these event types contains: + + +XFocusChangeEvent +XFocusInEvent +XFocusOutEvent + + + + +typedef struct { + int type; /* FocusIn or FocusOut */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* window of event */ + int mode; /* NotifyNormal, NotifyGrab, NotifyUngrab */ + int detail; + /* + * NotifyAncestor, NotifyVirtual, NotifyInferior, + * NotifyNonlinear,NotifyNonlinearVirtual, NotifyPointer, + * NotifyPointerRoot, NotifyDetailNone + */ +} XFocusChangeEvent; +typedef XFocusChangeEvent XFocusInEvent; +typedef XFocusChangeEvent XFocusOutEvent; + + + + +The window member is set to the window on which the +FocusIn +or +FocusOut +event was generated. +This is the window used by the X server to report the event. +The mode member is set to indicate whether the focus events +are normal focus events, +focus events while grabbed, +focus events +when a grab activates, or focus events when a grab deactivates. +The X server can set the mode member to +NotifyNormal, +NotifyWhileGrabbed, +NotifyGrab, +or +NotifyUngrab. + + + +All +FocusOut +events caused by a window unmap are generated after any +UnmapNotify +event; however, the X protocol does not constrain the ordering of +FocusOut +events with respect to +generated +EnterNotify, +LeaveNotify, +VisibilityNotify, +and +Expose +events. + + + +Depending on the event mode, +the detail member is set to indicate the notify detail and can be +NotifyAncestor, +NotifyVirtual, +NotifyInferior, +NotifyNonlinear, +NotifyNonlinearVirtual, +NotifyPointer, +NotifyPointerRoot, +or +NotifyDetailNone. + + +Normal Focus Events and Focus Events While Grabbed + + + + + +Normal focus events are identified by +XFocusInEvent +or +XFocusOutEvent +structures whose mode member is set to +NotifyNormal. +Focus events while grabbed are identified by +XFocusInEvent +or +XFocusOutEvent +structures whose mode member is set to +NotifyWhileGrabbed. +The X server processes normal focus and focus events while grabbed according to +the following: + + + + +When the focus moves from window A to window B, A is an inferior of B, +and the pointer is in window P, +the X server does the following: + + + + + +It generates a +FocusOut +event on window A, with the detail member of the +XFocusOutEvent +structure set to +NotifyAncestor. + + + + +It generates a +FocusOut +event on each window between window A and window B, exclusive, +with the detail member of each +XFocusOutEvent +structure set to +NotifyVirtual. + + + + +It generates a +FocusIn +event on window B, with the detail member of the +XFocusOutEvent +structure set to +NotifyInferior. + + + + +If window P is an inferior of window B +but window P is not window A or an inferior or ancestor of window A, +it generates a +FocusIn +event on each window below window B, down to and including window P, +with the detail member of each +XFocusInEvent +structure set to +NotifyPointer. + + + + + +When the focus moves from window A to window B, B is an inferior of A, +and the pointer is in window P, +the X server does the following: + + + + + +If window P is an inferior of window A +but P is not an inferior of window B or an ancestor of B, +it generates a +FocusOut +event on each window from window P up to but not including window A, +with the detail member of each +XFocusOutEvent +structure set to +NotifyPointer. + + + + +It generates a +FocusOut +event on window A, +with the detail member of the +XFocusOutEvent +structure set to +NotifyInferior. + + + + +It generates a +FocusIn +event on each window between window A and window B, exclusive, with the +detail member of each +XFocusInEvent +structure set to +NotifyVirtual. + + + + +It generates a +FocusIn +event on window B, with the detail member of the +XFocusInEvent +structure set to +NotifyAncestor. + + + + + +When the focus moves from window A to window B, +window C is their least common ancestor, +and the pointer is in window P, +the X server does the following: + + + + + +If window P is an inferior of window A, +it generates a +FocusOut +event on each window from window P up to but not including window A, +with the detail member of the +XFocusOutEvent +structure set to +NotifyPointer. + + + + +It generates a +FocusOut +event on window A, +with the detail member of the +XFocusOutEvent +structure set to +NotifyNonlinear. + + + + +It generates a +FocusOut +event on each window between window A and window C, exclusive, +with the detail member of each +XFocusOutEvent +structure set to +NotifyNonlinearVirtual. + + + + +It generates a +FocusIn +event on each window between C and B, exclusive, +with the detail member of each +XFocusInEvent +structure set to +NotifyNonlinearVirtual. + + + + +It generates a +FocusIn +event on window B, with the detail member of the +XFocusInEvent +structure set to +NotifyNonlinear. + + + + +If window P is an inferior of window B, it generates a +FocusIn +event on each window below window B down to and including window P, +with the detail member of the +XFocusInEvent +structure set to +NotifyPointer. + + + + + +When the focus moves from window A to window B on different screens +and the pointer is in window P, +the X server does the following: + + + + + +If window P is an inferior of window A, it generates a +FocusOut +event on each window from window P up to but not including window A, +with the detail member of each +XFocusOutEvent +structure set to +NotifyPointer. + + + + +It generates a +FocusOut +event on window A, +with the detail member of the +XFocusOutEvent +structure set to +NotifyNonlinear. + + + + +If window A is not a root window, +it generates a +FocusOut +event on each window above window A up to and including its root, +with the detail member of each +XFocusOutEvent +structure set to +NotifyNonlinearVirtual. + + + + +If window B is not a root window, +it generates a +FocusIn +event on each window from window B's root down to but not including +window B, with the detail member of each +XFocusInEvent +structure set to +NotifyNonlinearVirtual. + + + + +It generates a +FocusIn +event on window B, with the detail member of each +XFocusInEvent +structure set to +NotifyNonlinear. + + + + +If window P is an inferior of window B, it generates a +FocusIn +event on each window below window B down to and including window P, +with the detail member of each +XFocusInEvent +structure set to +NotifyPointer. + + + + + +When the focus moves from window A to +PointerRoot +(events sent to the window under the pointer) +or +None +(discard), and the pointer is in window P, +the X server does the following: + + + + + +If window P is an inferior of window A, it generates a +FocusOut +event on each window from window P up to but not including window A, +with the detail member of each +XFocusOutEvent +structure set to +NotifyPointer. + + + + +It generates a +FocusOut +event on window A, with the detail member of the +XFocusOutEvent +structure set to +NotifyNonlinear. + + + + +If window A is not a root window, +it generates a +FocusOut +event on each window above window A up to and including its root, +with the detail member of each +XFocusOutEvent +structure set to +NotifyNonlinearVirtual. + + + + +It generates a +FocusIn +event on the root window of all screens, with the detail member of each +XFocusInEvent +structure set to +NotifyPointerRoot +(or +NotifyDetailNone). + + + + +If the new focus is +PointerRoot, +it generates a +FocusIn +event on each window from window P's root down to and including window P, +with the detail member of each +XFocusInEvent +structure set to +NotifyPointer. + + + + + +When the focus moves from +PointerRoot +(events sent to the window under the pointer) +or +None +to window A, and the pointer is in window P, +the X server does the following: + + + + + +If the old focus is +PointerRoot, +it generates a +FocusOut +event on each window from window P up to and including window P's root, +with the detail member of each +XFocusOutEvent +structure set to +NotifyPointer. + + + + +It generates a +FocusOut +event on all root windows, +with the detail member of each +XFocusOutEvent +structure set to +NotifyPointerRoot +(or +NotifyDetailNone). + + + + +If window A is not a root window, +it generates a +FocusIn +event on each window from window A's root down to but not including window A, +with the detail member of each +XFocusInEvent +structure set to +NotifyNonlinearVirtual. + + + + +It generates a +FocusIn +event on window A, +with the detail member of the +XFocusInEvent +structure set to +NotifyNonlinear. + + + + +If window P is an inferior of window A, it generates a +FocusIn +event on each window below window A down to and including window P, +with the detail member of each +XFocusInEvent +structure set to +NotifyPointer. + + + + + +When the focus moves from +PointerRoot +(events sent to the window under the pointer) +to +None +(or vice versa), and the pointer is in window P, +the X server does the following: + + + + + +If the old focus is +PointerRoot, +it generates a +FocusOut +event on each window from window P up to and including window P's root, +with the detail member of each +XFocusOutEvent +structure set to +NotifyPointer. + + + + +It generates a +FocusOut +event on all root windows, +with the detail member of each +XFocusOutEvent +structure set to either +NotifyPointerRoot +or +NotifyDetailNone. + + + + +It generates a +FocusIn +event on all root windows, +with the detail member of each +XFocusInEvent +structure set to +NotifyDetailNone +or +NotifyPointerRoot. + + + + +If the new focus is +PointerRoot, +it generates a +FocusIn +event on each window from window P's root down to and including window P, +with the detail member of each +XFocusInEvent +structure set to +NotifyPointer. + + + + + + + +Focus Events Generated by Grabs + + + + + +Focus events in which the keyboard grab activates +are identified by +XFocusInEvent +or +XFocusOutEvent +structures whose mode member is set to +NotifyGrab. +Focus events in which the keyboard grab deactivates +are identified by +XFocusInEvent +or +XFocusOutEvent +structures whose mode member is set to +NotifyUngrab +(see +XGrabKeyboard). + + + + +When a keyboard grab activates before generating any actual +KeyPress +event that activates the grab, +G is the grab_window, and F is the current focus, +the X server does the following: + + + + + +It generates +FocusIn +and +FocusOut +events, with the mode members of the +XFocusInEvent +and +XFocusOutEvent +structures set to +NotifyGrab. +These events are generated +as if the focus were to change from +F to G. + + + + + +When a keyboard grab deactivates after generating any actual +KeyRelease +event that deactivates the grab, +G is the grab_window, and F is the current focus, +the X server does the following: + + + + + +It generates +FocusIn +and +FocusOut +events, with the mode members of the +XFocusInEvent +and +XFocusOutEvent +structures set to +NotifyUngrab. +These events are generated +as if the focus were to change from +G to F. + + + + + + + +Key Map State Notification Events + + + + + +EventsKeymapNotify +KeymapNotify +The X server can report +KeymapNotify +events to clients that want information about changes in their keyboard state. + + + +To receive +KeymapNotify +events, set the +KeymapStateMask +bit in the event-mask attribute of the window. +The X server generates this event immediately after every +EnterNotify +and +FocusIn +event. + + + +The structure for this event type contains: + + + +XKeymapEvent + + + + +/* generated on EnterWindow and FocusIn when KeymapState selected */ +typedef struct { + int type; /* KeymapNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + char key_vector[32]; +} XKeymapEvent; + + + + + +The window member is not used but is present to aid some toolkits. +The key_vector member is set to the bit vector of the keyboard. +Each bit set to 1 indicates that the corresponding key +is currently pressed. +The vector is represented as 32 bytes. +Byte N (from 0) contains the bits for keys 8N to 8N + 7 +with the least significant bit in the byte representing key 8N. + + + +Exposure Events + + + + + +The X protocol does not guarantee to preserve the contents of window +regions when +the windows are obscured or reconfigured. +Some implementations may preserve the contents of windows. +Other implementations are free to destroy the contents of windows +when exposed. +X expects client applications to assume the responsibility for +restoring the contents of an exposed window region. +(An exposed window region describes a formerly obscured window whose +region becomes visible.) +Therefore, the X server sends +Expose +events describing the window and the region of the window that has been exposed. +A naive client application usually redraws the entire window. +A more sophisticated client application redraws only the exposed region. + + +Expose Events + + + + + +EventsExpose +Expose +The X server can report +Expose +events to clients wanting information about when the contents of window regions +have been lost. +The circumstances in which the X server generates +Expose +events are not as definite as those for other events. +However, the X server never generates +Expose +events on windows whose class you specified as +InputOnly. +The X server can generate +Expose +events when no valid contents are available for regions of a window +and either the regions are visible, +the regions are viewable and the server is (perhaps newly) maintaining +backing store on the window, +or the window is not viewable but the server is (perhaps newly) honoring the +window's backing-store attribute of +Always +or +WhenMapped. +The regions decompose into an (arbitrary) set of rectangles, +and an +Expose +event is generated for each rectangle. +For any given window, +the X server guarantees to report contiguously +all of the regions exposed by some action that causes +Expose +events, such as raising a window. + + + +To receive +Expose +events, set the +ExposureMask +bit in the event-mask attribute of the window. + + + +The structure for this event type contains: + + + +XExposeEvent + + + + +typedef struct { + int type; /* Expose */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + int x, y; + int width, height; + int count; /* if nonzero, at least this many more */ +} XExposeEvent; + + + + + +The window member is set to the exposed (damaged) window. +The x and y members are set to the coordinates relative to the window's origin +and indicate the upper-left corner of the rectangle. +The width and height members are set to the size (extent) of the rectangle. +The count member is set to the number of +Expose +events that are to follow. +If count is zero, no more +Expose +events follow for this window. +However, if count is nonzero, at least that number of +Expose +events (and possibly more) follow for this window. +Simple applications that do not want to optimize redisplay by distinguishing +between subareas of its window can just ignore all +Expose +events with nonzero counts and perform full redisplays +on events with zero counts. + + + +GraphicsExpose and NoExpose Events + + + + + +EventsGraphicsExpose +EventsNoExpose +GraphicsExpose +The X server can report +GraphicsExpose +events to clients wanting information about when a destination region could not +be computed during certain graphics requests: +XCopyArea +or +XCopyPlane. +The X server generates this event whenever a destination region could not be +computed because of an obscured or out-of-bounds source region. +In addition, the X server guarantees to report contiguously all of the regions exposed by +some graphics request +(for example, copying an area of a drawable to a destination +drawable). + + + +NoExpose +The X server generates a +NoExpose +event whenever a graphics request that might +produce a +GraphicsExpose +event does not produce any. +In other words, the client is really asking for a +GraphicsExpose +event but instead receives a +NoExpose +event. + + + +To receive +GraphicsExpose +or +NoExpose +events, you must first set the graphics-exposure +attribute of the graphics context to +True. +You also can set the graphics-expose attribute when creating a graphics +context using +XCreateGC +or by calling +XSetGraphicsExposures. + + + +The structures for these event types contain: + + + +XGraphicsExposeEvent + + + + +typedef struct { + int type; /* GraphicsExpose */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Drawable drawable; + int x, y; + int width, height; + int count; /* if nonzero, at least this many more */ + int major_code; /* core is CopyArea or CopyPlane */ + int minor_code; /* not defined in the core */ +} XGraphicsExposeEvent; + + + + +XNoExposeEvent + + + +typedef struct { + int type; /* NoExpose */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Drawable drawable; + int major_code; /* core is CopyArea or CopyPlane */ + int minor_code; /* not defined in the core */ +} XNoExposeEvent; + + + + + +Both structures have these common members: drawable, major_code, and minor_code. +The drawable member is set to the drawable of the destination region on +which the graphics request was to be performed. +The major_code member is set to the graphics request initiated by the client +and can be either +X_CopyArea +or +X_CopyPlane. +If it is +X_CopyArea, +a call to +XCopyArea +initiated the request. +If it is +X_CopyPlane, +a call to +XCopyPlane +initiated the request. +These constants are defined in +<X11/Xproto.h>. +X11/Xproto.h +Files<X11/Xproto.h> +Headers<X11/Xproto.h> +The minor_code member, +like the major_code member, +indicates which graphics request was initiated by +the client. +However, the minor_code member is not defined by the core +X protocol and will be zero in these cases, +although it may be used by an extension. + + + +The +XGraphicsExposeEvent +structure has these additional members: x, y, width, height, and count. +The x and y members are set to the coordinates relative to the drawable's origin +and indicate the upper-left corner of the rectangle. +The width and height members are set to the size (extent) of the rectangle. +The count member is set to the number of +GraphicsExpose +events to follow. +If count is zero, no more +GraphicsExpose +events follow for this window. +However, if count is nonzero, at least that number of +GraphicsExpose +events (and possibly more) are to follow for this window. + + + + +Window State Change Events + + + + + +The following sections discuss: + + + + +CirculateNotify +events + + + + +ConfigureNotify +events + + + + +CreateNotify +events + + + + +DestroyNotify +events + + + + +GravityNotify +events + + + + +MapNotify +events + + + + +MappingNotify +events + + + + +ReparentNotify +events + + + + +UnmapNotify +events + + + + +VisibilityNotify +events + + + + + +CirculateNotify Events + + + + + +EventsCirculateNotify +CirculateNotify +The X server can report +CirculateNotify +events to clients wanting information about when a window changes +its position in the stack. +The X server generates this event type whenever a window is actually restacked +as a result of a client application calling +XCirculateSubwindows, +XCirculateSubwindowsUp, +or +XCirculateSubwindowsDown. + + + +To receive +CirculateNotify +events, set the +StructureNotifyMask +bit in the event-mask attribute of the window +or the +SubstructureNotifyMask +bit in the event-mask attribute of the parent window +(in which case, circulating any child generates an event). + + + +The structure for this event type contains: + + + +XCirculateEvent + + + + +typedef struct { + int type; /* CirculateNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window event; + Window window; + int place; /* PlaceOnTop, PlaceOnBottom */ +} XCirculateEvent; + + + + + +The event member is set either to the restacked window or to its parent, +depending on whether +StructureNotify +or +SubstructureNotify +was selected. +The window member is set to the window that was restacked. +The place member is set to the window's position after the restack occurs and +is either +PlaceOnTop +or +PlaceOnBottom. +If it is +PlaceOnTop, +the window is now on top of all siblings. +If it is +PlaceOnBottom, +the window is now below all siblings. + + + +ConfigureNotify Events + + + + + +EventsConfigureNotify +ConfigureNotify +The X server can report +ConfigureNotify +events to clients wanting information about actual changes to a window's +state, such as size, position, border, and stacking order. +The X server generates this event type whenever one of the following configure +window requests made by a client application actually completes: + + + + +A window's size, position, border, and/or stacking order is reconfigured +by calling +XConfigureWindow. + + + + +The window's position in the stacking order is changed by calling +XLowerWindow, +XRaiseWindow, +or +XRestackWindows. + + + + +A window is moved by calling +XMoveWindow. + + + + +A window's size is changed by calling +XResizeWindow. + + + + +A window's size and location is changed by calling +XMoveResizeWindow. + + + + +A window is mapped and its position in the stacking order is changed +by calling +XMapRaised. + + + + +A window's border width is changed by calling +XSetWindowBorderWidth. + + + + + +To receive +ConfigureNotify +events, set the +StructureNotifyMask +bit in the event-mask attribute of the window or the +SubstructureNotifyMask +bit in the event-mask attribute of the parent window +(in which case, configuring any child generates an event). + + + +The structure for this event type contains: + + +XConfigureEvent + + + + +typedef struct { + int type; /* ConfigureNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window event; + Window window; + int x, y; + int width, height; + int border_width; + Window above; + Bool override_redirect; +} XConfigureEvent; + + + + +The event member is set either to the reconfigured window or to its parent, +depending on whether +StructureNotify +or +SubstructureNotify +was selected. +The window member is set to the window whose size, position, +border, and/or stacking +order was changed. + + + +The x and y members are set to the coordinates relative to the parent window's +origin and indicate the position of the upper-left outside corner of the window. +The width and height members are set to the inside size of the window, +not including +the border. +The border_width member is set to the width of the window's border, in pixels. + + + +The above member is set to the sibling window and is used +for stacking operations. +If the X server sets this member to +None, +the window whose state was changed is on the bottom of the stack +with respect to sibling windows. +However, if this member is set to a sibling window, +the window whose state was changed is placed on top of this sibling window. + + + +The override_redirect member is set to the override-redirect attribute of the +window. +Window manager clients normally should ignore this window if the +override_redirect member +is +True. + + + +CreateNotify Events + + + + + +EventsCreateNotify +CreateNotify +The X server can report +CreateNotify +events to clients wanting information about creation of windows. +The X server generates this event whenever a client +application creates a window by calling +XCreateWindow +or +XCreateSimpleWindow. + + + +To receive +CreateNotify +events, set the +SubstructureNotifyMask +bit in the event-mask attribute of the window. +Creating any children then generates an event. + + + +The structure for the event type contains: + + + +XCreateWindowEvent + + + + +typedef struct { + int type; /* CreateNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window parent; /* parent of the window */ + Window window; /* window id of window created */ + int x, y; /* window location */ + int width, height; /* size of window */ + int border_width; /* border width */ + Bool override_redirect; /* creation should be overridden */ +} XCreateWindowEvent; + + + + + +The parent member is set to the created window's parent. +The window member specifies the created window. +The x and y members are set to the created window's coordinates relative +to the parent window's origin and indicate the position of the upper-left +outside corner of the created window. +The width and height members are set to the inside size of the created window +(not including the border) and are always nonzero. +The border_width member is set to the width of the created window's border, in pixels. +The override_redirect member is set to the override-redirect attribute of the +window. +Window manager clients normally should ignore this window +if the override_redirect member is +True. + + + +DestroyNotify Events + + + + + +EventsDestroyNotify +DestroyNotify +The X server can report +DestroyNotify +events to clients wanting information about which windows are destroyed. +The X server generates this event whenever a client application destroys a +window by calling +XDestroyWindow +or +XDestroySubwindows. + + + +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 X protocol does not constrain the ordering among +siblings and across subhierarchies. + + + +To receive +DestroyNotify +events, set the +StructureNotifyMask +bit in the event-mask attribute of the window or the +SubstructureNotifyMask +bit in the event-mask attribute of the parent window +(in which case, destroying any child generates an event). + + + +The structure for this event type contains: + + + +XDestroyWindowEvent + + + + +typedef struct { + int type; /* DestroyNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window event; + Window window; +} XDestroyWindowEvent; + + + + + +The event member is set either to the destroyed window or to its parent, +depending on whether +StructureNotify +or +SubstructureNotify +was selected. +The window member is set to the window that is destroyed. + + + +GravityNotify Events + + + + + +EventsGravityNotify +GravityNotify +The X server can report +GravityNotify +events to clients wanting information about when a window is moved because of a +change in the size of its parent. +The X server generates this event whenever a client +application actually moves a child window as a result of resizing its parent by calling +XConfigureWindow, +XMoveResizeWindow, +or +XResizeWindow. + + + +To receive +GravityNotify +events, set the +StructureNotifyMask +bit in the event-mask attribute of the window or the +SubstructureNotifyMask +bit in the event-mask attribute of the parent window +(in which case, any child that is moved because its parent has been resized +generates an event). + + + +The structure for this event type contains: + + + +XGravityEvent + + + + +typedef struct { + int type; /* GravityNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window event; + Window window; + int x, y; +} XGravityEvent; + + + + + +The event member is set either to the window that was moved or to its parent, +depending on whether +StructureNotify +or +SubstructureNotify +was selected. +The window member is set to the child window that was moved. +The x and y members are set to the coordinates relative to the +new parent window's origin +and indicate the position of the upper-left outside corner of the +window. + + + +MapNotify Events + + + + + +EventsMapNotify +MapNotify +The X server can report +MapNotify +events to clients wanting information about which windows are mapped. +The X server generates this event type whenever a client application changes the +window's state from unmapped to mapped by calling +XMapWindow, +XMapRaised, +XMapSubwindows, +XReparentWindow, +or as a result of save-set processing. + + + +To receive +MapNotify +events, set the +StructureNotifyMask +bit in the event-mask attribute of the window or the +SubstructureNotifyMask +bit in the event-mask attribute of the parent window +(in which case, mapping any child generates an event). + + + +The structure for this event type contains: + + + +XMapEvent + + + + +typedef struct { + int type; /* MapNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window event; + Window window; + Bool override_redirect; /* boolean, is override set... */ +} XMapEvent; + + + + + +The event member is set either to the window that was mapped or to its parent, +depending on whether +StructureNotify +or +SubstructureNotify +was selected. +The window member is set to the window that was mapped. +The override_redirect member is set to the override-redirect attribute +of the window. +Window manager clients normally should ignore this window +if the override-redirect attribute is +True, +because these events usually are generated from pop-ups, +which override structure control. + + + +MappingNotify Events + + + + + +EventsMappingNotify +MappingNotify +The X server reports +MappingNotify +events to all clients. +There is no mechanism to express disinterest in this event. +The X server generates this event type whenever a client application +successfully calls: + + + + +XSetModifierMapping +to indicate which KeyCodes are to be used as modifiers + + + + +XChangeKeyboardMapping +to change the keyboard mapping + + + + +XSetPointerMapping +to set the pointer mapping + + + + + +The structure for this event type contains: + + + +XMappingEvent + + + + +typedef struct { + int type; /* MappingNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; /* unused */ + int request; /* one of MappingModifier, MappingKeyboard, + MappingPointer */ + int first_keycode; /* first keycode */ + int count; /* defines range of change w. first_keycode*/ +} XMappingEvent; + + + + + +The request member is set to indicate the kind of mapping change that occurred +and can be +MappingModifier, +MappingKeyboard, +or +MappingPointer. +If it is +MappingModifier, +the modifier mapping was changed. +If it is +MappingKeyboard, +the keyboard mapping was changed. +If it is +MappingPointer, +the pointer button mapping was changed. +The first_keycode and count members are set only +if the request member was set to +MappingKeyboard. +The number in first_keycode represents the first number in the range +of the altered mapping, +and count represents the number of keycodes altered. + + + +To update the client application's knowledge of the keyboard, +you should call +XRefreshKeyboardMapping. + + + +ReparentNotify Events + + + + + +EventsReparentNotify +ReparentNotify +The X server can report +ReparentNotify +events to clients wanting information about changing a window's parent. +The X server generates this event whenever a client +application calls +XReparentWindow +and the window is actually reparented. + + + +To receive +ReparentNotify +events, set the +StructureNotifyMask +bit in the event-mask attribute of the window or the +SubstructureNotifyMask +bit in the event-mask attribute of either the old or the new parent window +(in which case, reparenting any child generates an event). + + + +The structure for this event type contains: + + + +XReparentEvent + + + + +typedef struct { + int type; /* ReparentNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window event; + Window window; + Window parent; + int x, y; + Bool override_redirect; +} XReparentEvent; + + + + + +The event member is set either to the reparented window +or to the old or the new parent, depending on whether +StructureNotify +or +SubstructureNotify +was selected. +The window member is set to the window that was reparented. +The parent member is set to the new parent window. +The x and y members are set to the reparented window's coordinates relative +to the new parent window's +origin and define the upper-left outer corner of the reparented window. +The override_redirect member is set to the override-redirect attribute of the +window specified by the window member. +Window manager clients normally should ignore this window +if the override_redirect member is +True. + + + +UnmapNotify Events + + + + + +EventsUnmapNotify +UnmapNotify +The X server can report +UnmapNotify +events to clients wanting information about which windows are unmapped. +The X server generates this event type whenever a client application changes the +window's state from mapped to unmapped. + + + +To receive +UnmapNotify +events, set the +StructureNotifyMask +bit in the event-mask attribute of the window or the +SubstructureNotifyMask +bit in the event-mask attribute of the parent window +(in which case, unmapping any child window generates an event). + + + +The structure for this event type contains: + + + +XUnmapEvent + + + + +typedef struct { + int type; /* UnmapNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window event; + Window window; + Bool from_configure; +} XUnmapEvent; + + + + + +The event member is set either to the unmapped window or to its parent, +depending on whether +StructureNotify +or +SubstructureNotify +was selected. +This is the window used by the X server to report the event. +The window member is set to the window that was unmapped. +The from_configure member is set to +True +if the event was generated as a result of a resizing of the window's parent when +the window itself had a win_gravity of +UnmapGravity. + + + +VisibilityNotify Events + + + + + +EventsVisibilityNotify +VisibilityNotify +The X server can report +VisibilityNotify +events to clients wanting any change in the visibility of the specified window. +A region of a window is visible if someone looking at the screen can +actually see it. +The X server generates this event whenever the visibility changes state. +However, this event is never generated for windows whose class is +InputOnly. + + + +All +VisibilityNotify +events caused by a hierarchy change are generated +after any hierarchy event +(UnmapNotify, +MapNotify, +ConfigureNotify, +GravityNotify, +CirculateNotify) +caused by that change. 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 X protocol does not constrain the ordering of +VisibilityNotify +events with +respect to +FocusOut, +EnterNotify, +and +LeaveNotify +events. + + + +To receive +VisibilityNotify +events, set the +VisibilityChangeMask +bit in the event-mask attribute of the window. + + + +The structure for this event type contains: + + + +XVisibilityEvent + + + + +typedef struct { + int type; /* VisibilityNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + int state; +} XVisibilityEvent; + + + + + +The window member is set to the window whose visibility state changes. +The state member is set to the state of the window's visibility and can be +VisibilityUnobscured, +VisibilityPartiallyObscured, +or +VisibilityFullyObscured. +The X server ignores all of a window's subwindows +when determining the visibility state of the window and processes +VisibilityNotify +events according to the following: + + + + +When the window changes state from partially obscured, fully obscured, +or not viewable to viewable and completely unobscured, +the X server generates the event with the state member of the +XVisibilityEvent +structure set to +VisibilityUnobscured. + + + + +When the window changes state from viewable and completely unobscured or +not viewable to viewable and partially obscured, +the X server generates the event with the state member of the +XVisibilityEvent +structure set to +VisibilityPartiallyObscured. + + + + +When the window changes state from viewable and completely unobscured, +viewable and partially obscured, or not viewable to viewable and +fully obscured, +the X server generates the event with the state member of the +XVisibilityEvent +structure set to +VisibilityFullyObscured. + + + + + + +Structure Control Events + + + + + +This section discusses: + + + + +CirculateRequest +events + + + + +ConfigureRequest +events + + + + +MapRequest +events + + + + +ResizeRequest +events + + + + +CirculateRequest Events + + + + + +EventsCirculateRequest +CirculateRequest +The X server can report +CirculateRequest +events to clients wanting information about +when another client initiates a circulate window request +on a specified window. +The X server generates this event type whenever a client initiates a circulate +window request on a window and a subwindow actually needs to be restacked. +The client initiates a circulate window request on the window by calling +XCirculateSubwindows, +XCirculateSubwindowsUp, +or +XCirculateSubwindowsDown. + + + +To receive +CirculateRequest +events, set the +SubstructureRedirectMask +in the event-mask attribute of the window. +Then, in the future, +the circulate window request for the specified window is not executed, +and thus, any subwindow's position in the stack is not changed. +For example, suppose a client application calls +XCirculateSubwindowsUp +to raise a subwindow to the top of the stack. +If you had selected +SubstructureRedirectMask +on the window, the X server reports to you a +CirculateRequest +event and does not raise the subwindow to the top of the stack. + + + +The structure for this event type contains: + + + +XCirculateRequestEvent + + + + +typedef struct { + int type; /* CirculateRequest */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window parent; + Window window; + int place; /* PlaceOnTop, PlaceOnBottom */ +} XCirculateRequestEvent; + + + + + +The parent member is set to the parent window. +The window member is set to the subwindow to be restacked. +The place member is set to what the new position in the stacking order should be +and is either +PlaceOnTop +or +PlaceOnBottom. +If it is +PlaceOnTop, +the subwindow should be on top of all siblings. +If it is +PlaceOnBottom, +the subwindow should be below all siblings. + + + +ConfigureRequest Events + + + + + +EventsConfigureRequest +ConfigureRequest +The X server can report +ConfigureRequest +events to clients wanting information about when a different client initiates +a configure window request on any child of a specified window. +The configure window request attempts to +reconfigure a window's size, position, border, and stacking order. +The X server generates this event whenever a different client initiates +a configure window request on a window by calling +XConfigureWindow, +XLowerWindow, +XRaiseWindow, +XMapRaised, +XMoveResizeWindow, +XMoveWindow, +XResizeWindow, +XRestackWindows, +or +XSetWindowBorderWidth. + + + +To receive +ConfigureRequest +events, set the +SubstructureRedirectMask +bit in the event-mask attribute of the window. +ConfigureRequest +events are generated when a +ConfigureWindow +protocol request is issued on a child window by another client. +For example, suppose a client application calls +XLowerWindow +to lower a window. +If you had selected +SubstructureRedirectMask +on the parent window and if the override-redirect attribute +of the window is set to +False, +the X server reports a +ConfigureRequest +event to you and does not lower the specified window. + + + +The structure for this event type contains: + + + +XConfigureRequestEvent + + + + +typedef struct { + int type; /* ConfigureRequest */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window parent; + Window window; + int x, y; + int width, height; + int border_width; + Window above; + int detail; /* Above, Below, TopIf, BottomIf, Opposite */ + unsigned long value_mask; +} XConfigureRequestEvent; + + + + + +The parent member is set to the parent window. +The window member is set to the window whose size, position, border width, +and/or stacking order is to be reconfigured. +The value_mask member indicates which components were specified in the +ConfigureWindow +protocol request. +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 above (sibling) and detail (stack-mode), +which are reported as +None +and +Above, +respectively, if they are not given in the request. + + + +MapRequest Events + + + + + +EventsMapRequest +MapRequest +The X server can report +MapRequest +events to clients wanting information about a different client's desire +to map windows. +A window is considered mapped when a map window request completes. +The X server generates this event whenever a different client initiates +a map window request on an unmapped window whose override_redirect member +is set to +False. +Clients initiate map window requests by calling +XMapWindow, +XMapRaised, +or +XMapSubwindows. + + + +To receive +MapRequest +events, set the +SubstructureRedirectMask +bit in the event-mask attribute of the window. +This means another client's attempts to map a child window by calling one of +the map window request functions is intercepted, and you are sent a +MapRequest +instead. +For example, suppose a client application calls +XMapWindow +to map a window. +If you (usually a window manager) had selected +SubstructureRedirectMask +on the parent window and if the override-redirect attribute +of the window is set to +False, +the X server reports a +MapRequest +event to you +and does not map the specified window. +Thus, this event gives your window manager client the ability +to control the placement of subwindows. + + + +The structure for this event type contains: + + + +XMapRequestEvent + + + + +typedef struct { + int type; /* MapRequest */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window parent; + Window window; +} XMapRequestEvent; + + + + + +The parent member is set to the parent window. +The window member is set to the window to be mapped. + + + +ResizeRequest Events + + + + + +EventsResizeRequest +ResizeRequest +The X server can report +ResizeRequest +events to clients wanting information about another client's attempts to change the +size of a window. +The X server generates this event whenever some other client attempts to change +the size of the specified window by calling +XConfigureWindow, +XResizeWindow, +or +XMoveResizeWindow. + + + +To receive +ResizeRequest +events, set the +ResizeRedirect +bit in the event-mask attribute of the window. +Any attempts to change the size by other clients are then redirected. + + + +The structure for this event type contains: + + + +XResizeRequestEvent + + + + +typedef struct { + int type; /* ResizeRequest */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + int width, height; +} XResizeRequestEvent; + + + + + +The window member is set to the window whose size another +client attempted to change. +The width and height members are set to the inside size of the window, +excluding the border. + + + + +Colormap State Change Events + + + + + +EventsColormapNotify +ColormapNotify +The X server can report +ColormapNotify +events to clients wanting information about when the colormap changes +and when a colormap is installed or uninstalled. +The X server generates this event type whenever a client application: + + + + +Changes the colormap member of the +XSetWindowAttributes +structure by +calling +XChangeWindowAttributes, +XFreeColormap, +or +XSetWindowColormap + + + + +Installs or uninstalls the colormap by calling +XInstallColormap +or +XUninstallColormap + + + + + +To receive +ColormapNotify +events, set the +ColormapChangeMask +bit in the event-mask attribute of the window. + + + +The structure for this event type contains: + + + +XColormapEvent + + + + +typedef struct { + int type; /* ColormapNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + Colormap colormap; /* colormap or None */ + Bool new; + int state; /* ColormapInstalled, ColormapUninstalled */ +} XColormapEvent; + + + + + +The window member is set to the window whose associated +colormap is changed, installed, or uninstalled. +For a colormap that is changed, installed, or uninstalled, +the colormap member is set to the colormap associated with the window. +For a colormap that is changed by a call to +XFreeColormap, +the colormap member is set to +None. +The new member is set to indicate whether the colormap +for the specified window was changed or installed or uninstalled +and can be +True +or +False. +If it is +True, +the colormap was changed. +If it is +False, +the colormap was installed or uninstalled. +The state member is always set to indicate whether the colormap is installed or +uninstalled and can be +ColormapInstalled +or +ColormapUninstalled. + + + +Client Communication Events + + + + + +This section discusses: + + + + +ClientMessage +events + + + + +PropertyNotify +events + + + + +SelectionClear +events + + + + +SelectionNotify +events + + + + +SelectionRequest +events + + + + +ClientMessage Events + + + + + +EventsClientMessage +ClientMessage +The X server generates +ClientMessage +events only when a client calls the function +XSendEvent. + + + +The structure for this event type contains: + + + +XClientMessageEvent + + + + +typedef struct { + int type; /* ClientMessage */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + Atom message_type; + int format; + union { + char b[20]; + short s[10]; + long l[5]; + } data; +} XClientMessageEvent; + + + + + +The message_type member is set to an atom that indicates how the data +should be interpreted by the receiving client. +The format member is set to 8, 16, or 32 and specifies whether the data +should be viewed as a list of bytes, shorts, or longs. +The data member is a union that contains the members b, s, and l. +The b, s, and l members represent data of twenty 8-bit values, +ten 16-bit values, and five 32-bit values. +Particular message types might not make use of all these values. +The X server places no interpretation on the values in the window, +message_type, or data members. + + + +PropertyNotify Events + + + + + +EventsPropertyNotify +PropertyNotify +The X server can report +PropertyNotify +events to clients wanting information about property changes +for a specified window. + + + +To receive +PropertyNotify +events, set the +PropertyChangeMask +bit in the event-mask attribute of the window. + + + +The structure for this event type contains: + + + +XPropertyEvent + + + + +typedef struct { + int type; /* PropertyNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + Atom atom; + Time time; + int state; /* PropertyNewValue or PropertyDelete */ +} XPropertyEvent; + + + + + +The window member is set to the window whose associated +property was changed. +The atom member is set to the property's atom and indicates which +property was changed or desired. +The time member is set to the server time when the property was changed. +The state member is set to indicate whether the property was changed +to a new value or deleted and can be +PropertyNewValue +or +PropertyDelete. +The state member is set to +PropertyNewValue +when a property of the window is changed using +XChangeProperty +or +XRotateWindowProperties +(even when adding zero-length data using +XChangeProperty) +and when replacing all or part of a property with identical data using +XChangeProperty +or +XRotateWindowProperties. +The state member is set to +PropertyDelete +when a property of the window is deleted using +XDeleteProperty +or, if the delete argument is +True, +XGetWindowProperty. + + + +SelectionClear Events + + + + + +EventsSelectionClear +SelectionClear +The X server reports +SelectionClear +events to the client losing ownership of a selection. +The X server generates this event type when another client +asserts ownership of the selection by calling +XSetSelectionOwner. + + + +The structure for this event type contains: + + + +XSelectionClearEvent + + + + +typedef struct { + int type; /* SelectionClear */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window window; + Atom selection; + Time time; +} XSelectionClearEvent; + + + + + +The selection member is set to the selection atom. +The time member is set to the last change time recorded for the +selection. +The window member is the window that was specified by the current owner +(the owner losing the selection) in its +XSetSelectionOwner +call. + + + +SelectionRequest Events + + + + + +EventsSelectionRequest +SelectionRequest +The X server reports +SelectionRequest +events to the owner of a selection. +The X server generates this event whenever a client +requests a selection conversion by calling +XConvertSelection +for the owned selection. + + + +The structure for this event type contains: + + + +XSelectionRequestEvent + + + + +typedef struct { + int type; /* SelectionRequest */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window owner; + Window requestor; + Atom selection; + Atom target; + Atom property; + Time time; +} XSelectionRequestEvent; + + + + + +The owner member is set to the window +that was specified by the current owner in its +XSetSelectionOwner +call. +The requestor member is set to the window requesting the selection. +The selection member is set to the atom that names the selection. +For example, PRIMARY is used to indicate the primary selection. +The target member is set to the atom that indicates the type +the selection is desired in. +The property member can be a property name or +None. +The time member is set to the timestamp or +CurrentTime +value from the +ConvertSelection +request. + + + +The owner should convert the selection based on the specified target type +and send a +SelectionNotify +event back to the requestor. +A complete specification for using selections is given in the X Consortium +standard Inter-Client Communication Conventions Manual. + + + +SelectionNotify Events + + + + + +EventsSelectionNotify +SelectionNotify +This event is generated by the X server in response to a +ConvertSelection +protocol request when there is no owner for the selection. +When there is an owner, it should be generated by the owner +of the selection by using +XSendEvent. +The owner of a selection should send this event to a requestor when a selection +has been converted and stored as a property +or when a selection conversion could +not be performed (which is indicated by setting the property member to +None). + + + +If +None +is specified as the property in the +ConvertSelection +protocol request, the owner should choose a property name, +store the result as that property on the requestor window, +and then send a +SelectionNotify +giving that actual property name. + + + +The structure for this event type contains: + + + +XSelectionEvent + + + + +typedef struct { + int type; /* SelectionNotify */ + unsigned long serial; /* # of last request processed by server */ + Bool send_event; /* true if this came from a SendEvent request */ + Display *display; /* Display the event was read from */ + Window requestor; + Atom selection; + Atom target; + Atom property; /* atom or None */ + Time time; +} XSelectionEvent; + + + + + +The requestor member is set to the window associated with +the requestor of the selection. +The selection member is set to the atom that indicates the selection. +For example, PRIMARY is used for the primary selection. +The target member is set to the atom that indicates the converted type. +For example, PIXMAP is used for a pixmap. +The property member is set to the atom that indicates which +property the result was stored on. +If the conversion failed, +the property member is set to +None. +The time member is set to the time the conversion took place and +can be a timestamp or +CurrentTime. + + + + + + + diff --git a/libX11/specs/libX11/CH11.xml b/libX11/specs/libX11/CH11.xml index df8a9630a..3fe6f23de 100644 --- a/libX11/specs/libX11/CH11.xml +++ b/libX11/specs/libX11/CH11.xml @@ -273,7 +273,8 @@ and processed by the X server. Any errors generated must be handled by the error handler. For each protocol error received by Xlib, XSync -calls the client application's error handling routine (see section 11.8.2). +calls the client application's error handling routine +(see section 11.8.2). Any events generated by the server are enqueued into the library's event queue. @@ -1512,7 +1513,7 @@ determines which clients should receive the specified events, and ignores any active grabs. This function requires you to pass an event mask. For a discussion of the valid event mask names, -see section 10.3. +see section 10.3. This function uses the w argument to identify the destination window as follows: @@ -2029,7 +2030,7 @@ It is the number that was the value of immediately before the failing call was made. The request_code member is a protocol request of the procedure that failed, as defined in -< X11/Xproto.h .> +<X11/Xproto.h>. The following error codes can be returned by the functions described in this chapter: diff --git a/libX11/specs/libX11/CH13.xml b/libX11/specs/libX11/CH13.xml index 4219fa981..37121ba47 100644 --- a/libX11/specs/libX11/CH13.xml +++ b/libX11/specs/libX11/CH13.xml @@ -3520,7 +3520,8 @@ and except that they work with font sets instead of single fonts and interpret the text based on the locale of the font set instead of treating the bytes of the string as direct font indexes. -See section 8.6 for details of the use of Graphics Contexts (GCs) +See section 8.6 for details +of the use of Graphics Contexts (GCs) and possible protocol errors. If a BadFont @@ -4553,7 +4554,7 @@ is being used to do input for multiple text entry areas, it will also be necessary to set the focus window of the input context whenever the focus window changes -(see section 13.5.6.3). +(see section 13.5.6.3). @@ -4671,7 +4672,8 @@ may change the geometry desired by the input method. -The table of XIC values (see section 13.5.6) +The table of XIC values +(see section 13.5.6) indicates the values that can cause the desired geometry to change when they are set. It is the responsibility of the client to renegotiate the geometry @@ -5857,7 +5859,8 @@ The following keys apply to this table. XNR6PreeditCallback -is obsolete and its use is not recommended (see section 13.5.4.6). +is obsolete and its use is not recommended +(see section 13.5.4.6). @@ -7506,7 +7509,7 @@ The XNGeometryCallback argument is a structure of type XIMCallback -(see section 13.5.6.13.12). +(see section 13.5.6.13.12). @@ -7561,7 +7564,8 @@ The XNDestroyCallback argument is a pointer to a structure of type XIMCallback -(see section 13.5.6.13.12). This callback is triggered when the input method +(see section 13.5.6.13.12). +This callback is triggered when the input method stops its service for any reason; for example, when a connection to an IM server is broken. After the destroy callback is called, the input context is destroyed and the input method is closed. @@ -7585,7 +7589,7 @@ The XNStringConversionCallback argument is a structure of type XIMCallback -(see section 13.5.6.13.12). +(see section 13.5.6.13.12). @@ -8034,7 +8038,7 @@ or XIMStatusArea. It is used for geometry negotiation between the client and the input method and has no other effect on the input method -(see section 13.5.1.5). +(see section 13.5.1.5). @@ -8783,7 +8787,8 @@ The callback is passed an structure in the call_data argument. The text member is an XIMStringConversionText -structure (see section 13.5.6.9) to be filled in by the client +structure (see section 13.5.6.9) +to be filled in by the client and describes the text to be sent to the input method. The data pointed to by the string and feedback elements of the @@ -10285,7 +10290,7 @@ called back the client and obtained no response The following symbols for string constants are defined in -<X11/Xlib.h> . +<X11/Xlib.h>. Although they are shown here with particular macro definitions, they may be implemented as macros, as global symbols, or as a mixture of the two. The string pointer value itself diff --git a/libX11/specs/libX11/CH14.xml b/libX11/specs/libX11/CH14.xml index d0eb36f10..b64830667 100644 --- a/libX11/specs/libX11/CH14.xml +++ b/libX11/specs/libX11/CH14.xml @@ -14,11 +14,14 @@ see the Inter-Client Communication Conventions Manual. Xlib provides a number of standard properties and programming interfaces that are ICCCM compliant. The predefined atoms for some of these properties are defined in the <X11/Xatom.h> header file, where to avoid name conflicts with user symbols their #define name has an XA_ prefix. -For further information about atoms and properties, see section 4.3. +For further information about atoms and properties, +see section 4.3. Xlib’s selection and cut buffer mechanisms provide the primary programming interfaces by which -peer client applications communicate with each other (see sections 4.5 and 16.6). The functions +peer client applications communicate with each other +(see sections 4.5 and +16.6). The functions discussed in this chapter provide the primary programming interfaces by which client applications communicate with their window and session managers as well as share standard colormaps. @@ -248,7 +251,8 @@ of top-level windows (that is, those that were created as children of the root window). Note that the subwindows that you create are ignored by window managers. Therefore, -you should use the basic window functions described in chapter 3 +you should use the basic window functions described in +chapter 3 to manipulate your application's subwindows. @@ -1179,7 +1183,12 @@ In addition, Xlib provides separate convenience functions that you can use to set each of these properties. For further information about these convenience functions, -see sections 14.1.4, 14.1.5, 14.2.1, and 14.2.2, respectively. +see sections +14.1.4, +14.1.5, +14.2.1, and +14.2.2, +respectively. @@ -3926,12 +3935,14 @@ If the normal_hints argument is non-NULL, XmbSetWMProperties calls XSetWMNormalHints, -which sets the WM_NORMAL_HINTS property (see section 14.1.7). +which sets the WM_NORMAL_HINTS property +(see section 14.1.7). If the wm_hints argument is non-NULL, XmbSetWMProperties calls XSetWMHints, -which sets the WM_HINTS property (see section 14.1.6). +which sets the WM_HINTS property +(see section 14.1.6). @@ -3944,7 +3955,7 @@ An argc of zero indicates a zero-length command. The hostname of the machine is stored using XSetWMClientMachine -(see section 14.2.2). +(see section 14.2.2). @@ -4129,21 +4140,24 @@ If the window_name argument is non-NULL, XSetWMProperties calls XSetWMName, -which, in turn, sets the WM_NAME property (see section 14.1.4). +which, in turn, sets the WM_NAME property +(see section 14.1.4). If the icon_name argument is non-NULL, XSetWMProperties calls XSetWMIconName, -which sets the WM_ICON_NAME property (see section 14.1.5). +which sets the WM_ICON_NAME property +(see section 14.1.5). If the argv argument is non-NULL, XSetWMProperties calls XSetCommand, -which sets the WM_COMMAND property (see section 14.2.1). +which sets the WM_COMMAND property +(see section 14.2.1). Note that an argc of zero is allowed to indicate a zero-length command. Note also that the hostname of this machine is stored using XSetWMClientMachine -(see section 14.2.2). +(see section 14.2.2). @@ -4151,12 +4165,14 @@ If the normal_hints argument is non-NULL, XSetWMProperties calls XSetWMNormalHints, -which sets the WM_NORMAL_HINTS property (see section 14.1.7). +which sets the WM_NORMAL_HINTS property +(see section 14.1.7). If the wm_hints argument is non-NULL, XSetWMProperties calls XSetWMHints, -which sets the WM_HINTS property (see section 14.1.6). +which sets the WM_HINTS property +(see section 14.1.6). @@ -4164,7 +4180,8 @@ If the class_hints argument is non-NULL, XSetWMProperties calls XSetClassHint, -which sets the WM_CLASS property (see section 14.1.8). +which sets the WM_CLASS property +(see section 14.1.8). If the res_name member in the XClassHint structure is set to the NULL pointer and the RESOURCE_NAME environment diff --git a/libX11/specs/libX11/CH15.xml b/libX11/specs/libX11/CH15.xml index 7abc6173e..760adcfe5 100644 --- a/libX11/specs/libX11/CH15.xml +++ b/libX11/specs/libX11/CH15.xml @@ -566,7 +566,7 @@ The function converts the null-terminated string (generally a fully qualified name) to a list of quarks. Note that the string must be in the valid ResourceName format -(see section 15.1). +(see section 15.1). If the string is not in the Host Portable Character Encoding, the conversion is implementation-dependent. @@ -650,7 +650,8 @@ The caller must allocate sufficient space for the quarks list before calling Component names in the list are separated by a period or an asterisk character. -The string must be in the format of a valid ResourceName (see section 15.1). +The string must be in the format of a valid ResourceName +(see section 15.1). If the string does not start with a period or an asterisk, a tight binding is assumed. For example, the string ``*a.b*c'' becomes: @@ -752,7 +753,8 @@ function opens the specified file, creates a new resource database, and loads it with the specifications read in from the specified file. The specified file should contain a sequence of entries in valid ResourceLine -format (see section 15.1); the database that results from reading a file +format (see section 15.1); +the database that results from reading a file with incorrect syntax is implementation-dependent. The file is parsed in the current locale, and the database is created in the current locale. @@ -805,7 +807,8 @@ The XrmPutFileDatabase function stores a copy of the specified database in the specified file. Text is written to the file as a sequence of entries in valid -ResourceLine format (see section 15.1). +ResourceLine format +(see section 15.1). The file is written in the locale of the database. Entries containing resource names that are not in the Host Portable Character Encoding or containing values that are not in the encoding of the database @@ -940,7 +943,8 @@ is similar to XrmGetFileDatabase except that it reads the information out of a string instead of out of a file. The string should contain a sequence of entries in valid ResourceLine -format (see section 15.1) terminated by a null character; +format (see section 15.1) +terminated by a null character; the database that results from using a string with incorrect syntax is implementation-dependent. The string is parsed in the current locale, @@ -2077,7 +2081,8 @@ If database contains NULL, creates a new database and returns a pointer to it. XrmPutLineResource adds a single resource entry to the specified database. -The line should be in valid ResourceLine format (see section 15.1) +The line should be in valid ResourceLine format +(see section 15.1) terminated by a newline or null character; the database that results from using a string with incorrect syntax is implementation-dependent. diff --git a/libX11/specs/libX11/CH16.xml b/libX11/specs/libX11/CH16.xml index db42bb170..fecbb2f49 100644 --- a/libX11/specs/libX11/CH16.xml +++ b/libX11/specs/libX11/CH16.xml @@ -655,7 +655,8 @@ if the specified KeySym is a PF key. -Chapter 13 describes internationalized text input facilities, +Chapter 13 +describes internationalized text input facilities, but sometimes it is expedient to write an application that only deals with Latin-1 characters and ASCII controls, so Xlib provides a simple function for that purpose. @@ -2132,7 +2133,8 @@ if the rectangle is partially in the specified region. Xlib provides functions to manipulate cut buffers, a very simple form of cut-and-paste inter-client communication. Selections are a much more powerful and useful mechanism for -interchanging data between clients (see section 4.5) +interchanging data between client +(see section 4.5) and generally should be used instead of cut buffers. @@ -2736,7 +2738,7 @@ plane n must be located at the address (data + (n * height * bytes_per_line)). For a description of the XImage structure, -see section 8.7. +see section 8.7. diff --git a/mesalib/Makefile b/mesalib/Makefile index f3c0a20a3..e77e64925 100644 --- a/mesalib/Makefile +++ b/mesalib/Makefile @@ -230,6 +230,7 @@ MAIN_FILES = \ $(DIRECTORY)/include/GL/vms_x_fix.h \ $(DIRECTORY)/include/GL/wglext.h \ $(DIRECTORY)/include/GL/wmesa.h \ + $(DIRECTORY)/include/pci_ids/*.h \ $(DIRECTORY)/src/getopt/SConscript \ $(DIRECTORY)/src/getopt/getopt*.[ch] \ $(DIRECTORY)/src/glsl/Makefile \ diff --git a/mesalib/configs/darwin b/mesalib/configs/darwin index 3cf1110b4..9d3bbcf98 100644 --- a/mesalib/configs/darwin +++ b/mesalib/configs/darwin @@ -44,10 +44,10 @@ GLU_LIB_GLOB = lib$(GLU_LIB).*dylib GLUT_LIB_GLOB = lib$(GLUT_LIB).*dylib GLW_LIB_GLOB = lib$(GLW_LIB).*dylib OSMESA_LIB_GLOB = lib$(OSMESA_LIB).*dylib -VG_LIB_GLOB = lib$(VG_LIB).*.dylib +VG_LIB_GLOB = lib$(VG_LIB).*dylib GL_LIB_DEPS = -L$(INSTALL_DIR)/$(LIB_DIR) -L$(X11_DIR)/$(LIB_DIR) -lX11 -lXext -lm -lpthread -OSMESA_LIB_DEPS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) +OSMESA_LIB_DEPS = GLU_LIB_DEPS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) GLUT_LIB_DEPS = -L$(TOP)/$(LIB_DIR) -l$(GLU_LIB) -l$(GL_LIB) -L$(INSTALL_DIR)/$(LIB_DIR) -L$(X11_DIR)/$(LIB_DIR) -lX11 -lXmu -lXi -lXext GLW_LIB_DEPS = -L$(TOP)/$(LIB_DIR) -l$(GL_LIB) -L$(INSTALL_DIR)/$(LIB_DIR) -L$(X11_DIR)/$(LIB_DIR) -lX11 -lXt diff --git a/mesalib/src/mesa/main/fbobject.c b/mesalib/src/mesa/main/fbobject.c index d4400709a..2230b2623 100644 --- a/mesalib/src/mesa/main/fbobject.c +++ b/mesalib/src/mesa/main/fbobject.c @@ -2429,6 +2429,17 @@ _mesa_BlitFramebufferEXT(GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1, if (mask & GL_COLOR_BUFFER_BIT) { colorReadRb = readFb->_ColorReadBuffer; colorDrawRb = drawFb->_ColorDrawBuffers[0]; + + /* From the EXT_framebuffer_object spec: + * + * "If a buffer is specified in and does not exist in both + * the read and draw framebuffers, the corresponding bit is silently + * ignored." + */ + if ((colorReadRb == NULL) || (colorDrawRb == NULL)) { + colorReadRb = colorDrawRb = NULL; + mask &= ~GL_COLOR_BUFFER_BIT; + } } else { colorReadRb = colorDrawRb = NULL; @@ -2437,10 +2448,19 @@ _mesa_BlitFramebufferEXT(GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1, if (mask & GL_STENCIL_BUFFER_BIT) { struct gl_renderbuffer *readRb = readFb->_StencilBuffer; struct gl_renderbuffer *drawRb = drawFb->_StencilBuffer; - if (!readRb || - !drawRb || - _mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) != - _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)) { + + /* From the EXT_framebuffer_object spec: + * + * "If a buffer is specified in and does not exist in both + * the read and draw framebuffers, the corresponding bit is silently + * ignored." + */ + if ((readRb == NULL) || (drawRb == NULL)) { + readRb = drawRb = NULL; + mask &= ~GL_STENCIL_BUFFER_BIT; + } + else if (_mesa_get_format_bits(readRb->Format, GL_STENCIL_BITS) != + _mesa_get_format_bits(drawRb->Format, GL_STENCIL_BITS)) { _mesa_error(ctx, GL_INVALID_OPERATION, "glBlitFramebufferEXT(stencil buffer size mismatch)"); return; @@ -2450,10 +2470,19 @@ _mesa_BlitFramebufferEXT(GLint srcX0, GLint srcY0, GLint srcX1, GLint srcY1, if (mask & GL_DEPTH_BUFFER_BIT) { struct gl_renderbuffer *readRb = readFb->_DepthBuffer; struct gl_renderbuffer *drawRb = drawFb->_DepthBuffer; - if (!readRb || - !drawRb || - _mesa_get_format_bits(readRb->Format, GL_DEPTH_BITS) != - _mesa_get_format_bits(drawRb->Format, GL_DEPTH_BITS)) { + + /* From the EXT_framebuffer_object spec: + * + * "If a buffer is specified in and does not exist in both + * the read and draw framebuffers, the corresponding bit is silently + * ignored." + */ + if ((readRb == NULL) || (drawRb == NULL)) { + readRb = drawRb = NULL; + mask &= ~GL_DEPTH_BUFFER_BIT; + } + else if (_mesa_get_format_bits(readRb->Format, GL_DEPTH_BITS) != + _mesa_get_format_bits(drawRb->Format, GL_DEPTH_BITS)) { _mesa_error(ctx, GL_INVALID_OPERATION, "glBlitFramebufferEXT(depth buffer size mismatch)"); return; diff --git a/mesalib/src/mesa/swrast/s_clear.c b/mesalib/src/mesa/swrast/s_clear.c index fac092f1e..9e9b53116 100644 --- a/mesalib/src/mesa/swrast/s_clear.c +++ b/mesalib/src/mesa/swrast/s_clear.c @@ -1,230 +1,238 @@ -/* - * Mesa 3-D graphics library - * Version: 7.1 - * - * Copyright (C) 1999-2008 Brian Paul All Rights Reserved. - * - * 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 - * BRIAN PAUL 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. - */ - -#include "main/glheader.h" -#include "main/colormac.h" -#include "main/condrender.h" -#include "main/macros.h" -#include "main/imports.h" -#include "main/mtypes.h" - -#include "s_accum.h" -#include "s_context.h" -#include "s_depth.h" -#include "s_masking.h" -#include "s_stencil.h" - - -/** - * Clear the color buffer when glColorMask is in effect. - */ -static void -clear_rgba_buffer_with_masking(struct gl_context *ctx, struct gl_renderbuffer *rb, - GLuint buf) -{ - const GLint x = ctx->DrawBuffer->_Xmin; - const GLint y = ctx->DrawBuffer->_Ymin; - const GLint height = ctx->DrawBuffer->_Ymax - ctx->DrawBuffer->_Ymin; - const GLint width = ctx->DrawBuffer->_Xmax - ctx->DrawBuffer->_Xmin; - SWspan span; - GLint i; - - ASSERT(rb->PutRow); - - /* Initialize color span with clear color */ - /* XXX optimize for clearcolor == black/zero (bzero) */ - INIT_SPAN(span, GL_BITMAP); - span.end = width; - span.arrayMask = SPAN_RGBA; - span.array->ChanType = rb->DataType; - if (span.array->ChanType == GL_UNSIGNED_BYTE) { - GLubyte clearColor[4]; - UNCLAMPED_FLOAT_TO_UBYTE(clearColor[RCOMP], ctx->Color.ClearColor[0]); - UNCLAMPED_FLOAT_TO_UBYTE(clearColor[GCOMP], ctx->Color.ClearColor[1]); - UNCLAMPED_FLOAT_TO_UBYTE(clearColor[BCOMP], ctx->Color.ClearColor[2]); - UNCLAMPED_FLOAT_TO_UBYTE(clearColor[ACOMP], ctx->Color.ClearColor[3]); - for (i = 0; i < width; i++) { - COPY_4UBV(span.array->rgba[i], clearColor); - } - } - else if (span.array->ChanType == GL_UNSIGNED_SHORT) { - GLushort clearColor[4]; - UNCLAMPED_FLOAT_TO_USHORT(clearColor[RCOMP], ctx->Color.ClearColor[0]); - UNCLAMPED_FLOAT_TO_USHORT(clearColor[GCOMP], ctx->Color.ClearColor[1]); - UNCLAMPED_FLOAT_TO_USHORT(clearColor[BCOMP], ctx->Color.ClearColor[2]); - UNCLAMPED_FLOAT_TO_USHORT(clearColor[ACOMP], ctx->Color.ClearColor[3]); - for (i = 0; i < width; i++) { - COPY_4V_CAST(span.array->rgba[i], clearColor, GLchan); - } - } - else { - ASSERT(span.array->ChanType == GL_FLOAT); - for (i = 0; i < width; i++) { - CLAMPED_FLOAT_TO_CHAN(span.array->rgba[i][0], ctx->Color.ClearColor[0]); - CLAMPED_FLOAT_TO_CHAN(span.array->rgba[i][1], ctx->Color.ClearColor[1]); - CLAMPED_FLOAT_TO_CHAN(span.array->rgba[i][2], ctx->Color.ClearColor[2]); - CLAMPED_FLOAT_TO_CHAN(span.array->rgba[i][3], ctx->Color.ClearColor[3]); - } - } - - /* Note that masking will change the color values, but only the - * channels for which the write mask is GL_FALSE. The channels - * which which are write-enabled won't get modified. - */ - for (i = 0; i < height; i++) { - span.x = x; - span.y = y + i; - _swrast_mask_rgba_span(ctx, rb, &span, buf); - /* write masked row */ - rb->PutRow(ctx, rb, width, x, y + i, span.array->rgba, NULL); - } -} - - -/** - * Clear an rgba color buffer without channel masking. - */ -static void -clear_rgba_buffer(struct gl_context *ctx, struct gl_renderbuffer *rb, GLuint buf) -{ - const GLint x = ctx->DrawBuffer->_Xmin; - const GLint y = ctx->DrawBuffer->_Ymin; - const GLint height = ctx->DrawBuffer->_Ymax - ctx->DrawBuffer->_Ymin; - const GLint width = ctx->DrawBuffer->_Xmax - ctx->DrawBuffer->_Xmin; - GLubyte clear8[4]; - GLushort clear16[4]; - GLvoid *clearVal; - GLint i; - - ASSERT(ctx->Color.ColorMask[buf][0] && - ctx->Color.ColorMask[buf][1] && - ctx->Color.ColorMask[buf][2] && - ctx->Color.ColorMask[buf][3]); - - ASSERT(rb->PutMonoRow); - - switch (rb->DataType) { - case GL_UNSIGNED_BYTE: - UNCLAMPED_FLOAT_TO_UBYTE(clear8[0], ctx->Color.ClearColor[0]); - UNCLAMPED_FLOAT_TO_UBYTE(clear8[1], ctx->Color.ClearColor[1]); - UNCLAMPED_FLOAT_TO_UBYTE(clear8[2], ctx->Color.ClearColor[2]); - UNCLAMPED_FLOAT_TO_UBYTE(clear8[3], ctx->Color.ClearColor[3]); - clearVal = clear8; - break; - case GL_UNSIGNED_SHORT: - UNCLAMPED_FLOAT_TO_USHORT(clear16[0], ctx->Color.ClearColor[0]); - UNCLAMPED_FLOAT_TO_USHORT(clear16[1], ctx->Color.ClearColor[1]); - UNCLAMPED_FLOAT_TO_USHORT(clear16[2], ctx->Color.ClearColor[2]); - UNCLAMPED_FLOAT_TO_USHORT(clear16[3], ctx->Color.ClearColor[3]); - clearVal = clear16; - break; - case GL_FLOAT: - clearVal = ctx->Color.ClearColor; - break; - default: - _mesa_problem(ctx, "Bad rb DataType in clear_color_buffer"); - return; - } - - for (i = 0; i < height; i++) { - rb->PutMonoRow(ctx, rb, width, x, y + i, clearVal, NULL); - } -} - - -/** - * Clear the front/back/left/right/aux color buffers. - * This function is usually only called if the device driver can't - * clear its own color buffers for some reason (such as with masking). - */ -static void -clear_color_buffers(struct gl_context *ctx) -{ - GLuint buf; - - for (buf = 0; buf < ctx->DrawBuffer->_NumColorDrawBuffers; buf++) { - struct gl_renderbuffer *rb = ctx->DrawBuffer->_ColorDrawBuffers[buf]; - if (ctx->Color.ColorMask[buf][0] == 0 || - ctx->Color.ColorMask[buf][1] == 0 || - ctx->Color.ColorMask[buf][2] == 0 || - ctx->Color.ColorMask[buf][3] == 0) { - clear_rgba_buffer_with_masking(ctx, rb, buf); - } - else { - clear_rgba_buffer(ctx, rb, buf); - } - } -} - - -/** - * Called via the device driver's ctx->Driver.Clear() function if the - * device driver can't clear one or more of the buffers itself. - * \param buffers bitfield of BUFFER_BIT_* values indicating which - * renderbuffers are to be cleared. - * \param all if GL_TRUE, clear whole buffer, else clear specified region. - */ -void -_swrast_Clear(struct gl_context *ctx, GLbitfield buffers) -{ -#ifdef DEBUG_FOO - { - const GLbitfield legalBits = - BUFFER_BIT_FRONT_LEFT | - BUFFER_BIT_FRONT_RIGHT | - BUFFER_BIT_BACK_LEFT | - BUFFER_BIT_BACK_RIGHT | - BUFFER_BIT_DEPTH | - BUFFER_BIT_STENCIL | - BUFFER_BIT_ACCUM | - BUFFER_BIT_AUX0; - assert((buffers & (~legalBits)) == 0); - } -#endif - - if (!_mesa_check_conditional_render(ctx)) - return; /* don't clear */ - - swrast_render_start(ctx); - - /* do software clearing here */ - if (buffers) { - if ((buffers & BUFFER_BITS_COLOR) - && (ctx->DrawBuffer->_NumColorDrawBuffers > 0)) { - clear_color_buffers(ctx); - } - if (buffers & BUFFER_BIT_DEPTH) { - _swrast_clear_depth_buffer(ctx, ctx->DrawBuffer->_DepthBuffer); - } - if (buffers & BUFFER_BIT_ACCUM) { - _swrast_clear_accum_buffer(ctx, - ctx->DrawBuffer->Attachment[BUFFER_ACCUM].Renderbuffer); - } - if (buffers & BUFFER_BIT_STENCIL) { - _swrast_clear_stencil_buffer(ctx, ctx->DrawBuffer->_StencilBuffer); - } - } - - swrast_render_finish(ctx); -} +/* + * Mesa 3-D graphics library + * Version: 7.1 + * + * Copyright (C) 1999-2008 Brian Paul All Rights Reserved. + * + * 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 + * BRIAN PAUL 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. + */ + +#include "main/glheader.h" +#include "main/colormac.h" +#include "main/condrender.h" +#include "main/macros.h" +#include "main/imports.h" +#include "main/mtypes.h" + +#include "s_accum.h" +#include "s_context.h" +#include "s_depth.h" +#include "s_masking.h" +#include "s_stencil.h" + + +/** + * Clear the color buffer when glColorMask is in effect. + */ +static void +clear_rgba_buffer_with_masking(struct gl_context *ctx, struct gl_renderbuffer *rb, + GLuint buf) +{ + const GLint x = ctx->DrawBuffer->_Xmin; + const GLint y = ctx->DrawBuffer->_Ymin; + const GLint height = ctx->DrawBuffer->_Ymax - ctx->DrawBuffer->_Ymin; + const GLint width = ctx->DrawBuffer->_Xmax - ctx->DrawBuffer->_Xmin; + SWspan span; + GLint i; + + ASSERT(rb->PutRow); + + /* Initialize color span with clear color */ + /* XXX optimize for clearcolor == black/zero (bzero) */ + INIT_SPAN(span, GL_BITMAP); + span.end = width; + span.arrayMask = SPAN_RGBA; + span.array->ChanType = rb->DataType; + if (span.array->ChanType == GL_UNSIGNED_BYTE) { + GLubyte clearColor[4]; + UNCLAMPED_FLOAT_TO_UBYTE(clearColor[RCOMP], ctx->Color.ClearColor[0]); + UNCLAMPED_FLOAT_TO_UBYTE(clearColor[GCOMP], ctx->Color.ClearColor[1]); + UNCLAMPED_FLOAT_TO_UBYTE(clearColor[BCOMP], ctx->Color.ClearColor[2]); + UNCLAMPED_FLOAT_TO_UBYTE(clearColor[ACOMP], ctx->Color.ClearColor[3]); + for (i = 0; i < width; i++) { + COPY_4UBV(span.array->rgba[i], clearColor); + } + } + else if (span.array->ChanType == GL_UNSIGNED_SHORT) { + GLushort clearColor[4]; + UNCLAMPED_FLOAT_TO_USHORT(clearColor[RCOMP], ctx->Color.ClearColor[0]); + UNCLAMPED_FLOAT_TO_USHORT(clearColor[GCOMP], ctx->Color.ClearColor[1]); + UNCLAMPED_FLOAT_TO_USHORT(clearColor[BCOMP], ctx->Color.ClearColor[2]); + UNCLAMPED_FLOAT_TO_USHORT(clearColor[ACOMP], ctx->Color.ClearColor[3]); + for (i = 0; i < width; i++) { + COPY_4V_CAST(span.array->rgba[i], clearColor, GLchan); + } + } + else { + ASSERT(span.array->ChanType == GL_FLOAT); + for (i = 0; i < width; i++) { + CLAMPED_FLOAT_TO_CHAN(span.array->rgba[i][0], ctx->Color.ClearColor[0]); + CLAMPED_FLOAT_TO_CHAN(span.array->rgba[i][1], ctx->Color.ClearColor[1]); + CLAMPED_FLOAT_TO_CHAN(span.array->rgba[i][2], ctx->Color.ClearColor[2]); + CLAMPED_FLOAT_TO_CHAN(span.array->rgba[i][3], ctx->Color.ClearColor[3]); + } + } + + /* Note that masking will change the color values, but only the + * channels for which the write mask is GL_FALSE. The channels + * which which are write-enabled won't get modified. + */ + for (i = 0; i < height; i++) { + span.x = x; + span.y = y + i; + _swrast_mask_rgba_span(ctx, rb, &span, buf); + /* write masked row */ + rb->PutRow(ctx, rb, width, x, y + i, span.array->rgba, NULL); + } +} + + +/** + * Clear an rgba color buffer without channel masking. + */ +static void +clear_rgba_buffer(struct gl_context *ctx, struct gl_renderbuffer *rb, GLuint buf) +{ + const GLint x = ctx->DrawBuffer->_Xmin; + const GLint y = ctx->DrawBuffer->_Ymin; + const GLint height = ctx->DrawBuffer->_Ymax - ctx->DrawBuffer->_Ymin; + const GLint width = ctx->DrawBuffer->_Xmax - ctx->DrawBuffer->_Xmin; + GLubyte clear8[4]; + GLushort clear16[4]; + GLvoid *clearVal; + GLint i; + + ASSERT(ctx->Color.ColorMask[buf][0] && + ctx->Color.ColorMask[buf][1] && + ctx->Color.ColorMask[buf][2] && + ctx->Color.ColorMask[buf][3]); + + ASSERT(rb->PutMonoRow); + + switch (rb->DataType) { + case GL_UNSIGNED_BYTE: + UNCLAMPED_FLOAT_TO_UBYTE(clear8[0], ctx->Color.ClearColor[0]); + UNCLAMPED_FLOAT_TO_UBYTE(clear8[1], ctx->Color.ClearColor[1]); + UNCLAMPED_FLOAT_TO_UBYTE(clear8[2], ctx->Color.ClearColor[2]); + UNCLAMPED_FLOAT_TO_UBYTE(clear8[3], ctx->Color.ClearColor[3]); + clearVal = clear8; + break; + case GL_UNSIGNED_SHORT: + UNCLAMPED_FLOAT_TO_USHORT(clear16[0], ctx->Color.ClearColor[0]); + UNCLAMPED_FLOAT_TO_USHORT(clear16[1], ctx->Color.ClearColor[1]); + UNCLAMPED_FLOAT_TO_USHORT(clear16[2], ctx->Color.ClearColor[2]); + UNCLAMPED_FLOAT_TO_USHORT(clear16[3], ctx->Color.ClearColor[3]); + clearVal = clear16; + break; + case GL_FLOAT: + clearVal = ctx->Color.ClearColor; + break; + default: + _mesa_problem(ctx, "Bad rb DataType in clear_color_buffer"); + return; + } + + for (i = 0; i < height; i++) { + rb->PutMonoRow(ctx, rb, width, x, y + i, clearVal, NULL); + } +} + + +/** + * Clear the front/back/left/right/aux color buffers. + * This function is usually only called if the device driver can't + * clear its own color buffers for some reason (such as with masking). + */ +static void +clear_color_buffers(struct gl_context *ctx) +{ + GLuint buf; + + for (buf = 0; buf < ctx->DrawBuffer->_NumColorDrawBuffers; buf++) { + struct gl_renderbuffer *rb = ctx->DrawBuffer->_ColorDrawBuffers[buf]; + + /* If this is an ES2 context or GL_ARB_ES2_compatibility is supported, + * the framebuffer can be complete with some attachments be missing. In + * this case the _ColorDrawBuffers pointer will be NULL. + */ + if (rb == NULL) + continue; + + if (ctx->Color.ColorMask[buf][0] == 0 || + ctx->Color.ColorMask[buf][1] == 0 || + ctx->Color.ColorMask[buf][2] == 0 || + ctx->Color.ColorMask[buf][3] == 0) { + clear_rgba_buffer_with_masking(ctx, rb, buf); + } + else { + clear_rgba_buffer(ctx, rb, buf); + } + } +} + + +/** + * Called via the device driver's ctx->Driver.Clear() function if the + * device driver can't clear one or more of the buffers itself. + * \param buffers bitfield of BUFFER_BIT_* values indicating which + * renderbuffers are to be cleared. + * \param all if GL_TRUE, clear whole buffer, else clear specified region. + */ +void +_swrast_Clear(struct gl_context *ctx, GLbitfield buffers) +{ +#ifdef DEBUG_FOO + { + const GLbitfield legalBits = + BUFFER_BIT_FRONT_LEFT | + BUFFER_BIT_FRONT_RIGHT | + BUFFER_BIT_BACK_LEFT | + BUFFER_BIT_BACK_RIGHT | + BUFFER_BIT_DEPTH | + BUFFER_BIT_STENCIL | + BUFFER_BIT_ACCUM | + BUFFER_BIT_AUX0; + assert((buffers & (~legalBits)) == 0); + } +#endif + + if (!_mesa_check_conditional_render(ctx)) + return; /* don't clear */ + + swrast_render_start(ctx); + + /* do software clearing here */ + if (buffers) { + if ((buffers & BUFFER_BITS_COLOR) + && (ctx->DrawBuffer->_NumColorDrawBuffers > 0)) { + clear_color_buffers(ctx); + } + if (buffers & BUFFER_BIT_DEPTH) { + _swrast_clear_depth_buffer(ctx, ctx->DrawBuffer->_DepthBuffer); + } + if (buffers & BUFFER_BIT_ACCUM) { + _swrast_clear_accum_buffer(ctx, + ctx->DrawBuffer->Attachment[BUFFER_ACCUM].Renderbuffer); + } + if (buffers & BUFFER_BIT_STENCIL) { + _swrast_clear_stencil_buffer(ctx, ctx->DrawBuffer->_StencilBuffer); + } + } + + swrast_render_finish(ctx); +} diff --git a/xorg-server/Xi/exevents.c b/xorg-server/Xi/exevents.c index c6f9d467f..3b0411d61 100644 --- a/xorg-server/Xi/exevents.c +++ b/xorg-server/Xi/exevents.c @@ -890,8 +890,8 @@ ProcessRawEvent(RawDeviceEvent *ev, DeviceIntPtr device) i = EventToXI2((InternalEvent*)ev, (xEvent**)&xi); if (i != Success) { - ErrorF("[Xi] %s: XI2 conversion failed in ProcessRawEvent (%d)\n", - device->name, i); + ErrorF("[Xi] %s: XI2 conversion failed in %s (%d)\n", + __func__, device->name, i); return; } diff --git a/xorg-server/dix/events.c b/xorg-server/dix/events.c index b60c29952..3c7bd50cd 100644 --- a/xorg-server/dix/events.c +++ b/xorg-server/dix/events.c @@ -432,7 +432,7 @@ GetEventFilter(DeviceIntPtr dev, xEvent *event) return filters[dev ? dev->id : 0][event->u.u.type]; else if ((evtype = xi2_get_type(event))) return (1 << (evtype % 8)); - ErrorF("[dix] Unknown device type %d. No filter\n", event->u.u.type); + ErrorF("[dix] Unknown event type %d. No filter\n", event->u.u.type); return 0; } @@ -1421,7 +1421,7 @@ CheckGrabForSyncs(DeviceIntPtr thisDev, Bool thisMode, Bool otherMode) static void DetachFromMaster(DeviceIntPtr dev) { - if (!IsFloating(dev)) + if (IsFloating(dev)) return; dev->saved_master_id = GetMaster(dev, MASTER_ATTACHED)->id; @@ -3997,7 +3997,7 @@ DeliverGrabbedEvent(InternalEvent *event, DeviceIntPtr thisDev, rc = EventToXI2(event, &xi2); if (rc == Success) { - int evtype = ((xGenericEvent*)xi2)->evtype; + int evtype = xi2_get_type(xi2); mask = grab->xi2mask[XIAllDevices][evtype/8] | grab->xi2mask[XIAllMasterDevices][evtype/8] | grab->xi2mask[thisDev->id][evtype/8]; diff --git a/xorg-server/dix/getevents.c b/xorg-server/dix/getevents.c index 13789f6a2..c935c971c 100644 --- a/xorg-server/dix/getevents.c +++ b/xorg-server/dix/getevents.c @@ -864,7 +864,7 @@ positionSprite(DeviceIntPtr dev, int mode, * to the current screen. */ miPointerSetPosition(dev, mode, screenx, screeny); - if(!IsMaster(dev) || !IsFloating(dev)) { + if(!IsMaster(dev) && !IsFloating(dev)) { DeviceIntPtr master = GetMaster(dev, MASTER_POINTER); master->last.valuators[0] = *screenx; master->last.valuators[1] = *screeny; @@ -911,7 +911,7 @@ updateHistory(DeviceIntPtr dev, ValuatorMask *mask, CARD32 ms) return; updateMotionHistory(dev, ms, mask, dev->last.valuators); - if(!IsMaster(dev) || !IsFloating(dev)) + if(!IsMaster(dev) && !IsFloating(dev)) { DeviceIntPtr master = GetMaster(dev, MASTER_POINTER); updateMotionHistory(master, ms, mask, dev->last.valuators); @@ -1052,17 +1052,39 @@ FreeEventList(InternalEvent *list, int num_events) free(list); } +/** + * Transform vector x/y according to matrix m and drop the rounded coords + * back into x/y. + */ static void -transformAbsolute(DeviceIntPtr dev, ValuatorMask *mask, int *x, int *y) +transform(struct pixman_f_transform *m, int *x, int *y) { struct pixman_f_vector p = {.v = {*x, *y, 1}}; - - pixman_f_transform_point(&dev->transform, &p); + pixman_f_transform_point(m, &p); *x = lround(p.v[0]); *y = lround(p.v[1]); } +static void +transformAbsolute(DeviceIntPtr dev, ValuatorMask *mask) +{ + int x, y, ox, oy; + + ox = x = valuator_mask_isset(mask, 0) ? valuator_mask_get(mask, 0) : + dev->last.valuators[0]; + oy = y = valuator_mask_isset(mask, 1) ? valuator_mask_get(mask, 1) : + dev->last.valuators[1]; + + transform(&dev->transform, &x, &y); + + if (valuator_mask_isset(mask, 0) || ox != x) + valuator_mask_set(mask, 0, x); + + if (valuator_mask_isset(mask, 1) || oy != y) + valuator_mask_set(mask, 1, y); +} + /** * Generate internal events representing this pointer event and enqueue them * on the event queue. @@ -1175,16 +1197,7 @@ GetPointerEvents(InternalEvent *events, DeviceIntPtr pDev, int type, int buttons } } - x = (valuator_mask_isset(&mask, 0) ? valuator_mask_get(&mask, 0) : - pDev->last.valuators[0]); - y = (valuator_mask_isset(&mask, 1) ? valuator_mask_get(&mask, 1) : - pDev->last.valuators[1]); - transformAbsolute(pDev, &mask, &x, &y); - if (valuator_mask_isset(&mask, 0)) - valuator_mask_set(&mask, 0, x); - if (valuator_mask_isset(&mask, 1)) - valuator_mask_set(&mask, 1, y); - + transformAbsolute(pDev, &mask); moveAbsolute(pDev, &x, &y, &mask); } else { if (flags & POINTER_ACCELERATE) { diff --git a/xorg-server/test/input.c b/xorg-server/test/input.c index ac37d67a1..837ce49dc 100644 --- a/xorg-server/test/input.c +++ b/xorg-server/test/input.c @@ -1223,8 +1223,11 @@ static void dix_valuator_alloc(void) assert(v); assert(v->numAxes == num_axes); +#ifndef __i386__ + /* must be double-aligned on 64 bit */ assert(((void*)v->axisVal - (void*)v) % sizeof(double) == 0); assert(((void*)v->axes - (void*)v) % sizeof(double) == 0); +#endif num_axes ++; } diff --git a/xorg-server/xkb/xkbfmisc.c b/xorg-server/xkb/xkbfmisc.c index 1ac9d8262..d8202b496 100644 --- a/xorg-server/xkb/xkbfmisc.c +++ b/xorg-server/xkb/xkbfmisc.c @@ -62,7 +62,7 @@ unsigned set,rtrn; rtrn|= _XkbKSUpper; } if (((ks>=XK_a)&&(ks<=XK_z))|| - ((ks>=XK_agrave)&&(ks<=XK_ydiaeresis))) { + ((ks>=XK_ssharp)&&(ks<=XK_ydiaeresis)&&(ks!=XK_division))) { rtrn|= _XkbKSLower; } break; @@ -71,7 +71,7 @@ unsigned set,rtrn; ((ks>=XK_Racute)&&(ks<=XK_Tcedilla))) { rtrn|= _XkbKSUpper; } - if (((ks>=XK_aogonek)&&(ks<=XK_zabovedot)&&(ks!=XK_caron))|| + if (((ks>=XK_aogonek)&&(ks<=XK_zabovedot)&&(ks!=XK_ogonek)&&(ks!=XK_caron)&&(ks!=XK_doubleacute))|| ((ks>=XK_racute)&&(ks<=XK_tcedilla))) { rtrn|= _XkbKSLower; } @@ -92,7 +92,8 @@ unsigned set,rtrn; ((ks>=XK_Amacron)&&(ks<=XK_Umacron))) { rtrn|= _XkbKSUpper; } - if (((ks>=XK_rcedilla)&&(ks<=XK_tslash))|| + if ((ks==XK_kra)|| + ((ks>=XK_rcedilla)&&(ks<=XK_tslash))|| (ks==XK_eng)|| ((ks>=XK_amacron)&&(ks<=XK_umacron))) { rtrn|= _XkbKSLower; -- cgit v1.2.3