Hardware-Tasten unter Linux unabhängig von Desktop-Umgebung nutzen

Eines vorweg, es ist keine Musterlösung und bestimmt auch nicht die eleganteste bzw. bequemste. Aber es ist eine Lösung, die einem (neben dem eigentlichen Ziel) einen etwas tieferen Einblick in das System ermöglicht. Vorteil für die, die wissen wollen, was eigentlich unter der Haube passiert.

Vorwort und Begriffsklärung

Um im weiteren Verlauf des Artikels den Überblick zu bewahren, sei hier ein Mal ganz kurz und ohne ausführlichen Erklärungen dazu einfach die grobe Funktionsweise eines Hardware-Key-Bindings auf einem Xserver dargestellt.

Der Kernel liefert bei einem Tastenanschlag den sog. scancode. Es ist eine hexadezimale Zahl, mit der der Xserver noch nicht viel anfangen kann. Dieser scancode muss dem sog. keycode zugeordnet werden (dezimale Zahl). Dieser keycode sollte dann wiederrum an Xserver's interne Symbole, die keysyms "gemappt" werden. Ein solcher Symbol kann ein ganz normaler Buchstabe sein, oder ein Sondersymbol, das keine Zeichen im eigentlichen Sinne produziert, sondern als einer Art Trigger für einen Befehl dienen kann.

Grob kann man also sagen:
Kernel's scancode -> keycode -> keysym -> evtl. Befehl

Wichtig: ich schreibe es in der "Umbruchsphase" von X, d.h. im Chaos des Versionswechsels von xorg 1.4 zu dem hotplugfähigen (hal-enabled) xorg 1.5 und die 1.6 ist schon im Anmarsch (testing in Archlinux). Desweiteren wird an dem evdev-Treiber fleißig rumgeschraubt, so dass Vieles aus diesem Artikel bereits jetzt veraltet sein könnte.

Events des X Servers auslesen

Idealerweise wird der Tastenanschlag als ein keycode bereits von X Server registriert und man kann es mit xev auslesen. Um das zu testen, öffnet man einen Terminal und startet den erwähnten xev. Wenn das xev-Fenster erscheint und im Fokus ist, drückt man auf die Hardware-Taste und beobachtet den output. Bei mir sieht es folgendermaßen aus:

Wie man sieht, registriert X meinen Tastenanschlag mit dem keycode 208. Einer wird ich wahrscheinlich wundern, warum bei mir die Taste bereits auf keysym "XF86AudioPlay" gemappt ist. Eines kann ich dazu sagen - ich habe mich auch gewundert, da ich es nicht eigenhändig gesetzt hatte.

Auch zu beachten ist, dass das Drücken und das Loslassen einer Taste in manchen Fällen unterschiedliche Keycodes liefern kann.

Falls bei jemandem kein keycode angezeigt wurde, dann muss man eben noch den scancode an keycode binden - siehe Abschnitt "Kernels Scancodes auslesen und den Keycodes zuweisen", bevor man mit "Den Keycodes die Keysyms zuweisen" fortfährt.

Den Keycodes die Keysyms zuweisen mit xmodmap

Für diese Aufgabe möchten wir nun so nah wie Möglich am X arbeiten. Für diese Zwecke verwenden wir das Werkzeug xmodmap. Dieses Tool liest sich die Zuweisungen aus der Datei .Xmodmap, die im User-Verzeichnis angelegt wird, beim Starten von X heraus. Bei manchen Distributionen kann dies auch ~/.xmodmaprc sein. In meinem Fall hat es mit der ersten funktioniert. Unter Umständen, kann man xmodmap auch aus der shell aufrufen mit:

xmodmap /pfad/zur/.Xmodmap-Datei

Falls nicht vorhanden, erstellen wir die Datei ~/.Xmodmap. Für meine Taste (siehe xev-Ausgabe) füge ich in die Datei folgendes hinzu:

keycode 208 = XF86RotateWindows

Hier wird der keycode and das Symbol "XF86RotateWindows" gebunden. Man darf hier keine eigene Symbole erfinden. Am besten nutzt man die Symbole "F21" bis "F246". Ich fand nur, dass "XF86RotateWindows" gut zu meinem Ziel, den Bildschirm per Tatendruck zu drehen, passen würde. Falls es jemanden wirklich interessiert kann sich eine Liste mit dem Befehl

dumpkeys -l
 

anzeigen lassen. Weitere XFree86-Symbole (fangen mit XF86 an) sind ohne Probleme bei Google zu finden oder direkt im Quellcode - bei mir in /usr/include/X11/XF86keysym.h.

Nach dem Eintrag in ~/.Xmodmap startet man entweder X neu oder führt xmodmap manuell aus. Nun müsste xev uns den gewünschten keysym beim Tastenanschlag zeigen:



