aboutsummaryrefslogtreecommitdiff
path: root/X11/extensions/fixesproto.txt
diff options
context:
space:
mode:
Diffstat (limited to 'X11/extensions/fixesproto.txt')
-rw-r--r--X11/extensions/fixesproto.txt1322
1 files changed, 661 insertions, 661 deletions
diff --git a/X11/extensions/fixesproto.txt b/X11/extensions/fixesproto.txt
index 27477094a..5903ac9ef 100644
--- a/X11/extensions/fixesproto.txt
+++ b/X11/extensions/fixesproto.txt
@@ -1,661 +1,661 @@
- 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.
+ 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-12 15:54:34 +0000