Eigene Tastaturbelegungen in X11 (X.Org / XFree86)

Nachdem ich schon mal angekündigt hatte, mich ein bisschen mit der Erstellung eigener Tastaturbelegungen unter X11 zu befassen, will ich mir an dieser Stelle mal nichts nachsagen lassen und anhand eines Beispiels demonstrieren, wie man sich sein eigenes Layout basteln kann. Dabei habe ich allerdings vermieden, allzu weit in die Untiefen des für die Tastenzuordnung verantwortlichen XKB-Systems abzusteigen (Interessierte finden hier und hier sicherlich ausreichend Lesestoff), sondern versucht, einfache Wege zu einer selbstgestrickten Keymap aufzuzeigen.

Der Plan

Weil einem das deutsche QWERTZ-Layout aufgrund der schlechten Erreichbarkeit mancher Sonderzeichen mitunter beim Programmieren in die Quere kommt, beschloss ich, mir eine eigene Tastaturbelegung zurechtzubasteln, die auf dem diesbezüglich eleganteren US-QWERTY-Layout basiert. Zusätzlich zur komfortablen Eingabe deutscher Umlaute sollte die neue Belegung auch einen schnellen Zugriff auf ein paar typographische Besonderheiten wie die horizontale Ellipse (…), deutsche Anführungszeichen („ und ”) oder den langen Gedankenstrich (–) ermöglichen. Gewissermaßen als kleiner Bonus wär’s auch schön, könnte man einige oft benötigte mathematische Symbole und Operatoren aus der Bool’schen Algebra direkt eingegeben.

Für alle, die mit der schnörkellosen Kargheit der amerikanischen Tastenanordnung noch nicht konfrontiert wurden oder einer Auffrischung bedürfen sei hier mal der alphanumerische Teil einer US-Tastatur abgebildet:

Da ich selbst schon länger mit einem modifizierten US-Layout [1] arbeite, bei dem deutsche Umlaute über die rechte Alt-Taste (auf nicht-US-Tastaturen Alt Gr) kombiniert mit dem jeweiligen Stammvokal eingegeben werden können, schien es mir angebracht, die Grundbelegung des US-Layouts zu übernehmen und die Eingabe zusätzlicher Zeichen über Kombinationen aus einer Taste mit Alt Gr bzw. Shift und Alt Gr zu ermöglichen. Berücksichtigt man den normalen Tastendruck und den Tastendruck in Kombination mit Shift, so existieren dann 4 mögliche Belegungen pro Zeichentaste, die es nach Belieben zu verteilen gilt. Angenehmerweise erlauben es die verschiedenen Mechanismen zur Zeichenzuweisung unter X11, bereits bestehende Layouts zu erweitern – in meinem Fall bleibt es mir also erspart, die gesamte US-Keymap neu zu definieren.

Bevor man sich aber an’s Werk macht, die schöne Einfalt einer US-Tastatur zu verwüsten, muss man erst mal wissen, welche Symbole man überhaupt braucht. In X11 können Tasten und Tastenkombinationen grundsätzlich mit beliebigen Unicode-Zeichen belegt werden (ob ein Programm dann jedoch eine passende Schriftart parat hat, um das dazugehörige Symbol auch darzustellen, ist freilich eine andere Frage). Generell dürfte gelten: Ein Zeichen, das man nicht kennt, braucht man auch nicht. Bei meiner Auswahl habe ich mich im Wesentlichen [2] auf folgende Unicode-Bereiche beschränkt.

Neben der eigentlichen Belegung fehlt jetzt nur noch ein sprechender Name. Aus Ermangelung einer besseren Idee hab’ ich mich entschieden, mein Layout auf den Namen us_ext (für U.S. Extended) zu taufen, da es im Grunde lediglich eine Erweiterung des US-Layouts darstellt. Die ersehnte Tastenbelegung sieht, wenn man alle erreichbaren Zeichen auf einer PC-Tastatur mit 102 Tasten einzeichnet, in etwa so aus:

Bei genauerer Betrachtung wird ersichtlich, dass die Taste rechts neben der linken Shift Taste zwar belegt ist, die ihr zugeordneten Zeichen aber auch über andere Tasten erreichbar sind. Das liegt daran, dass es diese Taste bei US-Tastaturen gar nicht gibt (pc101- bzw. pc104-Tastaturen haben stattdessen eine breitere Shift-Taste) und die ihr zugewiesenen Zeichen auf solchen Keyboards sonst nicht erreichbar wären.

