[franky]

Hallo Zusammen,

ich habe schon wieder mal ein FB-Problem.

Dank des neuen irkeytable Paketes konnte ich eine bisher nie richtig funktionierende FB/IR-Empfänger Kombination (TeVII S660) komplett neu anlernen.
Sehr störend war dann aber eine vorhandenen tevii_s660.evmap, die für den VDR teilweise völlig sinnlose Remapping-Einträge enthält.
Dadurch werden einige sinnvoll zugeordnete Tasten komplett unbrauchbar (KEY_MENU und KEY_OK) oder einer falschen Funktion zugeordnet.
Nach Entfernen aller Mapping-Einträge in dieser evmap hatte die FB genau so funktioniert wie angelernt.

Nach dem Kernel-Update 5.10.13 von heute hat die FB wieder nicht mehr richtig funktioniert, weil beim Kernel-Update über das Update von eventlircd die alte tevii_s660.evmap eingespielt worden ist.

Alternativ könnte man, wenn eine individuell erstellte rc-keymap vorhanden ist, die dazugehörige und nicht mehr benötigte evmap komplett löschen.
Bei einem Kernel-Update gibt es aber das gleiche Problem, wie bei einer angepassten evmap.

Selbst bei USB-Empfängern mit Standard-Keymap, wie meine X10-RF und MCE-IR-Empfänger, kann man ja jetzt falsch zugeordnete Tasten über das WebIF komfortabel neu zuordnen.
Auch hier ist eine vorhandene evmap überflüssig oder evtl. sogar störend.

Ein weiteres Beispiel, wo jetzt das Anlernen der FB im WebIF funktioniert, ist mein Streamzap USB-IR-Empfänger mit FB.
Für diesen musste ich vorher manuell eine individuelle rc-keymap (nach Vorlage /lib/udev/rc_keymaps/streamzap) erstellen und über rc_maps.cfg aktivieren.
In diesem Fall funktioniert die Tastenzuordnung ohne evmap nur über eine individuelle rc-keymap und bei einem Kernel-Update passiert nichts.

Ein anderer Fall ist mein "Topseed" USB-IR-Empfänger mit dazugehöriger Cyberlink-Fernbedienung.
Dieser Empfänger funktioniert mit eventlircd aber nicht mit ir-keytable, d.h. die einzige Möglichkeit Tastenzuordnungen anzupassen ist eine evmap.
Es ist auch eine topseed.evmap  vorhanden, die von eventlircd verwendet wird, leider waren fast alle Remapping-Einträge unbrauchbar.
Meine mit Hilfe von evtest manuell angepasste und funktionierende evmap wurde beim letzten Kernel-Update ebenfalls überschrieben.
Somit funktionieren nach dem Kernel-Update wieder viele, auch wichtige FB-Tasten, nicht mehr.

Ich hätte daher eine Idee.

Wäre es nicht möglich, alle derzeit in /etc/eventlirc.d/ vorhandenen evmaps in einen Unterordner (z.B. /etc/eventlirc.d/example) zu verlagern?
Somit gäbe es unter /etc/eventlirc.d/ keine aktiven und evtl. störenden evmaps mehr.

Passen die Tastenzuordnungen für eine Fernbedienung nicht, können diese in den meisten Fällen über das WebIF und eine individuelle rc-keymap angepasst werden.
Wird doch mal eine evmap benötigt, kopiert man die entsprechende Beispiel-evmap nach /etc/eventlirc.d/.
Dort kann sie individuell angepasst werden und wird bei einem Kernel-Upgrade wenigstens nicht mehr überschrieben.

[franky]

Ich hatte da bei meiner Idee einen Denkfehler drin.
Die evmaps darf man natürlich nicht einfach so aus /etc/eventlirc.d/ entfernen.

In der /lib/udev/rules.d/98-eventlircd.rules werden u.a. die USB-Empfänger, auf die eventlircd zugreifen soll, anhand ihrer Vendor-ID/Product-ID idendifiziert und ihnen einen evmap zugewiesen.
Entferne ich eine dort zugewiesene evmap (z.B. die tevii_s660.evmap), verwendet eventlircd den entsprechenden USB-Empfänger nicht mehr und somit funktioniert die FB nicht mehr im VDR.

[franky]

Ich habe jetzt doch eine Lösung für mein Problem gefunden. 

Meine evmap-Anpassungen mache ich nicht in den Standard evmaps sondern erstelle dafür individuell benannte evmaps, z.B. own_tevii_s660.evmap.
Eine zusätzliche 98-own-eventlircd.rules sorgt dann dafür dass eventlircd diese evmaps anstatt der Standard evmaps verwendet.
Die 98-own-eventlircd.rules habe ich auf Basis der 98-eventlircd.rules erstellt und die Abschnitte für meine FBs belassen und die evmaps angepasst.

