(vdr4)Arch - serial_ir ersetzt lirc_serial Modul mit Kernel >= 4.10

    Zitat von Dr. Seltsam

    ich führe weiter Selbstgespräche...

    Du hast in jedem Fall interessierte Zuhörer :D

    Ich veruche auch gerade die FB meiner S952 zur Mitarbeit zu bewegen, und deine Selbstgespräche helfen da ungemein (auch wenn ich sie ja lieber ohne lirc betreiben würde - aber mal sehen)

    VDR2: ASRock J4105-ITX, DVBSky S952, openSUSE Tumbleweed, VDR 2.4.7

    softhddevice/vaapidevice, DFAtmo, xmltv2vdr, tvscraper, tvguideng, VDRAdmin-AM (alles git, aber alt)

    Anscheinend liegt es daran, dass neben lircd auch lircd-uinput läuft. Wenn ich den kille, sind die Probleme weg. Ich dachte, ich hätte das Starten von lircd-uinput bereits durch die Einträge im Abschnitt [lircmd] unterbunden, aber anscheinend ist das dafür nicht zuständig. Ich hoffe, dass ein

    Code
    sudo systemctl disable lircd-uinput.service

    das jetzt dauerhaft behebt.


    Da hat sich offenbar allerlei bei lirc geändert. Was mir auch noch auffiel ist, dass irrecord trotz Aufruf über sudo nur noch dann funktioniert, wenn zusätzlich der Parameter

    Code
    -k --keep-root        Don't drop root privileges

    gesetzt wird. Sonst startet irrecord zwar, reagiert aber auf keinen Tastendruck. Ein weiteres Problem mit irrecord ist, dass es bei mir ständig mit einem segfault abstürzt, wenn die Konfiguration abgespeichert werden soll. Man findet dann noch temoräre Dateien (irrecord-tmp-[xyz]) in denen hinter jedem Code ein zweiter Eintrag "0xFFFFFFFFFFFFFFFF" steht. Wenn man den manuell löscht, kann man mit der temporären Datei weiterarbeiten, sie muss dann mit der Option

    Code
    -u --update        Amend buttons to existing file

    aufgerufen werden. Das ging früher glaube ich auch ohne, wenn man eine vorhandene conf vorgab um zusätzliche Tasten anzulernen. Ohne den -u Parameter fängt irrecord jetzt wieder ganz von vorne an.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Wenn du verhindern willst, dass ein Dienst gestartet werden kann, solltest du ihn maskieren statt ihn nur zu deaktivieren (das verhindert nur, dass er aufgrund der [Install] Section gestartet wird):sudo systemctl mask lircd-uinput.service

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    danke, hatte mich schon gewundert, warum der Dienst immer noch gestartet wurde

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Hallo an alle,

    inzwischen ist Dezember 2018, und ich krieg die Krise:

    ich bin auf

    Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-43-generic x86_64)
    mit dem yaVDR-ansible

    und bekomme mein LIRC (IR Empfänger am COM Port) nicht ans laufen.

    Meine /etc/lirc/lirc_options.conf sieht so aus:

    OK, es gibt kein /dev/lirc0 bei mir, sollte das von lircd angelegt werden ?

    die /etc/modprobe.d/serial_ir.conf ist so:

    Code
    # COM1 equivalent: /dev/ttyS0
#options serial_ir irq=4 io=0x3f8
# COM2 equivalent: /dev/ttyS1
options serial_ir irq=3 io=0x2f8

    Bei meinem ersten vesuch auf dieser Hardware mit einer yaVDR 2.6 Distri hatte meine FB mit lirc auf COM2 noch funktioniert,

    (da hatte ich nur andere Probleme nit dem DVB Treiber)

    'serial_ir' schein geladen zu sein:


    yavdr@yaVDR2:~$ lsmod | grep serial

    serial_ir 20480 0

    rc_core 36864 1 serial_ir


    Der Startversuch von LIRC :


    yavdr@yaVDR2:~$ sudo systemctl restart lircd

    Job for lircd.service failed because the control process exited with error code.

    See "systemctl status lircd.service" and "journalctl -xe" for details

    und

    Erstaunlicherweise scheinen auch keine neuen Einräge in 'dmesg' aufzutauchen, wenn ich versuche, mit

    sudo modprobe serial_ir

    den Treiber zu laden ?


    HILFE !

    Zitat von dongerry

    OK, es gibt kein /dev/lirc0 bei mir, sollte das von lircd angelegt werden ?

    Das sollte nach meinem Verständnis vom Treiber angelegt werden, wenn das Protokoll auf LIRC gesetzt ist (ich habe den Rechner mit dem Atric V5 noch nicht auf yavdr-ansible umgestellt). Siehst du den Empfänger nach dem Laden von serial_ir in der Ausgabe von sudo ir-keytable gelistet?


    Vermutlich musst du den UART-Treiber entladen, bevor du serial_ir laden kannst, also z.B:

    sudo /usr/bin/setserial /dev/ttyS0 uart none

    sudo /usr/bin/modprobe serial_ir

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hallo seahawk,


    yavdr@yaVDR2:~$ sudo setserial /dev/ttyS0 uart none

    yavdr@yaVDR2:~$ sudo setserial /dev/ttyS1 uart none

    yavdr@yaVDR2:~$ sudo modprobe serial_ir

    yavdr@yaVDR2:~$ sudo ir-keytable

    Keine Geräte gefunden


    Auch keine neuen Einträge in dmesg
    ich müsste auf ttyS1 sein (obwohl das Board nut einen Pfostenstecker für COM hat), mein Versuch mit dem yaVDR 6.2 hat nur mit LIRC auf COM2 funktioniert.

    Also ich mach in meinem runvdr script immer folgendes, bevor der VDR selber gestartet wird:

    Code
    # run lirc-daemon
