randrproto

7/23/2019 randrproto

1/51

The X Resize, Rotate and Reflect Extension Version 1.4.0 2012-07-03

Jim Gettys [email protected]

Cambridge Research LaboratoryHP Labs

Hewlett Packard Company

Keith [email protected]

Open Source Technology Center Intel Corporation

1. Introduction

The X Resize, Rotate and Reflect Extension, called RandR for short,brings the ability to resize, rotate and reflect the root window of ascreen. It is based on the X Resize and Rotate Extension as specifiedin the Proceedings of the 2001 Usenix Technical Conference [RANDR].

RandR as implemented and integrated into the X server differs inone substantial fashion from the design discussed in that paper: that

is, RandR 1.0 does not implement the depth switching described in thatdocument, and the support described for that in the protocol in thatdocument and in the implementation has been removed from theprotocol described here, as it has been overtaken by events.

These events include: Modern toolkits (in this case, GTK+ 2.x) have progressed to the point

of implementing migration between screens of arbitrary depths The continued advance of Moore's law has made limited amounts of VRAM

less of an issue, reducing the pressure to implement depth switchingon laptops or desktop systems

The continued decline of legacy toolkits whose design would haverequired depth switching to support migration

The lack of depth switching implementation experience in theintervening time, due to events beyond our control

Additionally, the requirement to support depth switching mightcomplicate other re-engineering of the device independent part of theX server that is currently being contemplated.

Rather than further delaying RandR's widespread deployment for a featurelong wanted by the community (resizing of screens, particularly on laptops),or the deployment of a protocol design that might be flawed due to lack ofimplementation experience, we decided to remove depth switching from theprotocol. It may be implemented at a later time if resources andinterests permit as a revision to the protocol described here, which will

remain a stable base for applications. The protocol described here has beenimplemented in the main X.org server, and more fully in the hw/kdriveimplementation in the distribution, which fully implements resizing,rotation and reflection.

1.2 Introduction to version 1.2 of the extension

One of the significant limitations found in version 1.1 of the RandRprotocol was the inability to deal with the Xinerama model where multiplemonitors display portions of a common underlying screen. In this environment,


2/51

zero or more video outputs are associated with each CRT controller whichdefines both a set of video timings and a 'viewport' within the largerscreen. This viewport is independent of the overall size of the screen, andmay be located anywhere within the screen.

The effect is to decouple the reported size of the screen from the sizepresented by each video output, and to permit multiple outputs to presentinformation for a single screen.

To extend RandR for this model, we separate out the output, CRTC and screenconfiguration information and permit them to be configured separately. Forcompatibility with the 1.1 version of the protocol, we make the 1.1 requestssimultaneously affect both the screen and the (presumably sole) CRTC andoutput. The set of available outputs are presented with UTF-8 encoded namesand may be connected to CRTCs as permitted by the underlying hardware. CRTCconfiguration is now done with full mode information instead of just sizeand refresh rate, and these modes have names. These names also use UTF-8encoding. New modes may also be added by the user.

Additional requests and events are provided for this new functionality.

1 A B

2 C screen CRTC output

In this picture, the screen is covered (incompletely) by two CRTCs. CRTC1is connected to two outputs, A and B. CRTC2 is connected to output C.

Outputs A and B will present exactly the same region of the screen usingthe same mode line. Output C will present a different (larger) region ofthe screen using a different mode line.

RandR provides information about each available CRTC and output; theconnection between CRTC and output is under application control, althoughthe hardware will probably impose restrictions on the possibleconfigurations. The protocol doesn't try to describe these restrictions,instead it provides a mechanism to find out what combinations are supported.


Version 1.3 builds on the changes made with version 1.2 and adds some new

capabilities without fundmentally changing the extension again. Thefollowing 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.


3/51


Version 1.4 adds an optional Border property.

An optional Border property. This property allows a client to specify that the viewport of the CRTC is smaller than the active display region described its mode. This is useful, for example, for compensating for the overscan behavior of certain televisions.

Version 1.4 adds a new object called a provider object. A provider objectrepresents a GPU or virtual device providing services to the X server.Providers have a set of abilities and a set of possible roles.

Provider objects are used to control multi-GPU systems. Provider roles canbe dynamically configured to provide support for:

1) Output slaving: plug in a USB device, but have its output renderedusing the main GPU. On some dual-GPU laptops, the second GPU isn'tconnected to the LVDS panel, so we need to use the first GPU as an outputslave for the second GPU.

2) offload - For dual-GPU laptops, allow direct rendered applications to be run

on the second GPU and display on the first GPU.3) GPU switching - Allow switching between two GPUs as the main screenrenderer.

4) multiple GPU rendering - This replaces Xinerama.

1.99 Acknowledgements

Our thanks to the contributors to the design found on the xpert mailinglist, in particular:

Alan Hourihane for work on the early implementation

Andrew C. Aitchison for help with the XFree86 DDX implementationAndy Ritger for early questions about how mergefb/Xinerama work with RandRCarl Worth for editing the specification and Usenix paperDavid Dawes for XFree86 DDX integration workThomas Winischhofer for the hardware-accelerated SiS rotation implementationMatthew Tippett and Kevin Martin for splitting outputs and CRTCs to morefully expose what video hardware can doDave Airlie for the 1.4.0 protocol changes.

2. Screen change model

Screens may change dynamically, either under control of this extension, ordue to external events. Examples include: monitors being swapped, pressing abutton to switch from internal display to an external monitor on a laptop,or, eventually, the hotplug of a display card entirely on busses such asCardbus or Express Card which permit hot-swap (which will require other workin addition to this extension).

Since the screen configuration is dynamic and asynchronous to the client andmay change at any time RandR provides mechanisms to ensure that your clientsview is up to date with the configuration possibilities of the moment and


4/51

enforces applications that wish to control the configuration to prove thattheir information is up to date before honoring requests to change thescreen configuration (by requiring a timestamp on the request).

Interested applications are notified whenever the screen configurationchanges, providing the current size of the screen and subpixel order (seethe Render extension [RENDER]), to enable proper rendering of subpixeldecimated client text to continue, along with a time stamp of theconfiguration change. A client must refresh its knowledge of the screenconfiguration before attempting to change the configuration after anotification, or the request will fail.

To avoid multiplicative explosion between orientation, reflection and sizes,the sizes are only those sizes in the normal (0) rotation.

Rotation and reflection and how they interact can be confusing. In Randr,the coordinate system is rotated in a counter-clockwise direction relativeto the normal orientation. Reflection is along the window system coordinatesystem, not the physical screen X and Y axis, so that rotation andreflection do not interact. The other way to consider reflection is to isspecified in the "normal" orientation, before rotation, if you find theother way confusing.

We expect that most clients and toolkits will be oblivious to changes to the

screen structure, as they generally use the values in the connections Displaystructure directly. By toolkits updating the values on the fly, we believepop-up menus and other pop up windows will position themselves correctly inthe face of screen configuration changes (the issue is ensuring that pop-upsare visible on the reconfigured screen).

3. Data Types

The subpixel order is shared with the Render extension, and is documentedthere. The only datatype defined is the screen size, defined in the normal(0 degree) orientation.

4. Errors

Errors are sent using core X error reports.

OutputA value for an OUTPUT argument does not name a defined OUTPUT.

CRTCA value for a CRTC argument does not name a defined CRTC.

ModeA value for a MODE argument does not name a defined MODE.

ProviderA value for a PROVIDER argument does not name a defined PROVIDER.

5. Protocol Types

RRCONFIGSTATUS { SuccessInvalidConfigTimeInvalidTime


5/51

Failed }

A value of type RRCONFIGSTATUS returned when manipulating the outputconfiguration or querying information from the server that has sometime-dependency.

InvalidConfigTime indicates that the supplied configurationtimestamp does not match the current X server configurationtimestamp. Usually this means that the output configuration haschanged since the timestamp was received by the application.

InvalidTime indicates that the supplied output reconfiguration timeis earlier than the most recent output reconfiguration request.Generally this indicates that another application has reconfiguredthe output using a later timestamp.

Failed is returned whenever the operation is unsuccessful for someother reason. This generally indicates that the requested outputconfiguration is unsupported by the hardware. The goal is to makethese limitations expressed by the protocol, but when that isn'tpossible it is correct to return this error value. If, as aimplentor, you find this error code required, please submit thehardware constraints that exist so that a future version of theextension can correctly capture the configuration constraints in

your system.ROTATION { Rotate_0

Rotate_90 Rotate_180 Rotate_270 Reflect_X Reflect_Y }

These values are used both to indicate a set of allowed rotationsand reflections as well as to indicate a specific rotation andreflection combination.

RRSELECTMASK { RRScreenChangeNotifyMask RRCrtcChangeNotifyMask (New in version 1.2) RROutputChangeNotifyMask (New in version 1.2) RROutputPropertyNotifyMask (New in version 1.2) RRProviderChangeNotifyMask (New in version 1.4) RRProviderPropertyNotifyMask (New in version 1.4) RRResourceChangeNotifyMask (New in version 1.4) }

SIZEID { CARD16 }

MODE { XID or None }

CRTC { XID }

OUTPUT { XID }

CONNECTION { Connected, Disconnected, UnknownConnection }

This value provides an indication of whether an output is actuallyconnected to a monitor or other presentation device.

SUBPIXELORDER { SubPixelUnknown The subpixel order uses the RenderSubPixelHorizontalRGB extensions definitions; they are here


6/51

SubPixelHorizontalBGR only for convenience.SubPixelVerticalRGBSubPixelVerticalBGRSubPixelNone }

SCREENSIZE { widthInPixels, heightInPixels: CARD16 widthInMillimeters, heightInMillimeters: CARD16 }

MODEFLAG { HSyncPositive HSyncNegative VSyncPositive VSyncNegative Interlace DoubleScan CSync CSyncPositive CSyncNegative HSkewPresent BCast PixelMultiplex DoubleClock ClockDivideBy2 }

MODEINFO { id: MODE

name: STRING width, height: CARD16 dotClock: CARD32 hSyncStart, hSyncEnd, hTotal, hSkew: CARD16 vSyncStart, vSyncEnd, vTotal: CARD16 modeFlags: SETofMODEFLAG }

REFRESH { rates: LISTofCARD16 }

5.5. Protocol Types added in version 1.4 of the extension

PROVIDER { XID }PROVIDER_CAPS { SourceOutput, SinkOutput, SourceOffload, SinkOffload }

Capabilties for this provider:SourceOutput: This device can source output buffers.SinkOutput: This device can sink output buffers.SourceOffload: This device can source offload buffers.SinkOffload: This device can sink offload buffers.

6. Extension Initialization

The name of this extension is "RANDR".

RRQueryVersion

client-major-version: CARD32client-minor-version: CARD32

major-version: CARD32minor-version: CARD32


7/51

The client sends the highest supported version to the serverand the server sends the highest version it supports, but nohigher than the requested version. Major versions changes canintroduce incompatibilities in existing functionality, minorversion changes introduce only backward compatible changes.It is the clients responsibility to ensure that the serversupports a version which is compatible with its expectations.

7. Extension Requests

RRSelectInput

window: WINDOWenable: SETofRRSELECTMASK

Errors: Window, Value

If 'enable' is RRScreenChangeNotifyMask, RRScreenChangeNotify eventswill be sent when the screen configuration changes, either fromthis protocol extension, or due to detected external screenconfiguration changes. RRScreenChangeNotify may also be sent when

this request executes if the screen configuration has changed sincethe client connected, to avoid race conditions.

New for version 1.2:

If 'enable' contains RRCrtcChangeMask, RRCrtcChangeNotify eventswill be sent when a the configuration for a CRTC associated with thescreen changes, either through this protocol extension or due todetected external changes. RRCrtcChangeNotify may also be sent whenthis request executes if the CRTC configuration has changed sincethe client connected, to avoid race conditions.

If 'enable' contains RROutputChangeMask, RROutputChangeNotify events

will be sent when a the configuration for an output associated withthe screen changes, either through this protocol extension or due todetected external changes. RROutputChangeNotify may also be sentwhen this request executes if the output configuration has changedsince the client connected, to avoid race conditions.

If 'enable' contains RROutputPropertyNotifyMask,RROutputPropertyNotify events will be sent when properties change onthis output.

New for version 1.4:

If 'enable' contains RRProviderChangeNotifyMask,

RRProviderChangeNotify events will be sent whenever the role for aprovider object has changed.

If 'enable' contains RRProviderPropertyNotifyMask,RRProviderPropertyNotify events will be sent when properties changeon a provider object.

If 'enable' contains RRResourceChangeNotifyMask,RRResourceChangeNotify events will be sent whenever the set ofavailable RandR resources associated with the screen has changed.


8/51

RRSetScreenConfig

window: WINDOWtimestamp: TIMESTAMPconfig-timestamp: TIMESTAMPsize-id: SIZEIDrotation: ROTATIONrate: CARD16

status: RRCONFIGSTATUSnew-timestamp: TIMESTAMPconfig-timestamp: TIMESTAMProot: WINDOWsubpixelOrder: SUBPIXELORDER

Errors: Value, Match

If 'timestamp' is less than the time when the configuration was lastsuccessfully set, the request is ignored and InvalidTime returned instatus.

If 'config-timestamp' is not equal to when the server's screenconfigurations last changed, the request is ignored and

InvalidConfigTime returned in status. This could occur if thescreen changed since you last made a RRGetScreenInfo request,perhaps by a different piece of display hardware being installed.Rather than allowing an incorrect call to be executed based on staledata, the server will ignore the request.

'rate' contains the desired refresh rate. If it is zero, the serverselects an appropriate rate.

This request may fail for other indeterminate reasons, in which case'status' will be set to Failed and no configuration change will bemade.

This request sets the screen to the specified size, rate, rotationand reflection.

When this request succeeds, 'status' contains Success and therequested changes to configuration will have been made.

'new-time-stamp' contains the time at which this request wasexecuted.

'config-timestamp' contains the time when the possible screenconfigurations were last changed.

'root' contains the root window for the screen indicated by the

window.

'subpixelOrder' contains the resulting subpixel order of the screento allow correct subpixel rendering.

Value errors are generated when 'rotation', 'rate' or 'size-id'are invalid.

RRGetScreenInfo


9/51

window: WINDOW

rotations: SETofROTATIONroot: WINDOWtimestamp: TIMESTAMPconfig-timestamp: TIMESTAMPsize-id: SIZEIDrotation: ROTATIONrate: CARD16sizes: LISTofSCREENSIZErefresh: LISTofREFRESH

Errors: Window

RRGetScreenInfo returns information about the current and availableconfigurations for the screen associated with 'window'.

'rotations' contains the set of rotations and reflections supportedby 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 failunless the timestamp indicates that the information the clientis using is up to date, to ensure clients can be well behavedin 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 refreshrate is unknown or on devices for which refresh is not relevant.

'sizes' is the list of possible frame buffer sizes (at the normal

orientation. Each size indicates both the linear physical size ofthe screen and the pixel size.

'refresh' is the list of refresh rates for each size. Each elementof 'sizes' has a corresponding element in 'refresh'. An empty listindicates no known rates, or a device for which refresh is notrelevant.

The default size of the screen (the size that would become thecurrent size when the server resets) is the first size in thelist.

7.1. Extension Requests added in version 1.2 of the extension

As introduced above, version 1.2 of the extension splits the screen sizefrom the crtc and output configuration, permitting the subset of the screenpresented by multiple outputs to be configured. As a separate notion, thesize of the screen itself may be arbitrarily configured within a definedrange. As crtcs and outputs are added and removed from the system, the setreturned by the extension will change so that applications can detectdynamic changes in the display environment.


10/51

RRGetScreenSizeRangewindow: WINDOW

CARD16 minWidth, minHeightCARD16 maxWidth, maxHeight

Errors: Window

Returns the range of possible screen sizes. The screen may be set toany size within this range.

RRSetScreenSize

window: WINDOWwidth: CARD16height: CARD16width-in-millimeters: CARD32height-in-millimeters: CARD32

Errors: Window, Match, Value

Sets the screen to the specified size. 'width' and 'height' must bewithin the range allowed by GetScreenSizeRanges, otherwise a Valueerror results. All active monitors must be configured to display a

subset of the specified size, else a Match error results.'width-in-millimeters' and 'height-in-millimeters' can be set toreflect the physical size of the screen reported both through thisextension and the core protocol. They must be non-zero, or Valueerror results.

If panning is enabled, the width and height of the panning and thetracking 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).

RRGetScreenResourceswindow: WINDOW

timestamp: TIMESTAMPconfig-timestamp: TIMESTAMPcrtcs: LISTofCRTCoutputs: LISTofOUTPUTmodes: LISTofMODEINFO

Errors: Window

RRGetScreenResources returns the list of outputs and crtcs connected

to the screen associated with 'window'.


'config-timestamp' indicates when the configuration information lastchanged. Requests to configure the output will fail unless thetimestamp indicates that the information the client is using is upto date, to ensure clients can be well behaved in the face of raceconditions.


11/51

'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

This request explicitly asks the server to ensure that theconfiguration data is up-to-date wrt the hardware. If that requirespolling, this is when such polling would take place. If thecurrent configuration is all that's required, useRRGetScreenResourcesCurrent instead.

RRGetOutputInfo

output: OUTPUTconfig-timestamp: TIMESTAMP

status: RRCONFIGSTATUStimestamp: TIMESTAMPcrtc: CRTC

name: STRINGconnection: CONNECTIONsubpixel-order: SUBPIXELORDER

widthInMillimeters, heightInMillimeters: CARD32crtcs: LISTofCRTCclones: LISTofOUTPUTmodes: LISTofMODEnum-preferred: CARD16

Errors: Output

RRGetOutputInfo returns information about the current and availableconfigurations 'output'.

If 'config-timestamp' does not match the current configurationtimestamp (as returned by RRGetScreenResources), 'status' is set to

InvalidConfigTime and the remaining reply data is empty. Otherwise,'status' is set to Success.


'crtc' is the current source CRTC for video data, or Disabled if theoutput is not connected to any CRTC.

'name' is a UTF-8 encoded string designed to be presented to theuser to indicate which output this is. E.g. "S-Video" or "DVI".

'connection' indicates whether the hardware was able to detect adevice connected to this output. If the hardware cannot determine

whether something is connected, it will set this toUnknownConnection.

