Multi-monitor (xinerama/mergefb) support in RandR
eric at anholt.net
Wed Jun 28 17:49:06 PDT 2006
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...
Size: 187 bytes
Desc: This is a digitally signed message part
More information about the xorg