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?

5 Answers 5


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.

  • 1
    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 (cvs.schmorp.de/rxvt-unicode/doc/…), 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, 2009 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. Nov 15, 2009 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. Dec 1, 2009 at 22:31
  • 1
    Same situation in 2017. I believe kmscon is a userland terminal that tries to improve the terminal (including 24-bit color). Though its development has stagnated in favor of a systemd alternative.
    – jiggunjer
    Feb 24, 2017 at 3:48
  • kmscon has been forked and as of this post is being actively developed: github.com/Aetf/kmscon Sep 6, 2018 at 11:27

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
  • 1
    ~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, 2009 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. Nov 19, 2009 at 16:57
  • 1
    ~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, 2009 at 17:24

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!

  • Looks awful being compared to any of X terminal clients. Sep 24, 2014 at 18:09
  • 1
    It's running in a framebuffer so you only have the 256 colors available to the framebuffer anyway.
    – Seb
    Sep 25, 2014 at 15:54
  • Wondering if you have any insight into this fbterm problem? superuser.com/questions/892028/…
    – dtmland
    Mar 20, 2015 at 18:47
  • Running emacs inside tmux may help as it should translate escape sequences for the surrounding terminal.
    – Tom Hale
    Nov 18, 2018 at 15:08


kmscon is a way to get you 256 colors and video without having a windows system (X, Wayland) installed.

It was abandoned but is currently maintained via a fork.

Documentation on installation is slim, but the README page here should get you by.

I've installed this and use it for console apps that require 256 colors (vim due to my configuration).

Read the installation instructions carefully.


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.

  • 2
    Actually, it is possible. Otherwise I would not be able to use mutt with 256 colors in URxvt. :) See also push.cx/2008/256-color-xterms-in-ubuntu But how do I get the same effect in a TTY?
    – timn
    Nov 11, 2009 at 15:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.