Jetzt fehlt nur noch eine Kleinigkeit zur funktionierenden Keymap: Um die blanken Tasten nämlich auch wirklich zuordnen zu können, müssen wir erst mal wissen, wie sie aus Sicht des X-Servers benannt sind.

Fast da – von Scancodes, Keycodes und symbolischen Namen

In X11 unter GNU/Linux durchläuft ein Tastendruck eine Menge unterschiedlicher Abstraktionsschichten, bevor er tatsächlich auf eine Funktion abgebildet werden kann. Die Tastatur-Hardware repräsentiert einen Tastendruck (bzw. das Loslassen einer Taste) mit einem sogenannten Scancode. Das ist eine kurze Byte-Folge, die sich je nach Tastaturtyp unterscheidet (so senden z.B. USB- und PS/2-Tastaturen unterschiedliche Scancodes) und vom Linux-Kernel anhand einer Tabelle in sogenannte Linux-Keycodes umgewandelt wird. Der Tastatur-Treiber des X-Servers wiederum greift den Linux-Keycode auf erzeugt daraus einen X11-Keycode. Nachdem das XKB-System im Regelfall auch weiß, welches Tastaturmodell am Rechner hängt, kann es jeder Taste zusätzlich noch einen symbolischen Namen zuordnen.

Um Keycodes und symbolische Namen herauszufinden gibt es grundsätzlich mehrere Möglichkeiten. Entweder man wirft einen Blick auf die Dateien, in denen die Namen definiert werden (die liegen bei mir in /usr/share/X11/xkb/keycodes/ – die Dateien xfree86 und aliases scheinen mir ganz gute Einstiegspunkte zu sein) und führt sich dann zu Gemüte, welchen Tasten diese symbolischen Namen in einer bekannten Keymap – also z.B. der Amerikanischen – zugewiesen werden (Datei us in /usr/share/X11/xkb/symbols/) oder man verwendet ein Programm wie xev, das ein Fenster zeichnet und alle in diesem Fenster stattfindenden X11-Events (also auch Keyboard-Eingaben) in folgender Form auf die Konsole ausgibt:

KeyPress event, serial 32, synthetic NO, window 0x2a00001,
    root 0x75, subw 0x0, time 17904895, (494,59), root:(675,684),
    state 0x0, keycode 24 (keysym 0x71, q), same_screen YES,
    XLookupString gives 1 bytes: (71) "q"
    XmbLookupString gives 1 bytes: (71) "q"
    XFilterEvent returns: False

Relevant ist dabei in erster Linie der ausgegebene Keycode – in diesem Fall 24 für die Q-Taste rechts neben der Tabulatorortaste.

Für alle, die sich jetzt Motivierenderes vorstellen können, als sich durch zahllose Definitionsdateien zu wühlen, hab’ ich mir mal die Mühe gemacht, die bei einer 105-Tasten-IBM-PC-Tastatur generierten X11 Keycodes aufzuzeichnen:

Sobald man weiß, welche Keycodes welchen Tasten zugeordnet sind, kann man die gewünschte Zeichen-Zuordnung tabellarisch notieren. Zur Veranschaulichung hab’ ich hier mal eine Tabelle erstellt, in denen sowohl die X11-Keycodes als auch die symbolischen Tastennamen aus /usr/share/X11/xkb/keycodes/xfree86 angeführt sind. Unter „Zeichen” finden sich die 4 Belegungen der einzelnen Zeichentasten als Symbol mit dem dazugehörigen Unicode-Wert:

Sollten in dieser Tabelle ein paar Zeichen nicht vernünftig dargestellt werden, so liegt das vermutlich am Browser bzw. der Tatsache, dass er keine Schriftart finden kann, die den benötigten Glyphen enthält. Ich habe die einzelnen Zellen daher mit title-Attributen ausgestattet, die eine textuelle Beschreibung des darzustellenden Zeichens enthalten – die meisten Browsern zeigen diese an, wenn man die Maus über der betreffenden Zelle ruhen lässt.

Wie denn nun?