'subpixel-order' contains the resulting subpixel order of theconnected device to allow correct subpixel rendering.

'widthInMillimeters' and 'heightInMillimeters' report the physicalsize of the displayed area. If unknown, or not really fixed (e.g.,for a projector), these values are both zero.


12/51

'crtcs' is the list of CRTCs that this output may be connected to.Attempting to connect this output to a different CRTC results in aMatch error.

'clones' is the list of outputs which may be simultaneouslyconnected to the same CRTC along with this output. Attempting toconnect this output with an output not in the 'clones' listresults in a Match error.

'modes' is the list of modes supported by this output. Attempting toconnect this output to a CRTC not using one of these modes resultsin a Match error.

The first 'num-preferred' modes in 'modes' are preferred by themonitor in some way; for fixed-pixel devices, this would generallyindicate which modes match the resolution of the output device.

RRListOutputProperties

output:OUTPUT

atoms: LISTofATOM

Errors: Output

This request returns the atoms of properties currently defined onthe output.

RRQueryOutputProperty

output: OUTPUTproperty: ATOM

pending: BOOLrange: BOOLimmutable: BOOLvalid-values: LISTofINT32

Errors: Name, Atom, Output

If the specified property does not exist for the specified output,then a Name error is returned.

If 'pending' is TRUE, changes made to property values withRRChangeOutputProperty will be saved in the pending property valueand be automatically copied to the current value on the nextRRSetCrtcConfig request involving the named output. If 'pending' isFALSE, changes are copied immediately.

If 'range' is TRUE, then the valid-values list will contain

precisely two values indicating the minimum and maximum allowedvalues. If 'range' is FALSE, then the valid-values list will containthe list of possible values; attempts to set other values willresult in a Value error.

If 'immutable' is TRUE, then the property configuration cannot bechanged by clients. Immutable properties are interpreted by the Xserver.


13/51

RRConfigureOutputPropertyoutput: OUTPUTproperty: ATOMpending: BOOLrange: BOOLvalid-values: LISTofINT32

Errors: Access, Name, Atom, Output

If the specified property is 'immutable', an Access error isreturned.

Otherwise, the configuration of the specified property is changed tothe values provided in this request.

If the specified property does not exist for the specified output,it is created with an empty value and None type.

RRChangeOutputProperty

output: OUTPUTproperty, type: ATOMformat: {8, 16, 32}mode: { Replace, Prepend, Append }

data: LISTofINT8 or LISTofINT16 or LISTofINT32Errors: Alloc, Atom, Match, Value, Output

This request alters the value of the property for the specifiedoutput. If the property is marked as a 'pending' property, only thepending value of the property is changed. Otherwise, changes arereflected in both the pending and current values of the property.The type is uninterpreted by the server. The format specifieswhether the data should be viewed as a list of 8-bit, 16-bit, or32-bit quantities so that the server can correctly byte-swap asnecessary.

If the mode is Replace, the previous property value is discarded.If the mode is Prepend or Append, then the type and format mustmatch the existing property value (or a Match error results). Ifthe property is undefined, it is treated as defined with the correcttype and format with zero-length data.

For Prepend, the data is tacked on to the beginning of the existingdata, and for Append, it is tacked on to the end of the existing data.

This request generates a OutputPropertyNotify

The lifetime of a property is not tied to the storing client.Properties remain until explicitly deleted, until the output is

destroyed, or until server reset (see section 10).

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

RRDeleteOutputProperty

output: OUTPUTproperty: ATOM


14/51

Errors: Atom, Output

This request deletes the property from the specified window if theproperty exists and generates a OutputPropertyNotify event unlessthe property does not exist.

RRGetOutputProperty

output: OUTPUTproperty: ATOMtype: ATOM or AnyPropertyTypelong-offset, long-length: CARD32delete: BOOLpending: BOOL

type: ATOM or Noneformat: {0, 8, 16, 32}bytes-after: CARD32value: LISTofINT8 or LISTofINT16 or LISTofINT32

Errors: Atom, Value, Output

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 thiscase.

If the specified property exists but its type does not match thespecified type, then the return type is the actual type of theproperty, the format is the actual format of the property (neverzero), the bytes-after is the length of the property in bytes (evenif the format is 16 or 32), and the value is empty. The deleteargument is ignored in this case.

If the specified property exists and either AnyPropertyType isspecified or the specified type matches the actual type of theproperty, then the return type is the actual type of the property,

the format is the actual format of the property (never zero), andthe bytes-after and value are as follows, given:

N = actual length of the stored property in bytes (even if the format is 16 or 32)

I = 4 offsetT = N - IL = 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 propertyrather than the current value. The returned value starts at byte

index I in the property (indexing from 0), and its length in bytesis L. However, it is a Value error if long-offset is given suchthat L is negative. The value of bytes-after is A, giving thenumber of trailing unread bytes in the stored property. If deleteis True and the bytes-after is zero, the property is also deletedfrom the output, and a RROutputPropertyNotify event is generated.

RRCreateMode

window: WINDOW


15/51

modeinfo: MODEINFO

mode: MODE

Errors: Window, Name, Value

'modeinfo' provides a new mode for outputs on the screenassociated with 'window'. If the name of 'modeinfo' names anexisting mode, a Name error is returned. If some parameter of themode is not valid in some other way, a Value error is returned.

The returned 'mode' provides the id for the mode.

RRDestroyMode

mode: MODE

Errors: Mode, Access

The user-defined 'mode' is destroyed. 'mode' must name a modedefined with RRCreateMode, else an Match error is returned. If'mode' is in use by some CRTC or Output, then an Access error isreturned.

RRAddOutputModeoutput: OUTPUTmode: MODE

Errors: Output, Mode, Match

'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.

This request generates OutputChangeNotify events.

RRDeleteOutputMode

output: OUTPUTmode: MODE

Errors: Output, Mode

'output' indicates which output is to be configured.

'mode' specifies which mode to delete. 'mode' must have been addedwith RRAddOutputMode, else an Access error is returned. 'mode' mustnot be active, else a Match error is returned.

This request generates OutputChangeNotify events.

RRGetCrtcInfo

crtc: CRTCconfig-timestamp: TIMESTAMP

status: RRCONFIGSTATUStimestamp: TIMESTAMP


16/51

x, y: INT16width, height: CARD16mode: MODErotation: ROTATIONoutputs: LISTofOUTPUT

rotations: SETofROTATIONpossible-outputs: LISTofOUTPUT

Errors: Window

RRGetCrtcModes returns information about the current and availableconfigurations for the specified crtc connected to the screenassociated with 'window'.

If 'config-timestamp' does not match the current configurationtimestamp (as returned by RRGetScreenResources), 'status' is set toInvalidConfigTime and the remaining reply data is empty. Otherwise,'status' is set to Success.


'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 screenpresented by this CRTC. This may be different than the size of themode due to rotation, the projective transform, and the Border propertydescribed below. They will be set to 0 when the CRTC is disabled.

'mode' indicates which mode is active, or None indicating that theCRTC has been disabled and is not displaying the screen contents.

'rotation' indicates the active rotation. It is set to Rotate_0when the CRTC is disabled.

'outputs' is the list of outputs currently connected to this CRTCand is empty when the CRTC is disabled.

'rotations' contains the set of rotations and reflections supportedby the CRTC.

'possible-outputs' lists all of the outputs which may be connectedto this CRTC.

RRSetCrtcConfig

crtc: CRTCtimestamp: TIMESTAMP

config-timestamp: TIMESTAMPx, y: INT16mode: MODErotation: ROTATIONoutputs: LISTofOUTPUT

status: RRCONFIGSTATUSnew-timestamp: TIMESTAMP

Errors: Value, Match


17/51

If 'timestamp' is less than the time when the configuration was lastsuccessfully set, the request is ignored and InvalidTime returned instatus.

If 'config-timestamp' is not equal to when the monitor'sconfiguration last changed, the request is ignored andInvalidConfigTime returned in status. This could occur if themonitor changed since you last made a RRGetScreenInfo request,perhaps by a different monitor being connected to the machine.Rather than allowing an incorrect call to be executed based on staledata, the server will ignore the request.

'x' and 'y' contain the desired location within the screen for thismonitor's content. 'x' and 'y' must be within the screen size, elsea Value error results.

'mode' is either the desired mode or None indicating the CRTC shouldbe disabled. If 'mode' is not one of these values, a Valueerror results. 'mode' must be valid for all of the configured outputs,else a Match error.

'rotation' contains the desired rotation along with whichreflections should be enabled. The rotation and reflection values

must be among those allowed for this monitor, else a Value errorresults.

'outputs' contains the set of outputs that this CRTC should beconnected to. The set must be among the list of acceptable outputsets for this CRTC or a Match error results.

If 'mode' is None, then 'outputs' must be empty, else a Match errorresults. Conversely, if 'mode' is not None, then 'outputs' must not beempty, 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, rotationand reflection. The entire area of the CRTC must fit within thescreen size, else a Match error results. As an example, rotating thescreen so that a single CRTC fills the entire screen before andafter may necessitate disabling the CRTC, resizing the screen,then re-enabling the CRTC at the new configuration to avoid aninvalid intermediate configuration.

If panning is enabled, the width and height of the panning and thetracking 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 therequested changes to configuration will have been made.



18/51

RRGetCrtcGammaSizecrtc: CRTC

size: CARD16

Errors: Crtc

This request returns the size of the gamma ramps used by 'crtc'.

RRGetCrtcGamma

crtc: CRTC

red: LISTofCARD16green: LISTofCARD16blue: LISTofCARD16

Errors: Crtc

This request returns the currently set gamma ramps for 'crtc'. Allthree lists will be the size returned by the RRGetCrtcGammaSizerequest.

RRSetCrtcGammacrtc: CRTCred: LISTofCARD16green: LISTofCARD16blue: LISTofCARD16

Errors: Crtc, Match

This request sets the gamma ramps for 'crtc'. All three listsmust be the size returned by RRGetCrtcGammaSize else a Value errorresults.

7.2. Extension Requests added in version 1.3 of the extension

RRGetScreenResourcesCurrent

window: WINDOW

timestamp: TIMESTAMPconfig-timestamp: TIMESTAMPcrtcs: LISTofCRTCoutputs: LISTofOUTPUTmodes: LISTofMODEINFO

Errors: Window

RRGetScreenResourcesCurrent returns the list of outputs and crtcsconnected to the screen associated with 'window'.


'config-timestamp' indicates when the configuration information lastchanged. Requests to configure the output will fail unless thetimestamp indicates that the information the client is using is upto date, to ensure clients can be well behaved in the face of raceconditions.


19/51

'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 currentconfiguration, and does not poll for hardware changes.

RRSetCrtcTransform

crtc: CRTCtransform: TRANSFORMfilter: STRING8values: LISTofFIXED

Errors: Crtc, Match

This request provides a mechanism that is more general than theexisting rotation and reflection values for describing thetransformation from frame buffer image to crtc presentation.'transform' is a full 2D projective transformation from screencoordinate space to crtc coordinate space. This transformation is

applied before the rotation and reflection values to compute thecomplete transform.

'filter' and 'values' specify a Render filter that may be used by theserver when transforming data from frame buffer to crtc.

This request sets the transform to be used at the nextRRSetCrtcConfig request execution; it does not cause any change tooccur in the current configuration.

When a non-identity transformation is in use, the rectangle returnedby RRGetCrtcInfo defines the bounding rectangle of the screen that isprojected 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: TRANSFORMpending-filter: STRING8pending-values: LISTofFIXEDcurrent-transform: TRANSFORMcurrent-filter: STRING8current-values: LISTofFIXED

This request returns the pending and current transforms for thespecified CRTC. The pending transform will be the same as the currenttransform if no new pending transform has been set since the last callto RRSetCrtcConfig.

RRGetPanning

crtc: CRTC


20/51

status: RRCONFIGSTATUStimestamp: TIMESTAMPleft, top, width, height: CARD16track_left, track_top, track_width, track_height: CARD16border_left, border_top, border_right, border_bottom: INT16

Errors: Crtc

Version 1.3 adds panning support again. If multiple crtcs are activethe panning behavior can be defined per crtc individually.RRGetPanning returns information about the currently set panningconfiguration for the specified crtc. If the CRTC does not supportpanning, all fields (except timestamp) will be 0.


All other entries are explained for RRSetPanning.

RRSetPanning

crtc: CRTCtimestamp: TIMESTAMPleft, top, width, height: CARD16

track_left, track_top, track_width, track_height: CARD16border_left, border_top, border_right, border_bottom: INT16

status: RRCONFIGSTATUSnew-timestamp: TIMESTAMP

Errors: Crtc, Match

This request sets the panning parameters. As soon as panning isenabled, 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 instatus.

CRTC X framebuffer panning area

'left', 'top', 'width', and 'height' contain the total panning areafor this CRTC. 'width' has to be larger than or equal to the CRTC'swidth or 0, and 'left'+'width' must be within the screen size, else aMatch error results. Equivalent restrictions for the height exist.'width' or 'height' set to 0 indicate that panning should be disabledon the according axis. Setting 'width'/'height' to the CRTC'swidth/height will disable panning on the X/Y axis as well, butRRSetScreenSize will silently enable panning if the screen size isincreased. This does not happen if set to 0.


21/51

CRTC tracking area X panning area

'track_left', 'track_top', 'track_width', and 'track_height' containthe pointer area for which the panning region is updated. For normaluse cases it should enclose the panning area minus borders, and istypically set to either the panning area minus borders, or to thetotal screen size. If set to the total screen size, the CRTC will panin the remaining axis even if the pointer is outside the panning areaon a different CRTC, as shown in the figure above. If the pointer isoutside the tracking area, the CRTC will not pan. Zero can be used asan 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 panningif the pointer hits them. If the borders are 0, the screen will panwhen the pointer hits the CRTC borders (behavior of pre-RandR Xserverpanning). If the borders are positive, the screen will pan when thepointer gets close to the CRTC borders, if they are negative, the

screen will only pan when the pointer is already way past the CRTCborders. Negative values might confuse users and disable panning tothe very edges of the screen. Thus they are discouraged.border_left + border_right has to be lower or equal than the CRTC'swidth, else a Match error results. An equivalent restriction for theheight exists.

Screen size changes update the panning and the tracking areas to thenew size. Both screen size changes and mode changes clamp these areasto the current CRTC size. In these cases panning borders are disabledif their requirements are no longer met.

When this request succeeds, 'status' contains Success and the

requested changes to configuration will have been made.


RRSetOutputPrimary

window: WINDOWoutput: OUTPUT


22/51

Errors: Match, Output, Window

RRSetOutputPrimary marks 'output' as the primary output for thescreen with the same root window as 'window'. This output's CRTCwill be sorted to the front of the list in Xinerama and RANDRgeometry requests for the benefit of older applications. Thedefault primary output is None, and None is a legal value to passto RRSetOutputPrimary. This request is expected to be used bydesktop environments to mark the screen that should hold the primarymenu bar or panel.

As this changes the logical layout of the screen, ConfigureNotifyand RRScreenChangeNotify will be generated on the appropriate rootwindow when the primary output is changed by this call. This requestalso generates RROutputChangeNotify events on the outputs that gainedand lost primary status.

If an output is disconnected asynchronously (eg. due to recabling),the primary status does not change, but RROutputChangeNotify eventswill 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 willact 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 screen.

7.4 Extension Requests added in version 1.4 of the extension.

RRGetProviders

window : WINDOW

timestamp: TIMESTAMPproviders: LISTofPROVIDER

Errors: Window

RRGetPRoviders returns the list of providers connected to the screen

associated with 'window'.


'providers' contains the list of PROVIDERs associated with thescreen.

RRGetProviderInfo

provider: PROVIDER


23/51

capabilities: PROVIDER_CAPSname: STRINGcrtcs: LISTofCRTCoutputs: LISTofOUTPUTassociated_providers: LISTofPROVIDERSassociated_provider_capability: LISTofPROVIDER_CAPS

Errors: Provider

RRGetProviderInfo return information about the specified provider.The capabilites of the current provider are returned, along withthe list of providers currently associated with this provider andthe capability they are associated with. It also provides the listof crtcs and outputs that this provider is responsible for.

'name' is a UTF-8 encoded string to be presented to the user toindicate the device or driver supplied name.

RRSetProviderOffloadSink

provider: PROVIDERsink_provider: PROVIDER

Errors: Provider

RRSetOffloadSink sets the offload sink for this provider to thespecified provider.

RRSetProviderOutputSource

provider: PROVIDERsource_provider: PROVIDER

Errors: Provider

RRSetOutputSource sets the output source for this provider to thespecified provider.

RRListProviderProperties

provider:PROVIDERS

atoms: LISTofATOM

Errors: Provider

This request returns the atoms of properties currently defined on

the provider.

RRQueryProviderProperty

provider: PROVIDERproperty: ATOM

pending: BOOLrange: BOOLimmutable: BOOL


24/51

valid-values: LISTofINT32

Errors: Name, Atom, Provider

If the specified property does not exist for the specified provider,then a Name error is returned.

If 'pending' is TRUE, changes made to property values withRRChangeProviderProperty will be saved in the pending property valueand be automatically copied to the current value on the nextRRSetCrtcConfig request on a crtc attached to that provider.If 'pending' is FALSE, changes are copied immediately.

If 'range' is TRUE, then the valid-values list will containprecisely two values indicating the minimum and maximum allowedvalues. If 'range' is FALSE, then the valid-values list will containthe list of possible values; attempts to set other values willresult in a Value error.

If 'immutable' is TRUE, then the property configuration cannot bechanged by clients. Immutable properties are interpreted by the Xserver.

RRConfigureProviderPropertyprovider: PROVIDERproperty: ATOMpending: BOOLrange: BOOLvalid-values: LISTofINT32

Errors: Access, Name, Atom, Provider

If the specified property is 'immutable', an Access error isreturned.

Otherwise, the configuration of the specified property is changed to

the values provided in this request.If the specified property does not exist for the specified provider,it is created with an empty value and None type.

RRChangeProviderProperty

provider: PROVIDERproperty, type: ATOMformat: {8, 16, 32}mode: { Replace, Prepend, Append }data: LISTofINT8 or LISTofINT16 or LISTofINT32

Errors: Alloc, Atom, Match, Value, Provider

