Added:

fixesproto-4.1.tar.gz
glproto-1.4.10.tar.gz
inputproto-1.9.99.15.tar.gz
randrproto-1.3.0.tar.gz
renderproto-0.11.tar.gz
xextproto-7.0.99.3.tar.gz
xproto-7.0.15.tar.gz

1 files changed, 628 insertions, 28 deletions

diff --git a/X11/extensions/randrproto.txt b/X11/extensions/randrproto.txt
index 6719cf800..1af20905a 100644
--- a/X11/extensions/randrproto.txt
+++ b/X11/extensions/randrproto.txt
@@ -1,6 +1,6 @@
 	       The X Resize, Rotate and Reflect Extension
-			      Version 1.2
-			       2006-4-13
+			      Version 1.3
+			       2006-20-7
       
 			      Jim Gettys
 			   Jim.Gettys@hp.com
@@ -110,6 +110,20 @@ bandwidth for large resolution screens. This is exposed in RandR by
 requiring that nothing be connected to the second CRTC when driving a high
 resolution screen on the first.
 
+1.3 Introduction to version 1.3 of the extension
+
+Version 1.3 builds on the changes made with version 1.2 and adds some new
+capabilities without fundmentally changing the extension again. The
+following features are added in this version:
+
+   • Projective Transforms. The implementation work for general rotation
+     support made it trivial to add full projective transformations. These
+     can be used to scale the screen up/down as well as perform projector
+     keystone correct or other effects.
+
+   • Panning. It was removed with RandR 1.2 because the old semantics didn't
+     fit any longer. With RandR 1.3 panning can be specified per crtc.
+
 1.1 Acknowledgements
 
 Our thanks to the contributors to the design found on the xpert mailing
@@ -497,6 +511,12 @@ dynamic changes in the display environment.
 	extension and the core protocol. They must be non-zero, or Value
 	error results.
 
+	If panning is enabled, the width and height of the panning and the
+	tracking areas are adapted to the new size and clamped afterwards.
+	Disabled panning axes remain disabled.
+	Panning borders are disabled if their requirements are no longer met
+	(see RRSetPanning).
+
 ┌───
     RRGetScreenResources
 	window: WINDOW
@@ -528,10 +548,10 @@ dynamic changes in the display environment.
 	
 	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. Requests for
-	further information should not poll, but rather return the data
-	collected at this point.
-	
+	polling, this is when such polling would take place.  If the
+	current configuration is all that's required, use
+	RRGetScreenResourcesCurrent instead.
+
 ┌───
     RRGetOutputInfo
 	output: OUTPUT
@@ -846,8 +866,10 @@ dynamic changes in the display environment.
 	'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 presented by this
-	CRTC.
+	'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' indicates which mode is active, or None indicating that the
 	CRTC has been disabled and is not displaying the screen contents.
@@ -925,6 +947,12 @@ dynamic changes in the display environment.
 	then re-enabling the CRTC at the new configuration to avoid an
 	invalid intermediate configuration.
 
+	If panning is enabled, the width and height of the panning and the
+	tracking areas are clamped to the new mode size.
+	Disabled panning axes remain disabled.
+	Panning borders are disabled if their requirements are no longer met
+	(see RRSetPanning).
+
 	When this request succeeds, 'status' contains Success and the
 	requested changes to configuration will have been made.
 	
@@ -968,6 +996,250 @@ dynamic changes in the display environment.
 	must be the size returned by RRGetCrtcGammaSize else a Value error
 	results.
 
