• Dave Carver (Digital HPW)

• Branko Gerovac (Digital HPW)

• Jim Gettys (MIT/Project Athena, Digital)

• Phil Karlton (Digital WSL)

• Scott McGregor (Digital SSG)

• Ram Rao (Digital UEG)

• David Rosenthal (Sun)

• Dave Winchell (Digital UEG)

• Susan Angebranndt (Digital)

• Raymond Drewry (Digital)

• Todd Newman (Digital)

• Andrew Cherenson (Berkeley)

• Burns Fisher (Digital)

• Dan Garfinkel (HP)

• Leo Hourvitz (Next)

• Brock Krizan (HP)

• David Laidlaw (Stellar)

• Dave Mellinger (Interleaf)

• Ron Newman (MIT)

• John Ousterhout (Berkeley)

• Andrew Palay (ITC CMU)

• Ralph Swick (MIT)

• Craig Taylor (Sun)

• Jeffery Vroom (Stellar)

Table of Contents

Request Format

Reply Format

Error Format

Event Format

Every request contains an 8-bitmajor opcodeand a 16-bitlength fieldexpressed in units of four bytes.Every request consists of four bytes of a header(containing the major opcode, the length field, and a data byte)followed by zero or more additional bytes of data.The length field defines the total length of the request, including the header.The length field in a request must equal the minimum length required to containthe request.If the specified length is smaller or larger than the required length,an error is generated.Unused bytes in a request are not required to be zero.Major opcodes 128 through 255 are reserved forextensions.Extensions are intended to contain multiple requests,so extension requests typically have an additionalminor opcode encodedin the second data byte in the request header.However, the placement and interpretation of this minor opcode and of allother fields in extension requests are not defined by the core protocol.Every request on a given connection is implicitly assigned asequence number,starting with one, that is used in replies, errors, and events.

Everyreply contains a 32-bit length fieldexpressed in units of four bytes.Every reply consists of 32 bytes followed by zero or more additional bytes ofdata, as specified in the length field.Unused bytes within a reply are not guaranteed to be zero.Every reply also contains the least significant 16 bits of the sequence numberof the corresponding request.

Error reports are 32 bytes long.Every error includes an 8-bit error code.Error codes 128 through 255 are reserved for extensions.Every error also includes the major and minor opcodes of the failed requestand the least significant 16 bits of the sequence number of the request.For the following errors (seesection 4),the failing resource ID is also returned:Colormap,Cursor,Drawable,Font,GContext,IDChoice,PixmapandWindow.ForAtomerrors, the failing atom is returned.ForValueerrors, the failing value is returned.Other core errors return no additional data.Unused bytes within an error are not guaranteed to be zero.

Events are 32 bytes long.Unused bytes within an event are not guaranteed to be zero.Every event contains an 8-bit type code.The most significant bit in this code is set if the event was generated from aSendEventrequest.Event codes 64 through 127 are reserved for extensions, although the coreprotocol does not define a mechanism for selecting interest in such events.Every core event (with the exception ofKeymapNotify)also contains the least significant 16 bits of the sequence number of the lastrequest issued by the client that was (or is currently being) processed bythe server.

• The syntax {...} encloses a set of alternatives.

• The syntax [...] encloses a set of structure components.

• In general, TYPEs are in uppercase andAlternativeValuesare capitalized.

• Requests insection 9 are describedin the following format:

  RequestNamearg1: type1     ...argN: typeN   ▶     result1: type1     ...     resultM: typeM     Errors: kind1, ..., kindK     Description.

  If no ▶ is present in the description,then the request has no reply (it is asynchronous),although errors may still be reported.If ▶+ is used,then one or more replies can be generated for a single request.

• Events insection 11 are describedin the following format:

  EventNamevalue1: type1     ...valueN: typeN     Description.

Note

TheAtom,Colormap,Cursor,Drawable,Font,GContext,PixmapandWindowerrors are also used when the argument type is extended by union with aset of fixed alternatives, for example, <WINDOW orPointerRootorNone>.

• The numlock modifier is on and the second KEYSYM is a keypad KEYSYM. Inthis case, if theShiftmodifier is on, or if theLockmodifier is on andis interpreted as ShiftLock, then the first KEYSYM is used; otherwise, thesecond KEYSYM is used.

• TheShiftandLockmodifiers are both off. In this case, the firstKEYSYM is used.

• TheShiftmodifier is off, and theLockmodifier is on and isinterpreted as CapsLock. In this case, the first KEYSYM is used, but ifthat KEYSYM is lowercase alphabetic, then the corresponding uppercaseKEYSYM is used instead.

• TheShiftmodifier is on, and theLockmodifier is on and is interpretedas CapsLock. In this case, the second KEYSYM is used, but if that KEYSYMis lowercase alphabetic, then the corresponding uppercase KEYSYM is usedinstead.

• TheShiftmodifier is on, or theLockmodifier is on and is interpretedas ShiftLock, or both. In this case, the second KEYSYM is used.

Table of Contents

Connection Initiation

Server Response

Server Information

Screen Information

Visual Information

The client must send an initial byte of data to identify the byte order to beemployed.The value of the byte must be octal 102 or 154.The value 102 (ASCII uppercase B) means values are transmitted most significantbyte first, and value 154 (ASCII lowercase l) means values are transmittedleast significant byte first.Except where explicitly noted in the protocol,all 16-bit and 32-bit quantities sent by the client must be transmitted withthis byte order,and all 16-bit and 32-bit quantities returned by the server will be transmittedwith this byte order.

Following the byte-order byte,the client sends the following information at connection setup:

The version numbers indicate what version of the protocol the clientexpects the server to implement.

The authorization name indicates what authorization (and authentication)protocol the clientexpects the server to use, and the data is specific to that protocol.Specification of valid authorization mechanisms is not part of the coreX protocol.A server that does not implement the protocol the client expectsor that only implements the host-based mechanism may simply ignore thisinformation.If both name and data strings are empty,this is to be interpreted as "no explicit authorization."

The client receives the following information at connection setup:

The client receives the following additional data if the returned successvalue isFailed,and the connection is not successfully established:

The client receives the following additional data if the returned successvalue isAuthenticate,and further authentication negotiation is required:

The contents of the reason string are specific to the authorizationprotocol in use. The semantics of this authentication negotiation arenot constrained, except that the negotiation must eventually terminatewith a reply from the server containing a success value ofFailedorSuccess.

The client receives the following additional data if the returned successvalue isSuccess,and the connection is successfully established:

The information that is global to the server is:

The protocol version numbers are an escape hatch in case future revisions ofthe protocol are necessary.In general,the major version would increment for incompatible changes,and the minor version would increment for small upward compatible changes.Barring changes,the major version will be 11, and the minor version will be 0.The protocol version numbers returned indicate the protocol the serveractually supports.This might not equal the version sent by the client.The server can (but need not) refuse connections from clients that offer adifferent version than the server supports.A server can (but need not) support more than one version simultaneously.

The vendor string gives some identification of the owner of the serverimplementation.The vendor controls the semantics of the release number.

The resource-id-mask contains a single contiguous set of bits (at least 18).The client allocates resource IDs for types WINDOW, PIXMAP,CURSOR, FONT, GCONTEXT, and COLORMAP by choosing a value with onlysome subset of these bits set and ORing it with resource-id-base.Only values constructed in this way can be used to name newly createdresources over this connection.Resource IDs never have the top three bits set.The client is not restricted to linear or contiguous allocationof resource IDs.Once an ID has been freed,it can be reused.An ID must be unique with respect to the IDs of all other resources,not just other resources of the same type.However, note that the value spaces of resource identifiers,atoms, visualids, and keysyms are distinguished by context, andas such, are not required to be disjoint; for example, a given numeric valuemight be both a valid window ID, a valid atom, and a valid keysym.

Although the server is in general responsible for byte-swapping data tomatch the client,images are always transmitted and received in formats (including byte order)specified by the server.The byte order for images is given by image-byte-order and applies to eachscanline unit in XY format (bitmap format) and to each pixel value in Z format.

A bitmap is represented inscanline order.Eachscanlineis padded to a multiple of bits as given by bitmap-scanline-pad.The pad bits are of arbitrary value.The scanline is quantized in multiples of bits as given by bitmap-scanline-unit.The bitmap-scanline-unit is always less than or equal to thebitmap-scanline-pad.Within each unit,the leftmost bit in the bitmap is either the least significantor most significant bit in the unit, as given by bitmap-bit-order.If a pixmap is represented in XY format,each plane is represented as a bitmap, and the planes appear frommost significant to least significant in bit order with no paddingbetween planes.

Pixmap-formats contains one entry for eachdepth value.The entry describes theZ formatused to represent images of that depth.An entry for a depth is included if any screen supports that depth,and all screens supporting that depth must support only that Z format for thatdepth.In Z format,the pixels are in scanline order, left to right within a scanline.The number of bits used to hold each pixel is given by bits-per-pixel.Bits-per-pixel may be larger than strictly required by the depth,in which case the least significant bits are used to holdthe pixmap data, and the values of the unused high-order bits areundefined.When the bits-per-pixel is 4,the order of nibbles in the byte is the same as the image byte-order.When the bits-per-pixel is 1,the format is identical for bitmap format.Each scanline is padded to a multiple of bits as given by scanline-pad.When bits-per-pixel is 1,this will be identical to bitmap-scanline-pad.

How a pointing device roams the screens is up to the serverimplementation and is transparent to the protocol.No geometry is defined among screens.

The server may retain the recent history of pointer motion and do so to afiner granularity than is reported byMotionNotifyevents.TheGetMotionEventsrequest makes such history available.The motion-buffer-size gives the approximate maximum numberof elements in the history buffer.

Maximum-request-length specifies the maximum length of a requestaccepted by the server, in 4-byte units.That is, length is the maximum value that can appear in the length field of arequest.Requests larger than this maximum generate aLengtherror,and the server will read and simply discard the entire request.Maximum-request-length will always be at least 4096(that is, requests of length up to and including 16384 byteswill be accepted by all servers).

Min-keycode and max-keycode specify the smallest and largest keycodevalues transmitted by the server.Min-keycode is never less than 8,and max-keycode is never greater than 255.Not all keycodes in this range are required to have corresponding keys.

The information that applies per screen is:

The allowed-depths specifies what pixmap and window depths are supported.Pixmaps are supported for each depth listed,and windows of that depth are supported if at least one visual type is listedfor the depth.A pixmap depth of one is always supported and listed,but windows of depth one might not be supported.A depth of zero is never listed,but zero-depthInputOnlywindows are always supported.

Root-depth and root-visual specify the depth and visual type of theroot window.Width-in-pixels and height-in-pixels specify the size ofthe root window (which cannot be changed).The class of the root window is alwaysInputOutput.Width-in-millimeters and height-in-millimeters can be used to determine thephysical size and the aspect ratio.

The default-colormap is the one initially associated with the root window.Clients with minimal color requirements creating windows ofthe same depth as the root may want to allocate from this map bydefault.

Black-pixel and white-pixel can be used in implementing a monochromeapplication.These pixel values are for permanently allocated entries in thedefault-colormap.The actual RGB values may be settable on some screensand, in any case, may not actually be black and white.The names are intended to convey the expected relative intensity of the colors.

The border of the root window is initially a pixmap filled with the black-pixel.The initial background of the root window is a pixmap filled with someunspecified two-color pattern using black-pixel and white-pixel.

Min-installed-maps specifies the number of maps that can be guaranteedto be installed simultaneously (withInstallColormap),regardless of the number of entries allocated in each map.Max-installed-maps specifies the maximum number of maps that might possibly beinstalled simultaneously, depending on their allocations.Multiple static-visual colormaps with identical contents but differing inresource ID should be considered as a single map for the purposes of thisnumber.For the typical case of a single hardware colormap, both values will be 1.

Backing-stores indicates when the server supports backing stores forthis screen, although it may be storage limited in the number ofwindows it can support at once.If save-unders isTrue,the server can support the save-under mode inCreateWindowandChangeWindowAttributes,although again it may be storage limited.

