From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Wed, 29 Jul 1998 10:29:51 -0400 (EDT)

Re: KGI backbone.

On Wed, 29 Jul 1998, Andrew Apted wrote:

> James A Simmons writes:
> 
> >  Right now the kernels console system is a mess.
> 
> No argument there.
> 
> >  In console.h we have 
> >  consw and in console_struct.h we have vc_data which describes data about
> >  each virtual console. Then we have vt*.h stuff. Yuk! With KGI all we need
> >  is kgi.h which does all this.
> 
> And kgi/console.h and kgi/keymap.h and kgi/kgi_struct.h and kgi/scroll.h
> and kgi/scroll_struct.h and probably some ggi/*.h stuff too.
> 
> >  Before we start porting all the kgicon
> >  drivers to this new system we should first rework promcon.c and vgacon.c
> >  etc to work with kgi. We would not rewrite console.c but change the consw
> >  interface to the kgi_display interface. If fbcon and the console system
> >  were layered on KGI could have a definite footing into the kernel.
> 
> The chances of the linux-kernel folk accepting that into the official
> kernel is zero with a capital 'Z'.  It ain't ever gonna happen. 

Never say never -- but you are right mostly it's a long way off.

> Maybe I
> misunderstand you, because I can't see the benefit in what you're
> proposing.  What functionality does kgi's console system provide that
> linux's console system lacks ?

Umm.  True xterm emulation with mouse operations for starters, then
there's all the goodies EvStacks had from a configuration perspective.

I for one was quite disappointed when direction changed towards
fbcon.  I had a functioning Degas Evstack tree with drivers working
and all and I was starting to cut my teeth on the finer points of
the drivers.

However anything that can be done to get the drivers and libGGI
a user base so they can be tested and developed more rapidly
must be, so I guess roll with it.

--
Brian S. Julin