The article uses 32 bits per pixel to illustrate the growth in performance requirements:

> In framebuffer however, to fill a 4K UHD-1 (3840x2160) screen in 32bpp mode we need to send 3840 * 2160 * 4 bytes of data, which is 33177600 bytes (approximately 33 MB).

but I don't know if that is in fact the definition a "framebuffer console" versus a terminal that uses character addressing.

That's a different issue that actually supporting 32-bit ANSI codes, but I think it's an indication of the scope of a an effort to update the console implementation.

Some of the code linked in the article seems to emulate the VGA style text console (1 value for char value, 1 value for color and attributes) and render it onto a 32bit framebuffer.

The diffs that are attributed to Carmack seem to deal with this. scr->rs_bs[off].uc and scr->rs_bs[off].attr appear to represent the gylph and attributes/color respectively.

So I would expect that would severely limit the amount of colors available to the input buffer. OTOH I just found the declaration in the code and the attributes are 32 bits wide which is more than the 8 that VGA provides:

    struct wsdisplay_charcell {
       u_int       uc;
       uint32_t    attr;
    };

Note I would expect the 32 bits of attr to be divided between fg and bg color, and it seems like they carved out bits for things like underline.

Edit: after reading some more it seems like the color values range from 0-7.

32 bits isn't really enough. One uses 24 bits for RGB, and the remaining 8 bits aren't really enough for the remaining graphics renditions that a modern terminal emulator should support.

Factor in things like the KiTTY underlining system, invisible, the little-recognized new (sic!) ECMA-48:1991 graphic renditions (encircled, framed, and overlined), and strikethrough; and one actually needs 13 to 14 bits (depending from how far one takes the KiTTY underlining system).

Moreover: No-one doing this style of terminal emulator really does Unicode properly. To do so actually involves having a string of one or more code points per cell, not simply exactly one. Some of the terminal emulators based upon external GUIs (e.g. X11) do do that, or approach it. (Although at the same time they take a giant leap backwards from video terminal semantics to paper terminal semantics, so it is a matter of swings and roundabouts. See https://unix.stackexchange.com/a/593613/5132 .)

> 32 bits isn't really enough. One uses 24 bits for RGB,

Yes, and as I mentioned you need to divide between FG and BG colors.

All a little moot because it seems to me like the code uses 3 bits for color.

> No-one doing this style of terminal emulator really does Unicode properly

Indeed, both multi-char and multi-codepoint glyphs. I also think the whole "matrix of glyphs" thing breaks down pretty severely when you want BiDi support for instance. The article mentions someone working on UTF-8 support. I wonder what that looks like.

The "I" in "ITU" does not stand for "ANSI". (-:

* https://itu.int/rec/T-REC-T.416

As M. Kochkov will attest, supporting 24-bit RGB (or even 32-bit ARGB) colour involves (a) recognizing and processing the new (sic!) control sequences from the 1990s, and (b) actually supporting having the display hardware in a non-palettized true colour mode (as opposed to using a 256-colour palettized mode and pretending).

The definition of a framebuffer virtual terminal is, rather, that the display hardware is in its graphics mode rather than its text mode. (This was the norm for some architectures, which didn't even have text mode display hardware. But the MDA/Hercules/CGA/EGA/VGA on the IBM PC and compatibles did.) The operating system, that is providing the virtual terminal, draws the glyphs by manipulating pixels, rather than relying upon "character generation" hardware to do it in the video output stage of the adapter.

I expect none of this (text mode, indexed colors, 16 bpp, hardware GDI/2D etc.) actually exists in hardware any more. I expect GPUs emulate all of this through shaders baked into the VBIOS/driver.

I doubt that very much. I cannot see people successfully making a business case to spend development time and money re-implementing MDA/CGA/EGA/VGA text mode, with the concomitant on-going support costs when inevitably the re-implementation misses stuff, for pretty much zero additional revenue. No, this wouldn't be implementable through drivers. It has to work during POST and IPL.