From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Fri, 7 Aug 1998 17:58:11 -0700 (PDT)

Re: vga kgicon problem summary

On Fri, 7 Aug 1998, Brian Julin wrote:

> On Fri, 7 Aug 1998, Jon M. Taylor wrote:
> > 	I wouldn't favor this.  We are just now getting to a more clean
> > and logical separation of components within GGI.  Lack of this caused us
> > problems in the past.  IMHO, all parts of GGI (GGI Console, LibGGI, KGI,
> > KGI drivers, KII) should be usable on their own or in any combination with
> > other GGI parts.  In particular video drivers and consoles should remain
> > separated, whether they be fbcon/fbdev or GGI Console/KGI.
> 
> No, no.
> 
> I didn't mean to suggest the full scroller; something along the lines
> of textops or whatever minimal subset of that can implement an fbcon
> would be fine.  

	Ok, but this still assumes that textops will be used.  Again,
drivers should export the hardware functionality.  If that includes
textops, great, but if not, that is a job for the console IMHO.

> None of the Degas drivers proper actually had their own 
> custom scrollers.  My point is it's more trouble than
> it's worth to try to mesh the fbcon renderers and KGI drivers.

	It works OK.  It isn't optimal, but we kinda have to shelve that
anyway when working with fbcon.  You can't optimize drivers for two driver
APIs at the same time, and fundamentally those KGI drivers were designed
to work with KGI.  They work OK with fbcon because we can sort of recreate
a little bit of KGI in fbcon-kgi.c, but like you said it is more trouble
than it is worth to do a lot of optimization.

> You'd basically have to end up writing a backend renderer for lots of
> chipsets; and if you're going to do that you maight as well
> do it in a way that GGI-Console will find useful.

	Then those backend renderers should be part of GGI Console.  The
KGI drivers should not be made to support any given API or set of APIs. 
Let those APIs support themselves.  GGI Console, X, LibGGI, and other
userspace APIs may all have different needs as far as backend renderers
are concerned, but they should all be able to use the exact same KGI
drivers.

> And note they don't _have_ to be bundled with the drivers.  In fact,
> they'd more likely be better built from libggi driver-libs and linked
> in optionally.

	Exactly.  That is just fine with me, in fact it is a very good
idea.  That's all GGI console *is* - just a bunch of "backend renderers"
of various types and complexities tied together in whatever way is needed. 
GGI Console's baseline in-kernel renderer could be basic text16 ops like
fbcon has now, and more complex or hardware-specific stuff could be added
on as kernel compile options and/or userspace modules (Stacks?  Are we
still calling them that?) as needed on a VC-by-VC basis.

	Man, every time I get to thinking about what GGI Console will make
possible, my mind just reels.  GGI Console is going to kick so much ass it
won't be funny.  I think that OSes of the future will have a modular
message passing and switching console system like GGI Console at their
core.  After all, the most important parts of a computer are the parts
that interact with the human user - the IO devices he/she uses and the
communication between them and the user.  i.e., the console.  

	In effect, *everything* in an OS except the console is a "backend
renderer".  The console IS the computer.  Everything else in a computer
exists to serve the console, and through that to serve the user.  In OOP
terminolgy, the console is the interface and everything else is the
implementation.  The implementation is supposed to be hidden and to exist
only to export the interface, but currently we let the implementation
dictate the interface by restricting the notion of a console to a
TTY+keyboard+mouse.  it will be really nice to get away from that. 

Jon

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