RandR version 1.2 revisited

[Alex Deucher]

On 9/13/06, Keith Packard <keithp at keithp.com> wrote:
> Discussions during DDC this summer prompted me to discard the
> specification and implementation of the RandR upgrade I'd been working
> on. I've finally managed to sort through the issues and come up with a
> new proposal that purports to meet the requirements presented at that
> meeting.
>
> I've attached the current draft to this message; it's also available via
> git in the git://anongit.freedesktop.org/git/xorg/proto/randrproto
> repository.
>
> Here's a thumbnail sketch of the plan:
>
> Screens (X screens) refer to three sets of objects:
>
>  1) Outputs     - display data.
>  2) Screens     - contain pixel data
>  3) CRTCs       - map a subset of the screen to zero or more Outputs.

Rather then having one big "screen" with multiple crtcs pointed at it,
it would be more efficient to have each crtc point at it's own
"screen" for multi-head modes.  In the driver we could just just give
the memory manager control of the entire FB and allocate a 1280x1024
chunk for one crtc and a 1024x768 for another, etc. rather than
allocating a huge 2304x1024 screen.  Then there would be no "dead"
areas of wasted memory.  It would also avoid problems with blitter
limits if you have a particularly big desktop on an older card.  You
could also support dissimilar color depths more easily that way.

Alex

>
> The goal here is to model real hardware in an attempt to make the
> extension flexible enough to cover the bulk of situations likely to
> exist.
>
> Outputs support a list of modes. CRTCs support a list of outputs.
>
> To hook output up, you select a set of outputs, a mode common to all of
> them, and then a CRTC which can drive all of them. This combination is
> then pointed at a specific location within the screen from which to
> display pixel data.
>
> A few questions remain unresolved:
>
>      1.  How to describe restrictions in the configuration; ideally,
>         we'd be able to model which configurations are possible, at a
>         minimum, we need to know how to change a configuration to make
>         it work.
>      2. How to describe the sub-pixel geometry per-monitor, and what to
>         do with that information when we have it.
>
> Please take a look at the spec and see if you can catch other errors or
> ommissions.
>
> --
> keith.packard at intel.com
>