This request alters the value of the property for the specifiedprovider. If the property is marked as a 'pending' property, only thepending value of the property is changed. Otherwise, changes arereflected in both the pending and current values of the property.The type is uninterpreted by the server. The format specifieswhether the data should be viewed as a list of 8-bit, 16-bit, or32-bit quantities so that the server can correctly byte-swap asnecessary.


25/51

If the mode is Replace, the previous property value is discarded.If the mode is Prepend or Append, then the type and format mustmatch the existing property value (or a Match error results). Ifthe property is undefined, it is treated as defined with the correcttype and format with zero-length data.

For Prepend, the data is tacked on to the beginning of the existingdata, and for Append, it is tacked on to the end of the existing data.

This request generates a ProviderPropertyNotify

The lifetime of a property is not tied to the storing client.Properties remain until explicitly deleted, until the provider isdestroyed, or until server reset (see section 10).

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

RRDeleteProviderProperty

provider: Providerproperty: ATOM

Errors: Atom, Provider

This request deletes the property from the specified provider if theproperty exists and generates a ProviderPropertyNotify event unlessthe property does not exist.

RRGetProviderProperty

provider: PROVIDERproperty: ATOMtype: ATOM or AnyPropertyTypelong-offset, long-length: CARD32delete: BOOLpending: BOOL

type: ATOM or Noneformat: {0, 8, 16, 32}bytes-after: CARD32value: LISTofINT8 or LISTofINT16 or LISTofINT32

Errors: Atom, Value, Provider

If the specified property does not exist for the specified provider,then the return type is None, the format and bytes-after are zero,and the value is empty. The delete argument is ignored in thiscase.

If the specified property exists but its type does not match thespecified type, then the return type is the actual type of theproperty, the format is the actual format of the property (neverzero), the bytes-after is the length of the property in bytes (evenif the format is 16 or 32), and the value is empty. The deleteargument is ignored in this case.

If the specified property exists and either AnyPropertyType isspecified or the specified type matches the actual type of theproperty, then the return type is the actual type of the property,


26/51

the format is the actual format of the property (never zero), andthe bytes-after and value are as follows, given:

N = actual length of the stored property in bytes (even if the format is 16 or 32)

I = 4 offsetT = N - IL = 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 propertyrather than the current value. The returned value starts at byteindex I in the property (indexing from 0), and its length in bytesis L. However, it is a Value error if long-offset is given suchthat L is negative. The value of bytes-after is A, giving thenumber of trailing unread bytes in the stored property. If deleteis True and the bytes-after is zero, the property is also deletedfrom the provider, and a RRProviderPropertyNotify event is generated.

8. Extension Events

Clients MAY select for ConfigureNotify on the root window to beinformed of screen changes. This may be advantageous if all yourclient needs to know is the size of the root window, as it avoidsround trips to set up the extension.

RRScreenChangeNotify is sent if RRSelectInput has requested itwhenever properties of the screen change, which may be due to externalfactors, such as re-cabling a monitor, etc.

RRScreenChangeNotify

rotation: ROTATION; new rotation

sequenceNumber: CARD16 low 16 bits of request seq. numbertimestamp: TIMESTAMP time screen was changedconfigTimestamp: TIMESTAMP time config data was changedroot: WINDOW root window of screenwindow: WINDOW window requesting notificationsize-id: SIZEID index of new SCREENSIZEsubpixelOrder: SUBPIXELORDER order of subpixelswidthInPixels: CARD16 width in pixels of the new SCREENSIZEheightInPixels: CARD16 height in pixels of the new SCREENSIZEwidthInMillimeters: CARD16 width in mm of the new SCREENSIZEheightInMillimeters: 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 thescreen configuration was changed. 'configTimestamp' says when thelast time the configuration was changed. 'root' is the root of thescreen the change occurred on, 'window' is window selecting for thisevent. 'size-id' contains the index of the current size.

This event is sent whenever the screen's configuration changesor if a new screen configuration becomes available that wasnot available in the past. In this case (config-timestamp inthe event not being equal to the config-timestamp returned in


27/51

the last call to RRGetScreenInfo), the client MUST callRRGetScreenInfo to update its view of possible screenconfigurations to have a correct view of possible screenorganizations.

Clients which select screen change notification events may besent an event immediately if the screen configuration waschanged between when they connected to the X server andselected for notification. This is to prevent a common racethat might occur on log-in, where many applications start upjust at the time when a display manager or log in script mightbe changing the screen size or configuration.

Note that the sizes in this event reflect the new SCREENSIZE andthus will appear rotated by the 'rotation' parameter from the sizesof the screen itself. In other words, when rotation is 90 or 270,widthInPixels in this event will be the same as the height valuefrom a ConfigureNotify that reflects the same size change. Thiswill probably confuse developers.

8.1 Events added in version 1.2 of the RandR extension

RROutputChangeNotify:

timestamp: TIMESTAMP time screen was reconfiguredconfig-timestamp: TIMESTAMP time available config data was changedwindow: WINDOW window requesting notificationoutput: OUTPUT output affected by changecrtc: CRTC connected CRTC or Nonemode: MODE mode in use on CRTC or Noneconnection: CONNECTION connection status

This event is generated whenever the available output configurationshave changed and is sent to requesting clients. 'timestamp'indicates when the crtc configuration was changed by a client.'config-timestamp' says when the last time the available

configurations changed. 'root' is the root of the screen the changeoccurred on, 'window' is window selecting for this event. Theprecise change can be detected by examining the new state of thesystem.

RROutputPropertyNotify:

window: WINDOW window requesting notificationoutput: OUTPUT output affected by changeatom: ATOM affected propertytime: TIMESTAMP time property was changedsubpixel-order: SUBPIXELORDER order of subpixelsstate: { NewValue, Deleted } new property state

This event is reported to clients selecting RROutputPropertyChangeon the window and is generated with state NewValue when a propertyof the window is changed using RRChangeOutputProperty even whenadding zero-length data and when replacing all or part of a propertywith identical data. It is generated with state Deleted when aproperty of the window is deleted using eitherRRDeleteOutputProperty or RRGetOutputProperty. The timestampindicates the server time when the property was changed.


28/51

RRCrtcChangeNotify

timestamp: TIMESTAMP time monitor was changedwindow: WINDOW window requesting notificationcrtc: CRTC CRTC which changedmode: MODE new moderotation: ROTATION; new rotationx: INT16 x position of CRTC within screeny: INT16 y position of CRTC within screenwidth: CARD16 width of new configurationheight: CARD16 height of new configuration

This event is generated whenever the CRTC configuration is changedand sent to requesting clients. 'timestamp' indicates when theCRTC configuration was changed. 'window' is window selecting for thisevent. 'mode' is the new mode, or None if the crtc is disabled.'x' and 'y' mark the location in the screen where this CRTCis reading data. 'width' and 'height' indicate the size of theCRTC viewport, which is the mode size adjusted by the optionalBorder output property described below. '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 wasnot available in the past. In this case, the client MUST callRRGetCrtcModes to update its view of possible monitorconfigurations to have a correct view of possible monitororganizations.

Clients which select monitor change notification events may besent an event immediately if the monitor configuration waschanged between when they connected to the X server andselected for notification. This is to prevent a common racethat might occur on log-in, where many applications start upjust at the time when a display manager or log in script mightbe changing the monitor size or configuration.

8.2 Events added in version 1.4 of the RandR extension

RRProviderChangeNotify:

timestamp: TIMESTAMP time screen was reconfiguredconfig-timestamp: TIMESTAMP time available config data was changedwindow: WINDOW window requesting notificationprovider: PROVIDER provider affected by changerole: CRTC new role for provider

This event is generated whenever the role for a provider has changed

and is sent to requesting clients. 'timestamp' indicates when theprovider configuration was changed by a client.'config-timestamp' says when the last time the availableconfigurations changed. 'root' is the root of the screen the changeoccurred on, 'window' is window selecting for this event. Theprecise change can be detected by examining the new state of thesystem.

RRProviderPropertyNotify:


29/51

window: WINDOW window requesting notificationprovider: PROVIDER providre affected by changeatom: ATOM affected propertytime: TIMESTAMP time property was changedstate: { NewValue, Deleted } new property state

This event is reported to clients selecting RRProviderPropertyChangeon the window and is generated with state NewValue when a propertyof the window is changed using RRChangeProviderProperty even whenadding zero-length data and when replacing all or part of a propertywith identical data. It is generated with state Deleted when aproperty of the window is deleted using eitherRRDeleteProviderProperty or RRGetProviderProperty. The timestampindicates the server time when the property was changed.

RRResourceChangeNotify:

window: WINDOW window requesting notificationtime: TIMESTAMP time property was changed

This event is reported to clients selecting RRResourceChangeon the window and is generated whenever the set of available

RandR resources associated with the screen has changed, eithercreated or destroyed. Querying the list of available resourceswith RRGetScreenResources and RRGetProviders will return the new set.

9. Properties

Properties are used for output specific parameters, and for announcingstatic or rarely changing data. Announced data is typicallyimmutable. Properties are also used for evaluating new parametersbefore adding them to the RandR protocol.

The following properties are hereby declared official, and drivers SHOULDprefix driver specific properties with '_', unless they are planned to beadded to this specification. List values, that are not declared by the tablebelow, and will remain driver specific or are not planned to be added to thisspecification, SHOULD be prefixed with "_" as well in order to avoid namespace or semantics clashes with future extensions of these values.