systemctl stop lircd; setserial /dev/ttyS1 uart none; setserial /dev/ttyS0 uart none; rmmod serial_ir; modprobe serial_ir


    gruß

    msv

    Den Treiber zu entladen und dann neu zu laden ist eine gute Idee.


    Ich meine das kann man auch von lircd selbst über die [modinit] Section in der lirc_options.conf ausführen lassen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    Hallo,

    nur noch mal ein paar abschliessende Bemerkungen zu meinen Posts vom Dezember:

    ich habe inzwischen auf Lirc verzichtet und nutze das 'serial_ir'. Mit Erfolg.

    Das Problem war noch, in Bezug auf den Post #27 vom 22.12.2018, dass bei mir noch

    'eventlircd' aktiv war, der sich die serielle Schnittstelle gekrallt hatte, nachdem ich dann

    lircd und eventlircd entfernt hatte, hat auch das 'serial_ir' funktioniert.

    Noch eine passende codetable für meine Fernbedienung erstellt und schon funktioniert's

    und das läuft genauso gut wie lirc, was z.B. die Geschwindigkeit beim Scrollen in Menüs angeht?

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Ja, das Scrollen ist kein Problem, es scheint mir sogar etwas schneller zu sein, auch bei z.B. Kanal hoch - runter darf man nur kurz die Taste drücken, sonst springt man gleich zwei Programme, aber ich denke, dass das wahrscheinlich an der FB selber liegt (Vivanco UR12BN), ich nehm ja mal an, dass die Wiederholrate von der FB selbst bestimmt wird.

    Im vdr gibt es Einstellmöglichkeiten, mit der man zu schnelle Fernbedienungen bremsen kann.


    Suche mal nach RcRepeatDelay und RcRepeatDelta.


    Lars

    Weiß jemand ob es für irexec eine alternative gibt wenn man auf lirc verzichten möchte?

    Ich nutze es um diverse Befehle auszuführen und um mit Hilfe von xte die Eingabe der FB in Tastatureingaben "umzuwandeln". Das fand ich bisher sehr bequem.

    Zitat von tecfreak

    Weiß jemand ob es für irexec eine alternative gibt wenn man auf lirc verzichten möchte?

    Wenn man eine Fernbedienung nutzt, die ein vom Kernel unterstützes Protokoll nutzt, kann man statt über lircd über das Kernel Input Device gehen. Wenn man eine Keytable mit Tasten nutzt, die vom X-Server verarbeitet werden können (Key-Code < 255), hast du die Tastendrücke direkt als Tastatureingabe in Xorg.

    Wenn man das nicht will kann man mit eventlircd das Input device exklusiv öffnen lassen und dann irexec an den Socket hängen.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

    ich hatte das damals ausprobiert, aber die FB war dadurch unglaublich zäh und langsam. vdr selbst kann ja auch nichts mit input devices anfangen. Man braucht entweder das remote-Plugin, oder muss doch wieder lirc mit devinput benutzen. So jedenfalls meine Erinnerung von den damaligen traumatischen Experimenten.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Dank Deiner "Selbstgespräche" habe ich den remote-Teil meines Xubuntu-Upgrades (14.04 auf 18.04) erstmal hinbekommen :-). Der Umstieg scheint wieder nervige Tage zu kosten, da es ja noch andere Änderungen zu beachten gilt (z.B. [offiziell] kein rc.local mehr). Die FB reagiert über events/inputlircd aber auch sehr träge. Ich werde es ebenfalls mal direkt mit lirc allein probieren.

    Wenn dann scheint es am Zusammenspiel mit dem seriellen Empfänger zu liegen. Mein anderer VDR mit events/inputlircd und MCE-USB-FB macht keine Probleme...

    My VDRs:

    Zitat von dad401

    Mein anderer VDR mit events/inputlircd und MCE-USB-FB macht keine Probleme...

    was ist da für ein Empfänger verbaut?

    Das träge Verhalten hatte ich mit atric.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    Zitat von Dr. Seltsam

    ich hatte das damals ausprobiert, aber die FB war dadurch unglaublich zäh und langsam. vdr selbst kann ja auch nichts mit input devices anfangen. Man braucht entweder das remote-Plugin, oder muss doch wieder lirc mit devinput benutzen. So jedenfalls meine Erinnerung von den damaligen traumatischen Experimenten.


    Kommt drauf an wie du ausgibst.

    Eigentlich sollten die gängigen "X-Server-Basierten" Ausgabeplugins direkt mit einer Tastatur klarkommen.

    Zitat von Dr. Seltsam

    was ist da für ein Empfänger verbaut?

    Das träge Verhalten hatte ich mit atric.

    Das ist ein eigener USB-Empfänger.


    Zurück zum atric - gerade gestestet: mit lircd statt inputlirc ist es nicht so träge.


    Wäre schön, wenn ich es einheitlich über inputlirc konfigurieren könnte - geht aber leider nicht. Alle atric-VDRs bleiben erstmal auf LIRC. Nun muss ich nur noch herausfinden, wie ich den KEY_SLEEP (über inputdev-event) abstellen kann. Denn ohne inputlirc wird der KEY an systemd weitergereicht und der VDR geht direkt in den Standby. Aber das ist ein anderer Thread.

    My VDRs:

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden