Multi-monitor (xinerama/mergefb) support in RandR

[Eric Anholt]

On Wed, 2006-06-28 at 15:03 -0400, Alex Deucher wrote:
> On 6/28/06, Michel Dänzer <michel at tungstengraphics.com> wrote:
> > On Wed, 2006-06-28 at 10:07 -0400, Alex Deucher wrote:
> > > On 6/28/06, Benjamin Herrenschmidt <benh at kernel.crashing.org> wrote:
> > > > On Tue, 2006-06-27 at 23:07 +0200, Keith Packard wrote:
> > > > > Eric and I are busy figuring out how to handle multiple monitor hot plug
> > > > > with X and have a fairly simple plan.
> > > > >
> > > > > Multi-screen X basically sucks, so few people are really excited about
> > > > > using it. Xinerama sucks in the DIX implementation because it makes
> > > > > things slow and bloated. Mergefb mostly rocks; fast, small and even DRI
> > > > > continues to work right.
> > > >
> > > >  +/- the limitations of some 3d engines for too big screens... I don't
> > > > know if/how that can be handled...
> > > >
> > >
> > > Iterating across the framebuffer in coordinate sized chucks in the 3D
> > > driver. The 2d engine will also have this problem due to the
> > > limitations of XAA.  for this to work properly, drivers really need
> > > EXA support, otherwise you'll have to add hacks to re-base the 2d
> > > engine if you are outside your coordinate limits.
> > >
> > > Come to think of it, even EXA may be problematic.  the visible screen
> > > may no longer be solely at offset 0 if you have particularly big
> > > multi-head desktop.
> >
> > I don't see what would prevent the drivers from handling all this
> > transparently, at least with Radeons. Maybe I'm missing something.
> >
> 
> if your blitter limits are 2048x2048 and your visible desktop is
> 2560x1024, you would need to re-base the blitter to handle the visible
> screen.  Last I checked, exa didn't handle cases where the coordinates
> were beyond the limits of the blitter for a paricular surface.

Correct, EXA doesn't handle it yet.  The intention is for it to handle
it for the cases that matter (copyarea, render?) when we've got anybody
who cares about it enough to write code and test that case. You would
rebase the pointer of the pixmap *in exa* to a new location that matches
the alignment requirement for pixmaps.  I guess this may not be good if
tiling unit is much greater than rendering offset alignment -- is this
really true? (I think it isn't on Radeon).  But the point of this is for
the logic to be in EXA when we get around to it, rather than being
per-driver and often broken (as we've seen with per-driver offset
alignments so many times).

If we need more API to make this a reasonable plan, we should talk about
what exactly is needed.

> you would have to set up a tiled surface so that the CPU could
> properly access the surface.  if your visible buffer is larger than
> the limits of the tiled surfaces, then you would need multiple tiled
> surfaces to handle the whole "visible" framebuffer. e.g., on older
> radeons you have a 2048x2048 limit on the tiled surface regs, but you
> might have a 2560x1024 desktop.  you'd either have to disable tiling,
> or set up 2 tiles surfaces to cover the whole surface.

OK, that's pretty harsh.  So, we would need to deal with setting up
multiple surfaces to cover a given pixmap.  That's really ugly, and I'm
hoping that few drivers will need to deal with it.  Is this not the
case?  What could we do here if this is going to be more than on just
Radeon?

Though I guess for this corner case, I wouldn't really not be offended
by us just turning off tiling.

-- 
Eric Anholt                             anholt at FreeBSD.org
eric at anholt.net                         eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060629/84fdc833/attachment.pgp>