The current-input-events is whatGetWindowAttributeswould return for the all-event-masks for the root window.

The information that applies per visual-type is:

A given visual type might be listed for more than one depth or formore than one screen.

ForPseudoColor,a pixel value indexes a colormap to produce independent RGB values;the RGB values can be changed dynamically.GrayScaleis treated in the same way asPseudoColorexcept which primary drives the screen is undefined;thus, the client should always store thesame value for red, green, and blue in colormaps.ForDirectColor,a pixel value is decomposed into separate RGB subfields,and each subfield separately indexes the colormap for the corresponding value.The RGB values can be changed dynamically.TrueColoris treated in the same way asDirectColorexcept the colormap has predefined read-only RGB values.These values are server-dependent but provide linear or near-linearincreasing ramps in each primary.StaticColoris treated in the same way asPseudoColorexcept the colormap has predefined read-only RGB values,which are server-dependent.StaticGrayis treated in the same way asStaticColorexcept the red, green, and blue values are equal for anysingle pixel value, resulting in shades of gray.StaticGraywith a two-entry colormap can be thought of as monochrome.

The red-mask, green-mask, and blue-mask are only defined forDirectColorandTrueColor.Each has one contiguous set of bits set to 1 with no intersections.Usually each mask has the same number of bits set to 1.

The bits-per-rgb-value specifies the log base 2 of the number ofdistinct color intensity values (individually) of red, green, and blue.This number need not bear any relation to the number of colormap entries.Actual RGB values are always passed in the protocol within a16-bit spectrum, with 0 being minimum intensity and 65535 being themaximum intensity.On hardware that provides a linear zero-based intensity ramp,the following relationship exists:

       hw-intensity = protocol-intensity / (65536 / total-hw-intensities)

Colormap entries are indexed from 0.The colormap-entries defines the number of available colormap entries in anewly created colormap.ForDirectColorandTrueColor,this will usually be 2 to the power of the maximum number of bits set to 1 inred-mask, green-mask, and blue-mask.

Table of Contents

CreateWindow

ChangeWindowAttributes

GetWindowAttributes

DestroyWindow

DestroySubwindows

ChangeSaveSet

ReparentWindow

MapWindow

MapSubwindows

UnmapWindow

UnmapSubwindows

ConfigureWindow

CirculateWindow

GetGeometry

QueryTree

InternAtom

GetAtomName

ChangeProperty

DeleteProperty

GetProperty

RotateProperties

ListProperties

SetSelectionOwner

GetSelectionOwner

ConvertSelection

SendEvent

GrabPointer

UngrabPointer

GrabButton

UngrabButton

ChangeActivePointerGrab

GrabKeyboard

UngrabKeyboard

GrabKey

UngrabKey

AllowEvents

GrabServer

UngrabServer

QueryPointer

GetMotionEvents

TranslateCoordinates

WarpPointer

SetInputFocus

GetInputFocus

QueryKeymap

OpenFont

CloseFont

QueryFont

QueryTextExtents

ListFonts

ListFontsWithInfo

SetFontPath

GetFontPath

CreatePixmap

FreePixmap

CreateGC

ChangeGC

CopyGC

SetDashes

SetClipRectangles

FreeGC

ClearArea

CopyArea

CopyPlane

PolyPoint

PolyLine

PolySegment

PolyRectangle

PolyArc

FillPoly

PolyFillRectangle

PolyFillArc

PutImage

GetImage

PolyText8

PolyText16

ImageText8

ImageText16

CreateColormap

FreeColormap

CopyColormapAndFree

InstallColormap

UninstallColormap

ListInstalledColormaps

AllocColor

AllocNamedColor

AllocColorCells

AllocColorPlanes

FreeColors

StoreColors

StoreNamedColor

QueryColors

LookupColor

CreateCursor

CreateGlyphCursor

FreeCursor

RecolorCursor

QueryBestSize

QueryExtension

ListExtensions

SetModifierMapping

GetModifierMapping

ChangeKeyboardMapping

GetKeyboardMapping

ChangeKeyboardControl

GetKeyboardControl

Bell

SetPointerMapping

GetPointerMapping

ChangePointerControl

GetPointerControl

SetScreenSaver

GetScreenSaver

ForceScreenSaver

ChangeHosts

ListHosts

SetAccessControl

SetCloseDownMode

KillClient

NoOperation

This request creates an unmapped window and assigns the identifier wid to it.

A class ofCopyFromParentmeans the class is taken from the parent.A depth of zero for classInputOutputorCopyFromParentmeans the depth is taken from the parent.A visual ofCopyFromParentmeans the visual type is taken from the parent.For classInputOutput,the visual type and depth must be a combination supported for the screen(or aMatcherror results).The depth need not be the same as the parent,but the parent must not be of classInputOnly(or aMatcherror results).For classInputOnly,the depth must be zero (or aMatcherror results), and the visual must be one supported for the screen (or aMatcherror results).However, the parent can have any depth and class.

The server essentially acts as ifInputOnlywindows do not exist for the purposes of graphics requests,exposure processing, andVisibilityNotifyevents.AnInputOnlywindow cannot be used as a drawable (as a source or destination for graphicsrequests).InputOnlyandInputOutputwindows act identically in other respects-properties,grabs, input control, and so on.

The coordinate system has the X axis horizontal and the Y axis verticalwith the origin [0, 0] at the upper-left corner.Coordinates are integral,in terms of pixels,and coincide with pixel centers.Each window and pixmap has its own coordinate system.For a window,the origin is inside the border at the inside, upper-left corner.

The x and y coordinatesfor the window are relative to the parent's originand specify the position of the upper-left outer corner of the window(not the origin).The width and height specify the inside size (not including the border)and must be nonzero (or aValueerror results).The border-width for anInputOnlywindow must be zero (or aMatcherror results).

The window is placed on top in the stacking order with respect to siblings.

The value-mask and value-list specify attributes of the window that areto be explicitly initialized.The possible values are:

The default values when attributes are not explicitly initializedare:

Only the following attributes are defined forInputOnlywindows:

It is aMatcherror to specify any other attributes forInputOnlywindows.

If background-pixmap is given,it overrides the default background-pixmap.The background pixmap and the window must have thesame root and the same depth (or aMatcherror results).Any size pixmap can be used, although some sizes may be faster than others.If backgroundNoneis specified, the window has no defined background.If backgroundParentRelativeis specified, the parent's background is used,but the window must have the same depth as the parent (or aMatcherror results).If the parent has backgroundNone,then the window will also have backgroundNone.A copy of the parent's background is not made.The parent's background is reexamined each time the window background isrequired.If background-pixel is given, it overrides the defaultbackground-pixmap and any background-pixmap given explicitly,and a pixmap of undefined size filled with background-pixel is used for thebackground.Range checking is not performed on the background-pixel value;it is simply truncated to the appropriate number of bits.For aParentRelativebackground,the background tile origin always aligns with the parent's background tileorigin.Otherwise, the background tile origin is always the window origin.

When no valid contents are available for regions of a windowand the regions are either visible or the server is maintaining backing store,the server automatically tiles the regions with the window's backgroundunless the window has a background ofNone.If the background isNone,the previous screen contents from other windows of the same depth as the windoware simply left in place if the contents come from the parent of the windowor an inferior of the parent;otherwise, the initial contents of the exposed regions are undefined.Exposure events are then generated for the regions, even if the background isNone.

The border tile origin is always the same as the background tile origin.If border-pixmap is given,it overrides the default border-pixmap.The border pixmap and the window must have the same rootand the same depth (or aMatcherror results).Any size pixmap can be used,although some sizes may be faster than others.IfCopyFromParentis given, the parent's border pixmap is copied (subsequent changes tothe parent's border attribute do not affect the child),but the window must have the same depth as the parent (or aMatcherror results).The pixmap might be copied by sharing the same pixmap object between thechild and parent or by making a complete copy of the pixmap contents.If border-pixel is given,it overrides the default border-pixmap and any border-pixmap given explicitly,and a pixmap of undefined size filled with border-pixel is used for the border.Range checking is not performed on the border-pixel value;it is simply truncated to the appropriate number of bits.

Output to a window is always clipped to the inside of the window,so that the border is never affected.

The bit-gravity defines which region of the window should be retainedif the window is resized, and win-gravity defines how the window shouldbe repositioned if the parent is resized (seeConfigureWindowrequest).

A backing-store ofWhenMappedadvises the server that maintaining contents of obscured regionswhen the window is mapped would be beneficial.A backing-store ofAlwaysadvises the server that maintaining contents even when the window isunmapped would be beneficial.In this case,the server may generate an exposure event when the window is created.A value ofNotUsefuladvises the server that maintaining contents is unnecessary,although a server may still choose to maintain contents while the windowis mapped.Note that if the server maintains contents,then the server should maintain complete contentsnot just the region within the parent boundaries,even if the window is larger than its parent.While the server maintains contents,exposure events will not normally be generated,but the server may stop maintaining contents at any time.

If save-under isTrue,the server is advised that when this window ismapped, saving the contents of windows it obscures would be beneficial.

When the contents of obscured regions of a window are being maintained,regions obscured by noninferior windows are included in thedestination (and source, when the window is the source) of graphicsrequests, but regions obscured by inferior windows are not included.

The backing-planes indicates (with bits set to 1) which bit planesof the window hold dynamic data that must be preserved in backing-storesand during save-unders.The backing-pixel specifies what value to use in planes notcovered by backing-planes.The server is free to save only the specified bit planes in the backing-storeor save-under and regenerate the remaining planes with the specified pixelvalue.Any bits beyond the specified depth of the window in thesevalues are simply ignored.

The event-mask defines which events the client is interested in forthis window (or for some event types, inferiors of the window).The do-not-propagate-mask defines which events should not be propagated toancestor windows when no client has the event type selected in thiswindow.

The override-redirect specifies whether map and configure requests on thiswindow should override aSubstructureRedirecton the parent, typically to inform a window manager not to tamper withthe window.

The colormap specifies the colormap that best reflects the truecolors of the window.Servers capable of supporting multiple hardware colormaps may use thisinformation, and window managers may use it forInstallColormaprequests.The colormap must have the same visual type and root as the window (or aMatcherror results).IfCopyFromParentis specified,the parent's colormap is copied (subsequent changes to the parent'scolormap attribute do not affect the child).However, the window must have the same visual type as the parent (or aMatcherror results), and the parent must not have a colormap ofNone(or aMatcherror results).For an explanation ofNone,seeFreeColormaprequest.The colormap is copied by sharing the colormap object between the childand the parent,not by making a complete copy of the colormap contents.

If a cursor is specified,it will be used whenever the pointer is in the window.IfNoneis specified,the parent's cursor will be used when the pointer is in the window,and any change in the parent's cursor will cause an immediate changein the displayed cursor.

This request generates aCreateNotifyevent.

The background and border pixmaps and the cursor may be freedimmediately if no further explicit references to them are to be made.

Subsequent drawing into the background or border pixmap has anundefined effect on the window state.The server might or might not make a copy of the pixmap.

The value-mask and value-list specify which attributes are to be changed.The values and restrictions are the same as forCreateWindow.

Setting a new background, whether by background-pixmap orbackground-pixel, overrides any previous background.Setting a new border, whether by border-pixel or border-pixmap,overrides any previous border.

Changing the background does not cause the window contents to be changed.Setting the border or changing the background such that theborder tile origin changes causes the border to be repainted.Changing the background of a root window toNoneorParentRelativerestores the default background pixmap.Changing the border of a root window toCopyFromParentrestores the default border pixmap.

Changing the win-gravity does not affect the current position of thewindow.

Changing the backing-store of an obscured window toWhenMappedorAlwaysor changing the backing-planes, backing-pixel, or save-under ofa mapped window may have no immediate effect.

