Nervt die CapsLock-Taste? Suchen Sie einen sinnvollen Verwendungzweck für die Windows-Tasten? Alles eine Frage der Definition …

Ein neuer Arbeitsplatz, ein neuer Rechner oder ein Keyboard, das nach langen, treuen Jahren der Zusammenarbeit den Weg alles Irdischen ging – irgendwann kommt jede/r mal in die Verlegenheit, sich mit einer neuen Tastatur anfreunden zu müssen, die heutzutage ganz sicher mit Windows-Tasten aufwartet. Selbst wenn man die gegen Pinguin-Tasten austauscht, so ändert das noch nichts an ihrer – je nach Distribution – (Nicht-)Funktion.

Mag eine unbenutzt vor sich hindämmernde Windows-Taste noch so unschön sein – richtig nervig ist oft die [CapsLock]-Taste, mit deren Hilfe man immer wieder mal aus Versehen das arme Rechnerlein anschreit.

Warum also nicht dem Quälgeist eine vernünftige Funktion geben? Sinnvoll wäre zum Beispiel, ihn zu einer zweiten linken [Umschalt]-([Shift]-)Taste umzufunktionieren, an deren Stelle er so oft aus Versehen gedrückt wird. Manche Leute tauschen einfach die Funktionen von [CapsLock] und der linken [Strg]-Taste. Auch einer individuellen Lösung steht wenig entgegen – zunächst einmal nur die Frage, wie das eigentlich geht.

Leider nicht mit einer einzigen Änderung, denn die beiden Benutzer-Schnittstellen unter Linux, die Textkonsole und das grafische X-Window-System, kümmern sich separat um die Tastenbelegung. Wer schon einmal eine Distribution installiert hat, bei der er/sie sich selbst um eine deutsche Tastenbelegung kümmern musste [1] oder Umlaute nachrüsten wollte [2], ahnt bereits, dass man dazu an separaten Rädchen drehen muss.

Tastenbelegung ohne X

Dass auch eine deutsche Tastatur mit einer amerikanischen Belegung arbeiten kann, weiß jede/r, die/der im BIOS-Menü ein y für “yes” eingeben wollte und mit der passenden Taste eines deutschen Keyboards ein z produzierte. Erst beim Hochfahren lädt das System die deutsche Tastenbelegung. Dazu muss es einen Befehl geben, und der sollte der Schlüssel zum Problem sein. Ihn im Alleingang zu finden, gibt es (mindestens) drei Möglichkeiten: * Die Lieblingssuchmaschine mit passenden Stichwörtern wie Tastaturbelegung, keytable und Linux zu füttern. * Die Boot-Skripte im init.d-Verzeichnis (meist /etc/rc.d/init.d oder /etc/init.d) nach einem Befehl zu durchsuchen, der vermutlich irgendwas mit key heißt. * In der whatis-Datenbank des eigenen Systems nach diesem Befehl zu fahnden.

Die erste Möglichkeit überlasse ich Ihren persönlichen Präferenzen; ob man mit der zweiten Erfolg hat, hängt stark von der verwendeten Distribution ab: Bei SuSE (als Beispiel dient 7.2) mit ihrer Vorliebe für möglichst komplexe, für Normal-Benutzer nahezu undurchschaubare Skripte kommt man zwar mit

