I think the parent poster's point was that the Linux console framebuffer renderer in particular, is not a particularly full-featured terminal in terms of the SGR sequences it supports. Which can be slightly unpleasant when you're stuck working in "text" (really, console framebuffer) mode in Linux for whatever reason.
(Which makes me wonder: is there a way to tell Linux to not use its own console framebuffer driver for displaying TTYs, but rather to instead spawn some userland libsdl binary and connect it to the raw framebuffer? If so, we could presumably just drop in a fully-featured terminal emulator to act as the Linux console.)
> is there a way to tell Linux to not use its own console framebuffer driver for displaying TTYs, but rather to instead spawn some userland libsdl binary and connect it to the raw framebuffer?
That's almost how frecon (and kmscon/systemd-consoled before it) works.
Cool, that's exactly the type of thing I was picturing.
Is this used or packaged in any major Linux distribution besides ChromiumOS? I'd like to try out living inside this for a while (probably in a fullscreened VM) but CrOS is a bit too restrictive/unfamiliar as a userland for me to want to attempt it there. I guess Crouton exists, but I'd be afraid that Crouton would add an additional layer of impedance-mismatch to the VT that isn't there when just using it raw (like the kind you get when using tmux-in-ssh-in-tmux.)
I seem to recall there being an fbdev-based terminal emulator that does just take over a VT, maybe it was this one: https://www.systutorials.com/docs/linux/man/1-fbterm/ but searches show a couple of possibilities.
I'm not sure how it works with systemd, but back in init land you could just replace the getty lines in /etc/inittab with whatever you wanted to use on that VT, or replace the default login command. What you wonder should be possible.
Source: Quite a long time ago I believed that the Linux framebuffer was the future of development, and spent a lot of time making animated bootup sequences, custom login screens, writing libraries (in collaboration with others) to make development easier without having to go into a "framework" like DirectFB, and using elinks (or was it links2?) for browsing and fbi for image and PDF viewing.
> Quite a long time ago I believed that the Linux framebuffer was the future of development
Hey, most of the Linux-based "retro portables" are running a pure "libsdl with Linux framebuffer backend" userland. So it was at least the future of something.
I did a little digging into the VGA text mode hardware interface and it'd be possible to do proper bold and italics support by loading a second font and reusing the line drawings (which shouldn't italicize) and block graphics (that shouldn't bold) for additional styled symbols. Computing bold is a simple matter of OR'ing a bit-shifted character and, for italics, you can shift the top third one bit to the right and the bottom third one bit to the left. We used to do that in the 8-bit era when having three bitmap fonts took too much disk space.
I believe it was links. It had numerous backends from what I recall, to include fb, X, and maybe even svgalib. I don't recall elinks supporting any of that. But I could be wrong.
(Which makes me wonder: is there a way to tell Linux to not use its own console framebuffer driver for displaying TTYs, but rather to instead spawn some userland libsdl binary and connect it to the raw framebuffer? If so, we could presumably just drop in a fully-featured terminal emulator to act as the Linux console.)