Migrating Linux Virtual Consoles to kmscon: Configuration and Trade‑offs

on

By the end of this guide the reader will be able to replace the legacy kernel framebuffer console (fbcon) with the userspace kmscon utility, understand its architecture, configure common options, and evaluate the impact on server or workstation workloads.

Understanding kmscon and Its Relationship to the Traditional Console

The traditional Linux virtual console is driven by the kernel‑space fbcon driver. fbcon writes directly to the framebuffer, handles font rasterisation, and processes keyboard layout tables inside the kernel. Because all of these responsibilities reside in kernel space, any change to the console subsystem requires a kernel rebuild or a reboot to apply new settings. Moreover, fbcon is limited to the bitmap fonts supplied by the kernel and offers no native support for modern font rendering libraries.

kmscon moves the console stack into userspace. It creates a kmscon daemon that opens the DRM/KMS (Direct Rendering Manager / Kernel Mode Setting) device, draws text using a selectable font engine, and forwards input events to the login manager. By operating outside the kernel, kmscon can be updated, reconfigured, or replaced without recompiling the kernel. The architecture also enables optional sub‑packages, allowing minimal installations on headless servers while providing richer graphics support on workstations.

Installing and Enabling kmscon

Fedora provides kmscon as a set of packages. The base package supplies the daemon and essential dependencies; optional packages add support for additional font engines such as Pango or extra font collections.

To install the core components, run:

sudo dnf install kmscon

If advanced font rendering is required, install the corresponding sub‑packages, for example:

sudo dnf install kmscon-pango kmscon-freetype

After installation, enable the kmscon service so that it starts on boot and replaces fbcon:

sudo systemctl enable --now kmscon.service

The command creates a systemd unit that launches the kmscon daemon during early boot, before any graphical session starts. To revert to the legacy console, stop and disable the service, then reinstall the fbcon kernel module if it has been removed.

Configuration File Overview

kmscon reads its settings from /etc/kmscon/kmscon.conf. A default example is shipped with the package and can be copied for modification:

sudo cp /etc/kmscon/kmscon.conf.example /etc/kmscon/kmscon.conf

The configuration file follows a simple key‑value syntax. The most frequently adjusted options are described below.

Logging and Diagnostics

The verbose flag enables detailed logs useful when troubleshooting display or input issues. Set it to yes to increase output, then view the journal with:

journalctl -u kmscon.service

Logs are stored in the standard systemd journal; no separate log files are created.

Font Engine Selection

kmscon supports three font engines:

  • freetype – uses the FreeType library; preferred when TrueType or OpenType fonts are available.
  • pango – provides advanced text layout and internationalisation support.
  • psf – legacy bitmap font format used by the kernel.

The font-engine key selects the engine. If the chosen engine is unavailable, kmscon falls back to unifont.

Specifying the Font

The font-name option identifies the font to render. For FreeType and Pango, the value must match the name reported by fc-list. Example:

fc-list | grep -i cascadia

Because kmscon runs as root, the font file must reside in a system directory such as /usr/share/fonts. Installing a font package makes it available system‑wide:

sudo dnf install cascadia-fonts-all

For bitmap fonts, provide the absolute path to the .psf file, e.g., /usr/share/kmscon/fonts/Lat2-Terminus16.psf.

Adjusting Font Size

The font-size key defines the height of each character in pixels. kmscon attempts to choose a size that yields roughly 120 columns by 40 rows on the primary monitor. To enforce a specific size, set an integer value, for example:

font-size=16

Multi‑Monitor Behaviour

When multiple monitors are attached, kmscon can operate in three modes controlled by the multi-monitor key:

  • scaled (default) – scales the font to minimise black borders on each screen.
  • clone – centres the terminal on every monitor, showing identical content.
  • largest – uses only the monitor with the greatest resolution for the console.

Select the mode that matches the intended workflow; for headless servers with a single display, the default is sufficient.

Power Management

The dpms-timeout option sets the interval, in seconds, after which the monitor powers down due to inactivity. The default of 600 seconds (10 minutes) balances energy savings with usability. To disable DPMS entirely, set the value to 0:

dpms-timeout=0

Mouse and Touchpad Interaction

On laptops, accidental mouse movement can interfere with text entry. The no-mouse flag disables mouse and touchpad input for the console. Enable it when a pure keyboard experience is required:

no-mouse=yes

Custom Colour Palettes

The palette setting allows redefining the terminal's colour scheme. kmscon ships with several predefined palettes; custom definitions consist of a comma‑separated list of 16 hexadecimal RGB values, matching the order of the standard ANSI colours.

Verifying the kmscon Deployment

After enabling the service, switch to a virtual console with Ctrl+Alt+F3 (or any unused VT). The login prompt should appear rendered by kmscon. To confirm the active console driver, query the kernel messages:

dmesg | grep -i kmscon

A successful start will show lines indicating that kmscon has taken control of the DRM device and initialized the selected font engine.

If the console falls back to fbcon, verify that the kmscon service is running:

systemctl status kmscon.service

Restart the service after any configuration change:

sudo systemctl restart kmscon.service

Trade‑offs Between fbcon and kmscon

Switching to kmscon brings several advantages:

  • Modularity – Font engines and additional features are optional, keeping server installations lightweight.
  • Upgradability – Changes to rendering or input handling can be applied by updating the userspace package, avoiding kernel recompilation.
  • Better Internationalisation – Pango and FreeType support complex scripts and Unicode glyph shaping not available in fbcon.

