> How do you scroll up in the console???
Speaking of which:
#Linux dropped the #scrollback mechanism from its kernel #VirtualTerminals entirely, in version 5.9, released in September 2020.
The "Linux keyboard and console HOWTO" in the meanwhile is dated 1998.
There are quite a number of outdated StackExchange answers that haven't been corrected for the new reality, too. So it's not solely the #LinuxDocumentationProject that was written "weeks ago". (-:
There is a linux-16color terminal type in Dickey #terminfo. It has been there since 2009.
The #Linux KVT does not support more than the standard 8 colours, and some sleight of hand has been employed to get sort-of 16.
Unfortunately, the sleight of hand is broken.
If you've ever set TERM=linux-16colour and wondered at some strange scrolling and redraw artifacts, it is because the "op" capability doesn't undo the sleight of hand used by the setab/setaf capabilities.
For the first time, I had real problems with #upgrading my #Fedora #GNU #Linux operating system. I ended up getting a useless system (by which I mean, it would boot but would never give me a log in screen, like #sddm, nor would the #keyboard respond, except the power button and there were no #VirtualTerminals to log in to either).
Of course, Apple showed us how to have buttons and frames and menus (and even a mouse pointer) on a text display many years ago, and Unicode 13 has made that system possible once again.
X11 is not required in order to have a terminal emulator on a framebuffer. jfbterm, zhcon, and my console-fb-realizer all do so without X11.
This gave me an idea. Although the 8×8 fonts cannot be synthetically obliqued and boldfaced, because they are square, rectangular Ubuntu Mono can be.
So I can use #unscii PET for upright medium, unscii #BBCMicro for upright boldface, and #UbuntuMono for the oblique medium and boldface.
It works out fairly well.
The 8×8 #BBCMicro font from #unscii works rather better than Ubuntu Mono does, when rendering virtual terminals to the framebuffer with console-fb-realizer, I think. And the PET font from unscii works better still.
Some random terminal test programs.
The first is using 24-bit colour, which as you can see the #FreeBSD kernel built-in terminal emulator does not handle. The second is setting various ECMA-48 standard attributes. The FreeBSD kernel built-in terminal emulator does not handle most of those, either.
The small display size is down to the bloody awful buggy nVidia closed source framebuffer driver. I'm having to rely upon vesa(4) for now.
I can view the Japanese manual page for #yash (the Watanabe shell) in #FreeBSD.
It comes out as gibberish on kernel #VirtualTerminals. On user-space VTs it come out rather well. (This is what I want to screen grab.)
I fixed jfbterm and zhcon so that they work on FreeBSD again. Neither managed to display a UTF-8 Japanese manual page.
jfbterm is greeking everything, so just getting a font that works might well solve that. In zhcon the page comes out in the wrong encoding.
I want to screenshot a user-space VT being realized on the framebuffer.
There are three framebuffer dump programs that I know of: fbdump, fbgrab, and fbshot. None of them work on #FreeBSD, because its framebuffer device works in a different way.
So writing a program to dump the frame buffer it is, then.
It looks like PBM files are the easiest output format.
JdeBP
Khurram Wadee ✅