Re: GGI, EGCS/PGCC, Kernel source

Geert Uytterhoeven (Geert.Uytterhoeven@cs.kuleuven.ac.be)
Mon, 2 Mar 1998 04:31:00 +0100 (CET)


On Sun, 1 Mar 1998, Geert Uytterhoeven wrote:
> On Wed, 25 Feb 1998, Jon M. Taylor wrote:
> > On Wed, 25 Feb 1998, Alan Cox wrote:
> >
> > > > > drivers/hw/fbdev/fbdev.c is about all IIRC.
> > > >
> > > > KGI/m68k runs on top of fbcons.c. KGI exists in part because
> > > > fbcons.c was never ported to VGA-style hardware.
> > >
> > > Thats a good start. Cos fbcon exists for vga text mode now,
> >
> > When did this happen? This is good. Now we can potentially make
>
> Some months ago. It's called drivers/video/vgacon.c.

OK, although I can't follow this thread as closely as I want because I'm
currently abroad, I'd like to give some reasons why we'd like to have the
`abstract console stuff' in 2.1.x (and thus 2.2.0):

1. GGI isn't ready yet (that's what the GGI guys told me theirselves).

2. The abstract console stuff is multi-platform, and supports both VGA text
(currently 80x25 only), graphical consoles and GSPs (e.g. TIGA 340x0).

It's known to work on at least:

- m68k: frame buffer devices (Amiga, Atari, Apollo, Mac, graphics boards),
and TIGA graphics boards.

- ia32 (aka i386): VGA text mode (vgacon)

- AXP (aka Alpha): VGA text mode (vgacon) and TGA frame buffer device
(tgafb)

- PPC: VGA text mode (vgacon) on PReP, frame buffer device on Pmac and
CHRP

Furthermore people are working on frame buffer devices for ARM and MIPS.

So the only people that have reasons to complain are the SPARC and MIPS
guys (due to the lack of finalized frame buffer devices) and Pmac owners
with some graphics boards that aren't 100% Open Firmware compliant (same
reason). But then please read reason 4 :-)

3. Backwards compatibility: on ia32, you can keep on using your favorite X
server and SVGAlib applications (who am I to break compatibility on the most
popular Linux platform?). On Pmac/CHRP, you can keep on using Xpmac.

4. Of course CONFIG_ABSTRACT_CONSOLE is just a config option. We provide a new
console.c (console.new.c) and some changes in a few other files.

Final reason (more emotionally): is there any good reason why the first
non-Intel port of Linux (for the ignorant: the m68k port) is still not
completely integrated, while we had all those nice things running back in 1994
(no typo, one nine nine four!)????

Greetings,

Geert

P.S. For the people that wanted a URL about the abstract console scheme:

http://www.cs.kuleuven.ac.be/~geert/Console/

The web pages aren't up-to-date, but you can get an impression...

P.S.2. Writing a frame buffer device for one hardwired resolution of a graphics
board is a piece of cake. Look at tgafb.c for an example... What I'm
trying to say is that you should be able to write a frame buffer device
for your Sun in less than an evening.

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

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu