Framebuffer consoles have been around before on Unix workstations

June 12, 2022

The early Unix machines were what we would today call 'servers', and generally used serial terminals as their system console (well, they used serial ttys for pretty much everyone, but one of them was special). But then Unix workstations came along, which is to say small Unix machines with graphical displays. In theory these machines could have been designed to boot with their system console as a serial terminal (and often you could reconfigure them that way), but in practice that would have been rather awkward, so the graphics hardware and the graphical display were used as the system console. Which is to say that these machines had a framebuffer console, much like how modern Linux kernels work on x86 hardware. And just like modern Linux machines, these Unix workstations generally had surprisingly slow text output on their framebuffer consoles.

(For example, you can watch the somewhat leisurely text output of the kernel boot messages in this video of a Sun 3/60 booting.)

There generally were three reasons for this. First, these machines were just slow in general (by modern standards). Second, the machines were often using simple unaccelerated graphics to render their console text; using sophisticated code and hardware acceleration was generally something only the display server did (and there wasn't always hardware acceleration). Among other things, this kept the complexity of the kernel framebuffer driver down. And third, they were generally rendering text on the entire screen, often with large fonts. This would be like the difference between a normal 80x24 terminal window with normal sized text and a full screen terminal window with big text, although today's hardware often has fast enough text rendering that you might not notice much speed difference.

(One way for Unixes to cheat here was to render the text console as a more normal sized window in the middle of the display, as if it was running inside a terminal program like xterm.)

In fact, PC Unixes (including Linux) were generally the exception in how fast and good their text consoles were. This is because on traditional BIOS based x86 systems, the text console is actually handled by the kernel as more or less text through VGA text mode (also). The PC VGA text console required far less memory to be manipulated to change its contents compared to even a basic black and white bitmapped display (never mind a colour one, even 8-bit colour).

One of the consequences of this is that you almost never used Unix workstations in their text console mode. The text console was mostly for emergencies and for getting into the graphics system (and sometimes for watching boot messages, if you were the kind of person who did that).

(My fallible memory is that there was also a real range of console text rendering speeds. There were some Unix workstation vendors and workstation models that were well known for very slow console text rendering, and others that weren't so bad.)

Workstation Unix vendors did take advantage of the console's graphics capabilities to do various extra things. Sun famously drew their logo on the screen at the start of the boot process, and some of SGI's workstations had relatively graphical and 'user friendly' boot processes (there are various videos of SGI Indys booting that you can watch for some examples of how this looked).

Written on 12 June 2022.
« Linux kernel mode setting on servers (and Ubuntu 22.04)
In general Unix system calls are not cancellable, just abortable »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Jun 12 23:05:50 2022
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.