From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Deucher Subject: Re: FB model basic issues (WAS: radeon, apertures & memory mapping) Date: Wed, 16 Mar 2005 16:17:37 -0500 Message-ID: References: <1110837171.5863.16.camel@gaston> <1110839873.5673.41.camel@gaston> <1110862777.4044.592.camel@localhost> <20050315060138.GA13064@sci.fi> <4236C770.8020101@hispeed.ch> <1110907029.4001.624.camel@localhost> <1110942559.24296.107.camel@gaston> <20050316200808.GB6651@sci.fi> <20050316210812.GA19937@sci.fi> Reply-To: Alex Deucher Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20050316210812.GA19937@sci.fi> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: xorg-bounces@lists.freedesktop.org Errors-To: xorg-bounces@lists.freedesktop.org Content-Type: text/plain; charset="iso-8859-1" To: Benjamin Herrenschmidt , =?ISO-8859-1?Q?Michel_D=E4nzer?= , Jon Smirl , Linux Fbdev development list , dri-devel@lists.sourceforge.net, xorg@lists.freedesktop.org On Wed, 16 Mar 2005 23:08:12 +0200, Ville Syrj=E4l=E4 wrot= e: > On Wed, Mar 16, 2005 at 03:58:07PM -0500, Alex Deucher wrote: > > On Wed, 16 Mar 2005 22:08:08 +0200, Ville Syrj=E4l=E4 = wrote: > > > On Wed, Mar 16, 2005 at 02:09:18PM +1100, Benjamin Herrenschmidt wrot= e: > > > > > > > > > It's ugly, but that's not the point. The point is that all deploy= ed > > > > > versions of X (and even current X.org CVS head still, in fact) ma= ke 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 futur= e > > > system with an in kernel memory manager. The current APIs just have t= oo > > > many limitations. I think the memory manager must be the foundation o= f > > > everything and after it's in place the fbdev API should be able to us= e it. > > > The only change to simple fbdev apps would be that they can't get acc= ess > > > 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 prob= lem. > > > > > > 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 poin= t > > > 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"? >=20 > I haven't seen anyone coming forward with a design/code for the memory > manager. >=20 > In the meantime I'm assuming that people might want to make some use of > their dualhead cards... >=20 Good point. > -- > Ville Syrj=E4l=E4 > syrjala@sci.fi > http://www.sci.fi/~syrjala/ >