Coming from Linux, you'll be thinking that there's not much difference betwenn the kernel virtual terminal system provided by Linux (yes, the actual kernel) and what you get on the BSDs. Superficially, that's seemingly the case. After all, they all do what SCO Xenix MultiScreen was doing in 1986: providing multiple virtual terminals each with their own login sessions that one can switch amongst using ⎇ Alt+Fn keychords.
But upon closer inspection, things turn out not to be quite as similar.
The BSDs fall into two major categories when it comes to KVTs. OpenBSD and NetBSD use a long‐established system called wscons. FreeBSD went its own way with first a KVT system called syscons, which was replaced, but not wholly, in FreeBSD 10 with a new KVT system called vt.
Unlike the Linux KVT system, the wscons system builds up kernel virtual terminals with commands issued by application‐mode utilities at system bootstrap.
A boot‐time single‐shot service named wscons processes /etc/wscons.conf and according to what is specified there runs various utilities (wsconsctl(8), wsconscfg(8), and wsfontload(8)) to actually create kernel virtual terminals, set what emulation modes they are running in, attach the desired keyboard/mouse/multiplexor devices, and load their individual fonts into kernel memory.
They don't actually exist as far as the kernel is concerned, and attempts to open their device files will fail with an error, until application‐mode utilities create them.
Unlike the Linux KVT system, KVTs come in blocks of 8: /dev/ttyE[0-7], /dev/ttyF[0-7], /dev/ttyG[0-7], and so on.
Unlike on Linux, control programs do not arbitrarily open a KVT device file and send it ioctl() commands to do KVT‐wide things.
Instead, there are separate control devices for each block: /dev/ttyEcfg, /dev/ttyFcfg, /dev/ttyGcfg, and so on.
Unlike the Linux KVT system, there's no pretence made that it is anything like X11.
wscons does not pretend to share keyboard layouts with X11, as Debian does with /etc/default/console-setup.
wscons keyboard layouts aren't even stored in files, mostly.
They are compiled into the kernel itself, and picked by setting the encoding setting with wsconsctl(8).
Unlike the Linux KVT system, syscons(4) and vt(4) have clearer roots in SCO Xenix MultiScreen. (Linux has those roots, too. They are just more obscured.) The kbdmap(5) file format is identical to the one used by SCO Xenix, and SCO's own keyboard(HW) manual page from the SCO Administrator's Reference (going back at least as far as the 1993 edition) does a better job of explaining that file format than even FreeBSD's manual does.
Unlike the Linux KVT system, the two configuration utilities for KVTs are kbdcontrol(1) and vidcontrol(1).
The manuals lead you to believe that you can switch video modes at runtime with vidcontrol.
Although prior to FreeBSD 10 this was possible (I did it myself on PC-BSD 9.), the reality is that both the proprietary NVidia framebuffer device driver and the new vt system break vidcontrol's ability to mode switch, and in practical terms one sets the video mode in /boot/loader.conf.local (c.f. loader.conf(5)) with the kern.vt.fb.default_mode kernel environment variable (yes, the FreeBSD kernel has its own environment variables that control things — another difference from Linux, c.f. kenv(1)) before the kernel is loaded, and that video mode is fixed thereafter.
I would have said that, like the Linux KVT system, FreeBSD's KVT system has its own idiosyncratic font file format that no‐one else uses; were it not that I wrote a user‐space virtual terminal system for FreeBSD (and NetBSD and OpenBSD and Linux‐based operating systems) and I simply re‐used the FreeBSD vt font format.
(Why invent yet another font file format? I saw no reason to.)
As the aforelinked nosh Guide explains, the vtfontcvt(8) utility is both decidedly iffy (having some strange defaults and very poor error handling) and only available on FreeBSD.
One of these days, perhaps someone will do the obvious thing and add a portable hex2vtfnt tool to GNU Unifont to go alongside all of its other hex2* tools.
That's really the proper place for such a tool.
© Copyright 2026
Jonathan de Boyne Pollard.
"Moral" rights asserted.
Permission is hereby granted to copy and to distribute this web page in its original, unmodified form as long as its last modification datestamp is preserved.