RandR future proposals

[Andy Ritger]

Thanks for raising these points, Keith.

wrt the pan-and-scan thing, yes, it's straightforward to implement 
(though there are a few behavioral questions to debate).  The "panning
domain" TwinView stuff in the NVIDIA driver isn't widely used, but I
have received feedback from power users that appreciate it.  I think
it's most commonly used when you have dissimilar sized CRTC rectangles,
and you want to pan the smaller one to access otherwise dead regions.

For interfacing RandR with Xinerama-classic, a 'GPU' object would be
a good thing to expose.  However the layer between the CRTC and the X
screen may be better served as a "framebuffer" or "physical X screen".
Some of the drivers today support having multiple X screens on one GPU;
while this is often less efficient than TwinView/MergedFB, it does serve
several purposes:

     - you can advertise different capabilities on each X screen (e.g.,
       stereo, overlays, etc)

     - you can overcome hardware size limitations that you run into with
       TwinView/MergedFB (e.g., 2 2560x1600 30" panels side-by-side exceed
       4k pixels; if your hardware cannot render to larger than 4k buffers,
       then users can instead configure two separate X screens, one to
       drive each of the 30" panels) and optionally enable Xinerama-classic
       over that

     - if you don't want the outputs driven by a GPU to be physically
       contiguous within your larger virtual Xinerama-classic X screen;
       e.g., a common 3-headed powerwall config is something like this:

         +--------+--------+--------+
         | a)     | b)     | c)     |
         |        |        |        |
         |        |        |        |
         +--------+--------+--------+

       where b) is expected to be where most of the interesting rendering
       happens and has one dedicated GPU, while a) and c) are driven by
       a second GPU.  You'd want a) and c) to have separate buffers,
       even if they're driven by the same GPU.

So I think it would be useful for RandR to have a notion of what "buffer"
each CRTC is scanning from, but that should probably be distinct from
the notion of a GPU, though a buffer could belong to a GPU.  If there 
were multiple buffers on the GPU, maybe you should even be able to swap
which buffer (on the same GPU) a CRTC is reading from.

After the RandR 1.2 work wraps up, I would be happy to take a stab at
(or atleast help with) the spec language for some of this stuff.

- Andy


On Thu, 15 Feb 2007, Keith Packard wrote:

> 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
> protocol.
>
> 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
> 1.3 version.
>
> -- 
> keith.packard at intel.com
>