Epochal change in Linux text consoles underway

Better security, getting rid of legacy, and new features: This is what an impending change in Linux's Virtual Terminal (VT) technology promises.

listen Print view
New Kmscon before Tux

(Image: Tux by Larry Ewing/GIMP / heise medien)

5 min. read
By
  • Thorsten Leemhuis
Contents

Following Wayland, another technology is poised to displace the old guard: In Fedora, a program running in userspace, rather than the Linux kernel, will soon be responsible for providing Virtual Terminals (VTs) – the full-screen text consoles invoked by key combinations like Ctrl+Alt+F3. Like Wayland, the new approach initially changes little but requires a rethink; nevertheless, other distributions are likely to follow suit sooner or later.

No wonder, as VTs are implemented by the kernel using Framebuffer consoles (fbcon) based on framebuffer devices (fbdev) – two techniques that are a thorn in the side of some developers. Foremost among them are those behind the Direct Rendering Manager (DRM), on which all modern kernel graphics drivers are built: They have long wanted to get rid of these two techniques from the kernel's early days, as the code exhibits many structural weaknesses and likely security vulnerabilities. One of these became known years ago and was more circumvented than fixed by developers, for instance, by disabling the scrolling function via Shift-Page-Up or -Down (scrollback) in Linux 5.9 – much to the chagrin of many old Linux veterans.

Nevertheless, fbdev and fbcon are still present in mainstream distributions because VTs, among other things, require them. Yet, David Herrmann (now in Rheinsberg) developed the software "Kmscon" back in late 2011, which implements VTs in userspace using Kernel Mode Setting (KMS) from DRM. A serious bug in the VT-related code would thus only affect the session and not the entire kernel. Development largely stalled in 2014 until other programmers breathed new life into it in 2022 – and just a few days ago released version 9.3.0.

The previous Framebuffer Console (fbcon).

(Image: heise medien)

The main driving force behind this is Red Hat developer Jocelyn Falempe, who has been pushing for the switch to Kmscon for the upcoming version 44 of Fedora Linux, expected in April 2026. On current Fedora versions, Kmscon can already be tried out with just a few steps.

Apart from a slightly different and sharper font, such a VT looks the same as a classic one with fbcon. However, it displays longer text much faster because Kmscon works much more efficiently. No wonder, as, similar to typical Wayland compositors, it renders the image directly via Kernel Mode Setting (KMS) through DRM, instead of via its Fbdev emulation.

The new Kmscon appears sharper than fbcon.

(Image: heise medien)

With Kmscon, the familiar scrollback also works again. Further advantages beyond potentially more secure and modern code become apparent upon closer inspection: keyboard layout switching via shortcut, better Unicode support, screen rotation support, and simple mouse support including copy & paste. The latter can be achieved on classic VTs via gpm, which does not work under Kmscon. The same applies to familiar tools like loadkeys or setfont for setting keyboard layouts or fonts; additionally, graphical interfaces must be started via the script kmscon-launch-gui.sh instead of startx.

It remains to be seen whether Fedora will find any major issues during the beta phase that might cause it to postpone the transition by a version. It is also uncertain whether and when other distributions will follow suit – or even opt for a different solution. This could be a simple Wayland compositor like Weston, where a terminal program usable under Gnome or KDE runs in full screen.

Videos by heise

Fbdev and fbcon will remain in use in Fedora for the time being, as the rescue shell invoked in case of boot problems requires them – however, Kmscon is likely to take over this job in the medium term. Furthermore, Fedora continues to use both techniques for outputting kernel messages during startup. This task will likely be delegated to the kernel function "DRM Log" in the medium term, which Jocelyn Falempe contributed to Linux 6.14. It offers significantly fewer functions than the old techniques and thus considerably less attack surface; the code for it is partly based on that of "DRM Panic," which also originates from Falempe. Through this, Linux has been able to reliably output fatal kernel errors since version 6.10, similar to a Windows Blue Screen – from Linux 6.12 onwards, optionally as a QR code. However, graphics drivers must support DRM Log and Panic; this is now the case for most common kernel drivers.

All in all, there is still a lot to do. As with any technological change, various bugs and missing features will emerge in the initial phase. This, and the obsolescence of Loadkeys, Startx & Co., will displease some users – resistance is therefore likely, similar to what the Linux world has experienced with Systemd or Wayland.

(afl)

Don't miss any news – follow us on Facebook, LinkedIn or Mastodon.

This article was originally published in German. It was translated with technical assistance and editorially reviewed before publication.