Beginning with version 1.3 of the RandR extension, certain propertiesare mandatory and MUST be provided by implementations. Earlierversions of the RandR extension MAY provide these properties as well,as long as the semantics are not altered. Clients SHOULD fall backgracefully to lower version functionality, though, if the driverdoesn't handle a mandatory property correctly.

9.1 Known properties

"Backlight" aka RR_PROPERTY_BACKLIGHTType: INTEGERFormat: 32Num. items: 1Flags: -Range/List: 0-x (driver specific)


30/51

This property controls the brightness on laptop panels and equivalentdisplays with a backlight controller. The driver specific maximumvalue MUST turn the backlight to full brightness, 1 SHOULD turn thebacklight to minimum brightness, 0 SHOULD turn the backlight off.

"CloneList" aka RR_PROPERTY_CLONE_LISTType: ATOMFormat: 32Num. items: 2*nFlags: ImmutableRange/List: 0-

Some combinations of outputs on some cards cannot be servedindependently from each other, because they are wired up to the sameencoder outputs.This property lists all output + signal format pairs that aredriven together with this output, and thus can only be programmed inclone mode with the same CRTC.This property MUST be symmetric, but may change with changing signalformat. I.e. if the property for DVI-1/VGA specifies VGA-1/VGA to becloned, VGA-1/VGA has to list DVI-1/VGA as well.Outputs / format pairs listed in this property MUST be included in theCompatibilityList.

"CompatibilityList" aka RR_PROPERTY_COMPATIBILITY_LISTType: ATOMFormat: 32Num items: 2*nFlags: ImmutableRange/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 ata time.This property lists all output + signal format pairs that can bedriven together with this output. NULL atoms specify any output / anysignal format, respectively.

This property MUST be symmetric, but may change with changing signalformat. I.e. if the property for DVI-1/TMDS specifies VGA-1/VGA to beavailable, VGA-1/VGA has to list DVI-1/TMDS as well.

"ConnectorNumber" aka RR_PROPERTY_CONNECTOR_NUMBERType: INTEGERFormat: 32Num items: 1Flags: Immutable, StaticRange/List: 0-

Outputs that route their signal to the same connector MUSThave the same connector number. Outputs with the same

connector number MUST route their signal to the sameconnector, except if it is 0, which indicates unknownconnectivity. 1 is called the primary connector, 2 thesecondary. 3 is typically a TV connector, but that is completelydriver / hardware dependent.Outputs with the same connector number SHOULD have the sameconnector type. Meaning and client behavior for mismatchingconnector types is undefined at the moment.

"ConnectorType" aka RR_PROPERTY_CONNECTOR_TYPE


31/51

Type: ATOMFormat: 32Num items: 1Flags: Immutable, StaticRange/List: unknown VGA DVI DVII DVIA DVID HDMI Panel

TV TV-Composite TV-SVideo TV-ComponentTV-SCART TV-C4 DisplayPort

Connector type, as far as known to the driver.Values with dashes (TVComposite) describe more specific versions ofthe base values (TV). The former SHOULD be used if the connector isnot capable of producing other signal formats. The later SHOULD beused if the exact connector is unknown, or the connector is amultiformat connector that is not described otherwise. DVI, forinstance, SHOULD be handled like a DVII connector, unless additionalinformation is available to the user agent. PANEL describeslaptopinternal (normally LVDS) displays. TV, TVSCART, TVComponent,and TVC4 with signal format VGA are valid combinations and describeRGB TV signals.

"EDID" aka RR_PROPERTY_RANDR_EDIDType: INTEGERFormat: 8Num items: n

Flags: ImmutableRange/List: -

Raw EDID data from the device attached to the accordingoutput. Should include main EDID data and all extensionblocks. Previously known as EdidData.

"SignalFormat" aka RR_PROPERTY_SIGNAL_FORMATType: ATOMFormat: 32Num items: 1Flags: -Range/List: unknown VGA TMDS LVDS Composite Composite-PAL

Composite-NTSC Composite-SECAM SVideoComponent DisplayPort

Signal format / physical protocol format that is used for thespecified output. valid-values lists all possible formats on thisoutput, which SHOULD be a subset of the list above and MUST be static.Values with dashes (Composite-PAL) describe more specific versions ofthe base values (Composite) and SHOULD be used if known to the driver.A driver MAY change this property of an output if the underlyinghardware indicates a protocol change (e.g. TV formats). Clients areallowed to change the signal format in order to select a differentsignal format (e.g. Composite etc.) or physical protocol (e.g. VGA orTMDS on DVI-I).

Laptop panels SHOULD not be detected with this property, but rather byConnectorType.

"SignalProperties" aka RR_PROPERTY_SIGNAL_FORMATType: ATOMFormat: 32Num items: nFlags: -Range/List: For Composite signals:

NTSC NTSC-M NTSC-J NTSC-N NTSC-4.43 NTSC-film


32/51

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-KFor TMDS signals: SingleLink DualLinkFor DisplayPort signals: Lane1 Lane2 Lane4 LowSpeed HiSpeed

Properties of the signal format that is currently used for thespecified output. valid-values lists all possible properties on thisoutput, which SHOULD be a subset of the list above. It will change ifSignalFormat changes. Multiple properties are allowed.Values with dashes (PAL-B) describe more specific versions of the basevalues (PAL) and SHOULD be used if known to the driver. A driver MAYchange this property of an output if the underlying hardware indicatesa signal change (e.g. TV formats). Clients are allowed to change theproperties in order to select a different signal subformat.

"Border" aka RR_PROPERTY_BORDERType: CARDINALFormat: 16Num items: 0, 1, 2, or 4Flags: Immutable

Range/List: 0-This property is a list of integers specifying adjustments for the edgesof the displayed image. How this property is applied depends on thenumber of elements in the list:

0 = No border is applied 1 = A border of Border[0] is applied to all four sides of the image. 2 = A border of Border[0] is applied to the left and right sides of the image, and a border of Border[1] is applied to the top and bottom. 4 = The border dimensions are as follows:

Border[0]: left

Border[1]: topBorder[2]: rightBorder[3]: bottom

Note that how many configuration dimensions are actually supported isspecified by the BorderDimensions property described below. If more thanBorderDimensions values are specified, the extra values are ignored.

These border dimensions shrink the region of pixels displayed by theCRTC by the corresponding number of rows or columns, and is appliedafter the CRTC transform. For example, a mode with a 1920x1080 activeregion, border dimensions of [ 10, 20, 30, 40 ], and a x scalingtransform would display a rectangle of 940x510 pixels from the scanout

pixmap scaled to 1880x1020 raster pixels positioned at (10, 20) indisplay raster space.

Raster pixels in the border are black.

This property is created with pending == TRUE, so changes are notapplied immediately and instead take effect at the next RRSetCrtcConfig.

If multiple outputs with different border settings are bound to the sameCRTC when the configuration is changed, the behavior is undefined.


33/51

If the length of the property is less than four when the CRTC isconfigured, the missing values are assumed to be zero. If the length isgreater than four, the extra values are ignored.

If the width of the mode is less than or equal to the sum of the leftand right borders, then the left and right border settings are ignored.Likewise, if the height of the mode is less than or equal to the sum ofthe top and bottom borders, the top and bottom borders are ignored.

"BorderDimensions" aka RR_PROPERTY_BORDER_DIMENSIONSType: CARDINALFormat: 8Num items: 1Flags: Immutable, StaticRange/List: 0, 1, 2, or 4

This property lists how many border adjustment parameters can actuallybe used:

0 = no borders are supported 1 = a single border value is applied to all four sides of the image 2 = left/right and top/bottom borders can be specified independently 4 = all four borders can be specified independently

9.2 Properties introduced with version 1.2 of the RandR extension

Property Immutable Mandatory since EDID yes n/a

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 mandatoryCompatibilityList yes not mandatoryConnectorNumber yes: static not mandatoryConnectorType yes: static RandR 1.3SignalFormat no RandR 1.3SignalProperties no not mandatory

9.4 Properties introduced with version 1.3.1 of the RandR extension

Property Immutable Mandatory since

Backlight no not mandatory

9.5 Properties introduced with version 1.4.0 of the RandR extension

Property Immutable Mandatory since Border yes not mandatoryBorderDimensions yes: static not mandatory


34/51

10. Extension Versioning

The RandR extension was developed in parallel with the implementationto ensure the feasibility of various portions of the design. Asportions of the extension are implemented, the version number of theextension has changed to reflect the portions of the standard provided.This document describes the version 1.4 of the specification, thepartial implementations have version numbers less than that. Here's alist of what each version provided:

0.0: This prototype implemented resize and rotation in the TinyX server Used approximately the protocol described in the Usenix paper. Appeared in the TinyX server in XFree86 4.2, but not in the XFree86 main server.

0.1: Added subpixel order, added an event for subpixel order. This version was never checked in to XFree86 CVS.

1.0: Implements resize, rotation, and reflection. Implemented both in the XFree86 main server (size change only at this date), and fully (size change, rotation, and reflection) in XFree86's TinyX server.

1.1: Added refresh rates1.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.

1.4: Added provider objects for handling multi-GPU systems.

Compatibility between 0.0 and 1.0 was *NOT* preserved, and 0.0 clientswill fail against 1.0 servers. The wire encoding op-codes were

