Präsentiere: input-event-daemon v0.1.3

Guten Abend allerseits,

hiermit möchte ich meine aktuelle Zeitverschwendung der Epoche auch abschliessen. Wer sich ein bisschen mit Linux beschäftigt, der weiss, dass Sondertasten (z.B. Lautstärketasten auf Laptops) zur Zeit in der Regel nur von der Desktop-Umgebung behandelt werden.

Will man seine Lautstärketasten auch in der Konsole ohne X11 benutzen, dann ist die Alternative dazu ist dann meistens nur acpid (den ich nicht mag und der nur acpi-events kann) oder hal-basierte Lösungen wie halevt (hal mag ich nicht und es stirbt eh bald aus).

Also hab ich aus der Not eine Tugend gemacht und mir selber ein 1000-Zeiler in C geschrieben, der das auf das Linux-Input-Subsystem horcht und da Befehle bei bestimmten Tastendrücken ausführt.

"Screenshot":

[root@ThinkPad ~]# input-event-daemon --monitor
input-event-daemon: Monitoring mode started. Press CTRL+C to abort.


/dev/input/event12:
  keys     : BTN_LEFT


/dev/input/event1:
  keys     : CTRL + ALT + J


/dev/input/event7:
  keys     : PROG1


/dev/input/event7:
  switch   : RADIO:0


/dev/input/event11:
  switch   : HEADPHONE_INSERT:1


/dev/input/event7:
  keys     : SCREENLOCK


/dev/input/event1:
  keys     : SHIFT + S

Ob ihr damit nur die Lautstärketasten auf amixer mappt oder beim einstecken der Kopfhörer automatisch den MP3-Player startet ist euch überlassen. Das Tool hört auf Tastendrücke (Keyboard- und Maustasten, teilweise auch Joystick-Tasten, je nach Treiber) und Switches (Killswitches, Notebook-Lids und Kopfhörerbuchsen, je nach Treiber). Das Tool ist relativ flexibel, mit dem Parameter --monitor könnt ihr mal horchen was so alles für Input-Events genereriert werden und danach eine Config schreiben.

Ja, schaut auch die Dokumentation an, an dieser Stelle noch meinen Dank an Griggi und oreissigs fürs Korrekturlesen.

Achja, Linux 2.6 (vermutlich sogar ab 2.6.16 oder so) ist zwingend nötig. Auch müssen die Kernel-Header installiert sein (linux-api-headers bei Arch Linux, linux-kernel-headers bei Debian/Ubuntu).

Manpage der Version 0.1.0 als HTML:
input-event-daemon-0.1.0.html (17,84 KB)

Quellcode & mehr: gandro's input-event-daemon at master - GitHub
Download: http://github.com/gandro/input-event-daemon/tarball/v0.1.3

Version 0.1.1 ist draussen. Nur Rechtschreibfehler und einen Mini-Memory-Leak gefixt.

Keine Ahnung ob das langsamer als X11 ist. Falls ja fallen mir nur drei Theorien ein, denn ich fange die Events direkt vom Kernel ab, genau wie es auch Xorg tut.

a) Läuft der Tastaturdaemon von X11 mit einer höheren Priorität.

b) Ist mein Daemon recht langsam beim auffinden des passenden Events (lässt sich ggf. noch verbessern), dann dürfte er im Monitoring-Mode aber nicht langsamer sein als X11, weil da wird kein Event gesucht, sondern nur ausgegeben.

c) Wartet mein Daemon anders als die meisten X11-Programme auf ein Release. Der Event wird erst getriggert, wenn ihr die Taste wieder loslässt, nicht wenn ihr sie drückt.

Bezüglich Amilayout: Mein Daemon kümmert sich gar nicht um um irgendwelche Tastaturlayouts, sondern gibt exakt das aus, was hardwaremässig von der Tastatur kommt, ohne jegliches Mapping, und das ist wohl auch bei deutschen Tastaturen auf der Y-Taste dann wohl doch der Z-Keycode.

Je nach dem kann ich eine Funktion einbauen, die auch bereits beim Drücken ein Event auslöst. Aber Standardmässig möchte ich das nicht haben, nur schon weil die meisten Tastaturen ja anfangen den Tastendruck zu wiederholen und dass dann auch mehrere Events auslöst.

AUR (en) - input-event-daemon

Paket im AUR, inkl Initscript. Versionsupdate auf 0.1.2 (paar Makefile-Korrekturen, damit es auch ein anständiges Paket gibt).

Zitat von DosAmp

“A deamon”? Das schreit nach Korrektur. :>

Grml. Fixed.

Version 0.1.3 ist draussen (und im AUR).

Einzelne Tasten werden jetzt bereits beim Drücken getriggert. Damit sollten einzelne Tastendrücke gleichzeitig oder sogar vor X11 erwischt werden (meine Lautstärkeanzeige unter XFCE ist jetzt synchron, vorher hinkte sie nach, das ist auch der Hauptgrund warum ich das Verhalten geändert habe).

Tastenkombinationen werden nach wie vor erst beim loslassen getriggert (d.h. bei CTRL+ALT+D wird zuerst CTRL alleine getriggert und als nächstes dann die ganze Tastenkombo (ALT und D werden nie separat getriggert)).

Zudem wird der RESET-Befehl im [Idle] Abschnitt jetzt immer ausgeführt, falls nach min. 750ms Leerlauf eine Taste gedrückt wird (und nicht mehr wie vorher erst wenn min. ein Event getriggert wurde).

Zitat von YAL

BTW: Hat wer ne Idee, wie ich jack sensing zum laufen bekomm?

Auf meinem ThinkPad macht das Input-Event direkt der ALSA-Treiber (snd-hda-intel), und der kann das wohl auch nicht auf jeder Hardware.

Also du sprichst nicht vom Monitoring-Mode, sondern davon, dass ein Event nur von input-event-daemon geparst werden sollte und der dass dann blockiert..?

Müsst ich schauen ob das machbar ist. Ich bezweifle es, weil ievd die Events auch nicht zwingend als erster Kriegt (sondern "gleichzeitig" mit XOrg und so).

Man kann zwar Tasten vorher remappen, aber bei Tastenkombinationen sieht das anders aus. Aber ich schau nachher mal.

Ich hab mich noch ein bisschen mit der Sache beschäftigt.

evdev, der Teil das Linux-Input-Subsystemes den ich verwende bietet keine Möglichkeit einzelne Events zu stoppen. Alles was ich kann ist das gesamte Gerät zu blockieren, dass nur noch ich es haben darf.

Die einzige Möglichkeit wäre es also ein Gerät zu blockieren und eine zweite Tastatur zu emulieren, welche alle nicht behandelten Tastendrücke ausgibt, nur müsste dann input-event-daemon jeweils immer vor Xorg gestartet werden (falls Xorg mit einer solchen Handhabe überhaupt klarkommt) und sonderlich elegant oder resourcenschondend ist es auch nicht.

Nachtrag: Im übrigen bin ich nicht der einzige der sich da etwas mehr Flexibilität wünschte.[1] Aber bisher ist da afaik nichts passiert.

[1] http://lkml.org/lkml/2007/6/9/59