From: Andrew Apted <ajapted@netspace.net.au>
  To  : ggi-develop@eskimo.com
  Date: Mon, 3 Aug 1998 18:00:25 +1000

Re: More progress with kgicon

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.

If this info is only valid _after_ a mode has been set, then that's OK,
we just need to rearrange things a bit (like where we call kgi_encode_fix).

>  I took a look this afternoon at fbcon-kgi.c and the et6000 chipset
>  driver, and I see what you are doing but I don't think it is the
>  correct way to handle default modes.
>  
>  	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).

>  	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.

>  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*).

>  > (Note the current code assumes *1* mmio structure which is the
>  > framebuffer -- if there are others then they would need to be *after*
>  > the first one.  Probably kgicon should scan the list looking for the
>  > FRAMEBUFFER tag...).
>  
>  	Again, you shouldn't need to look at the MMIO regions to get the 
>  base and size of the LFB if your mode is set up correctly.

We need the physical address (mmio.pstart) so that fb_mmap() will work.
  
Cheers,
_____________________________________________  ____
                                               \  /
  Andrew Apted   <andrew@ggi-project.org>       \/