remote-plugin nutzt exklusiven Zugriff auf /dev/input/eventX und blockiert andere Programme

dile · 27. Juli 2019

Hallo,

da Lirc ja veraltet ist und jetzt alles direkt über den Kernel gelöst wird, wollte ich mich jetzt auch komplett von Lirc verabschieden. Bisher habe ich Kodi, VDR und irexec mit Lirc genutzt. irexec wird verwendet um zwischen Kodi und VDR hin- und herzuschalten und um ein paar Steckdosen an- und auszuschalten.

Ich habe jetzt triggerhappy als alternative zu irexec installiert und eingerichtet. (Das Programm führt direkt ein Script aus wenn über /dev/input/eventX der entsprechende Tastendruck kommt. ) VDR habe ich mit dem remote-plugin eingerichtet damit die Fernbedienung direkt funktioniert und Kodi funktioniert auch direkt über die /dev/input/eventX

Jetzt habe ich das Problem, dass wenn der VDR gestartet wird, dieser scheinbar exklusiven Zugriff auf /dev/input/eventX hat und triggerhappy die Signale der Fernbedienung nicht mehr bekommt. Sobald der VDR beendet wird dann funktioniert triggerhappy wieder. Bei Kodi und Triggerhappy tritt das Problem nicht auf.

Ich verwende Debian und kann mit dem folgenden Befehl von Triggerhappy auch nachvollziehen das die Signale nur angezeigt werden wenn der VDR nicht läuft.

Code

thd --user nobody --deviceglob /dev/input/event* --dump

Leider habe ich beim remote-plugin keinen Parameter gefunden mit dem ich einstellen kann, dass der Zugriff nicht exklusiv stattfinden soll. Hat da jemand einen Tipp für mich oder geht das mit dem remote-plugin nicht ?

Vielen Dank für eure Hilfe.

Gruß dile

Dr. Seltsam · 28. Juli 2019

schreib doch mal den Autor UFO bzw. Oliver Endriss an.

Bei einem kurzen Blick in den Code fällt mir auf, dass das Plugin das device ohne den nonblocking-Parameter öffnet:

Code

default:
fh[i] = open(devnam[i], O_RDONLY);

Ob das in remote.c so

Code

default:
fh[i] = open(devnam[i], O_RDONLY|O_NONBLOCK);

nun funktioniert, ob der Treiber das überhaupt unterstützt oder was es evtl. für Nachteile hat, kann ich mit meinem gefährlichen Halbwissen aber auch nicht sagen.

M-Reimer · 28. Juli 2019

Das würde garnichts ändern.

Die relevanten Zeilen sind:

Code

    if (ioctl(f, EVIOCGRAB, data) == 0)
        dsyslog("%s: exclusive access granted", name);

in remote.c

Die beiden kommentieren und das Device wird nicht mehr "blockiert".

Keine Ahnung warum man sich im Remote-Plugin entschieden hat das Input-Device "exklusiv" haben zu wollen und vor allem warum es keine Option gibt das abzuschalten.

Ich könnte mir vorstellen, dass man das auch ohne Plugin-Patchen hinbasteln kann wenn man ein Perl-Script beim VDR-Start das Device exklusiv öffnen lässt (dann schafft es das remote-Plugin nicht den exklusiven Zugriff zu bekommen) und dieses Perl-Script sich dann einfach zu einen bestimmten Zeitpunkt (ggf. zeitgetriggert) selbst beendet (und damit faktisch den eigenen exklusiven Zugriff aufgibt).

dile · 29. Juli 2019

Zitat von M-Reimer
Die relevanten Zeilen sind:
Code
    if (ioctl(f, EVIOCGRAB, data) == 0)
        dsyslog("%s: exclusive access granted", name);
in remote.c

Ich habe das Plugin auf meinem Testsystem einmal ohne diese beiden Zeilen neu gebaut und tatsächlich funktioniert es damit und ich habe mit triggerhappy Zugriff auch wenn der VDR läuft.

Schon einmal vielen Dank

Zitat von M-Reimer

Ich könnte mir vorstellen, dass man das auch ohne Plugin-Patchen hinbasteln kann wenn man ein Perl-Script beim VDR-Start das Device exklusiv öffnen lässt (dann schafft es das remote-Plugin nicht den exklusiven Zugriff zu bekommen) und dieses Perl-Script sich dann einfach zu einen bestimmten Zeitpunkt (ggf. zeitgetriggert) selbst beendet (und damit faktisch den eigenen exklusiven Zugriff aufgibt).

Da habe ich leider gar keine Ahnung wie ich das machen kann.

Gruß dile

dile · 29. Juli 2019

Ich habe den Plugin Autor einmal angeschrieben und hoffe das man den exklusiven Zugriff in einer zukünftigen Version per Option einstellen kann.

Gruß dile

Hollywood · 3. August 2019

Hallo,

gibt es eigentich noch weitere Alternativen zu irexec ? Ich suche schon länger etwas was wie irexec auch doppelte Tastendrücke auswerten kann.

triggerhappy habe mich mir angesehen. Das kann auf einen gehaltenen Tastendruck reagieren was auch eine Alternative wäre, führt dann aber einen Repeat aus sodaß mein Script dann mehrfach gestartet werden würde. Um mit einem Sccript z.B. zwischen Kodi und VDR zu wechseln ist das natürlich nicht geeignet.

Kennt da jemand eine Lösung ?

Gruss

Stefan

seahawk1986 · 3. August 2019

Bei yavdr-ansible ist es so gelöst, dass die Fernbedienungen von eventlircd augewertet werden (über udev-Attribute kann man steuern, was als Fernbedienung gilt und der X-Server wird dann per Konfiguration dazu gebracht deren Tastendrücke zu ignorieren, wenn eventlircd gerade nicht läuft, so dass es beim Start die Geräte exklusiv öffnen kann). Sowohl der VDR als auch KODI und irexec können dadurch von einem Lirc-Sockel lesen.

Um das VDR-Frontend, KODI und weitere Anwendungen zu verwalten, gibt es ein Frontend-Skript. Das bietet u.a. eine DBus-API, die über Shell-Befehle aus dem VDR-OSD (menuorg-Plugin, desktop-Plugin, commands.conf), irexec usw. angesteuert werden kann. Das Umschalten zwischen VDR und KODI ist damit recht bequem möglich, für irexec sieht das z.B. so aus: https://github.com/yavdr/yavdr…ktop/templates/.lircrc.j2

Hollywood · 3. August 2019

Auf meinem Server mache ich das mit Lirc und starte mittels irexec verschiedene Scripte, klappt dort wunderbar.

Auf meinem Client läuft kein Lirc, da mache ich es ähnlich wie im Eingangspost beschrieben (Kerneltreiber nuvoton-cir). Und hierfür suche ich eine Möglichkeit um eine Taste mit mehreren Funktionen, durch Doppel- oder langen Tastendruck zu belegen um darüber dann verschiedene Scripte auszuführen.

Triggerhappy kommt schon in die Richtung, kann aber keine doppelten Tastendrücke auswerten.

remote-plugin nutzt exklusiven Zugriff auf /dev/input/eventX und blockiert andere Programme

Jetzt mitmachen!

Teilen