However, there are trade‑offs to consider:

  • Dependency on DRM/KMS – kmscon requires a functional DRM driver; systems with minimal or custom kernel configurations may lack the necessary interfaces.
  • Early‑boot Timing – Because kmscon runs as a userspace daemon, it starts slightly later than fbcon, which is initialized directly by the kernel. On very early boot diagnostics, the console may be unavailable for a few seconds.
  • Resource Footprint – While modest, kmscon consumes additional memory and CPU cycles for font rasterisation compared with the bitmap‑only fbcon.

For headless servers that never display a console, retaining fbcon may reduce the attack surface and resource usage. For workstations, laptops, or any environment where a richer text interface improves productivity, kmscon offers a clear functional upgrade.

Reverting to the Legacy Console

If kmscon does not meet expectations, revert by disabling its service and ensuring the kernel fbcon driver is loaded:

sudo systemctl disable --now kmscon.service
sudo modprobe fbcon

After disabling kmscon, a reboot guarantees that fbcon regains control of the virtual terminals. The original configuration files under /etc/kmscon can be retained for future re‑enablement.

Source: fedoramagazine.org

Comments

Post a Comment

Subscribe to: Post Comments (Atom)

Popular Posts

Install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Overview Running a local large language model (LLM) is easier than ever thanks to Ollama and Open WebUI. Ollama handles model downloads and inference, while Open WebUI gives you a clean, chat-style interface in your browser. In this tutorial, you'll install both on Ubuntu 24.04 (works on 22.04 too), enable NVIDIA GPU acceleration, and deploy them with Docker Compose. The result is a fast, private AI stack you control. What You'll Need - Ubuntu 24.04 or 22.04 (fresh or existing server/desktop). - An NVIDIA GPU with recent drivers (Turing/RTX or newer recommended). - Root or sudo access. - Open ports 3000 (Open WebUI) and 11434 (Ollama) on your firewall if you access remotely. Step 1: Install NVIDIA Drivers and Verify CUDA First, update your system and install the recommended NVIDIA driver. On Ubuntu Desktop you can use Additional Drivers, but the CLI route is reliable: sudo apt update && sudo apt -y upgrade sudo ubuntu-drivers autoinstall sudo reboot After reboo...

Install a Local AI Chatbot on Ubuntu 24.04 with Ollama and Open WebUI (Step-by-Step)

Running a fast, private AI chatbot on your own computer or server is easier than ever. In this guide, you will install Ollama (a lightweight local LLM runtime) and Open WebUI (a modern web interface) on Ubuntu 24.04 . You will be able to chat with models like Llama 3 or Mistral without sending data to the cloud, and with optional GPU acceleration if you have an NVIDIA card. What you will need : an Ubuntu 22.04/24.04 machine (VM, bare metal, or WSL), at least 8 GB RAM (16 GB recommended for larger models), 15–30 GB free disk space for models, Internet access, and optional NVIDIA GPU drivers for acceleration. Why Ollama + Open WebUI? Ollama manages local large language models (LLMs) with simple commands and sensible defaults. Open WebUI gives you a clean, chat-style interface with features like prompt history, file uploads (for some models), and model switching. Together, they are a simple, reliable stack for a self-hosted AI experience. 1) Update Ubuntu and install basics First, ...

Install Ollama + Open WebUI on Ubuntu 24.04 with NVIDIA GPU Acceleration (Step-by-Step)

Overview This guide shows you how to install Ollama and Open WebUI on Ubuntu 24.04 with NVIDIA GPU acceleration. You will get a fast local AI stack that can run modern large language models (LLMs) like Llama 3 on your own hardware, secured and accessible in a web browser. We will cover GPU driver setup, Docker with the NVIDIA Container Toolkit, Ollama installation, Open WebUI deployment, basic security, and troubleshooting. Prerequisites - A machine running Ubuntu 24.04 (fresh or updated). - An NVIDIA GPU with at least 8 GB VRAM recommended for 8B models (more is better). - Internet access and sudo privileges. Step 1: Install the NVIDIA GPU Driver Install the recommended proprietary driver so CUDA becomes available to both Ollama and containers. sudo apt update && sudo apt install -y ubuntu-drivers-common sudo ubuntu-drivers autoinstall sudo reboot After reboot, verify the GPU is recognized: nvidia-smi You should see a driver version and your GPU model. If not, check...

Trending Now

Homogeneous Nucleation on Mars: A Textbook Process Finally Observed in Nature

on
By the end of this piece, you will understand what the Arsia Mons Elongated Cloud is, why it resisted explanation for several years after its first observation, and what the newly published model reveals about a physical process that has never been directly confirmed on any planet's atmosphere. The cloud that broke the model Every morning during Martian spring and summer, a thin, extremely long cloud forms near the Arsia Mons volcano and gradually elongates until it stretches to more than 1,000 miles before dissipating. The cycle then repeats for several months. The formation was first recorded by a probe in 2018, and from that point onward it became a persistent puzzle for atmospheric scientists working with Mars data. The cloud's geometry, its timing, and its seasonal recurrence all pointed to a real and reproducible physical process, yet no existing model could reproduce it. For a technical audience familiar with simulation work, the situation is analogous to a product...