Multi-monitor (xinerama/mergefb) support in RandR

[Eric Anholt]

On Wed, 2006-06-28 at 23:40 -0400, Alex Deucher wrote:
> On 6/28/06, Eric Anholt <eric at anholt.net> wrote:
> > 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).
> >
> 
> Doesn't exa make some assumptions about where the front buffer is (ie,
> lower offset than offscreen or offset 0)?  If not you could just flag
> the offsets of the scan out buffers in the driver (or better yet in
> exa/pixmap).   I'm just not sure what special stuff would be needed
> for the sofware rendering side.  How would you register multiple
> scanout buffers (with different pitches, etc) with the fb layer if you
> used ExaAllocate() to allocate your scanout buffers?

No, EXA really shouldn't need to know anything about scanout buffers --
they're just another scratch pixmap whose pointer happens to point at
framebuffer.  If your driver wants to relocate where the screen is in
memory, I think it would just have to get the screen pixmap and modify
the pointer and pitch to the new location.

The fb implementation wouldn't be able to split a single screen pixmap
into two separate memory buffers.  To do that you have to go to
traditional multihead with multiple screens.

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