Deutsch | English

Terminal-Emulatoren & Systemkonsolen unter Verwendung der Bibliothek TSM. Von einem Wayland-kompatiblen Terminal-Emulator zur virtuellen Konsole in Chromebooks.


Inhalt


TSM – Terminal-Emulator State Machine

Die Bibliothek TSM ist lediglich für die reine Terminal-Emulation zuständig, ohne dabei an eine Grafikbibliothek gebunden zu sein ⁽¹⁾. Der letzte Commit fand 2014 statt und fügte ein GTK-Widget hinzu, um einen Terminal-Emulator zu erzeugen ⁽²⁾. Ein aktiver Fork findet sich hier ⁽³⁾, neue Features sind in der ReadMe aufgelistet.

  1. Freedesktop.org: Wiki: Software → libtsm → »libtsm - Terminal-emulator State Machine«
  2. Freedesktop.org: cgit → dvdhrm/libtsm: »Terminal-Emulator State Machine« → commit: »gtktsm: add libtsm example«
    Datum: 2014-04-24 | Commit: David Herrmann
  3. GitHub: Aetf/libtsm → »Terminal-emulator State Machine«

wlterm

wlterm

wlterm ist der einzige Terminal-Emulator, der zusammen mit der Bibliothek TSM verwendet wird.

In der wayland-devel-Mailingliste findet sich ein Posting des Entwicklers David Herrmann zum Terminal-Emulator wlterm, der die technischen Hintergründe beleuchtet ⁽¹⁾.

Hierzu gehört, dass bisherige Fehlen eines Terminal-Emulators für Wayland, um Bugs in der Wayland-API zu finden. Interessant ist auch der Hinweis, dass Dekorationen seitens wlterm selbst gezeichnet werden. Dies berührt wieder die Thematik Client-Side-Decorations unter Wayland, die in den beiden vorherigen Artikeln zu Sway und Terminal-Emulatoren mit angesprochen wurde ⁽²⁾ ⁽³⁾.

Des Weiteren verwendet wlterm die Bibliothek TSM zu Testzwecken, die hier auf GTK oder ähnliche Abhängigkeiten verzichtet und auch nicht für das Rendering verantwortlich ist. Der Übersichtsseite zu wlterm kann man entnehmen, das ursprünglich keine Abhängigkeiten zu Grafik-Toolkits wie GTK oder Qt bestanden ⁽⁴⁾ – was sich später den weiteren Informationen dort nach änderte mit einer Erweiterung für GTK.

Ein Commit zur Entfernung der wlterm-Quellen im Git-Repo inkl. kurzer Begründung und Verweis auf eine GTK-basierte Variante ⁽⁵⁾. Der allerletzte Commit für die GTK-basierte Version von wlterm liegt auch schon eine Weile zurück ⁽⁶⁾. Im Arch User Repository finden wir wlterm verwaist, inklusive GTK-Abhängigkeiten ⁽⁷⁾.

Was aber bleibt, ist, dass wlterm als erster nativer Wayland-Terminal-Client eingesetzt werden konnte, der nicht auf die VTE-Bibliothek angewiesen war.

  1. LWN.net: »wlterm: the native Wayland terminal emulator«
    Gepostet: 2012-09-27 | Entwickler: David Herrmann | Original Post: Mailinglist wayland-devel
  2. Blog: »semantic design« → »Tiling-Window-Manager unter Wayland: Sway« → »Client-Side-Decorations versus Server-Side-Decorations«
    Veröffentlicht: 2019-06-24 | Autor: Markus Richter
  3. Blog: »semantic design« → »Terminal-Emulatoren: Fenster ins System« → »Tilix«
    Veröffentlicht: 2019-09-30 | Autor: Markus Richter
  4. Freedesktop.org: Wiki: Software → kmscon → »wlterm«
  5. GitHub: dvdhrm/wlterm → Commit: »wlterm: remove«
    Commit: 2013-10-23 | Entwickler: David Herrmann
  6. Freedesktop.org: cgit → dvdhrm/wlterm → »Summary«
    Commit: 2013-11-12 | Entwickler: David Herrmann
  7. ArchLinux: User Repository: Packages → »wlterm-git«
    Letzte Aktualisierung: 2016-06-21

Kmscon

Kmscon

libtsm kommt ohne einen Display-Server aus und wurde auch hierfür entwickelt. Kmscon verwendet diese Bibliothek und kann somit die virtuelle Konsole ersetzen unter Linux-Systemen ⁽¹⁾.

Eine kurze Zusammenfassung der Gründe, die für einen Wechsel der Konsole sprechen in der FAQ ⁽²⁾, sowie die ausführliche Variante als Artikel des Entwicklers ⁽³⁾. Begleitend erschien dazu ein Artikel, der sich mehr auf die bisherige Umsetzung in Form von virtuellen Konsolen bezog und die damit einhergehenden Problematiken ⁽⁴⁾. Ein weiterer Artikel als komprimierte Einführung zu Kmscon ⁽⁵⁾.

Im ersten Artikel dieser dreiteiligen Serie von Red Hat zu Konzepten von Virtuellen Maschinen und Containern werden Userspace & Kernelspace als abstraktes Modell erklärt ⁽⁶⁾.

Das Debian-Handbuch fächert den Userspace auf ⁽⁷⁾,

  • anhand der Verbindung zwischen Prozessen & Daemons
  • und einer Erläuterung, wie diese untereinander und mit dem Systemkern kommunizieren,
  • sowie der Rolle einiger Bibliotheken darin.

Das Arch Linux-Wiki zeigt, wie man Kmscon auf den virtuellen Terminals einrichtet ⁽⁸⁾. Verwendet wird Kmscon in Kombination mit KMS (Kernel Mode Setting) ⁽⁹⁾, dieser Wikipedia-Artikel schlüsselt Mode-Setting noch etwas auf ⁽¹⁰⁾. Der Direct Rendering Manager (DRM) gewährt Zugriffe auf den Speicher der Grafikkarte und verwaltet diese ⁽¹¹⁾.

Die letzte Version von libtsm, die für Kmscon verwendet wurde, ist von 2013 und findet sich hier ⁽¹²⁾, in dieser wurde das GTK-basierende Terminal-Widget GtkTsmTerminal hinzugefügt, um Terminal-Emulatoren zu erstellen. Der letzte Commit zu Kmscon fand statt im Juli 2014 ⁽¹³⁾.

Ein Fork von Kmscon findet sich auf GitHub, der mit kontinuierlichen Commits bis September 2018 aufwartet ⁽¹⁴⁾. Auch libtsm wird hier als Fork weiter betreut.

  1. Freedesktop.org: Wiki: Software → kmscon → »KMS/DRM based System Console«
  2. GitHub: dvdhrm/kmscon → Wiki: FAQ
  3. Blog: »Ponyhof – Disfunctional Programming« → »KMSCON: Linux KMS/DRM based Virtual Console«
    Datum: 2012-08-11 | Autor: David Herrmann
  4. Blog: »Ponyhof – Disfunctional Programming« → »Deprecating CONFIG_VT«
    Datum: 2012-08-12 | Autor: David Herrmann
  5. Blog: »Ponyhof – Disfunctional Programming« → »KMSCON Introduction«
    Datum: 2012-12-10 | Autor: David Herrmann
  6. Blog: RedHat: »Architecting Containers Part 1: Why Understanding User Space vs. Kernel Space Matters«
    Veröffentlicht: 2015-07-29 | Autor: Scott McCarty
  7. The Debian Administrator's Handbook: »B.5. The User Space«
  8. ArchLinux: Wiki → »KMSCON«
  9. ArchLinux: Wiki → »Kernel mode setting«
  10. Wikipedia: »Mode-Setting«
  11. Wikipedia: »Direct Rendering Manager«
  12. Freedesktop.org: Software → kmscon: Releases
  13. GitHub: dvdhrm/kmscon → Commits
  14. GitHub: Aetf/kmscon → Commits

Frecon

Was passierte ansonsten mit Kmscon und libtsm? Es gibt einen Hinweis in der Entwickler-Mailingliste von Kmscon ⁽¹⁾ ⁽²⁾. Google verwendet ChromiumOS ⁽³⁾ in einer abgewandelten Form als ChromeOS in seinen Chromebooks bezeichneten Geräten ⁽⁴⁾. Google ersetzte den Display-Server X11 in seinem eigenen Grafik-Stack namens Freon. ⁽⁵⁾. Innerhalb des Grafik-Stacks Freon existiert kein Display-Server, sondern der Chrome-Browser (der erst einmal die einzige Applikation des Systems ist) kommuniziert direkt via KMS.

Wir finden kongenial dazu einige Informationen zu Frecon, als virtuelle Konsole im Userspace. Frecon verwendet ebenfalls KMS und setzt auf libtsm. Eine kurze Ankündigung auf Google+ zu dem Wechsel auf Freon/Frecon ⁽⁶⁾. Eine Einführung in Frecon ⁽⁷⁾ und verwendbare Kommandos ⁽⁸⁾.

  1. Freedesktop.org: Mailinglists → kmscon-devel → »what is the development status of kmscon«
    Datum: 2017-11-29
  2. Freedesktop.org: Mailinglists → kmscon-devel → Reply: »what is the development status of kmscon«
    Datum: 2017-11-29
  3. »The Chromium Projects« → »Chromium OS«
  4. Google: Chromebook
  5. tuicool.org (Originalartikel von Phoronix) → »Chrome OS Switches To "Freon" Graphics Stack To Replace X11«
    Datum: 2015-03-09 | Autor: Michael Larabel
  6. Google+ → »… in a nutshell, project ozone¹/freon is Chrome OS without X server«
    Datum: 2015-03-04 | Gepostet von: Francois Beaufort
  7. GoogleSource → Chromium: ChromiumOS: Frecon → »Frecon, a console for freon« → »Docs«
  8. GoogleSource → Chromium: ChromiumOS: Frecon → »frecon: the Freon Console« → »Commands«
Creative Commons Lizenzvertrag
Dieser Artikel ist lizenziert unter einer
Creative Commons Namensnennung - Weitergabe unter gleichen Bedingungen 4.0 International Lizenz.