Posts by Dr. Seltsam

    heisst Deine Datei jetzt /etc/modules-load.d/serial_ir oder /etc/modules-load.d/serial_ir.conf?

    Ich bin mir nicht sicher, ob in Zeile 2 die Auskommentierung greift, wenn sie nicht am Anfang steht. da das schon in Zeile 1 steht, ist es zudem überflüssig.

    Und Zeile 3 ist nochmal das gleiche.


    Bei Deiner autoserial.conf hoffe ich mal, dass die nicht wirklich so aussieht, sondern hier nur falsch bzw. doppelt reinkopiert wurde.


    Mir fiel noch auf, dass ich in meiner /etc/lirc/lirc_options.conf den Eintrag nodaemon = True habe, während es bei Dir False ist.

    Code
    1. [lircmd]
    2. uinput = False
    3. nodaemon = True


    Und meine /etc/modprobe.d/serial-ir.conf sieht anders aus:

    Code
    1. install serial_ir setserial /dev/ttyS0 uart none; modprobe --ignore-install serial_ir

    Das habe ich auch nur aus dem Forum und verstehe die Syntax nicht wirklich. Das heisst ich weiss auch nicht, wie man hier die anderen Modulparameter für den Port mit einbaut. Aber eigentlich müsstest Du das für Deinen Fall direkt dahinter schreiben können:


    Code
    1. install serial_ir setserial /dev/ttyS1 uart none; modprobe --ignore-install serial_ir irq=3 io=0x2f8

    Ich dachte, Du hattest /etc/modules-load.d/serial_ir.conf schon wieder gelöscht?

    Ich habe den Eintrag "serial-ir" direkt in /etc/modules drin. Kommt aufs gleiche hinaus Für die Modulparameter ist ausschließlich /etc/modprobe.d/serial_ir.conf zuständig. Und das muss funktionieren.


    Auf meinem Ubuntu 18.04 ist /etc/serial.conf auch nicht vorhanden, und im [modinit]-Abschnitt der /etc/lirc/lirc_options.conf habe ich auch nichts stehen. Ich meine mich zu erinnern, dass ich auch lange an dem Punkt festhing. Laut https://wiki.ubuntuusers.de/Lirc/ istd er richtige Weg jetzt bein Eintrag in /var/lib/setserial/autoserial.conf. Darin steht bei mir

    Code
    1. setserial /dev/ttyS0 uart none


    Bei Dir wäre es dann ttyS1.

    auf alle Fälle solltest Du

    code2 = /sbin/modprobe serial_ir ttyS1

    in

    code2 = /sbin/modprobe serial_ir

    ändern. Mit sense die Autoerkennung zu übergehen dürfte auch nichts bringen. Wenn da nicht automatisch active-low kommt, ist der Empfänger entweder nicht richtig angeschlossen und/oder hat einen Hardware-Fehler.

    Mein Reden :-)

    Ändere in /etc/lirc/lirc_options.conf im Abschnitt [lircd] den driver von devinput auf default.

    /etc/modprobe.d/lirc.conf kannst Du löschen.

    Solange Du im Log

    Code
    1. serial_ir serial_ir.0: auto-detected active high receiver

    bekommst, hast Du ein Problem. Das muss low sein.

    Wenn Da eine Spannung umgeschaltet werden muss, dann durch serial-ir, denn das hat lirc-serial ersetzt.

    lircd ist nur ein Daemon und schaltet keine Hardware.

    Leider ist sehr schlecht bis gar nicht dokumentiert, wie das alles zusammenspielt und funktioniert.


    Die Einstellungen in /etc/lirc/lirc_options.conf betreffen ja nicht die Modulparameter der Kernelmodule. Damit serial_ir einen bestimmten COM-Port benutzt, muss man das schon als Modulparameter vorgeben. Bei Ubuntu (und dann wahrscheinlich auch Debian) geht das mit einer

    /etc/modprobe.d/serial_ir.conf mit folgendem Inhalt für den seriellen Port COM1


    Code
    1. # COM2 equivalent: /dev/ttyS1
    2. options serial_ir irq=3 io=0x2f8

    Im [modinit]-Abschnitt der /etc/lirc/lirc_options.conf muss dann analog

    Code
    1. code = /usr/bin/setserial ttyS1 uart none

    stehen.

    Und ich würde mal probieren, im Abschnitt [lircd] den driver = devinput in driver = default zu ändern.

    als ich das letzte Mal lirc unter Ubuntu 18.04 eingerichtet habe, bin ich fast verrückt geworden. Auch andere sind auf aktuellen Systemen verzweifelt, siehe (vdr4)Arch - serial_ir ersetzt lirc_serial Modul mit Kernel >= 4.10


    Da die direkte Nutzung der Kernelschnittstelle über /dev/input... grottenlahm im Vergleich zu lirc war, habe ich die Nutzung der seriellen Schnittstelle für mich abgehakt. Beim nächsten mal werde ich mir ein FLIRC-Modul kaufen, dass einfach eine Tastatur emuliert.


    lirc ist deprecated und wird z.B. von mpv längst nicht mehr unterstützt. Um mittels mplayer-Plugin mpv nutzen zu können, musste ich mit irxevent jedes lirc-Kommando in einen Tastaturbefehl umwandeln. Das ist mit FLIRC dann auch nicht mehr notwendig.

    Ich muss noch die Anmerkungen von hier und hier berücksichtigen, dann werde ich den Patch nach ftp://ftp.tvdr.de/vdr/Developer/Patches/vdr-2.4 einspielen. Damit sollte es dann funktionieren, vorausgesetzt, an allen Eingängen liegen entsprechende Signale an. Devices zu erkennen, an denen (evtl. temporär) kein Signal anliegt, kommt danach.


    Klaus

    und während der Wiedergabe: "vdr wird in 5:00 Minuten abgeschaltet" bitte nicht vergessen

    Ich glaube ihr redet aneinander vorbei und habt beide Recht.


    Deprecated ist Ziffer 6 der API, und hier insbesondere die Decoder-ioctls in Ziffer 6.2 und 6.3. Dieses API wurde zunächst ausschließlich von vdr (zunächst im core, später im dvbsddevice-Plugin) genutzt. Zu der Zeit war die alte SD-FF-Karte (Treiber dvb-ttpci) der einzige Hardwaredecoder, der vom Linux-Kernel unterstützt wurde. Vor über 10 Jahren kam dann der ivtv-Treiber dazu und benutzte für den Hardwaredecoder der PVR350 ebenfalls dieses API, was wegen weiterer Besonderheiten der Karte aufgebohrt wurde. Das von mir damals mitentwickelte pvr350-Plugin war dann lange Zeit neben dem dvbsddevice-Plugin das einzige Userspace-Programm (sieht man mal von Testfunktionen in v4l2-ctl ab), das dieses API nutzte.


    Von mir völlig unbemerkt (wer nutzt heute schon noch reine MPEG2-Decoder und SDTV?) und vermutlich auch von der Mehrheit der vdr-Nutzer (das dvbsddevice-Plugin ist mittlerweile nicht mehr Bestandteil der vdr-Sourcen) wurde das API in Teil 6 dann für obsolet erklärt (sicher keine einsame Einzelentscheidung von Mauro) und durch neue ioctls in Ziffer 7 ersetzt. Vorausgegangen war eine intensive Diskussion in der community , wie dieses Posting zeigt. Der ivtv-Treiber wurde entsprechend angepasst - die alten ioctls aus dvb/video.h und dvb/audio.h sind dort zwar noch enthalten, aber als deprecated gekennzeichnet. Der Treiber unterstützt also schon das neue API. Analog hätte jetzt eigentlich auch der dvb-ttpic-Treiber (und in der Folge ggf. das dvbsddevice-Plugin, sofern es noch jemand benutzt) angepasst werden müssen, aber nachdem UFO schon vor Jahren entnervt das Handtuch geworfen hatte, hat der Treiber ja keinen Maintainer mehr.


    Dass das dvbhddevice-Plugin und der Treiber für die TT6400 einige ioctls des alten API (Teil 6) benutzten, war mir bislang neu. Dass Mauro schon in der Phase, wo die alten ioctls nur als deprecated markiert, aber noch vorhanden sind, das ioctl AUDIO_GET_PTS einfach rausschmeisst, nur weil es nicht in der API dokumentiert ist, war sicher schwach. Man hätte sich ja auch stattdessen fragen können, ob vielleicht nur die Dokumentation unvollständig ist. Auch hätte er merken müssen, dass zumindest ein im Kernel enthaltener Treiber (dvb-ttpci) es noch unterstützt hat. Wie auch immer, das ist ja nun wieder drin. Es löst aber das Problem nicht, dass irgendwann die deprecated ioctls rausfliegen werden. In einer idealen Welt hätten Treiber-Maintainer und Userspace-Entwickler jetzt geprüft, ob das gewünschte Ziel mit einem der neuen ioctls aus Teil 7 darstellbar ist bzw. ob man überhaupt ein ioctl dafür braucht - und wenn das nicht möglich ist, einen entsprechenden Vorschlag zur Erweiterung des neuen API gemacht.


    Ein ganz wesentliches Problem bleibt aber offen: Auch das neue API orientiert sich am Bedarf von MPEG2-Dekoderkarten. Ich gehe mal davon aus, dass ein h264-Dekoder ganz andere Anforderungen stellt und andere, zusätzliche ioctl braucht. In der Situation dann nur auf das v4l2-API (Teil 7) zu verweisen und den Entwickler alleine damit zu lassen, notwendige Erweiterungen vorzuschlagen und durchzusetzen, ist etwas mager für einen linuxtv-Maintainer.


    Abschließend sei allerdings die Frage erlaubt, ob es wirklich sinnvoll ist, für einen einzigen existierenden h264-Hardwaredekoder, der zudem keine große Verbreitung hat und schon lange nicht mehr als Neuware erhältlich ist, viel Zeit in die Erweiterung eines API zu investieren. Die TT6400 kann nichtmal FullHD ausgeben, und schon in wenigen Jahren wird sie genauso vergessen sein wie die SD-FF-Karte oder die PVR350. Von daher könnte es vielleicht zielführender sein, den Treiber außerhalb des Kernels zu lassen. Denn eins ist klar: Wenn er es in den Kernel schafft, dann nur mit neuen ioctls. Es müsste in der Folge also auch noch jemand gefunden werden, der das dvbhddevice-Plugin entsprechend anpasst.