> nonsense. the poster's asserting that there's a lot of color tty
> handling code in the kernel. offhand, I suspect it's smaller than
> he thinks (just as the split-the-kernel whiners thing that the other
> architectures take up significant space.) but he's right about one
> thing: it should probably be in some shared library, rather than
> in the kernel.
Complete nonsense. This is something you cannot (reasonably) do with
library code.
What you _can_ do with library code, is already done so - see ncurses.
To do the rest, you'd have to directly access the video memory from that
library. All output to the screen would have to be special-cased to go
through that library. The idea is completely insane.
As to it being not much code, in that you are correct. Have a look at it.
Color support in a text screen driver is trivial to do. It's no more
difficult than support for other attributes, like brightness or
underlining. You need to have a current attribute value anyway, the
hardware wants to see it.
MfG Kai