What about using the overlapped mode and dividing memory into four regions

FB0
PCI visible free mem
FB1
APER_SIZE
non-visible free mem

This way setting the mode on FB0 doesn't always bump into FB1.

The DRM could do this:
FB0
back0
depth0
aux0, etc
PCI visible free mem - textures priority 2
aux1, etc
depth1
back1
FB1
APER_SIZE
non-visible free mem - textures priority 1


On Sun, 13 Mar 2005 12:35:43 +1100, Benjamin Herrenschmidt
[off-list ref] wrote:

I could maybe use a single ioremap though, that is use a single
aperture, and then switch the swapper on accesses. Though I should also
be careful not to end up conflicting with a userland process relying on
having the 2 separate aperture swappers stable for the mode on the 2
separate framebuffer mappings... Like X would use fb0 while console
would use fb1 with a different swapper setting. That would blow up for
sure unless fbcon arbitrates accesses with X, which I don't see
happening right away. I suppose we'll have to consider both heads linked
as far as console ownership is concerned, at least for now, until the
kernel console subsystem is overhauled significantly.

In the long term I was hoping to design thing such that the two heads
can be used by two independent users, each could be running X or
fbdev.

A user space console implementation also makes a lot of sense in the
multiuser case. User space console can be a DRI application instead of
fbdev reducing the need to map.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click