diff options
Diffstat (limited to 'X11/extensions/fixesproto.txt')
-rw-r--r-- | X11/extensions/fixesproto.txt | 1238 |
1 files changed, 661 insertions, 577 deletions
diff --git a/X11/extensions/fixesproto.txt b/X11/extensions/fixesproto.txt index 5ef815385..27477094a 100644 --- a/X11/extensions/fixesproto.txt +++ b/X11/extensions/fixesproto.txt @@ -1,577 +1,661 @@ - The XFIXES Extension - Version 4.0 - Document Revision 2 - 2006-12-14 - Keith Packard - keithp@keithp.com - -1. Introduction - -X applications have often needed to work around various shortcomings in the -core X window system. This extension is designed to provide the minimal -server-side support necessary to eliminate problems caused by these -workarounds. - -2. Acknowledgements - -This extension is a direct result of requests made by application -developers, in particular, - - + Owen Taylor for describing the issues raised with the XEMBED - mechanisms and SaveSet processing and his initial extension - to handle this issue. - - + Bill Haneman for the design for cursor image tracking. - - + Havoc Pennington - - + Fredrik Höglund for cursor names - - + Deron Johnson for cursor visibility - -3. Basic Premise - -Requests in this extension may seem to wander all over the map of X server -capabilities, but they are tied by a simple rule -- resolving issues raised -by application interaction with core protocol mechanisms that cannot be -adequately worked around on the client side of the wire. - -4. Extension initialization - -The client must negotiate the version of the extension before executing -extension requests. Behavior of the server is undefined otherwise. - -QueryVersion - - client-major-version: CARD32 - client-minor-version: CARD32 - - -> - - major-version: CARD32 - minor-version: CARD32 - - The client sends the highest supported version to the server and - the server sends the highest version it supports, but no higher than - the requested version. Major versions changes can introduce - new requests, minor version changes introduce only adjustments to - existing requests or backward compatible changes. It is - the clients responsibility to ensure that the server supports - a version which is compatible with its expectations. - -************* XFIXES VERSION 1 OR BETTER *********** - -5. Save Set processing changes - -Embedding one application within another provides a way of unifying -disparate documents and views within a single framework. From the X -protocol perspective, this appears similar to nested window managers; the -embedding application "manages" the embedded windows much as a window -manager does for top-level windows. To protect the embedded application -from embedding application failure, it is reasonable to use the core SaveSet -mechanism so that embedding application failure causes embedded windows to -be preserved instead of destroyed. - -The core save set mechanism defines the target for each save set member -window as the nearest enclosing window not owned by the terminating client. -For embedding applications, this nearest window is usually the window -manager frame. The problem here is that the window manager will not -generally expect to receive and correctly manage new windows appearing within -that window by the save set mechanism, and will instead destroy the frame -window in response to the client window destruction. This causes the -embedded window to be destroyed. - -An easy fix for this problem is to change the target of the save set member -to a window which won't be affected by the underlying window destruction. -XFIXES chooses the root window as the target. - -Having embedded windows suddenly appear at the top level can confuse users, -so XFIXES also lets the client select whether the window should end up -unmapped after the save set processing instead of unconditionally making -them be mapped. - -5.1 Requests - -ChangeSaveSet - - window: Window - mode: { Insert, Delete } - target: { Nearest, Root } - map: { Map, Unmap } - - ChangeSaveSet is an extension of the core protocol ChangeSaveSet - request. As in that request, mode specifies whether the indicated - window is inserted or deleted from the save-set. Target specifies - whether the window is reparented to the nearest non-client window as - in the core protocol, or reparented to the root window. Map - specifies whether the window is mapped as in the core protocol or - unmapped. - -6. Selection Tracking - -Applications wishing to monitor the contents of current selections must -poll for selection changes. XFIXES improves this by providing an event -delivered whenever the selection ownership changes. - -6.1 Types - - SELECTIONEVENT { SetSelectionOwner, - SelectionWindowDestroy, - SelectionClientClose } - -6.1 Events - -SelectionNotify - - subtype: SELECTIONEVENT - window: Window - owner: Window - selection: Atom - timestamp: Timestamp - selection-timestamp: Timestamp - -6.2 Requests - -SelectSelectionInput - - window: Window - selection: Atom - event-mask: SETofSELECTIONEVENT - - Selects for events to be delivered to window when various causes of - ownership of selection occur. Subtype indicates the cause of the - selection ownership change. Owner is set to the current selection - owner, or None. Timestamp indicates the time the event was - generated while selection-timestamp indicates the timestamp used to - own the selection. - -7. Cursor Image Monitoring - -Mirroring the screen contents is easily done with the core protocol or VNC -addons, except for the current cursor image. There is no way using the core -protocol to discover which cursor image is currently displayed. The -cursor image often contains significant semantic content about the user -interface. XFIXES provides a simple mechanism to discover when the cursor -image changes and to fetch the current cursor image. - -As the current cursor may or may not have any XID associated with it, there -is no stable name available. Instead, XFIXES returns only the image of the -current cursor and provides a way to identify cursor images to avoid -refetching the image each time it changes to a previously seen cursor. - -7.1 Types - CURSOREVENT { DisplayCursor } - -7.2 Events - -CursorNotify - - subtype: CURSOREVENT - window: Window - cursor-serial: CARD32 - timestamp: Timestamp - name: Atom (Version 2 only) - -7.3 Requests - -SelectCursorInput - - window: Window - event-mask: SETofCURSOREVENT - - This request directs cursor change events to the named window. - Events will be delivered irrespective of the screen on which they - occur. Subtype indicates the cause of the cursor image change - (there is only one subtype at present). Cursor-serial is a number - assigned to the cursor image which identifies the image. Cursors - with different serial numbers may have different images. Timestamp - is the time of the cursor change. - - Servers supporting the X Input Extension Version 2.0 or higher only - notify the clients of cursor change events for the ClientPointer, not - of any other master pointer (see Section 4.4. in the XI2 protocol - specificiation). - -GetCursorImage - - -> - - x: INT16 - y: INT16 - width: CARD16 - height: CARD16 - x-hot: CARD16 - y-hot: CARD16 - cursor-serial: CARD32 - cursor-image: LISTofCARD32 - - GetCursorImage returns the image of the current cursor. X and y are - the current cursor position. Width and height are the size of the - cursor image. X-hot and y-hot mark the hotspot within the cursor - image. Cursor-serial provides the number assigned to this cursor - image, this same serial number will be reported in a CursorNotify - event if this cursor image is redisplayed in the future. - - The cursor image itself is returned as a single image at 32 bits per - pixel with 8 bits of alpha in the most significant 8 bits of the - pixel followed by 8 bits each of red, green and finally 8 bits of - blue in the least significant 8 bits. The color components are - pre-multiplied with the alpha component. - -************* XFIXES VERSION 2 OR BETTER *********** - -8. Region Objects - -The core protocol doesn't expose regions as a primitive object and this -makes many operations more complicated than they really need to be. Adding -region objects simplifies expose handling, the Shape extension and other -operations. These operations are also designed to support a separate -extension, the X Damage Extension. - -8.1 Types - - Region: XID - WINDOW_REGION_KIND: { Bounding, Clip } - -8.2 Errors - - Region The specified region is invalid - -8.3 Requests - -CreateRegion - - region: REGION - rects: LISTofRECTANGLE - - Creates a region initialized to the specified list of rectangles. - The rectangles may be specified in any order, their union becomes - the region. The core protocol allows applications to specify an - order for the rectangles, but it turns out to be just as hard to - verify the rectangles are actually in that order as it is to simply - ignore the ordering information and union them together. Hence, - this request dispenses with the ordering information. - - Errors: IDChoice - -CreateRegionFromBitmap - - region: REGION - bitmap: PIXMAP - - Creates a region initialized to the set of 'one' pixels in bitmap - (which must be depth 1, else Match error). - - Errors: Pixmap, IDChoice, Match - -CreateRegionFromWindow - - window: Window - kind: WINDOW_REGION_KIND - region: Region - - Creates a region initialized to the specified window region. See the - Shape extension for the definition of Bounding and Clip regions. - - Errors: Window, IDChoice, Value - -CreateRegionFromGC - - gc: GContext - region: Region - - Creates a region initialized from the clip list of the specified - GContext. - - Errors: GContext, IDChoice - -CreateRegionFromPicture - - picture: Picture - region: Region - - - Creates a region initialized from the clip list of the specified - Picture. - - Errors: Picture, IDChoice - -DestroyRegion - - region: Region - - Destroys the specified region. - - Errors: Region - -SetRegion - - region: Region - rects: LISTofRECTANGLE - - This replaces the current contents of region with the region formed - by the union of rects. - -CopyRegion - source: Region - destination: Region - - This replaces the contents of destination with the contents of - source. - -UnionRegion -IntersectRegion -SubtractRegion - - source1: Region - source2: Region - destination: Region - - Combines source1 and source2, placing the result in destination. - Destination may be the same as either source1 or source2. - - Errors: Region, Value - -InvertRegion - - source: Region - bounds: RECTANGLE - destination: Region - - The source region is subtracted from the region specified by - bounds. The result is placed in destination, replacing its contents. - - Errors: Region - -TranslateRegion - - region: Region - dx, dy: INT16 - - The region is translated by dx, dy in place. - - Errors: Region - -RegionExtents - - source: Region - destination: Region - - The extents of the source region are placed in the destination - -FetchRegion - - region: Region - -> - extents: RECTANGLE - rectangles: LISTofRECTANGLE - - The region is returned as a list of rectangles in YX-banded order. - - Errors: Region - -SetGCClipRegion - - gc: GCONTEXT - clip-x-origin, clip-y-origin: INT16 - region: Region or None - - This request changes clip-mask in gc to the specified region and - sets the clip origin. Output will be clipped to remain contained - within the region. The clip origin is interpreted relative to the - origin of whatever destination drawable is specified in a graphics - request. The region is interpreted relative to the clip origin. - Future changes to region have no effect on the gc clip-mask. - - Errors: GContext, Region - -SetWindowShapeRegion - - dest: Window - destKind: SHAPE_KIND - xOff, yOff: INT16 - region: Region or None - - This request sets the specified (by destKind) Shape extension region - of the window to region, offset by xOff and yOff. Future changes to - region have no effect on the window shape. - - Errors: Window, Value, Region - -SetPictureClipRegion - - picture: Picture - clip-x-origin, clip-y-origin: INT16 - region: Region or None - - This request changes clip-mask in picture to the specified region - and sets the clip origin. Input and output will be clipped to - remain contained within the region. The clip origin is interpreted - relative to the origin of the drawable associated with picture. The - region is interpreted relative to the clip origin. Future changes - to region have no effect on the picture clip-mask. - - Errors: Picture, Region - -9. Cursor Names - -Attaching names to cursors permits some abstract semantic content to be -associated with specific cursor images. Reflecting those names back to -applications allows that semantic content to be related to the user through -non-visual means. - -9.1 Events - -CursorNotify - - subtype: CURSOREVENT - window: Window - cursor-serial: CARD32 - timestamp: Timestamp - name: Atom or None - - In Version 2 of the XFIXES protocol, this event adds the atom - of any name associated with the current cursor (else None). - -9.2 Requests - -SetCursorName - - cursor: CURSOR - name: LISTofCARD8 - - This request interns name as an atom and sets that atom as the name - of cursor. - - Errors: Cursor - -GetCursorName - - cursor: CURSOR - -> - atom: ATOM or None - name: LISTofCARD8 - - This request returns the name and atom of cursor. If no name is - set, atom is None and name is empty. - - Errors: Cursor - -GetCursorImageAndName - - -> - - x: INT16 - y: INT16 - width: CARD16 - height: CARD16 - x-hot: CARD16 - y-hot: CARD16 - cursor-serial: CARD32 - cursor-atom: ATOM - cursor-name: LISTofCARD8 - cursor-image: LISTofCARD32 - - This is similar to GetCursorImage except for including both - the atom and name of the current cursor. - -ChangeCursor - - source, destination: CURSOR - - This request replaces all references to the destination with a - reference to source. Any existing uses of the destination cursor - object will now show the source cursor image. - -ChangeCursorByName - - src: CURSOR - name: LISTofCARD8 - - This request replaces the contents of all cursors with the specified - name with the src cursor. - -************* XFIXES VERSION 3 OR BETTER *********** - -10. Region Expansion - -This update provides another operation on the region objects defined in -Section 8 of this document. - -10.1 Requests - -ExpandRegion - source: REGION - destination: REGION - left, right, top, bottom: CARD16 - - Creates destination region containing the area specified by - expanding each rectangle in the source region by the specified - number of pixels to the left, right, top and bottom. - -************* XFIXES VERSION 4 OR BETTER *********** - -11. Cursor Visibility - -Composite managers may want to render the cursor themselves instead of -relying on the X server sprite drawing, this provides a way for them to -do so without getting a double cursor image. - -11.1 Requests - -HideCursor - - window: WINDOW - - A client sends this request to indicate that it wants the - cursor image to be hidden (i.e. to not be displayed) when - the sprite is inside the specified window, or one of its - subwindows. If the sprite is inside a window for which one - or more active clients have requested cursor hiding then the - cursor image will not be displayed. - - Note that even though cursor hiding causes the cursor image - to be invisible, CursorNotify events will still be sent - normally, as if the cursor image were visible. - - If, during a grab, one or more active clients have requested - cursor hiding for grab window, or one of its ancestors, the - cursor image of the grab cursor will not be displayed during - the lifetime of that grab. - - When a client with outstanding cursor hiding requests - terminates its connection these requests will be deleted. - - Servers supporting the X Input Extension Version 2.0 or higher hide - all visible cursors in response to a HideCursor request. If a master - pointer is created while the cursors are hidden, this master pointer's - cursor will be hidden as well. - -ShowCursor - - window: WINDOW - - A client sends this request to indicate that it wants the - cursor image to be displayed when the sprite is inside the - specified window, or one of its subwindows. If the sprite - is inside a window for which no active clients have requested - cursor hiding then the cursor image for that window will be - displayed. In other words, if a client calls HideCursor for - a specified window, or window subtree, this request reverses - the effects of the HideCursor request. - - If the client has made no outstanding HideCursor requests - a BadMatch error is generated. - - Servers supporting the X Input Extension Version 2.0 or higher show - all visible cursors in response to a ShowCursor request. - -99. Future compatibility - -This extension is not expected to remain fixed. Future changes will -strive to remain compatible if at all possible. The X server will always -support version 1 of the extension protocol if requested by a client. - -Additions to the protocol will always by marked by minor version number -changes so that applications will be able to detect what requests are -supported. + The XFIXES Extension
+ Version 5.0
+ Document Revision 1
+ 2010-11-15
+ Keith Packard
+ keithp@keithp.com
+
+1. Introduction
+
+X applications have often needed to work around various shortcomings in the
+core X window system. This extension is designed to provide the minimal
+server-side support necessary to eliminate problems caused by these
+workarounds.
+
+2. Acknowledgements
+
+This extension is a direct result of requests made by application
+developers, in particular,
+
+ + Owen Taylor for describing the issues raised with the XEMBED
+ mechanisms and SaveSet processing and his initial extension
+ to handle this issue, and for pointer barriers
+
+ + Bill Haneman for the design for cursor image tracking.
+
+ + Havoc Pennington
+
+ + Fredrik Höglund for cursor names
+
+ + Deron Johnson for cursor visibility
+
+3. Basic Premise
+
+Requests in this extension may seem to wander all over the map of X server
+capabilities, but they are tied by a simple rule -- resolving issues raised
+by application interaction with core protocol mechanisms that cannot be
+adequately worked around on the client side of the wire.
+
+4. Extension initialization
+
+The client must negotiate the version of the extension before executing
+extension requests. Behavior of the server is undefined otherwise.
+
+QueryVersion
+
+ client-major-version: CARD32
+ client-minor-version: CARD32
+
+ ->
+
+ major-version: CARD32
+ minor-version: CARD32
+
+ The client sends the highest supported version to the server and
+ the server sends the highest version it supports, but no higher than
+ the requested version. Major versions changes can introduce
+ new requests, minor version changes introduce only adjustments to
+ existing requests or backward compatible changes. It is
+ the clients responsibility to ensure that the server supports
+ a version which is compatible with its expectations.
+
+************* XFIXES VERSION 1 OR BETTER ***********
+
+5. Save Set processing changes
+
+Embedding one application within another provides a way of unifying
+disparate documents and views within a single framework. From the X
+protocol perspective, this appears similar to nested window managers; the
+embedding application "manages" the embedded windows much as a window
+manager does for top-level windows. To protect the embedded application
+from embedding application failure, it is reasonable to use the core SaveSet
+mechanism so that embedding application failure causes embedded windows to
+be preserved instead of destroyed.
+
+The core save set mechanism defines the target for each save set member
+window as the nearest enclosing window not owned by the terminating client.
+For embedding applications, this nearest window is usually the window
+manager frame. The problem here is that the window manager will not
+generally expect to receive and correctly manage new windows appearing within
+that window by the save set mechanism, and will instead destroy the frame
+window in response to the client window destruction. This causes the
+embedded window to be destroyed.
+
+An easy fix for this problem is to change the target of the save set member
+to a window which won't be affected by the underlying window destruction.
+XFIXES chooses the root window as the target.
+
+Having embedded windows suddenly appear at the top level can confuse users,
+so XFIXES also lets the client select whether the window should end up
+unmapped after the save set processing instead of unconditionally making
+them be mapped.
+
+5.1 Requests
+
+ChangeSaveSet
+
+ window: Window
+ mode: { Insert, Delete }
+ target: { Nearest, Root }
+ map: { Map, Unmap }
+
+ ChangeSaveSet is an extension of the core protocol ChangeSaveSet
+ request. As in that request, mode specifies whether the indicated
+ window is inserted or deleted from the save-set. Target specifies
+ whether the window is reparented to the nearest non-client window as
+ in the core protocol, or reparented to the root window. Map
+ specifies whether the window is mapped as in the core protocol or
+ unmapped.
+
+6. Selection Tracking
+
+Applications wishing to monitor the contents of current selections must
+poll for selection changes. XFIXES improves this by providing an event
+delivered whenever the selection ownership changes.
+
+6.1 Types
+
+ SELECTIONEVENT { SetSelectionOwner,
+ SelectionWindowDestroy,
+ SelectionClientClose }
+
+6.1 Events
+
+SelectionNotify
+
+ subtype: SELECTIONEVENT
+ window: Window
+ owner: Window
+ selection: Atom
+ timestamp: Timestamp
+ selection-timestamp: Timestamp
+
+6.2 Requests
+
+SelectSelectionInput
+
+ window: Window
+ selection: Atom
+ event-mask: SETofSELECTIONEVENT
+
+ Selects for events to be delivered to window when various causes of
+ ownership of selection occur. Subtype indicates the cause of the
+ selection ownership change. Owner is set to the current selection
+ owner, or None. Timestamp indicates the time the event was
+ generated while selection-timestamp indicates the timestamp used to
+ own the selection.
+
+7. Cursor Image Monitoring
+
+Mirroring the screen contents is easily done with the core protocol or VNC
+addons, except for the current cursor image. There is no way using the core
+protocol to discover which cursor image is currently displayed. The
+cursor image often contains significant semantic content about the user
+interface. XFIXES provides a simple mechanism to discover when the cursor
+image changes and to fetch the current cursor image.
+
+As the current cursor may or may not have any XID associated with it, there
+is no stable name available. Instead, XFIXES returns only the image of the
+current cursor and provides a way to identify cursor images to avoid
+refetching the image each time it changes to a previously seen cursor.
+
+7.1 Types
+ CURSOREVENT { DisplayCursor }
+
+7.2 Events
+
+CursorNotify
+
+ subtype: CURSOREVENT
+ window: Window
+ cursor-serial: CARD32
+ timestamp: Timestamp
+ name: Atom (Version 2 only)
+
+7.3 Requests
+
+SelectCursorInput
+
+ window: Window
+ event-mask: SETofCURSOREVENT
+
+ This request directs cursor change events to the named window.
+ Events will be delivered irrespective of the screen on which they
+ occur. Subtype indicates the cause of the cursor image change
+ (there is only one subtype at present). Cursor-serial is a number
+ assigned to the cursor image which identifies the image. Cursors
+ with different serial numbers may have different images. Timestamp
+ is the time of the cursor change.
+
+ Servers supporting the X Input Extension Version 2.0 or higher only
+ notify the clients of cursor change events for the ClientPointer, not
+ of any other master pointer (see Section 4.4. in the XI2 protocol
+ specificiation).
+
+GetCursorImage
+
+ ->
+
+ x: INT16
+ y: INT16
+ width: CARD16
+ height: CARD16
+ x-hot: CARD16
+ y-hot: CARD16
+ cursor-serial: CARD32
+ cursor-image: LISTofCARD32
+
+ GetCursorImage returns the image of the current cursor. X and y are
+ the current cursor position. Width and height are the size of the
+ cursor image. X-hot and y-hot mark the hotspot within the cursor
+ image. Cursor-serial provides the number assigned to this cursor
+ image, this same serial number will be reported in a CursorNotify
+ event if this cursor image is redisplayed in the future.
+
+ The cursor image itself is returned as a single image at 32 bits per
+ pixel with 8 bits of alpha in the most significant 8 bits of the
+ pixel followed by 8 bits each of red, green and finally 8 bits of
+ blue in the least significant 8 bits. The color components are
+ pre-multiplied with the alpha component.
+
+************* XFIXES VERSION 2 OR BETTER ***********
+
+8. Region Objects
+
+The core protocol doesn't expose regions as a primitive object and this
+makes many operations more complicated than they really need to be. Adding
+region objects simplifies expose handling, the Shape extension and other
+operations. These operations are also designed to support a separate
+extension, the X Damage Extension.
+
+8.1 Types
+
+ Region: XID
+ WINDOW_REGION_KIND: { Bounding, Clip }
+
+8.2 Errors
+
+ Region The specified region is invalid
+
+8.3 Requests
+
+CreateRegion
+
+ region: REGION
+ rects: LISTofRECTANGLE
+
+ Creates a region initialized to the specified list of rectangles.
+ The rectangles may be specified in any order, their union becomes
+ the region. The core protocol allows applications to specify an
+ order for the rectangles, but it turns out to be just as hard to
+ verify the rectangles are actually in that order as it is to simply
+ ignore the ordering information and union them together. Hence,
+ this request dispenses with the ordering information.
+
+ Errors: IDChoice
+
+CreateRegionFromBitmap
+
+ region: REGION
+ bitmap: PIXMAP
+
+ Creates a region initialized to the set of 'one' pixels in bitmap
+ (which must be depth 1, else Match error).
+
+ Errors: Pixmap, IDChoice, Match
+
+CreateRegionFromWindow
+
+ window: Window
+ kind: WINDOW_REGION_KIND
+ region: Region
+
+ Creates a region initialized to the specified window region. See the
+ Shape extension for the definition of Bounding and Clip regions.
+
+ Errors: Window, IDChoice, Value
+
+CreateRegionFromGC
+
+ gc: GContext
+ region: Region
+
+ Creates a region initialized from the clip list of the specified
+ GContext.
+
+ Errors: GContext, IDChoice
+
+CreateRegionFromPicture
+
+ picture: Picture
+ region: Region
+
+
+ Creates a region initialized from the clip list of the specified
+ Picture.
+
+ Errors: Picture, IDChoice
+
+DestroyRegion
+
+ region: Region
+
+ Destroys the specified region.
+
+ Errors: Region
+
+SetRegion
+
+ region: Region
+ rects: LISTofRECTANGLE
+
+ This replaces the current contents of region with the region formed
+ by the union of rects.
+
+CopyRegion
+ source: Region
+ destination: Region
+
+ This replaces the contents of destination with the contents of
+ source.
+
+UnionRegion
+IntersectRegion
+SubtractRegion
+
+ source1: Region
+ source2: Region
+ destination: Region
+
+ Combines source1 and source2, placing the result in destination.
+ Destination may be the same as either source1 or source2.
+
+ Errors: Region, Value
+
+InvertRegion
+
+ source: Region
+ bounds: RECTANGLE
+ destination: Region
+
+ The source region is subtracted from the region specified by
+ bounds. The result is placed in destination, replacing its contents.
+
+ Errors: Region
+
+TranslateRegion
+
+ region: Region
+ dx, dy: INT16
+
+ The region is translated by dx, dy in place.
+
+ Errors: Region
+
+RegionExtents
+
+ source: Region
+ destination: Region
+
+ The extents of the source region are placed in the destination
+
+FetchRegion
+
+ region: Region
+ ->
+ extents: RECTANGLE
+ rectangles: LISTofRECTANGLE
+
+ The region is returned as a list of rectangles in YX-banded order.
+
+ Errors: Region
+
+SetGCClipRegion
+
+ gc: GCONTEXT
+ clip-x-origin, clip-y-origin: INT16
+ region: Region or None
+
+ This request changes clip-mask in gc to the specified region and
+ sets the clip origin. Output will be clipped to remain contained
+ within the region. The clip origin is interpreted relative to the
+ origin of whatever destination drawable is specified in a graphics
+ request. The region is interpreted relative to the clip origin.
+ Future changes to region have no effect on the gc clip-mask.
+
+ Errors: GContext, Region
+
+SetWindowShapeRegion
+
+ dest: Window
+ destKind: SHAPE_KIND
+ xOff, yOff: INT16
+ region: Region or None
+
+ This request sets the specified (by destKind) Shape extension region
+ of the window to region, offset by xOff and yOff. Future changes to
+ region have no effect on the window shape.
+
+ Errors: Window, Value, Region
+
+SetPictureClipRegion
+
+ picture: Picture
+ clip-x-origin, clip-y-origin: INT16
+ region: Region or None
+
+ This request changes clip-mask in picture to the specified region
+ and sets the clip origin. Input and output will be clipped to
+ remain contained within the region. The clip origin is interpreted
+ relative to the origin of the drawable associated with picture. The
+ region is interpreted relative to the clip origin. Future changes
+ to region have no effect on the picture clip-mask.
+
+ Errors: Picture, Region
+
+9. Cursor Names
+
+Attaching names to cursors permits some abstract semantic content to be
+associated with specific cursor images. Reflecting those names back to
+applications allows that semantic content to be related to the user through
+non-visual means.
+
+9.1 Events
+
+CursorNotify
+
+ subtype: CURSOREVENT
+ window: Window
+ cursor-serial: CARD32
+ timestamp: Timestamp
+ name: Atom or None
+
+ In Version 2 of the XFIXES protocol, this event adds the atom
+ of any name associated with the current cursor (else None).
+
+9.2 Requests
+
+SetCursorName
+
+ cursor: CURSOR
+ name: LISTofCARD8
+
+ This request interns name as an atom and sets that atom as the name
+ of cursor.
+
+ Errors: Cursor
+
+GetCursorName
+
+ cursor: CURSOR
+ ->
+ atom: ATOM or None
+ name: LISTofCARD8
+
+ This request returns the name and atom of cursor. If no name is
+ set, atom is None and name is empty.
+
+ Errors: Cursor
+
+GetCursorImageAndName
+
+ ->
+
+ x: INT16
+ y: INT16
+ width: CARD16
+ height: CARD16
+ x-hot: CARD16
+ y-hot: CARD16
+ cursor-serial: CARD32
+ cursor-atom: ATOM
+ cursor-name: LISTofCARD8
+ cursor-image: LISTofCARD32
+
+ This is similar to GetCursorImage except for including both
+ the atom and name of the current cursor.
+
+ChangeCursor
+
+ source, destination: CURSOR
+
+ This request replaces all references to the destination with a
+ reference to source. Any existing uses of the destination cursor
+ object will now show the source cursor image.
+
+ChangeCursorByName
+
+ src: CURSOR
+ name: LISTofCARD8
+
+ This request replaces the contents of all cursors with the specified
+ name with the src cursor.
+
+************* XFIXES VERSION 3 OR BETTER ***********
+
+10. Region Expansion
+
+This update provides another operation on the region objects defined in
+Section 8 of this document.
+
+10.1 Requests
+
+ExpandRegion
+ source: REGION
+ destination: REGION
+ left, right, top, bottom: CARD16
+
+ Creates destination region containing the area specified by
+ expanding each rectangle in the source region by the specified
+ number of pixels to the left, right, top and bottom.
+
+************* XFIXES VERSION 4 OR BETTER ***********
+
+11. Cursor Visibility
+
+Composite managers may want to render the cursor themselves instead of
+relying on the X server sprite drawing, this provides a way for them to
+do so without getting a double cursor image.
+
+11.1 Requests
+
+HideCursor
+
+ window: WINDOW
+
+ A client sends this request to indicate that it wants the
+ cursor image to be hidden (i.e. to not be displayed) when
+ the sprite is inside the specified window, or one of its
+ subwindows. If the sprite is inside a window for which one
+ or more active clients have requested cursor hiding then the
+ cursor image will not be displayed.
+
+ Note that even though cursor hiding causes the cursor image
+ to be invisible, CursorNotify events will still be sent
+ normally, as if the cursor image were visible.
+
+ If, during a grab, one or more active clients have requested
+ cursor hiding for grab window, or one of its ancestors, the
+ cursor image of the grab cursor will not be displayed during
+ the lifetime of that grab.
+
+ When a client with outstanding cursor hiding requests
+ terminates its connection these requests will be deleted.
+
+ Servers supporting the X Input Extension Version 2.0 or higher hide
+ all visible cursors in response to a HideCursor request. If a master
+ pointer is created while the cursors are hidden, this master pointer's
+ cursor will be hidden as well.
+
+ShowCursor
+
+ window: WINDOW
+
+ A client sends this request to indicate that it wants the
+ cursor image to be displayed when the sprite is inside the
+ specified window, or one of its subwindows. If the sprite
+ is inside a window for which no active clients have requested
+ cursor hiding then the cursor image for that window will be
+ displayed. In other words, if a client calls HideCursor for
+ a specified window, or window subtree, this request reverses
+ the effects of the HideCursor request.
+
+ If the client has made no outstanding HideCursor requests
+ a BadMatch error is generated.
+
+ Servers supporting the X Input Extension Version 2.0 or higher show
+ all visible cursors in response to a ShowCursor request.
+
+************* XFIXES VERSION 5 OR BETTER ***********
+
+12. Pointer Barriers
+
+Compositing managers and desktop environments may have UI elements in
+particular screen locations such that for a single-headed display they
+correspond to easy targets according to Fitt's Law, for example, the top
+left corner. For a multi-headed environment these corners should still be
+semi-impermeable. Pointer barriers allow the application to define
+additional constraint on cursor motion so that these areas behave as
+expected even in the face of multiple displays.
+
+Absolute positioning devices like touchscreens do not obey pointer barriers.
+There's no advantage to target acquisition to do so, since on a touchscreen
+all points are in some sense equally large, whereas for a relative
+positioning device the edges and corners are infinitely large.
+
+WarpPointer and similar requests do not obey pointer barriers, for
+essentially the same reason.
+
+12.1 Types
+
+ BARRIER: XID
+
+ BarrierDirections
+
+ BarrierPositiveX: 1 << 0
+ BarrierPositiveY: 1 << 1
+ BarrierNegativeX: 1 << 2
+ BarrierNegativeY: 1 << 3
+
+12.2 Errors
+
+ Barrier
+
+12.3 Requests
+
+CreatePointerBarrier
+
+ barrier: BARRIER
+ drawable: DRAWABLE
+ x1, y2, x2, y2: INT16
+ directions: CARD32
+ devices: LISTofDEVICEID
+
+ Creates a pointer barrier along the line specified by the given
+ coordinates on the screen associated with the given drawable. The
+ barrier has no spatial extent; it is simply a line along the left
+ or top edge of the specified pixels. Barrier coordinates are in
+ screen space.
+
+ The coordinates must be axis aligned, either x1 == x2, or
+ y1 == y2, but not both. The varying coordinates may be specified
+ in any order. For x1 == x2, either y1 > y2 or y1 < y2 is valid.
+ If the coordinates are not valid BadValue is generated.
+
+ Motion is allowed through the barrier in the directions specified:
+ setting the BarrierPositiveX bit allows travel through the barrier
+ in the positive X direction, etc. Nonsensical values (forbidding Y
+ axis travel through a vertical barrier, for example) and excess set
+ bits are ignored.
+
+ If the server supports the X Input Extension version 2 or higher,
+ the devices element names a set of master device to apply the
+ barrier to. If XIAllDevices or XIAllMasterDevices are given, the
+ barrier applies to all master devices. If a slave device is named,
+ BadDevice is generated; this does not apply to slave devices named
+ implicitly by XIAllDevices. Naming a device multiple times is
+ legal, and is treated as though it were named only once. If a
+ device is removed, the barrier continues to apply to the remaining
+ devices, but will not apply to any future device with the same ID
+ as the removed device. Nothing special happens when all matching
+ devices are removed; barriers must be explicitly destroyed.
+
+ Errors: IDChoice, Window, Value, Device
+
+DestroyPointerBarrier
+
+ barrier: BARRIER
+
+ Destroys the named barrier.
+
+ Errors: Barrier
+
+99. Future compatibility
+
+This extension is not expected to remain fixed. Future changes will
+strive to remain compatible if at all possible. The X server will always
+support version 1 of the extension protocol if requested by a client.
+
+Additions to the protocol will always by marked by minor version number
+changes so that applications will be able to detect what requests are
+supported.
|