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