Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

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?


  • 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):

       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:

       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
share|improve this answer
~quack this all awesome information but I'm unsure it'll lead to success. You say "Yes" but then say "experiment" and "if you find one". I took a more direct route; I searched the kernel code. I've not been able to find any code that handles escape sequences for color - ANYWHERE in the kernel. Not in the fb code, not in the tty code... nowhere. Thus my conclusion that it's handled in the BIOS. This is supported by my memories of using the exact same ANSI escape sequences under DOS. I believe the various ANSI escape sequences are being handled by the BIOS in both cases. – pbr Nov 19 '09 at 16:12
@pbr: i checked out the kernel code as well. TTY code doesn't place any limits on the number of colors. BIOS doesn't enter into it -- you're dealing with the framebuffer, which can take various bitdepths (specifics are hardware dependent, tho if you've disabled the framebuffer ...). the 16-color limitation may be in GeTTY, thus the recommendation to check out Qingy, or may be in the terminfo stuff, thus the recommendation to try various alternate TERM definitions. i can't advise beyond that, but your BIOS ranting is off-base and not helpful. – quack quixote Nov 19 '09 at 16:57
~quack - you're right that it's not in the BIOS (see my revised answer below) but still off in recommending investigating Qingy et al. The virtual terminal code is hard-coded with vt102 emulation. – pbr Dec 1 '09 at 17:24

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.

share|improve this answer
That's right. I am talking about these "low-level virtual terminals". But since I am using the framebuffer, it is the fbcon kernel module that is being employed I think. See Documentation/fb/fbcon.txt. Or is fbcon just a wrapper around n_tty adding some additional features? Looking at the URxvt patch (…), it seems to be fairly easy to extend the 256-color support. I am not quite certain whether n_tty is the right kernel module as I do not see any color definitions there. – timn Nov 14 '09 at 22:52
i think the framebuffer is one device, and the tty is another -- the virtual terminal requires the tty device, and those use the framebuffer as a display device, but the framebuffer isn't the only possible display device. – quack quixote Nov 15 '09 at 4:04
+1 this sounds more likely (vt102 not supporting the extended colors, and the terminal driver hard-coded to vt102 emulation). nice bit of research. – quack quixote Dec 1 '09 at 22:31

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:

However, mplayer should work!

share|improve this answer
Looks awful being compared to any of X terminal clients. – phil pirozhkov Sep 24 '14 at 18:09
It's running in a framebuffer so you only have the 256 colors available to the framebuffer anyway. – Seb Sep 25 '14 at 15:54
Wondering if you have any insight into this fbterm problem?… – dtmland Mar 20 '15 at 18:47

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.

share|improve this answer
Actually, it is possible. Otherwise I would not be able to use mutt with 256 colors in URxvt. :) See also But how do I get the same effect in a TTY? – timn Nov 11 '09 at 15:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .