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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ------------------------------------------------------- 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 -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