changed for GetScreenInfo to ensure this failure in a relativelygraceful way. Version 1.1 servers and clients are cross compatible with1.0. Version 1.1 is considered to be stable and we intend upwardcompatibility from this point. Version 1.2 offers an extended model of thesystem with multiple output support. Version 1.3 adds a cheap version ofGetScreenResources to avoid expensive DDC operations, CRTC transformations,panning, and the primary output concept. Versions 1.2 through 1.4 arebackward-compatible with 1.1.

11. Relationship with other extensions

Two other extensions have a direct relationship with this extension. Thissection attempts to explain how these three are supposed to work together.

11.1 XFree86-VidModeExtension

XFree86-VidModeExtension changes the configuration of a single monitorattached to the screen without changing the configuration of the screenitself. It provides the ability to specify new mode lines for the server touse along with selecting among existing mode lines. As it uses screennumbers instead of window identifiers, it can be used to affect multiple


35/51

monitors in a single-screen Xinerama configuration. However, the associationbetween screen numbers and root windows in a multi-Screen environment is notdefined by the extension. Version 2.0 of this extension added the ability toadjust the DAC values in a TrueColor server to modify the brightness curvesof the display.

All of the utility of this extension is subsumed by RandR version 1.2, RandRshould be used in preference to XFree86-VidModeExtension where both arepresent.

11.2 Xinerama

Xinerama provides a mechanism for describing the relationship between theoverall screen display and monitors placed within that area. As such, itprovides the query functionality of RandR 1.2 without any of theconfiguration functionality. Applications using Xinerama to discovermonitor geometry can continue to do so, with the caveat that they will not beinformed of changes when they occur. However, Xinerama configuration datawill be updated, so applications selecting for RandR notification andre-querying the configuration with the Xinerama extension will get updatedinformation. It is probably better to view RandR as a superset of Xineramaat this point and use it in preference to Xinerama where both are present.

Appendix A. Protocol Encoding

Syntactic Conventions

This document uses the same syntactic conventions as the core Xprotocol encoding document.

A.1 Common Types

ROTATION

0x0001 Rotate_0

0x0002 Rotate_900x0004 Rotate_1800x0008 Rotate_2700x0010 Reflect_X0x0020 Reflect_Y

Used to encode both sets of possible rotations and individualselected rotations.

RRSELECTMASK

0x0001 ScreenChangeNotifyMask0x0002 CrtcChangeNotifyMask Added in version 1.2

0x0004 OutputChangeNotifyMask Added in version 1.20x0008 OutputPropertyNotifyMask Added in version 1.20x0010 ProviderChangeNotifyMask Added in version 1.40x0020 ProviderPropertyNotifyMask Added in version 1.40x0040 ResourceChangeNotifyMask Added in version 1.4

Event select mask for RRSelectInput


36/51

RRCONFIGSTATUS0x0 Success0x1 InvalidConfigTime0x2 InvalidTime0x3 Failed

Return status for requests which depend on time.

MODEINFO (32) Added in version 1.2

4 CARD32 id2 CARD16 width in pixels2 CARD16 height in pixels4 CARD32 dot clock2 CARD16 h sync start2 CARD16 h sync end2 CARD16 h total2 CARD16 h skew2 CARD16 v sync start2 CARD16 v sync end2 CARD16 v total2 CARD16 name length4 SETofMODEFLAG mode flags

An output mode specifies the complete CRTC timings fora specific mode. The vertical and horizontal synchronization ratescan be computed given the dot clock and the h total/v totalvalues. If the dot clock is zero, then all of the timingparameters and flags are not used, and must be zero as thisindicates that the timings are unknown or otherwise unused.The name itself will be encoded separately in each usage.

MODEFLAG

0x00000001 HSyncPositive0x00000002 HSyncNegative

0x00000004 VSyncPositive0x00000008 VSyncNegative0x00000010 Interlace0x00000020 DoubleScan0x00000040 CSync0x00000080 CSyncPositive0x00000100 CSyncNegative0x00000200 HSkewPresent0x00000400 BCast0x00000800 PixelMultiplex0x00001000 DoubleClock0x00002000 ClockDivideBy2

CONNECTION0 Connected1 Disconnected2 UnknownConnection

A.2 Protocol Requests


37/51

Opcodes 1 and 3 were used in the 0.0 protocols, and will returnerrors if used in version 1.0.

RRQueryVersion

1 CARD8 major opcode1 0 RandR opcode2 3 length4 CARD32 major version4 CARD32 minor version

1 1 Reply1 unused2 CARD16 sequence number4 0 reply length1 CARD32 major version1 CARD32 minor version

RRSetScreenConfig

1 CARD8 major opcode1 2 RandR opcode

2 6 length4 WINDOW window on screen to be configured4 TIMESTAMP timestamp4 TIMESTAMP config timestamp2 SIZEID size index2 ROTATION rotation/reflection2 CARD16 refresh rate (1.1 only)2 CARD16 pad

1 1 Reply1 RRCONFIGSTATUS status2 CARD16 sequence number4 0 reply length

4 TIMESTAMP new timestamp4 TIMESTAMP new configuration timestamp4 WINDOW root2 SUBPIXELORDER subpixel order defined in Render2 CARD16 pad44 CARD32 pad54 CARD32 pad6

RRSelectInput


2 3 length4 WINDOW window2 SETofRRSELECTMASK enable2 CARD16 pad

RRGetScreenInfo



38/51

2 2 length4 WINDOW window

1 1 Reply1 CARD8 set of Rotations2 CARD16 sequence number4 0 reply length4 WINDOW root window4 TIMESTAMP timestamp4 TIMESTAMP config timestamp2 CARD16 number of SCREENSIZE following2 SIZEID current size index2 ROTATION current rotation and reflection2 CARD16 current rate (added in version 1.1)2 CARD16 length of rate info (number of CARD16s)2 CARD16 pad

SCREENSIZE2 CARD16 width in pixels2 CARD16 height in pixels2 CARD16 width in millimeters2 CARD16 height in millimeters

REFRESH

2 CARD16 number of rates (n)2n CARD16 rates

A.2.1 Protocol Requests added with version 1.2

RRGetScreenSizeRange

1 CARD8 major opcode1 6 RandR opcode2 2 length4 WINDOW window

1 1 Reply1 unused2 CARD16 sequence number4 0 reply length2 CARD16 minWidth2 CARD16 minHeight2 CARD16 maxWidth2 CARD16 maxHeight16 unused

RRSetScreenSize

1 CARD8 major opcode

1 7 RandR opcode2 5 length4 WINDOW window2 CARD16 width2 CARD16 height4 CARD32 width in millimeters4 CARD32 height in millimeters

RRGetScreenResources


39/51


1 1 Reply1 unused2 CARD16 sequence number4 c+o+8m+(b+p)/4 reply length4 TIMESTAMP timestamp4 TIMESTAMP config-timestamp2 c number of CRTCs2 o number of outputs2 m number of modeinfos2 b total bytes in mode names8 unused4c LISTofCRTC crtcs4o LISTofOUTPUT outputs32m LISTofMODEINFO modeinfosb STRING8 mode namesp unused, p=pad(b)

RRGetOutputInfo

1 CARD8 major opcode1 9 RandR opcode2 3 length4 OUTPUT output4 TIMESTAMP config-timestamp

1 1 Reply1 RRCONFIGSTATUS status2 CARD16 sequence number4 1+c+m+(n+p)/4 reply length4 TIMESTAMP timestamp4 CRTC current connected crtc4 CARD32 width in millimeters

4 CARD32 height in millimeters1 CONNECTION connection1 SUBPIXELORDER subpixel-order2 c number of CRTCs2 m number of modes2 p number of preferred modes2 o number of clones2 n length of name4c LISTofCRTC crtcs4m LISTofMODE modes4o LISTofOUTPUT clonesn STRING8 namep unused, p=pad(n)

RRListOutputProperties

1 CARD8 major opcode1 10 RandR opcode2 2 length4 OUTPUT output

1 1 Reply1 unused


40/51

2 CARD16 sequence number4 n reply length2 n number of ATOMs in atoms22 unused4n LISTofATOM atoms

RRQueryOutputProperty

1 CARD8 major opcode1 11 RandR opcode2 3 request length4 OUTPUT output4 ATOM property

1 1 Reply1 unused2 CARD16 sequence number4 n reply length1 BOOL pending1 BOOL range1 BOOL immutable21 unused4n LISTofINT32 valid values

RRConfigureOutputProperty1 CARD8 major opcode1 12 RandR opcode2 4+n request length4 OUTPUT output4 ATOM property1 BOOL pending1 BOOL range2 unused4n LISTofINT32 valid values

RRChangeOutputProperty1 CARD8 major opcode1 13 RandR opcode2 6+(n+p)/4 request length4 OUTPUT output4 ATOM property4 ATOM type1 CARD8 format1 mode

0 Replace1 Prepend2 Append

2 unused

4 CARD32 length of data in format units(= n for format = 8)(= n/2 for format = 16)(= n/4 for format = 32)

n LISTofBYTE data(n is a multiple of 2 for format = 16)(n is a multiple of 4 for format = 32)

p unused, p=pad(n)


41/51

