aboutsummaryrefslogtreecommitdiff
path: root/X11/extensions
diff options
context:
space:
mode:
authormarha <marha@users.sourceforge.net>2009-10-07 09:21:18 +0000
committermarha <marha@users.sourceforge.net>2009-10-07 09:21:18 +0000
commitb741086f4b268041e1c171c6dc4bb9182e7666d3 (patch)
tree02dfe9fd170cddb55b6532de49768133221ef3b6 /X11/extensions
parentf78ab58911de1fa9a15afffcd4fcdc11ae67c646 (diff)
parentc73dc01b6de45612b24dc2dd34fba24d81ebf46c (diff)
downloadvcxsrv-b741086f4b268041e1c171c6dc4bb9182e7666d3.tar.gz
vcxsrv-b741086f4b268041e1c171c6dc4bb9182e7666d3.tar.bz2
vcxsrv-b741086f4b268041e1c171c6dc4bb9182e7666d3.zip
svn merge ^/branches/released .
Diffstat (limited to 'X11/extensions')
-rw-r--r--X11/extensions/fixesproto.txt577
-rw-r--r--X11/extensions/randr.h1
-rw-r--r--X11/extensions/randrproto.txt332
-rw-r--r--X11/extensions/xfixesproto.h2
-rw-r--r--X11/extensions/xfixeswire.h2
5 files changed, 750 insertions, 164 deletions
diff --git a/X11/extensions/fixesproto.txt b/X11/extensions/fixesproto.txt
new file mode 100644
index 000000000..5ef815385
--- /dev/null
+++ b/X11/extensions/fixesproto.txt
@@ -0,0 +1,577 @@
+ 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.
diff --git a/X11/extensions/randr.h b/X11/extensions/randr.h
index c624d96b2..1ee95f936 100644
--- a/X11/extensions/randr.h
+++ b/X11/extensions/randr.h
@@ -151,6 +151,7 @@ typedef unsigned long XRandrModeFlags;
/* Conventional RandR output properties */
+#define RR_PROPERTY_BACKLIGHT "Backlight"
#define RR_PROPERTY_RANDR_EDID "EDID"
#define RR_PROPERTY_SIGNAL_FORMAT "SignalFormat"
#define RR_PROPERTY_SIGNAL_PROPERTIES "SignalProperties"
diff --git a/X11/extensions/randrproto.txt b/X11/extensions/randrproto.txt
index 1af20905a..c56bd5f29 100644
--- a/X11/extensions/randrproto.txt
+++ b/X11/extensions/randrproto.txt
@@ -1,13 +1,13 @@
The X Resize, Rotate and Reflect Extension
- Version 1.3
- 2006-20-7
-
+ Version 1.3.1
+ 2009-10-5
+
Jim Gettys
Jim.Gettys@hp.com
Cambridge Research Laboratory
HP Labs
Hewlett Packard Company
-
+
Keith Packard
keith.packard@intel.com
Open Source Technology Center
@@ -35,13 +35,13 @@ These events include:
on laptops or desktop systems
► The continued decline of legacy toolkits whose design would have
required depth switching to support migration
- ► The lack of depth switching implementation experience in the
+ ► The lack of depth switching implementation experience in the
intervening time, due to events beyond our control
Additionally, the requirement to support depth switching might
complicate other re-engineering of the device independent part of the
X server that is currently being contemplated.
-
+
Rather than further delaying RandR's widespread deployment for a feature
long wanted by the community (resizing of screens, particularly on laptops),
or the deployment of a protocol design that might be flawed due to lack of
@@ -61,7 +61,7 @@ monitors display portions of a common underlying screen. In this environment,
zero or more video outputs are associated with each CRT controller which
defines both a set of video timings and a 'viewport' within the larger
screen. This viewport is independent of the overall size of the screen, and
-may be located anywhere within the screen.
+may be located anywhere within the screen.
The effect is to decouple the reported size of the screen from the size
presented by each video output, and to permit multiple outputs to present
@@ -85,7 +85,7 @@ Additional requests and events are provided for this new functionality.
┃ ┏━━━╋━━━━━━━━━━━━━━━┫ ║ ║ ║ ║
┣━━━╋━━━┛ ┃ ╚════════╝ ╚════════╝
│ ┃ 2 ┃─────────────────┐
- │ ┃ ┃ ╔═══════════════════╗
+ │ ┃ ┃ ╔═══════════════════╗
│ ┃ ┃ ║ ║
│ ┗━━━━━━━━━━━━━━━━━━━┫ ║ C ║
└───────────────────────┘ ║ ║
@@ -215,7 +215,7 @@ RRCONFIGSTATUS { Success
A value of type RRCONFIGSTATUS returned when manipulating the output
configuration or querying information from the server that has some
time-dependency.
-
+
InvalidConfigTime indicates that the supplied configuration
timestamp does not match the current X server configuration
timestamp. Usually this means that the output configuration has
@@ -249,7 +249,7 @@ ROTATION { Rotate_0
RRSELECTMASK { RRScreenChangeNotifyMask
RRCrtcChangeNotifyMask (New in version 1.2)
- RROutputChangeNotifyMask (New in version 1.2)
+ RROutputChangeNotifyMask (New in version 1.2)
RROutputPropertyNotifyMask (New in version 1.2) }
SIZEID { CARD16 }
@@ -342,25 +342,25 @@ The name of this extension is "RANDR".
the client connected, to avoid race conditions.
New for version 1.2:
-
+
If 'enable' contains RRCrtcChangeMask, RRCrtcChangeNotify events
will be sent when a the configuration for a CRTC associated with the
screen changes, either through this protocol extension or due to
detected external changes. RRCrtcChangeNotify may also be sent when
this request executes if the CRTC configuration has changed since
- the client connected, to avoid race conditions.
-
+ the client connected, to avoid race conditions.
+
If 'enable' contains RROutputChangeMask, RROutputChangeNotify events
will be sent when a the configuration for an output associated with
the screen changes, either through this protocol extension or due to
detected external changes. RROutputChangeNotify may also be sent
when this request executes if the output configuration has changed
- since the client connected, to avoid race conditions.
+ since the client connected, to avoid race conditions.
If 'enable' contains RROutputPropertyNotifyMask,
RROutputPropertyNotify events will be sent when properties change on
this output.
-
+
┌───
RRSetScreenConfig
window: WINDOW
@@ -381,7 +381,7 @@ The name of this extension is "RANDR".
If 'timestamp' is less than the time when the configuration was last
successfully set, the request is ignored and InvalidTime returned in
status.
-
+
If 'config-timestamp' is not equal to when the server's screen
configurations last changed, the request is ignored and
InvalidConfigTime returned in status. This could occur if the
@@ -396,19 +396,19 @@ The name of this extension is "RANDR".
This request may fail for other indeterminate reasons, in which case
'status' will be set to Failed and no configuration change will be
made.
-
+
This request sets the screen to the specified size, rate, rotation
and reflection.
When this request succeeds, 'status' contains Success and the
requested changes to configuration will have been made.
-
+
'new-time-stamp' contains the time at which this request was
executed.
-
+
'config-timestamp' contains the time when the possible screen
configurations were last changed.
-
+
'root' contains the root window for the screen indicated by the
window.
@@ -421,7 +421,7 @@ The name of this extension is "RANDR".
┌───
RRGetScreenInfo
window: WINDOW
- ▶
+ ▶
rotations: SETofROTATION
root: WINDOW
timestamp: TIMESTAMP
@@ -442,15 +442,15 @@ The name of this extension is "RANDR".
by the screen.
'root' is the root window of the screen.
-
+
'config-timestamp' indicates when the screen configuration
information last changed: requests to set the screen will fail
unless the timestamp indicates that the information the client
is using is up to date, to ensure clients can be well behaved
- in the face of race conditions.
-
+ in the face of race conditions.
+
'timestamp' indicates when the configuration was last set.
-
+
'size-id' indicates which size is active.
'rate' is the current refresh rate. This is zero when the refresh
@@ -533,7 +533,7 @@ dynamic changes in the display environment.
to the screen associated with 'window'.
'timestamp' indicates when the configuration was last set.
-
+
'config-timestamp' indicates when the configuration information last
changed. Requests to configure the output will fail unless the
timestamp indicates that the information the client is using is up
@@ -545,7 +545,7 @@ dynamic changes in the display environment.
'outputs' contains the list of outputs associated with the screen.
'modes' contains the list of modes associated with the screen
-
+
This request explicitly asks the server to ensure that the
configuration data is up-to-date wrt the hardware. If that requires
polling, this is when such polling would take place. If the
@@ -560,7 +560,7 @@ dynamic changes in the display environment.
status: RRCONFIGSTATUS
timestamp: TIMESTAMP
crtc: CRTC
-
+
name: STRING
connection: CONNECTION
subpixel-order: SUBPIXELORDER
@@ -573,15 +573,15 @@ dynamic changes in the display environment.
Errors: Output
RRGetOutputInfo returns information about the current and available
- configurations 'output'.
-
+ configurations 'output'.
+
If 'config-timestamp' does not match the current configuration
timestamp (as returned by RRGetScreenResources), 'status' is set to
InvalidConfigTime and the remaining reply data is empty. Otherwise,
'status' is set to Success.
'timestamp' indicates when the configuration was last set.
-
+
'crtc' is the current source CRTC for video data, or Disabled if the
output is not connected to any CRTC.
@@ -592,7 +592,7 @@ dynamic changes in the display environment.
device connected to this output. If the hardware cannot determine
whether something is connected, it will set this to
UnknownConnection.
-
+
'subpixel-order' contains the resulting subpixel order of the
connected device to allow correct subpixel rendering.
@@ -648,7 +648,7 @@ dynamic changes in the display environment.
and be automatically copied to the current value on the next
RRSetCrtcConfig request involving the named output. If 'pending' is
FALSE, changes are copied immediately.
-
+
If 'range' is TRUE, then the valid-values list will contain
precisely two values indicating the minimum and maximum allowed
values. If 'range' is FALSE, then the valid-values list will contain
@@ -658,7 +658,7 @@ dynamic changes in the display environment.
If 'immutable' is TRUE, then the property configuration cannot be
changed by clients. Immutable properties are interpreted by the X
server.
-
+
┌───
RRConfigureOutputProperty
output: OUTPUT
@@ -687,7 +687,7 @@ dynamic changes in the display environment.
data: LISTofINT8 or LISTofINT16 or LISTofINT32
└───
Errors: Alloc, Atom, Match, Value, Output
-
+
This request alters the value of the property for the specified
output. If the property is marked as a 'pending' property, only the
pending value of the property is changed. Otherwise, changes are
@@ -702,7 +702,7 @@ dynamic changes in the display environment.
match the existing property value (or a Match error results). If
the property is undefined, it is treated as defined with the correct
type and format with zero-length data.
-
+
For Prepend, the data is tacked on to the beginning of the existing
data, and for Append, it is tacked on to the end of the existing data.
@@ -713,7 +713,7 @@ dynamic changes in the display environment.
destroyed, or until server reset (see section 10).
The maximum size of a property is server-dependent and may vary
- dynamically.
+ dynamically.
┌───
RRDeleteOutputProperty
@@ -721,7 +721,7 @@ dynamic changes in the display environment.
property: ATOM
└───
Errors: Atom, Output
-
+
This request deletes the property from the specified window if the
property exists and generates a OutputPropertyNotify event unless
the property does not exist.
@@ -745,28 +745,28 @@ dynamic changes in the display environment.
If the specified property does not exist for the specified output,
then the return type is None, the format and bytes-after are zero,
and the value is empty. The delete argument is ignored in this
- case.
-
+ 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.
-
+ argument is ignored in this case.
+
If the specified property exists and either AnyPropertyType is
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
+ N = actual length of the stored property in bytes
(even if the format is 16 or 32)
I = 4 × offset
T = N - I
L = MINIMUM(T, 4 × long-length)
A = N - (I + L)
-
+
If 'pending' is true, and if the property holds a pending value,
then the value returned will be the pending value of the property
rather than the current value. The returned value starts at byte
@@ -785,14 +785,14 @@ dynamic changes in the display environment.
mode: MODE
└───
Errors: Window, Name, Value
-
+
'modeinfo' provides a new mode for outputs on the screen
associated with 'window'. If the name of 'modeinfo' names an
existing mode, a Name error is returned. If some parameter of the
mode is not valid in some other way, a Value error is returned.
The returned 'mode' provides the id for the mode.
-
+
┌───
RRDestroyMode
mode: MODE
@@ -803,7 +803,7 @@ dynamic changes in the display environment.
defined with RRCreateMode, else an Match error is returned. If
'mode' is in use by some CRTC or Output, then an Access error is
returned.
-
+
┌───
RRAddOutputMode
output: OUTPUT
@@ -814,10 +814,10 @@ dynamic changes in the display environment.
'output' indicates which output is to be configured.
'mode' specifies which mode to add. If 'mode' is not valid for
- 'output', then a Match error is generated.
+ 'output', then a Match error is generated.
This request generates OutputChangeNotify events.
-
+
┌───
RRDeleteOutputMode
output: OUTPUT
@@ -845,7 +845,7 @@ dynamic changes in the display environment.
mode: MODE
rotation: ROTATION
outputs: LISTofOUTPUT
-
+
rotations: SETofROTATION
possible-outputs: LISTofOUTPUT
└───
@@ -860,23 +860,23 @@ dynamic changes in the display environment.
timestamp (as returned by RRGetScreenResources), 'status' is set to
InvalidConfigTime and the remaining reply data is empty. Otherwise,
'status' is set to Success.
-
+
'timestamp' indicates when the configuration was last set.
-
+
'x' and 'y' indicate the position of this CRTC within the screen
region. They will be set to 0 when the CRTC is disabled.
'width' and 'height' indicate the size of the area within the screen
presented by this CRTC. This may be different than the size of the
- mode due to rotation. They will be set to 0 when the CRTC is
- disabled.
-
+ mode due to rotation. They will be set to 0 when the CRTC
+ is disabled.
+
'mode' indicates which mode is active, or None indicating that the
CRTC has been disabled and is not displaying the screen contents.
'rotation' indicates the active rotation. It is set to Rotate_0
when the CRTC is disabled.
-
+
'outputs' is the list of outputs currently connected to this CRTC
and is empty when the CRTC is disabled.
@@ -904,7 +904,7 @@ dynamic changes in the display environment.
If 'timestamp' is less than the time when the configuration was last
successfully set, the request is ignored and InvalidTime returned in
status.
-
+
If 'config-timestamp' is not equal to when the monitor's
configuration last changed, the request is ignored and
InvalidConfigTime returned in status. This could occur if the
@@ -929,16 +929,16 @@ dynamic changes in the display environment.
'outputs' contains the set of outputs that this CRTC should be
connected to. The set must be among the list of acceptable output
- sets for this CRTC or a Match error results.
-
+ sets for this CRTC or a Match error results.
+
If 'mode' is None, then 'outputs' must be empty, else a Match error
results. Conversely, if 'mode' is not None, then 'outputs' must not be
empty, else a Match error results.
-
+
This request may fail for other indeterminate reasons, in which case
'status' will be set to Failed and no configuration change will be
made.
-
+
This request sets the CRTC to the specified position, mode, rotation
and reflection. The entire area of the CRTC must fit within the
screen size, else a Match error results. As an example, rotating the
@@ -955,10 +955,10 @@ dynamic changes in the display environment.
When this request succeeds, 'status' contains Success and the
requested changes to configuration will have been made.
-
+
'new-time-stamp' contains the time at which this request was
executed.
-
+
┌───
RRGetCrtcGammaSize
crtc: CRTC
@@ -976,13 +976,13 @@ dynamic changes in the display environment.
red: LISTofCARD16
green: LISTofCARD16
blue: LISTofCARD16
-└───
+└───
Errors: Crtc
-
+
This request returns the currently set gamma ramps for 'crtc'. All
three lists will be the size returned by the RRGetCrtcGammaSize
request.
-
+
┌───
RRSetCrtcGamma
crtc: CRTC
@@ -991,7 +991,7 @@ dynamic changes in the display environment.
blue: LISTofCARD16
└───
Errors: Crtc, Match
-
+
This request sets the gamma ramps for 'crtc'. All three lists
must be the size returned by RRGetCrtcGammaSize else a Value error
results.
@@ -1014,7 +1014,7 @@ dynamic changes in the display environment.
connected to the screen associated with 'window'.
'timestamp' indicates when the configuration was last set.
-
+
'config-timestamp' indicates when the configuration information last
changed. Requests to configure the output will fail unless the
timestamp indicates that the information the client is using is up
@@ -1025,8 +1025,8 @@ dynamic changes in the display environment.
'outputs' contains the list of outputs associated with the screen.
- 'modes' contains the list of modes associated with the screen
-
+ 'modes' contains the list of modes associated with the screen.
+
Unlike RRGetScreenResources, this merely returns the current
configuration, and does not poll for hardware changes.
@@ -1211,10 +1211,6 @@ dynamic changes in the display environment.
desktop environments to mark the screen that should hold the primary
menu bar or panel.
- If the named output is not connected to any CRTC, or if the Window
- and Output are not attached to the same screen, BadMatch is generated.
- In the latter case, errorValue will be the Window, not the Output.
-
As this changes the logical layout of the screen, ConfigureNotify
and RRScreenChangeNotify will be generated on the appropriate root
window when the primary output is changed by this call. This request
@@ -1238,7 +1234,7 @@ dynamic changes in the display environment.
└───
Errors: Window
- RRGetOutputPrimary returns the primary output for the system.
+ RRGetOutputPrimary returns the primary output for the screen.
❧❧❧❧❧❧❧❧❧❧❧
@@ -1401,6 +1397,83 @@ doesn't handle a mandatory property correctly.
9.1 Known properties
+ "Backlight" aka RR_PROPERTY_BACKLIGHT
+ Type: int32
+ Flags: -
+ Range/List: 0-x (driver specific)
+
+ This property controls the brightness on laptop panels and equivalent
+ displays with a backlight controller. The driver specific maximum
+ value MUST turn the backlight to full brightness, 1 SHOULD turn the
+ backlight to minimum brightness, 0 SHOULD turn the backlight off.
+
+ "CloneList" aka RR_PROPERTY_CLONE_LIST
+ Type: int32 [2*n] / Atom pairs
+ Flags: Immutable
+ Range/List: 0-
+
+ Some combinations of outputs on some cards cannot be served
+ independently from each other, because they are wired up to the same
+ encoder outputs.
+ This property lists all output + signal format pairs that are
+ driven together with this output, and thus can only be programmed in
+ clone mode with the same CRTC.
+ This property MUST be symmetric, but may change with changing signal
+ format. I.e. if the property for DVI-1/VGA specifies VGA-1/VGA to be
+ cloned, VGA-1/VGA has to list DVI-1/VGA as well.
+ Outputs / format pairs listed in this property MUST be included in the
+ CompatibilityList.
+
+ "CompatibilityList" aka RR_PROPERTY_COMPATIBILITY_LIST
+ Type: int32 [2*n] / Atom pairs
+ Flags: Immutable
+ Range/List: 0-
+
+ Some combinations of outputs on some cards cannot be served at all,
+ because the according encoder is only capable of driving one output at
+ a time.
+ This property lists all output + signal format pairs that can be
+ driven together with this output. NULL atoms specify any output / any
+ signal format, respectively.
+ This property MUST be symmetric, but may change with changing signal
+ format. I.e. if the property for DVI-1/TMDS specifies VGA-1/VGA to be
+ available, VGA-1/VGA has to list DVI-1/TMDS as well.
+
+ "ConnectorNumber" aka RR_PROPERTY_CONNECTOR_NUMBER
+ Type: int32
+ Flags: Immutable, Static
+ Range/List: 0-
+
+ Outputs that route their signal to the same connector MUST
+ have the same connector number. Outputs with the same
+ connector number MUST route their signal to the same
+ connector, except if it is 0, which indicates unknown
+ connectivity. 1 is called the primary connector, 2 the
+ secondary. 3 is typically a TV connector, but that is completely
+ driver / hardware dependent.
+ Outputs with the same connector number SHOULD have the same
+ connector type. Meaning and client behavior for mismatching
+ connector types is undefined at the moment.
+
+ "ConnectorType" aka RR_PROPERTY_CONNECTOR_TYPE
+ Type: int32 / Atom
+ Flags: Immutable, Static
+ Range/List: unknown VGA DVI DVI‐I DVI‐A DVI‐D HDMI Panel
+ TV TV-Composite TV-SVideo TV-Component
+ TV-SCART TV-C4 DisplayPort
+
+ Connector type, as far as known to the driver.
+ Values with dashes (TV‐Composite) describe more specific versions of
+ the base values (TV). The former SHOULD be used if the connector is
+ not capable of producing other signal formats. The later SHOULD be
+ used if the exact connector is unknown, or the connector is a
+ multi‐format connector that is not described otherwise. DVI, for
+ instance, SHOULD be handled like a DVI‐I connector, unless additional
+ information is available to the user agent. PANEL describes
+ laptop‐internal (normally LVDS) displays. TV, TV‐SCART, TV‐Component,
+ and TV‐C4 with signal format VGA are valid combinations and describe
+ RGB TV signals.
+
"EDID" aka RR_PROPERTY_RANDR_EDID
Type: int8 [n]
Flags: Immutable
@@ -1408,7 +1481,7 @@ doesn't handle a mandatory property correctly.
Raw EDID data from the device attached to the according
output. Should include main EDID data and all extension
- blocks.
+ blocks. Previously known as EdidData.
"SignalFormat" aka RR_PROPERTY_SIGNAL_FORMAT
Type: int32 / Atom
@@ -1454,93 +1527,32 @@ doesn't handle a mandatory property correctly.
a signal change (e.g. TV formats). Clients are allowed to change the
properties in order to select a different signal subformat.
- "ConnectorType" aka RR_PROPERTY_CONNECTOR_TYPE
- Type: int32 / Atom
- Flags: Immutable, Static
- Range/List: unknown VGA DVI DVI‐I DVI‐A DVI‐D HDMI Panel
- TV TV-Composite TV-SVideo TV-Component
- TV-SCART TV-C4 DisplayPort
-
- Connector type, as far as known to the driver.
- Values with dashes (TV‐Composite) describe more specific versions of
- the base values (TV). The former SHOULD be used if the connector is
- not capable of producing other signal formats. The later SHOULD be
- used if the exact connector is unknown, or the connector is a
- multi‐format connector that is not described otherwise. DVI, for
- instance, SHOULD be handled like a DVI‐I connector, unless additional
- information is available to the user agent. PANEL describes
- laptop‐internal (normally LVDS) displays. TV, TV‐SCART, TV‐Component,
- and TV‐C4 with signal format VGA are valid combinations and describe
- RGB TV signals.
-
- "ConnectorNumber" aka RR_PROPERTY_CONNECTOR_NUMBER
- Type: int32
- Flags: Immutable, Static
- Range/List: 0-
-
- Outputs that route their signal to the same connector MUST
- have the same connector number. Outputs with the same
- connector number MUST route their signal to the same
- connector, except if it is 0, which indicates unknown
- connectivity. 1 is called the primary connector, 2 the
- secondary. 3 is typically a TV connector, but that is completely
- driver / hardware dependent.
- Outputs with the same connector number SHOULD have the same
- connector type. Meaning and client behavior for mismatching
- connector types is undefined at the moment.
-
- "CompatibilityList" aka RR_PROPERTY_COMPATIBILITY_LIST
- Type: int32 [2*n] / Atom pairs
- Flags: Immutable
- Range/List: 0-
-
- Some combinations of outputs on some cards cannot be served at all,
- because the according encoder is only capable of driving one output at
- a time.
- This property lists all output + signal format pairs that can be
- driven together with this output. NULL atoms specify any output / any
- signal format, respectively.
- This property MUST be symmetric, but may change with changing signal
- format. I.e. if the property for DVI-1/TMDS specifies VGA-1/VGA to be
- available, VGA-1/VGA has to list DVI-1/TMDS as well.
-
- "CloneList" aka RR_PROPERTY_CLONE_LIST
- Type: int32 [2*n] / Atom pairs
- Flags: Immutable
- Range/List: 0-
-
- Some combinations of outputs on some cards cannot be served
- independently from each other, because they are wired up to the same
- encoder outputs.
- This property lists all output + signal format pairs that are
- driven together with this output, and thus can only be programmed in
- clone mode with the same CRTC.
- This property MUST be symmetric, but may change with changing signal
- format. I.e. if the property for DVI-1/VGA specifies VGA-1/VGA to be
- cloned, VGA-1/VGA has to list DVI-1/VGA as well.
- Outputs / format pairs listed in this property MUST be included in the
- CompatibilityList.
-
9.2 Properties introduced with version 1.2 of the RandR extension
Property Immutable Mandatory since
──────── ───────── ───────────────
-EdidData yes n/a
+EDID yes n/a
-EdidData is provided by the RandR frontend, thus not driver specific.
+EDID is provided by the RandR frontend, thus not driver specific.
9.3 Properties introduced with version 1.3 of the RandR extension
Property Immutable Mandatory since
──────── ───────── ───────────────
+CloneList yes not mandatory
+CompatibilityList yes not mandatory
+ConnectorNumber yes: static not mandatory
+ConnectorType yes: static RandR 1.3
SignalFormat no RandR 1.3
SignalProperties no not mandatory
-ConnectorType yes: static RandR 1.3
-ConnectorNumber yes: static not mandatory
-CompatibilityList yes not mandatory
-CloneList yes not mandatory
+
+9.4 Properties introduced with version 1.4 of the RandR extension
+
+Property Immutable Mandatory since
+──────── ───────── ───────────────
+Backlight no not mandatory
❧❧❧❧❧❧❧❧❧❧❧
@@ -1655,7 +1667,7 @@ A.1 Common Types
0x0008 OutputPropertyNotifyMask Added in version 1.2
└───
Event select mask for RRSelectInput
-
+
┌───
RRCONFIGSTATUS
0x0 Success
@@ -1664,7 +1676,7 @@ A.1 Common Types
0x3 Failed
└───
Return status for requests which depend on time.
-
+
┌───
MODEINFO (32) Added in version 1.2
4 CARD32 id
@@ -1681,7 +1693,7 @@ A.1 Common Types
2 CARD16 name length
4 SETofMODEFLAG mode flags
└───
-
+
An output mode specifies the complete CRTC timings for
a specific mode. The vertical and horizontal synchronization rates
can be computed given the dot clock and the h total/v total
@@ -1689,7 +1701,7 @@ A.1 Common Types
parameters and flags are not used, and must be zero as this
indicates that the timings are unknown or otherwise unused.
The name itself will be encoded separately in each usage.
-
+
┌───
MODEFLAG
0x00000001 HSyncPositive
@@ -1738,7 +1750,7 @@ errors if used in version 1.0.
└───
┌───
RRSetScreenConfig
-
+
1 CARD8 major opcode
1 2 RandR opcode
2 6 length
@@ -2171,7 +2183,7 @@ A.2.2 Protocol Requests added with version 1.3
p unused, p=pad(n)
4v FIXED filter params
└───
-
+
┌───
RRGetCrtcTransform
1 CARD8 major opcode
@@ -2199,7 +2211,7 @@ A.2.2 Protocol Requests added with version 1.3
cnp unused, cnp=pad(cn)
4*cf FIXED current filter params
└───
-
+
┌───
RRGetPanning
1 CARD8 major opcode
@@ -2261,7 +2273,7 @@ A.2.2 Protocol Requests added with version 1.3
4 WINDOW window
4 OUTPUT output
└───
-
+
┌───
RRGetOutputPrimary
1 CARD8 major opcode
@@ -2355,13 +2367,13 @@ A.4 Protocol Errors
Base + 1 Crtc
Base + 2 Mode
└───
-
+
Bibliography
[RANDR] Gettys, Jim and Keith Packard, "The X Resize and Rotate
Extension - RandR", Proceedings of the 2001 USENIX Annual
Technical Conference, Boston, MA
-[RENDER]
+[RENDER]
Packard, Keith, "The X Rendering Extension", work in progress,
- documents found in xc/specs/Render.
+ http://cgit.freedesktop.org/xorg/proto/renderproto/tree/renderproto.txt
diff --git a/X11/extensions/xfixesproto.h b/X11/extensions/xfixesproto.h
index 545e325a9..1e9a98306 100644
--- a/X11/extensions/xfixesproto.h
+++ b/X11/extensions/xfixesproto.h
@@ -1,6 +1,4 @@
/*
- * $XFree86: xc/include/extensions/xfixesproto.h,v 1.1 2002/11/30 06:21:43 keithp Exp $
- *
* Copyright 2006 Sun Microsystems
*
* Permission to use, copy, modify, distribute, and sell this software and its
diff --git a/X11/extensions/xfixeswire.h b/X11/extensions/xfixeswire.h
index 6f2027057..72e84a7ff 100644
--- a/X11/extensions/xfixeswire.h
+++ b/X11/extensions/xfixeswire.h
@@ -1,6 +1,4 @@
/*
- * $XFree86: xc/include/extensions/xfixeswire.h,v 1.1 2002/11/30 06:21:43 keithp Exp $
- *
* Copyright 2006 Sun Microsystems
*
* Permission to use, copy, modify, distribute, and sell this software and its