On Sat, 28 Mar 1998, Linus Torvalds wrote:
> For example, I've already pointed out that the current kernel already
> _has_ a rather limited support for graphics: it can already write text on
> various graphics cards (the TGA chip I mention is only one of them, and I
> brought it up really only because that's the one I've used personally).
There's indeed support for graphical consoles in the kernel since a very long
time. But the TGA (and Sun and PowerMac) console has one major drawback: it
assumes the console principal operations are the blitting of single characters.
This makes scrolling very slow. And the only possible optimization is that you
don't have to draw a character if it's already present at its destination
screen position.
The only reasons the TGA console is still usable are that the TGA is connected
to a PCI bus (133 MB/s) and that it uses a fairly low resolution of 640x480
only. On slower buses/higher resolutions this scheme becomes unusable.
In fact this is the same reason I left GGI when I ported it to the m68k one
year ago. At that time the basic GGI console operation was the copying of
characters. This performed _very_ bad on the Amiga due to its slow bus. Amigas
were very nice machines, but only if you exploit their full capabilities.
(disclaimer: everyone has limited time, so I haven't looked in-depth at GGI
and EvStack since I stopped working on it)
It's better to consider more high level operations for the console, as is done
by our abstract console driver. But I'm open for other options too. One fact we
can't ignore is that more machines without a hardware text mode are hitting the
market. I don't mind _how_ the problem is solved, as long as (1) it _is_ solved
and (2) it performs reasonably well.
> So what is the difference between that kind of graphics support and the
> GGI kind?
>
> The difference is really a matter of interface, and tying my hands.
>
> The TGA kind of "make the graphics card work as a text-mode thing" kernel
> code does not imply a new interface. The code to do the text rendering may
> be simple or complex, buggy or bug-free, but whatever the case is it does
> not limit me or the kernel in any way because it really implies only a
> very limited interface to user space, and it is also an interface that I'm
> more thn happy to provide and that is _obviously_ required, ie a basic
> tty-like interface.
>
> Think of it as a very basic kind of driver, but a driver that makes no
> policy. The kernel only really guarantees that it can write characters on
> the screen.
>
> In contrast, the GGI kind of interface implies a lot _more_ in the way of
> support. And by implying that, it ties my hands: I am no longer free to do
> what I think is right, because I have to abide by the interface. This is
> what makes UNIX so good: the basic interfaces are _really_ well thought
> out (whether by chance or good design the basic "fork()" + "execve()" +
> "everything is a file" mentality is a very simple but powerful one). That
> is why I like UNIX, and why I wanted to write my own.
I really like the UNIX `KISS' (Keep It Small and Simple) philosophy. It allows
to do the most complex tasks by concatenating simple building blocks.
When extending this idea to the console, a console is indeed simply a tty. A
separate user process reads from it and renders the characters on the screen,
scrolls the screen, etc, using a communication protocol like VT100/ANSI X3.64.
User input (keyboard, mouse, ...) is fed to the tty by the user process.
Multihead and multikeyboard are implicit. Sounds great!!
Using this scheme, the whole drivers/char/console.c etc. stuff can be removed
from the kernel.
However, this also has a major drawback: where's the initial console, before
the userspace console daemon is running? I don't mind using console=ttyS0, but
many people will object against this. So we need at least a little bit of
support for `graphics hardware' (a generic term) in the kernel.
The two extrema are:
- put everything in the kernel: this is definitely not what we want, for
various reasons (discussed many times before).
- put everything in user space: this causes problems with interrupts and DMA
channels.
Thus we need a compromis. The question is: where to put the borderline between
kernel and user space?
Unfortunately these things may require a lot of work, and 2.2 is waiting...
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu