Linux vdr4 4.12.14-lp150.12.45-default
Wenn ich micht recht entsinne, dann war das serial_ir modul im 4.12er noch etwas buggy.
Der letzte "-" müsste der trailing pulse sein oder ein Teil davon sein.
Was fehlt ist dann eigentlich nur die Lücke. Merkwürdig, dass es nicht geht.
Ein Vergleich mit dem RaspberryPi wäre aufschlussreich, wie es da auch aussieht.
Bei unterschieden auch mal die nicht graphische mode2-Ausgabe mit den Signalzeiten vergleichen, dann weiss man genau, was da am Ende fehlt.
"ptrail" könnte man testweise mal auskommentieren. Keine Ahnung das was da bringt, aber vielleicht gibt es zumindest eine andere Fehlermeldung.
VDR berücksichtigt den Wiederholcounter durchaus. [...]
Mir ist es jedenfalls nicht gelungen, es so einzustellen, dass x einzelne Tastendrücke die Funktion auch immer x mal ausführen und es trotzdem bei längerem Druck nicht zum nachlaufen kommt.
Gegen doppelte Eingaben bei einem kurzen Tastendruck haben die beiden Einstellungen auch nicht geholfen, es sei denn ich hab sie so hoch gedreht, dass die FB unerträglich langsam wurde. "suppress_repeat" in der lircd.conf hat es dann gebracht.
Wenn ich micht recht entsinne, dann war das serial_ir modul im 4.12er noch etwas buggy.
Es ist doch immer wieder schön, wenn etwas, das lange Zeit gut funktioniert hat, durch etwas neues ersetzt wird, das erstmal nicht mehr funktioniert... :-(.
Ich habe jetzt mal versucht, den neuesten Kernel zu installieren...
/etc/zypp/zypp.conf:
- multiversion.kernels = latest,latest-1,running
+ multiversion.kernels = latest,latest-1,running,oldest
zypper ar -f http://download.opensuse.org/repositories/Kernel:/HEAD/standard/ kernel-repo
zypper dist-upgrade -r kernel-repo...aber danach wird immer noch der alte Kernel gebootet.
Und in /boot ist auch nur sehr wenig von einem Kernel 5.0.0 zu sehen:
-rw-r--r-- 1 root root 65 15. Mai 2018 .vmlinuz-4.12.14-lp150.11-default.hmac
-rw-r--r-- 1 root root 65 15. Jan 20:21 .vmlinuz-4.12.14-lp150.12.45-default.hmac
-rw-r--r-- 1 root root 3458736 15. Mai 2018 System.map-4.12.14-lp150.11-default
-rw-r--r-- 1 root root 3478164 15. Jan 18:46 System.map-4.12.14-lp150.12.45-default
-rw-r--r-- 1 root root 1725 19. Dez 10:14 boot.readme
-rw-r--r-- 1 root root 196346 14. Mai 2018 config-4.12.14-lp150.11-default
-rw-r--r-- 1 root root 196269 15. Jan 17:50 config-4.12.14-lp150.12.45-default
drwxr-xr-x 3 root root 4096 1. Jan 1970 efi
drwxr-xr-x 6 root root 4096 6. Feb 11:32 grub2
lrwxrwxrwx 1 root root 34 26. Jan 14:42 initrd -> initrd-4.12.14-lp150.12.45-default
-rw------- 1 root root 12956292 6. Feb 11:24 initrd-4.12.14-lp150.11-default
-rw------- 1 root root 13268288 6. Feb 11:25 initrd-4.12.14-lp150.12.45-default
-rw-r--r-- 1 root root 1195737 4. Feb 09:58 symtypes-5.0.0-rc5-1.ga42dcc6-default.gz
-rw-r--r-- 1 root root 387429 15. Mai 2018 symvers-4.12.14-lp150.11-default.gz
-rw-r--r-- 1 root root 389041 15. Jan 19:03 symvers-4.12.14-lp150.12.45-default.gz
-rw-r--r-- 1 root root 484 15. Mai 2018 sysctl.conf-4.12.14-lp150.11-default
-rw-r--r-- 1 root root 484 15. Jan 19:03 sysctl.conf-4.12.14-lp150.12.45-default
-rw-r--r-- 1 root root 7993788 15. Mai 2018 vmlinux-4.12.14-lp150.11-default.gz
-rw-r--r-- 1 root root 8045337 15. Jan 19:26 vmlinux-4.12.14-lp150.12.45-default.gz
lrwxrwxrwx 1 root root 35 26. Jan 14:42 vmlinuz -> vmlinuz-4.12.14-lp150.12.45-default
-rw-r--r-- 1 root root 7028944 15. Mai 2018 vmlinuz-4.12.14-lp150.11-default
-rw-r--r-- 1 root root 7073904 15. Jan 20:21 vmlinuz-4.12.14-lp150.12.45-defaultMache ich etwas falsch?
Oder gibt es eine Möglichkeit, lediglich das serial_ir Modul upzudaten?
Klaus
Also, bei mir enden die Signale auch immer mit einem pulse.
Das sollte also nicht das Problem sein.
[...]
pulse 900
space 3263900
pulse 900
space 900
pulse 900
space 900
pulse 1800
space 850
pulse 900
space 1700
pulse 1800
space 1750
pulse 1800
space 1700
pulse 1850
space 1700
pulse 1800
space 850
pulse 900
space 90600
pulse 950
space 850
pulse 900
space 900
pulse 1800
space 850
pulse 900
space 1700
pulse 1800
space 1700
pulse 1850
space 1700
pulse 1800
space 1700
pulse 1800
space 900
pulse 900
space 3263900
[...]Ein kurzer Tastendruck, Code plus eine Wiederholung.
( -s kennt meine Version von mode2 nicht)
Es ist doch immer wieder schön, wenn etwas, das lange Zeit gut funktioniert hat, durch etwas neues ersetzt wird, das erstmal nicht mehr funktioniert... :-(.
Und wenn das dann endlich funktioniert, soll lirc durch rccore abgelöst werden.
Zu SuSE und den Kerneln kann ich nichts sagen, da bin ich zu lange raus.
4.12 ist aber schon länger EOL, merkwürdig, dass der noch läuft. Ich hätte da einen LTS-Kernel (4.9 oder 4.14) mit aktiven Support erwartet. Eventuell klappt da generell was mit den Updates nicht.
http://download.opensuse.org/repositories/K…ard/kernel-repo
Der link geht im Browser zumindest mal nicht.
Oder gibt es eine Möglichkeit, lediglich das serial_ir Modul upzudaten?
Früher konnte und musste man die lirc-Module per out of tree bauen.
Ob das noch immer geht, konnte ich nicht in Erfahrung bringen.
Den Kernel upzudaten wird inzwischen aber die einfachere Option sein, schätze ich.
Möglicherweise ist das, was da am Ende des von 'mode2 -s 500' dargestellten Diagramms zunächst fehlt und erst beim nächsten Tastendruck erscheint, ja dieser lange "space" zwischen den Tastendrücken.
Ja, das ist der "space".
Ich war nur nicht mehr sicher, ob der "space" erst mit dem nächsten Code kommt, oder ob er schon vorher, durch einen Timeout, kommen sollte.
Aber das Verhalten ist so korrekt.
Das würde dann aber heißen, dass der Fehler im lircd passiert,
Das ist der logische Schluss.
was aber wiederum heißen müsste, dass LIRC (zumindest in der Version, die bei openSUSE Leap 15.0 dabei ist) nirgendwo funktionieren kann - was ich mir aber eigentlich auch nicht vorstellen kann...
Eventuell betrifft es nur spezielle Fernbedienungen (mit "trailing pulse"?).
Die Erkennung geht ja bis zum "trailing pulse" korrekt.
Hast du mal versucht "ptrail" auf genau 563 zu setzen?
Wobei die geringe Abweichung eigentlich aufgefangen werden müsste.
Was ich aber auch noch immer nicht verstehe ist, dass es bei längerem Tastendruck geht.
Die FB sendet den Code ja nur einmal und dann den "repeat code". D.h. die Erkennung des Codes am Anfang muss funktioniert haben.
Hast du mal versucht "ptrail" auf genau 563 zu setzen?
Macht keinen Unterschied.
Das würde dann aber heißen, dass der Fehler im lircd passiert, was aber wiederum heißen müsste, dass LIRC (zumindest in der Version, die bei openSUSE Leap 15.0 dabei ist) nirgendwo funktionieren kann - was ich mir aber eigentlich auch nicht vorstellen kann...
Ich nutze das Original LIRC von Leap 15.0 zusammen mit einem selbstkompilierten yausbIR Modul für LIRC. Das ist zwar noch nicht im produktiven Einsatz, funktioniert aber einwandfrei. Das Problem müsste sich dann auf das serial_ir-Modul beschränken.
Hast Du mal den Quellcode des Moduls zwischen Raspi und Leap verglichen?
Oder ein anderes LIRC RPM probieren? https://software.opensuse.org/package/lirc
Mich wundert das weniger, ich würde mir nie ein Board ohne kaufen.
Diese "alten" Schnittstellen sind noch immer die einzige Möglichkeit, wenn es um Hardware nahe, direkte Ein- und Ausgabe geht. (Zumindest, wenn es sich preislich im Rahmen bleiben soll.)
Die Schnittstellen selber sind dazu in allen Multi-IO-Bausteinen drin, Mehrkosten sind also nur die Stiftleisen.
Heutzutage ist der gängigere Weg einen Mikrocontroller zwischen I/O und den USB Port zu bauen. Billig und im Zeitalter von Arduino auch nicht schwer zu erlernen.
Beim nächsten mal werde ich mir ein FLIRC-Modul kaufen, dass einfach eine Tastatur emuliert.
Dann hast du aber manchmal Nachlauf.
Er wartet anscheinend auf den "trailing pulse", aber dann kommt ihm ein Timeout dazwischen.
Timeout ist das Stichwort:
https://github.com/torvalds/linux…/rc/serial_ir.c
(3. Commit von unten)
Es ist also ein Kernel-Update angesagt.
Das erklärt dann aber auch, warum nicht alle die Probleme haben. Das wird nur bei einigen "langsamen" FBs mit langen Codes Probleme machen.
RC-5 ist beispielsweise so schnell, dass es praktisch unmöglich ist den Tasten-Code nur einmal zu senden.
Wobei laut dem Link das "serial_ir"-Modul lediglich das umbenannte "lirc_serial" ist.
Was dann bedeuten müsste, dass es auch da einige Versionen betreffen müsste, oder der Fehler erst ab der Änderung auftritt.
Leider konnte ich auf die Schnelle keine Historie zu "lirc_serial" finden, das hätte mich schon interessiert.
Heutzutage ist der gängigere Weg einen Mikrocontroller zwischen I/O und den USB Port zu bauen. Billig und im Zeitalter von Arduino auch nicht schwer zu erlernen.
Das ist bei vielen Problemen auch eine gute Lösung.
Nur liegen da zwischen Ein- und Ausgabe einige Puffer und eine Tonne Software. Zeitkritische Sachen kann man also knicken oder sie werden recht aufwändig.
Leider konnte ich auf die Schnelle keine Historie zu "lirc_serial" finden, das hätte mich schon interessiert.
Use the source, Luke:
https://github.com/torvalds/linux…c/lirc_serial.c
Das ist bei vielen Problemen auch eine gute Lösung.
Nur liegen da zwischen Ein- und Ausgabe einige Puffer und eine Tonne Software. Zeitkritische Sachen kann man also knicken oder sie werden recht aufwändig.
Zeitkritisch und PC?
Wenn man einen Echtzeit-Linuxkernel mit in die Gleichung nimmt, dann könnte man vielleicht noch ein paar Spezialanwendungen finden, aber ein Standard-Linux inklusive all der Programme die um Rechenzeit auf der CPU konkurrieren ist von "Echtzeit" meilenweit entfernt.
Bei allem was zeitkritisch ist, hat man eigentlich auch schon vor USB einen µC eingesetzt. Nur eben mit MAX232 für die RS232-Schnittstelle adaptiert. Ähnlich wie man es heute mit einem FT232RL macht um auf USB zu gehen.
Nur liegen da zwischen Ein- und Ausgabe einige Puffer und eine Tonne Software. Zeitkritische Sachen kann man also knicken oder sie werden recht aufwändig.
Sind dir Bruchteile von Millisekunden zu viel?
Ich habe damals beim Entwickeln sogar mal gebenchmarkt, wieviel Zeit zwischen dem Senden von IR und dem Empfang liegt. Die genauen Zahlen weiß ich nicht mehr, aber es war so wenig, dass ich mich dann nicht mehr drum gekümmert habe.
Im Verhältnis zur Länge eines Frames ist das vernachlässigbar.
Ja, bei IR ist das eher vernachlässigbar - wenn schon die Übertragung eines IR-Frames für einen Tastendruck im zweistelligen Millisekundenbereich liegt, kommt es auf die kleine Verzögerung von unter einer Millisekunde durch die USB-Übertragung kaum mehr an.
USB-Eingaberäte mit Tasten bekommen einen guten Teil ihres Input-Lags (und den damit verbundenen schlechten Ruf) durch die fürs Debouncing benötigte Zeit (die Hersteller stecken da vergleichsweise wenig Aufwand rein) - wenn man es darauf anlegt, geht das deutlich flotter: https://michael.stapelberg.de/posts/2018-04-…ard-controller/).
Eine RC5 FB mit serial_ir funktioniert auf meinem x86_64 System erst, wenn ich "uinput" blackliste.
Eine RC5 FB mit serial_ir funktioniert auf meinem x86_64 System erst, wenn ich "uinput" blackliste.
Lieber lircd-uinput.service deaktivieren, das Lirc-Paket für Debian ist da ziemlich übereifrig, was das aktivieren von Diensten angeht.
Vielleicht hilft das ja jemandem, das tatsächliche Problem zu erkennen.
Auch wenn ich es nicht ganz nachvollziehen kann, vermute ich, das das mit dem von mir o.ä. commit zusammenhängt.
Da muss wohl ein Fehler bei Timeout drin gewesen sein, so dass readdata() zu lange auf wartet.
Genau die Seite suchte ich verzweifelt! 
Jetzt musst du mit nur verraten, wie man da hin kommt.
Die haben das gesamte Timing in dem Modul umgestellt, da wird sich wohl der Fehler mit eingeschlichen haben.
Zu den Schnittstellen nur noch so viel:
Primär verwende ich die noch für diese Bitbang-Programmierkabel und ähnliche Geschichten. Mit denen kann man viel machen für kleines Geld.
Wenn es über USB gehen soll wird es deutlich teurer und/oder aufwändiger.
Don’t have an account yet? Register yourself now and be a part of our community!
