From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 29 Jul 1998 13:17:18 -0700 (PDT)

Re: I've seen the stars too... [Re: kgicon, etc]

On Wed, 29 Jul 1998, Rodolphe Ortalo wrote:

> >> > >IIRC it's a known problem (since the kernel's driver will already have
> >> > >claimed the vga space).  The #if 0 is alright in the short term, I'm not
> >> > >sure what exactly should be done in the long term...
> >
> >Write a proper console driver that doesn't claim these ports.
> > [...]
> >You know, my opinion about the console code can't be printed, can not
> >even be said in front of an audience. To say the least, it's a mess.
> 
> I don't know the current console code of linux. I only know the one
> of KGI. ;-)) So I cannot say...

	I know about it, although I am not an expert.

> Do you mean it is possible to write cleanly a multi-headed, 

	Yes.  Insert new fbcon drivers and use con2fbmap to migrate only 
some, not all, of the console to the new driver.  There's your multihead.

> multiple
> inputs capable 

	No.  AFAIK fbcon consoles cannot be switched to use different 
input devices.

> console system without EvStacks ? ;-)))
> Maybe then we don't need EvStacks in fact then ?
> BTW: I'm wondering, couldn't it be that earth is flat also... ?

	EvStack/GGI console is light-years ahead of fbcon.  But remember,
fbcon is not meant to be revolutionary.  Geert invented(?) fbcon to
implement the traditional linux console on framebuffer devices.
 
> >The KGI i386 boot display driver code doesn't use more than
> >a plain frame buffer. And it is shut up when a real driver loads.
> >That's why I am skeptical about the kgicon approach, but hey,
> >I am willing to learn.
> 
> The only interest I find in kgicon is that fact that it allows me to
> use a standard kernel to develop my KGI drivers NOW (because, aheemmm,
> currently it is difficult to develop with a KGI patch inside...).

	It is convenient.  It allows to separate the driver development
from the console development (and rom the input device development as
well), which IMHO is a good thing.  Not all people want to work on all
those things at the same time.  For example, now that I am working on
kgicon, I can turn on DEBUG_LEVEL=3 in all the drivers and it will not
lock up my system!  That always slowed down my development before, when I
was forced to use KGI's console to use KGI drivers. 

> I know I should be working on libgwt instead of playing with my graphic
> card, but well, you know...
> 
> The other interest is that it will allow us to distribute our code
> without requiring users to patch their kernel (a thing that seems
> to be associated with a sacrilege).

	It is a PITA which many people did not want to deal with. 

> But well, with a fully operational KGI kernel, I guess we will someday
> do the opposite: a /dev/fb emulation layer for KGI.

	I would rather see the Linux fbcon system tweaked to be able to 
use /dev/graphic (KGI) directly instead of /dev/fb (fbdev).

Jon

---
'Cloning and the reprogramming of DNA is the first serious step in 
becoming one with God.'
	- Scientist G. Richard Seed