Multi-monitor (xinerama/mergefb) support in RandR

[Keith Packard]

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.

To make multi-screen usable, we'll have to support sharing resources
(pixmaps, mostly) across screens, which would be a huge amount of work
in the DIX. It turns out that making multi-card Xinerama efficient is
almost exactly the same work, so we might as well just do multi-card
Xinerama at some point and save ourselves all of the application-visible
issues.

What does that mean for monitor hot plug though? What it means is that
we should focus on a Xinerama world where monitors are just views onto a
larger 'screen' area which is incompletely populated with monitor
viewports. Adding and subtracting monitor viewports is easy as the core
protocol doesn't expose these, and most clients won't ever care. We can
handle some of the complexity of monitor manipulation by resizing the
root window to shrink-wrap the set of monitors. This seems conceptually
clean (or as clean as Xinerama ever gets), shouldn't impact clients much
more than RandR already does and looks reasonably easy to implement as
well.

What does this mean for RandR? Well, that's a longer story, so I've gone
ahead and started looking at how this would work.

http://gitweb.freedesktop.org/?p=xorg-proto-randrproto;a=shortlog;h=multi-monitor

shows what the specification for this new adventure might look like.
Essentially, I've "extended" the existing RandR spec to separate out
screen size from monitor mode, by making the screen contain a list of
monitors, and each monitor contain a list of full CRTC mode
specifications. Each monitor also contains an x/y position within the
screen and a rotation/reflection value.

Compatibility with the existing extension is provided by reporting the
modes present for the first monitor in the list, along with a fake mode
based on the screen size (if different from the monitor mode).
Applications setting modes with the old extension will set both the
screen size and the mode for the first monitor. Additional monitors will
be set to a 'reasonable' mode and show a clone of the first monitor.

The implementation will emulate the old requests and DDX interface using
new data structures. That work is well underway and appears
straightforward.

With this change, RandR replaces the functionality of the XFree86
VidMode extension and Xinerama, while augmenting the capabilities of the
X server. It doesn't handle gamma table adjustment per-monitor, we can
just leave that in the VidMode extension if we like.

Interested parties are encouraged to read and comment on the proposed
changed to the RandR specficiation. I'm hoping to have a working
implementation done in the next week or so; Eric has been busy getting
the Intel driver ready to support this change.

-- 
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20060627/385f2e1e/attachment.pgp>