Re: Repeat the Ending

Geert Uytterhoeven (
Tue, 10 Jun 1997 11:07:45 +0200 (MET DST)

On Tue, 10 Jun 1997, Mike A. Harris wrote:
>On Mon, 9 Jun 1997, Geert Uytterhoeven wrote:
>> We could use a redesign of the console system. Things I'd like to see:
>> - separation between generic console stuff and low-level (VGA) stuff
>> - scrollback on all VCs, using a decent implementation (i.e. not depending
>> on VGA features, since they're of no use to me)
>> The way GGI does it (using the `scroller' interface) could be a start (but GGI
>> isn't perfect neither, for machines without a hardware text mode).
>> If you want to know more about the machines without VGA text mode, please let
>> me know.
>I have 18 local consoles, 5 to 10 of which I'm always logged in
>on. Since my VGA is only a 1meg card, the scrollback buffers are
>virtually useless to me, even more so if X is running. I'd
>definately like to see the console system re-written to allow a
>user defined buffer size for individual consoles. That way you
>could have consoles with and consoles without a buffer, and each
>console could have a different sized buffer. The vga hardware
>method is not very good IMHO.
>I'm very much interested in your thoughts.

You can find my abstract console patch at

(for Linux/m68k 2.1.42: abscon-m68k-2.1.42.diff.gz)

Here are some explanations, and my console wishes:

Amigas and Ataris don't have a text mode, so we use bitmapped graphics through
our frame buffer device. Other features we have:

- console.c always writes in a shadow image of the screen and then calls
optimized drawing operations (through struct consw in <linux/console.h>).
- scrolling up/down is done through a hardware trick
- each virtual console can have a different size. This is especially
important if you have more than one video board, with different resolutions
on each video board. Support for more than one video board is

What we don't have:

- scrollback support

SPARCs don't have text mode neither, and the same is true for the TGA driver.

My `abstract console' patch merges our console.c (which was
arch/m68k/kernel/console.c) with drivers/char/console.c. After applying it all
m68k console stuff is fully integrated.

What I'd like to see is a full split-off of the high-level and low-level
drawing operations.

- high-level:

o console.c performs all operations on a shadow image of the screen and
calls the low-level driver through an API similar to our struct consw.

o the shadow screen is large enough to provide a scrollback buffer for
all virtual consoles (not only for the current, cfr. VGA), without
using VGA tricks.

o the shadow screen could be 32-bit, allowing for 16-bit characters
(unicode), 4-bit foreground/background color, and 8 bit extra
attributes. VGA color can't draw bold or underlined color characters,
but bitmapped displays can!

o to speed up scrolling, the shadow screen can be a circular buffer.

- low-level:

o provides operations for

- block clear and copy
- draw one or more characters
- scroll (a part of) the screen
- draw/hide cursor
- blank the screen
- get/set font
- set palette

o characters are translated from the 32-bit representation to something
that fits on the screen.

This way a low-level driver can be written for

- hardware text mode
- bitmapped graphics text mode emulation

There also exist graphics board with a separate CPU (and memory) that can only
be accessed through some I/O registers (e.g. boards with a Texas Instruments
TMS34010 Graphical Signal Processor like the A2410 and DMI Resolver on Amiga).
These boards don't have memory visible from the host CPU but they are supported
through our struct consw. Jes Soerensen wrote a driver for his board, but it's
not yet integrated in the main source tree due to legal problems.

If you have some comments or questions, don't hesitate to tell me!




Geert Uytterhoeven           
Wavelets, Linux/m68k on Amiga
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium