X.Org, evdev und HAL - Teil 3

Technobabble-Warnung

Eigentlich dachte ich, das Problem aus dem Zusammenspiel von X11, Multimedia-Tastatur, evdev-Treiber, HAL und LinEAK sei gelöst gewesen - doch hat "roo" mich in den Kommentaren darauf aufmerksam gemacht, dass mit dem xorg.conf-Schalter “AutoAddDevices = no" einfach nur HAL deaktiviert wurde. Das funktioniert zwar, ist aber nicht das, was man gerne haben möchte - nämlich die Verwaltung aller Eingabegeräte an einer zentralen Stelle, im "Hardware Abstraction Layer".

Nun hat "roo" am Dienstag einen weiteren Kommentar geschrieben, den ich jedoch übersehen habe:

Also ich hab herausgefunden, dass das Problem nicht bei HAL, nicht bei evdev und auch nicht bei X liegt. Sondern beim Desktop Environment - sprich Gnome/Xfce/KDE. Habe nämlich mal Fluxbox emerged und damit mal probiert (Fluxbox lässt sich ja fix emergen und starten). Und dort habe ich diese Probleme nicht. Alle Tasten werden von xev perfekt erkannt. Und verursachen keine Probleme.

Tatsächlich hatte ich auch schon eigene Experimente durchgeführt, und bin zu dem gleichen Ergebnis gekommen: Unter Fluxbox kann ich alle Tastencodes der Spezialtasten mit xev beobachten, unter XFCE jedoch nicht die Lautstärketasten - und ausgerechnet die hatte ich in meinem letzten Beitrag meistens zum Testen verwendet.

In der Ausgabe von xev sind mir dann jedoch einige Details aufgefallen (hier als Beispiel für die Taste "Startseite"):

 KeyRelease event, serial 33, synthetic NO, window 0x4c00001,
 root 0x7e, subw 0x0, time 39405674, (136,70), root:(747,528),
 state 0x10, keycode 180 (keysym 0x1008ff18, XF86HomePage), same_screen YES,
 XLookupString gives 0 bytes:
 XFilterEvent returns: False

Diese Taste hat bei einem "Microsoft Comfort Curve Keyboard 2000" normalerweise den Keycode 130, wie ein kurzer Blick in die Datei /etc/lineakkb.def zeigte - und nicht 180, wie xev behauptet. Eine Tastatur, bei der dieser Knopf den Tastencode 180 sendet, ist in dieser Datei überhaupt nicht verzeichnet! Dies - und die korrekte Erkennung des "keysym" als "XF86HomePage" - brachte mich dann aber auf die richtige Spur.

Diese Kombination von Tastencode und Keysym (180 = HOMEPAGE) findet sich in der Datei "/usr/share/X11/xkb/keycodes/evdev" wieder. Anscheinend (ich habe dazu überhaupt keine Dokumentation gefunden, korrigiert mich, falls ich wieder falsch liege) haben die Entwickler mit dem Umstieg auf HAL einen meiner Meinung nach richtigen Schritt getan und die Zuordnung der Spezialtasten in den Treiber verbannt, und es nicht mehr der Anwendung überlassen, diese Tasten richtig zu interpretieren. Der Anwendungsentwickler kann sich also nun drauf verlassen, dass der Tastaturcode 180 gesendet wird, wenn der Benutzer die Taste "Startseite/Web/Homepage" drückt - egal, welches Modell er besitzt. Eine gute Idee, nur hätte man dies ein bisschen besser Dokumentieren können.

Was aber hatte nun zu dem beobachteten Problem geführt? Bisher (vor HAL) konnte XFCE mit meiner Tastatur und insbesondere den "XF86Audio"-Tasten für die Lautstärke nichts anfangen. Die Keycodes wurden also weitergereicht und konnten von der Anwendung - z.B. LinEAK - verarbeitet werden. Nach dem Wechsel auf den HAL-basierten evdev-Treiber erkannte XFCE die Tasten dann selbst und wollte sich drum kümmern; was jedoch nicht gelang, da mir die verwendete Hilfsanwendung "aumix" fehlte. Die Befehle hatten also keinerlei Reaktion mehr zur Folge, kamen aber auch nicht mehr bei lineakd an.

Und was ist nun die Lösung? Nun, entweder kann man seine Shortcuts in den Window-Manager übertragen und diesem die Ausführung überlassen. Bei XFCE geht man dazu in die "Einstellungen" (Settings), dann in die "Tastatureinstellungen" (Keyboard Settings) und dort auf "Tastenkürzel" (Shortcuts). Hier legt man sich ein neues "Schema" an und definiert dort die gewünschten Aktionen. Nachteil: Die Shortcuts funktionieren nur innerhalb von XFCE, nicht unter KDE oder Gnome (es sei denn, man richtet sie dort ebenfalls ein).

Will man die Verwaltung der Multimediatasten weiterhin LinEAK überlassen, wird es etwas aufwendiger. Zunächst muss man die Verknüpfung des Window-Managers mit den Shortcuts beseitigen. Dies geht bei XFCE ebenfalls über ein neues "Schema", nur dass man dieses mal die mit "XF86" beginnenden Verknüpfungen löscht. Anschließend muss man die "evdev-Tastatur" bei LinEAK bekannt machen. Dazu läd man am besten die Datei lineak-evdev.def herunter und hängt sie (als root) an die Datei /etc/lineakkb.def an:

$ cat lineak-evdev.def >> /etc/lineakkb.def

Nun kann man sich mit dem Befehl lineakd -c EVDEV eine neue Konfigurationsdatei $HOME/.lineak/lineakd.conf erzeugen und anschließend wie gewohnt mit Leben füllen. Dabei aber bitte beachten, dass diese Keyboard-Konfiguration sämtliche über evdev verfügbaren Tastencodes beinhaltet, unabhängig davon, ob die Befehle auf der eigenen Tastatur überhaupt vorhanden sind.

Mein Dank geht an "roo", für den Anstoß, mich noch einmal tiefergehender mit dem Problem zu geschaffen.

Der Vollständigkeit halber hier auch nochmal meine nun funktionierende /etc/hal/fdi/policy/10-x11-input.fdi, da in der letzten Version ein Fehler drin war (es muss "input.xkb" statt "input.x11_options" heißen):

<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
  <device>
    <match key="info.capabilities" contains="input.mouse">
      <merge key="input.x11_driver" type="string">evdev</merge>
    </match>

    <match key="info.capabilities" contains="input.keyboard">
      <merge key="input.x11_driver" type="string">evdev</merge>
      <merge key="input.xkb.model" type="string">evdev</merge>
      <merge key="input.xkb.layout" type="string">de</merge>
      <merge key="input.xkb.rules" type="string">xorg</merge>
    </match>
  </device>
</deviceinfo>

• #gentoo
• #linux
• #patch