Grundsätzlich gibt es (mindestens) zwei verschiedene Möglichkeiten, dem X-Server ein eigenes Keyboard-Layout unterzujubeln:

Die erste – und zweifelsfrei elegantere – Lösung besteht darin, eine eigene Symboltabelle zu definieren, die dann eine gleichberechtigte Existenz unter den anderen dem X-Server bekannten Layouts fristet. Das ist auf Desktop-Rechnern sicher kein Problem, dürfte sich aber als schwierig erweisen, wenn man keinen Root-Zugriff auf das System hat, auf dem der X-Server läuft – der will die Symboltabelle nämlich in einem bestimmten Verzeichnis auffinden, das klarerweise nicht für alle Nutzer beschreibbar ist (wäre ja wohl nicht besonders nett, wenn irgendein Spaßvogel mal schnell die Standard-Layouts umdefiniert ;-)

Die andere Variante ist ein bisschen häßlicher, dürfte im Regelfall aber genauso gut funktionieren. Bei ihr wird zuerst eine installierte Keymap geladen und dann vom angemeldeten Nutzer mittels des Kommandozeilen-Programms xmodmap umdefiniert (das kann man freilich auch über ein Session-Skript automatiseren). Dieser Ansatz hat den Vorteil, dass man den X-Server selbst in Ruhe lassen und die eigene Keymap quasi automatisch mit dem Home-Verzeichnis auf andere Rechner mitnehmen kann, ist aber prinzipell die „dreckigere” Lösung …

Variante 1: Erstellen einer eigenen XKB-Symboltabelle

Grundsätzlich definiert eine XKB-Symboltabelle eine Abbildung von einer symbolischen Tastenbezeichnung auf ein oder mehrere Zeichen. Weil es abrt allerhand verschiedene Keyboard-Layouts mit unterschiedlichen Eigenheiten gibt, kann sowas schon mal recht kompliziert werden – in so einer Symboltabelle ist es nämlich nicht nur möglich, Mehrfachbelegungen festzulegen, sondern man kann einer Taste auch verschiedene „Zeichengruppen” zuordnen oder auch ihren Typ (Buchstabe, Ziffer, …) modifizieren. Für das vergleichsweise einfache us_ext-Layout sind diese erweiterten Funktionen allesamt nicht von Interesse, da es sich damit zufrieden gibt, schlicht und einfach bis zu vier verschiedene Zeichen auf eine einzelne Taste zu legen.

Jede Symboltabelle ist auf eine oder mehrere Text-Dateien verstreut, die – zumindest bei mir – allesamt unter /usr/share/X11/xkb/symbols/ liegen. Auf die Syntax möchte ich an dieser Stelle nicht näher eingehen, als es unbedingt nötig ist – wer sich dafür interessiert, dem sei angeraten, einen Blick auf die verschiedenen Standard-Symboltabellen in diesem Verzeichnis zu werfen oder aber ein bisschen in diesen Text reinzuschnuppern.

Für us_ext muss man im Grunde lediglich das bereits bestehende us-Layout in der spartanischen basic-Variante (sowie die Definition von Alt Gr als ISO_Level3_Shift für die dritte und vierte Belegung) importieren und alle Tasten, die mit zusätzlichen Zeichen auszustatten sind, entsprechend umdefinieren. Ich habe einfach eine neue Datei mit dem Namen us_ext in /usr/share/X11/xkb/symbols/ erzeugt und mit folgendem Inhalt gefüllt:

// us_ext: Custom extended us keymap