Hier gibt es ein Problem. Zwar wird der keysym richtig dem keycode zugeordnet, aber es scheint als ob der keysym bereits für einen anderen keycode (162, sagt der gute) verwendet wird.
Man kann jetzt entweder einen anderen keysym auswählen, oder sicherstellen, dass er nur einmal vorkommt - also die Zuordnung(en) zu anderen keycodes entfernen. Mit

xmodmap -pke | grep XF86RotateWindows

werden alle keycodes gelistet, den das Symbol zugeordnet ist. Bei mir ist es nur die 162.
Was ich zu tun habe ist in der ~/.Xmodmap einen weiteren Eintrag hinzufügen:

keycode 162 = NoSymbol

Damit "enteignen" wir den keycode 162

Und so sieht die xev-Ausgabe nach dem "Säubern" der xmodmap:


Bemerkung: "xmodmap -pke" gibt die aktuell verwendete xmodmap in der Form zurück, mit der die Konfigurationsdatei "gefüttert" werden kann (siehe "man xmodmap").

Nun geht's weiter mit dem Zuweisen des Befehls, der beim Tastenanschlag ausgeführt werden soll.

Zuweisen des Befehls an keysym mit xbindkeys

Ich habe da ein kleines bash-Script, welches mir mit Hilfe von xrandr meinen Bildschirm um 90° um Uhrzeigersinn dreht, das beim Drücken der Taste ausgeführt werden soll.

Als Werkzeug, welches uns helfen wird den keysym and diesen Skript zu binden, empfehle ich xbindkeys. Schlank, leicht konfigurierbar und nur von X abhängig. Nach dem Anlegen der Konfigurationsdatei ~./xbindkeysrc muss ein Eintrag nach folgendem Schema hinzugefügt werden:

"Befehl_zum_ausfuehren"
    KeySymbol

Ich habe für meinen Button stehen:

"/usr/local/bin/rotatetablet"
    XF86RotateWindows

Führt man jetzt das Kommando xbindkeys aus, wird der angegebene Befehl beim nächsten Tastenanschlag ausgeführt. Damit es auch nach dem Neustart so ist, muss xbindkeys immer nach dem starten von X ausgeführt werden. Session-unabhängig macht man das in der ~/.xinitrc. Damit wäre man mit den Zuweisung der Hardware-Taste fertig. Nach Bedarf kann man die entsprechenden Einträge für weiteren Tasten/Buttons machen. Nach 1-2 Tasten geht es dann sogar relativ flott.

Bemerkung: Wenn man ein Skript in xbindkeys als Befehl angibt, muss der Skript natürlich ausführbar sein. Auch ob besondere Rechte notwendig sind, muss beachtet werden.

Kernels Scancodes auslesen und den Keycodes zuweisen

Wenn man kein Glück hatte und xev keinen Keycode lieferte, geht's eine Stufe näher dem Kernel herab.
Auf dem x41t liefert bei mir eine kleine Reset-Taste keinen X event. xev bleibt also stumm.

Normalerweise sollte man mit showkey -s (als root) nach einem Tastenanschlag den scancode geliefert bekommen. Bei mir war das leider auch nicht der Fall. Erst mit dem Tool evtest (Quellcode hier), gelang mir das Auslesen. Kompilieren kann muss man es mit

gcc -o evtest evtest.c

Nun lässt man die kompilierte Datei als root laufen mit einem Device als Agument, das evdev für den Keyboard-Input nutzt (eines aus den /dev/input/eventX). Rausfinden welches  Device man braucht kann man mit:

egrep -e ".*keyboard.*/dev/input/event[0-9]{1,2}.*" /var/log/Xorg.0.log

Der evtest-Aufruf müsste als root erfolgen und etwa so aussehen (Device ggf. ändern), wenn man sich im Verzeichnisbefindet, in dem die kompilierte Datei liegt:

./evtest /dev/input/event1

Wenn man jetzt die Hardware-Taste betätigt, wird der scancode geliefert. Bei mir sieht es so aus:
Der scancode ist also "67". Dieser scancode muss nun einem keycode mit Hilfe von setkeycodes, am Besten direkt beim Booten zugeordnet werden (wie man Skripte/Befehle beim Systemstart ausführt, werde ich hier nicht erzählen, Hint: init-Skripte). Das Zuordnen passiert sehr einfach:

 Outro

 Natürlich ist es etwas viel z.T. unnötiger Arbeit für die Meisten auf diesem Planeten. Ich denke, dass ich in dieser Hinsicht ein Puritaner... nein, ein Dinosaurier bin sogar. Ich mag's halt, wenn es transparent ist, in den Zeiten von dem undurchsichtlichen Konfigurationsdschungel der "YetAnotherKickassWay"-Tools.
Zwar ist die Zielgruppe dieses Artikels schwindend gering, aber hoffentlich sucht jemand ausgerechnet diese Info und findet diese hier. Und wenn nicht, dann tut es halt meinem Ego gut.