+7.2. Extension Requests added in version 1.3 of the extension
+
+┌───
+    RRGetScreenResourcesCurrent
+	window: WINDOW
+      ▶
+	timestamp: TIMESTAMP
+	config-timestamp: TIMESTAMP
+	crtcs: LISTofCRTC
+	outputs: LISTofOUTPUT
+	modes: LISTofMODEINFO
+└───
+	Errors: Window
+
+	RRGetScreenResourcesCurrent returns the list of outputs and crtcs
+	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
+	to date, to ensure clients can be well behaved in the face of race
+	conditions.
+
+	'crtcs' contains the list of CRTCs associated with the screen.
+
+	'outputs' contains the list of outputs 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.
+
+┌───
+    RRSetCrtcTransform
+	crtc: CRTC
+	transform: TRANSFORM
+	filter: STRING8
+	values: LISTofFIXED
+└───
+	Errors: Crtc, Match
+
+	This request provides a mechanism that is more general than the
+	existing rotation and reflection values for describing the
+	transformation from frame buffer image to crtc presentation.
+	'transform' is a full 2D projective transformation from screen
+	coordinate space to crtc coordinate space. This transformation is
+	applied before the rotation and reflection values to compute the
+	complete transform.
+
+	'filter' and 'values' specify a Render filter that may be used by the
+	server when transforming data from frame buffer to crtc.
+
+	This request sets the transform to be used at the next
+	RRSetCrtcConfig request execution; it does not cause any change to
+	occur in the current configuration.
+
+	When a non-identity transformation is in use, the rectangle returned
+	by RRGetCrtcInfo defines the bounding rectangle of the screen that is
+	projected to the crtc. It is this projected rectangle which must be
+	within the area of the screen when the mode is set.
+
+┌───
+    RRGetCrtcTransform
+	crtc: CRTC
+      ▶
+	pending-transform: TRANSFORM
+	pending-filter: STRING8
+	pending-values: LISTofFIXED
+	current-transform: TRANSFORM
+	current-filter: STRING8
+	current-values: LISTofFIXED
+└───
+
+	This request returns the pending and current transforms for the
+	specified CRTC. The pending transform will be the same as the current
+	transform if no new pending transform has been set since the last call
+	to RRSetCrtcConfig.
+
+┌───
+    RRGetPanning
+	crtc: CRTC
+      ▶
+	status: RRCONFIGSTATUS
+	timestamp: TIMESTAMP
+	left, top, width, height: CARD16
+	track_left, track_top, track_width, track_height: CARD16
+	border_left, border_top, border_right, border_bottom: INT16
+└───
+
+	Errors: Crtc
+
+	Version 1.3 adds panning support again. If multiple crtcs are active
+	the panning behavior can be defined per crtc individually.
+	RRGetPanning returns information about the currently set panning
+	configuration for the specified crtc.  If the CRTC does not support
+	panning, all fields (except timestamp) will be 0.
+
+	'timestamp' indicates when the configuration was last set.
+
+	All other entries are explained for RRSetPanning.
+
+┌───
+    RRSetPanning
+	crtc: CRTC
+	timestamp: TIMESTAMP
+	left, top, width, height: CARD16
+	track_left, track_top, track_width, track_height: CARD16
+	border_left, border_top, border_right, border_bottom: INT16
+      ▶
+	status: RRCONFIGSTATUS
+	new-timestamp: TIMESTAMP
+└───
+	Errors: Crtc, Match
+
+	This request sets the panning parameters.  As soon as panning is
+	enabled, the CRTC position can change with every pointer move.
+	RRCrtcChangeNotify events are sent to the clients requesting those.
+
+	If 'timestamp' is less than the time when the configuration was last
+	successfully set, the request is ignored and InvalidTime returned in
+	status.
+
+	┌──┳━━━━━━━━━━━━━━┳─────┬ ─ ─ ─ ─ ─ ┐
+	│  ┃     CRTC     ┃     │
+	│  ┃              ┃     │           │
+	│  ┃             X┃→    │
+	│  ┃              ┃     │           │  framebuffer
+	│  ┗━━━━━━━━━━━━━━┛     │
+	│                       │           │
+	│panning area           │
+	└───────────────────────┴ ─ ─ ─ ─ ─ ┘
+
+	'left', 'top', 'width', and 'height' contain the total panning area
+	for this CRTC.  'width' has to be larger than or equal to the CRTC's
+	width or 0, and 'left'+'width' must be within the screen size, else a
+	Match error results.  Equivalent restrictions for the height exist.
+	'width' or 'height' set to 0 indicate that panning should be disabled
+	on the according axis.  Setting 'width'/'height' to the CRTC's
+	width/height will disable panning on the X/Y axis as well, but
+	RRSetScreenSize will silently enable panning if the screen size is
+	increased. This does not happen if set to 0.
+
+	┌────────┳━━━━━━━━━━━━━━┳ ─ ─ ─ ─ ─ ┐
+	│        ┃     CRTC     ┃
+	│        ┃              ┃           │
+	│        ┃              ┃
+	│        ┃              ┃           │  tracking area
+	│        ┗━━━━━━━━━━━━━━┫     X
+	│               ↓       │     ↓     │
+	│panning area           │
+	└───────────────────────┴ ─ ─ ─ ─ ─ ┘
+
+	'track_left', 'track_top', 'track_width', and 'track_height' contain
+	the pointer area for which the panning region is updated.  For normal
+	use cases it should enclose the panning area minus borders, and is
+	typically set to either the panning area minus borders, or to the
+	total screen size. If set to the total screen size, the CRTC will pan
+	in the remaining axis even if the pointer is outside the panning area
+	on a different CRTC, as shown in the figure above. If the pointer is
+	outside the tracking area, the CRTC will not pan. Zero can be used as
+	an alias for the total screen size.
+
+	┌──┳━━━━━━━━━━━━━━┳────────────┐
+	│  ┃     CRTC     ┃            │
+	│  ┃              ┃            │
+	│  ┃              ┃→           │
+	│  ┃           X←→┃            │
+	│  ┃       border_right        │
+	│  ┗━━━━━━━━━━━━━━┛            │
+	│                              │
+	│panning area                  │
+	└──────────────────────────────┘
+
+	'border_left', 'border_top', 'border_right', and 'border_bottom'
+	define the distances from the CRTC borders that will activate panning
+	if the pointer hits them.  If the borders are 0, the screen will pan
+	when the pointer hits the CRTC borders (behavior of pre-RandR Xserver
+	panning).  If the borders are positive, the screen will pan when the
+	pointer gets close to the CRTC borders, if they are negative, the
+	screen will only pan when the pointer is already way past the CRTC
+	borders.  Negative values might confuse users and disable panning to
+	the very edges of the screen.  Thus they are discouraged.
+	border_left + border_right has to be lower or equal than the CRTC's
+	width, else a Match error results.  An equivalent restriction for the
+	height exists.
+
+	Screen size changes update the panning and the tracking areas to the
+	new size. Both screen size changes and mode changes clamp these areas
+	to the current CRTC size.  In these cases panning borders are disabled
+	if their requirements are no longer met.
+
+	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.
+
+┌───
+    RRSetOutputPrimary
+	window: WINDOW
+	output: OUTPUT
+└───
+	Errors: Match, Output, Window
+
+	RRSetOutputPrimary marks 'output' as the primary output for the
+	screen with the same root window as 'window'. This output's CRTC
+	will be sorted to the front of the list in Xinerama and RANDR
+	geometry requests for the benefit of older applications. The
+	default primary output is None, and None is a legal value to pass
+	to RRSetOutputPrimary. This request is expected to be used by
+	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
+	also generates RROutputChangeNotify events on the outputs that gained
+	and lost primary status.
+
+	If an output is disconnected asynchronously (eg. due to recabling),
+	the primary status does not change, but RROutputChangeNotify events
+	will be generated if the hardware is capable of detecting this;
+	clients are expected to reconfigure if appropriate.
+
+	If an output is deleted (eg. due to device hotplug), the server will
+	act as though None was passed to RRSetOutputPrimary, including
+	generating the appropriate events.
+
+┌───
+    RRGetOutputPrimary
+	window: WINDOW
+      ▶
+	output: OUTPUT
+└───
+	Errors: Window
+
+	RRGetOutputPrimary returns the primary output for the system.
+
                               ❧❧❧❧❧❧❧❧❧❧❧
 
 8. Extension Events
@@ -990,12 +1262,12 @@ factors, such as re-cabling a monitor, etc.
 	configTimestamp: TIMESTAMP	time config data was changed
 	root: WINDOW			root window of screen
 	window: WINDOW			window requesting notification
-	size-id: SIZEID			index of new size
+	size-id: SIZEID			index of new SCREENSIZE
 	subpixelOrder: SUBPIXELORDER	order of subpixels
-	widthInPixels: CARD16
-	heightInPixels: CARD16
-	widthInMillimeters: CARD16
-	heightInMillimeters: CARD16
+	widthInPixels: CARD16		width in pixels of the new SCREENSIZE
+	heightInPixels: CARD16		height in pixels of the new SCREENSIZE
+	widthInMillimeters: CARD16	width in mm of the new SCREENSIZE
+	heightInMillimeters: CARD16	height in mm of the new SCREENSIZE
 └───
 	This event is generated whenever the screen configuration is changed
 	and sent to requesting clients. 'timestamp' indicates when the
@@ -1021,6 +1293,13 @@ factors, such as re-cabling a monitor, etc.
 	just at the time when a display manager or log in script might
 	be changing the screen size or configuration.
 
+	Note that the sizes in this event reflect the new SCREENSIZE and
+	thus will appear rotated by the 'rotation' parameter from the sizes
+	of the screen itself. In other words, when rotation is 90 or 270,
+	widthInPixels in this event will be the same as the height value
+	from a ConfigureNotify that reflects the same size change. This
+	will probably confuse developers.
+
 8.1 Events added in version 1.2 of the RandR extension
 
 ┌───