Diese diese eigene rules-Datei und die individuellen evmaps überstehen auch ein Update von eventlircd.
Bei einem ersten Test mit der own_tevii_s660.evmap und einem Kernel-Update von 5.10.12 auf 5-10.13 hat es auf jeden Fall funktioniert.

[clausmuus]

Ja, leider gibt es einige Fernbedienungen die auf eine evmap Datei nicht verzichten können. Aber Du hast natürlich Recht, dass in den Fällen wo das Mapping per irkeytable gemacht wurde (oder gemacht werden kann) auf ein Mapping per evmap verzichtet werden soll.
Das Mapping sollte sich mit einer udev Regel komplett abschalten lassen, die so erstellt werden kann:

Code: [Select]

echo 'SUBSYSTEM=="input", KERNEL=="event[0-9]*", ENV{eventlircd_evmap}=""' > /lib/udev/rules.d/99-eventlircd-disable-mapping.rules
Besser wäre natürlich, wenn das Mapping gezielt nur für das Device abgeschaltet wird, für das eine keytable erstellt wurde. Dafür müsste ich aber erst einmal herausfinden, wie ich das Device per udev Regel erkenne. Aktuell vermute ich, dass das per vender/product ID gehen müsste.

Du kannst mal Bitte testen, ob die genannte udev Regel bei Dir hilft, wenn Du Deine eigene 98-own-eventlircd.rules wieder entfernst.

[franky]

Diese udev Regel hilft.

Nach einem ersten Reboot wurden zwar erst mal die Kernel-Treiber für die TeVii S660 nicht mehr geladen.
Somit schwarzer Bildschirm, da natürlch weder DVB-Tuner noch IR-Empfänger funktioniert haben.
Ein kompletter Shutdown und Stromstecker ziehen hat dann aber geholfen.
Jetzt funktioniert der IR-Empfänger der S660 auch ohne evmap.

Diese USB-Empfänger mit Montage-Tuner, wie die S660 oder die Verwandschaft von DVBSky bzw. Terratec, sind sowieso etwas zickig.

Ich teste die udev Regel auch noch auf anderen Systemen.

[franky]

Ich habe die disable-mapping Regel noch auf weiteren Systemen, bei denen alle FB-Tasten über eine individuelle rc_keymap funktionierten, erfolgreich getestet.

Erst habe ich zum besseren Testen einige FB-Tasten gezielt über die entsprechende evmap unbrauchbar gemacht.
Nach dem Erstellen der udev Regel mit deinem Befehl und anschließendem Reboot hatten wieder alle Tasten einwandfrei funktioniert.

[clausmuus]

Ich habe jetzt setup so erweitert, das beim speichern einer angelernten Konfiguration ein udev Regel erstellt wird, die die evmap nur für dieses eine Gerät deaktiviert.
Magst Du auch noch testen, ob dies bei Dir funktioniert? Also Deine selbst erstellte udev Datei wieder löschen und im Setup einmal die key Config speichern. Anschließend neu booten und hoffen das noch immer alles passt.

[franky]

Hi Claus,

leider hatte es erst mal nicht funktioniert.
Ich habe aber eine Lösung gefunden, was leider etwas gedauert hat. 

Die individuelle rules Datei wurde erstellt, aber die Regel anscheinend nicht angewendet.
Vendor und Product-ID waren aber korrekt.
Die Änderung von "" für keine evmap in "default.evmap", die keine VDR relevanten Keys enthält war auch wirkungslos.

Letztendlich lag es nicht am Inhalt der individuellen rules Datei sondern am Dateinamen, der verhindert hat, dass die in 98-eventlircd.rules bereits definierte evmap wieder deaktiviert wird.

Ich musste nur analog zu deiner 99-eventlircd-disable-mapping.rules die 98 am Beginn des Dateinamens in 99 ändern.

Für die S660 also z.B. von 98-eventlircd-TeVii_S660_USB.rules in 99-eventlircd-TeVii_S660_USB.rules

Ich hab noch mit 2 anderen Systemen (andere Empfängern/FBs) getestet, bei denen das Deaktiviern der evmap auch erst nach der Änderung des Dateinamens funktioniert hat.

Gruß
Klaus

[clausmuus]

Du hast mit dem Dateinamen natürlich Recht. Ich werde es heute Abend ändern.

[franky]

Ich habe gerade die neue ireytable 2021.02.03-14.21 getestet und es funktioniert.
Nach dem Speichern einer bearbeiteten Tastenzuordnung beginnt der Dateiname der erstellten rules Datei mit 99.
Nach einem Reboot ist die entsprechende evmap deaktiviert. 

Für jeden meiner Empfänger der eine angepasste evmap braucht, erstelle ich eine rules Datei nach dem gleichen Schema.
Anstatt "" für das deaktivieren der evmap trage ich die individuelle benannte evmap für den Empfanger ein, die dann anstatt der Standard evmap geladen wird.
Die individuellen evmaps und rules Dateien überstehen dann auch ein eventlircd Update.

Ich setze das Thema auf gelöst.

Vielen Dank für die schnelle Umsetzung.