default
partial alphanumeric_keys
xkb_symbols "basic" {

  include "us(basic)"
  include "level3(ralt_switch)"

  key <TLDE> {[ grave,        asciitilde,  U2248                           ]};
  key <AE01> {[ 1,            exclam,      onesuperior                     ]};
  key <AE02> {[ 2,            at,          twosuperior,    onehalf         ]};
  key <AE03> {[ 3,            numbersign,  threesuperior,  onethird        ]};
  key <AE04> {[ 4,            dollar,      foursuperior,   onequarter      ]};
  key <AE05> {[ 5,            percent,     U2030                           ]};
  key <AE06> {[ 6,            asciicircum, U22BB                           ]};
  key <AE07> {[ 7,            ampersand,   logicaland,     U22BC           ]};
  key <AE08> {[ 8,            asterisk,    U2219,          multiply        ]};
  key <AE09> {[ 9,            parenleft,   guillemotleft,  U2039           ]};
  key <AE10> {[ 0,            parenright,  guillemotright, U203A           ]};
  key <AE11> {[ minus,        underscore,  endash,         emdash          ]};
  key <AE12> {[ equal,        plus,        notequal,       plusminus       ]};

  key <AD03> {[ e,            E,           EuroSign,       U2203           ]};
  key <AD04> {[ r,            R,           registered                      ]};
  key <AD05> {[ t,            T,           trademark                       ]};
  key <AD07> {[ u,            U,           udiaeresis,     Udiaeresis      ]};
  key <AD08> {[ i,            I,           U21D2,          ifonlyif        ]};
  key <AD09> {[ o,            O,           odiaeresis,     Odiaeresis      ]};
  key <AD10> {[ p,            P,           section,        paragraph       ]};
  key <AD11> {[ bracketleft,  braceleft,   U201E,          U201A           ]};
  key <AD12> {[ bracketright, braceright,  U201D,          U2019           ]};

  key <AC01> {[ a,            A,           adiaeresis,    Adiaeresis       ]};
  key <AC02> {[ s,            S,           ssharp                          ]};
  key <AC03> {[ d,            D,           degree                          ]};
  key <AC04> {[ f,            F,           U2200                           ]};
  key <AC11> {[ apostrophe,   quotedbl,    U2019                           ]};
  key <BKSL> {[ backslash,    bar,         logicalor,     U22BD            ]};

  key <LSGT> {[ U201E,        U201D,       U201A,         U2019            ]};
  key <AB03> {[ c,            C,           copyright,     cent             ]};
  key <AB06> {[ n,            N,           notsign                         ]};
  key <AB07> {[ m,            M,           mu                              ]};
  key <AB08> {[ comma,        less,        lessthanequal, lessthanequal    ]};
  key <AB09> {[ period,       greater,     ellipsis,      greaterthanequal ]};
  key <AB10> {[ slash,        question,    division                        ]};

};

In dieser Datei wird nur eine Variante der Keymap – nämlich basic – definiert und als Standard-Variante ausgezeichnet. Die Angabe partial teilt XKB mit, dass es sich dabei nicht um eine vollständige Definition handelt – Tastenzuordnungen, die also weder hier, noch in den importierten Symboltabellen auffindbar sind, muss sich das XKB-System anderswo suchen (und das tut es auch). Dank der – etwas mißverständlichen – Auszeichnung alphanumeric_keys weiß XKB, dass sich diese Tabelle lediglich auf den Hauptteil der Tastatur (anstatt auf Modifikatortasten, Keypad oder Funktionstasten) bezieht.

Die Zuordnungstabelle selbst (der große, mit geschwungenen Klammern umschlossene Teil) besteht aus Definitionen für einzelne Tasten, die mit ihrem symbolischen Namen angesprochen werden. Jede Zuordnung ist wiederum in geschwungene Klammern eingeschlossen und wird mit einem Strichpunkt beendet. Die eckigen Klammern sind grundsätzlich dazu da, einzelne Zuordnungsgruppen voneinander zu trennen. Das wäre jedoch in dieser Keymap, die für jede Taste nur eine einzige Gruppe definiert, im Grunde nicht notwendig. Zum besseren Verständnis will ich mal eine Zeile herausgreifen:

key <AD03> {[ e, E, EuroSign, U2203 ]};

Hier werden der Taste mit dem symbolischen Namen AD03 der Reihe nach 4 verschiedene Zeichen zugeordnet, die jeweils mit einem sogenannten „Level” einhergehen. In us_ext entspricht Level 1 dem normalen Tastendruck, Level 2 dem Tastendruck mit Shift, Level 3 dem Drücken der Taste mit Alt Gr und Level 4 der Kombination der Taste mit Shift und Alt Gr.

