RandR future proposals
keithp at keithp.com
Thu Feb 15 09:36:37 PST 2007
While we're busy finishing up the RandR 1.2 work, I wanted to make sure
we didn't lose the good ideas that have been floating around for a few
days on IRC and from XDC.
During XDC, we chatted about issues of RandR with Xinerama-classic and
other multi-GPU environments. Right now, with RandR 1.2, you get
multiple X screens, one per-GPU, each of which can have multiple
monitors connected. With the goal of having only one X screen, we
discussed re-using the existing Xinerama implementation to merge
multiple GPUs into one X screen.
To let clients know what the underlying configuration in the X server
was, we talked about exposing a new RandR object, the 'GPU'. A GPU would
present another layer between the X screen and the CRTCs. It would
represent a collection of CRTCs and Outputs, and would have geometry.
The CRTCs would be required to be placed within the geometry of the
related GPU. GPU size and position would be controlled through the
Yesterday, Fredrik Höglund asked on IRC about pan-and-scan mode where
the position of the CRTC is controlled by the mouse. Right now, RandR
pretty much eliminates this as CRTC position is controlled only through
the protocol. Aaron Plattner mentioned that the nVidia closed-source
driver has an extra rectangle for each CRTC; CRTCs are allowed to
pan-and-scan within that rectangle, instead of the whole screen.
I think this idea makes some sense, and seems easy to add to RandR; a
simple rectangle-per-CRTC which confines the pan-and-scan boundaries. By
default, this would be set to the extents of the CRTC itself whenever
the CRTC mode was set. We'd still report CRTC changes through the RandR
protocol, so clients could even tell what parts of the screen were
currently visible. I imagine the Xinerama information would report the
pan-and-scan rectangle rather than the CRTC rectangle.
Neither of these ideas will be incorporated into RandR 1.2, but I'd like
to see if other people have ideas about what else might go into a RandR
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg