TTY with 256 colors?

Question

With URxvt and xterm it is possible to use a virtual terminal supporting 256 colors instead of only eight. Since my Intel GMA graphics card is well-supported by the KMS framebuffer driver, I am exclusively working on the TTY. Unfortunately it only supports eight colors although with MPlayer (-vo fbdev/fbdev2) and other framebuffer tools far more can be addressed. Is there a way to tell the TTY to use more than eight colors?

Answer 1

Your 256-color RXVT/xterm/URXVT/etc are defined by terminfo and the setting of the TERM variable. In most Linux distributions your virtual terminals are defined in /etc/inittab, and use a default terminal type that defines how many colors the terminal can use.

Is there a way to tell the TTY to use more than eight colors?

Yes.

• Make sure your framebuffer is using the correct resolution/bit depth. Try adding vga=773 to the kernel options, for example, to get 1024x768 and 256-color (8-bit color depth).

• Set a different TERM (eg, export TERM=foo). You'll need to experiment to find the right one. If you find one that works, you can modify your /etc/inittab so that your virtual terminals run it by default (see next section).

• This article discusses other options that may work for you. It recommends Qingy (Qingy is not GettY) as a getty replacement, and may give you what you're looking for if switching TERM variables isn't an option.

• Speaking of getty replacements, I swear I've seen instructions for replacing getty with GNU screen somewhere along the way. I'm not finding the link at the moment, but since there is a 256-color TERM for screen, you might look into it.

---

/etc/inittab uses lines like this to setup virtual terminals:

# Format:
#  <id>:<runlevels>:<action>:<process>
#
1:2345:respawn:/sbin/getty 38400 tty1
2:2345:respawn:/sbin/getty 38400 tty2
3:2345:respawn:/sbin/getty 38400 tty3

Here's the manpage on /sbin/getty (from my Debian system, so it's technically the agetty program):

SYNOPSIS
       agetty [-8ihLmnw] [-f issue_file] [-l login_program] [-I init]
       [-t timeout] [-H login_host] baud_rate,...  port [term]

Note the baud_rate,... port [term] there at the end. That matches up with the command in the /etc/inittab line (/sbin/getty 38400 ttyN) -- note there's no [term] argument, so we get a default (run echo $TERM just after you log in on a virtual console to see what your system uses). From the manpage again:

ARGUMENTS
       term   The value to be used for the TERM environment variable.  This  over‐
              rides  whatever  init(8) may have set, and is inherited by login and
              the shell.

If you find a TERM that works, modify the getty lines in your inittab and add the proper TERM at the end:

1:2345:respawn:/sbin/getty 38400 tty1 TERM-with-256-colors
2:2345:respawn:/sbin/getty 38400 tty2 TERM-with-256-colors

Answer 2

I'm revising my answer now that I'm sure of things.

It was erroneous to conclude that the ANSI sequences were being handled via BIOS or otherwise outside of the kernel; indeed, they're handled in the kernel. I found what I had missed before thanks to hnaz_ on the LinuxNewbies IRC channel: drivers/char/vt.c implements an emulation of a Digital Equipment VT102 terminal which is used by the virtual terminal driver.

So... as a definitive answer, having reviewed the source code that handles the escape sequences for virtual terminals: If you want 256 color support on virtual terminals you'll have to build you own kernel after extending the code that parses the escape sequences to handle the wider color-specification.

The function is called csi_m(). The changes will have to be similar to those which extend the X-based terminal emulators to handle escape sequences specifying the richer color codes. There will probably be other changes needed as well, but this is where you would start.

Answer 3

The ANSI escape sequences for setting the foreground and background colors of text are what's limiting things here.

From memory these sequences look something like escape [ 01;34m There are codes in the 30's for foreground and I think 40's for background.

So I don't think there's any way to achieve what you're looking for.

Answer 4

Have a look at fbterm - it's a replacement framebuffer that can run in 256-color mode (you just run it as root from a TTY)

I've had mixed success with it - some applications work fine, and report 256 colors; however Emacs (the main reason I wanted 256 colors on TTY) doesn't seem to work; there's a bit of a discussion about it here, but it doesn't really get resolved:

http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00989.html

However, mplayer should work!