@@ -1065,27 +1344,26 @@ factors, such as re-cabling a monitor, etc.
 ┌───
     RRCrtcChangeNotify
 	timestamp: TIMESTAMP		time monitor was changed
-	config-timestamp: TIMESTAMP	time config data was changed
-	root: WINDOW			root window of screen
 	window: WINDOW			window requesting notification
 	crtc: CRTC			CRTC which changed
 	mode: MODE			new mode
 	rotation: ROTATION;		new rotation
 	x: INT16			x position of CRTC within screen
 	y: INT16			y position of CRTC within screen
+	width: CARD16			width of new mode
+	height: CARD16			height of new mode
 └───
 	This event is generated whenever the CRTC configuration is changed
 	and sent to requesting clients. 'timestamp' indicates when the
-	CRTC configuration was changed. 'config-timestamp' says when the
-	last time the configuration was changed. 'root' is the root of the
-	screen the change occurred on, 'window' is window selecting for this
-	event.
+	CRTC configuration was changed. 'window' is window selecting for this
+	event. 'mode' is the new mode, or None if the crtc is disabled.
+	'x' and 'y' mark the location in the screen where this CRTC
+	is reading data. 'width' and 'height' indicate the size of the
+	mode. 'x', 'y, 'width' and 'height' are all zero when 'mode' is None.
 
 	This event is sent whenever the monitor's configuration changes
 	or if a new monitor configuration becomes available that was
-	not available in the past. In this case (config-timestamp in
-	the event not being equal to the config-timestamp returned in
-	the last call to RRGetCrtcModes), the client MUST call
+	not available in the past. In this case, the client MUST call
 	RRGetCrtcModes to update its view of possible monitor
 	configurations to have a correct view of possible monitor
 	organizations.
@@ -1100,7 +1378,173 @@ factors, such as re-cabling a monitor, etc.
 
                               ❧❧❧❧❧❧❧❧❧❧❧
 
-9. Extension Versioning
+9. Properties
+
+Properties are used for output specific parameters, and for announcing
+static or rarely changing data.  Announced data is typically
+immutable.  Properties are also used for evaluating new parameters
+before adding them to the RandR protocol.
+
+The following properties are hereby declared official, and drivers SHOULD
+prefix driver specific properties with '_', unless they are planned to be
+added to this specification.  List values, that are not declared by the table
+below, and will remain driver specific or are not planned to be added to this
+specification, SHOULD be prefixed with "_" as well in order to avoid name
+space or semantics clashes with future extensions of these values.
+
+Beginning with version 1.3 of the RandR extension, certain properties
+are mandatory and MUST be provided by implementations.  Earlier
+versions of the RandR extension MAY provide these properties as well,
+as long as the semantics are not altered.  Clients SHOULD fall back
+gracefully to lower version functionality, though, if the driver
+doesn't handle a mandatory property correctly.
+
+9.1 Known properties
+
+    "EDID"			aka RR_PROPERTY_RANDR_EDID
+	Type:			int8 [n]
+	Flags:			Immutable
+	Range/List:		-
+
+	Raw EDID data from the device attached to the according
+	output. Should include main EDID data and all extension
+	blocks.
+
+    "SignalFormat"		aka RR_PROPERTY_SIGNAL_FORMAT
+	Type:			int32 / Atom
+	Flags:			-
+	Range/List:		unknown VGA TMDS LVDS Composite Composite-PAL
+				Composite-NTSC Composite-SECAM SVideo
+				Component DisplayPort
+
+	Signal format / physical protocol format that is used for the
+	specified output. valid-values lists all possible formats on this
+	output, which SHOULD be a subset of the list above and MUST be static.
+	Values with dashes (Composite-PAL) describe more specific versions of
+	the base values (Composite) and SHOULD be used if known to the driver.
+	A driver MAY change this property of an output if the underlying
+	hardware indicates a protocol change (e.g. TV formats).  Clients are
+	allowed to change the signal format in order to select a different
+	signal format (e.g. Composite etc.) or physical protocol (e.g. VGA or
+	TMDS on DVI-I).
+	Laptop panels SHOULD not be detected with this property, but rather by
+	ConnectorType.
+
+    "SignalProperties"		aka RR_PROPERTY_SIGNAL_FORMAT
+	Type:			int32 [n] / Atom
+	Flags:			-
+	Range/List:		For Composite signals:
+				  NTSC NTSC-M NTSC-J NTSC-N NTSC-4.43 NTSC-film
+				  PAL PAL-B PAL-G PAL-H PAL-H PAL-I PAL-M PAL-D
+				  PAL-N PAL-Nc PAL-L PAL-60
+				  SECAM SECAM-L SECAM-B SECAM-G SECAM-D SECAM-K
+				  SECAM-H SECAM-K
+				For TMDS signals:
+				  SingleLink DualLink
+				For DisplayPort signals:
+				  Lane1 Lane2 Lane4 LowSpeed HiSpeed
+
+	Properties of the signal format that is currently used for the
+	specified output. valid-values lists all possible properties on this
+	output, which SHOULD be a subset of the list above. It will change if
+	SignalFormat changes.  Multiple properties are allowed.
+	Values with dashes (PAL-B) describe more specific versions of the base
+	values (PAL) and SHOULD be used if known to the driver.  A driver MAY
+	change this property of an output if the underlying hardware indicates
+	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
+
+EdidData 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
+────────			─────────	───────────────
+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
+
+                              ❧❧❧❧❧❧❧❧❧❧❧
+
+10. Extension Versioning
 
 The RandR extension was developed in parallel with the implementation
 to ensure the feasibility of various portions of the design. As
