Posts by joe_pow

Tja, ist wohl offensichtlich kein yavdr-Problem.

Nachdem "normales" Blacklisten nicht funktionert hat, bin ich testweise mal so vorgegangen (Module aber eingetragen in blacklist.conf):

Manuelles entfernen der Module mit sudo rmmod ir_lirc_codec und sudo rmmod lirc_dev

Anschließend sudo depmod -a und sudo update-initramfs -u

Nach einem Reboot erscheinen zwar wieder die Module mit lsmod, es funktioniert aber alles.

Ich kapier es zwar nicht, gebe jetzt aber auf und warte mal auf das nächsten Kernel-Update.

Auch die probeweise Installation über die Mini.iso lieferte die Einbindung über lirc_dev. Da auch dabei ein blacklisten nichts half, habe ich einfach mal die Module "lirc_dev" und "ir-lirc-codec" umbenannt, so dass sie nicht mehr gefunden wurden.

Und siehe da - alles funktioniert problemlos, auch über Reboot und An- und Abstecken hinweg.

Mittlerweile habe ich auch in http://www.lirc.org/html/configuration-guide.html gesehen, dass die Standardkonfiguration von lirc nur mit einer Fernbedienung funktioniert. Ich verstehe aber die Zusammenhänge mit vdr nicht ganz und würde es gerne sauber konfigurieren, so dass ich nach einem Kernel-Update nicht jedesmal die Module umbenennen muss.

So, bin jetzt einen kleinen Schritt weiter.

Da blacklisten nichts half und die Hardwareerkennung mit Ubuntu Desktop offensichtlich anders funktioniert, habe ich einfach mal eine Ubuntu Desktop (minimal) Installation vorgenommen.

Anschließend mit der Holzhammermethode X11 entfernt sudo apt-get purge libx11.* libqt.*

Danach lief das Playbook ohne Probleme durch und führte zu einer funktionierenden ansible-Installation.

Ein ir-keytable liefert jetzt:

Leider greift die rc_maps.cfg nur für den imon-Empfänger.

Ein manueller Aufruf von sudo ir-keytable -s rc0 -a /etc/rc_maps.cfg setzt aber das Protokoll rc-6 richtig und beide Fernbedienungen laufen wie gewünscht.

Jetzt bleibt nur die Frage, warum die Automatik nicht durchläuft.

Ein sudo fuser -v /dev/lirc0 bringt eine leere Ausgabe.

Was mir auffällt im Vergleich zu einem Live-Ubuntu-Desktop ist das zusätzliche Laden der Module "lirc_dev" und "ir_lirc_codec", die bei meiner Konstellation nicht nötig sein sollten.

Wie kann ich herausfinden, wo dies geschieht?

Ich gehe eigentlich genauso vor wie in yavdr6.

Zuerst habe ich das Template der rc_maps.cfg auf meine Bedürfnisse angepasst:

Die entsprechenden Keymaps sind hinterlegt und funktionieren genauso in yavdr6.

rc6-jg:

und rc-imon-pad-jg:

Komischerweise werden automatisch beide Keymaps richtig geladen, nur bei der mce Fernbedienung wird RC6 nicht aktiviert.

Ein manuelles Ausführen von sudo ir-keytable -s rc1 -a /etc/rc_maps.cfg aktiviert dann auch rc6, Protokoll lirc bleibt aber auch aktiviert:

Auch jetzt keine Reaktion mit irw, evtest etc.

Hallo,

nach erfolgreichem Start mit yavdr-ansible hakt es jetzt mit der Einbindung der zweiten Fernbedienung.

Neben einem im Gehäuse vorhandenen imon-Empfänger habe ich noch einen externen über USB angebundenen Empfänger.

Diese Kombi läuft mit eigenen Keymaps in yavdr6 seit Jahren problemlos.

Unter ansible wird nur der imon-Empfänger richtig erkannt und die eigene modifizerte Keymap geladen.

Den externen MCE-Empfänger schnappt sich irgendwie lirc.

ir-keytable -v liefert folgendes:

Eine probeweise Installation mit Ubuntu 18.04 Desktop führt zu zwei funktionierenden Fernbedienungen.

Der Unterschied scheint ein laden von lirc_dev zu sein.

lsmod liefert:

Da weiß ich jetzt aber nicht mehr weiter.

Das übliche Vorgehen mit irw, evtest und mode2 habe ich schon probiert - immer nur Ausgaben bei rc0.

Gruß

joe_pow

Hallo,

ich habe ähnliches Setup - ein imon 15c2:0034 und einen mceusb-Empfänger. Bei mir läuft der imon mit dem imon-Protokoll.
Dadurch kommen sie sich nicht in die Quere. Du solltest es mit ir-keytable auf das Protokoll "other" setzen können.
Ich nutze yavdr, da habe ich das ganze dauerhaft mit Template und eigenen keymaps in /etc/rc_maps.cfg gesetzt.

Gruß joe_pow

Hat grub beim install irgendwelche Fehlermeldungen gebracht?
Um zu testen, ob doch grub unsichtbar startet entweder beim booten die SHIFT-Taste gedrückt halten oder auf ESCAPE drücken.
Eventuell kommt dadurch doch das Grub-Menü zum Vorschein.

Gruß joe_pow

Hallo Norman,

auf jeden Fall muss in der order.conf das alte graphtft deaktiviert werden:
-graphtft

unter /etc/vdr/plugins habe ich einfach meine alte plugin.graphtft.conf nach plugin.graphtftng.conf kopiert.
Sie enhält nur "-d none"

Themes werden bei mir aus /var/lib/vdr/plugins/graphtftng/themes geladen, dort sind links auf die einzelnen Themes.
Ich benutze anthraize. Das eigentliche Theme liegt unter /usr/share/vdr-tftng-anthraize.

Gruß joe

Kann es sein, dass bei dem Dist-upgrade graphtft durch graphtft-ng ersetzt wurde?
Bei mir musste ich damals die conf-Dateien entsprechend für graphtft-ng umbenennen und im Plugin-setup explizit das Theme neu speichern.
Ist aber schon länger her - deshalb grob aus dem Kopf.

Gruß,

joe

Vielen Dank für den Tip!
Hat bei mir auch geholfen.
Allerdings startet bei mir graphtftng als zweites Plugin, da ein anderes hier nicht zu nennendes Plugin gerne als erstes starten sollte.

Ich habe genau diesen Pixelmüll seit kurzem auch.
Tritt glaube ich seit einem letzten dist-upgrade auf, bei dem auch graphtft-ng geupdatet wurde.
Lief davor schon lange ohne Probleme.
Benutze übrigens auch das gleiche anthraize-Theme.