Re: framebuffer ioctl

[Otto Solares <solca@guug.org>]

On Sun, Sep 05, 2004 at 10:13:09AM -0700, Zack wrote:
> Some reasons for moving drawing routines into the kernel include
> (correct me if I'm wrong)

Does 'moving drawing routines into the kernel' means 'exporting
to user-space drawing (possibly accelerated)' routines?

> 1. there is some needless duplication of effort between these
> various fullscreen-gui projects (svgalib, ggi, etc)
> 2. there is afaik presently no good facility for adding acceleration
> support for things like drawing lines
> 3. the chance that any fullscreen-gui project will become broken
> due to a new kernel is real (SVGAlib is broken with 2.4.26 & 2.6.7)
> 4. new features would be optional anyway: fullscreen-guis need not
> recognize their existence, but would benefit from doing so
> since some fb drivers would override the generic routines
> to implement accelerated routines.

These are good reasons for a single user-space library, not kernel
bloat.

The only consumer of drawing routines in the kernel is fbcon,
and acceleration should not go into the kernel, user-space libs do
a better and safer job here.

The only --true-- reason drawing routines should go into the kernel
is hw w/o a user-space accesible fb (maybe true for some rare and
for some next-gen cards).

-otto


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click