Multi-monitor (xinerama/mergefb) support in RandR

[Keith Packard]

On Mon, 2006-07-10 at 20:05 -0700, Henry Zhao wrote:

> This is a good idea. But I hope the implementation also covers MergedFB
> mode where some monitor info may be driver private (for example, in
> radeon driver, mode info for the secondary monitor is stored in
> ((RADEONInfoPtr)(pScrn)->driverPrivate)->CRT2pScrn) and more driver
> interaction will be required.

MergedFB is the primary target here, with the initial implementation
pointing at the Intel driver (oddly). 'classic' Xinerama with the
DIX-level kludgery is not that interesting to me; we need to fix the
server so that it doesn't require horrible duplication of resources
before multi-card Xinerama can really work with modern applications
(which all allocate huge piles of off-screen memory).

I'd love to see someone take the radeon (or any other MergeFB capable
card) driver and get it supporting monitor hot-plug on randr query;
that's really the only hard part within the driver for the new RandR
semantics.

> Another thought is whether it is possible to add mode resetting to
> RandR protocol to allow system to adjust modes to new configuration such
> as adding/removing monitors, change of config file, etc, without 
> restarting server. Although the implementation is still to be
> investigated, and currently if feasible, will depend on drivers.

This part has already been implemented for the classic RandR in the
Intel modesetting branch; you can plug a new monitor in, hit randr and
it will detect new monitors and present you with new mode lists. There
are limitations in the implementation which will be fixed when we plug
the new extension semantics in.

-- 
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/20060710/283d2444/attachment.pgp>