From: Geert Uytterhoeven <Geert.Uytterhoeven@cs.kuleuven.ac.be>
  To  : ggi-develop@eskimo.com
  Date: Wed, 12 Aug 1998 13:36:47 +0200 (CEST)

Re: kgicon FAQ

On Tue, 11 Aug 1998, Jon M. Taylor wrote:
> On Tue, 11 Aug 1998, Geert Uytterhoeven wrote:
> 	fbcon drivers are headed for the same mess.  The fbcon API is
> cleaner and more consistent than XFree86's, but the drivers are all still
> monolithic and I can see them diverging further and further from
> commonality as they are tweaked more and more over time.  It has become
> noticeably more difficult to use the fbcon drivers as examples just since
> 2.1.107.  The more that happens, the harder it will become to maintain the
> drivers and pull out common code and the harder it will be to extend the
> fbcon API without breaking lots of drivers that did wierd things on their
> own.

You're right about that.

Atyfb is getting more and more complex, because some Mach64 chips have builtin
clock/RAMDAC why others don't.

> > > 2. What can kgicon do that vesafb cannot?
> > > 
> > > * Work on older hardware that does not support VESA 2.0. 
> > > 
> > > * Load as a module.  vesafb must be compiled into the kernel.
> > 
> > Can't be difficult to change. Just add init_module() etc. functions.
> 
> 	That isn't the problem.  Right now, the BIOS calls to set the
> video mode are made in video.S, which executes early in the boot sequence
> before protected mode is entered.  To do this at runtime, you'd need to
> open up a vm86() box in the kernel like DOSemu does and make the BIOS
> calls in there, and you'd have to *keep* it open as long as the driver was
> loaded if you wanted to enable on-the-fly modesetting capabilities.  Not
> impossible, but not trivial either. 

I didn't say you have to set the video mode in the kernel. You can boot without
a working console (video mode initialized by video.S) and insmod vesafb later
(with some minor tweaks to vesafb).

> > > * Use YWRAP/YPAN to speed up console scrolling.  vesafb is limited in its
> > > knowledge of the layout of and ability to control the underlying hardware,
> > > and so it cannot use some tricks such as changing the start address of the
> > > framebuffer to speed scrolling.  KGI drivers have full control over every
> > > aspect of the hardware, and so they can use whatever capabilities are
> > > present to speed up scrolling.
> > 
> > Obsolete comment :-)
> 
> 	How so?  I hadn't heard this.

There's panning support for vesafb now. Haven't tried it myself yet (no Intel
nor VBE 2.0 cards).

> > > 3. What can vesafb do that kgicon cannot?
> > > 
> > > * Be compiled into the kernel and used at boot time.  kgicon drivers only 
> > > work as modules right now.  Sorry, no penguin logo |-<.
> > 
> > Time to make fbcon.c a module, too?
> 
> 	IIRC, the penguin logo bitmap data is thrown away after the kernel
> boots.

The logo is in fbcon.c. If fbcon.c is a module, you can still have it.

Unfortunately Linus decided not to take __init for modules for 2.2 :-( Code for
that was present in the vger tree, IIRC.

Greetings,

						Geert

--
Geert Uytterhoeven                     Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP}  http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium