Programmstart direkt durch Kernel-Key-Event (ohne lircrc) auslösen?

Wie kann ich denn unter Debian unabhängig von /etc/lirc/lircrc & irexec einfach bei Auftreten eines Key-Events wie nachstehendem ein Programm starten lassen?

Zitat von ir-keytable -t

Testing events. Please, press CTRL-C to abort.
1429393119.200066: event MSC: scancode = 100015
1429393119.200066: event sync

Nicht lircrc, da bei dessen Verwendung ja nur noch darin (über irexec o.ä.) behandelte Tasten beachtet und deren Codes laut /etc/lirc/lircd.conf dann nicht mehr an (auch auf Clients laufendes) irw oder sonstige Anwendungen weitergeleitet werden.
Kein xbindkeys o.ä., da kein grafischer Desktop.
Konkreter Anlass ist, unabhängig auch vom VDR bestimmte Fernbedienungstasten zur Szenensteuerung zu nutzen, also irsend-Befehle an weitere Geräte absetzen zu lassen.

Danke! Ähnliche Sequenzen habe ich für meine Einsatzorte in bash zusammengestellt.

Läuft denn z.B. unter Debian&Derivaten nicht bereits systemseitig ein standardisierter Handler (außerhalb X11 etc.), der auf Tastendruck (Events) bestimmte Programme (Shellskript etc.) starten kann?
Dann müsste ja kein weiterer wie von Dir in Python zusätzlich auf diese warten (habe headless ARMs im Einsatz, deren Installation natürlich so schlank wie möglich bleiben soll).

Der "Basic setup flow" auf http://www.lirc.org/html/configuration-guide.html scheint mir nicht ganz zu stimmen, denn bei irw (angeblich als "pass 1" vor lircrc) kommt weder auf der LIRC-Maschine selbst noch bei ihrem Client weiter etwas an, sobald lircrc angelegt ist und dadurch automatisch irexec mitgestartet wird.

Zitat von seahawk1986

Nicht dass ich wüsste, Tastatureingaben landen normalerweise einfach auf dem gerade aktiven TTY. Außerdem generiert dein Empfänger laut der Ausgabe gar keine "richtigen" Tastatur-Tastendrücke über den Treiber, sondern liefert mangels keytable zum Übersetzen in ein EV_KEY (vermutlich da er im Lirc-Modus läuft) nur ein EV_MSC mit dem decodierten Scancode, der von der Fernbedienung kommt.

Ja, die Taste hatte ich in /etc/rc_keymaps/Universal8in1 noch nicht eingetragen (der Kernel sollte sie für lircrc ja nicht namentlich kennen müssen), sondern bislang nur in /etc/lirc/lircd.conf definiert.

Damit ich es sprachunabhängig durchschaue:

/dev/input# hexdump -C event2
00000000  07 91 33 55 fc 34 0e 00  04 00 04 00 15 00 10 00  |..3U.4..........|
00000010  07 91 33 55 fc 34 0e 00  00 00 00 00 00 00 00 00  |..3U.4..........|
00000020  08 91 33 55 b6 bf 00 00  04 00 04 00 15 00 10 00  |..3U............|
00000030  08 91 33 55 b6 bf 00 00  00 00 00 00 00 00 00 00  |..3U............|

6 bytes Zeitstempel, 2 Bytes Event, 2 Bytes EV_MSC, 4 Bytes Scancode - d.h. auf diese letzten 4-8 Bytes müsste (m)ein Programm ggf. in Endlosschleife warten?

Durch ir-keytable -c -w /etc/rc_keymaps/Universal8in1 bekanntgemachte Scancodes erzeugen ja nur für Tastatureingaben benötigte zusätzliche key-down/up-Events (also eigentlich nicht nötig, wenn ein Scancode lediglich z.B. eine irsend-Sequenz anstoßen soll) und machten für u.g. Effekt auch keinen Unterschied.

Zitat von seahawk1986

Kannst du deine Konfiguration eventuell ein bisschen genauer beschreiben? Bislang hatte ich keine Probleme damit irexec und einen lirc-Client, der vom Lirc-Socket liest, parallel zu nutzen.

Debian wheezy mit bodhi-Kernel 3.16 erwies sich als stabilstes für Pogoplug E02 in mehreren Installationen, die folgende Aufgaben gemein haben:
/usr/sbin/lircd --device=/dev/lirc0 --listen # mceusb, mit Clients wie VDR bidirektional (inkl. irsend) an LAN-Port 8765
/usr/sbin/LCDd -s 1 -f -c /etc/LCDd.conf # VFD zur Statusanzeige bzw. für vdr-plugin-lcdproc wo vorhanden
iptables # dynamisches Blacklisting v.a. der SSH-Bruteforce-Botnetze
sshd # einzige "Konsole", und Tunnel zu übrigen Maschinen im LAN

/etc/lirc/lircrc sollte im einfachsten Fall z.B. bei Druck auf eine IR- oder RF-Fernbedienung einen LED-Stripe schalten:

begin
 prog = irexec
 remote = Universal_8in1
 button = VPWR
 config = irsend send_once I44 KEY_POWER
end

service lirc restart sorgt dann aber dafür, daß auf irw lokal wie an Clients (obwohl "pass 1" davon doch gar nicht betroffen sein sollte) und auch ir-keytable -t Funkstille einkehrt, bis /etc/lirc/lircrc wieder deaktiviert und lirc restarted wird (es genügt auch noch kein kill auf die PID von /usr/bin/irexec -d /etc/lirc/lircrc).

Starte ich nach service lirc stop
manuell /usr/sbin/lircd --device=/dev/lirc0 --listen
und dann /usr/bin/irexec [-d] /etc/lirc/lircrc_
gibt letzteres (bzw. bei -d dann ircat irexec) nichts aus, aber irw funktioniert weiter.

Dabei fällt auf, daß ircat0.9.0-pre1 -c bzw. --config= nicht annimmt, sondern eine hartcodierte /etc/lirc/lirc/lircrc (also eine Verzeichnisebene "doppelt gemoppelt") verlangt.

Setze ich nun für /usr/bin/irexec -d /etc/lirc/lirc/lircrc statt des Kommandos eine einfache Protokollierung, erscheint diese auch als user.notice in logread:
config = echo irsend | logger

Erstaunlicherweise finde ich dort ohne logger auch Spuren von irsend selbst:

Apr 19 15:13:37 debian daemon.notice lircd-0.9.0-pre1[15911]: accepted new client on /var/run/lirc/lircd
Apr 19 15:13:37 debian daemon.info lircd-0.9.0-pre1[15911]: removed client

Es scheint also speziell irsend im Kontext von irexec ohne Effekt (aber eben auch ohne Fehlermeldung) zu bleiben.

Lagert man irsend mit vorangestelltem sleep 3 && in ein seinerseits mit config = /etc/lirc/lirc/test.sh & abgehängt gestartetes Skript aus, funktioniert es (mit der so erzwungenen Verzögerung).

Schließe ich daraus richtig folgendes?
Bug 1: mceusb ist erst mehrere Sekunden nach letztem Empfang (Loslassen der Taste) sendefähig
Bug 2: lircd-0.9.0-pre1 ist für /usr/bin/ircat und /usr/bin/irexec irgendwo fälschlich festverdrahtet auf /etc/lirc/lirc/lircrc
Bug 3: Die zugehörige /etc/init.d/lirc hingegen versucht irexec dazu nicht passend fest mit -d /etc/lirc/lircrc so zu starten, daß trotz gemeldetem [ ok ] hinterher auch lircd/irw nicht benutzbar ist.

Zitat von seahawk1986

Interessant, das scheint durch die Option für --sysconfdir=/etc/lircd in debian/rules zu passieren. Wenn ich das autoconfigure-Skript richtig interpretiere, sollte das nur auf /etc gesetzt werden (so hat es zumindest Arch Linx gemacht). Warum ircat den Pfad für die Konfigurationsdatei nicht annimmt, ist mir noch nicht klar.

Vielen Dank nochmal!
BTW Debian jessie mit Kernel 3.18.5 (blockierender mceusb-Treiber http://forum.doozan.com/read.php?2,20609,20753#msg-20753, außerdem nftables noch unfertig) und Arch (ALARM) 3.19 konnte ich auf dieser Hardware gar nicht einsetzen.

Zitat von TEN

Bug 1: mceusb ist erst mehrere Sekunden nach letztem Empfang (Loslassen der Taste) sendefähig
Bug 2: lircd-0.9.0-pre1 ist für /usr/bin/ircat und /usr/bin/irexec irgendwo fälschlich festverdrahtet auf /etc/lirc/lirc/lircrc
Bug 3: Die zugehörige /etc/init.d/lirc hingegen versucht irexec dazu nicht passend fest mit -d /etc/lirc/lircrc so zu starten, daß trotz gemeldetem [ ok ] hinterher auch lircd/irw nicht benutzbar ist.

Habe den Startprozess weiter auseinandergenommen und Variationen der /etc/init.d/lirc getestet, wobei mir auffiel, daß eine darin manuell eingetragene /usr/bin/irexec -d zwei solche Prozesse in ps aux sichtbar erzeugt.
Normalerweise fällt das nur nicht auf, weil über start-stop-daemon der zweite nicht mehr gestartet würde.
Ursache scheint mir zu sein, daß u.g. mit grep -r aufgespürte udev-Regel das Startskript nochmals aufruft:

/lib/udev/rules.d/85-lirc.rules:ACTION=="add", KERNEL=="lirc[0-9]", RUN="/etc/init.d/lirc restart udev"
/lib/udev/rules.d/85-lirc.rules:ACTION=="remove", KERNEL=="lirc[0-9]", RUN="/etc/init.d/lirc stop udev"

Wie auch für den VDR selbst funktioniert restart auf /etc/init.d nicht immer zuverlässig (v.a. wenn es ausdrücklich udev dazwischenfunken lässt).

pass 1 / irw bleibt trotz irexec und o.g. Regeln funktionsfähig, wenn man neben dem rmmod aus http://ubuntuforums.org/showthread.php?t=2270362 /etc/init.d/lirc auf den "falschen" Pfad patched und das zwangsweise Beenden der ersten irexec-Instanz aus dem stop-case übernimmt (killall in dieser Distro nicht standardmäßig installiert):

if [ ! -f /etc/lirc/lirc/lircrc ] || grep -q "^#UNCONFIGURED" /etc/lirc/lirc/lircrc; then
        START_IREXEC=false
fi
# ...
case "$1" in
        start)
# ...
                if [ "$START_IREXEC" = "true" ]; then
                        log_daemon_msg "Stopping execution daemon: irexec"
                        start-stop-daemon --stop --quiet --exec /usr/bin/irexec
                        log_end_msg $?
                        log_daemon_msg "Starting execution daemon: irexec"
                        start-stop-daemon --start --quiet --oknodo --exec /usr/bin/irexec -- -d /etc/lirc/lirc/lircrc < /dev/null
                        log_end_msg $?
                fi
                ;;

Bis das ohnehin wegen seiner auf 50µs begrenzten (Un-)Genauigkeit auf meiner Abschussliste stehende mceusb (vgl. http://www.vdr-portal.de/board…besondere-elv#post1241754) ersetzt werden kann, möchte ich die udev-Regeln ungern stilllegen, da dieses Dongle sich unter den meisten anderen Kernels gerne mal aufhängt und seit es diese gibt dann durch Ab- und Wiederanstecken reaktiviert werden kann.