The virtual terminal subsystem requires various resources.
On systems with /usr/share/vt/keymaps/ (such as FreeBSD), the external formats conversion subsystem takes the old-style SCO/FreeBSD kernel virtual terminal keyboard maps from there and generates a range of keyboard map files suitable for console-fb-realizer by passing them through console-convert-kbdmap.
The original maps are converted with some modifications supplied by overlay map files:
soft_backspace.kbd
The DEC VT backspace ⌫ key is actually programmable with the DECBKM control sequence.
The FreeBSD keyboard maps hardwire the mapping from the backspace ⌫ keycode to the DEL and BS control characters, and if used as they stand would prevent the key from being soft-switchable.
This overlay replaces that with a mapping to the bspace action, letting console-terminal-emulator handle the mapping to control characters in concert with the DECBKM setting.
soft_delete.kbd
The XTerm delete ⌦ key is actually programmable with the DECSM/DECRM 1037 control sequences.
The FreeBSD keyboard maps hardwire the mapping from the delete ⌦ keycode to the DEL control character, and if used as they stand would prevent the key from being soft-switchable.
This overlay replaces that with a mapping to the delete action, letting console-terminal-emulator handle the mapping to control characters in concert with the DECSM/DECRM 1037 setting.
soft_enter.kbd and soft_return.kbd
Likewise, these replace hardwired FreeBSD mappings, from the return ⮠ and enter keys to the CR and LF control characters, with the return and enter actions.
The DEC VT enter key is actually programmable with the DECNKM control sequence.
The enter action lets console-terminal-emulator handle the mapping to control characters in concert with the DECNKM setting.
The return action ensures that the return key can be distinguished from a CR or LF control character in input messages.
jp_to_jp.104.kbd
jp_to_jp.109.kbd
The FreeBSD keyboard maps usually apply to all of the Model M/Windows keyboards invariantly. Overlays such as this are per-country per-keycount fixes for various things.
The FreeBSD jp.kbd keyboard map maps the "Grave" key (engraved with Zenkaku/Henkaku/Kanji on the JIS 109-key keyboard) to the ESC control character.
jp_to_jp.109.kbd fixes it for 109-key keyboards to instead map the "Grave" key to the "IM Switch" input event that activates and deactivates the input method front-end processor.
jp_to_jp.104.kbd fixes it for other keycount keyboards to instead map the "Grave" key to what the "International3" key does on 109-key keyboards.
On systems where there is no /usr/share/vt/keymaps/, the external formats conversion subsystem generates a (narrower) range of keyboard map files by overlaying the default null map, U.S. International, built into console-convert-kbdmap with map files that provide just the differences between U.S. International and other layouts rather than entire maps as come with FreeBSD.
For example:
default_to_uk.kbd is the difference between U.S. International and U.K. International.
The generated keyboard maps are placed in /etc/system-control/convert/kbdmaps/ and can be linked to the service directories of, or simply used directly by, any keyboard device user-space virtual terminal realizer services.
Their names follow a regular pattern comprising the ISO country code, the PC Windows keyboard variant (i.e. 104, 105, 106, 107, or 109), and any options such as .capsctrl for maps generated with the swap_capsctrl.kbd overlay that swaps the capitals lock ⇬ and control ⎈ keys.
Fonts suitable for console-fb-realizer have to be in the "vt" format of FreeBSD.
BDF fonts can be converted to this format with FreeBSD's vtfontcvt tool, as long as they are (arbitrarily) limited to 8 or 16 pixel-wide bounding rectangles.
(This unfortunately prevented FreeBSD's vtfontcvt until 2019 from being able to convert Ubuntu Monospace, which has varying-sized bounding rectangles for individual characters.)
Useful monospace fonts that can be obtained and converted to "vt" format (sometimes by converting to BDF format first, using tools like Jan Engelhardt's fnt2bdf):
vgarom-8x16 is a "vt" font that comes in the box with FreeBSD, purportedly taken from VGA ROM firmware of a PC compatible. It only has a small glyph repertoire.
Ed Maste also produced a small repository of "vt" fonts for FreeBSD's "vt" subsystem.
k16-1990.bdf is a square 16×16 pixels JISX0208.1990 font with many CJK glyphs.
Markus Kuhn's -misc-fixed- fonts, especially 9x15 and 9x15B, have a fairly wide coverage of the BMP. They come in BDF form.
Dmitry Yu. Bolkhovityanov's Unicode VGA is based upon the vga.bdf in XDosEmu. It covers much of the BMP, but none of the supplementary Unicode planes.
Hugo Chargois's GoHuFont is partly based upon Markus Kuhn's, and comes in BDF form.
Uwe Waldmann's UW ttyp0 covers only some of the BMP. It comes in BDF form.
GNU Unifont has extensive glyph coverage of Unicode. It is in a "hex" file format that needs first to be converted to BDF.
Ville-Matias Heikkilä's unscii-16 font takes inspiration from personal and home computer 8×8 and 8×16 fonts, and is available in the same "hex" file format as GNU Unifont.
Joseph Gil's fntcol16.zip package is a collection of VGA firmware and MS/PC-DOS fonts. The fonts are in an idiosyncratic format that first must be converted to BDF and mapped to the relevant Unicode code points.
IBM PlexMono in "vt" font form.
console-input-method is table-driven.
The tables that it uses are the same CIN data files as are used by xcin, gcin (GitHub), jscin (GitHub), hime (GitHub), PIME (GitHub), OpenVanilla (GitHub), Chinese Open Desktop (GitHub), OkidoKey.app (GitHub), and MacOS.
Some operating systems supply snapshots of some of these collections as packages, such as Debian's openvanilla-imgeneric-data-all package for example.
The CIN file collections supplied with each software do not exactly overlap, and some are more up-to-date than others, but taken as a whole they range from Esperanto input helpers through Pinyin and Katakana to Hanja. The nosh toolset does not provide yet another collection to augment the mess. Rather, one should pull the CIN files from these collections. There are three exceptions:
hiraganaThis data table provides an input method for Hiragana, encoding everything explicitly in the data table itself, including gemination of consonants for sokuon. It incorporates only Nihon-shiki and Kunrei-shiki, and is case-insensitive.
katakanaThis data table provides an input method for Katakana and symbols, encoding everything explicitly in the data table itself, including gemination of consonants for sokuon and gemination of vowels for chōonpu. It is a grab-bag mixture of Nihon-shiki, Kunrei-shiki, Hebon-shiki, Hyoojun-shiki, old ANSI/BS standards, and unofficial but common stuff (such as an "l" prefix for little kana). It also incorporates ASCII spellings for punctuation and symbols, such as "hakko" for various sorts of brackets, and is case-insensitive.
romaji-x11This data table incorporates a subset of the Xlib compose key sequences, not duplicating Xlib sequences that are available in other ways on user-space virtual terminals. (For examples: Many of the combining diacritics are already a standard part of the keyboard map, in the common secondary group, because of ISO 9995-3. Hangeul and Kana are already directly available via other input methods dedicated to them.) It is suitable for use as a "romaji" input method alongside CJKV input methods.