Multiple clients can select input on the same window;their event-masks are disjoint.When an event is generated,it will be reported to all interested clients.However, only one client at a time can select forSubstructureRedirect,only one client at a time can select forResizeRedirect,and only one client at a time can select forButtonPress.An attempt to violate these restrictions results in anAccesserror.

There is only one do-not-propagate-mask for a window, not one perclient.

Changing the colormap of a window (by defining a new map, not bychanging the contents of the existing map) generates aColormapNotifyevent.Changing the colormap of a visible window might have no immediate effecton the screen (seeInstallColormaprequest).

Changing the cursor of a root window toNonerestores the default cursor.

The order in which attributes are verified and altered is server-dependent.If an error is generated,a subset of the attributes may have been altered.

This request returns the current attributes of the window.A window isUnviewableif it is mapped but some ancestor is unmapped.All-event-masks is the inclusive-OR of all event masks selected on the windowby clients.Your-event-mask is the event mask selected by the querying client.

If the argument window is mapped,anUnmapWindowrequest is performed automatically.The window and all inferiors are then destroyed, and aDestroyNotifyevent is generated for each window.The ordering of theDestroyNotifyevents is such that for any given window,DestroyNotifyis generated on all inferiors of the window before being generated onthe window itself.The ordering among siblings and across subhierarchies is not otherwiseconstrained.

Normal exposure processing on formerly obscured windows is performed.

If the window is a root window,this request has no effect.

This request performs aDestroyWindowrequest on all children of the window, in bottom-to-top stacking order.

This request adds or removes the specified window from the client'ssave-set.The window must have been created by some other client (or aMatcherror results).For further information about the use of the save-set,seesection 10.

When windows are destroyed,the server automatically removes them from the save-set.

If the window is mapped,anUnmapWindowrequest is performed automatically first.The window is then removed from its current position in the hierarchyand is inserted as a child of the specified parent.The x and y coordinates are relative to the parent's originand specify the new position of the upper-left outer corner of thewindow.The window is placed on top in the stacking order with respectto siblings.AReparentNotifyevent is then generated.The override-redirect attribute of the window is passed on in this event;a value ofTrueindicates that a window manager should not tamper with this window.Finally, if the window was originally mapped, aMapWindowrequest is performed automatically.

Normal exposure processing on formerly obscured windows is performed.The server might not generate exposure events for regions from theinitial unmap that are immediately obscured by the final map.

AMatcherror is generated if:The new parent is not on the same screen as the old parent.The new parent is the window itself or an inferior of the window.The new parent isInputOnly,and the window is not.The window has aParentRelativebackground, and the new parent is not the same depth as the window.

If the window is already mapped, this request has no effect.

If the override-redirect attribute of the window isFalseand some other client has selectedSubstructureRedirecton the parent, then aMapRequestevent is generated, but the window remains unmapped.Otherwise, the window is mapped,and aMapNotifyevent is generated.

If the window is now viewable and its contents have been discarded,the window is tiled with its background (if no background is defined,the existing screen contents are not altered), and zero or more exposureevents are generated.If a backing-store has been maintained while the window was unmapped,no exposure events are generated.If a backing-store will now be maintained,a full-window exposure is always generated.Otherwise, only visible regions may be reported.Similar tiling and exposure take place for any newly viewable inferiors.

This request performs aMapWindowrequest on all unmapped children of the window,in top-to-bottom stacking order.

If the window is already unmapped, this request has no effect.Otherwise, the window is unmapped, and anUnmapNotifyevent is generated.Normal exposure processing on formerly obscured windows is performed.

This request performs anUnmapWindowrequest on all mapped children of the window,in bottom-to-top stacking order.

This request changes the configuration of the window.The value-mask and value-list specify which values are to be given.The possible values are:

The x and y coordinates are relative to the parent's originand specify the position of the upper-left outer corner of the window.The width and height specify the inside size, not including the border, andmust be nonzero (or aValueerror results).Those values not specified are taken from the existing geometry of the window.Note that changing just the border-width leaves the outer-left cornerof the window in a fixed position but moves the absolute position of thewindow's origin.It is aMatcherror to attempt to make the border-width of anInputOnlywindow nonzero.

If the override-redirect attribute of the window isFalseand some other client has selectedSubstructureRedirecton the parent, aConfigureRequestevent is generated, and no further processing is performed.Otherwise, the following is performed:

If some other client has selectedResizeRedirecton the window and the inside width or height of the window is being changed,aResizeRequestevent is generated,and the current inside width and height are used instead.Note that the override-redirect attribute of the window has no effect onResizeRedirectand thatSubstructureRedirecton the parent has precedence overResizeRedirecton the window.

The geometry of the window is changed as specified,the window is restacked among siblings, and aConfigureNotifyevent is generated if the state of the window actually changes.If the inside width or height of the window has actually changed,then children of the window are affected,according to their win-gravity.Exposure processing is performed on formerly obscured windows(including the window itself and its inferiors if regions of them wereobscured but now are not).Exposure processing is also performed on any new regions of the window(as a result of increasing the width or height)and on any regions where window contents are lost.

If the inside width or height of a window is not changedbut the window is moved or its border is changed,then the contents of the window are not lost but move with the window.Changing the inside width or height of the window causes its contents to bemoved or lost, depending on the bit-gravity of the window.It also causes children to be reconfigured, depending on their win-gravity.For a change of width and height of W and H,we define the [x, y] pairs as:

When a window with one of these bit-gravities is resized,the corresponding pair defines the change in position of each pixel in thewindow.When a window with one of these win-gravities has its parent window resized,the corresponding pair defines the change in positionof the window within the parent.This repositioning generates aGravityNotifyevent.GravityNotifyevents are generated after theConfigureNotifyevent is generated.

A gravity ofStaticindicates that the contents or origin should not move relative to the originof the root window.If the change in size of the window is coupled with a changein position of [X, Y],then for bit-gravity the change in position of each pixel is [-X, -Y] and forwin-gravity the change in position of a child when its parent is soresized is [-X, -Y].Note thatStaticgravity still only takes effect when the width or height of thewindow is changed, not when the window is simply moved.

A bit-gravity ofForgetindicates that the window contents are always discarded after a size change,even if backing-store or save-under has been requested.The window is tiled with its background (except, if no background is defined,the existing screen contents are not altered)and zero or more exposure events are generated.

The contents and borders of inferiors are not affected by their parent'sbit-gravity.A server is permitted to ignore the specified bit-gravity and useForgetinstead.

A win-gravity ofUnmapis likeNorthWest,but the child is also unmapped when the parent is resized,and anUnmapNotifyevent is generated.UnmapNotifyevents are generated after theConfigureNotifyevent is generated.

If a sibling and a stack-mode are specified,the window is restacked as follows:

If a stack-mode is specified but no sibling is specified,the window is restacked as follows:

It is aMatcherror if a sibling is specified without a stack-modeor if the window is not actually a sibling.

Note that the computations forBottomIf,TopIf,andOppositeare performed with respect to the window's final geometry (as controlled bythe other arguments to the request), not to its initial geometry.

Attempts to configure a root window have no effect.

If some other client has selectedSubstructureRedirecton the window, then aCirculateRequestevent is generated, and no further processing is performed.Otherwise, the following is performed, and then aCirculateNotifyevent is generated if the window is actually restacked.

ForRaiseLowest,CirculateWindowraises the lowest mapped child (if any) that isoccluded by another child to the top of the stack.ForLowerHighest,CirculateWindowlowers the highest mapped child (if any) that occludes another child tothe bottom of the stack.Exposure processing is performed on formerly obscured windows.

This request returns the root and current geometry of the drawable.The depth is the number of bits per pixel for the object.The x, y, and border-width will always be zero for pixmaps.For a window,the x and y coordinates specify the upper-left outer corner of the windowrelative to its parent's origin,and the width and height specify the inside size, not including the border.

It is legal to pass anInputOnlywindow as a drawable to this request.

This request returns the root, the parent, and the children of the window.The children are listed in bottom-to-top stacking order.

This request returns the atom for the given name.If only-if-exists isFalse,then the atom is created if it does not exist.The string should use the ISO Latin-1 encoding.Uppercase and lowercase matter.

The lifetime of an atom is not tied to the interning client.Atoms remain defined until server reset (seesection 10).

This request returns the name for the given atom.

This request alters the property for the specified window.The type is uninterpreted by the server.The format specifies whether the data should be viewed as a list of 8-bit,16-bit, or 32-bit quantities so that the server can correctly byte-swapas necessary.

If the mode isReplace,the previous property value is discarded.If the mode isPrependorAppend,then the type and format must match the existing property value (or aMatcherror results).If the property is undefined,it is treated as defined with the correct typeand format with zero-length data.ForPrepend,the data is tacked on to the beginning of the existing data, and forAppend,it is tacked on to the end of the existing data.

This request generates aPropertyNotifyevent on the window.

The lifetime of a property is not tied to the storing client.Properties remain until explicitly deleted, until the window is destroyed,or until server reset (seesection 10).

The maximum size of a property is server-dependent and may vary dynamically.

This request deletes the property from the specified windowif the property exists and generates aPropertyNotifyevent on the window unless the property does not exist.

If the specified property does not exist for the specified window,then the return type isNone,the format and bytes-after are zero,and the value is empty.The delete argument is ignored in this case.If the specified property exists but its type does not match the specified type,then the return type is the actual type of the property,the format is the actual format of the property (never zero),the bytes-after is the length of the property in bytes(even if the format is 16 or 32),and the value is empty.The delete argument is ignored in this case.If the specified property exists and eitherAnyPropertyTypeis specified or the specified type matches the actual type of the property,then the return type is the actual type of the property,the format is the actual format of the property (never zero),and the bytes-after and value are as follows, given:

N = actual length of the stored property in bytes    (even if the format is 16 or 32)I = 4 * long-offsetT = N - IL = MINIMUM(T, 4 * long-length)A = N - (I + L)

The returned value starts at byte index I in the property (indexing from 0),and its length in bytes is L.However, it is aValueerror if long-offset is given such that L is negative.The value of bytes-after is A,giving the number of trailing unread bytes in the storedproperty.If delete isTrueand the bytes-after is zero,the property is also deleted from the window,and aPropertyNotifyevent is generated on the window.

If the property names in the list are viewed as being numbered startingfrom zero, and there are N property names in the list,then the value associated with property name I becomes the valueassociated with property name (I + delta) mod N, for all I from zero to N - 1.The effect is to rotate the states by delta places around the virtual ringof property names (right for positive delta, left for negative delta).

If delta mod N is nonzero,aPropertyNotifyevent is generated for each property in the order listed.

If an atom occurs more than once in the list or no property with thatname is defined for the window,aMatcherror is generated.If anAtomorMatcherror is generated, no properties are changed.

This request returns the atoms of properties currently defined on the window.

This request changes the owner, owner window,and last-change time of the specified selection.This request has no effect if the specified time is earlierthan the current last-change time of the specified selection or islater than the current server time.Otherwise, the last-change time is set to the specified timewithCurrentTimereplaced by the current server time.If the owner window is specified asNone,then the owner of the selection becomesNone(that is, no owner).Otherwise, the owner of the selection becomes the client executing the request.If the new owner (whether a client orNone)is not the same as the current ownerand the current owner is notNone,then the current owner is sent aSelectionClearevent.

If the client that is the owner of a selection is later terminated(that is, its connection is closed) or if the owner window it hasspecified in the request is later destroyed,then the owner of the selection automatically reverts toNone,but the last-change time is not affected.

The selection atom is uninterpreted by the server.The owner window is returned by theGetSelectionOwnerrequest and is reported inSelectionRequestandSelectionClearevents.

Selections are global to the server.

This request returns the current owner window of the specified selection,if any.IfNoneis returned, then there is no owner for the selection.

If the specified selection has an owner,the server sends aSelectionRequestevent to that owner.If no owner for the specified selection exists,the server generates aSelectionNotifyevent to the requestor with propertyNone.The arguments are passed on unchanged in either of the events.

