[Linux] Limitations on patching /drivers/char/vt.c to support 256 colors
This has been nagging me since day 1 of using Linux. It was always a mystery to me why the tty device doesn't support 256 colors. Only recently, as I struggle to learn Linux, I started to go through framebuffers and terminal emulators and the works. Reading numerous threads on forums everywhere and trying to understand documentation didn't quite help me answer this question. Answers are usually derisive, or fleeting, and often indicating the person answering really doesn't know what they are talking about. The best I could ever get was that I would need to hack the kernel and do it myself. That's fair enough. But the question then becomes why haven't someone?
I finally got a break when I started reading on the kernel and understood(?) where to look for stuff. And that's where I am now.
I've been looking at drivers/char/vt.c like it was my wife for the past couple of days. But still can't quite understand it. The VT102 emulator it defines and that serves as the basis for the virtual terminal device puts no restrictions on color depth that I can see. Yet it defines only 16 colors through escape sequences.
What's been stopping a patch to support 256 colors? Framebuffers can support higher color depths. At a very minimum, 8 bit. It's a shame the virtual terminal upstream limits their reach.
The only thing I can think of is limitations on the very escape sequences. The current format doesn't abstract well a 256 color space. Especially because it's already partially used. I don't see how it could be extended into 256 colors and not be a mess. But couldn't a new one be devised with internal alias to the old one so it remained backwards compatible?