From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Tue, 14 Jul 1998 09:59:01 -0400 (EDT)

Re: set_mode complexity

On Wed, 8 Jul 1998, Jon M. Taylor wrote:
> > (So There I was starting to work on a evstack-based way to replace the 
> > mode negotiation/hardware initialization system so things would
> > be more flexible, and then along came kgicon and, well, no more 
> > kgi-manager for a while, not that kgicon isn't a good thing to have
> > happened.)
> 
> 	More details, please.  This sounds like a good idea in general,
> but I question the appropriateness of including it in the GGI Console
> (EvStack? |->).

Basically one would insert the subsystem modules independently,
then clone the driver stack for each, then feed them events telling 
them how to find their hardware or set operational parameters
(e.g. make an instance of the monitor driver into a timelist and pass 
in the modes), then attach the clone to a mode negotiation stack then 
once each driver stack attached to a mode negotiation stack is happy 
that it can talk to all the other subsystems, activate the stack by
attaching it to a head stack.

This could be elaborated easily by, say attaching two monitor drivers
to a mode negotiation stack which would only allow modes valid on both 
monitors (so one can be assured of being able to swap monitors), or 
a surrogate "mon-merger" stack that picks and activate the monitor(s) 
the mode fits on (so a laptop would display on both LCD and CRT when the 
mode fit.)  More thought needed, but it would be nice to work things out 
so you could set policy for individual VCs such that VCs 0-3 are guaranteed 
to be displayable after the laptop is detached from CRT while 
4-7 may work only on the CRT (attaching to VC stacks rather than head
would be a bit kludgy).

The basic reasoning to use EvStacks -- umm -- GGI-Console was a) why 
reinvent the wheel -- mode negotiation uses a sort of check-fail-retry 
event-like process anyway, b) the stacks offer a way to get around
using yucky insmod parameters, c) you could join new unheard-of 
subsystems onto the stack without modifying GGI-Console, d) you can
add a few subsystems with an alternative mode negotiation system
plus one subsystem that translates for the others and develop in a neat
modular fashion.

The only hitch is unlike most evstacks these do feedback, so they have
to be coded very carefully.  Anyway I didn't get too horribly far before
kgicon shifted my focus, so I save for a rainy day.  Right now I'm
just having fun poking around undocumented registers on my chipsets
and not doing my laundry; should have new drivers soon if my workplace
doesn't drive me to seek out meaningless entertainment this weekend 
in order to retain my mental health.

--
Brian S. Julin