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
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,335
- 1
- 7
- 14
-
1That'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 (http://cvs.schmorp.de/rxvt-unicode/doc/urxvt-8.2-256color.patch?view=markup), 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 04: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 01 '09 at 22:31
-
1Same 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 '17 at 03:48
-
kmscon has been forked and as of this post is being actively developed: https://github.com/Aetf/kmscon – user3751385 Sep 06 '18 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?
Yes.
Make sure your framebuffer is using the correct resolution/bit depth. Try adding
vga=773to 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/inittabso 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 screensomewhere along the way. I'm not finding the link at the moment, but since there is a 256-color TERM forscreen, 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
- 42,186
- 14
- 105
- 129
-
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 '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
-
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 01 '09 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:
http://lists.gnu.org/archive/html/emacs-devel/2011-08/msg00989.html
However, mplayer should work!
- 410
- 3
- 6
-
-
1It'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? http://superuser.com/questions/892028/fbterm-expected-behavior-at-launch – dtmland Mar 20 '15 at 18:47
-
Running `emacs` inside `tmux` may help as it should translate escape sequences for the surrounding terminal. – Tom Hale Nov 18 '18 at 15:08
kmscon
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.
- 210
- 2
- 5
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.
- 1,335
- 1
- 7
- 14
-
2Actually, it is possible. Otherwise I would not be able to use mutt with 256 colors in URxvt. :) See also http://push.cx/2008/256-color-xterms-in-ubuntu But how do I get the same effect in a TTY? – timn Nov 11 '09 at 15:52