Für die auszugebenden Zeichen habe ich dort symbolische Namen (in der X11-Terminologie: Keysyms) verwendet, wo es mir im Sinne der Lesbarkeit sinnvoll erschien, bei den Tasten hatte ich hingegen keine Wahl: In Symboltabellen ist die Verwendung von symbolischen Tastennamen (wie sie z.B. in /usr/share/X11/xkb/xfree86 definiert werden) Pflicht – wohl, um sicherzustellen, dass exotische Tastaturen, die abweichende X11-Keycodes erzeugen, dennoch eine brauchbare Zuordnung erhalten. Zeichen hingegen lassen sich sowohl durch ihre Position im Unicode-Zeichensatz referenzieren, als auch durch den in der Datei /usr/include/X11/keysymdef.h definierten symbolischen Namen [3] – dabei muss man jedoch die ersten drei Zeichen (XK_) weglassen. Statt obiger Zeile hätte ich also genausogut Folgendes schreiben können, würde mich dann aber nach einiger Zeit nicht mehr in der Symboltabelle zurechtfinden.

key <AD03> {[ U0065, U0045, U20AC, U2203 ]};

Nachdem man die eigene Symboltabelle dort abgelegt hat, wo der X-Server sie sucht (also z.B. in /usr/share/X11/xkb/symbols/), muß sie bloß noch geladen werden. Das kann man entweder mit setxkbmap aus der laufenden X-Session heraus oder aber global mit einer Einstellung in der Konfigurationsdatei des X-Servers (bei mir /etc/X11/xorg.conf) machen. Ein Aufruf von setxkbmap sieht z.B. so aus:

setxkbmap us_ext

Wahlweise können auch noch Keyboard-Modell und Keycode-Mapping explizit angegeben werden:

setxkbmap -model pc102 -keycodes xfree86 us_ext

In xorg.conf könnte die entsprechende Passage (in der InputDevice-Sektion für’s Keyboard) etwa so aussehen

Identifier      "Generic Keyboard"
  Driver          "kbd"
  Option          "CoreKeyboard"
  Option          "XkbRules"      "xorg"
  Option          "XkbModel"      "pc102"
  Option          "XkbLayout"     "us_ext"
EndSection

Wenn alles klappt, hat man nun seine eigene Keymap, die man in allen X11-Anwendungen verwenden kann.

Für alle, die nicht am XKB-System herumpfuschen wollen, bietet sich mit xmodmap eine alternative Vorgehensweise …

Variante 2: Umdefinieren der Zuordnungen mit xmodmap

Das Kommandozeilenprogramm xmodmap erlaubt das Anpassen einer bereits geladenen Keymap innerhalb der laufenden X-Session. Für das selbstgestrickte us_ext-Layout würde es sich also anbieten, zuerst mit setxkbmap eine dem X-Server beiliegende Keymap zu laden – etwa die us-Keymap in ihrer basic-Variante –, um dann einige der dort festgelegten Tastenbelegungen mit xmodmap zu überschreiben.

Die Tatsache, dass zum Zeitpunkt der Ausführung von xmodmap bereits eine Symboltabelle geladen ist, hat den angenehmen Nebeneffekt, dass man Tasten nun nicht nur über ihre X11-Keycodes referenzieren kann, sondern auch über die ihnen bereits zugewiesenen Zeichen. Gewissermaßen im Gegenzug für diesen Komfortgewinn weiß xmodmap jedoch nichts mit den symbolischen Tastennamen aus den geladenen Dateien in /usr/share/X11/xkb/keycodes/ anzufangen.

Ohne weiter auf Details herumzureiten: Eine mögliche Eingabedatei für xmodmap, in der die Tastenzuordnungen aus einem geladenen us-Layout umdefiniert werden, sieht z.B. so aus:

keycode 113         = Mode_switch

keysym grave        = grave        asciitilde   U2248
keysym 1            = 1            exclam       onesuperior
keysym 2            = 2            at           twosuperior    onehalf
keysym 3            = 3            numbersign   threesuperior  onethird
keysym 4            = 4            dollar       foursuperior   onequarter
keysym 5            = 5            percent      U2030
keysym 6            = 6            asciicircum  U22BB
keysym 7            = 7            ampersand    logicaland     U22BC
keysym 8            = 8            asterisk     U2219          multiply
keysym 9            = 9            parenleft    guillemotleft  U2039
keysym 0            = 0            parenright   guillemotright U203A
keysym minus        = minus        underscore   endash         emdash
keysym equal        = equal        plus         notequal       plusminus

