From: Ville <sy...@sc...> - 2005-03-16 20:08:12
|
On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrote: >=20 > > 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 t= his > > assumption. >=20 > 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=20 system with an in kernel memory manager. The current APIs just have too=20 many limitations. I think the memory manager must be the foundation of=20 everything and after it's in place the fbdev API should be able to use it= .=20 The only change to simple fbdev apps would be that they can't get access=20 to any offscreen memory as they do now. Something like DirectFB would nee= d=20 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=20 matroxfb's example and cut the memory into two parts. The cutoff point=20 should probably be configurable via a module option. --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |