Fernbedienung Telink Wireless Receiver

    Hi *,


    ich habe hier eine Maus-/Tastatur-/Fernbedienungskombination namens "Telink Wireless Receiver":

    Das Teil ist per USB angeschlossen und kommuniziert per Funk, nicht per IR mit seinem Empfänger.

    lsusb sagt: "Bus 001 Device 002: ID 248a:8367 Maxxter".

    Der X-Server erkennt auch alle drei Devices, wenn ich das richtig lese (s.u.). Es funktioniert beim VDR allerdings momentan nur Programm rauf und runter.

    Ist das damit getan, eine passende remote.conf zur Verfügung zu stellen? Und wenn ja, hat zufällig Jemand eine parat?


    Danke und ciao.

    Michael.

    Schau mal mit evtest, was da an Input Events für die Tasten an Events kommt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Danke für den Hinweis. Das Ergebnis ist ein wenig verwirrend.

    - Für einige Tasten wurde ein Event gemeldet, sie hatten aber (noch) keine Auswirkungen auf den VDR:

    - Für einige Tasten wurde kein Event gemeldet, sie hatten aber Auswirkungen auf den VDR. Dies waren Prg auf/ab, Cursor links/rechts/hoch/runter und alle Zahlentasten.

    - Für einige Tasten wurde weder ein Event gemeldet noch hatten sie eine Reaktion des VDR zur Folge, u.a. die fette OK-Taste im Jogshuttle, die "TV"-Taste sowie die vier Farbtasten.


    Kann man damit überhaupt etwas anfangen?


    Ciao.

    Michael

    Schau auch mal noch mit evtest auf die anderen vom Kernel für den Empfänger angelegten Kernel Input Devices. Vermutlich gibt es da eine Dreiteilung:

    • Medientasten (die von dir gepostete Ausgabe)
    • "normale" Tastatur-Events
    • Maus-Events

    Der X-Server ignoriert Tastencodes größer 255 und das vdr-plugin-remote kann soweit ich das in Erinnerung habe nur von einem einzelnen Kernel Input Device lesen, d.h. du brauchst sowas wie eventlircd, inputlircd oder lircd mit dem devinput-Treiber, um da alle Tastendrücke auswerten zu können.


    Eventlircd kann solche Eingabegeräte grundsätzlich anhand von gesetzten udev-Attributen erfassen und man kann die Events mit Hilfe einer evmap in ein für yaVDR passendes Schema von Tastennamen überführen.


    So eine udev-Regel könnte für yaVDR z.B. so aussehen (das Setzen des Attributs in der letzte Zeile sorgt dafür, dass der X-Server das Gerät aufgrund des Snippets aus https://github.com/yavdr/yavdr…ignore-eventlircd.conf.j2 ignoriert, was wichtig ist, weil eventlircd das Gerät sonst nicht exklusiv öffnen kann):

    Code: /etc/udev/rules.d/95-wireless_remote.rules
    # Telink Wireless Receiver
ACTION=="add|remove", SUBSYSTEM=="input", ENV{ID_VENDOR_ID}=="248a", ENV{ID_MODEL_ID}=="8367", \
  ENV{eventlircd_enable}="true", \
  ENV{eventlircd_evmap}="03_$env{ID_VENDOR_ID}_$env{ID_MODEL_ID}.evmap", \
  ENV{ID_INPUT.tags}="eventlircd"

    Dazu dann noch eine keymap (gemäß der obigen udev-Regel muss sie existieren, darf aber leer sein), in der du die Tastennamen remappen kannst, also z.B.

    Code: /etc/eventlircd.d/03_248a_8367.evmap
    KEY_CONFIG = KEY_SETUP

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ok, ich habe eventlircd geholt, übersetzt und installiert.

    Das X-Server File habe ich auch angelegt, ebenso die udev-Regel und ein leeres evmap.


    Brauche ich nun trotzdem noch lircd? Und wenn ja, mit welcher Konfiguration dann?


    Ciao.

    Michael.

    Einmal editiert, zuletzt von nobanzai ()

    Zitat von nobanzai

    Brauche ich nun trotzdem noch lircd? Und wenn ja, mit welcher Konfiguration dann?

    Nein (wobei das Programm irw nützlich sein kann, um zu sehen, was eventlircd ausgibt), du musst dem VDR nur sagen, dass er vom Socket lesen soll, den eventlircd anlegt und eine remote.conf Anlernen bzw. Schreiben, die die gewünschten Tastennamen nutzt - bei yavdr-ansible sieht das so aus: https://github.com/yavdr/yavdr…les/vdr/files/remote.conf

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Dummerweise bekomme ich nix aus dem eventlircd raus - keine Meldung, kein garnix 8-<

    Egal, was ich für Parameter mitgeben (oder auch ganz ohne), bekomme ich lediglich einen Returncode 1.

    Die man Page passt nicht zum Programm (z.B. --map vs. --evmap).


    Habe ich die falsche Version oder mache ich sonst was falsch?

    Zitat von nobanzai

    Dummerweise bekomme ich nix aus dem eventlircd raus - keine Meldung, kein garnix 8-<

    Dafür kann man es mit dem Schalter -v starten, der bis zu drei mal wiederholt werden darf (-vvv), um es gesprächiger zu machen.

    Zitat von nobanzai

    Egal, was ich für Parameter mitgeben (oder auch ganz ohne), bekomme ich lediglich einen Returncode 1.

    Dann geht etwas gehörig schief - die Verbose-Ausgabe sollte da hoffentlich Klarheit schaffen.


    Vielleicht tust du dir mit der yaVDR-Installation für den Proof of concept leichter, da ist schon alles vorbereitet...

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hm, also im udev rules file muss hier wohl ATTR{idVendor} und ATTR{idProduct} stehen.

    Also im Ganzen:

    Code
    ACTION=="add|remove", SUBSYSTEM=="input", \
  ATTR{idVendor}=="248a", ATTR{idProduct}=="8367", \
  ENV{eventlircd_enable}="true", \
  ENV{eventlircd_evmap}="03_$ATTR{idVendor}_$ATTR{idProduct}.evmap", \
  ENV{ID_INPUT.tags}="eventlircd"

    Aber das Teil ist ja noch weniger gesprächig als Unix-Programme das eh üblicherweise schon sind - selbst mit --verbose redet er nicht mit mir 8-<

    systemd unit dazu:

    Zitat von nobanzai

    selbst mit --verbose redet er nicht mit mir 8-<

    Dann schreib stattdessen mal -vvv dahinter.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Nö, da kommt auch nix - zumindest nicht im Journal und nicht auf stdout.

    Aber er läuft jetzt immerhin.

    Jetzt muss ich noch die Keys mappen. Hab leider keine passende evmap gefunden, also zu Fuß das Ganze.


    Thx again.


    Ciao.

    Michael.

    Zitat von nobanzai

    Nö, da kommt auch nix - zumindest nicht im Journal und nicht auf stdout.

    Ein systemctl daemon-reload hast du nach der Änderung an der Unit vor dem Neustart des Dienstes gemacht?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986

    Ein systemctl daemon-reload hast du nach der Änderung an der Unit vor dem Neustart des Dienstes gemacht?

    Ich editiere immer mit "systemctl edit --full <service-file>", da sollte kein daemon-reload notwendig sein.

    Aber wegen anderer Änderungen habe ich einen Reboot machen müssen - und danach kommt auch nicht mehr an Ausgaben.

    Auch auf der Kommandzeile mit -f kommt übrigens nicht mehr.


    Allgemein hänge ich noch ein wenig bei den Zusammenhängen.

    Brauche ich Inhalte in der /etc/eventlircd.d/03_248a_8367.evmap? Und wenn ja, woher nehme ich die Infos dafür? irw gibt garnix aus, evtest die weiter oben genannten Daten.

    Ich habe mir die Zuordnungs-Liste auf der yavdr Page angeschaut. Da steht ja schön, welcher Key in welcher Datei was bedeutet, aber mir fehlt bei den key/value Paaren in den jeweiligen Dateien, woher key und value Infos jeweils kommen.


    Ciao.

    Michael.

    Zitat von nobanzai

    Brauche ich Inhalte in der /etc/eventlircd.d/03_248a_8367.evmap?

    Nicht zwingend - bei yaVDR ist das nützlich, weil die remote.conf und die Lircmap.xml für KODI und einige weitere Programme von einer bestimmten Benennung ausgehen und dann im Idealfall einfach alles funktioniert, wenn man die Tastendrücke auf diesen Standard bringt.

    Zitat von nobanzai

    Und wenn ja, woher nehme ich die Infos dafür?

    Die Tastennamen kann man entweder mit evtest oder wenn eventlircd funktioniert auch mit irw (dem muss man ggf. noch den passenden Pfad mitgeben, ich weiß nicht, wie und mit welchen Anpassungen das für SuSE kompiliert wurde) ermitteln.


    Wenn irw nichts ausgibt, könnte es sein, dass die udev-Regel noch nicht passt - dann wäre die Ausgabe von udevadm info --query=all --name=/dev/input/eventX (eventX durch das jeweilige Input Device ersetzen) noch interessant, eventuell gibt es da Besonderheiten, die verhindern, dass die jetzige udev-Regel greift.


    Zitat von nobanzai

    Ich habe mir die Zuordnungs-Liste auf der yavdr Page angeschaut. Da steht ja schön, welcher Key in welcher Datei was bedeutet, aber mir fehlt bei den key/value Paaren in den jeweiligen Dateien, woher key und value Infos jeweils kommen.

    In einer evmap kann man einer Taste(nkombination) einen anderen Tastennamen zuordnen, also gilt da sowas:

    Code
    <vom Empfänger gesendeter Tastenname> <von eventlircd gesendeter Tastenname>

    Bei der remote.conf des VDR gilt sowas:

    Code
    <Quelle>.<VDR-interner Tastenname> <externer Tastenname>

    Im Fall von eventlircd liest der VDR von einem lirc-kompatiblen Sockel, also ist die Quelle LIRC - natürlich kann man die remote.conf auch einfach vom VDR anlernen lassen, wenn einem das lieber ist.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ich wollte das Anlernen via VDR eigentlich machen, aber irgendwie will das mit meinem X-Server so nicht klappen.

    Ich habe dem vdr das tty10 gegeben, der X-Server läuft auf tty8.

    Wenn ich den VDR beende, die remote.conf lösche und den VDR mit softhddevice und X-Server starte, dann fragt er im X-Fenster nach einem Tastendruck.

    Wenn ich dann eine Taste drücke, geht er einfach ins aktuelle Fernsehprogramm und sonst passiert nix mehr - weder im X-Fenster noch auf tty10.

    Was ich besonders seltsam finde nach deinen Erläuterungen: Selbst ohne remote.conf funktionieren immer noch die Tasten Prg auf/ab, Cursor links/rechts/hoch/runter und alle Zahlentasten. Wie kann das sein?


    Ciao.

    Michael

    Ok, ich habe es jetzt in den Anlernmodus von VDR geschafft (geht doch einfach im X-Server Fenster).

    Aber wie es aussieht, ist es nicht LIRC, was da von VDR abgefragt wird, sondern XKeySym - zumindest wird das dann so abgespeichert in der remote.conf.

    Kann es sein, dass das an softhddevice liegt? Da steht ja in der README auch, dass man die XKeySms in die remote.conf eintragen soll.

    Bei einige Tasten kommt allerdings nach wie vor nichts im System an - weder bei VDR, noch bei evtest, egal welches der vorhandenen Input-Devices ich bisher getestet habe.

    Für mich sieht das danach aus, dass eventlircd das Gerät nicht exklusiv geöffnet hat (entweder passt die udev-Regel nicht oder der X-Server schnappt ihm den Empfänger weg) und die Tasten-Events weiterhin über den X-Server an den VDR gelangen, was den oben genannten Beschränkungen hinsichtlich der weitergeleiteten Tasten unterliegt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Ich habe die Rule so modifiziert:


    Damit spuckt er im Journal auch "95-wireless_remote.rules fired" aus:

    Die Rule trifft also, wie es aussieht.

    "events of unsupported event type EV_MSC will be discarded" verstehe ich allerdings nicht.

    Zitat von nobanzai

    "events of unsupported event type EV_MSC will be discarded" verstehe ich allerdings nicht.

    Neben Events mit Tastendrücken können auf einem Kernel Input Device auch noch andere Event-Typen ankommen - eventlircd kann mit denen nichts anfangen und ignoriert sie. EV_MSC liefert rohe Scancodes (was z.B. bei rc-core Empfänger nützlich ist, wenn man für die eine Keytable für ir-keytable erstellen will).

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden