yaVDR und [irmp]lircd Fernbedienungen – eine grundsätzliche Frage

    Auf Ubuntu Xenial Desktop funktionieren stm32IRalarm und stm32IRconfig_gui nach anpassen der rules tadellos (als normaler Benutzer).

    stm32IRconfig funktioniert nur dann einwandfrei, wenn man vorher lircd2uinput stoppt. Sonst meldet er im Monitor-Modus bei Fernbedienungstastendrücken den Nutzer ab (funktioniert aber weiterhin). Ein ähnliches Problem wie in #50? Statt lircd2uinput zu stoppen hilft auch eventlircd zu starten.


    Danke für's Pakete bauen, und sorry, dass nun schon wieder was angepasst werden muss (die rules) :( .

    Statt jedem auf dem System Schreibrechte für das HID-Gerät zu geben würde ich das lieber auf eine Gruppe wie dialout beschränken.

    Die oben beschriebene Konfiguration für den X-Server, die Geräte mit dem eventlircd-Tag ignoriert ist bei yavdr-ansible schon drin.

    Zitat von jrie
    RUN+="/bin/mkdir /var/run/lirc"

    Das Verzeichnis lasse ich bei den Paketen in den yaVDR-PPAs über tmpfiles

    erstellen, dann ist garantiert, dass es rechtzeitig angelegt wird. Ansonsten sollte man mkdirmit dem Argument -p aufrufen, damit es keinen Fehler wirft, wenn das Verzeichnis schon existiert.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986

    Statt jedem auf dem System Schreibrechte für das HID-Gerät zu geben würde ich das lieber auf eine Gruppe wie dialout beschränken.

    Macht Sinn, dann muss aber sicher gestellt sein, dass der User in der Gruppe ist.


    Zitat von seahawk1986

    Das Verzeichnis lasse ich bei den Paketen in den yaVDR-PPAs übertmpfiles

    erstellen, dann ist garantiert, dass es rechtzeitig angelegt wird. Ansonsten sollte man mkdirmit dem Argument -p aufrufen, damit es keinen Fehler wirft, wenn das Verzeichnis schon existiert.

    Das gucke ich mir mal an.


    Edit: Deine /usr/lib/tmpfiles.d/irmplircd.conf gefällt mir. Ich werde das übernehmen.

    Zitat von seahawk1986

    Der irmp-Empfänger, den mir ranseyer damals zugeschickt hatte, ist leider sehr zickig beim Aushandeln der USB-Verbindung und funktioniert nur an einem alten Athlon64, aber nicht an meinem normalen Testsystem. Außerdem scheint er zumindest bei RC-5 die ersten paar Tastenwiederholungen zu verschlucken.

    Der erste Part war der Fall mit einer Firmware die die Pins für VUSB nicht richtig configuriert hatte (Pullup oder Down).

    Das ist inzwischen behoben würde ich sagen.


    Zum zweiten Fall kann ich wenig sagen, und ich bin inzwischen auch "eher für 32 Bit Hardware"...

    Das gute an Jörgs Lösung ist eben auch dass diese massiv gepflegt wird...

    Zitat von ranseyer

    Der erste Part war der Fall mit einer Firmware die die Pins für VUSB nicht richtig configuriert hatte (Pullup oder Down).

    Was bräuchte man denn, um die Firmware zu aktualisieren?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von jrie

    Damit geht es:

    Code
    SUBSYSTEM=="usb", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="4444", MODE="0666"

    Durch den Wechsel von hidapi-libusb auf hidapi-hidraw ist das nicht mehr nötig.


    Zitat von seahawk1986

    Statt jedem auf dem System Schreibrechte für das HID-Gerät zu geben würde ich das lieber auf eine Gruppe wie dialout beschränken.

    Was hälst du davon, statt z.B. GROUP="plugdev" das modernere TAG+="uaccess" zu verwenden?

    https://github.com/systemd/systemd/issues/4288

    Wenn nur User mit einem aktiven Seat Zugriff auf das Gerät benötigen, könnte man das machen - über SSH mit X-Forwarding (oder über einen Dienst, der nicht mit root-Rechten ohne aktiven Seat läuft) kann man dann aber aber nicht zugreifen, wenn ich das richtig gelesen habe.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat von seahawk1986

    SSH mit X-Forwarding

    wollte ich schon immer mal antesten. Auf meinem Windows Rechner Xming installiert, putty konfiguriert, und geht: stm32config_gui vom VDR auf dem Windows Desktop.

    Mit TAG+="uaccess" und als normaler Benutzer.

    Das geht vermutlich deshalb, weil nach einloggen per ssh der normale Benutzer einen aktiven Seat hat.

    Ok, die einzige Besonderheit scheint zu sein, dass der Tag rechtzeitig gesetzt werden muss, damit er von der nachfolgenden udev-Regel berücksichtigt wird.


    Weißt du schon, wie das mit der HID-Keyboard Variante deines IRMP-Empfängers aussieht?

    Muss man für den in der udev-Regel nur das Subsystem anpassen (input statt hidraw oder ändert sich da noch etwas anderes, auf das man matchen muss (z.B. die USB-ID)?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Soweit bin ich noch nicht. Vielleicht lasse ich die USB ID (es sei denn jemand findet einen triftigen Grund dagegen). Der Empfänger ist jetzt ein Verbund-Gerät, d.h. er besteht aus 2 Geräten, einem input device und einem hidraw device. hidraw ist nach wie vor für die Konfiguration.

    Erstmal müssen jetzt die Konfigurationsprogramme angepasst werden, dann kümmere ich mich um den Rest.

    Gemäß USB HUT 1.12 Page 0x07 können nur bestimmte Keys ausgegeben werden.

    Und von denen auch nur die, die dann noch von evtest erkannt werden.

    Das sind immerhin noch ca. 169, aber manche Keys, die yavdr verwendet, z.B. KEY_RED etc. gibt es nicht über USB.

    Das sollte vielleicht umgestellt werden.

    Sonst müssen es die User von Hand machen.

    Nur mal so als Überlegung für die Zukunft :)

    yaVDR nutzt Consumer Keys, die laut https://github.com/torvalds/li…vers/hid/hid-input.c#L858 in der USB HUT v1.12 auf den Seiten 75-84 zu finden sind - wobei die Farbtasten gemeinerweise in einem reservierten Bereich zu liegen scheinen (Seite 76).


    Die Tastennamen kann man aber auch mit einer evmap für eventlircd bequem auf den yaVDR-Standard bringen, wenn dann mal feststeht, welche Key-Codes du für dein Gerät verwenden willst.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Für ein Gerät, dass sich als Keyboard anmeldet gelten die Seiten 53 - 59 (Kapitel 10 Keyboard/Keypad Page (0x07).


    Zitat von seahawk1986

    Die Tastennamen kann man aber auch mit einer evmap für eventlircd bequem auf den yaVDR-Standard bringen

    Gut zu wissen :)


    Zitat von seahawk1986

    wenn dann mal feststeht, welche Key-Codes du für dein Gerät verwenden willst.

    Das kann jeder User so machen, wie er will.

    Es wäre natürlich schön, wenn es eine einheitliche Vorlage gibt.

    Das überlege ich mir dann mal.

    Gibt es ein eindeutiges udev-Merkmal, mit dem man so einen Empfänger erkennen kann? Oder ist der wie die bisherige Variante mit dem Unterschied, dass es zusätzlich eine Tastatur als Kernel Input Device gibt?

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Da würde sich

    ATTRS{name}=="STMicroelectronics STM32 IRMP HID-KBD-Device" oder

    ATTRS{product}=="STM32 IRMP HID-KBD-Device" anbieten.

    Der Unterschied ist das "-KBD"

    Ich habe mal yavdr-remote für bionic um die evmap und eine udev-Regel erweitert, die sie dem Empfänger zuordnet.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Zitat

    Mit dem USBASP .... ;)

    Denke du hast einen aus der Charge wo genau das Thema Pullup in der Firmware falsch war. Diese Teile hatten das Problem nur an bestimmten Rechnern zu laufen.


    Kann dir das Teil neu gerne flashen wenn du willst.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden