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

[Alex Deucher]

On Wed, 16 Mar 2005 23:08:12 +0200, Ville Syrjälä <syrjala at sci.fi> wrote:
> 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...
> 

Good point.

> --
> Ville Syrjälä
> syrjala at sci.fi
> http://www.sci.fi/~syrjala/
>