Multi-monitor (xinerama/mergefb) support in RandR

[Eric Anholt]

On Wed, 2006-06-28 at 15:18 -0400, Alex Deucher wrote:
> On 6/28/06, Alex Deucher <alexdeucher at gmail.com> 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.  Also, for things like tiling, you may need
> > multiple tiled surfaces to handle big desktops (one per crtc
> > potentially).
> 
> Actually, what about just extending the exa memory manager to get rid
> of the concept of offscreen, just flag certain pixmaps as "scanout
> buffers" and then just allocated the buffers from the offscreen
> manager. then turning on the second head is just a matter of
> exaAllocateMem().  You'd have to re-init the DRI stuff though as your
> locations may change, but back/depth/texture buffers could all just be
> ExaAllocate() calls as well.  I guess we are back to the old FB
> manager problem...

There's nothing stopping you from doing this already, unless you've got
a DRI implementation that doesn't allow the server to ever move the 
front/back/depth (since things get freed at VT switch currently).

-- 
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/a2367bef/attachment.pgp>