RRDeleteOutputProperty1 CARD8 major opcode1 14 RandR opcode2 3 request length4 OUTPUT output4 ATOM property

RRGetOutputProperty

1 CARD8 major opcode1 15 RandR opcode2 7 request length4 OUTPUT output4 ATOM property4 ATOM type

0 AnyPropertyType4 CARD32 long-offset4 CARD32 long-length1 BOOL delete1 BOOL pending2 unused

1 1 Reply1 CARD8 format

2 CARD16 sequence number4 (n+p)/4 reply length4 ATOM type

0 None4 CARD32 bytes-after4 CARD32 length of value in format units

(= 0 for format = 0)(= n for format = 8)(= n/2 for format = 16)(= n/4 for format = 32)

12 unusedn LISTofBYTE value

(n is zero for format = 0)

(n is a multiple of 2 for format = 16)(n is a multiple of 4 for format = 32)p unused, p=pad(n)

RRCreateMode

1 CARD8 major opcode1 16 RandR opcode2 12+(n+p)/4 length4 WINDOW window32 MODEINFO moden STRING8 mode namep unused, p=pad(n)

1 1 Reply1 unused2 CARD16 sequence number4 0 reply length4 MODE mode20 unused

RRDestroyMode


42/51

1 CARD8 major opcode1 17 RandR opcode2 2 length4 MODE mode

RRAddOutputMode

1 CARD8 major opcode1 18 RandR opcode2 3 length4 OUTPUT output4 MODE mode

RRDeleteOutputMode

1 CARD8 major opcode1 19 RandR opcode2 3 length4 OUTPUT output4 MODE mode

RRGetCrtcInfo


1 20 RandR opcode2 3 length4 CRTC crtc4 TIMESTAMP config-timestamp

1 1 Reply1 RRCONFIGSTATUS status2 CARD16 sequence number4 o+p reply length4 TIMESTATMP timestamp2 INT16 x2 INT16 y2 CARD16 width

2 CARD16 height4 MODE mode2 ROTATION current rotation and reflection2 ROTATION set of possible rotations2 o number of outputs2 p number of possible outputs4o LISTofOUTPUT outputs4p LISTofOUTPUT possible outputs

RRSetCrtcConfig


2 7+2n length4 CRTC crtc4 TIMESTAMP timestamp4 TIMESTAMP config timestamp2 INT16 x2 INT16 y4 MODE mode2 ROTATION rotation/reflection2 unused8n LISTofOUTPUT outputs


43/51

1 1 Reply1 RRCONFIGSTATUS status2 CARD16 sequence number4 0 reply length4 TIMESTAMP new timestamp20 unused

RRGetCrtcGammaSize

1 CARD8 major opcode1 22 RandR opcode2 2 length4 CRTC crtc

1 1 Reply1 unused2 CARD16 sequence number4 0 reply length2 CARD16 size22 unused

RRGetCrtcGamma


1 1 Reply1 unused2 CARD16 sequence number4 (6n+2)/4 reply length2 n size20 unused2n LISTofCARD16 red2n LISTofCARD16 green

2n LISTofCARD16 bluep unused, p=pad(6n) RRSetCrtcGamma

1 CARD8 major opcode1 24 RandR opcode2 3+(6n+2)/4 length4 CRTC crtc2 n size2 unused2n LISTofCARD16 red2n LISTofCARD16 green

2n LISTofCARD16 bluep unused, p=pad(6n)


RRGetScreenResourcesCurrent



44/51

2 2 length4 WINDOW window

1 1 Reply1 unused2 CARD16 sequence number4 c+o+8m+(b+p)/4 reply length4 TIMESTAMP timestamp4 TIMESTAMP config-timestamp2 c number of CRTCs2 o number of outputs2 m number of modeinfos2 b total bytes in mode names8 unused4c LISTofCRTC crtcs4o LISTofOUTPUT outputs32m LISTofMODEINFO modeinfosb STRING8 mode namesp unused, p=pad(b)

RRSetCrtcTransform


1 26 RandR opcode2 12+(n+p)/4+v length4 CRTC crtc36 TRANSFORM transform2 CARD16 filter length2 unusedn STRING8 filter namep unused, p=pad(n)4v FIXED filter params

RRGetCrtcTransform


1 1 Reply1 unused2 CARD16 sequence number4 16+(pn+pnp)/4+(cn+cnp)/4+pf+cf reply length36 TRANSFORM pending transform1 BOOL has transforms3 unused36 TRANSFORM current transform

4 unused2 pn pending filter name length2 pf pending filter num params2 cn current filter name length2 cf current filter num paramspn STRING8 pending filter namepnp unused, pnp=pad(pn)4*pf FIXED pending filter paramscn STRING8 current filter namecnp unused, cnp=pad(cn)


45/51

4*cf FIXED current filter params

RRGetPanning


1 1 Reply1 RRCONFIGSTATUS status2 CARD16 sequence number4 1 reply length4 TIMESTAMP timestamp2 CARD16 left2 CARD16 top2 CARD16 width2 CARD16 height2 CARD16 track_left2 CARD16 track_top2 CARD16 track_width2 CARD16 track_height2 INT16 border_left

2 INT16 border_top2 INT16 border_right2 INT16 border_bottom

RRSetPanning

1 CARD8 major opcode1 29 RandR opcode2 9 length4 CRTC crtc4 TIMESTAMP timestamp2 CARD16 left2 CARD16 top

2 CARD16 width2 CARD16 height2 CARD16 track_left2 CARD16 track_top2 CARD16 track_width2 CARD16 track_height2 INT16 border_left2 INT16 border_top2 INT16 border_right2 INT16 border_bottom

1 1 Reply1 RRCONFIGSTATUS status

2 CARD16 sequence number4 0 reply length4 TIMESTAMP new timestamp20 unused

RRSetOutputPrimary



46/51

2 3 length4 WINDOW window4 OUTPUT output

RRGetOutputPrimary


1 1 Reply1 unused2 CARD16 sequence number4 CARD32 length4 OUTPUT output4 CARD32 pad14 CARD32 pad24 CARD32 pad34 CARD32 pad4


RRGetProviders


1 1 Reply1 unused2 CARD16 sequence number4 CARD32 length4 TIMESTAMP timestamp

2 p number of Providers2 CARD16 maximum masters4 CARD32 flags4p LISTofPROVIDERS providers

RRGetProviderInfo

1 CARD8 major opcode1 33 RandR opcode2 3 length4 PROVIDER provider4 TIMESTAMP config-timestamp

1 1 Reply1 RRCONFIGSTATUS status2 CARD16 sequence number4 1+c+o+(a*2)+(n+p)/4 reply length4 TIMESTATMP timestamp4 CARD32 capabilites2 c number of crtcs2 o number of outputs2 a number of associated providers2 n length of name


47/51

4c LISTofCRTC crtcs4o LISTofOUTPUT outputs4a LISTofPROVIDER associated providers4a CARD32 associated provider capabilityn STRING8 namep unused, p=pad(n)

RRSetProviderOffloadSink

1 CARD8 major opcode1 34 RandR opcode2 2 length4 PROVIDER provider4 PROVIDER offload sink provider4 TIMESTAMP timestamp

RRSetProviderOutputSource

1 CARD8 major opcode1 35 RandR opcode2 2 length4 PROVIDER provider4 PROVIDER output source provider4 TIMESTAMP timestamp

RRListProviderProperties1 CARD8 major opcode1 36 RandR opcode2 2 length4 PROVIDER provider

1 1 Reply1 unused2 CARD16 sequence number4 n reply length2 n number of ATOMs in atoms22 unused

4n LISTofATOM atoms RRQueryProviderProperty

1 CARD8 major opcode1 37 RandR opcode2 3 request length4 PROVIDER provider4 ATOM property

1 1 Reply1 unused2 CARD16 sequence number

4 n reply length1 BOOL pending1 BOOL range1 BOOL immutable21 unused4n LISTofINT32 valid values

RRConfigureProviderProperty



48/51

1 38 RandR opcode2 4+n request length4 PROVIDER provider4 ATOM property1 BOOL pending1 BOOL range2 unused4n LISTofINT32 valid values

RRChangeProviderProperty

1 CARD8 major opcode1 39 RandR opcode2 6+(n+p)/4 request length4 PROVIDER provider4 ATOM property4 ATOM type1 CARD8 format1 mode

0 Replace1 Prepend2 Append

2 unused4 CARD32 length of data in format units

(= n for format = 8)(= n/2 for format = 16)(= n/4 for format = 32)

n LISTofBYTE data(n is a multiple of 2 for format = 16)(n is a multiple of 4 for format = 32)

p unused, p=pad(n) RRDeleteProviderProperty

1 CARD8 major opcode1 40 RandR opcode2 3 request length

4 PROVIDER provider4 ATOM property RRGetProviderProperty

1 CARD8 major opcode1 41 RandR opcode2 7 request length4 PROVIDER provider4 ATOM property4 ATOM type

0 AnyPropertyType4 CARD32 long-offset

4 CARD32 long-length1 BOOL delete1 BOOL pending2 unused

1 1 Reply1 CARD8 format2 CARD16 sequence number4 (n+p)/4 reply

Date post:	13-Feb-2018
Category:	Documents
Upload:	caio-loureiro
View:	219 times
Download:	0 times

randrproto

Documents