On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote: > On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä <[EMAIL PROTECTED]> wrote: > > On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote: > > > > > > > It's ugly, but that's not the point. The point is that all deployed > > > > versions of X (and even current X.org CVS head still, in fact) make this > > > > assumption. > > > > > > Oh, that's fine and that's not a problem. I will only repaint the > > > framebuffer on bit depth or line lenght changes. I'm trying to talk > > > about the _future_ here. That is support for dual head at the fbdev > > > level and other niceties. > > > > I don't see the current system slowly evolving into some superb future > > system with an in kernel memory manager. The current APIs just have too > > many limitations. I think the memory manager must be the foundation of > > everything and after it's in place the fbdev API should be able to use it. > > The only change to simple fbdev apps would be that they can't get access > > to any offscreen memory as they do now. Something like DirectFB would need > > to change to accomodate the new system but I don't see that as a problem. > > > > I think the best short term option for radeonfb is to simply follow > > matroxfb's example and cut the memory into two parts. The cutoff point > > should probably be configurable via a module option. > > > > if we are going to go through the trouble to do it at all why not do > it "the right way"?
I haven't seen anyone coming forward with a design/code for the memory manager. In the meantime I'm assuming that people might want to make some use of their dualhead cards... -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- 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_ide95&alloc_id396&op=click -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