IfPointerWindowis specified,destination is replaced with the window that the pointer is in.IfInputFocusis specified and the focus window contains the pointer,destination is replaced with the window that the pointer is in.Otherwise, destination is replaced with the focus window.

If the event-mask is the empty set,then the event is sent to the client that created the destination window.If that client no longer exists, no event is sent.

If propagate isFalse,then the event is sent to every client selectingon destination any of the event types in event-mask.

If propagate isTrueand no clients have selected on destination anyof the event types in event-mask,then destination is replaced with theclosest ancestor of destination for which some client has selected atype in event-mask and no intervening window has that type in itsdo-not-propagate-mask.If no such window exists or if the window is an ancestor of the focus windowandInputFocuswas originally specified as the destination,then the event is not sent to any clients.Otherwise, the event is reported to every client selecting on the finaldestination any of the types specified in event-mask.

The event code must be one of the core events or one of the eventsdefined by an extension (or aValueerror results) so that the server can correctly byte-swap thecontents as necessary.The contents of the event are otherwise unaltered and uncheckedby the server except to force on the most significant bit of the event codeand to set the sequence number in the event correctly.

Active grabs are ignored for this request.

This request actively grabs control of the pointer.Further pointer events are only reported to the grabbing client.The request overrides any active pointer grab by this client.

If owner-events isFalse,all generated pointer events are reported with respect to grab-windowand are only reported if selected by event-mask.If owner-events isTrueand a generated pointer event would normally be reported to this client,it is reported normally.Otherwise, the event is reported with respect to the grab-window and isonly reported if selected by event-mask.For either value of owner-events,unreported events are simply discarded.

If pointer-mode isAsynchronous,pointer event processing continues normally.If the pointer is currently frozen by this client,then processing of pointer events is resumed.If pointer-mode isSynchronous,the state of the pointer (as seen by means of the protocol) appears to freeze,and no further pointer events are generated by the server until thegrabbing client issues a releasingAllowEventsrequest or until the pointer grab is released.Actual pointer changes are not lost while the pointer is frozen.They are simply queued for later processing.

If keyboard-mode isAsynchronous,keyboard event processing is unaffected by activation of the grab.If keyboard-mode isSynchronous,the state of the keyboard (as seen by means of the protocol) appears to freeze,and no further keyboard events are generated by the server until the grabbingclient issues a releasingAllowEventsrequest or until the pointer grab is released.Actual keyboard changes are not lost while the keyboard is frozen.They are simply queued for later processing.

If a cursor is specified,then it is displayed regardless of what window the pointer is in.If no cursor is specified,then when the pointer is in grab-window or one of its subwindows,the normal cursor for that window is displayed.Otherwise, the cursor for grab-window is displayed.

If a confine-to window is specified,then the pointer will be restricted to stay contained in that window.The confine-to window need have no relationship to the grab-window.If the pointer is not initially in the confine-to window,then it is warped automatically to the closest edge(and enter/leave events are generated normally) just before the grab activates.If the confine-to window is subsequently reconfigured,the pointer will be warped automatically as necessary tokeep it contained in the window.

This request generatesEnterNotifyandLeaveNotifyevents.

The request fails with statusAlreadyGrabbedif the pointer is actively grabbed by some other client.The request fails with statusFrozenif the pointer is frozen by an active grab of another client.The request fails with statusNotViewableif grab-window or confine-to window is not viewableor if the confine-to window lies completely outside the boundariesof the root window.The request fails with statusInvalidTimeif the specified time is earlier than the last-pointer-grab time or later thanthe current server time.Otherwise, the last-pointer-grab time is set to the specified time, withCurrentTimereplaced by the current server time.

This request releases the pointer if this client has it actively grabbed (fromeitherGrabPointerorGrabButtonor from a normal button press) and releases any queued events.The request has no effect if the specified time is earlier thanthe last-pointer-grab time or is later than the current server time.

This request generatesEnterNotifyandLeaveNotifyevents.

AnUngrabPointerrequest is performed automatically if the event window orconfine-to window for an active pointer grab becomes not viewableor if window reconfiguration causes the confine-to window to liecompletely outside the boundaries of the root window.

This request establishes a passive grab.In the future,the pointer is actively grabbed as described inGrabPointer,the last-pointer-grab time is set to the time at which the button waspressed (as transmitted in theButtonPressevent), and theButtonPressevent is reported if all of the following conditions are true:The pointer is not grabbed and the specified button is logically pressedwhen the specified modifier keys are logically down,and no other buttons or modifier keys are logically down.The grab-window contains the pointer.The confine-to window (if any) is viewable.A passive grab on the same button/key combination does not existon any ancestor of grab-window.

The interpretation of the remaining arguments is the same as forGrabPointer.The active grab is terminated automatically whenthe logical state of the pointer has all buttons released,independent of the logical state of modifier keys.Note that the logical state of a device (as seen by means of the protocol)may lag the physical state if device event processing is frozen.

This request overrides all previous passive grabs by the same client onthe same button/key combinations on the same window.A modifier ofAnyModifieris equivalent to issuing the request for all possible modifier combinations(including the combination of no modifiers).It is not required that all specified modifiers have currently assignedkeycodes.A button ofAnyButtonis equivalent to issuing the request for all possible buttons.Otherwise, it is not required that the button specified currently be assignedto a physical button.

AnAccesserror is generated if some other client has already issued aGrabButtonrequest with the same button/key combination on the same window.When usingAnyModifierorAnyButton,the request fails completely (no grabs are established), and anAccesserror is generated if there is a conflicting grab for any combination.The request has no effect on an active grab.

This request releases the passive button/key combinationon the specified window if it was grabbed by this client.A modifiers argument ofAnyModifieris equivalent to issuing the request for all possible modifiercombinations (including the combination of no modifiers).A button ofAnyButtonis equivalent to issuing the request for all possible buttons.The request has no effect on an active grab.

This request changes the specified dynamic parameters if the pointer isactively grabbed by the client and the specified time is no earlier than thelast-pointer-grab time and no later than the current server time.The interpretation of event-mask and cursor are the same as inGrabPointer.This request has no effect on the parameters of any passive grabs establishedwithGrabButton.

This request actively grabs control of the keyboard.Further key events are reported only to the grabbing client.This request overrides any active keyboard grab by this client.

If owner-events isFalse,all generated key events are reported with respect to grab-window.If owner-events isTrueand if a generated key event would normally be reported to this client,it is reported normally.Otherwise, the event is reported with respect to the grab-window.BothKeyPressandKeyReleaseevents are always reported,independent of any event selection made by the client.

If keyboard-mode isAsynchronous,keyboard event processing continues normally.If the keyboard is currently frozen by this client,then processing of keyboard events is resumed.If keyboard-mode isSynchronous,the state of the keyboard (as seen by means of the protocol) appears to freeze.No further keyboard events are generated by the server until thegrabbing client issues a releasingAllowEventsrequest or until the keyboard grab is released.Actual keyboard changes are not lost while the keyboard is frozen.They are simply queued for later processing.

If pointer-mode isAsynchronous,pointer event processing is unaffected by activation of the grab.If pointer-mode isSynchronous,the state of the pointer (as seen by means of the protocol) appears to freeze.No further pointer events are generated by the serveruntil the grabbing client issues a releasingAllowEventsrequest or until the keyboard grab is released.Actual pointer changes are not lost while the pointer is frozen.They are simply queued for later processing.

This request generatesFocusInandFocusOutevents.

The request fails with statusAlreadyGrabbedif the keyboard is actively grabbed by some other client.The request fails with statusFrozenif the keyboard is frozen by an active grab of another client.The request fails with statusNotViewableif grab-window is not viewable.The request fails with statusInvalidTimeif the specified time is earlier than the last-keyboard-grab timeor later than the current server time.Otherwise, the last-keyboard-grab time is set to the specified time withCurrentTimereplaced by the current server time.

This request releases the keyboard if this client has it actively grabbed(as a result of eitherGrabKeyboardorGrabKey)and releases any queued events.The request has no effect if the specified time is earlier than thelast-keyboard-grab time or is later than the current server time.

This request generatesFocusInandFocusOutevents.

AnUngrabKeyboardis performed automatically if the event window for an active keyboard grabbecomes not viewable.

This request establishes a passive grab on the keyboard.In the future,the keyboard is actively grabbed as described inGrabKeyboard,the last-keyboard-grab time is set to the time at which the key was pressed(as transmitted in theKeyPressevent), and theKeyPressevent is reported if all of the following conditions are true:The keyboard is not grabbed and the specified key(which can itself be a modifier key) is logically pressedwhen the specified modifier keys are logically down,and no other modifier keys are logically down.Either the grab-window is an ancestor of (or is) the focus window,or the grab-window is a descendent of the focus window and contains the pointer.A passive grab on the same key combination does not existon any ancestor of grab-window.

The interpretation of the remaining arguments is the same as forGrabKeyboard.The active grab is terminated automatically when the logical stateof the keyboard has the specified key released,independent of the logical state of modifier keys.Note that the logical state of a device (as seen by means of the protocol)may lag the physical state if device event processing is frozen.

This request overrides all previous passive grabs by the same clienton the same key combinations on the same window.A modifier ofAnyModifieris equivalent to issuing the request for all possible modifier combinations(including the combination of no modifiers).It is not required that all modifiers specified havecurrently assigned keycodes.A key ofAnyKeyis equivalent to issuing the request for all possible keycodes.Otherwise, the key must be in the range specified by min-keycodeand max-keycode in the connection setup (or aValueerror results).

AnAccesserror is generated if some other client has issued aGrabKeywith the same key combination on the same window.When usingAnyModifierorAnyKey,the request fails completely (no grabs are established),and anAccesserror is generated if there is a conflicting grab for any combination.

This request releases the key combination on the specified windowif it was grabbed by this client.A modifiers argument ofAnyModifieris equivalent to issuing the request for all possible modifier combinations(including the combination of no modifiers).A key ofAnyKeyis equivalent to issuing the request for all possible keycodes.This request has no effect on an active grab.

This request releases some queued events if the client has caused a device tofreeze.The request has no effect if the specified time is earlierthan the last-grab time of the most recent active grab for the clientor if the specified time is later than the current server time.

ForAsyncPointer,if the pointer is frozen by the client,pointer event processing continues normally.If the pointer is frozen twice by the client on behalf of two separate grabs,AsyncPointerthaws for both.AsyncPointerhas no effect if the pointer is not frozen by the client,but the pointer need not be grabbed by the client.

ForSyncPointer,if the pointer is frozen and actively grabbed by the client,pointer event processing continues normally until the nextButtonPressorButtonReleaseevent is reported to the client,at which time the pointer again appears to freeze.However, if the reported event causes the pointer grab to be released,then the pointer does not freeze.SyncPointerhas no effect if the pointer is not frozen by theclient or if the pointer is not grabbed by the client.

ForReplayPointer,if the pointer is actively grabbed by the client andis frozen as the result of an event having been sent to the client(either from the activation of aGrabButtonor from a previousAllowEventswith modeSyncPointerbut not from aGrabPointer),then the pointer grab is released and that event is completely reprocessed,this time ignoring any passive grabs at or above (towards the root)the grab-window of the grab just released.The request has no effect if the pointer is not grabbed by the clientor if the pointer is not frozen as the result of an event.

ForAsyncKeyboard,if the keyboard is frozen by the client,keyboard event processing continues normally.If the keyboard is frozen twice by the client on behalf of two separate grabs,AsyncKeyboardthaws for both.AsyncKeyboardhas no effect if the keyboard is not frozen by the client,but the keyboard need not be grabbed by the client.

ForSyncKeyboard,if the keyboard is frozen and actively grabbed by the client,keyboard event processing continues normally until the nextKeyPressorKeyReleaseevent is reported to the client,at which time the keyboard again appears to freeze.However, if the reported event causes the keyboard grab to be released,then the keyboard does not freeze.SyncKeyboardhas no effect if the keyboard is not frozen by the client orif the keyboard is not grabbed by the client.

