terminal resources

The virtual terminal subsystem requires various resources.

keyboard maps

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.

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

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):

input methods

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:

hiragana

This 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.

katakana

This 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-x11

This 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.