Re: [Linux-fbdev-devel] Future of Framebuffer

[Sven <lu...@dp...>]

On Thu, Oct 04, 2001 at 04:12:52PM -0500, M. R. Brown wrote:
> * Chris Wright <cw...@so...> on Thu, Oct 04, 2001:
> 
> > This is somewhat ironic, but a friend of mine and myself have been
> > recently pondering vast extentions into the /dev/fb device.
> > Basically, we see it as a great device already.  (a simple pointer to
> > screen memory is all a graphics programmer ever wants).  however, most new
> > hardware usually supports some form of 2d and 3d acceleration.
> > unfortunately, these are seldom/never used in linux unless you have a card
> > that is supported, and then, only if you use X, which defeats the purpose
> > of /dev/fb.   we are proposing that a standard suite of ioctl's get added
> > to aid in acceleration.  of course, the basic driver would be a simple
> > vesafb driver plus software accelerations.  as cards are added, and
> > drivers are ported, they could be used in the software's place.  This
> > would make the hardware usable by anything, not just stuff in X, which
> > seems like a Good Thing to me :^)
> > 
> > so, is it a completly idiotic idea, or is there some potential here?
> > 
> 
> IMO, DRM is best suited for this, except that DRM is currently only used by
> the DRI in X.  I would think this would be the way to go (instead of a new,
> clunky, IOCTL interface), but then the question becomes, do you want to
> duplicate all of the DRI work (since DRM is only concerned with the
> "basics", as it should be) for a fb interface?  Or would a fb-only
> interface independent of DRI (but still a Mesa backend) be better?

There is no reason we couldn't use the DRM. I think James was speaking some
time ago about integrating DRM and fbdev, but i don't know if it is realistic,
or if this idea has progressed since.

Basically, from my experimentation with it while working on the X glint
driver, the DRI stuff is composed of 3 parts :

 o the DRM kernel driver, which contains interrupt handling, as well as the
   dma buffers support, with some additional control mechanism, allowing only
   root to access some part of the dma registers. This could and can be used
   for other purposes.

 o the XFree86 DRI driver, which does the intialization and the ressource
   management. It also handles some part of the context switching and register 
   saving/setting. This we will need to dupilcate, and i don't really think
   that it is the right place for it. The X folk don't thnk so though.

 o and finally, the openGL/Mesa drivers. This is a clientside thing, which
   provide all the stuff needed for acccel, and there is nothing stopping us
   from using it from the console.

What would be needed for fbdev to support DRI/OpenGL accels, would be for the
fbdev to provide the ressource management and initialisation done by the
XFree86 DRI driver, and most of the other stuff could be used as is. Anyway,
the fbdev driver mostly already has part of the info already needed (the cards
io and mem base and other such stuff), but i don't really know if there is
much more generic DRI stuff done. I think yes, but i have not looked. Most of
this could be handled by a userland small server app controlling the DRI
usage, or whatever. It may not even contain device specific stuff, not sure
though about it.

That said, the main problem is with the coordination of the 3D accel usage
between X and fbdev, especially if both use separate dma buffers. It would
also add lot of unused context switching.

Friendly,

Sven Luther

Now,