From: James Simmons <jsimmons@edgeglobal.com>
  To  : ggi-develop@eskimo.com
  Date: Thu, 25 Mar 1999 09:44:02 -0500 (EST)

Re: Linus on linuxworld

On Thu, 25 Mar 1999, Johan Karlberg wrote:

> 
> 
> On Wed, 24 Mar 1999, Josh wrote:
> 
> > 
> > 
> > On Wed, 24 Mar 1999, Sengan Baring-Gould wrote:
> > 
> > > http://www.linuxworld.com/linuxworld/lw-1999-03/lw-03-opensources.html
> > > 
> > > Rule number 1 for keeping the kernel healthy: avoid new system interfaces.
> > > Once you give an interface to users they will start coding to it and once
> > > somebody starts coding to it you are stuck with it. Do you want to support
> > > the exact same interface for the rest of your system's life?
> > > 
> > > Given that graphics evolves very quickly, isn't the above actually rather
> > > hard
> > > to achieve beyond a framebuffer?
> > > 
> > > Sengan
> > 
> > 
> > 
> > I've just started getting into the ggi project, so I'm not in any position
> > to dictate where ggi should go, but it seems like the logical thing to do
> > is to make kgi the absolute minimal driver. Maybe setSaneMode() (in the
> > case that something gets hosed), saveState(), restoreState(), setMode(),
> > and a few setVideoRegister()/getVideoRegister() functions that disallow
> > invalid/destructive register settings.  This way the kernel API is
> > minimal, and all the real work is done in user space.
> > 

The way to think about drivers is by what they function to do. Not writing
hardware specific code. All video cards do a getMode or do a Setmode at
least once. Sbus based sparcs can have their mode switched after booting.
The new KGI api even abstracts it more so you can support even more types
of hardware.

> > In any event, I applaud the ggi project.  The linux kernel is
> > fundamentally broken.  
Yes the kernel is broken and I'm working hard to fix it. 

> > It's purpose is to abstract the hardware so that
> > applications may make use of it effectively, and it fails in the area of
> > video cards.  It's like not supporting sound cards because the PC speaker
> > is sufficient to produce error bells.  fbcon is better than just text
> > mode, but it's rudamentary at best.

Well all video cards can set modes but not every video card does accels. I
had this discussion with the fb developers. We agreed to have a seperate
driver for accels expect for the basic ones like blits and fill rect. I
have been busy fixing the fbcon system so I haven't worked on /dev/gfx
yet. The plan is to have /dev/gfx which worked on a per process bases.
This way you can run 3 OpenGL programs that use /dev/gfx in X windows at
the same time. During context switches the graphics state is saved for
process that use gfx. I know alot of people don't like the idea of per
process base but I have to see if it possiable and worth it.

> Yes, the minimal KGI driver you are talking about is pretty much our ideal
> driver, for the ideal hardware in an ideal world. Unfortunatley however,
> many a hardware out there has no way for you to safely export acceleration
> registers to userspace while also guaranteeeing that a user cannot lock
> upo the graphics card or acceleration engine, thus leaving the system
> unusable. On some hardware, Matrox cmes to mind, it is supposedly possible
> to export acceleration registers safely, and in such a case, it is the way
> it is supposed to be done. a minimal kernel driver and acceleration in the
> ggi stubs. On most hardware that is buggy or poorly designed (S3 comes to
> mind here, alsthough not exclusivly in anyway) we will have to have
> acceleration in the kernel, or not at all, in order to maintain system
> integrity.

Ping Pong buffer time. For broken hardware you mmap a psuedo accel buffer.
>From time to time the kernel reads this buffer and filters out the
dangerous commands and flushes the safe ones to the accelerator.