You can find my abstract console patch at
http://www.cs.kuleuven.ac.be/~geert/bin/abscon-native-2.1.42.diff.gz
(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
work-in-progress.
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!
--------------------------------------------------------------------------------
Greetings,
Geert
-- Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be Wavelets, Linux/m68k on Amiga http://www.cs.kuleuven.ac.be/~geert/ Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium