From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop <ggi-develop@eskimo.com>
  Date: Sat, 6 Feb 1999 11:01:13 -0500 (EST)

Re: [linux-fbdev] Accel or not accel in kernel! (fwd)

Hi guys. I have tried to make a comprimise which I think will be in the
best interest of everyone.

> Why not have a separate distribution of theese things... :-)
> We can then stop arguing about this here.. There is no need for accel in
> fbdev. Let's do acceldevs instead and distribute them beside the kernel.
> As it look today this is leading nowhere.    
>

I completely agree. I have been doing research on SGI stations and coming
up with ideas to NOT bloat the kernel and to bring peace to everyone.

Yes accels do not belong in fbcon! Here are my reasons.

1: 
  Not every video card supports accels but every video card does support
  setting at least one mode. This is the true purpose of fbdev. I know one
  fear was the scattered accel API mess and what if people wanted to use
  software accels in the kernel to make their cards behave like true HW
  accelerated cards. 

2:
  Some cards come with a extra graphics coprocessor which can't be
  detected by the BUS ie. glint cards. How would fbdev handle this?
  Its shouldn't have to handle this. Also what about video cards that
  support accels but not framebuffers. Placing accels into fbcon will bind
  accel support only to fbdev. Then the accel API would have to be
  ported to non framebuffer devices.

3:
  I realized that accels in fbcon would limit the potential at using
  accels properly. This is something SGI showed me. Lets take the position
  that fbcon did add accels to its API. Now I start X windows that uses
  fbdev and starts to use accels. Now I want to start to use accels in 3
  different graphics programs. Here are the different models that exist:

  I. Present model with fbdev.

  Regular   app in X -> Xlib -> Xserver -> fbdev
  Graphical app in X -> Xlib -> Xserver -> fbdev
                                        -> hit accels in userland.
   /* or we can do it this way like MESA does */
  Grpahical app in X -> Xlib -> Xserver -> fbdev /* to set mode */ 
                     -> hit accels in user land 
  Graphical app not in X -> open fb -> hit accels in userland if needed.

  The above situation can hose a system. Also you have to admit to make
  libsvga, X server, OpenGL, Mesa, libggi all make sure the other doesn't
  step on each others feet would add alot of overhead. You needed to
  manage accels because the 2nd and 3rd situation can happen at the same.
 
  II. Fbdev with accels.  

  Regular app in X -> Xlib -> Xserver -> fbdev  
  Graphical app in X -> Xlib -> Xserver -> fbdev -> accels in fbdev.
  Graphical app in X -> open fb -> accels in fbdev.
  Graphical app not in X -> open fb -> accels in fbdev

  As you can see you have to open fb again to just use accels to avoid
  the overhead of going threw Xlib. This also binds the accels API to
  fbcon and not every card has accels and not every card that has accels
  has a framebuffer.
 
  III. Purposed model.

  The direct rendering model SGI uses.

  Regular app in X -> Xlib -> Xserver -> fbdev or some other device.
  Regular app in X -> Xlib -> Xserver -> X server wants to use /dev/gfx
                                         for things like blits to move
                                         windows fast. Independent of app
                                         and if X uses fbdev or some other
                                         device to set a mode.
  Graphics app in X -> hit /dev/gfx directly for speed. 
  Graphics app not in X -> hit /dev/gfx directly for speed.

  
As you can see the SGI model has its strong points. With this model fbcon
will never hear about accels again. Does this purposal sound like
something everyone can live with?