ForReplayKeyboard,if the keyboard is actively grabbed by the clientand is frozen as the result of an event having been sent to the client(either from the activation of aGrabKeyor from a previousAllowEventswith modeSyncKeyboardbut not from aGrabKeyboard),then the keyboard grab is released and that event is completely reprocessed,this time ignoring any passive grabs at or above (towards the root)the grab-window of the grab just released.The request has no effect if the keyboard is not grabbed by the clientor if the keyboard is not frozen as the result of an event.

ForSyncBoth,if both pointer and keyboard are frozen by the client,event processing (for both devices) continues normally until the nextButtonPress,ButtonRelease,KeyPress,orKeyReleaseevent is reported to the client for a grabbed device(button event for the pointer, key event for the keyboard),at which time the devices again appear to freeze.However, if the reported event causes the grab to be released,then the devices do not freeze (but if the other device is stillgrabbed, then a subsequent event for it will still cause both devicesto freeze).SyncBothhas no effect unless both pointer and keyboard are frozen by the client.If the pointer or keyboard is frozen twice by the client on behalfof two separate grabs,SyncBoththaws for both (but a subsequent freeze forSyncBothwill only freeze each device once).

ForAsyncBoth,if the pointer and the keyboard are frozen by the client,event processing for both devices continues normally.If a device is frozen twice by the client on behalf of two separate grabs,AsyncBoththaws for both.AsyncBothhas no effect unless both pointer and keyboard are frozen by the client.

AsyncPointer,SyncPointer,andReplayPointerhave no effect on processing of keyboard events.AsyncKeyboard,SyncKeyboard,andReplayKeyboardhave no effect on processing of pointer events.

It is possible for both a pointer grab and a keyboard grab to be activesimultaneously (by the same or different clients).When a device is frozen on behalf of either grab,no event processing is performed for the device.It is possible for a single device to be frozen because of both grabs.In this case, the freeze must be released on behalf of both grabsbefore events can again be processed.If a device is frozen twice by a single client, then a singleAllowEventsreleases both.

This request disables processing of requests and close-downs on allconnections other than the one this request arrived on.

This request restarts processing of requests and close-downson other connections.

The root window the pointer is logically on and the pointer coordinatesrelative to the root's origin are returned.If same-screen isFalse,then the pointer is not on the same screen as the argument window,child isNone,and win-x and win-y are zero.If same-screen isTrue,then win-x and win-y are the pointer coordinates relative to theargument window's origin, and child is the child containing thepointer, if any.The current logical state of the modifier keys and the buttonsare also returned.Note that the logical state of a device (as seen by means of the protocol)may lag the physical state if device event processing is frozen.

This request returns all events in the motion history buffer that fallbetween the specified start and stop times (inclusive)and that have coordinates that lie within (including borders)the specified window at its present placement.The x and y coordinates are reported relative to the origin of the window.

If the start time is later than the stop time or if the start time isin the future, no events are returned.If the stop time is in the future, it is equivalent to specifyingCurrentTime.

The src-x and src-y coordinates are taken relative to src-window'sorigin and are returned as dst-x and dst-y coordinates relative todst-window's origin.If same-screen isFalse,then src-window and dst-window are on different screens,and dst-x and dst-y are zero.If the coordinates are contained in a mapped child of dst-window,then that child is returned.

If dst-window isNone,this request moves the pointer by offsets [dst-x, dst-y]relative to the current position of the pointer.If dst-window is a window,this request moves the pointer to [dst-x, dst-y] relative to dst-window'sorigin.However, if src-window is notNone,the move only takes place if src-window contains the pointerand the pointer is contained in the specified rectangle of src-window.

The src-x and src-y coordinates are relative to src-window's origin.If src-height is zero,it is replaced with the current height of src-window minus src-y.If src-width is zero,it is replaced with the current width of src-window minus src-x.

This request cannot be used to move the pointer outside the confine-towindow of an active pointer grab.An attempt will only move the pointer as far as the closest edgeof the confine-to window.

This request will generate events just as if the user had instantaneouslymoved the pointer.

This request changes the input focus and the last-focus-change time.The request has no effect if the specified time is earlier than the currentlast-focus-change time or is later than the current server time.Otherwise, the last-focus-change time is set to the specified timewithCurrentTimereplaced by the current server time.

IfNoneis specified as the focus,all keyboard events are discarded until a new focus window is set.In this case, the revert-to argument is ignored.

If a window is specified as the focus,it becomes the keyboard's focus window.If a generated keyboard event would normally be reported tothis window or one of its inferiors, the event is reported normally.Otherwise, the event is reported with respect to the focus window.

IfPointerRootis specified as the focus,the focus window is dynamically taken to be the root window of whatever screenthe pointer is on at each keyboard event.In this case,the revert-to argument is ignored.

This request generatesFocusInandFocusOutevents.

The specified focus window must be viewable at the time of the request (or aMatcherror results).If the focus window later becomes not viewable,the new focus window depends on the revert-to argument.If revert-to isParent,the focus reverts to the parent (or the closest viewable ancestor)and the new revert-to value is taken to beNone.If revert-to isPointerRootorNone,the focus reverts to that value.When the focus reverts,FocusInandFocusOutevents are generated,but the last-focus-change time is not affected.

This request returns the current focus state.

This request returns a bit vector for the logical state of the keyboard.Each bit set to 1 indicates that the corresponding key is currently pressed.The vector is represented as 32 bytes.Byte N (from 0) contains the bits for keys 8N to 8N + 7with the least significant bit in the byte representing key 8N.Note that the logical state of a device (as seen by means of the protocol)may lag the physical state if device event processing is frozen.

This request loads the specified font, if necessary,and associates identifier fid with it.The font name should use the ISO Latin-1 encoding,and uppercase and lowercase do not matter.When the characters“?” and“*” are used in a font name, apattern match is performed and any matching font is used.In the pattern,the“?” character (octal value 77) will match any single character,and the“*” character (octal value 52) will match any numberof characters.A structured format for font names is specified in theX.Org standardX Logical Font Description Conventions.

Fonts are not associated with a particular screenand can be stored as a component of any graphics context.

This request deletes the association between the resource ID and the font.The font itself will be freed when no other resource references it.

This request returns logical information about a font.If a gcontext is given for font,the currently contained font is used.

The draw-direction is just a hintand indicates whether most char-infos have a positive,LeftToRight,or a negative,RightToLeft,character-width metric.The core protocol defines no support for vertical text.

If min-byte1 and max-byte1 are both zero,then min-char-or-byte2 specifies the linear character index correspondingto the first element of char-infos,and max-char-or-byte2 specifies the linear character index of the last element.If either min-byte1 or max-byte1 are nonzero,then both min-char-or-byte2 and max-char-or-byte2 will be less than 256,and the 2-byte character index values corresponding to char-infos element N(counting from 0) are:

byte1 = N/D + min-byte1byte2 = N\\D + min-char-or-byte2

where:

D = max-char-or-byte2 - min-char-or-byte2 + 1/ = integer division\\ = integer modulus

If char-infos has length zero,then min-bounds and max-bounds will be identical,and the effective char-infos is one filled with this char-info, of length:

L = D * (max-byte1 - min-byte1 + 1)

That is,all glyphs in the specified linear or matrix range have the same information,as given by min-bounds (and max-bounds).If all-chars-exist isTrue,then all characters in char-infos have nonzero bounding boxes.

The default-char specifies the character that will be used when anundefined or nonexistent character is used.Note that default-char is a CARD16, not CHAR2B.For a font using 2-byte matrix format,the default-char has byte1 in the most significant byteand byte2 in the least significant byte.If the default-char itself specifies an undefined or nonexistent character,then no printing is performed for an undefined or nonexistent character.

The min-bounds and max-bounds contain the minimum and maximum values ofeach individual CHARINFO component over all char-infos (ignoringnonexistent characters).The bounding box of the font (that is, thesmallest rectangle enclosing the shape obtained by superimposing allcharacters at the same origin [x,y]) has its upper-left coordinate at:

[x + min-bounds.left-side-bearing, y - max-bounds.ascent]

with a width of:

max-bounds.right-side-bearing - min-bounds.left-side-bearing

and a height of:

max-bounds.ascent + max-bounds.descent

The font-ascent is the logical extent of the font above the baselineand is used for determining line spacing.Specific characters may extend beyond this.The font-descent is the logical extent of the font at or below the baselineand is used for determining line spacing.Specific characters may extend beyond this.If the baseline is at Y-coordinate y,then the logical extent of the font is inclusivebetween the Y-coordinate values (y - font-ascent) and (y + font-descent - 1).

A font is not guaranteed to have any properties.The interpretation of the property value (for example, INT32, CARD32)must be derived froma priori knowledge of the property.A basic set of font properties is specified in the X.OrgstandardX Logical Font Description Conventions.

