From: Jon M. Taylor <taylorj@ecs.csus.edu>
  To  : ggi-develop@eskimo.com
  Date: Mon, 3 Aug 1998 15:21:24 -0700 (PDT)

Re: More progress with kgicon

On Mon, 3 Aug 1998, Andrew Apted wrote:

> Jon writes:
> 
> >  >> This change broke the Matrox Millennium driver. It says MMIO == NULL.
> >  >
> >  > Oh, sorry I thought everything was supposed to set up the MMIO
> >  > information probably (except maybe the stock VGA driver).
> >  
> >  	No, AFAIK MMIO information as it pertains to the card as a whole
> >  is internal to the KGI drivers and should not be exposed to the outside
> >  world except in the context of a kgi_mode. 
> 
> The mmio information is the only place to get the physical address of
> the framebuffer which belongs in fb_fix_screeninfo.smem_start (and
> which char/fbmem.c _needs_ to allow userspace mmapping), and the total
> size of the framebuffer which belongs in fb_fix_screeninfo.smem_len.

	Ah, OK.  I had thought that this was done by the KGI drivers, but 
I forgot that we don't have KGI itself anymore.

> >  	The ET6000 chipset driver currently sets a default mode by
> >  scanning the hardware settings and building a kgi_mode out of them.  It
> >  seems like this is designed to ensure that the video mode before driver
> >  insertion is the same mode that is set after driver insertion.  But this
> >  is not always a valid thing to do.  What if your driver is to be run on a
> >  system not based on VGA-style hardware?  What if the card is hooked to
> >  another monitor for multiheading, and that monitor cannot handle the same
> >  mode as the other one?  What if the user wants to start off with a 
> >  different mode?
> 
> Isn't this a legacy of "Dali" KGI ?  AFAIK KGI drivers were supposed to
> recognise the existing text mode at insmod time and restore that mode
> rmmod time (so that the boot driver could handle it).

	Yeah.  However, the situation is different with fbcon because
drivers are not overloaded the way they were in KGI.  If your driver takes
over consoles from another driver, that other driver must take over the
console again in order to be able to handle it - it doesn't happen
automatically.

> >  	Also, in fbcon-kgi.c in kgi_init(), you commented out the call to
> >  kgim_check_mode(), thus passing the default kgi_mode set by your chipset
> >  driver through unmodified.  Problem is, that kgi_mode is set by the
> >  chipset driver at chipset init time, and the chipset doesn't know anything
> >  about the other driver subsections.  The mode MUST be passed through
> >  kgim_check_mode() to give each of those subsections a crack at it before
> >  its info can be assumed valid and be used for anything.  The various 
> >  check_*_mode() functions can tweak the mode in many ways, and it is 
> >  possible that something important like the LFB base or the resolution 
> >  could change.
> 
> What happens now is that in kgi_do_set_mode(), the ggi_mode is
> calculated from the var structure, then the kgi_mode is
> checked/filled-out by check_mode(CMD_PROPOSE) (which causes
> kgim_check_mode() to be called) and then set_mode is called.
> 
> So the initial mode-set which occurred in init_kgi() now happens in
> kgifb_init() via the call to kgifb_set_var() in there.  The check_mode
> hasn't been skipped, just moved.

	OK, but the MMIO base is used before that point, which means that
the chipset driver must set a default mode like the ET6000 driver does
(and S3 drivers do not).  So, I get MMIO == NULL.

> >  If it is desired to set the default
> >  mode of the new display to the mode of the VC it was mapped from, that
> >  information should be passed in to kgicon by fbcon when the CON2FBMAP
> >  ioctl is recieved.
> 
> Well yeah, we can try to make the initial mode matching whatever
> vc->cols and vc->rows is, and fallback to something else if that fails
> (and calling some resize_console function *shudder*).

	The fallback logic gets quite complex at that point.  You can
raise or lower the mode timing, resolution, bit depth or text rows/cols. 
Which of these are more "important"?  How do you know which are the most
likely to give a working mode with the least tweaking? 

Jon

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