OpenELEC ist jetzt auch in meinem git.
Da die lirc rausgeworfen haben, und lircd-uinput die lirc lib braucht, musste ich erst mal lircd-uinput so kompilieren, dass es die lib an einer Stelle sucht, an die ich sie hinlegen kann.
OpenELEC ist jetzt auch in meinem git.
Da die lirc rausgeworfen haben, und lircd-uinput die lirc lib braucht, musste ich erst mal lircd-uinput so kompilieren, dass es die lib an einer Stelle sucht, an die ich sie hinlegen kann.
Auf Ubuntu 18.04 Desktop versucht.
sudo add-apt-repository ppa:yavdr/experimental-main
sudo apt-get update
sudo apt-get install irmplircd
cd /etc/irmplircd
wget https://raw.githubusercontent.com/j1rie/IRMP_STM32/master/irmplircd/yaVDR/irmp.map
mv irmp.map irmplircd.map
sudo apt-get install lircd2uinput
sudo apt-get install eventlircd
cd /lib/udev/rules.d
mv 98-eventlircd.rules.disabled 98-eventlircd.rules
Fehlermeldung:
Jan 20 15:55:28 ubu dbus-daemon[608]: [system] Service file "/usr/share/dbus-1/system-services/de.yavdr.lircd2input.service" should have been named "de.yavdr.lircd2uinput.service"and will not work with system bus activation
Ich muste von Hand:
und eventuell auch, aber da bin ich nicht mehr sicher:
Dann ging es.
Läuft ohne Nachbessern noch nicht ganz rund.
Ich passe den Dateinamen mal im Paket an. Wenn du lircd2uinput zusammen mit irmplircd nutzen willst, solltest du das Paket yavdr-hardware-irmp installieren, das zieht die benötigten Abhängigkeiten und ergänzt das in yaVDR und [irmp]lircd Fernbedienungen – eine grundsätzliche Frage erwähnte Drop-In für die Systemd-Unit.
So, das neue lircd2uinput Paket ist im PPA, damit sollte die DBus-Activation wieder funktionieren.
Danke, werde ich mal probieren.
Wenn ich mich richtig erinnere, hat er yavdr-hardware-irmp automatisch mit installiert bei sudo apt-get install irmplircd.
Eigentlich ist yavdr-hardware-irmp das Paket, das irmplircd und lircd2uinput als Abhängigkeiten zieht - in debian/control des Quellpakets ist das auch so definiert:
Package: irmplircd
Architecture: any
Description: USB IRMP Client ...
Package: yavdr-hardware-irmp
Architecture: all
Depends: irmplircd, lircd2uinput
Description: yaVDR integration for irmplircd
Das Paket yavdr-hardware-irmp wird auch von der Ansible-Rolle für die Erkennung eines IRMP-Empfängers installiert: https://github.com/yavdr/yavdr…dware-irmp/tasks/main.yml
Dann wäre der richtige Weg yavdr-hardware-irmp zu installieren, und alles andere kommt automatisch mit?
Und bei Ansible sogar ganz automatisch?
Nebenbei, es gibt eine neuere Version von irmplircd, in deinen ppa's ist noch die Alte.
Dann wäre der richtige Weg yavdr-hardware-irmp zu installieren, und alles andere kommt automatisch mit?
Und bei Ansible sogar ganz automatisch?
Ja, so ist das gedacht.
Nebenbei, es gibt eine neuere Version von irmplircd, in deinen ppa's ist noch die Alte.
Ich habe gerade eine aktualisierte Version für bionic und xenial hochgeladen.
Zweiter Versuch auf Ubuntu 18.04 bionic Desktop.
sudo add-apt-repository ppa:yavdr/experimental-main
sudo apt-get update
sudo apt-get install yavdr-hardware-irmp
cd /etc/irmplircd
wget https://raw.githubusercontent.com/j1rie/IRMP_STM32/master/irmplircd/yaVDR/irmp.map
mv irmp.map irmplircd.map
Danach den Empfänger ab- und anstecken, und dann erkennt evtest die Tastendrücke.
Dann
sudo apt-get install eventlircd
cd /lib/udev/rules.d
mv 98-eventlircd.rules.disabled 98-eventlircd.rules
Damit er die rules einliest, ist ein Neustart am einfachsten.
Dann erkennt irw /run/lirc/lircd die Tastendrücke.
Funktioniert jetzt sehr schön .
Ein lustiger Nebeneffekt: Wenn eventlircd nicht läuft, kann man in einer Konsole mit den Pfeil-Auf/Ab Tasten der Fernbedienung rasant durch die Befehls-History scrollen .
Spricht eigentlich etwas dagegen, in der 60-irmplircd.rules ein , SYMLINK+="irmp_stm32" anzuhängen? Das sorgt dafür, dass stm32IRalarm und stm32IRconfig den Empfänger automatisch finden, ohne das man herausbekommen muss, ob irmplircd-hidraw0 oder irmplircd-hidraw1 oder irmplircd-hidraw2 oder ... richtig wäre.
yavdr-ansible bionic probiert, die Installation läuft gut durch, Key-Map rein und Neustart, Fernbedienung funktioniert tadellos.
Ein lustiger Nebeneffekt: Wenn eventlircd nicht läuft, kann man in einer Konsole mit den Pfeil-Auf/Ab Tasten der Fernbedienung rasant durch die Befehls-History scrollen .
Ja, das mit dem Key-Release muss ich noch mal angehen... - was man auf jeden Fall machen kann ist den Geräten, für die das Udev-Attribut ENV{eventlircd_enable}="true" gesetzt wird, noch ein zusätzliches Attribut ENV{ID_INPUT.tags}+="eventlircd" zu verpassen und dann dem X-Server sagt, dass er diese Eingabegeräte ignorieren soll:
Section "InputClass"
Identifier "exclude eventlircd devices"
MatchTag "eventlircd"
Option "Ignore" "True"
EndSection
Spricht eigentlich etwas dagegen, in der 60-irmplircd.rules ein , SYMLINK+="irmp_stm32" anzuhängen? Das sorgt dafür, dass stm32IRalarm und stm32IRconfig den Empfänger automatisch finden, ohne das man herausbekommen muss, ob irmplircd-hidraw0 oder irmplircd-hidraw1 oder irmplircd-hidraw2 oder ... richtig wäre.
Kann ich machen, aber das skaliert nicht für mehr als einen gleichzeitig angeschlossenen Empfänger, oder?
Er würde dann wohl immer den zuletzt angeschlossenen als /dev/irmp_stm32 nehmen.
(Wenn ich Firmware's an meinem Produktiv-VDR teste und ständig Empfänger an- und abstecke, funktioniert mein Haupt-Empfänger manchmal hinterher vorübergehend nicht mehr, bis ich ihn ab- und anstecke.)
Aber für den Normal-Nutzer mit nur einem irmp_stm32-Empfänger sollte der Vorteil größer sein als der Nachteil.
Mehr als eine Platine macht eigentlich auch keinen Sinn. Man kann an eine auch mehrere TSOP anschließen.
Kann es sein, dass es stm32-iralarm, stm32-irconfig und stm32-irconfig-gui für Xenial und Bionic noch gar nicht im yaVDR-ppa gibt?
Ich lasse gerade ein aktualisiertes Paket bauen. Benötigt das stm32IRconfig_gui Programm erhöhte Rechte (dann wird es unter Wayland schwer das zu starten ohne Löcher in das Sicherheitskonzept zu bohren) oder könnte man das auch mit einer normalen .desktop-Datei als Benutzer starten?
Leider keine Ahnung, ich habe das unter Wayland noch nicht probiert.
Nur X reicht jedenfalls nicht, man braucht auch einen Window Manager (jedenfalls für bestimmte Funktionen).
Leider keine Ahnung, ich habe das unter Wayland noch nicht probiert.
Die Frage ist einfach, ob man das Programm mit root-Rechten starten muss (das sieht Wayland für GUI-Programme eigentlich nicht vor), um den Empfänger konfigurieren zu können oder ob dafür die normalen Benutzerrechte genügen.
Bei yaVDR wird Openbox als Window Manager genutzt. Mit dem vdr-plugin-desktop kann man im Zusammenspiel mit dem Frontend-Skript (für mit yavdr-ansible vorbereitete Installationen) aus dem VDR-OSD heraus Programme starten, die als User laufen und eine passende .desktop-Dateien mitbringen (dabei wird das VDR-Frontend vorübergehend gestoppt, bis das Programm beendet wurde).
Ich habe gerade einen Schnelltest gemacht ohne Window Manager.
Als normaler User bekomme ich "Unable to connect to device", als root verbindet er sich mit dem Empfänger. In beiden Fällen startet das Program.
Edit: stm32IRconfig funktioniert als normaler User, wenn ich die Rechte für /dev/irmp_stm32 auf 666 setze. stm32IRconfig_gui aber auch dann nicht.
Damit geht es:
cat 80-usb.rules
SUBSYSTEM=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="4444", MODE="0666"
cat 80-irmp.rules
KERNEL=="hidraw*", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="4444", SYMLINK+="irmp_stm32", MODE="0666", RUN+="/bin/mkdir /var/run/lirc", TAG+="systemd"
Edit: Das geht natürlich auch in einer Datei.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!