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

[M. R. B. <mr...@0x...>]

* 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?

M. R.