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

On Wed, 16 Mar 2005 23:08:12 +0200, Ville Syrjälä [off-list ref] wrote:

On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote:

quoted

On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrjälä [off-list ref] wrote:

quoted

On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote:

quoted

quoted

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