[Linux-fbdev-devel] Re: FB model basic issues (WAS: radeon, apertures & memory mapping)

Jon Smirl jonsmirl at gmail.com
Wed Mar 16 15:35:49 PST 2005

On Thu, 17 Mar 2005 10:26:57 +1100, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> On Wed, 2005-03-16 at 15:42 -0500, Michel Dänzer wrote:
> > On Wed, 2005-03-16 at 22:08 +0200, Ville Syrjälä wrote:
> > >
> > > 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 agree on this.
> Ok, ok, I'll do crap since that's what everybody wants.

Why don't we modify the new radoenfb driver to have a real
arbitration/management layer. Directfb can continue to use the old
driver. The rule is that you can't mix old and new style fbdev drivers
in a system. Over time DirectFb and X can be fixed to use the new

There is going to have to be a transition path while we debug the
arbitration/management layer and figure out the right API for it.
Supporting multiple disparate users of the graphics hardware is a
quite complex feature that no other operating system implements.

> Ben.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg

Jon Smirl
jonsmirl at gmail.com

More information about the xorg mailing list