From: Brian Julin <bri@forcade.calyx.net>
  To  : ggi-develop@eskimo.com
  Date: Thu, 6 Aug 1998 23:46:18 -0400 (EDT)

vga kgicon problem summary

Woohoo! (sorta)

I finally have a working kgicon on a sunsite kernel (2.1.114).
And I'm writing this e-mail on it.

These are the issues I observed and some of the things I had to
do to get things working.

First, I had to run in 1bpp mode; to do this I had to set the
hardcoded default in fbcon-kgi.c.  It's not horrible -- it
underlines bold text.

Using 8-bit mode as a default results in real big characters interlaced
with each other.  Probably because when the VGA driver gets a request 
for anything bigger than 320x200 it uses mode X, and then fbcon tries
to draw on this as though it's a linear-8 buffer.

Using 4 bit seems to lock the machine solid.  Not even Magic SysRq works.
Colored vertical stripes are displayed.  Note even 4-bit needs special
support in 640x400, as the plane masks need to be changed.  Do I remember
seeing fbcon support for vga 4bpp at one point?  But if it
selects a regular planar renderer...  also could be the accel module
registering a real large area (Andy's MMIO cleverness for 
letting the libGGI driver select multiple bitplanes via segfault.)

Noone has fixed the mode.fb being a physical address problem --
vga_text16.inc can probably be removed for now to accomplish this.
until such why not just kgifb_videovirt = bus_to_virt(kgifb_videophys)??
If you want the vga driver to work this is the way I did it.

2 suggestions to fix:

1) Unless there is a fbdev_mda running, use A0000-Bffff -- this gives you
a 128K window.  Use 4bpp as a default mode (all drivers should IMO,
it's the most widely supportable color mode.)  Use 640x200 and 
8x8 characters and you fit in a linear window.  However the vga chip will
plane out at 64k -- unless anyone can find a vga standard way to
force it to use 32k planes then we get a 2bpp mode with fbcon
being under the impression it's 4bpp.

But it's color and it works mostly, and the older svga chipsets can often 
plane at 32k just by _setting_ the available memory bits to tell the 
chipset it has 128kb, so on those drivers you get 4bpp with a simple 
alteration in set_mode that won't effect libggi when used with a 
default planar-4.  When mdafb is present, hack mem_claim_region to
fail and the driver can be coded to pass a 1bpp default mode.
The 2bpp way requires the kgi driver to set the pallette in
all 16 locations with a repeated 4 color pallette.

2) The real fix is to allow the kgi driver to offer a scroller via
kgi_text_operations and write a framebuffer driver that uses the kgi 
scroller's framebuffer operations.  What I'm suggesting is a move to 
the Degas drivers, as this also I believe will make the mode.fb trouble
go away; they use virtual addresses in the extended mode.fb.* struct.  The
only problem here is a few of them don't have complete text-->dpp/bpp
fixes, but a few of us had that fixed in our own private
sources already.

Last problem:

The clean target should not fail out if a driver subdirectory
has a broken makefile; I fixed a problem today with my new
makefile experiments where the WD driver prevented build.
It should hit all the subdirectories, but tolerate failures
with a warning.

P.S. For some reason 2.1.114 will hang my ethernet card (ISA 3c509);
I think this is avoidable by pinging something right after
boot; but that's just a guess -- time will tell.

--
Brian S. Julin