Vorschlag zu lirc.c

Sollte ein automatisches Erkennen der Wiederholrate nicht beim Anlernen der FB stattfinden?

Quote from jrie

Steht im MANUAL.

Das habe ich natürlich gelesen.
Die Sache ist nur, das sich die FB anders verhält, als ich es danach erwarte.

Meine Interpretation vom Manual:
Mit RcRepeatDelta kann man die Wiederholrate der FB verringern.
Mit RcRepeatDelay kann man die Pause, bis die Wiederholungen einsetzen, verlängern.
Soweit korrekt?

Bei softhddevice und beim Keyboard hingegen wird RcRepeatDelta anscheinend für die Erkennung, ob es sich um ein "repeat" handelt verwendet (ist Zustand).
Das passt für mich nicht wirklich zusammen.
Ich denke man sollte als erstes mal klären, was man mit diesen Werten einstellen können soll.
Dann ggf. das Manual entsprechend anpassen.
Bei dieser erweiterten Auslegung müsste man sich eigentlich die zusätzliche RcRepeatTimeout sparen können.

Da ich eine Verlangsamung meiner FB nicht will, hatte ich beide Werte auf 0 gestellt. Das war auch ein Tipp hier aus dem Forum, wenn ich das recht erinnere.
Das führte zu starkem Nachlaufen, wenn ich eine Taste länger gedrückt halte.
Das Nachlaufen ist einigermaßen o.k., wenn ich RcRepeatDelta auf 110ms einstelle.
Wenn ich RcRepeatDelta auf 120ms einstelle sind die Wiederholungen nur etwa halb so schnell.

Jetzt schreibst Du hier aber, man soll die RcRepeatDelta knapp oberhalb der Wiederholrate der FB einstellen.
Ich würde, nach meinen Erfahrungen, RcRepeatDelta immer knapp darunter einstellen, das verwirrt mich etwas.

Dann wirkt RcRepeatDelta und RcRepeatDelay hier auch bei mehrmaligen drücken der gleichen Taste.
Ich finde das eher ungünstig. (Besonders, wenn man bei RcRepeatDelay versehentlich 10000, statt 1000 einstellt .)
Du hast das in deinem Patch auch raus genommen, wenn ich richtig sehen.
Was ich inzwischen anhand des Quellcodes nachvollziehen konnte ist, dass es bei RcRepeatDelta wohl Absicht ist, bei RcRepeatDelay aber nicht (ist Zustand).

Bis auf das Nachlaufen und dass RcRepeatDelay auch auf schnelle Tastendrücke wirkt, scheint mein System aber zumindest so zu reagieren, wie ich es laut Quellcode erwarten würde (ist Zustand).
In meinem LIRC-Setup muss also noch irgendwo ein anderer Fehler sein, den muss ich wohl als erstes beseitigen. Solange da noch was anderes faul ist, macht es auch keinen Sinn irgendwas neues zu testen.
Die Patches habe ich mir demzufolge erstmal nur angesehen.

