FB model basic issues (WAS: radeon, apertures & memory mapping)

[Ville Syrjälä]

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ä <syrjala at sci.fi> 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ä
syrjala at sci.fi
http://www.sci.fi/~syrjala/