For a character origin at [x,y],the bounding box of a character (that is,the smallest rectangle enclosing the character's shape), described interms of CHARINFO components, is a rectangle with its upper-left corner at:

[x + left-side-bearing, y - ascent]

with a width of:

right-side-bearing - left-side-bearing

and a height of:

ascent + descent

and the origin for the next character is defined to be:

[x + character-width, y]

Note that the baseline is logically viewed as being just belownondescending characters (when descent is zero, only pixels withY-coordinates less than y are drawn) and that the origin is logicallyviewed as being coincident with the left edge of a nonkerned character(when left-side-bearing is zero, no pixels with X-coordinate less thanx are drawn).

Note that CHARINFO metric values can be negative.

A nonexistent character is represented with all CHARINFO componentszero.

The interpretation of the per-character attributes field isserver-dependent.

This request returns the logical extents of the specified string of charactersin the specified font.If a gcontext is given for font,the currently contained font is used.The draw-direction, font-ascent, and font-descent are the same asdescribed inQueryFont.The overall-ascent is the maximum of the ascent metrics of all charactersin the string, and the overall-descent is the maximum of the descent metrics.The overall-width is the sum of the character-width metrics of all charactersin the string.For each character in the string,let W be the sum of the character-width metrics of all characters preceding itin the string,let L be the left-side-bearing metric of the character plus W,and let R be the right-side-bearing metric of the character plus W.The overall-left is the minimum L of all characters in the string,and the overall-right is the maximum R.

For fonts defined with linear indexing rather than 2-byte matrix indexing,the server will interpret each CHAR2B as a 16-bit number thathas been transmitted most significant byte first (that is, byte1 of theCHAR2B is taken as the most significant byte).

Characters with all zero metrics are ignored.If the font has no defined default-char,then undefined characters in the string are also ignored.

This request returns a listof available font names (as controlled by the font search path; seeSetFontPathrequest)that match the pattern.At most, max-names names will be returned.The pattern should use the ISO Latin-1 encoding,and uppercase and lowercase do not matter.In the pattern,the“?” character (octal value 77) will match any single character,and the“*” character (octal value 52) will match any numberof characters.The returned names are in lowercase.

This request is similar toListFonts,but it also returns information about each font.The information returned for each font is identical to whatQueryFontwould return except that the per-character metrics are not returned.Note that this request can generate multiple replies.With each reply,replies-hint may provide an indication of how many more fonts will be returned.This number is a hint only and may be larger or smaller thanthe number of fonts actually returned.A zero value does not guarantee that no more fonts will be returned.After the font replies,a reply with a zero-length name is sent to indicate the end of the replysequence.

This request defines the search path for font lookup.There is only one search path per server, not one per client.The interpretation of the strings is operating-system-dependent,but the strings are intended to specify directories to be searched in theorder listed.

Setting the path to the empty list restores the default path definedfor the server.

As a side effect of executing this request,the server is guaranteed to flush all cached information about fontsfor which there currently are no explicit resource IDs allocated.

The meaning of an error from this request is system specific.

This request returns the current search path for fonts.

This request creates a pixmap and assigns the identifier pid to it.The width and height must be nonzero (or aValueerror results).The depth must be one of the depths supported by the root of the specifieddrawable (or aValueerror results).The initial contents of the pixmap are undefined.

It is legal to pass anInputOnlywindow as a drawable to this request.

This request deletes the association between the resource ID and the pixmap.The pixmap storage will be freed when no other resource references it.

This request creates a graphics contextand assigns the identifier cid to it.The gcontext can be used with any destination drawable having the same rootand depth as the specified drawable;use with other drawables results in aMatcherror.

The value-mask and value-list specify which components are to beexplicitly initialized.The context components are:

In graphics operations,given a source and destination pixel,the result is computed bitwise on corresponding bits of the pixels;that is, a Boolean operation is performed in each bit plane.The plane-mask restricts the operation to a subset of planes,so the result is:

((src FUNC dst) AND plane-mask) OR (dst AND (NOT plane-mask))

Range checking is not performed on the values for foreground, background,or plane-mask.They are simply truncated to the appropriate number of bits.

The meanings of the functions are:

The line-width is measured in pixels and can be greater than or equal toone, a wide line, or the special value zero, a thin line.

Wide lines are drawn centered on the path described by the graphics request.Unless otherwise specified by the join or cap style,the bounding box of a wide line with endpoints [x1, y1], [x2, y2] andwidth w is a rectangle with vertices at the following real coordinates:

[x1-(w*sn/2), y1+(w*cs/2)], [x1+(w*sn/2), y1-(w*cs/2)],[x2-(w*sn/2), y2+(w*cs/2)], [x2+(w*sn/2), y2-(w*cs/2)]

The sn is the sine of the angle of the line and cs is the cosine ofthe angle of the line.A pixel is part of the line (and hence drawn) if the center of the pixelis fully inside the bounding box, which is viewed as having infinitely thinedges.If the center of the pixel is exactly on the bounding box,it is part of the line if and only if the interior is immediately to its right(x increasing direction).Pixels with centers on a horizontal edge are a special case and are part ofthe line if and only if the interior or the boundary is immediately below(y increasing direction) and if the interior or the boundary is immediatelyto the right (x increasing direction).Note that this description is a mathematical model describing the pixelsthat are drawn for a wide line and does not imply that trigonometry is requiredto implement such a model.Real or fixed point arithmetic is recommended for computing the corners of theline endpoints for lines greater than one pixel in width.

Thin lines (zero line-width) are nominally one pixel wide lines drawn using anunspecified, device-dependent algorithm.There are only two constraints on this algorithm.First, if a line is drawn unclipped from [x1,y1] to [x2,y2]and another line is drawn unclipped from [x1+dx,y1+dy] to [x2+dx,y2+dy],then a point [x,y] is touched by drawing the first line ifand only if the point [x+dx,y+dy] is touched by drawing the second line.Second, the effective set of points comprising a line cannot be affectedby clipping.Thus, a point is touched in a clipped line if and only if the point liesinside the clipping region and the point would be touched by the linewhen drawn unclipped.

Note that a wide line drawn from [x1,y1] to [x2,y2] always draws thesame pixels as a wide line drawn from [x2,y2] to [x1,y1], not countingcap-style and join-style.Implementors are encouraged to make this property true for thin lines,but it is not required.A line-width of zero may differ from a line-width of one in which pixelsare drawn.In general,drawing a thin line will be faster than drawing a wide line of width one,but thin lines may not mix well aesthetically with wide linesbecause of the different drawing algorithms.If it is desirable to obtain precise and uniform results across all displays,a client should always use a line-width of one, rather than a line-width ofzero.

The line-style defines which sections of a line are drawn:

The cap-style defines how the endpoints of a path are drawn:

The join-style defines how corners are drawn for wide lines:

For a line with coincident endpoints (x1=x2, y1=y2), when the cap-styleis applied to both endpoints, the semantics depends on the line-widthand the cap-style:

For a line with coincident endpoints (x1=x2, y1=y2),when the join-style is applied at one or both endpoints,the effect is as if the line was removed from the overall path.However, if the total path consists of (or is reduced to) a single pointjoined with itself,the effect is the same as when the cap-style is applied at both endpoints.

The tile/stipple represents an infinite two-dimensional planewith the tile/stipplereplicated in all dimensions. When that plane is superimposed onthe drawable for use in a graphics operation, the upper-left cornerof some instance of the tile/stipple is at the coordinates withinthe drawable specified by the tile/stipple origin.The tile/stipple and clip origins are interpreted relative to theorigin of whatever destination drawable is specified in a graphicsrequest.

The tile pixmap must have the same root and depth as the gcontext (or aMatcherror results).The stipple pixmap must have depth one and must have the same rootas the gcontext (or aMatcherror results).For fill-styleStippled(but not fill-styleOpaqueStippled),the stipple pattern is tiled in a single planeand acts as an additional clip mask to be ANDed with the clip-mask.Any size pixmap can be used for tiling or stippling,although some sizes may be faster to use than others.

The fill-style defines the contents of the source for line, text, andfill requests.For all text and fill requests (for example,PolyText8,PolyText16,PolyFillRectangle,FillPoly,andPolyFillArc)as well as for line requests with line-styleSolid,(for example,PolyLine,PolySegment,PolyRectangle,PolyArc )and for the even dashes for line requests with line-styleOnOffDashorDoubleDash:

For the odd dashes for line requests with line-styleDoubleDash:

The dashes value allowed here is actually a simplified form of the moregeneral patterns that can be set withSetDashes.Specifying a value of N here is equivalent to specifyingthe two element list [N, N] inSetDashes.The value must be nonzero (or aValueerror results).The meaning of dash-offset and dashes are explained in theSetDashesrequest.

The clip-mask restricts writes to the destination drawable.Only pixels where the clip-mask has bits set to 1 are drawn.Pixels are not drawn outside the area covered by the clip-maskor where the clip-mask has bits set to 0.The clip-mask affects all graphics requests,but it does not clip sources.The clip-mask origin is interpreted relative to the origin of whateverdestination drawable is specified in a graphics request.If a pixmap is specified as the clip-mask,it must have depth 1 and have the same root as the gcontext (or aMatcherror results).If clip-mask isNone,then pixels are always drawn, regardless of the clip origin.The clip-mask can also be set with theSetClipRectanglesrequest.

ForClipByChildren,both source and destination windows are additionally clipped by all viewableInputOutputchildren.ForIncludeInferiors,neither source nor destination window is clipped by inferiors.This will result in including subwindow contents in thesource and drawing through subwindow boundaries of the destination.The use ofIncludeInferiorswith a source or destination window of one depth with mapped inferiorsof differing depth is not illegal,but the semantics is undefined by the core protocol.

The fill-rule defines what pixels are inside (that is, are drawn) forpaths given inFillPolyrequests.EvenOddmeans a point is inside if an infinite ray with the point as origin crossesthe path an odd number of times.ForWinding,a point is inside if an infinite ray with the point as origin crosses anunequal number of clockwise and counterclockwise directed path segments.A clockwise directed path segment is one that crosses the ray from leftto right as observed from the point.A counter-clockwise segment is one that crosses the ray from right to leftas observed from the point.The case where a directed line segment is coincident with the ray isuninteresting because one can simply choose a different ray that is notcoincident with a segment.

For both fill rules,a point is infinitely small and the path is an infinitely thin line.A pixel is inside if the center point of the pixel is insideand the center point is not on the boundary.If the center point is on the boundary,the pixel is inside if and only if the polygon interior is immediatelyto its right (x increasing direction).Pixels with centers along a horizontal edge are a special caseand are inside if and only if the polygon interior is immediately below(y increasing direction).

The arc-mode controls filling in thePolyFillArcrequest.

The graphics-exposures flag controlsGraphicsExposureevent generation forCopyAreaandCopyPlanerequests (and any similar requests defined by extensions).

The default component values are:

Storing a pixmap in a gcontext might or might not result in a copybeing made.If the pixmap is later used as the destination for a graphics request,the change might or might not be reflected in the gcontext.If the pixmap is used simultaneously in a graphics requestas both a destination and as a tile or stipple,the results are not defined.

It is quite likely that some amount of gcontext information will becached in display hardware and that such hardware can only cache asmall number of gcontexts.Given the number and complexity of components,clients should view switching between gcontexts with nearlyidentical state as significantly more expensive than making minorchanges to a single gcontext.

This request changes components in gc.The value-mask and value-list specify which components are to be changed.The values and restrictions are the sameas forCreateGC.

Changing the clip-mask also overrides any previousSetClipRectanglesrequest on the context.Changing dash-offset or dashes overrides any previousSetDashesrequest on the context.

The order in which components are verified and altered is server-dependent.If an error is generated,a subset of the components may have been altered.

This request copies components from src-gc to dst-gc.The value-mask specifies which components to copy, as forCreateGC.The two gcontexts must have the same root and the same depth (or aMatcherror results).

This request sets dash-offset and dashes in gc for dashed line styles.Dashes cannot be empty (or aValueerror results).Specifying an odd-length list is equivalent to specifying the same listconcatenated with itself to produce an even-length list.The initial and alternating elements of dashes are the even dashes;the others are the odd dashes.Each element specifies a dash length in pixels.All of the elements must be nonzero (or aValueerror results).The dash-offset defines the phase of the pattern,specifying how many pixels into dashes the pattern should actually begin inany single graphics request.Dashing is continuous through path elements combined with a join-stylebut is reset to the dash-offset between each sequence of joined lines.

The unit of measure for dashes is the same as in the ordinarycoordinate system.Ideally, a dash length is measured along the slope of the line,but implementations are only required to match this idealfor horizontal and vertical lines.Failing the ideal semantics,it is suggested that the length be measured along the major axis of the line.The major axis is defined as the x axis for lines drawn at an angle ofbetween -45 and +45 degrees or between 135 and 225 degrees from the x axis.For all other lines, the major axis is the y axis.

For any graphics primitive, the computation of the endpoint of an individualdash only depends on the geometry of the primitive, the start positionof the dash, the direction of the dash, and the dash length.

For any graphics primitive, the total set of pixels used to render theprimitive (both even and odd numbered dash elements) withDoubleDashline-style is the same as the set of pixels used to render theprimitive withSolidline-style.

For any graphics primitive, if the primitive is drawn withOnOffDashorDoubleDashline-style unclipped at position [x,y] and again at position[x+dx,y+dy], then a point [x1,y1] is included in a dash in the firstinstance if and only if the point [x1+dx,y1+dy] is included in the dash inthe second instance. In addition, the effective set of points comprising adash cannot be affected by clipping. A point is included in a clipped dashif and only if the point lies inside the clipping region and the pointwould be included in the dash when drawn unclipped.

This request changes clip-mask in gc to the specified list of rectanglesand sets the clip origin.Output will be clipped to remain contained within the rectangles.The clip origin is interpreted relative to the origin ofwhatever destination drawable is specified in a graphics request.The rectangle coordinates are interpreted relative to the clip origin.The rectangles should be nonintersecting, or graphics results will beundefined.Note that the list of rectangles can be empty,which effectively disables output.This is the opposite of passingNoneas the clip-mask inCreateGCandChangeGC.

If known by the client,ordering relations on the rectangles can be specified with the orderingargument.This may provide faster operation by the server.If an incorrect ordering is specified,the server may generate aMatcherror, but it is not required to do so.If no error is generated,the graphics results are undefined.UnSortedmeans that the rectangles are in arbitrary order.YSortedmeans that the rectangles are nondecreasing in their Y origin.YXSortedadditionally constrainsYSortedorder in that all rectangles with an equal Y origin arenondecreasing in their X origin.YXBandedadditionally constrainsYXSortedby requiring that, for every possible Y scanline,all rectangles that include that scanline have identical Y origins and Yextents.

This request deletes the association between the resource ID and the gcontextand destroys the gcontext.

The x and y coordinates are relative to the window's originand specify the upper-left corner of the rectangle.If width is zero,it is replaced with the current width of the window minus x.If height is zero,it is replaced with the current height of the window minus y.If the window has a defined background tile,the rectangle is tiled with a plane-mask of all ones and function ofCopyand a subwindow-mode ofClipByChildren.If the window has backgroundNone,the contents of the window are not changed.In either case,if exposures isTrue,then one or more exposure events are generated for regions of the rectanglethat are either visible or are being retained in a backing store.

It is aMatcherror to use anInputOnlywindow in this request.

This request combines the specified rectangle of src-drawable with thespecified rectangle of dst-drawable.The src-x and src-y coordinates are relative to src-drawable's origin.The dst-x and dst-y are relative to dst-drawable's origin,each pair specifying the upper-left corner of the rectangle.The src-drawable must have the same root and the same depthas dst-drawable (or aMatcherror results).

If regions of the source rectangle are obscured and have not been retainedin backing storeor if regions outside the boundaries of the source drawable are specified,then those regions are not copied,but the following occurs on all corresponding destination regions that areeither visible or are retained in backing-store.If the dst-drawable is a window with a background other thanNone,these corresponding destination regions are tiled(with plane-mask of all ones and functionCopy)with that background.Regardless of tiling and whether the destination is a window or a pixmap,if graphics-exposures in gc isTrue,thenGraphicsExposureevents for all corresponding destination regions are generated.

If graphics-exposures isTruebut noGraphicsExposureevents are generated,then aNoExposureevent is generated.

GC components: function, plane-mask, subwindow-mode,graphics-exposures, clip-x-origin, clip-y-origin, clip-mask

The src-drawable must have the same root as dst-drawable (or aMatcherror results), but it need not have the same depth.The bit-plane must have exactly one bit set to 1 and the value of bit-planemust be less than %2 sup n% wheren is the depth of src-drawable (or aValueerror results).Effectively, a pixmap of the same depth as dst-drawable and with size specifiedby the source region is formed using the foreground/background pixels in gc(foreground everywhere the bit-plane in src-drawable contains a bit set to 1,background everywhere the bit-plane contains a bit set to 0),and the equivalent of aCopyAreais performed, with all the same exposure semantics.This can also be thought of as using the specified region of the sourcebit-plane as a stipple with a fill-style ofOpaqueStippledfor filling a rectangular area of the destination.

GC components: function, plane-mask, foreground, background,subwindow-mode, graphics-exposures, clip-x-origin, clip-y-origin,clip-mask

This request combines the foreground pixel in gc with the pixelat each point in the drawable.The points are drawn in the order listed.

The first point is always relative to the drawable's origin.The rest are relative either to that origin or the previous point,depending on the coordinate-mode.

GC components: function, plane-mask, foreground, subwindow-mode,clip-x-origin, clip-y-origin, clip-mask

This request draws lines between each pair of points (point[i], point[i+1]).The lines are drawn in the order listed.The lines join correctly at all intermediate points,and if the first and last points coincide,the first and last lines also join correctly.

For any given line,no pixel is drawn more than once.If thin (zero line-width) lines intersect,the intersecting pixels are drawn multiple times.If wide lines intersect,the intersecting pixels are drawn only once, as though the entirePolyLinewere a single filled shape.

The first point is always relative to the drawable's origin.The rest are relative either to that origin or the previous point,depending on the coordinate-mode.

When either of the two lines involved in aBeveljoin is neither verticalnor horizontal, then the slope and position of the line segment definingthe bevel join edge is implementation dependent. However, the computationof the slope and distance (relative to the join point) only depends onthe line width and the slopes of the two lines.

GC components: function, plane-mask, line-width, line-style,cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,clip-y-origin, clip-mask

GC mode-dependent components: foreground, background, tile, stipple,tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes

For each segment,this request draws a line between [x1, y1] and [x2, y2].The lines are drawn in the order listed.No joining is performed at coincident endpoints.For any given line,no pixel is drawn more than once.If lines intersect,the intersecting pixels are drawn multiple times.

GC components: function, plane-mask, line-width, line-style,cap-style, fill-style, subwindow-mode, clip-x-origin, clip-y-origin,clip-mask

GC mode-dependent components: foreground, background, tile, stipple,tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes

This request draws the outlines of the specified rectangles, as if a five-pointPolyLinewere specified for each rectangle:

[x,y] [x+width,y] [x+width,y+height] [x,y+height] [x,y]

The x and y coordinates of each rectangle are relative to the drawable's originand define the upper-left corner of the rectangle.

The rectangles are drawn in the order listed.For any given rectangle,no pixel is drawn more than once.If rectangles intersect,the intersecting pixels are drawn multiple times.

GC components: function, plane-mask, line-width, line-style,cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,clip-y-origin, clip-mask

GC mode-dependent components: foreground, background, tile, stipple,tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes

This request draws circular or elliptical arcs.Each arc is specified by a rectangle and two angles.The angles are signed integers in degrees scaled by 64,with positive indicating counterclockwise motion andnegative indicating clockwise motion.The start of the arc is specified by angle1 relative to the three-o'clockposition from the center of the rectangle,and the path and extent of the arc is specified by angle2 relative to thestart of the arc.If the magnitude of angle2 is greater than 360 degrees,it is truncated to 360 degrees.The x and y coordinates of the rectangle are relative to the origin ofthe drawable.For an arc specified as [x,y,w,h,a1,a2],the origin of the major and minor axes is at [x+(w/2),y+(h/2)],and the infinitely thin path describing the entire circle/ellipse intersectsthe horizontal axis at [x,y+(h/2)] and [x+w,y+(h/2)] and intersects thevertical axis at [x+(w/2),y] and [x+(w/2),y+h].These coordinates are not necessarily integral; that is,they are not truncated to discrete coordinates.

For a wide line with line-width lw, the ideal bounding outlines for fillingare given by the two infinitely thin paths consisting of all points whoseperpendicular distance from a tangent to the path of the circle/ellipse isequal to lw/2 (which may be a fractional value). When the width and heightof the arc are not equal and both are nonzero, then the actual boundingoutlines are implementation dependent. However, the computation of theshape and position of the bounding outlines (relative to the center of thearc) only depends on the width and height of the arc and theline-width.

The cap-style is applied the same as for a line corresponding to thetangent of the circle/ellipse at the endpoint. When the angle of an arcface is not an integral multiple of 90 degrees, and the width and height ofthe arc are both are nonzero, then the shape and position of the cap atthat face is implementation dependent. However, for aButtcap, the faceis defined by a straight line, and the computation of the position(relative to the center of the arc) and the slope of the line onlydepends on the width and height of the arc and the angle of the arc face.For other cap styles, the computation of the position (relative to thecenter of the arc) and the shape of the cap only depends on the widthand height of the arc, the line-width, the angle of the arc face, and thedirection (clockwise or counter clockwise) of the arc from the endpoint.

The join-style is applied the same as for two lines corresponding to thetangents of the circles/ellipses at the join point. When the width andheight of both arcs are nonzero, and the angle of either arc face is not anintegral multiple of 90 degrees, then the shape of the join isimplementation dependent. However, the computation of the shape onlydepends on the width and height of each arc, the line-width, the angles ofthe two arc faces, the direction (clockwise or counter clockwise) of thearcs from the join point, and the relative orientation of the two arccenter points.

For an arc specified as [x,y,w,h,a1,a2],the angles must be specified in the effectively skewed coordinate system ofthe ellipse (for a circle, the angles and coordinate systems are identical).The relationship between these angles and angles expressed in the normalcoordinate system of the screen (as measured with a protractor) is asfollows:

skewed-angle = atan(tan(normal-angle) * w/h) + adjust

The skewed-angle and normal-angle are expressed in radians (ratherthan in degrees scaled by 64) in the range [0,2*PI).The atan returns a value in the range [-PI/2,PI/2].The adjust is:

The arcs are drawn in the order listed.If the last point in one arc coincides with the first point in the followingarc,the two arcs will join correctly.If the first point in the first arc coincides with the last pointin the last arc,the two arcs will join correctly.For any given arc,no pixel is drawn more than once.If two arcs join correctly and the line-width is greater than zeroand the arcs intersect,no pixel is drawn more than once.Otherwise, the intersecting pixels of intersecting arcs are drawn multipletimes.Specifying an arc with one endpoint and a clockwise extent draws thesame pixels as specifying the other endpoint and an equivalentcounterclockwise extent, except as it affects joins.

By specifying one axis to be zero,a horizontal or vertical line can be drawn.

Angles are computed based solely on the coordinate system,ignoring the aspect ratio.

GC components: function, plane-mask, line-width, line-style,cap-style, join-style, fill-style, subwindow-mode, clip-x-origin,clip-y-origin, clip-mask

GC mode-dependent components: foreground, background, tile, stipple,tile-stipple-x-origin, tile-stipple-y-origin, dash-offset, dashes

This request fills the region closed by the specified path.The path is closed automatically if the last point in the list does notcoincide with the first point.No pixel of the region is drawn more than once.

The first point is always relative to the drawable's origin.The rest are relative either to that origin or the previous point,depending on the coordinate-mode.

The shape parameter may be used by the server to improve performance.Complexmeans the path may self-intersect.Contiguous coincident points in the path are not treatedas self-intersection.

Nonconvexmeans the path does not self-intersect,but the shape is not wholly convex.If known by the client,specifyingNonconvexoverComplexmay improve performance.IfNonconvexis specified for a self-intersecting path,the graphics results are undefined.

Convexmeans that for every pair of points inside the polygon,the line segment connecting them does not intersect the path.If known by the client,specifyingConvexcan improve performance.IfConvexis specified for a path that is not convex,the graphics results are undefined.

GC components: function, plane-mask, fill-style, fill-rule,subwindow-mode, clip-x-origin, clip-y-origin, clip-mask

GC mode-dependent components: foreground, background, tile, stipple,tile-stipple-x-origin, tile-stipple-y-origin

This request fills the specified rectangles, as if a four-pointFillPolywere specified for each rectangle:

[x,y] [x+width,y] [x+width,y+height] [x,y+height]

The x and y coordinates of each rectangle are relative to the drawable's originand define the upper-left corner of the rectangle.

The rectangles are drawn in the order listed.For any given rectangle,no pixel is drawn more than once.If rectangles intersect,the intersecting pixels are drawn multiple times.

GC components: function, plane-mask, fill-style, subwindow-mode,clip-x-origin, clip-y-origin, clip-mask

GC mode-dependent components: foreground, background, tile, stipple,tile-stipple-x-origin, tile-stipple-y-origin

For each arc,this request fills the region closed by the infinitely thin pathdescribed by the specified arc and one or two line segments,depending on the arc-mode.ForChord,the single line segment joining the endpoints of the arc is used.ForPieSlice,the two line segments joining the endpoints of the arc with the center pointare used.

For an arc specified as [x,y,w,h,a1,a2], the origin of the major and minoraxes is at [x+(w/2),y+(h/2)], and the infinitely thin path describing theentire circle/ellipse intersects the horizontal axis at [x,y+(h/2)] and[x+w,y+(h/2)] and intersects the vertical axis at [x+(w/2),y] and[x+(w/2),y+h]. These coordinates are not necessarily integral; that is,they are not truncated to discrete coordinates.

The arc angles are interpreted as specified in thePolyArcrequest. Whenthe angle of an arc face is not an integral multiple of 90 degrees, thenthe precise endpoint on the arc is implementation dependent. However, forChordarc-mode, the computation of the pair of endpoints (relative to thecenter of the arc) only depends on the width and height of the arc andthe angles of the two arc faces. ForPieSlicearc-mode, the computation ofan endpoint only depends on the angle of the arc face for thatendpoint and the ratio of the arc width to arc height.

The arcs are filled in the order listed.For any given arc,no pixel is drawn more than once.If regions intersect,the intersecting pixels are drawn multiple times.

GC components: function, plane-mask, fill-style, arc-mode,subwindow-mode, clip-x-origin, clip-y-origin, clip-mask

GC mode-dependent components: foreground, background, tile, stipple,tile-stipple-x-origin, tile-stipple-y-origin

This request combines an image with a rectangle of the drawable.The dst-x and dst-y coordinates are relative to the drawable's origin.

IfBitmapformat is used,then depth must be one (or aMatcherror results), and the image must be in XY format.The foreground pixel in gc defines the source for bits set to 1 in the image,and the background pixel defines the source for the bits set to 0.

ForXYPixmapandZPixmap,the depth must match the depth of the drawable (or aMatcherror results).ForXYPixmap,the image must be sent in XY format.ForZPixmap,the image must be sent in the Z format defined for the given depth.

The left-pad must be zero forZPixmapformat (or aMatcherror results).ForBitmapandXYPixmapformat,left-pad must be less than bitmap-scanline-pad as given in the serverconnection setup information (or aMatcherror results).The first left-pad bits in every scanline are to be ignored by the server.The actual image begins that many bits into the data.The width argument defines the width of the actual imageand does not include left-pad.

GC components: function, plane-mask, subwindow-mode, clip-x-origin,clip-y-origin, clip-mask

GC mode-dependent components: foreground, background

This request returns the contents of the given rectangle of the drawable in thegiven format.The x and y coordinates are relative to the drawable's originand define the upper-left corner of the rectangle.IfXYPixmapis specified,only the bit planes specified in plane-mask are transmitted,with the planes appearing from most significant to least significantin bit order.IfZPixmapis specified, then bits in all planes not specified in plane-mask aretransmitted as zero.Range checking is not performed on plane-mask;extraneous bits are simply ignored.The returned depth is as specified when the drawable was createdand is the same as a depth component in a FORMAT structure (in the connectionsetup), not a bits-per-pixel component.If the drawable is a window,its visual type is returned.If the drawable is a pixmap,the visual isNone.

If the drawable is a pixmap,then the given rectangle must be wholly contained within the pixmap (or aMatcherror results).If the drawable is a window,the window must be viewable,and it must be the case that,if there were no inferiors or overlapping windows,the specified rectangle of the window would be fully visible on the screenand wholly contained within the outside edges of the window (or aMatcherror results).Note that the borders of the window can be included and read with this request.If the window has a backing store,then the backing-store contents are returned for regions of the windowthat are obscured by noninferior windows;otherwise, the returned contents of such obscured regions are undefined.Also undefined are the returned contents of visibleregions of inferiors of different depth than the specified window.The pointer cursor image is not included in the contents returned.

This request is not general-purpose in the same sense as othergraphics-related requests.It is intended specifically for rudimentary hardcopy support.

The x and y coordinates are relative to the drawable's originand specify the baseline starting position (the initial character origin).Each text item is processed in turn.A font item causes the font to be stored in gcand to be used for subsequent text.Switching among fonts does not affect the next character origin.A text element delta specifies an additional change in the positionalong the x axis before the string is drawn;the delta is always added to the character origin.Each character image, as defined by the font in gc,is treated as an additional mask for a fill operation on the drawable.

All contained FONTs are always transmitted most significant byte first.

If aFonterror is generated for an item,the previous items may have been drawn.

For fonts defined with 2-byte matrix indexing,each STRING8 byte is interpreted as a byte2 value of a CHAR2B with a byte1value of zero.

GC components: function, plane-mask, fill-style, font,subwindow-mode, clip-x-origin, clip-y-origin, clip-mask

GC mode-dependent components: foreground, background, tile, stipple,tile-stipple-x-origin, tile-stipple-y-origin

This request is similar toPolyText8,except 2-byte (or 16-bit) characters are used.For fonts defined with linear indexing rather than 2-byte matrix indexing,the server will interpret each CHAR2B as a 16-bit number thathas been transmitted most significant byte first (that is, byte1 of theCHAR2B is taken as the most significant byte).

The x and y coordinates are relative to the drawable's originand specify the baseline starting position (the initial character origin).The effect is first to fill a destination rectangle with the backgroundpixel defined in gc and then to paint the text with the foreground pixel.The upper-left corner of the filled rectangle is at:

[x, y - font-ascent]

the width is:

overall-width

and the height is:

font-ascent + font-descent

The overall-width, font-ascent, and font-descent are asthey would be returned by aQueryTextExtentscall using gc and string.

The function and fill-style defined in gc are ignored for this request.The effective function isCopy,and the effective fill-styleSolid.

For fonts defined with 2-byte matrix indexing,each STRING8 byte is interpreted as a byte2 value of a CHAR2B with a byte1value of zero.

GC components: plane-mask, foreground, background, font,subwindow-mode, clip-x-origin, clip-y-origin, clip-mask

This request is similar toImageText8,except 2-byte (or 16-bit) characters are used.For fonts defined with linear indexing rather than 2-byte matrix indexing,the server will interpret each CHAR2B as a 16-bit number thathas been transmitted most significant byte first (that is, byte1 of theCHAR2B is taken as the most significant byte).

This request creates a colormap of the specified visual type for the screenon which the window resides and associates the identifier mid with it.The visual type must be one supported by the screen (or aMatcherror results).The initial values of the colormap entries are undefined for classesGrayScale,PseudoColor,andDirectColor.ForStaticGray,StaticColor,andTrueColor,the entries will have defined values,but those values are specific to the visual and are not definedby the core protocol.ForStaticGray,StaticColor,andTrueColor,alloc must be specified asNone(or aMatcherror results).For the other classes, if alloc isNone,the colormap initially has no allocated entries,and clients can allocate entries.

If alloc isAll,then the entire colormap is allocated writable.The initial values of all allocated entries are undefined.ForGrayScaleandPseudoColor,the effect is as if anAllocColorCellsrequest returned all pixel values from zero to N - 1,where N is the colormap-entries value in the specified visual.ForDirectColor,the effect is as if anAllocColorPlanesrequest returned a pixel value of zero and red-mask,green-mask, and blue-mask values containing the same bits as thecorresponding masks in the specified visual.However,in all cases, none of these entries can be freed withFreeColors.

This request deletes the association between the resource ID and the colormapand frees the colormap storage.If the colormap is an installed map for a screen,it is uninstalled (seeUninstallColormaprequest).If the colormap is defined as the colormap for a window (by means ofCreateWindoworChangeWindowAttributes),the colormap for the window is changed toNone,and aColormapNotifyevent is generated.The protocol does not define the colors displayed for a window with a colormap ofNone.

This request has no effect on a default colormap for a screen.

This request creates a colormap of the same visual typeand for the same screen as src-cmap,and it associates identifier mid with it.It also moves all of the client's existing allocations from src-cmapto the new colormap with their color values intactand their read-only or writable characteristics intact,and it frees those entries in src-cmap.Color values in other entries in the new colormap are undefined.If src-cmap was created by the client with allocAll(seeCreateColormaprequest),then the new colormap is also created with allocAll,all color values for all entries are copied from src-cmap,and then all entries in src-cmap are freed.If src-cmap was not created by the client with allocAll,then the allocations to be moved are all those pixels and planes that havebeen allocated by the client using eitherAllocColor,AllocNamedColor,AllocColorCells,orAllocColorPlanesand that have not been freed since they were allocated.

This request makes this colormap an installed map for its screen.All windows associated with this colormap immediately display with true colors.As a side effect,additional colormaps might be implicitly installedor uninstalled by the server.Which other colormaps get installed or uninstalled is server-dependentexcept that the required list must remain installed.

If cmap is not already an installed map, aColormapNotifyevent is generated on every window having cmap as an attribute.In addition,for every other colormap that is installed or uninstalled as a resultof the request, aColormapNotifyevent is generated on every window having that colormap as an attribute.

At any time, there is a subset of the installed maps that are viewed as anordered list and are called the required list.The length of the required list is at most M,where M is the min-installed-maps specified for the screen in theconnection setup.The required list is maintained as follows.When a colormap is an explicit argument toInstallColormap,it is added to the head of the list; the list is truncated at thetail, if necessary, to keep the length of the list to at most M.When a colormap is an explicit argument toUninstallColormapand it is in the required list, it is removed from the list.A colormap is not added to the required list when it is installed implicitlyby the server, and the server cannot implicitly uninstall a colormap that isin the required list.

Initially the default colormap for a screen is installed (but is not inthe required list).

If cmap is on the required list for its screen (seeInstallColormaprequest),it is removed from the list.As a side effect,cmap might be uninstalled,and additional colormaps might be implicitly installed or uninstalled.Which colormaps get installed or uninstalled is server-dependentexcept that the required list must remain installed.

If cmap becomes uninstalled, aColormapNotifyevent is generated on every window having cmap as an attribute.In addition,for every other colormap that is installed or uninstalled as a result ofthe request, aColormapNotifyevent is generated on every window having that colormap as an attribute.

This request returns a list of the currently installed colormaps for thescreen of the specified window.The order of colormaps is not significant,and there is no explicit indication of the required list (seeInstallColormaprequest).

This request allocates a read-only colormap entry corresponding to the closestRGB values provided by the hardware.It also returns the pixel and the RGB values actually used.Multiple clients requesting the same effective RGB values can be assignedthe same read-only entry, allowing entries to be shared.

This request looks up the named color with respect to the screen associatedwith the colormap.Then, it does anAllocColoron cmap.The name should use the ISO Latin-1 encoding,and uppercase and lowercase do not matter.The exact RGB values specify the true values for the color,and the visual values specify the values actually used in the colormap.

The number of colors must be positive,and the number of planes must be nonnegative (or aValueerror results).If C colors and P planes are requested,then C pixels and P masks are returned.No mask will have any bits in common with any other maskor with any of the pixels.By ORing together masks and pixels,C*%2 sup P% distinct pixels can be produced;all of these are allocated writable by the request.ForGrayScaleorPseudoColor,each mask will have exactly one bit set to 1; forDirectColor,each will have exactly three bits set to 1.If contiguous isTrueand if all masks are ORed together,a single contiguous set of bits will be formed forGrayScaleorPseudoColor,and three contiguous sets of bits (one within each pixel subfield) forDirectColor.The RGB values of the allocated entries are undefined.

The number of colors must be positive,and the reds, greens, and blues must be nonnegative (or aValueerror results).If C colors, R reds, G greens, and B blues are requested,then C pixels are returned, and the masks have R, G, and B bits set,respectively.If contiguous isTrue,then each mask will have a contiguous set of bits.No mask will have any bits in common with any other maskor with any of the pixels.ForDirectColor,each mask will lie within the corresponding pixel subfield.By ORing together subsets of masks with pixels,C*%2 sup R+G+B% distinct pixels can be produced;all of these are allocated writable by the request.The initial RGB values of the allocated entries are undefined.In the colormap,there are only C*%2 sup R% independent red entries,C*%2 sup G% independent green entries,and C*%2 sup B% independent blue entries.This is true even forPseudoColor.When the colormap entry for a pixel value is changed usingStoreColorsorStoreNamedColor,the pixel is decomposed according to the masks and thecorresponding independent entries are updated.

The plane-mask should not have any bits in common with any of thepixels.The set of all pixels is produced by ORing together subsets ofplane-mask with the pixels.The request frees all of these pixels thatwere allocated by the client (usingAllocColor,AllocNamedColor,AllocColorCells,andAllocColorPlanes).Note that freeing anindividual pixel obtained fromAllocColorPlanesmay not actually allow it to be reused until all of its related pixelsare also freed.Similarly, a read-only entry is not actually freed until it has beenfreed by all clients, and if a client allocates the same read-only entrymultiple times, it must free the entry that many times before theentry is actually freed.

All specified pixels that are allocated by the client in cmap are freed,even if one or more pixels produce an error.AValueerror is generated if a specified pixel is not a valid index into cmap.AnAccesserror is generated if a specified pixel is not allocated by theclient (that is, is unallocated or is only allocated by another client)or if the colormap was created with all entries writable (using an allocvalue ofAllinCreateColormap).If more than one pixel is in error,it is arbitrary as to which pixel is reported.