Kann es sein, dass da in Zeile 145/156 was fehlt?
Bei dem Kommentar davor, hätte ich darin noch die Variable timeout erwartet.
So in der Art etwa ???
if (count == 0 && Setup.RcTogglingProtocol || (strcmp(KeyName, LastKeyName) != 0 && Delta > timeout)) { // new key pressed
Eigentlich kann man den Block mit strcmp immer drin lassen, das sollte normalerweise ja nie auftreten.
Und wenn es auftritt, könnte man das evtl. auch gleich zur Erkennung einer problematischen FB/LIRC-Version verwenden?
Den umgekehrten Fall (count unberechtigt 0) zu detektieren ist leider deutlich schwieriger.

Ich bin auch nicht sicher, ob RcTogglingProtocol ein guter Name ist.
Irgendwas wie RcBugFix oder so wäre u.U. besser und universeller einsetzbar. (In Anlehnung an EPGBugFix)
Default sollte es besser abgeschaltet sein, denke ich, dann sollte sich das Verhalten zum Aktuellen nicht ändern, wenn ich das richtig sehe.

Im Anhang noch noch ein kleiner Patch, der verhindern soll, dass man (wie ich ) seinen VDR mit einer Fehleingabe von RcRepeatDel*** unbedienbar macht. (bislang ungetestet)

Quote from SHF

Meine Interpretation vom Manual:
Mit RcRepeatDelta kann man die Wiederholrate der FB verringern.
Mit RcRepeatDelay kann man die Pause, bis die Wiederholungen einsetzen, verlängern.

Nur zur Klarheit: Die Wiederholrate und Pause, bis die Wiederholungen einsetzen der FB sind durch die FB vorgegeben. RcRepeatDelta und RcRepeatDelay beeinflussen diese nicht, sie dienen dazu, zu erkennen, ob es sich um Wiederholungen oder neue Tastendrücke handelt.

jrie Ich hab mir das im Detail noch nicht näher angeschaut, steht aber auf meiner TODO-Liste (wenn auch relativ weit unten).

Von mir gab es bislang noch kein Feedback, da ich mich noch nicht wirklich zu dem eigentlichen Thema durchgearbeitet habe.
Die Nachfrage nehme ich trotzdem mal als Anlass für einen Zwischenbericht.

Da sich mein System zuletzt wie in Beitrag #15 erwähnt verhielt, allerdings bei korrekt toggelnder FB (!), war ich damals auch nicht sicher, ob ich da nicht doch von dem Problem betroffen bin. Meine erwähnten Beobachtungen sollten das nur veranschaulichen, dabei war ich wohl etwas zu ausführlich...

Inzwischen konnte ich die Fehler aber finden und beseitigen.
Neben einem kleinen Fehler, der bei mir lag, hatte die lirc.c (Stand VDR 2.7.7) auch noch mehrere Fehler drin, was in Kombination zu diesem Verhalten geführt hat:

• In Zeile 145 steht Setup.RcRepeatDelay statt Setup.RcRepeatDelta. (Das hat bei mir das Chaos perfekt gemacht und war wohl auch der Grund, warum ich die beiden Werte dauernd durcheinander gebracht haben. )
  if (strcmp(KeyName, LastKeyName) == 0 && FirstTime.Elapsed() < (uint)Setup.RcRepeatDelay)
  So macht das für mich logisch jedenfalls keinen Sinn, mit der Voreinstellung "300" bei "Setup.RcRepeatDelay" werden dadurch ständig Tastendrücke verschluckt. Wenn müsste man da "Setup.RcRepeatDelta" verwenden. (Erstaunlich, dass das noch keiner gemerkt hat.)
• Ich würde diese Zeile aber ganz raus nehmen (daher korrigiert und auskommentiert), da es sich da nicht um Wiederholungen, sondern absichtliche Tastendrücke handelt.
  (Da sollte man sich mal überlegen, wie man das generell handhaben will. Momentan scheint das nicht wirklich konsistent gemacht zu sein.)
• Dann erscheint mir die Variable "pressed" unnötig.
  Bei der ersten Abfrage ist es immer "true" und bei der Zweiten auch, sofern "repeat" true ist.
  Nach etwas Optimierung der if-Abfragen, ist die Struktur mit der von cLircDevRemote auf einmal nahezu identisch.
  Da die Schnittstellen sehr ähnlich sind, von dem was sie einem liefern, ist das ein gutes Zeichen, denke ich.
• Den timeout habe ich fest eingestellt, so dass er für alle bekannten Fernbedienungen passen sollte. Das spart einem das Timer-Objekt. (Der war wohl sowieso problematisch und wurde schon mal verlängert.)
  Ein paar ms mehr merkt man da sowieso nicht und der gewählte Wert ist sogar noch etwas kürzer als der bislang automatisch ermittelte.
  (Selbst 250ms wären noch o.k., da merkt man es aber manchmal. Kritisch ist eher, wenn der timeout zu kurz ist, dann gibt es sofort fieses Nachlaufen.)

Mit diesen Änderungen scheint der VDR jetzt endlich korrekt zu reagieren, wenn der Input vom LIRCd in Ordnung ist.
Das habe ich jetzt so seit ein paar Wochen laufen und bin recht zufrieden damit.
Patch im Anhang.

Danke euch für die Erklärungen zum Thema RcRepeatDelay und RcRepeatDelta! (Das ASCII-Art von jrie ist ja schon fast Kunst. Das wäre auch was fürs Manual.)
Ich habe mich zu dem Thema inzwischen auch noch etwas unmgesehen:

Das, was im Manual steht, entspricht etwa jrie s Auslegung.
kls hat aber auch Recht, beim Keyboard und einigen Plugins wird RcRepeatDelta zusätzlich auch zur Repeat-Erkennung benutzt. z.B.:
if (Poller.Poll(Setup.RcRepeatDelta * 3 / 2)) {
Bei LIRC aber nicht, da wird (ist Zustand) ausschließlich dem Counter von LIRC vertraut:
if (count == 0) { // new key pressed

Irgendwie scheint RcRepeatDelta * 1,5 so der Standard für die Erkennung, ob es ein repeat ist, zu sein. Wirklich gut ist die Wahl IMHO aber nicht:
Bei einem RcRepeatDelta von zB 200 würde alles unter 300ms als Wiederholung erkannt und ggf. verworfen. Wirklich bedienen kann ich den VDR damit nicht mehr. Der Einstellmöglichkeit mit RcRepeatDelta ist aktuell also ziemlich eingeschränkt.
Eigentlich kann man es momentan nur dazu benutzen die Wiederholreate von Keyboard (s.u.) und FB anzugleichen.
Ich denke es macht Sinn, RcRepeatDelta und die Repeat-Erkennunggs-Schwelle irgendwie zu entkoppeln.

Dann habe ich auch einige Timing-Tests gemacht (Abfallprodukt der Fehlersuche) und ab und zu gibt es auch Ausreisser nach unten:

Delta: 102
Delta: 104
Delta: 110
Delta: 108
Delta: 106
Delta: 107
Delta: 100
Delta: 106
Delta: 110

(Geloggt wurden Delta-Werte von 110ms oder weniger, meine FB liefert normalerweise 113 oder 114ms.)
Werte unter 100ms gibt es zwar praktisch nie, das Minimum was ich bislang hatte war aber 89ms.
Die Ausreisser sind auch recht selten, einer so alle 2-3 Tage und meist wenn dass System unter Last ist (zB. Aufnahmen + Videokodierung).
Aber ignorieren kann man das nicht. Die Wiederholratenerkennung, so wie sie derzeit vorgesehen, dürfte in dem Fall Problem bekommen.
Ich denke ich hätte da sogar was aus einem anderen Projekt, was man hierfür recyclen könnte, aber das Ganze wird dann schon ziemlich aufwändig ....

Nachfolgend noch ein paar Sachen, die mir nebenbei aufgefallen sind, die ich mir aber bislang noch nicht näher ansehen konnte.
Ich stelle mal einfach meine Notizen als Diskussionsgrundlage hier rein:

Wie man Kernel-LIRC aktiviert scheint nur im HISTORY "dokumentiert" zu sein. Sonst habe ich jedenfalls nichts gesehen.
Es wäre nicht verkehrt, zumindest mal den Absatz aus den HISTORY in den Manpage zu kopieren.

Die Faktoren bei den Timing-Werten halte ich für ungünstig, da die Auflösung und der Jitter durch den Scheduler (nahezu) konstant sind.
Die Schwelle +-3% sind bei einer Wiederholrate von 100ms +-3ms, das ist knapp kalkuliert, aber möglich.
Bei einer Wiederholrate vom 40ms (die sollten wir doch auch unerstützen?) sind das nur noch 1,2ms, also angerundet +-1ms. Ich bezweifele, dass das funktionieren wird, das ist schon im Bereich das Rauschens.
Ich mache das eigentlich immer mit Schwellenwert +- Jitter-Zuschlag, das ist robuster.

Den Begriff Repeat_timeout finde ich irgendwie ungünstig gewählt (den Parameter einzuführen macht aber Sinn). Spontan dachte ich da zunächst an einen Timeout, der die Tastenwiederholungen beendet. In remote.c gibt es schon einen REPEATTIMEOUT der (vermutlich) diese Funktion hat.
Repeat_Threshold (Schwellenwert für Tastenwiederholung) wäre mein Vorschlag.

Wenn man den REPEATTIMEOUT als "Wiederholrate der Fernbedienung" definiert, könnte man auch den Jitter-Zuschlag individuell je nach Eingangs-Schnittstelle dazu geben.
Bei cLircUsrRemote und cKbdRemote also zB. 5ms und beim Softhddevice-Plugin zB. 25ms (also die nötigen ~20ms mehr gleich dazu).
Die Idee dahinter: Der User stellt dann einfach das ein, was seine FB haben soll (oder halt auf Auto) und es geht überall best möglich. Aber über den Ansatz kann man streiten...

cKbdRemote ist vom Aufbau ganz anders als lirc* und das remote-plugin.
Ein Keyboard hat aber eine deutlich schnellere Wiederholrate als eine FB. (16/s war das Minimum, was hier gefunden habe.) Viel schneller, als ein Mensch eine Taste kontrolliert(!) drücken kann.
Wenn man es wirklich nur mit einem Keyboard zu tun hat, könnte man also die Repeat-Erkennung ganz anders angehen.
Dann haben Keyboards typischer Weise selber ein deutliches RepeatDelay (in wieweit das hier ankommt bin ich aber derzeit nicht sicher).

cKbdRemote liest von stdin, kommt da überhaut was anderes als ein Keyboard an?
Man könnte dahin natürlich irgendwie auch eine FB umleiten, aber macht das wer?
Wenn man schon Sachen nach stdin umleitet hätte man es u.U. auch mit mehreren unterscheidlichen Eingabegeräten gleichzeitig zu tun, die man nicht wirklich auseinanderhalten kann. Eine sinnvolle Widerholratenerkennung wird dann schwierig.
Die Sache ist wohl komplizierter, als es auf den ersten Blick erscheint.

Mit dem Hintergrund könnte der unterschiedliche Aufbau von cKbdRemote durchaus Sinn machen und man sollte es vielleicht besser so lassen, wie es ist (bis auf den Repeat-Schwellenwert)?
Zumindest kann ich im Moment noch nicht überblicken, ob die vorgeschlagene Änderung Vorteile bringen würde, oder nicht. Gleiches gilt für mögliche Nebenwirkungen.

jrie Bitte habt noch etwas Geduld, ich bin momentan an einer anderen (VDR-)Baustelle dran ;-). Ich schau mir das an, so bald ich dazu komme. Allerdings schwebt mir immer noch eine Lösung vor, bei der der Benutzer eine Taste gedrückt hält und das Programm die relevanten Parameter selber durch Messung ermittelt.