trish@linux:~ > grep keys /etc/init.d/*[…]
/etc/init.d/kbd:        rc_status && retmsg="`loadkeys $KEYMAP 2>&1`"[…]

recht schnell zu der Ansicht, dass die Datei /etc/init.d/kbd (wie “keyboard“) für’s Laden der richtigen Tastaturtabelle verantwortlich ist, doch wer einen Blick in dieses Skript wirft und nicht bereits weiß, wonach er/sie sucht, wird sich vermutlich etwas verlassen vorkommen. Das Suchergebnis bei Debian (/etc/init.d/keymap.sh), Red Hat (/etc/init.d/keytable) oder Caldera OpenLinux (/etc/rc.d/init.d/keytable) ist wesentlich übersichtlicher und legt das Ergebnis nahe, dass loadkeys der gesuchte Befehl ist.

Die Suche in der whatis-Datenbank mit dem Befehl apropos oder

trish@linux:~ > man -k keys
loadkeys (1)         - load keyboard translation tables

und ein anschließender Blick in die entsprechende Manpage bestätigen den Verdacht: Mit diesem Kommando lässt sich die Tastaturbelegung auf der Konsole ändern. Die Belegung wiederum ist in sogenannten Map-Dateien unterhalb von /usr/lib/kbd/keymaps (SuSE, Red Hat), /usr/share/keymaps (Debian) oder /usr/share/kbd/keymaps (Caldera) zu finden. Allerdings nicht in genau diesem Unterverzeichnis, sondern fein säuberlich sortiert nach Rechner-Architektur (i386, sun, mac etc.) und Keyboard-Layout (qwerty, qwertz usw.).

Die darin liegenden Map-Dateien (z. B. i386/qwertz/de-latin1.map.gz) lassen sich als mit gzip gepackte Textdateien beispielsweise mit dem Befehl zless anschauen (Listing 1 zeigt einen Ausschnitt).

# de-latin1.map: German keymap
[…]
include "qwertz-layout"
[…]
#            Normal    Shift   AltGr      Strg
keycode  1 = Escape    Escape
[…]
keycode 54 = Shift
keycode 56 = Alt
keycode 57 = space     space   Meta_space nul
keycode 58 = Caps_Lock
keycode 86 = less      greater bar
keycode 97 = Control

Wie so oft, leitet ein #-Zeichen am Anfang der Zeile einen Kommentar ein, der keine Auswirkung auf die Funktionalität hat. Interessant ist die Zeile include "qwertz-layout" – statt wirklich alles selbst zu definieren, kann man also auch bereits vordefinierte Keymaps einbinden. Bei den einzelnen Tastenbelegungsdefinitionen steht auf der linken Seite des Gleichheitszeichens ein sogenannter Keycode, rechts davon werden bis zu vier Funktionswerte definiert: einer für den einfachen Druck der jeweiligen Taste, einer für den Tastendruck bei gleichzeitig niedergehaltener [Umschalt]-Taste, ein dritter bei gleichzeitig gedrückter [AltGr]-Taste und ein vierter, wenn die Taste zusammen mit [Strg] gedrückt wird.

Wider das Geschrei auf der Konsole

Netterweise bekommen wir den Keycode von [CapsLock] frei Haus geliefert und können damit sehr schnell die Funktionalität des Quälgeists umdefinieren: Wir erzeugen eine neue Datei namens personal.map, und schreiben dort hinein, dass wir die Taste mit dem Keycode 58 auf Shift-Funktionalität setzen wollen, uns bei der restlichen Belegung aber auf die de-latin1.map verlassen:

include "/usr/share/kbd/keymaps/i386/qwertz/de-latin1.map.gz"
keycode 58 = Shift

(Den Pfad zu de-latin1.map.gz müssen Sie eventuell an Ihr System anpassen.) Testweise auf der Konsole mit

trish@linux:~ > loadkeys personal.map
Loading personal.map

aufgerufen, wirkt das neue Key-Mapping wunderbar: [CapsLock] arbeitet jetzt wie die [Shift]-Taste.

Nützliche Windows-Taste

Um die Windows-Tasten auch auf der Konsole einzusetzen, müssen wir zunächst deren Keycode herausfinden. Netterweise nennt die loadkeys-Manpage im Abschnitt LOAD KERNEL KEYMAP den passenden Befehl: showkey. Einmal eingetippt …

trish@linux:~ > showkey
kb mode was RAW
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]
KDSKBMODE: Die Operation ist nicht erlaubt

… verweigert es in einem X-Terminal logischerweise die Mitarbeit: Ein Beweis für die Unabhängigkeit der Tastaturbelegung mit und ohne X. Auf der Konsole dahingegen (Listing 2) bekommen wir als erstes den Tastencode der [Return]-Taste (28) zu sehen, ehe wir selbst weitere Tasten drücken können. showkey gibt dabei sowohl an, welche Taste jeweils gedrückt (press) und welche losgelassen (release) wurde. Sobald wir alle fraglichen Codes zusammengesammelt haben, ist Geduld angesagt: Kein [Strg-C], kein [Alt-D], nichts außer 10 Sekunden Warten hilft, damit sich das Programm abschaltet.

trish@linux:~ > showkey
kb mode was XLATE
press any key (program terminates 10s after last keypress)…
keycode  28 release[Rechte_Win-Taste]
keycode 125 press
keycode 125 release[Linke_Win-Taste]
keycode 126 press
keycode 126 release[Menü-Taste]
keycode 127 press
keycode 127 release

Jetzt müssen die Tasten mit den Keycodes 125–127 lediglich noch etwas Nützliches zu tun bekommen. Warum sollte die linke Windows-Taste nicht tatsächlich etwas Windows-ähnliches tun, nämlich die grafische Oberfläche starten? (Dies ist allerdings keine sinnvolle Option für Leute, die sich ohnehin grafisch einloggen, denn da läuft X schon.) Die rechte Windows-Taste könnte Datum und Uhrzeit anzeigen, und die [Menü]-Taste naheliegenderweise die letzten 20 Kommandos ausgeben. Aus denen lässt sich mit einem Ausrufezeichen und der Kommando-Nummer (wie in [2] beschrieben) eines aussuchen und erneut (ggf. sogar modifiziert) ausführen.

Alles sehr einfache Aktionen, die man mit den Befehlen startx, date und history 20 auf der Kommandozeile realisiert. Stellt sich lediglich die Frage, wie sie sich mit der jeweiligen Taste verknüpfen lassen. Wieder ist die loadkeys-Manpage hilfreich: Unter der Überschrift LOAD KERNEL STRING TABLE verrät sie, dass man sich damit behilft, die Symbole für ohnehin nicht vorhandene Funktionstasten wie F100, F101 und F102 dem jeweiligen Keycode zuzuweisen:

keycode 127 = F102

Dieses Symbol lässt sich nun mit einem Text belegen, zum Beispiel:

string F102 = "history 20"

Lädt man diese neugeschriebene Keymap, platziert ein Druck auf die [Menü]-Taste tatsächlich den String history 20 auf der Kommandozeile. Man muss ihn nur noch mit [Return] abschicken, und schon wird das Kommando ausgeführt. Allerdings wollen wir uns den Druck auf die [Enter]-Taste sparen; ein Druck auf [Menü] sollte das Kommando history 20 gleich auch abschicken.

Das, was wir mit [Return] eingeben, ist – textuell gesehen – ein Zeilenumbruch. Wenn wir den mit im String verpacken könnten, hätte sich das Problem erledigt. Beim Stichwort “Text ausgeben auf der Kommandozeile” fällt einer der echo-Befehl ein, und einen Zeilenumbruch bekommen wir da mit \n (“newline”) hin:

trish@linux:~ > echo -e "bla\nblub"
bla
blub

Die Analogie passt tatsächlich! string F102 = "history 20\n" in der (nach der Änderung mit loadkeys neu zu ladenden) Keymap sorgt dafür, dass

trish@linux:~ > [Menü]
  926  history 20
[…]
  942  echo -e "bla\nblub"
  943  vi personal.map
  944  loadkeys personal.map
trish@linux:~ > !943

tatsächlich den vi-Editor mit der Datei personal.map aufruft.

# Unsere Code-Map basiert auf
include "/usr/lib/kbd/keymaps/i386/qwertz/de-latin1.map"
# (Pfad angegeben fuer SuSE 7.2, ggf. anpassen)
# CapsLock zu Shift umdefinieren
keycode 58 = Shift
# Rechte Windows-Taste startet X
# (ggf. Pfad zu startx anpassen!)
keycode 125 = F100
string F100 = "/usr/X11R6/bin/startx\n"
# Linke Windows-Taste gibt Datum und Uhrzeit aus
keycode 126 = F101
string F101 = "date\n"
# Kontext-Menü-Taste gibt die letzten 20 Befehle aus
# Shift oder CapsLock und Menü-Taste listet den Inhalt des
# aktuellen Verzeichnisses auf. Ende mit q.
keycode 127 = F102 F103
string F102 = "history 20\n"
string F103 = "ls -Al | less \n"

Neu belegt, gleich beim Booten

Da mit loadkeys geladene Tastenbelegungen auch nach dem Ausloggen ihre Gültigkeit behalten, sollte man sich auf einem Rechner auf eine einzige, für alle Benutzer/innen gültige Keymap einigen. Die auf die individuellen Bedürfnisse zugeschnittene und gut getestete Map (die besprochenen Beispiele aus Listing 3 können als Ausgangsbasis dienen) sollte daher beim Booten geladen werden. Dazu legt root die individuelle personal.map mit gzip gepackt im System-Keymap-Verzeichnis ab.

Doch wer jetzt bei SuSE (bis einschließlich 7.3) den KEYTABLE-Eintrag in der /etc/rc.config ändert, hat zumindest bei SuSE 7.2 die Rechnung ohne den Distributor gemacht. SuSE lädt im Anschluss an die Standard-Map noch verschiedene Tastenbelegungen nach, darunter auch für die Windows-Tasten (nachzuprüfen übrigens mit dem Kommando dumpkeys | less ).

Da hoffentlich das SuSE-Init-Skript /etc/init.d/kbd das einzige ist, das sich um die Tastenbelegung kümmert, empfiehlt es sich, hier den Befehl loadkeys personal.map.gz einzutragen. So unübersichtlich diese Datei auch ist, sie hat glücklicherweise die gängige Syntax eines Start-Stopp-Skripts, in der eine case-Konstruktion festlegt, was zu tun ist, wenn das Skript mit dem Argument start, stop o. ä. aufgerufen wird. In unserem Fall kümmern wir uns einfach nicht um den ganzen unübersichtlichen Wust und schreiben vor das ;;, das den start-Zweig beendet, unsere loadkeys-Zeile.

case $1 in
    start|reload) dies
    ;;
    stop) das
    ;;
esac

Andere Distributionen machen es der Systemverwalterin einfacher und enthalten wie Red Hat ein Skript namens /etc/rc.d/rc.local, das erst ganz am Ende des Boot-Prozesses aufgerufen wird, wenn alle systemseitigen Einstellungen bereits gesetzt wurden. Das Ende dieser Datei ist ein prädestinierter Platz für den Aufruf einer individuellen Keymap.

Und natürlich kann man auch sein einfaches eigenes Init-Skript des Inhalts

#!/bin/sh
loadkeys personal

(die Endung map.gz ist tatsächlich in aller Regel optional, bei manchen Distributionen darf sie sogar gar nicht angegeben werden) im jeweiligen init.d-Verzeichnis ablegen, aus der /etc/inittab den Standard-Runlevel heraussuchen und im jeweiligen rc?.d-Verzeichnis (etwa rc2.d für Runlevel 2) einen Link darauf anlegen. Der Name des Links muss mit S (wie “start”) und einer recht hohen Zahl beginnen. So wird ein Link S100keymap, der auf das Init-Skript zeigt, nach allen Skripten aufgerufen, deren Namen mit S01 bis S99 beginnen.

Tastenbelegungen für KDE

Was auch immer man auf der Textkonsole einstellt – darauf, wie sich die Tastatur unter X verhält, hat das keinen Einfluss. Geht es nur um die Windows-Tasten, so führt der erste Weg einer KDE-Benutzerin ins Kontrollzentrum. Hier lassen sich vorgegebenen Aktionen unter Erscheinungsbild / Tastenzuordnung (KDE 2.1.2, Abbildung 1) bzw. Erscheinungsbild / Tastenkürzel (KDE 3.0, Abbildung 2) bis zum Umfallen Tasten(-Kombinationen) zuordnen.

Abbildung 1: Tastenkürzel zuordnen bei KDE 2.1.2

Abbildung 2: Aktionen zu Tastenkombinationen bei KDE 3.0

Sinnvollerweise sucht man sich zunächst eines der vordefinierten Schemata aus, das den eigenen Arbeitsgewohnheiten bereits sehr nahe kommt. Anschließend markiert man die Aktion, der ein Hotkey zugewiesen (bzw. deren Tastenkombination geändert) werden soll. Nun wählt man im unteren Dialogteil Tastenkombination für die ausgewählte Aktion den Punkt Benutzerdefiniert (KDE 3.0) bzw. Benutzerdef. Taste (KDE 2.1.2) aus.

Das 2er KDE setzt der Phantasie nun ein paar Grenzen: Wer sich nicht mit einer Einzeltaste begnügt (auf den stilisierten Tasten-Knopf aus Abbildung 1 klicken und die gewünschte Taste auf der Tastatur drücken), kann lediglich noch die [Alt]-, die [Strg]- und/oder die [Umschalt]-Taste dazu wählen. Benutzer/innen, die zu oft aus Versehen auf die [Menü]-Taste drücken, werden die Aktion Aufklapp-Menü daher sicher nicht wie in Abbildung 1 auf [Menü] legen, sondern sich beim Öffnen des K-Menüs eher mit [Umschalt-Strg-Alt-Menü] die Finger brechen.

Ein Mausklick auf Schema speichern... sorgt dafür, dass die neue Konfiguration unter einem eigenen Namen gespeichert wird und somit keines der vordefinierten Schemata überschreibt. Drückt man nun noch auf den Button Anwenden, so darf man die neudefinierten Tastenbelegungen endlich auch benutzen.

Abbildung 3: Die Hotkeys zu einer Aktion in KDE 3 definiert man hier

KDE 3 ist noch etwas flexibler. Drückt man die stilisierte Taste im Dialog aus Abbildung 2, so erscheint ein etwas unintuitiver Dialog (Abbildung 3). Hat man vor, der ausgewählten Aktion nur eine Taste zuzuordnen, bleibt der Punkt Mehrere Tasten unangekreuzt, und man darf einfach nur die eine, gewünschte Taste auf dem Keyboard betätigen (zum Beispiel [Menü] bei der Aktion Aufklapp-Menü).

Bei Tastenkombinationen gilt es, nicht nur Mehrere Tasten anzuwählen, sondern auch überlegt beim Eintippen der gewünschten Keys zu Werke zu gehen, sonst hat man schnell einen echten Fingerbrecher kombiniert. Mit dem Punkt Alternativ lässt sich auf dieselbe Art und Weise ein zweiter Hotkey für dieselbe Aktion definieren.

Wer Tastenkombinationen eines vorgegebenen Schemas ändert, bemerkt, dass KDE 3 sofort die Option Neues Schema aktiviert und anwählt. Will man dem einen Namen geben, drückt man auf Speichern (Abbildung 2). Doch auch wenn das zugrundeliegende Schema verändert werden soll, muss man den Weg über Neues Schema und den Speichern-Button gehen: Hier belässt man es im Dialog Tastaturschema speichern (Abbildung 4) einfach beim alten Namen, während ein neues Schema an dieser Stelle neu getauft wird. Zurück im Kontrollzentrum sorgt ein Druck auf den Anwenden-Knopf auch bei KDE 3 dafür, dass das neu- oder umdefinierte Schema “in Kraft tritt”.

Abbildung 4: Soll ein bestehendes Schema verändert werden, belässt man es beim vorgegebenen Namen

Kein CapsLock für X

Doch all diese Änderungsmöglichkeiten nutzen denjenigen nichts, die GNOME, XFce oder Standalone-Window-Manager benutzen – außerhalb von KDE funktionieren die besagten Settings verständlicherweise nicht. Und auch die nervende [CapsLock]-Taste lässt sich so nicht umfunktionieren.

Die Lösung zu diesem Problem setzt beim Fundament an – dem X-Window-System. In dessen grundlegender Konfigurationsdatei XF86Config (meist im Verzeichnis /etc oder /etc/X11 gelagert und für XFree 4 manchmal auch mit einer angehängten 4 im Dateinamen versehen) finden sich die wichtigsten Festlegungen dazu, um was für eine Tastatur es sich handelt und welche Belegung sie haben soll. Die Syntax der Einträge unterscheidet sich dabei zwischen den 3er und 4er Versionen von XFree86 etwas (Listing 4).

# Definitionen für eine PC-Tastatur mit 104 Tasten und deutscher
# Tastenbelegung. Der nodeadkeys-Eintrag bewirkt, dass Akzente
# sofort ausgegeben werden, ohne darauf zu warten, dass das
# naechste Zeichen eines sein könnte, das mit einem Akzent versehen
# werden soll.
# XFree 3                       # XFree 4
Section "Keyboard"              Section "InputDevice"
                                    Driver        "keyboard"
                                    Identifier    "Keyboard[0]"
    Protocol "Standard"             Option        "Protocol"      "Standard"
    XkbRules "xfree86"              Option        "XkbKeyCodes"   "xfree86"
    XkbModel "pc104"                Option        "XkbModel"      "pc104"
    XkbLayout "de"                  Option        "XkbLayout"     "de"
    XkbVariant "nodeadkeys"         Option        "XkbVariant"    "nodeadkeys"
EndSection                      EndSection

Doch wie so viele systemweite Einstellungen ist auch diese für alle User unter X vorgegebene Tastaturbelegung nicht heilig. Mit

trish@linux:~ > apropos key | grep -w X
xmodmap (1x)   - utility for modifying keymaps and pointer button mappings in X
setxkbmap (1x) - set the keyboard using the X Keyboard Extension
xkeycaps (1x)  - graphically display and edit the X keyboard mapping

finden wir mindestens einen sehr interessanten Eintrag: xmodmap zum Festlegen individueller Tastenbelegungen. (Um xkeycaps kümmert sich übrigens Kasten 1.) Ein einfaches xmodmap auf der Kommandozeile, dessen Ausgabe im Tastenkürzel-Reiter Sondertasten unter dem Punkt X-Sondertasten-Zuordnung übrigens auch im Kontrollzentrum von KDE 3 enthalten ist (Abbildung 5), zeigt, welche Tasten als Modifizierer wirken: Zum Umschalten (shift) zwischen den zwei Grundbelegungen (bei Buchstaben zwischen Groß- und Kleinschreibung) kommen die linke (Shift_L) und die rechte (Shift_R) [Umschalt]-Taste zum Einsatz; die [CapsLock]-Taste hält diese Umschaltung fest (lock) usw.

Abbildung 5: KDE 3 integriert die xmodmap-Ausgabe ins Kontrollzentrum

Damit der letzte Effekt aufgehoben wird, müssen wir Caps_Lock aus der Liste der lock-Modifier entfernen. Mit Hilfe der xmodmap-Manpage versuchen wir’s mal mit

xmodmap -e "remove lock = Caps_Lock"

Tatsächlich fehlt die Caps_Lock-Angabe nun in der Ausgabe von xmodmap:

xmodmap:  up to 3 keys per modifier, (keycodes in parentheses):
shift       Shift_L (0x32),  Shift_R (0x3e)
lock
[…]

Nehmen wir Caps_Lock nunmehr mit xmodmap -e "add shift = Caps_Lock" in die shift-Liste auf, ergibt ein Test, dass sich der Nervzwerg plötzlich ganz zahm wie die [Umschalt]-Tasten verhält, und zwar in allen Anwendungen, die auf dem aktuellen X-Server laufen. Der xmodmap-Aufruf spricht demzufolge auch von

shift       Shift_L (0x32),  Shift_R (0x3e),  Caps_Lock (0x42)

Neue Heimat für die Klammern

Bei der Neubelegung der Windows-Tasten müssen wir allerdings ein wenig kleinere Brötchen backen als unter KDE: Menüs zu öffnen, virtuelle Desktops zu wechseln und ähnliches sind Sache des verwendeten Window-Managers. Dem X-Server können wir allerdings sagen, dass die [Windows]-Tasten die auf deutschen Tastaturen erst in Kombination mit [AltGr] erreichbaren geschweiften Klammern ausgeben sollen, während [Umschalt-Windows] für die jeweilige eckige Klammer sorgt.

Dazu brauchen wir zunächst einmal den Keycode der [Windows]-Tasten. Mit dem unscheinbaren Programm xev (Abbildung 6), auf das die xmodmap-Manpage verweist, geht das recht einfach, sofern man sich nicht davon verwirren lässt, dass das Programm im X-Terminal, aus dem heraus es aufgerufen wurde, nicht nur Tastatur-, sondern auch Maus-Ereignisse ungerührt anzeigt. Listing 5 zeigt die Beispielausgabe für Drücken (KeyPress event) und Loslassen (KeyRelease event) der linken [Windows]-Taste (keycode 115) und ihrer rechten Schwester (keycode 116), wenn sich der Mausfokus innerhalb des schwarzen Quadrats im xev-Fenster befindet.

KeyPress event, serial 28, synthetic NO, window 0xe00001,
    root 0x2c, subw 0xe00002, time 1060529679, (30,37), root:(34,57),
    state 0x0, keycode 115 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 characters:  ""
KeyRelease event, serial 28, synthetic NO, window 0xe00001,
    root 0x2c, subw 0xe00002, time 1060529913, (30,37), root:(34,57),
    state 0x40, keycode 115 (keysym 0xffe7, Meta_L), same_screen YES,
    XLookupString gives 0 characters:  ""
KeyPress event, serial 28, synthetic NO, window 0xe00001,
    root 0x2c, subw 0xe00002, time 1060531499, (30,37), root:(34,57),
    state 0x0, keycode 116 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 characters:  ""
KeyRelease event, serial 28, synthetic NO, window 0xe00001,
    root 0x2c, subw 0xe00002, time 1060531733, (30,37), root:(34,57),
    state 0x0, keycode 116 (keysym 0xff20, Multi_key), same_screen YES,
    XLookupString gives 0 characters:  ""

Abbildung 6: Ins schwarze Feld mit dem Cursor und Taste drücken

Jetzt müssen wir nur noch die Bezeichnung für die Klammern herausfinden. Da diese schon auf [AltGr-7] ({), [AltGr-8] ([), [AltGr-9] (]) und [AltGr-0] (}) liegen, sollte das von xmodmap zu erfahren sein. xmodmap -pke | less (-pke steht für “print keymap expression”) heißt das Zauberwort:

keycode  16 = 7 slash braceleft seveneighths
keycode  17 = 8 parenleft bracketleft trademark
keycode  18 = 9 parenright bracketright plusminus
keycode  19 = 0 equal braceright degre

Das sieht so ähnlich aus wie die Map-Datei für die Konsole und zeigt netterweise gleich an, wie man einem Keycode eine Belegung unter X zuordnet. Der jeweils dritte Eintrag rechts vom Gleichheitszeichen dürfte dem Analogieprinzip zufolge der Name der gesuchten Klammer (“brace” – geschweifte Klammer, “bracket” – eckige Klammer) sein. Mit

xmodmap -e "keycode 115 = braceleft bracketleft"
xmodmap -e "keycode 116 = braceright bracketright"

sollten wir damit das Ziel unserer Wünsche erreicht haben.

Haltbar machen

All diese xmodmap-Kommandos kann man natürlich in die persönliche X-Startup-Datei ~/.xinitrc und/oder ~/.xsession eintragen. Doch die in der Manpage angegebene Syntax zu xmodmap …

xmodmap [-options …] [filename]

… legt nahe, die gesamten Tastenbelegungen in einer Datei zu sammeln (Listing 6). Die Manpage schlägt ~/.xmodmaprc vor, Distributionen wie SuSE kümmern sich bereits darum, dass .Xmodmap im Home-Verzeichnis beim X-Starten mit xmodmap eingelesen wird. Beim genauen Studium der Manpage erfährt man so nebenbei, dass Kommentare nicht mit #, sondern mit ! eingeleitet werden.

! Caps_Lock soll nicht mehr sperren
remove lock = Caps_Lock
! … sondern stattdessen als weitere Umschalttaste wirken
add shift = Caps_Lock
! linke Windowstaste = {, plus [Umschalt] = [
keycode 115 = braceleft bracketleft
! rechte Windowstaste = }, plus [Umschalt] = ]
keycode 116 = braceright bracketright

Ein Eintrag xmodmap ~/.Xmodmap in ~/xinitrc (so nicht schon distributonsseitig vorhanden) sorgt nun dafür, dass beim Starten von X mit startx die entsprechenden Keymappings geladen werden. Wer sich mit grafischem Login anmeldet, setzt diesen Befehl in die ~/.xsession.

Doch bei aller Freude über die neugewonnenen Klammer-Tasten stellen KDE-Benutzer/innen fest, dass es für KDE nun praktisch keine [Windows]-Tasten mehr gibt – das sind jetzt Geschweifte-Klammer-Tasten, und ob man ausgerechnet daraus einen Hotkey machen will, ist fraglich …

Abbildung 7: .Xmodmaps selbst erstellen mit xkeycaps

pjung@chekov:~/software/xkeycaps-2.46$ make -n install
if [ -d /usr/X11R6/bin ]; then set +x; \
else (set -x; mkdir -p /usr/X11R6/bin); fi
install -c -s  xkeycaps /usr/X11R6/bin/xkeycaps
echo "install in . done"

Abbildung 8: Bei der Tastenbelegung sollte man sich auf darstellbare Zeichen beschränken