RandR 1.2 feedback
aritger at nvidia.com
Wed Nov 22 17:38:36 PST 2006
I'm very sorry for taking so long to review the RandR 1.2 spec. It looks
good. I have just two main suggestions.
I read the version of the spec here:
- It would be nice if the specification tracked the list of modes
per output. Rather than have a single list of modes for the X screen,
and then have each output reference whichever modes are valid for that
output, it may make more sense to just store the modes per output.
One advantage is that the user can request a mode named "auto-select",
and each output could have a different mode with that name. We've had
this in the NVIDIA driver for a while, and it's been very useful.
The NVIDIA X driver also ensures that each mode in the per-output
list has a unique name, so that each mode can be uniquely requested
through the existing X config file. There is some info on that in
this section of the NVIDIA README:
I suppose that if you ever wanted to associate additional properties
with modes, but if those properties should be different per output,
then storing the modes per output would make this easier.
The downside of per-output modelists is that you end up with some
duplication of modes that are valid for each output. I wouldn't
consider that a big deal, though.
I think to support that, the spec would need to be changed to move the
LISTofMODEINFO out of the RRGetScreenResources and into RRGetOutputInfo.
RRCreateMode and RRDestroyMode would need to take an OUTPUT, and then
RRAddOutputMode and RRDeleteOutputMode would be unneeded.
If that sounds reasonable, I could make the spec changes.
- The proposed spec lets the client separately configure the X screen
size and each CRTC. This has very nice flexibility in that each piece
can be separately controlled.
One minor downside is that it takes multiple requests to reconfigure
things, and if one request fails, then the client may need to unravel
the previous requests to restore the X server to the previous state.
(that's in the best case where the client is actually coded to handle
that failure case; likely that clients would punt and then it would
be up to the user to get things back to the original state)
One major downside is that this doesn't give an implementation a
good opportunity to perform validation of the complete system.
The CRTC vs output distinction expose some specific hardware
capabilities/limitations to the client. That's fine, except that
there may be other restrictions. For example, things like video memory
bandwidth or TMDS Links may limit the combinations of modes that you
can use on different outputs at the same time.
Exposing CRTC vs output in the spec seems OK, but seems insufficient
to reflect all hardware restrictions; and I think hardware changes
too rapidly to realistically reflect all the various limitations that
hardware might have.
For our research into display configuration in the NVIDIA driver,
we've used the idea of a MetaMode as a container of an X screen's
configuration: X screen size, per-output mode, mode positioning,
panning, etc. A client can use NV-CONTROL protocol to dynamically
add new MetaModes to an X screen (the X screen contains a list of
MetaModes); then, the client separately switches which MetaMode the
X screen should use.
This is nice because adding a new MetaMode gives the implementation
a central place to perform any needed validation, and then you have
a higher likelihood of later being able to fullfill the request to
switch to that MetaMode. A MetaMode is also a nice abstraction for
backwards compatibility with RandR 1.1 and XF86VidMode -- they just
see the MetaMode as a single mode. Lastly, keeping multiple complete
screen configurations around makes it easy to return to the previous
config, if the user wants to revert his changes (or you present an
"are these new settings OK?" dialog with a 10 second timeout).
I've included some pointers at the end of this email, in case you're
interested in poking around more with the NV-CONTROL API for this stuff.
I know it's late in the RandR 1.2 design to suggest such a drastic
change, but to adjust RandR 1.2 to take more of a "MetaMode" approach,
the needed changes would probably be:
- add requests to add/remove a "ScreenConfiguration" (or call it a
"MetaMode", or whatever); a ScreenConfiguration would likely contain
the arguments that are current passed to the RRSetScreenSize and
- add a request to change the current ScreenConfiguration
- remove the RRSetCrtcConfig and RRSetScreenSize requests
If that sounds interesting, atleast to see what the spec would look
like with those changes, I could make the spec changes. I'd also
volunteer to help with the implementation effort.
- Other minor stuff:
- Should DPI be queriable per-output; I know the core X protocol
provides a single WidthMM, HeightMM per X screen, but it might be
useful to allow aware applications to query the DPI with per-output
- The spec should probably be clear that just because the width/height
in a RRSetScreenSize request is within the min/max range reported by
RRGetScreenSizeRange, we're not guaranteed to be able to fullfill
that. Video memory constraints, or other hardware constraints may
come into play that cannot be reflected completely by the min/max
values reported by RRGetScreenSizeRange (I assume that range is
intended to report the maximum renderable sizes?)
- I believe TwinView/MergedFB is different than Xinerama, and
that they solve slightly different problems. RandR 1.2 solves
the problem of querying/configuring outputs on an X screen on a
single GPU. But having a Xinerama X screen across multiple GPUs
is slightly different -- if each GPU stores only a portion of the
entire Xinerama X screen, the outputs connected to that GPU are
limited in which portions of the Xinerama X screen they can display.
(I know there are plenty of implementation concerns with Xinerama:
duplicated pixmaps on each physical X screen, etc; hopefully those
issues are independent of the XRandR+Xinerama issues discussed
This is a post-1.2 RandR issue, but my vote would be to expose
the underlying physical X screens through RandR when Xinerama
- Should a future version of the RandR spec allow clients to talk
in terms of the physical X screens underlying a Xinerama X screen?
If so, then perhaps the requests
should take a screen index, rather than a WINDOW? I assume in
Xinerama there is one Window for the entire Xinerama X screen,
whereas we may want finer granularity in the future?
Here are some NV-CONTROL pointers, in case it's interesting to see the
API that we used in the NVIDIA driver.
For talking about MetaModes and ModeLines, the NV-CONTROL extension uses
strings since they're very flexible. But defined data structures are
more concrete and probably better for RandR.
There is some info on the NVIDIA driver's mode validation here:
and some info on the NVIDIA driver's MetaMode syntax here:
If you grab the NVIDIA Linux control panel source here:
The relevant string attributes are documented in the header file:
The relevant string attributes are:
More information about the xorg