Text consoles and framebuffer consoles in Linux
utcc.utoronto.ca
utcc.utoronto.ca
I didn't have time to read the article yet but I assume those DOS era display cards were just hella optimised for text output.
My Apple II could write text faster than a PC.
> It was like it just output the last page only.
There are times you want the scrolling so you have an idea of how much went by the terminal.
True, it was not very handy, but I was very impressed :)
There's a very noticeable difference compared to a X stack known for its low latency (X, no compositor and XTerm).
I think part of the reason is that most distros don't use the native text console but use their own (they draw their own characters because 80x25 is not really handy on a 27" display :P ). And I think GPU's don't really optimise this mode like the DOS ones did.
After all, this mode is only ever used for the boot screen (and these days often not even there!). Or perhaps for ESXi or Linux servers, not an important usecase and not something people really interact with on a daily basis anyway.
There were tools to program VGA card to higher resolution text mode (svgatextmode), and also s3fb supports higher resolution text mode in kernel.
The system I was experimenting on was a mid-90's 120MHz ancient Packard Bell PC with 56MB of RAM in SIMMs (had that famed bad CMD640 IDE chip). Had a Cirrus Logic VGA adapter onboard.
I remember being able to set all kinds of crazy text resolutions - like lower than 80x25, which was funny.
I also remember in the quest for the highest text resolution - there was some setting about memory clock speed being a controllable setting, higher clock speeds needed for higher text resolutions, and if it was set too fast dots would crawl on the screen.
It's just text, small textures for the fixed width characters I assume.
Computer games were rendering millions of triangles a second over 20 years ago, even in software rendering engines.
If it's noticeably slow, there must be some unnecessary inefficiencies in there.
I use graphical VTE's like konsole though, which have way more than the in the article mentioned 128x40 characters, on a 4K screen, and I don't notice any slowdown in there at least, it can scroll as fast as you want, with full RGB color codes and unicode characters and 100K lines of scroll history.
If you compare to things like Kitty or other GPU accelerated terminals then you'll see the speed you're expecting, but that's not built into the kernel. There is work towards enabling that though via KMSCON but that's not ready for primetime yet.
Does this linear frame buffer have some very restricted bandwidth or something? On modern PC's? Don't all graphics card support VESA modes that are more than fast enough for graphics?
EDIT: as rightfully pointed out, in 1998 Unreal was not feasible at that resolution (it was playable in software mode though, and a 450 MHz pentium II existed). But in 2002 it definitely was for that game, which is also 20 years ago.
I did have a voodoo and similar at the time, with the VGA loop lead from the normal 2D card.
I didn’t howver have a working linux install in 1998, as my 2D card was an SIS62something or similar, which wasn’t really supported din redhat 5.2 or perhaps not redhat6. Throw in the issues with using minicom to dial the internet (pay per minute), and having to background it and then invoke pppd, all to use linx, meant I didn’t really do linux until about 2000 when I had the combination of hardware, software (Debian - potato I think) and games (railroad tycoon 2) to make it work.
The trouble is, unless we're talking about the operating system for a modern video game console, the kernel is not interested in re-architecting its graphics rendering for maximum throughput, it wants to keep things as simple as possible. That's partially because kernel code needs to be super-reliable, and also because (unlike a modern video game) it needs to support all kinds of output from modern high-end GPUs to simple memory-mapped bitmap displays to character-at-a-time serial ports, so lowest-common-denominator code wins.
In a classic 1990s PC, to write a character to the screen, the CPU can write a single byte directly into the text-display part of the VGA card's memory, and a fraction of a millisecond later the VGA hardware is looking up that byte in the character ROM and sending electrical pulses down the VGA cable.
In a modern PC, if the CPU wants to write a single character to the screen, it probably needs to write each pixel separately, each pixel is three or four bytes, and writing a pixel probably requires making a change to CPU RAM, preparing a command buffer, creating an "update texture" command, uploading the entire screen contents as the new texture, signalling to the GPU that a command buffer is ready, waiting for the GPU to signal that it's ready to receive, sending the command + data, and waiting for the GPU to signal that it's successfully received the data. And then the GPU actually has to draw the output into its own framebuffer, and send that to the monitor.
A modern PC can send all that data much more quickly than a 1990s PC could, but the 1990s PC is much simpler, so it has much less data to send.
The only way you could update the whole screen every frame on these computers was with hardware scrolling, in the style of Mario or Civilization.
With modern resolutions what they are, and 16-32 bpp color depths, combined with the unaccelerated dumb linear framebuffer you get with the console framebuffer drivers, it's quite slow relative to a classical VGA text mode.
Even if you still had the same number of lines and columns of text as a classical VGA text mode, just the higher dpi and bpp will still be a lot of bytes for the CPU to move around without any DMA or GPU to assist.
On top of that the VGA console driver in Linux used to exploit the hardware scrolling capabilities which basically just updated an offset register in the VGA instead of having to update the entire screen. IIRC you would lose your console scrollback history by switching virtual consoles because of this implementation. It was blazing fast but the VGA-resident contents were clobbered on VC switch.
Really ticks me off how the kernel is dropping stuff like scrollback for fast framebuffer devices, and since I got downvoted to hell the last time I said how slow and complicated certain finger-in-the-pie distros are making this area this time I'll post with a throw-away account.
[Also the title is ambiguous. While technically correct by referring to the kernel as Linux, I thought it originally meant GNU/Linux (the OS) because it didn’t say (e.g.) “consoles in the Linux kernel” or “consoles in GNU/Linux”]
I'm not incredibly familiar with sixels, but my basic understanding is that they're in a format that was convenient for use with dot matrix printers and were later adapted to terminal use with color support and such. This means that interacting with them is not going to be straightforward for developers familiar with any sort of modern graphics APIs on either the software or terminal ends.
If the main advantage is compatibility with old terminals that only really matter to a niche subset of retrocomputer enthusiasts I'd argue that any efforts to add graphics to the Linux terminal should be focused on a more modern design such as the base64-encoded images supported by a few terminals.
Something like Ascii85 or basE91 would have been even better, but beggars can't be choosers.
Have you checked out Chimera Linux? Should I refer to that system as “the Linux kernel” or “GNU/Linux”? Neither makes sense.
Personally, I find it the most sane to understand that “Linux” is the name of the kernel and a “Linux Distribution” is a curated collection of software that runs on the Linux kernel. GNU Software may or may not be involved.
For me, the whole “GNU/Linux” things has always felt desperate. It is a bit like the 70’s BSD guys says AT&T needed to call their software BSD/UNIX because so many people used BSD stuff on their systems.
There is a definitive list: https://www.gnu.org/software/
> Is Wayland? Is GNOME?
Wayland never was. GNOME was at one point but isn’t any longer.
> Have you checked out Chimera Linux? Should I refer to that system as “the Linux kernel” or “GNU/Linux”? Neither makes sense.
Neither, but it would be both accurate and more specific to say that it is a Linux-based OS with BSD’s userland.
> whole “GNU/Linux” things has always felt desperate.
It’s now “desperate” to ask to receive credit for software you wrote? GNU wrote coreutils and gcc and early GNOME and those are part of pretty much any early GNU/Linux system and you think giving GNU credit for the work they put into building an OS is ‘desperate’?? No offense but screw that.
> It is a bit like the 70’s BSD guys says AT&T needed to call their software BSD/UNIX because so many people used BSD stuff on their systems.
But the BSD guys never said that..that I can tell. Unless you can provide specific examples, I can only assume this is a straw man and ignore it.
This is possible on NetBSD: https://github.com/isaki68k/misc/blob/master/NetBSD/patch/x6...
Also, more and more terminals are getting Sixel support: https://www.arewesixelyet.com/
> On the other hand, text output to the console has generally gotten slower, usually much slower than you would expect for the change in console size
I don't see why we should tolerate slow rendering of text. Some of the techniques suggested by Casey Muratori (and recently used to accelerate text rendering in Windows Terminal) should also be usable in the framebuffer console.
But now it's higher-resolution, while being usable across a very wide variety of hardware, as long as the hardware supports some very simple frame buffer protocol. This is quite useful, because hardware became much more varied.