Epochaler Wandel bei Textkonsolen von Linux im Werden

Bessere Sicherheit, Altlasten loswerden und neue Features: Das verspricht ein sich anbahnender Wechsel bei der Technik für Virtual Terminals (VTs) von Linux.

vorlesen Druckansicht 6 Kommentare lesen
Neue Kmscon vor Tux

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

Lesezeit: 5 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Nach Wayland schickt sich gerade eine weitere Technik an, althergebrachtes zu verdrängen: Bei Fedora soll bald nicht mehr der Linux-Kernel, sondern ein im Userspace arbeitendes Programm die Virtual Terminals (VTs) bereitstellen – also die Vollbild-Textkonsolen, die Tastenkombinationen wie Strg+Alt+F3 aufrufen. Wie Wayland verändert der neue Ansatz auf den ersten Blick wenig, erfordert zugleich aber Umdenken; dennoch dürften andere Distributionen diesem Beispiel über kurz oder lang folgen.

Kein Wunder, denn VTs realisiert der Kernel mit Framebuffer-Konsolen (fbcon) auf Basis von Frame-Buffer-Geräten (fbdev) – zwei Techniken, die einigen Entwicklern ein Dorn im Auge sind. Allen voran jenen hinter dem Direct Rendering Manager (DRM), auf dem alle modernen Kernel-Grafiktreibern aufbauen: Sie wollen die beiden Techniken aus der Anfangszeit des Kernels schon lange gerne loswerden, da der Code viele strukturelle Schwächen und vermutlich Sicherheitslücken aufweist. Eine davon wurde vor Jahren bekannt und von den Entwicklern mehr umschifft denn beseitigt, indem sie unter anderem die Funktion zum Scrollen via Shift-Bild-Auf beziehungsweise -Ab (Scrollback) bei Linux 5.9 deaktiviert haben – zum Ärger von so manch altem Linux-Hasen.

Fbdev und Fbcon sind bei Mainstream-Distributionen dennoch nach wie vor dabei, da unter anderem VTs diese benötigen. Dabei hat David Herrmann (mittlerweile Rheinsberg) schon Ende 2011 die Software „Kmscon“ entwickelt, die VTs mithilfe Kernel Mode Setting (KMS) von DRM im Userspace realisiert. Ein böser Bug im Code rund um VTs betrifft so nur die Sitzung und nicht den ganzen Kernel. Die Entwicklung schlief allerdings 2014 weitgehend ein, bis andere Programmierer ihr 2022 wieder Leben einhauchten – und vor wenigen Tagen die Version 9.3.0 veröffentlichten.

Die bisherige Framebuffer-Console (fbcon).

(Bild: heise medien)

Haupttriebkraft dahinter ist Red-Hat-Entwickler Jocelyn Falempe, der seit einigen Monaten parallel den Umstieg auf Kmscon bei der für April 2026 erwarteten Version 44 von Fedora Linux vorantreibt. Bei aktuellen Fedora-Versionen kann man Kmscon bereits mit wenigen Handgriffen ausprobieren.

Ein solches VT sieht von einer leicht anderen und schärferen Schriftart abgesehen, genauso aus wie ein klassisches mit Fbcon. Es stellt einen längeren Text aber viel schneller dar, weil Kmscon viel effizienter arbeitet. Kein Wunder, denn ähnlich wie typische Wayland-Compositoren gibt es das Bild mithilfe von Kernel Mode Setting (KMS) via DRM direkt aus statt über dessen Fbdev-Emulation.

Die neue Kmscon wirkt schärfer als fbcon.

(Bild: heise medien)

Bei Kmscon funktioniert auch das altbekannte Scrollback wieder. Weitere Vorteile jenseits von potenziell sicherem und modernerem Code zeigen sich beim genaueren Hinsehen: Tastaturbelegungswechsel per Shortcut, besserer Unicode-Support, Unterstützung zur Bildschirmdrehung sowie simpler Maus-Support samt Copy & Paste. Letzteres lässt sich bei klassischen VTs über gpm realisieren, das unter Kmscon nicht funktioniert. Das Gleiche gilt auch für altbekannte Werkzeuge wie loadkeys oder setfont zum Setzen von Tastaturbelegung oder Schriftart; außerdem muss man grafische Oberflächen statt via startx über das Skript kmscon-launch-gui.sh starten.

Abzuwarten bleibt, ob Fedora in der Beta-Phase noch größere Probleme findet, durch die es den Umstieg womöglich um eine Version vertagt. Ebenso ist ungewiss, ob und wann andere Distributionen dem Beispiel folgen – oder gar auf eine andere Lösung setzen. Das könnte ein simpler Wayland-Compositor wie Weston sein, bei dem ein auch unter Gnome oder KDE nutzbares Terminalprogramm im Vollbild läuft.

Videos by heise

Fbdev und Fbcon bleiben bei Fedora vorerst weiter im Einsatz, da die bei Boot-Problemen aufgerufene Rescue-Shell diese erfordert – diesen Job dürfte Kmscon mittelfristig aber auch übernehmen. Ferner nutzt Fedora die beiden Techniken weiter zur Ausgabe der Kernel-Meldungen beim Start. Diese Aufgabe dürfte mittelfristig vermutlich an die Kernel-Funktion "DRM Log" gehen, die Jocelyn Falempe bei Linux 6.14 beigesteuert hat. Sie bietet deutlich weniger Funktionen als die alten Techniken und so erheblich weniger Angriffsfläche; der dahin stehende Code basiert zum Teil auf jenem von "DRM Panic", der ebenfalls von Falempe stammt. Durch diese kann Linux seit Version 6.10 bei fatalen Kernel-Fehlern verlässlich und ähnlich wie einen Blue-Screen von Windows ausgeben – ab Linux 6.12 auf Wunsch auch als QR-Code. Grafiktreiber müssen DRM Log und Panic allerdings unterstützen; bei den meisten gängigen Kernel-Treibern ist das aber mittlerweile der Fall.

Alles in allem gibt es also noch einiges zu tun. Wie bei jedem Technologiewechsel werden in der Anfangsphase noch allerlei Bugs und fehlende Features auftauchen. Das und die Hinfälligkeit von Loadkeys, Startx & Co. wird einigen Anwendern missfallen – Gegenwind wie ist daher wahrscheinlich, ähnlich, wie die Linux-Welt das von Systemd oder Wayland kennt.

(dmk)