This is a second try to establish a request for comments on the standard
properties of the upcoming RandR 1.3.
The first try died out pretty quickly, also due to /me being a lazy
bastard (read: other projects took away all of my time).
I finally updated the draft, as my original version wasn't exactly
future proof. The current version should work with both naming schemes
for outputs (connectors vs. encoders)
Of course, everything is open for discussion, but there are some
additional points I'd like to point out that need more thoughts:
- Apparently there are only 8, 16, and 32bit integers available as
property types. Having ATOMs and FLOATs would add semantics, which
could help in some cases. But if this implies some changes throughout
the system, I don't think this is helpful. If it's basically xrandr,
it would be easy.
- Is RANDR_BANDWIDTH helpful? Or should we have a dedicated property for
indicating dual link capability on DVI? What other meta information
(also on other connections) would be useful?
- Should RANDR_CONNECTOR_TYPE be made mandatory?
If a driver *really* doesn't want to implement anything here, it could
always set this to '0' and be done.
- Panning - Keith indicated pretty strongly that this should be part of
the protocol level, and not a property. Haven't dealt with that yet,
it's still in the diff.
- So far we didn't have standard properties, and no RANDR_ prefix.
EDID_DATA had been around since 1.2, should that be renamed to
RANDR_EDID_DATA (as indidcated in the draft), be left alone (and the
whole RANDR_ prefix idea burried), or cloned?
Matthias
--
Matthias Hopf <[EMAIL PROTECTED]> __ __ __
Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ [EMAIL PROTECTED]
Phone +49-911-74053-715 __) |_| __) |__ R & D www.mshopf.de
diff --git a/randrproto.txt b/randrproto.txt
index 626da56..2ac64e2 100644
--- a/randrproto.txt
+++ b/randrproto.txt
@@ -1100,7 +1100,167 @@ 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.
+
+Properties starting with "RANDR_" are hereby declared official, and
+driver SHOULD refrain from adding properties with this prefix that
+will remain driver specific or are not 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 "X_" 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 server
+doesn't handle a mandatory property correctly.
+
+9.1 Known properties
+
+ "RANDR_EDID_DATA" aka RR_PROPERTY_RANDR_EDID_DATA
+ 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.
+
+ "RANDR_SIGNAL_FORMAT" 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 (FBAS-PAL) describe more specific versions of the
+ base values (FBAS) 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-PAL etc.) or physical protocol
+ (e.g. VGA or TMDS on DVI-I).
+
+ "RANDR_CONNECTOR_TYPE" 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.
+
+ "RANDR_CONNECTOR_NUMBER" 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.
+
+ "RANDR_BANDWIDTH" aka RR_PROPERTY_BANDWIDTH
+ Type: int32 [2]
+ Flags: Immutable
+ Range/List: 0-
+
+ Maximum bandwidth of output in kHz, minimum and maximum values, for
+ the currently selected signal format. This also allows to determine
+ dual link capability of DVI-D outputs (more than 165Mhz).
+
+ "RANDR_COMPATIBILITY_LIST" 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.
+
+ "RANDR_CLONE_LIST" 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
+ RANDR_COMPATIBILITY_LIST.
+
+ "RANDR_PANNING_AREA" aka RR_PROPERTY_PANNING_AREA
+ Type: string
+ Flags: -
+ Format: <width>x<height>[+<xoffset>+<yoffset>]
+
+ Specifies the panning area in RandR mode per output.
+ This actually is a Crtc‐specific property. No panning will be active
+ if the specified panning area is smaller than the visible screen area
+ (determined by the active mode).
+
+
+9.2 Properties introduced with version 1.2 of the RandR extension
+
+Property Immutable Mandatory since
+──────── ───────── ───────────────
+EDID_DATA yes not mandatory
+ renamed to RANDR_EDID_DATA in version 1.3
+
+
+9.3 Properties introduced with version 1.3 of the RandR extension
+
+Property Immutable Mandatory since
+──────── ───────── ───────────────
+RANDR_SIGNAL_FORMAT no RandR 1.3
+RANDR_CONNECTOR_TYPE yes: static not mandatory (TBD)
+RANDR_CONNECTOR_NUMBER yes: static not mandatory
+RANDR_BANDWIDTH yes not mandatory
+RANDR_COMPATIBILTY_LIST yes not mandatory
+RANDR_CLONE_LIST yes not mandatory
+RANDR_PANNING_AREA no 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
@@ -1139,12 +1299,12 @@ version 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 +1321,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
_______________________________________________
xorg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xorg
