Beiträge von whocares02

  • Hardware-Encoder Linux-fähig?

    Die Antwort kommt zwar ein bißchen spät, aber ja, man muss selbst kompilieren. Hier sind die allgemeinen Avidemux-Compile-Anweisungen. Mit Arch-Linux kenne ich mich nicht aus. Ich kann nur für Ubuntu sprechen. Man muss unbedingt hier die Nvidia-FFmpeg-Header-Dateien runterladen, damit der Compiler das im System installierte VAAPI und LibVA nutzen kann.

    Das heißt libva, vaapi und natürlich ffmpeg müssen auf jeden Fall installiert sein, um Videobeschleunigung zu bekommen. Ob noch was fehlt wird beim Kompilieren angezeigt. Das sieht dann zum Beispiel so aus:


    ...bei diesem Durchgang fehlten also noch viele Audio- und Video-Codecs im System, die man mit Paketmanager nachinstallieren muss. Wichtig: Der Compiler findet nur Pakete, die mit "-dev" enden. Ist im Paketmanager also zum Beispiel libvorbis installiert, nützt das nichts, um Vorbis-Unterstützung im avidemux zu bekommen. Das Paket libvorbis-dev muss dafür installiert sein.

    Das Compiler-Skript berichtet außerdeb, ob NVENC, libva und VAAPI gefunden wurden. Das fehlt jetzt in der Ausgabe, die ich oben gepostet habe. Sind die drei Sachen drin, sieht's schonmal sehr gut aus, mit der Videobeschleunigung.


    Das Kompilieren wird so gestartet:

    Code
     bash bootStrap.bash --deb --with-qt --with-cli --with-plugins --with-core


    ...wie man sieht gibt's da verschiedene Flags, um dem Compiler-Skript zu sagen was man haben will. Ich wollte also das Programm mit allen Plugins, QT5-Oberfläche, Kommandozeilenprogramm und das ganze als .deb-Pakete für die anschließende Installation.


    Eine Liste aller möglichen Flags gibt's mit dem Befehl:

    Code
    bash bootStrap.bash --help


    Ich habe diesen alten Thread jetzt nach drei Jahren zum Glück wiedergefunden, weil es tatsächlich immernoch nirgendwo Anleitungen gibt. Standardmäßig ist Avidemux auch nach drei Jahren immernoch ohne NVENC-Unterstützung in den Paketquellen. Ich habe auch nirgendwo Alternativ-Pakete gefunden - nicht mal AppImages oder Snap-Pakete. VDPAU und LibVA waren in meinem aktuellen Ubuntu vorinstalliert. Auch ffmpeg kommt inzwischen standardmäßig mit NVENC-Unterstützung...nur leider die Anwender-Programme nicht.


    Ich wusste wirklich nicht mehr, wie ich damals das Avidemux kompiliert hatte. Bitte nicht löschen, dieser Thread ist richtig wertvoll!

  • Serielles IR mit Lirc 0.10 unter Debian9

    Ein gutes neues Netzteil (Mean Well GST90A12-P1M mit 6,67A und 80W) in Kombination mit dem ersten Adapterboard hat die Störung minimiert. Das Netzteil hatte in einem Testbericht gut abgeschnitten und wurde als Beispiel für ein Premium-Netzteil genannt.


    Zur Sache mit dem IR: Das Zappeln kam von einem zweiten Lirc-Service, der im Hintergrund lief und abgeschaltet werden musste. Ich glaube er leitete die Eingaben zusätzlich als Kernel-Event an den Linux-Kernel weiter. Weil vermutlich die Tasten dabei die gleichen Bezeichnungen hatten, wurde dadurch alles doppelt (oder manchmal sogar endlos) registriert. Ein Abschalten dieses zweiten Services beendete den Spuk. Wie der genaue Befehl nun hieß weiß ich gerade nicht mehr. Sitze an einem anderen Computer. Sorry.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Ich weiß, das wird jetzt schwer offtopic:

    Wo Du gerade von Power sprichts: Ich bastele ja an einem kleinen ITX-Computer. Dessen Netzteil war furchtbar laut. Hab das Netzteil durch eine Adapterplatine Ersetzt, das von einem externen 12V-Netzteil gespeist wird (sog. ITX-PSU - gibt's extra für MiniPCs). Jetzt flackert das Bild! Wie bescheurt! Neues Adapterboard geholt -> keine Änderung. Jetzt bleiben zwei Möglichkeiten: Entweder beide Adapterboards sind Käse oder das Netzteil taugt nichts. Jetzt suche ich nach einem neuen Netzteil und stelle fest: Ich finde gar keine Markenhersteller! Wie kann ich die Adapterboards als Fehlerquelle ausschließen und worauf müsste ich beim Netzteilkauf achten? Mir wird's gerade ein wenig zu teuer...


    Was das noch mit IR zu tun hat? Nach dem Hochfahren "zappelt" die IR-Erkennung. Es werden willkürlich Tasten registriert. Nach einiger Zeit und Tastendrückerei ist es dann weg. Ich habe das Stromversorgungsproblem in Verdacht. Zumal auch das Drücken von Tastatur-Tasten die Zappelei beseitigt.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Oh nein, noch mehr Hausaufgaben... OK, werde mir das anschauen und mich dann melden. Unterdessen hier die geforderte lircd.service:



  • Serielles IR mit Lirc 0.10 unter Debian9

    geht das ein bisschen genauer? lircd soll ganz am Schluss starten. Vielleicht fuehrt es dann ja doch den modprobe-Befehl aus, der in seiner /etc/lirc/lirc_options.conf am Schluss steht.


    Das vollautomatische Laden des Kernel-Modules beim Booten wuerde ich dafuer entfernen. COM2 ist ja am Ende des Bootvorgangs stets richtig konfiguriert. Irgendeins der vielen Bootup-Skript fuehrt setserial also korrekt aus...nur eben immer NACH dem Laden des Kernel-Modules serial_ir. Ich brauche also ein "modprobe serial_ir" ganz am Schluss des Bootvorgangs, aber VOR lircd.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Wieviele Startup-Dienste gibt es denn bei Debian? lircd habe ich bisher mit systemctl gestartet, dann gibt es den Befehl service, es gibt ausserdem einen Ordner /etc/init.d mit Startup-Skripten, nicht zu vergessen diese runlevel-Ordner /etc/rc[0-6].d. Sind das jetzt nicht mindestens drei verschiedene Bootup-Dienste?


    Edit:


    So wie ich das sehe, nutzt Debian bereits systemd. Wollte da mal kurz ein paar Docs zu ueberfliegen...keine Chance..dafuer braucht man ein Studium. Auch sytemd-gui ist nicht hilfreich. Reihenfolgen lassen sich da nicht festlegen.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Hab hier auch was gefunden: Link. Da hatte einer genau mein Problem. Bei ihm heisst der Befehl allerdings preinstall statt install und braucht keine Semikolons. Hat trotzdem nicht funktioniert.


    Ich werde Deinen Vorschlag ausprobieren.


    Alternativ habe ich versucht, die Reihenfolge in /etc/rc0.d zu aendern. Die Start-Skripte sind ja durchnummeriert K01lircd kommt natuerlich (alphabetisch) VOR K01setserial. Habe also die Reihenfolge geaendert und dabei ein neues Skript eingefuegt, in dem einfach


    Code
    modprobe serial_ir


    steht. Wieder kein Erfolg.


    Wenn ich schon dabei bin das Modul per Skript zu laden, kann das eigentlich auch das Lirc-script machen (wie eigentlich ja vorgesehen). Also wieder /etc/lirc/lirc_options.conf editiert und da die Kommentarzeichen vor den Code-Zeilen (am Ende der Datei) wieder weg. Dann muessten ja setserial und modprobe ausgefuehrt werden...passiert aber nicht. Wieso fuehrt das lirc-skript eigentlich nicht diese Befehle aus?

    Wuerde mir ja schon reichen, der unelegante Weg. Es geht aber einfach gar keiner! Das kann doch nicht sein! Ich werd' doch noch ein Skript beim Boot-Up ausfuehren koennen!


    Ich probier jetzt noch Deine Methode aus.


    Edit:


    Ich hatte noch vergessen zu erwaehnen, dass der Kernel sicherheitshalber noch folgende Option von mir in der /etc/default/grub spendiert bekommen hat:


    Code
    GRUB_CMDLINE_LINUX_DEFAULT="quiet 8250.nr_uarts=4"


    8250.nr_uarts=4 teilt dem Kernel mit, dass es ings. 4 Serial-Ports gibt. Leider hat das aber nichts geholfen.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Nachdem ich mir die Ausgaben mal selber genauer angeschaut habe, habe ich mal die ganzen Fehler beseitigt, die da gemeldet werden:


    -> .conf-Dateien der Fernbedienungen bereinigt

    -> in der /etc/lirc/lirc_options.conf die Zeile /var/run/... in /run/... geaendert

    -> in der Datei /etc/modules-load.d/serial_ir.conf wieder auf Ausgangs-Eisntellung: Da steht einfach nur noch serial_ir drin.


    Ergebnis ist ein deutlich kuerzeres Log nach dem Booten:


    cat /var/log/syslog|grep lirc

    Pastebin-Link



    cat /var/log/syslog|grep serial


    Pastebin-Link


    Die /var/lib/setserial/autoserial.conf ist gleich geblieben:


    Code
    /dev/ttyS1 uart none port 0x02f8 irq 3
/dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal skip_test

    Es ist schon wie ich vermute: Setserial wird nicht oder zu spaet ausgefuehrt. Sonst staend das nicht extra im Log beim module-load:


    Zusammengeschnitten steht da ja:

    Zitat

    port 02f8 already in use

    use 'setserial /dev/ttySX uart none'

    or compile the serial port driver as module and

    make sure this module is loaded first

    Wenn ich das richtig auswerte, wird laut Log versucht, einfach COM1 zu benutzen.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Bei beiden Befehlen kommt gar nichts. Habe soeben frisch gebootet.

    Ja, die Datei heisst korrekterweise /etc/modules-load.d/serial_ir.conf.

    Ich komme hier langsam ein wenig durcheinander mit den ganzen .conf-Dateien. Auch diese autoconf-Datei (kompletten Pfad bitte jetzt mal selber denken) ist tatsaechlich hier versehentlich doppelt eingefuegt worden.

    Ich versuche es jetzt mit der neuen serial_ir.conf.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Mir kam gerade der Einfall, dass /etc/lirc/lirc_options.conf ja auch noch den Aufruf des Kernel-Moduls und auch den Aufruf von setserial enthaelt. Also die Codezeilen am Ende der Datei auskommentiert und neu gestartet. Kein Unterschied.

    Umgekehrter Fall: Modul nicht mehr beim Booten laden lassen und die lirc_options.conf alles erledigen lassen..warum denn nicht?


    Da stellt sich die Frage, ob lirc denn ueberhaupt automatisch gestartet wird. systemctl status lircd direkt nach dem Booten zeigt nun folgendes:

    Ist das vielleicht irgendein Rechte/Gruppen-Problem?

  • Serielles IR mit Lirc 0.10 unter Debian9

    Zitat von Dr. Seltsam

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

    Hatte ich auch. Was soll mich hindern, die wieder anzulegen? Ich probier halt alles aus.


    Diese /etc/modules kannte ich noch nicht. serial_ir hab ich jetzt mal da reingeschrieben, statt in diese andere Datei, deren Name ich gerade vergessen habe. Gleichzeitig

    steht in der /etc/modules-load.d/serial_ir:

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

    und in der /var/lib/setserial/autoserial.conf:


    Da passiert das gleiche wie vorher: Wenn ich im mode2 oder irw was sehen will muss ich erst


    Code
    rmmod serial_ir
modprobe serial_ir
systemctl restart lircd

    nach dem Booten eintippen. Mir scheint, diese Serial-Einstellungen kommen erst nach dem Modul-Load zur Anwendung, denn /dev/ttyS1 ist richtig konfiguriert.


    Code
    #setserial /dev/ttyS1
/dev/ttyS1, UART: unknown, Port: 0x02f8, IRQ: 3

  • Serielles IR mit Lirc 0.10 unter Debian9

    Ich habe den Eindruck, dass /etc/modules-load.d/serial_ir.conf das Modul serial_ir laedt, aber ohne den rictigen COM-Port. Ich muss naemlich


    Code
    rmmod serial_ir


    und

    Code
    modprobe serial_ir


    eintippen, wenn ich danach Lirc und mode2 von Hand starten will.

    Kann es sein, dass setserial beim Booten irgendwie erst nach dem modprobe ausgefuehrt wird?


    Ausserdem: Es gibt auf meinem System eine Datei /var/lib/setserial/autoserial.conf


    Inhalt:

    Da steht alles richtig drin. Verstehe gar nicht, warum das setserial uebrhaupt noch gebraucht wird.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Ich weiss was GND ist.


    Zitat von Argus

    auf welche Belegung ?

    Von Pin5 auf Pin9. Das aendert aber auch nichts daran, dass RTS nicht hochgezogen wird. Lirc hat Macken in den 0.9er-Versionen! Ich kann froh sein, dass DTS jetzt geht und werde das nicht weiter ausreizen.

    Uebrigens habe ich eine elegante Loesung gefunden: Auf dem Mainboard sind Pins fuer Speaker und Chassis-Intrusion. Beides brauche ich nicht. Dadurch sind da gleich zwei freie 5V- und GND-Pins. Perfekt fuer die Jumper-Kabel meines Empfaengers.


    Zitat von seahawk1986

    Ist das Paket setserial installiert?

    Ja.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Jaja, umstecken hatte ich schon probiert. Es lag ja gar nicht nur am GND, sondern auch an den -11V an RTS, die nicht auf +11V geaendert wurden. Oder anders gesagt: Lirc sollte Serial so ansprechen, dass RTS nicht gepollt wird, sondern als Stromquelle herhaelt. Das hat offensichtlich nicht geklappt. Keine Ahnung was mit dem GND-Pin ist, ob der von Lirc haette runtergezogen werden muessen.


    Das mit den beiden Dateien fuer das Bootup klappt nicht. Beim Booten wird sich beschwert, dass der Port belegt sei. Ich kann Lirc dann auch nicht mehr manuell starten. Deshalb habe ich die Dateien wieder entfernt. Jetzt geht's wieder.


    Trotzdem brauche ich ein Autostart

    Ich hatte zudem den Befehl fuer den Lirc-Service falsch getippt. So scheint was zu passieren:

    Code
    systemctl enable lircd
Synchronizing state of lircd.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable lircd

    Natuerlich gibt's immernoch kein Autostart, weil ja der Port freigemacht und das kernel-modul vorher geladen werden muss.


    Nicht zuletzt gibt's noch ein kleines Problem mit Kodi: Es reagiert nur auf eine von zwei Fernbedienungen, obwohl beide in der Lircmap.xml definiert sind. irw reagiert korrekt auf beide.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Nene, auf dem Mainboard sind Pfostenstecker fuer eine COM2-Slotblech-Erweiterung. Da hatte ich Jumperkabel drangesteckt - diese Dupont-Kabel fuer Breadboards.


    Ich habe die beiden empfohlenen Dateien angelegt. Wie bekomme ich nun Lirc automatisch beim Booten gestartet?


    Code
    systemctl enable lirc
Failed to enable unit: Unit file lirc.service does not exist.systemctl enable lirc


  • Serielles IR mit Lirc 0.10 unter Debian9

    Es laeuft! Ich glaub's nicht! Ich hatte mir schon die Anleitung fuer einen Arduino-Empfaenger rausgesucht. Seit Lirc 0.93+ ist da naemlich eine Arduino-Unterstuetzung im Lirc.

    4 Tage! Mit Nachtschichten! Ich hab nicht mehr d'ran geglaubt!


    Dr. Seltsam schrieb:

    Zitat

    Wenn da nicht automatisch active-low kommt, ist der Empfänger entweder nicht richtig angeschlossen und/oder hat einen Hardware-Fehler.

    Deshalb bin ich jetzt einfach hin und hab die Stromversorgung des Empfaengers selbst sichergestellt. Plus kommt jetzt von der 5V-Leitung eines Molex-Steckers. Lirc meldete dadurch ploetzlich "Active-Low". mode2 empfing immernoch nichts. Spannungen geprueft und festgestellt, dass auch am Minuspol eine Spannung liegt (Pin 5 des Serial-Anschlusses). Als ich den Minuspol dann an echtes GND gelegt hatte, erwachte alles zum Leben! Die Empfaenger LED-blinkt hell und blau, mode2 schickt seitenweise Gruesse. Mit dem Seriell-Anschluss ist also nur noch die Datenleitung (Pin1 / DCD) verbunden. Sonst nichts.

    Zur Visualisierung nochmal das Diagramm im Anhang.

    Wie gesagt: GND und RTS kommen jetzt direkt vom Molex-Stecker des Netzteils. Statt mit RTS ist der Empfaenger also mit der +5V-Leitung verbunden.

  • Serielles IR mit Lirc 0.10 unter Debian9

    Nein, kannte ich noch nicht. Werde ich machen. Habe aber das hier versucht, abgewandelt von hier:


    Code
    modprobe serial_ir sense=1


    Ergebnis (nach Lirc-Neustart):


    Code
    [ 3425.164461] serial_ir: unknown parameter '/dev/ttyS1' ignored
[ 3425.164914] serial_ir serial_ir.0: Manually using active low receiver
[ 3425.164931] Registered IR keymap rc-rc6-mce
[ 3425.165014] rc rc0: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0
[ 3425.165133] input: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0/input24
[ 3425.165510] rc rc0: lirc_dev: driver serial_ir registered at minor = 0, raw IR receiver, raw IR transmitter

    Da steht jetzt active-low! Leider bringt es nichts: Der Receiver empfaengt immernoch nichts.