keysym e            = e            E            EuroSign       U2203
keysym r            = r            R            registered
keysym t            = t            T            trademark
keysym u            = u            U            udiaeresis     Udiaeresis
keysym i            = i            I            U21D2          ifonlyif
keysym o            = o            O            odiaeresis     Odiaeresis
keysym p            = p            P            section        paragraph
keysym bracketleft  = bracketleft  braceleft    U201E          U201A
keysym bracketright = bracketright braceright   U201D          U2019

keysym a           = a             A            adiaeresis      Adiaeresis
keysym s           = s             S            ssharp
keysym d           = d             D            degree
keysym f           = f             F            U2200
keysym apostrophe  = apostrophe    quotedbl     U2019
keysym backslash   = backslash     bar          logicalor       U22BD

keycode 94          = U201E         U201D       U201A           U2019
keysym c            = c             C           copyright       cent
keysym n            = n             N           notsign
keysym m            = m             M           mu
keysym comma        = comma         less        lessthanequal   lessthanequal
keysym period       = period        greater     ellipsis        greaterthanequal
keysym slash        = slash         question    division

In der ersten Zeile wird die Alt Gr-Taste (X11-Keycode 113 mit dem Mode_switch-Zeichen belegt, das es erlaubt, auf die dritte und – zusammen mit Shift – auf die vierte Belegung umzuschalten [4].

In den weiteren Zeilen werden bereits definierte Tasten über die symbolischen Namen der ihnen gegenwärtig zugewiesenen Zeichen umdefiniert. Die einzige Ausnahme bildet die Taste rechts der linken Shift-Taste (X11-Keycode 94): Für sie gibt es in der us-Symboltabelle keine Zuweisung, weshalb sie direkt über ihren Keycode referenziert werden muss.

Hat man die xmodmap-Eingabedatei z.B. unter dem Namen mm_us_ext im eigenen Home-Verzeichnis abgelegt, so kann man sie mit folgenden Aufrufen – etwa in einem X-Session-Skript – laden:

setxkbmap us\(basic\)
xmodmap ~/mm_us_ext

Abschließende Worte

Wenn mir auch bewusst ist, dass dieser Artikel viele Fragen zur Konfiguration des Keyboard-Layouts unter X11 nicht einmal anschneidet, hoffe ich doch, dass sich für den einen oder anderen Leser als nützlich erweist.

Über Anregungen, Fragen oder Kritik würde ich mich freuen.

Ein paar nützliche Links

• Doug Palmer: An Unreliable Guide to XKB Configuration
• Ivan Pascal: X Keyboard Extension
• René Seindal spricht (nicht nur) über Scancodes und den Linux-Keycode-Table

Fußnoten

[1]

Dieses amerikanische Layout mit deutschen Umlauten nannte sich us_de. Ich hatte es vor geraumer Zeit irgendwo im Web gefunden (ich glaube, das war auf einer privaten Seite, weiß aber leider nicht mehr, auf welcher). Die us_de-Keymap funktionierte im Grunde genauso wie die hier dargestellte us_ext-Symboltabelle, war aber syntaktisch nicht ganz mit aktuellen X-Servern kompatibel.

[2]

Für die pedantischen unter den Lesern: Wer genau hinschaut, entdeckt zusätzlich vereinzelt ein paar Zeichen aus „Superscripts and Subscripts” (2070-209F), „Letterlike Symbols” (2100-214F), „Number Forms” (2150-218F) und „Arrows” (2190-21FF).

[3]

Durch Zufall bin ich auf einen kleinen Bug in keysymdef.h gestossen: Der symbolische Zeichenname implies wird nicht – wie dort angeführt – auf das passende Unicode-Zeichen 0x21D2, sondern vielmehr auf 0x22A2 abgebildet.

[4]

Leider bin ich mir über die unterschiedliche Numerierung einzelner Tasten-Levels in XKB-Symboltabellen und xmodmap-Eingabedateien bzw. insbesondere über das Verhältnis zwischen den Keysyms Mode_shift und ISO_Level3_Shift bis dato nicht ganz im Klaren (soll heißen: Ich weiß nicht, wovon ich hier schreibe ;-) – zu diesem Thema war auf die Schnelle schlicht und einfach keine Dokumentation aufzutreiben …