From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Wed, 8 Jul 1998 15:49:30 -0700 (PDT)

Re: set_mode complexity

On Wed, 8 Jul 1998, Brian Julin wrote:

> On Wed, 8 Jul 1998, Salvador Eduardo Tropea (SET) wrote:
> > What I still thinking is that the complex negotiation must be moved 
> > outside the core of the driver. Perhaps a solution could be make it 
> > as another module (or the same just to make less troubles but very 
> > well divided internally).
> 
> I believe I'm not the only one who's commented that except for the 
> primitive code necessary to find default modes in an emergency or during 
> initialization, the drivers should merely validate, cache, and program modes; 
> not set them.

	Yes.  It is the job of a device driver to let you use the hardware
to the fullest extent safely possible, whilst putting as few programmatic
or representational barriers between userspace and the hardware as
necessary.  If you want to put further restrictions or abstraction on top
of this, do it in your userspace libraries or in higher-level kernel
layers like fbcon.

> The only role they should play in the calculation process is providing 
> info to whatever user-space programs handles calculating non-default modes.
> Moving the rest into user-space removes the kludge of having a driver
> "read a system configuration file," the calculation library does that.

	Yes.  The kernel driver needs to be able to reject invalid modes,
but it should not be in the business of saying what *is* a valid mode - to
it, *everything* that isn't invalid is valid.  Drivers should not say what
*is* permitted, they should say what is *not* permitted.  This is the
exokernel argument in a nutshell - OSes should not dictate interfaces or
set policy, they should multiplex the hardware safely and securely.  End
of story.

> (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? |->).  Hardware initialization should IMHO be taken care of
first by architecture(bus)-specific routines and secondarily by the
chipset drivers like it is done now, and mode negotiation by kgicon.  GGI
Console now deals strictly with abstract framebuffers and textbuffers,
doesn't it? 

Jon

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