@@ -1128,23 +1572,29 @@ list of what each version provided:
 	1.2: Separate screens from CRTCs and outputs, switch to full VESA
 	     modes
 
+	1.3: Added cheap version of RRGetScreenResources.  Added CRTC
+	     transformations.  Added panning.  Added primary outputs.
+	     Added standard properties.
+
 Compatibility between 0.0 and 1.0 was *NOT* preserved, and 0.0 clients
 will fail against 1.0 servers. The wire encoding op-codes were
 changed for GetScreenInfo to ensure this failure in a relatively
 graceful way. Version 1.1 servers and clients are cross compatible with
 1.0. Version 1.1 is considered to be stable and we intend upward
 compatibility from this point. Version 1.2 offers an extended model of the
-system with multiple output support. It offers backward compatibility with
-version 1.1.
+system with multiple output support. Version 1.3 adds a cheap version of
+GetScreenResources to avoid expensive DDC operations, CRTC transformations,
+panning, and the primary output concept. 1.2 and 1.3 are backward-compatible
+with 1.1.
 
                               ❧❧❧❧❧❧❧❧❧❧❧
 
-10. Relationship with other extensions
+11. Relationship with other extensions
 
 Two other extensions have a direct relationship with this extension. This
 section attempts to explain how these three are supposed to work together.
 
-10.1 XFree86-VidModeExtension
+11.1 XFree86-VidModeExtension
 
 XFree86-VidModeExtension changes the configuration of a single monitor
 attached to the screen without changing the configuration of the screen
@@ -1161,7 +1611,7 @@ All of the utility of this extension is subsumed by RandR version 1.2, RandR
 should be used in preference to XFree86-VidModeExtension where both are
 present.
 
-10.2 Xinerama
+11.2 Xinerama
 
 Xinerama provides a mechanism for describing the relationship between the
 overall screen display and monitors placed within that area. As such, it
@@ -1434,6 +1884,7 @@ A.2.1 Protocol Requests added with version 1.2
 	2	n			length of name
 	4c	LISTofCRTC		crtcs
 	4m	LISTofMODE		modes
+	4o	LISTofOUTPUT		clones
 	n	STRING8			name
 	p				unused, p=pad(n)
 └───
@@ -1680,6 +2131,155 @@ A.2.1 Protocol Requests added with version 1.2
 	p				unused, p=pad(6n)
 └───
 
+A.2.2 Protocol Requests added with version 1.3
+
+┌───
+    RRGetScreenResourcesCurrent
+	1	CARD8			major opcode
+	1	25			RandR opcode
+	2	2			length
+	4	WINDOW			window
+      ▶
+	1	1			Reply
+	1				unused
+	2	CARD16			sequence number
+	4	c+o+8m+(b+p)/4		reply length
+	4	TIMESTAMP		timestamp
+	4	TIMESTAMP		config-timestamp
+	2	c			number of CRTCs
+	2	o			number of outputs
+	2	m			number of modeinfos
+	2	b			total bytes in mode names
+	8				unused
+	4c	LISTofCRTC		crtcs
+	4o	LISTofOUTPUT		outputs
+	32m	LISTofMODEINFO		modeinfos
+	b	STRING8			mode names
+	p				unused, p=pad(b)
+└───
+
+┌───
+    RRSetCrtcTransform
+	1	CARD8			major opcode
+	1	26			RandR opcode
+	2	12+(n+p)/4+v		length
+	4	CRTC			crtc
+	36	TRANSFORM		transform
+	2	CARD16			filter length
+	2				unused
+	n	STRING8			filter name
+	p				unused, p=pad(n)
+	4v	FIXED			filter params
+└───
+    
+┌───
+    RRGetCrtcTransform
+	1	CARD8			major opcode
+	1	27			RandR opcode
+	2	2			length
+	4	CRTC			crtc
+      ▶
+	1	1			Reply
+	1				unused
+	2	CARD16			sequence number
+	4	16+(pn+pnp)/4+(cn+cnp)/4+pf+cf	reply length
+	36	TRANSFORM		pending transform
+	1	BOOL			has transforms
+	3				unused
+	36	TRANSFORM		current transform
+	4				unused
+	2	pn			pending filter name length
+	2	pf			pending filter num params
+	2	cn			current filter name length
+	2	cf			current filter num params
+	pn	STRING8			pending filter name
+	pnp				unused, pnp=pad(pn)
+	4*pf	FIXED			pending filter params
+	cn	STRING8			current filter name
+	cnp				unused, cnp=pad(cn)
+	4*cf	FIXED			current filter params
+└───
+    
+┌───
+    RRGetPanning
+	1	CARD8			major opcode
+	1	28			RandR opcode
+	2	2			length
+	4	CRTC			crtc
+      ▶
+	1	1			Reply
+	1	RRCONFIGSTATUS		status
+	2	CARD16			sequence number
+	4	1			reply length
+	4	TIMESTAMP		timestamp
+	2	CARD16			left
+	2	CARD16			top
+	2	CARD16			width
+	2	CARD16			height
+	2	CARD16			track_left
+	2	CARD16			track_top
+	2	CARD16			track_width
+	2	CARD16			track_height
+	2	INT16			border_left
+	2	INT16			border_top
+	2	INT16			border_right
+	2	INT16			border_bottom
+└───
+┌───
+    RRSetPanning
+	1	CARD8			major opcode
+	1	29			RandR opcode
+	2	9			length
+	4	CRTC			crtc
+	4	TIMESTAMP		timestamp
+	2	CARD16			left
+	2	CARD16			top
+	2	CARD16			width
+	2	CARD16			height
+	2	CARD16			track_left
+	2	CARD16			track_top
+	2	CARD16			track_width
+	2	CARD16			track_height
+	2	INT16			border_left
+	2	INT16			border_top
+	2	INT16			border_right
+	2	INT16			border_bottom
+      ▶
+	1	1			Reply
+	1	RRCONFIGSTATUS		status
+	2	CARD16			sequence number
+	4	0			reply length
+	4	TIMESTAMP		new timestamp
+	20				unused
+└───
+
+┌───
+    RRSetOutputPrimary
+	1	CARD8			major opcode
+	1	30			RandR opcode
+	2	3			length
+	4	WINDOW			window
+	4	OUTPUT			output
+└───
+    
+┌───
+    RRGetOutputPrimary
+	1	CARD8			major opcode
+	1	31			RandR opcode
+	2	2			length
+	4	WINDOW			window
+      ▶
+	1	1			Reply
+	1				unused
+	2	CARD16			sequence number
+	4	CARD32			length
+	4	OUTPUT			output
+	4	CARD32			pad1
+	4	CARD32			pad2
+	4	CARD32			pad3
+	4	CARD32			pad4
+└───
+
 A.3 Protocol Events
 
 ┌───