RandR version 1.2 revisited

[Alex Deucher]

On 9/13/06, Xavier Bestel <xavier.bestel at free.fr> wrote:
> On Wed, 2006-09-13 at 17:08, Alex Deucher wrote:
> > 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.
>
> RandR is intended to replace Xinerama which allowed this behavior (big
> screen with holes and overlaps). As this "big screen" concept is
> intended to work with different gfx cards put together in one machine, I
> don't think treating your FB as 2 entities is wrong.
>

As long as they are controlled by the same instance of the driver.
that was always my problem with the way dualhead is currently
implemented.  They don't have to be "screens" per se, it would just be
nice to be able to allocate buffers per "head".  that might even make
multi-card multi-head easier to deal with.  At some point we may even
be able to transfer from card to card directly without going through
system memory.

Alex

>         Xav
>
>