Beiträge von Dr. Seltsam

  • media-build-dkms

    Die neuen Module wurden in /lib/modules/4.15.0-22-generic/updates/dkms installiert.

    Die alten Module sind in /lib/modules/4.15.0-22-generic/kernel/drivers/media verblieben.


    Wenn ich jetzt einen Treiber laden will, kommt


    martin@ubuntuvdr1:~$ sudo modprobe dvb_usb_dib0700

    modprobe: ERROR: could not insert 'dvb_usb_dib0700': Exec format error

  • femon: nach update auf vdr 2.4.0 keine Anzeige mehr von STR, CNR und BER

    ich habe mal in den Code von Klaus' dvbdevice.c gesehen. Da gibt es einen "Fall back to DVB API 3". Deshalb sieht man im LCARS-Skin auch Balkenanzeigen für STR/SNR. Auch einige skindesigner-Skins zeigen diese Werte an.

    Es ist mir unverständlich, weshalb die Abwärtskompatibilität dann nicht auch im femon-Plugin dringelassen wurde, solange es noch nicht angepasste Treiber gibt.

  • Ubuntu 18.04. - kein /etc/acpi/powerbtn.sh mehr?

    Vielleicht hat hierzu noch einer eine Idee:


    Ich habe einen kompletten xfce-Desktop installiert und starte vdr über das runvdr-Script von Klaus, das im Autostart von xfce eingetragen ist. Wenn ich jetzt über das poweroff-Script den neuen Timer ins ACPI schreibe, softhddevice detache und danach poweroff ausführe, erscheint zunächst eine Maske von xfce mit der Auswahloption für Abmelden, Neustart oder Herunterfahren. Nach ein paar Sekunden geht der Rechner dann aus, obwohl ich keine Option ausgewählt habe.

    Unter "Sitzung und Startverhalten" in den xfce-Einstellungen habe ich in den Abmeldeeinstellungen den Punkt "vor dem Abmelden nachfragen" aktiviert. Wenn ich das nicht ankreuze, wird mein User nicht nur sofort ausgeloggt, sondern der Rechner schaltet sich auch aus, ohne dass überhaupt die Warnung von vdr über ein bevorstehendes Aussschalten angezeigt wird. Es scheint, als wenn /etc/acpi/powerbtn.sh und der darin enthaltene Aufruf von "/usr/local/bin/svdrpsend HITK power" dann gar nicht ausgeführt wird.


    Ich habe den Punkt "vor dem Abmelden nachfragen" in meinem zweiten vdr auch aktiviert, da erscheint hingegen keine Anzeige der Abmeldeoptionen beim poweroff.


    Kann es sein, dass der Eintrag HandlePowerKey=ignore in /etc/systemd/logind.conf nicht greift, wenn Abmelden ohne Nachfragen aktiviert ist?

  • wenn Audioausgabe von softhddevice über pulseaudio, hängt Rechner beim Runterfahren

    TheChief schrieb:

    Eventuell softhddevice vor dem runter fahren detachen (svdrpsend plug softhddevice deta) Hatte selbiges Problem, allerdings unter Debian und mit alsa.

    hast Du eine Idee, wo ich das bei einem systemd-basierten System eintragen kann?

    Oder wahrscheinlich am einfachsten direkt im poweroff-Script, nach dem Schreiben in /sys/class/rtc/rtc0/wakealarm und vor dem Auruf von poweroff?

  • wenn Audioausgabe von softhddevice über pulseaudio, hängt Rechner beim Runterfahren

    Ich habe dazu bereits einen Thread im ubuntuusers-Forum aufgemacht, aber vielleicht hat ja hier jemand auch schon mal das Problem gehabt und eine Idee dazu.


    Ubuntu 18.04 läuft mit pulseaudio. Den vdr habe ich selbst kompiliert und lokal installiert. Gestartet wird er mit der Original runvdr aus den vdr-Sourcen über einen Autostart-Eintrag in xfce. Für softhddevice übergebe ich keine Parameter für audio devices, nutze also die Standardausgabe = pulseaudio. Dabei spielt es keine Rolle, ob ich das pulsecontrol-Plugin verwende oder nicht.


    Problem: Wenn ich mit laufendem vdr den Rechner runterfahre, kommt es zu einer langen Verzögerung von 90s:

    Beende ich vdr vor dem Runterfahren manuell, gibt es kein Problem. Ebenso gibt es kein Problem, wenn ich softhddevice die direkten alsa-devices vorgebe:

    Spoiler anzeigen


    Spricht etwas dagegen, das so zu lassen? Ich meine mich zu erinnern, das bei dieser Konfiguration früher mal zur Deinstallation von pulseaudio geraten wurde.

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

    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
    1. 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
    1. -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
    1. -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.
     

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

    ich führe weiter Selbstgespräche...


    Leider musste ich feststellen, dass die Fernbedienung ohne lirc und nur über den Kernel erheblich träger läuft. Ich habe bereits mit delay und repeat-Werten gespielt, aber flüssiges Scrollen durch die Menüs ist damit nicht möglich. Die gleiche FB über lircd läuft super flott.

    So sieht meine lirc_options.conf in Ubuntu 18.04 aus:




    inputlirc ist deinstalliert, und ganz wichtig ist die Deaktivierung von lircd-uinput im Abschnitt [lircmd]. Den Abschnitt

    [modinit] habe ich noch auskommentiert, da ich serial-ir über einen Eintrag in /etc/modules in Verbindung mit einer Konfigurationsdatei in /etc/modprobe.d starte.


    Nun gibt es aber ein unerwartetes Problem, da sich in meiner 15jährigen vdr-Laufbahn bisher nicht hatte:

    Direkt nach dem Start funktionieren einige Tasten nicht richtig. Ich weiss nicht mal, ob es die Tasten sind oder vdr. Immerhin spielt es dabei keine Rolle, ob ich die FB oder die Tastatur zur Steuerung benutze. Folgendes Phänomen: Beim Umschalten wird die Kanalanzeige nicht eingeblendet. Drücke ich kurz auf die ok-Taste, blitzt die Kanalanzeige für einen Sekundenbruchteil auf. Die Zifferntasten funktionieren auch nicht. Man sieht auch hier ganz kurz eine OSD-Einblendung, aber der vdr reagiert nicht auf die Taste bzw. schaltet das Programm nicht um. Andere Tasten bzw. Funktionen funktionieren einwandfrei. Welches OSD ich verwende, spielt keine Rolle. Wenn ich vdr ohne die --lirc-Option starte und nur über die Tastatur steuere, ist es das gleiche. Aber: nach ein paar Minuten gibt sich das von selbst. Mir fällt auf, dass die load am Anfang auch sehr hoch ist (über 1) und danach auf 0,03 fällt.
    im Log ist nichts zu sehen. vdr loggt überhaupt nichts beim Drücken der nicht reagierenden Tasten.


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

    mühsam nährt sich das Eichhörnchen...


    Ich habe es jetzt mit inputlirc versucht. Das lief auch schon mal. Nun kriege ich aber nur noch

    Code
    1. Apr 27 14:57:55 ubuntuvdr1 inputlircd[1600]: /dev/input/event12 100013
    2. Apr 27 14:57:55 ubuntuvdr1 inputlircd[1600]: Unable to bind AF_UNIX socket to /var/run/lirc/lircd: No such file or directory
    3. Apr 27 14:57:55 ubuntuvdr1 systemd[1]: inputlirc.service: Main process exited, code=exited, status=71/n/a
    4. Apr 27 14:57:55 ubuntuvdr1 systemd[1]: inputlirc.service: Failed with result 'exit-code'.


    /etc/default/inputlirc:

    Code
    1. # Options to be passed to inputlirc.
    2. #EVENTS="/dev/input/event12"
    3. EVENTS="/dev/input/by-path/platform-serial_ir.0-event-ir"
    4. OPTIONS="-d /var/run/lirc/lircd -g -m 0"


    Das device ist richtig.

    Nach meinem Verständnis sollte der Socket /var/run/lirc/lircd doch gerade von inputlirc angelegt werden - wieso kommt da eine Fehlermeldung, dass es den nicht gibt? Wer sonst sollte das Socket anlegen?


    Mit dem remote-Plugin geht es. Gibt es aber wirklich keine einfachere Alternative? Ich glaube, die Unterstützung von anderen Kernel-Inputdevices als Keyboards sollte auf die To-Do-Liste für vdr 2.5

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

    ich habe jetzt lirc komplett deinstalliert, weil es nach jedem Neustart nicht mehr funktionierte und ich einfach nicht heraus bekam, wo es hakte. Es gibt also weder eine /etc/lirc noch lircd . Stattdessen will ich es nun mal auf die neue, angeblich einfachere Art versuchen.


    Erstes Problem war, dass der Eintrag "setserial /dev/ttyS0 uart none" in /var/lib/setserial/autoserial.conf anscheinend beim Laden von serial-ir unberücksichtigt bleibt, nachdem dieses Modul nun über einen Eintrag in /etc/modules geladen wird. Erst nachdem ich eine /etc/modprobe.d/serial-ir.conf mit dem Inhalt

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

    angelegt hatte, funktionierte es.


    Ich habe bereits eine keymap angelegt. Das ging mit der Anleitung von MarMic auch ganz gut. Ich musste mich dazu allerdings von dem bisher genutzen Code eines Aiwa-VCRs trennen, da dessen Codes von keinem Protokoll erkannt wurden.


    Das Laden der keymap mit Vorgabe des richtigen Protokolls übernimmt im Moment noch der Eintrag

    Code
    1. ir-keytable -s rc0 -c -p rc-6 -w /etc/rc_keymaps/Ru880_Kabel_004

    in /etc/rc.local


    Die Syntax von /etc/rc_maps.cfg (driver - table - file) verstehe ich nämlich noch nicht so ganz. Im Kopf der standardmäßig bereits vorhandenen Datei steht

    Zitat

    table - RC keymap table, provided via uevent - use * for any table

    Was ist die "RC keymap table"? Und wie gebe ich das Protokoll vor?


    Ist /etc/rc_maps.cfg das Ubuntu-Equivalent zu /etc/rc_maps.conf?


    ir-keytable sagt nun:

    Code
    1. /sys/class/rc/rc0/ gefunden (/dev/input/event14) mit:
    2. Name: Serial IR type home-brew
    3. Treiber: serial_ir, Tabelle: rc-rc6-mce
    4. Lirc Gerät: /dev/lirc0
    5. unterstützte Protokolle: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
    6. Aktivierte Protokolle: lirc rc-6
    7. bus: 25, Anbieter/Produkt: 0001:0001, Version: 0x0100
    8. Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms

    Im syslog steht

    Code
    1. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.918418] serial_ir serial_ir.0: auto-detected active low receiver
    2. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.927287] lirc_dev: IR Remote Control driver registered, major 240
    3. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.994552] rc rc0: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0
    4. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.994690] input: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0/input14
    5. Apr 26 13:56:43 ubuntuvdr1 kernel: [ 3641.995267] lirc lirc0: lirc_dev: driver ir-lirc-codec (serial_ir) registered at minor = 0

    Wie schaffe ich es nun, dass vdr auf diese Fernbedienung hört? Wenn ich vdr mit der lirc-Option starte, hagelt es Fehlermeldungen

    Code
    1. ERROR (lirc.c,43): /var/run/lirc/lircd: Datei oder Verzeichnis nicht gefunden

    Brauche ich jetzt das remote-Plugin? Oder eventlirc? Oder das inputdev-Plugin?



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

    Ich blicke hier trotzdem nicht durch...

    Meine Fernbedienung ist eine programmierbare Fernbedienung, wo ich unter der für den VDR vorgesehenen Gerätetaste die Codes eines Aiwa-Videorekorders programmiert habe. Dazu habe ich bereits eine passende lircd.conf.


    Nachdem ich nun in der /etc/lirc/lircmd.conf den Eintrag

    driver = devinput

    auf

    driver = default

    geändert habe, läuft die Fernbedienung über /dev/lirc0 und lircd statt /dev/input/event15. Das funktioniert also.


    Was müsste ich denn tun, um auf lircd verzichten zu können? Wie kann ich dem Treiber beibringen, dass er mit Protokoll rc-5 statt rc-6 arbeiten soll? Gibt es eine Möglichkeit, die lircd.conf in eine keymap umzuwandeln?



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

    Moin,

    mit Ubuntu 18.04 beisse ich mir im Moment noch die Zähne aus.


    Das sieht soweit ganz gut aus:


    Code
    1. [ 715.696863] serial_ir serial_ir.0: auto-detected active low receiver
    2. [ 715.706154] lirc_dev: IR Remote Control driver registered, major 240
    3. [ 715.710794] IR LIRC bridge handler initialized
    4. [ 715.744854] Registered IR keymap rc-rc6-mce
    5. [ 715.750690] IR RC6 protocol handler initialized
    6. [ 715.776991] rc rc0: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0
    7. [ 715.777130] input: Serial IR type home-brew as /devices/platform/serial_ir.0/rc/rc0/input16
    8. [ 715.777559] lirc lirc0: lirc_dev: driver ir-lirc-codec (serial_ir) registered at minor = 0


    Ich sehe bei jedem Tastendruck die grüne LED vom atric-Einschalter blinken. Es passiert aber nichts. Auch irrecord erkennt keinen Tastendruck. Was mich stutzig macht ist der Hinweis "IR RC6 protocol handler initialized". Ich meine, dass meine FB nur RC5 kann. Laut ir-keytable kann der Lirc-Receiver zwar RC5, aber es sit anscheinend nur das Protokoll RC6 aktiviert.

    Code
    1. martin@ubuntuvdr1:/tmp$ sudo ir-keytable
    2. /sys/class/rc/rc0/ gefunden (/dev/input/event15) mit:
    3. Name: Serial IR type home-brew
    4. Treiber: serial_ir, Tabelle: rc-rc6-mce
    5. Lirc Gerät: /dev/lirc0
    6. unterstützte Protokolle: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 sharp xmp
    7. Aktivierte Protokolle: lirc rc-6
    8. bus: 25, Anbieter/Produkt: 0001:0001, Version: 0x0100
    9. Wiederholungsverzögerung = 500 ms, Wiederholungsperiode = 125 ms

    Kann das eine Erklärung sein, warum der IR-Receiver nichts empfängt? Wie kann ich das Protokoll wechseln?

  • Ubuntu 18.04. - kein /etc/acpi/powerbtn.sh mehr?

    wow, vielen Dank!

    Nach Ändern der /etc/systemd/logind.conf konnte ich meine vorhandenen Dateien wieder verwenden. Deine Scripte, Saman,muss ich mir ebenso wie das Projekt von M-Reimer in einer ruhigen Minute mal genauer anschauen, das ist viel umfangreicher als meine bisherige Umsetzung.

  • Ubuntu 18.04. - kein /etc/acpi/powerbtn.sh mehr?

    Die Powertaste der Fernbedienung veranlasst bei mir den atrci-Einschalter, die power-Kontakte auf dem Mainboard zu schließen. Ich war es gewohnt, das Runterfahren des VDRs (egal ob per FB oder Gehäuseschalter) und den vorherigen Aufruf eines acpi-wakeup-Scripts über /etc/acpi/powerbtn.sh zu steuern.


    Bei Ubuntu 18.04 finde ich in /etc/acpi aber nichts mehr, was auf den Powerschalter hindeutet. Dennoch funktioniert dieser. Wie ist das realisiert, und wie muss ein acpi-wakeup-Script nun eingebunden werden? Hat das was mit systemd zu tun?