4 ms·
The "I" in "ITU" does not stand for "ANSI". (-: * https://itu.int/rec/T-REC-T.416 https://itu.int/rec/T-REC-T.416 As M. Kochkov will attest, supporting 24-bi
by JdeBP 6y ago
The "I" in "ITU" does not stand for "ANSI". (-:
* https://itu.int/rec/T-REC-T.416 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.
- formerly_proven 6y agoI 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.
- JdeBP 6y agoI 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.