I installed FreeBSD 11.2 on my DELL Latitude E7470 with UEFI (might be important). By default it does not install a GUI and that is fine by me (for now). Using the <Alt>+<Fn> keys I can switch between different virtual terminals.

I cannot change the colors with vt

I tried with the following in /boot/loader.conf but this had no effect:

i915kms_load="YES"
kern.vt.color.1.rgb="#cc241d"
# definitions for all other colors follow but omitted in this example

Additionally, I changed /etc/ttys to set xterm-256color in the third column instead of xterm but this does not enable 256 color support.

I want to stress that I want to change the number of colors when locally accessing the computer via its own keyboard and monitor in text mode (no gnome, Xorg, KDE...). Accessing the computer over SSH is something completely different.

FreeBSD console imitates xterm using teken (see earlier discussion here, and mailing list). It is not a complete implementation; the FreeBSD developers have trimmed out a few items from the terminal description (making the real xterm less useful on that platform).

FreeBSD console (teken) doesn't actually implement 256 colors. See the source-code:

499 /**
500 * The xterm-256 color map has steps of 0x28 (in the range 0-0xff), except
501 * for the first step which is 0x5f. Scale to the range 0-6 by dividing
502 * by 0x28 and rounding down. The range of 0-5 cannot represent the
503 * larger first step.
504 *
505 * This table is generated by the follow rules:
506 * - if all components are equal, the result is black for (0, 0, 0) and
507 * (2, 2, 2), else white; otherwise:
508 * - subtract the smallest component from all components
509 * - if this gives only one nonzero component, then that is the color
510 * - else if one component is 2 or more larger than the other nonzero one,
511 * then that component gives the color
512 * - else there are 2 nonzero components. The color is that of a small
513 * equal mixture of these components (cyan, yellow or magenta). E.g.,
514 * (0, 5, 6) (Turquoise2) is a much purer cyan than (0, 2, 3)
515 * (DeepSkyBlue4), but we map both to cyan since we can't represent
516 * delicate shades of either blue or cyan and blue would be worse.
517 * Here it is important that components of 1 never occur. Blue would
518 * be twice as large as green in (0, 1, 2).
519 */

Those steps map application's attempts to use 256 colors onto the console's 16 colors.

Since it's not capable of doing what's asked, setting TERM to xterm-256color will not be very effective.

The rgb code is supported in a different part of the kernel, which lets one set the values in the (16-)color palette:

41 static struct 
42 unsigned char r; /* Red percentage value. */
43 unsigned char g; /* Green percentage value. */
44 unsigned char b; /* Blue percentage value. */
45 color_def[NCOLORS] = 
46 0, 0, 0, /* black */
47 50, 0, 0, /* dark red */
48 0, 50, 0, /* dark green */
49 77, 63, 0, /* dark yellow */
50 20, 40, 64, /* dark blue */
51 50, 0, 50, /* dark magenta */
52 0, 50, 50, /* dark cyan */
53 75, 75, 75, /* light gray */
54 
55 18, 20, 21, /* dark gray */
56 100, 0, 0, /* light red */
57 0, 100, 0, /* light green */
58 100, 100, 0, /* light yellow */
59 45, 62, 81, /* light blue */
60 100, 0, 100, /* light magenta */
61 0, 100, 100, /* light cyan */
62 100, 100, 100, /* white */
63 ;

In the mailing list, I mentioned these screenshots:

As M. Dickey says, the FreeBSD kernel's built-in terminal emulator simply does not have either indexed or 24-bit direct colour support. Really, one should not treat it as xterm at all, and this is yet another case of the xterm terminal type being the wrong thing to use. It is quite significantly different from actual XTerm in this and other respects.

The terminfo database record for it uses the name teken. I have a teken termcap entry which I add to FreeBSD termcap. With these the TERM environment variable value can be set to its proper value of teken, not xterm or xterm-256color.

I ship my termcap entry with the nosh toolset, in the nosh-bundles binary package. It is set up by the external configuration import subsystem, which uses cap_mkdb to create a combined termcap database (which also includes additions for interix and linux) in /etc/system-control/convert/termcap/termcap.db, which can be symbolically linked from /etc/termcap.db. Or one can use the raw constituents in /etc/system-control/convert/termcap/ to make a termcap database by hand onesself.

It also has a teken-256color entry. This isn't for the FreeBSD terminal emulator. It is for my terminal emulator, that provides a superset of teken that includes indexed and 24-bit direct colour capabilities amongst other things. It is designed to be faithful to teken for the most part, that extending even to employing the same undocumented admixture of DECFNK and Xenix Console function key sequences that the FreeBSD terminal emulator actually generates.

JdeBP % console-decode-ecma48 
^[OP^[OQ^[OR^[OS^[OT^[[17~^[[18~^[[19~^[[20~^[[21~^[[23~^[[24~
DEC KEY_PAD_F1
DEC KEY_PAD_F2
DEC KEY_PAD_F3
DEC KEY_PAD_F4
DEC KEY_PAD_F5
DEC F6
DEC F7
DEC F8
DEC F9
DEC F10
DEC F11
DEC F12
LF
^[[Y^[[Z^[[a^[[b^[[o^[[p^[[q^[[r^[[^^[[_^[[`^[[{
SCO Level2+F1
SCO Level2+F2
SCO Level2+F3
SCO Level2+F4
SCO Control+F5
SCO Control+F6
SCO Control+F7
SCO Control+F8
SCO Control+Level2+F9
SCO Control+Level2+F10
SCO Control+Level2+F11
SCO Control+Level2+F12
LF
JdeBP %

One of its uses is as a user-space replacement for the FreeBSD kernel terminal emulator that does not require X11, rendering to the framebuffer and reading input from keyboard and mouse HIDs. The same colour cube as in M. Dickey's answer looks somewhat different:

Because it is user-space, rather than built in to the kernel, it can afford to include multiple-font Unicode support, CIN-file-driven CJKV input methods, and compatibility with other built-in kernel terminal emulators, including the Linux one (hence the similarly enhanced linux termcap entry).

If you want more than 16 colours without X11, my terminal emulator or one of the several other full-screen framebuffer terminal emulators is the route that you have to take.

Further reading

• Jonathan de Boyne Pollard (2015). "256-colour and 24-bit True Colour support". A quick look at user-space virtual terminals. nosh toolset. Softwares.


• Jonathan de Boyne Pollard (2018). Japanese input methods in nosh user-space virtual terminals. nosh toolset. Softwares.


• Jonathan de Boyne Pollard (2018). "console-decode-ecma48". nosh Guide. Softwares.


• https://unix.stackexchange.com/a/177209/5132


• https://unix.stackexchange.com/a/303767/5132