Vorschlag zu lirc.c

Quote from kls

Bitte habt noch etwas Geduld

Von mir aus kannst Du dir gerne Zeit lassen, "mein" Fehler ist gefunden, verstanden und behoben .

Quote from kls

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.

Aktuell geht es erstmal "nur noch" um eine Optimierung/Fehlerbehebung der bestehenden cLircUsrRemote.
Eine Änderung bei den Einstellwerten und cKbdRemote ist also derzeit von meiner Seite nicht geplant.

Den Fehler bei der Auswertung mancher FB-Signale seitens des LIRCd werde ich(/wir?) erst mal versuchen schon an der Quelle (LIRCd) zu beseitigen.

Nach längerem überlegen und probieren bin ich inzwischen zu dem Schuss gekommen, dass eine einmalige automatische Erkennung nicht wirklich funktionieren wird, bzw. der Aufwand nicht lohnt:

"Setup.RcRepeatDelay" und "Setup.RcRepeatDelta" sind Einstellwerte, mit denen der User das Verhalten der FB/KB beeinflussen kann. Diese Werte kommen nicht vom Eingabegerät und können gar nicht ermittelt werden.
Da sind sich jrie, MANUAL und Quellcode einig und der Meinung schließe ich mich inzwischen auch an .
Da irgendwas am Verhalten zu ändern macht für mich keinen Sinn. Auch die Default-Werte sind auch sinnvoll gewählt.

Den Schwellenwert für die Repeaterkennung könnte man ermitteln. Wirklich Sinn macht das für mich aber auch nicht:

• Die Fernbedienungen kommen praktisch alle über user/kernel-LIRC rein (zum Teil über Umwege), da wird der Werte gar nicht verwendet.
• Wenn man eine wirkliche Optimierung anstrebt, müsste man das für jedes Eingabegerät einzeln machen, da die Werte je Fernbedienung/Eingabegerät unterschiedlich sind. Das wird ein riesen Aufriss und der Nutzen ist fraglich.
• Wenn man nur einem VDR-weiten Wert ermittelt, führt das bei mehreren Eingabegeräten zwangsläufig zu einen Kompromiss.
  Dann wird es nicht lange dauern, bis man doch eine Einstellmöglichkeit einbaut, weil irgendwer eine Kombination hat, bei der es nicht wie gewünscht funktioniert.
  Dann kann man das auch gleich machen....

Der sinnvolle Wertebereich ist recht begrenzt: 80...160ms

Der genaue Wert ist auch nicht besonders kritisch, es gibt eigentlich nur 3 wichtige Schwellen:

• 150ms: Aktuell impliziter default beim Keyboard.
  Failsave, sollte immer funktionieren.
  Evtl. werden sehr schnelle Tastenwiederholungen fälschlich als repeat erkannt.
• 120ms:
  Ideal für fast alle IR-Fernbedienung, außer Sky-Protokoll (->150ms).
  Risiko der Falscherkennung von schnellen Tastenwiederholungen minimal.
• 90ms:
  Ideal für Keyboard und einige, wenige Fernbedienungen (die aller meisten FB gehen damit nicht ->120ms)
  Falscherkennung schneller Tastenwiederholungen praktisch ausgeschlossen.

Das, mit einem default von 150ms, müsste irgendwie nutzerfreundlich einstellbar zu machen sein.
Irgendwas wie: optimieren für: Standard, Ferbedienung, Keyboard, Automatisch, Manuelle Eingabe.
Wer will kann dann was einstellen, sonst lässt man es halt bei default, der dem Aktuellen entspricht (und über den sich bis jetzt ja noch keiner beschwert ).
Das auszuarbeiten, dazu bin ich aber noch nicht gekommen.

Auch sollte mit dem Hintergrund spätestens nach der 3. Wiederholung feststehen, ob es ein repeat ist:

• Abstand größer 150ms -> kein repeat (keine Hardware ist so langsam)
• Abstand kleiner 90ms -> repeat (kein Mensch ist so schnell)
• Im Bereich dazwischen:
  3 oder mehr Wiederholungen im gleichen Abstand (ca. +-3ms) -> ziemlich sicher ein repeat (kein Mensch ist so genau)
  Je mehr Wiederholungen und je genauer der Abstand, desto sicherer ist man.

Bei einem Keyboard wüsste man also schon bei der der ersten Wiederholung sicher, dass es ein repeat ist, da die Wiederholrate deutlich unter 90ms liegt.

Wie man das jetzt am besten umsetzt, zB. ob man den Wert temporär zwischenspeichert, habe ich mir noch nicht überlegt. Meine Priorität liegt derzeit noch bei LIRC und da braucht man das nicht.

Quote from jrie

Wenn man will, kann man auch noch in Zeile 134 ret > 0 weglassen

Bist Du sicher, dass safe_read() hier nie 0 (EOF) liefern kann?
Mir war das zu heikel.

Quote from jrie

Wenn du allerdings „pressed“ weg lässt, produzierst du ziemlich viele Releases

Wenn das so ist, fällt das zumindest nicht unangenehm auf .
Ich habe den Patch jetzt seit etwa 3 Wochen drin und die FB läuft besser denn je .

Ich müsste es mir sicherheitshalber nochmal ansehen, aber ging bislang davon aus, dass das if (repeat) das auch schon ausreichend abfängt. Bei cLircDevRemote wird das ja auch so gemacht.

Quote from jrie

Die mit Abstand höchste Repeatrate hat Sky mit 150 ms. Wie viel man da noch drauf legt, ist Geschmackssache.

Mein Wert ist eher konservativ gewählt, aber nicht extrem groß..
Da hätte es bei mir in den 3 Wochen nur eine einzige Fehlerkennung bei einer Sky-Remote gegeben.
Man könnte aber auch auf 180ms gehen, wie aktuell bei mir automatisch bestimmt.

Bei einer Sky-Remote würde aktuell aber ein Wert von ~225ms errechnet werden, das ist für meinen Geschmack unnötig hoch.

Quote from jrie

In Zeile 120 steigt er bei f < 0 || ready && ret <= 0 mit break aus...

Das break wirkt nur auf die innere Schleife in dem Block (Zeile 125).
Wenn ich in Zeile 120 mit ready == true und ret <= 0 rein komme, komme ich doch genau so wieder aus dem Block raus. Die Werte werden in dem Block gar nicht verwendet.

Aber Du hast schon Recht, da sieht irgendwas komisch aus.
Ehrlich gesagt, hatte ich mir den Block bislang noch nicht so genau angesehen, da ich die darin enthaltenen Log-Meldungen nicht hatte.

Mit einem else if (ready) (Z. 135) sollte es aber gehen.
Alternativ könnte auch am Ende von dem Block ein continue setzen (nach Z. 131).
Ich denke das mach eh Sinn, nach dem Reconnect vor dem Auswerten, immer erstmal neue Daten zu laden .

Man könnte Zeile auch noch 120 umsortieren:
if (f < 0 || ret <= 0 && ready) {
Da ret <= 0 praktisch nie auftritt, müsste das effizienter sein, da dann das ready gar nicht erst ausgewertet wird.

Dann habe ich mir die Sache mit pressed nochmal angesehen:
repeat wird nie true, wenn pressed false ist. (Zumindest sehe ich keine Möglichkeit wie das passieren könnte.) Auch mit Patch lirc.c.4.diff.txt nicht.
pressed ist also wirklich unnötig.

Dann setze ich den Timeout auch immer auf -1 (unendlich), außer es handelt sich um ein repeat.
Das spart einem Menge CPU und man kommt an das else (Z. 160) eigentlich nur, wenn auch ein release nötig ist (und evtl im Fehlerfall).
Das if (repeat) verhindert eigentlich nur im Fehlerfall den unnötigen release.

Von mir aus bin ich dann eigentlich auch erstmal mit der lirc.c fertig, der endgültige Test steht zwar noch aus, das mache ich aber bei Gelegenheit noch.
Dann baue ich auch noch mal eine Debug-Meldung ein, wegen des pressed, dass wir ganz sicher sind.

Quote from jrie

Dann ist das Interval erst 120 und dann 108, und das bringt die Wiederholraten Erkennung dann aus dem Tritt.

Das ist typisch, dass der erste zu lang ist, der nächste dann zu kurz.
Damit kann man aber arbeiten, da die Summe der 2 dann wieder stimmt.
Außerdem passiert das sehr selten, 99.9% sind ja o.k..
Man muss also nur aufpassen, dass einem so ein Ausreißer keine Probleme macht und die entsprechend raus filtern.

Quote from jrie

Deswegen gehört die Wiederholraten Erkennung auf einen Mikrocontroller, der nur das macht und sonst nichts und daher nie Hänger hat.

Oder man macht es wie bei LIRC und arbeitet mit Timestamps, die vom Empfänger kommen.
Dann ist es egal, ob bei der Auswertung Verzögerungen gibt.

Quote from jrie

Ein konstantes Timeout ist nur eine Notlösung. Bei einem Protokoll mit 25 ms Wiederholrate ist 165 ms einfach zu groß.

Wenn man den Timeout nur für den release verwendet sind 165 ms einwandfrei.
Ich würde den Timeout fürs release und die Wiederholraten Erkennung auch getrennt halten, sonst wird das zu unübersichtlich.

Die Ändernung an den "tools" Funktionen um so niedrige Timeouts zu ermöglichen, gefallen mir auch gar nicht. Wer weiß bei welchem Plugin das zu Fehlern führt...
Zumal ein Timeout unter 100ms komplett unnötig ist, da alles darunter repeats seinen müssen.

Wer das nicht glaubt, kann es selber probieren (für Schäden am Keyboard übernehme ich aber keine Haftung )
time (typeset -i i=0; while((i<10)); do read; i=i+1; done)
Einfach 11 mal so schnell wie möglich Return drücken. Den user Wert muss man dann noch durch 10 teilen.
Ich habe da viel probiert und mein Minimum waren 1,3 Sekunden, bzw. 130ms.
100ms, keine Chance, nicht mal Lucky Luke würde das mit meinem Keyboard schaffen .

120ms halte ich inzwischen übrigens für weitgehend ideal (Ausnahme SKY-FB).
Das lässt sich auch recht einfach ausprobieren: RcRepeatDelta auf 80ms einstellen, das sollte einen timeout von 120ms beim Keyboard ergeben.
Wenn Das Keyboard dann immer noch nicht so geschmeidig reagiert wie es das soll, muss man sich das halt auch mal ansehen.
Das habe ich mir noch nicht gemacht und ist bei mir auch eher von niedriger Priorität, da ich das Keyboard nur sporadisch benutze.

Die Wiederholrate des Keyboards bekommt man übrigens mit:
read; time (typeset -i i=0; while((i<10)); do read; i=i+1; done)
Return gedrückt halten, bis das Ergebnis erscheint. Den user Wert muss man auch hier wieder durch 10 teilen.

Quote from jrie

Der Nutzen besteht in einem genauen Timeout, der hilft Wiederholungen von Neuen zu unterscheiden, so dass Neue nicht fälschlich als Wiederholungen ausgefiltert werden.

Der Vorschlag war doch das einmalig beim Anlernen(?) zu messen.
Ich denke nicht, dass das sinnvoll funktionieren wird und eher Probleme macht, als es löst.
Was macht man zB. bei mehreren Fernbedienungen im System? Ich habe eine IR-FB an LIRC und 2x Keyboard, Konsole und Xieliboutput.
Wenn beim Anlernen was schief geht, hat man auch ein Problem.

Dann doch lieber eine einstellbare Variable mit sinnvollem Default-Wert.
Die Variable braucht es ja eh, wenn man es einmalig anlernt.

Außerdem ist das Anlernen der Wiederholrate unnötig, sobald eine Taste 4-5 Wiederholungen liefert, weiß man die nahezu sicher.
Das bedeutet, man hat den Wert sicher, sobald jemand eine Taste länger als 0,5s drückt. So lange kommt man auch mit einem sinnvollen Default-Wert aus. Und nach einem Neustart ließe sich die Zeit sicher auch noch verkürzen.

Das also problemlos machbar. Ich will da momentan nur keine Zeit rein stecken, bevor ich weiß, dass das wirklich benutzt wird. Dazu ist meine Zeit derzeit einfach zu knapp .

Quote from jrie

Ob das Problem auch für andere Empfänger im VDR gelöst wird, liegt ganz bei kls.

Gibt es denn überhaupt noch andere problematische Empfänger als den LIRCd?
Bei dem konnte ich es ja bestätigen.

Beim LIRCd gehen nach meinen Tests, die Daten mit korrektem timing rein und auch wieder raus. Nur die Repeat-Erkennung ist falsch.

Wenn man diese Fehl-Erkennungen in Nachhinein noch beheben kann, dann ist das für mich eindeutig ein Bug im LIRCd und der sollte am besten auch dort behoben werden.
Erst wenn das nicht geht, oder gewollt ist, sollte man im VDR einen Workaround einbauen.

Der Lircd wäre auch eindeutig die bessere Stelle, da man da wirklich alle Informationen zur Verfügung hat.
Timing-Informationen zur jeweiligen FB, Zeitstempel vom Empfänger, fehlerhafte Datenpakete im korrekten Zeitraster usw., das kommt ja alles im VDR nicht mehr an.
Und da lirc mit Zeitstempeln arbeitet, sollte ganze auch unter einem Multitasking-Sytem sauber und ohne Klimmzüge funktionieren.

Ich werde mich jedenfalls erstmal mit dem LIRCd beschäftigen und versuchen da den Fehler zu finden.

Mein Stand beim LIRCd:
Eigentlich ist bei den Daten ja nur der Zähler falsch. Der wird teilweise zurückgesetzt, wenn er inkrementiert werden sollte (kann ich bestätigen), bzw. anders herum (konnte ich noch nicht bestätigen).
Daher habe ich mal gezielt nach diesem Zähler gesucht, der meist mit reps bezeichnet wird.

Der Zähler (reps) wird get_release_data() in release.c zurückgesetzt, wenn release_remote == NULL ist oder durchgereicht. Das release_remote kommt über register_button_press() aus ir-remote.c, da kommt auch reps Wert her. Im Endeffekt kommt der Zähler (reps) also wohl irgendwo aus ir-remote.c.
Das blöde ist, dass es da einen Haufen Stellen gibt, wo was schief laufen kann.
Dazu sollten wir aber vielleicht besser ein eigenes Thema aufmachen...

Quote from jrie

Das bezweifle ich, denn ganz genau wie du bei Last falsche Timings hattest, werden vermutlich auch die Zeitstempel von lirc betroffen sein. Habe ich aber nicht überprüft.

Das kann logisch eigentlich nicht sein:

1. Wenn das Timing wirklich daneben ist, würde zuerst der Code nicht erkannt werden.
   Da get es um +- 100us, muss also mindestens um den Faktor 10 genauer sein.
2. Wenn das Timing beim lirc.d daneben ist, kämen die Tasten auch entsprechen verzögert beim VDR an.
   Dein Patch RC2.diff.txt würde in dem Fall dann auch nicht funktionieren.

Quote from jrie

Die Empfänger geben aber keine Timestamps aus.

Vielleicht ist der Begriff "Timestamp" hier nicht ganz korrekt, aber das was auf /dev/lirc0 übergeben wird enthält die Timing-Informationen vom Empfänger: MODE2

Und diese Timing-Informationen müssen korrekt sein, sonst würde die Taste nicht erkannt werden. Zumal das Timing bei den einzelnen Bits noch viel kritischer ist.

Eine subtile Ausnahme gibt es aber:
Mode2 hat typischer Weise einen Timeout von 2 Sekunden. Solange kann man nicht warten, bis eine Taste ausgewertet wird.
Daher wird release.c ein Timer auf kurz nach dem erwarteten Eintreffen des nächsten repeat gesetzt. (Zeile 74-79). Da wird zwar ein Puffer von 10ms drauf addiert, der eigentlich reichen sollte, aber evtl. reicht das doch nicht.

Wer will kann ja mal versuche, was passiert, wenn man den Timeout etwas anhebt. Ich komme da dieses Jahr wohl nicht mehr dazu.

diff -ru ../lirc-git-eec331ada5eb32afb68901495a47df236d712dc1/lib/release.c ./lib/release.c
--- ../lirc-git-eec331ada5eb32afb68901495a47df236d712dc1/lib/release.c    2025-08-26 14:45:22.000000000 +0200
+++ ./lib/release.c    2025-12-06 22:47:13.272730023 +0100
@@ -76,7 +76,7 @@
                    - remote->min_gap_length)
              + receive_timeout(upper_limit(remote,
                            remote->min_gap_length))
-              + 10000;
+              + 25000;
    log_trace("release_gap: %lu", release_gap);
    register_input();
}

Quote from jrie

Nein, denn bei der nächsten Schleife wird ja timeout auf -1 gesetzt.

Stimmt, das hatte ich in dem Moment wohl übersehen.
Immerhin spart es eine unnötige Schleife .

Quote from jrie

Dann hast du noch nicht probiert, zwei Tasten beinahe gleichzeitig zu drücken (mit zwei Fingern).
Das ist mir mal eher aus Versehen passiert, und ich habe mich dann gewundert, dass ich so schnell war.

Nein, das hatte ich natürlich noch nicht versucht .

Aber das wäre dann auch kein repeat, da es unterschiedliche Tasten sind.
Das dürfte also keine Probleme machen.

Quote from jrie

Das wäre dann mein Patch ohne automatische Wiederholraten Erkennung mit zwei zusätzlichen Setup Parametern.

Ich dachte erstmal nur daran dieses komische RcRepeatDelta * 3 / 2 zu ersetzen.

Das folgende ist nur Illustration was ich meine gedacht:

#define RcRepeatTresholdAuto 99
#define RcRepeatTresholdAutoVal 120
#define RcRepeatTreshold_Failsave 201
#define RcRepeatTreshold_FailsaveVal 150

Add(new cMenuEditIntItem( tr("Setup.Miscellaneous$Remote control repeat treshold (ms)"), &data.RcRepeatTreshold, RcRepeatTresholdAuto, RcRepeatTreshold_Failsave, tr("Setup.Miscellaneous$auto / optimal") tr("Setup.Miscellaneous$fail save")));

In der Anwendung dann etwa so:

#define JitterMargin 10 // zB. 10ms Keyboard, 30 ms Softhddevice

timeout = (Setup.RcRepeatTreshold == RcRepeatTresholdAuto ? RcRepeatTresholdAutoVal : (Setup.RcRepeatTreshold == RcRepeatTreshold_Failsave ?  RcRepeatTreshold_FailsaveVal : Setup.RcRepeatTreshold) + JitterMargin ;

Vielleicht etwas sperrig, aber so hätte man aber immer einen "auto"- und einen "Failsave"-Mode. Den "Failsave"-Mode könnte man sich aber auch sparen, das würde die Sache übersichtlicher machen.
Auf Eingabegeräten, die das wirklich unterstützen, sollte man natürlich den echten "auto"-Mode verwenden und nicht den Wert.
Default sollte "auto" sein.

Wie ich das in lirc.c mit der Fehlerbehebung angehen würde, ist etwa wie folgt:

--- lirc.c.shf.v2    2025-12-05 23:41:44.732223113 +0100
+++ lirc.c    2025-12-05 23:41:51.276280499 +0100
@@ -110,6 +110,10 @@
  char LastKeyName[LIRC_KEY_BUF] = "";
  bool repeat = false;
  int timeout = -1;
+  int RepeatRate = -1;
+  char LastRemoteName[LIRC_KEY_BUF] = "";
+  int RepeatCnt = 0;
+  int RepeatRateTmp = 0;

  while (Running()) {

@@ -134,11 +138,44 @@
           buf[ret - 1] = 0;
           int count;
           char KeyName[LIRC_KEY_BUF];
-           if (sscanf(buf, "%*x %x %29s", &count, KeyName) != 2) { // '29' in '%29s' is LIRC_KEY_BUF-1!
+           char RemoteName[LIRC_KEY_BUF];
+           if (sscanf(buf, "%*x %x %s %29s", &count, KeyName, RemoteName) != 3) { // '29' in '%29s' is LIRC_KEY_BUF-1!
              esyslog("ERROR: unparsable lirc command: %s", buf);
              continue;
              }
+
+           if (Setup.RcBugFix > 0) {
+              int Delta = ThisTime.Elapsed(); // the time between two subsequent LIRC events
+              ThisTime.Set()
+              if (strcmp(LastRemoteName, RemoteName)) { // new remote, reset RepeatRate
+                 RepeatRate = -1;
+                 RepeatCnt = 0;
+                 RepeatRateTmp = 0;
+                 esyslog("[lirc] new remote: %s\n", RemoteName);
+                 sprintf(LastRemoteName, "%s", RemoteName);
+                 }
+              if (abs(RepeatRateTmp - Delta) < 2 && Delta < LIRC_REPEAT_TIMEOUT - 10) { // prevent timeout been detected as repeat
+# define MIN_FACTOR 10
+                 RepeatRateTmp = (Delta * (MIN_FACTOR - RepeatCnt) + RepeatRateTmp * (RepeatCnt - MIN_FACTOR)) / MIN_FACTOR;
+                 if (RepeatCnt > 6 || RepeatRate < 0 && RepeatCnt > 2)
+                    RepeatRate = RepeatRateTmp < 110 ? 110 : RepeatRateTmp;
+                 if (RepeatCnt < MIN_FACTOR - 1)
+                    RepeatCnt++;
+                 }
+              else {
+                 RepeatCnt = 0;
+                 RepeatRateTmp = 0;
+                 }
+              }
+           else
+               RepeatRate = -1;
+
           if (count == 0) { // new key pressed
+              if (RepeatRate > 0 && Delta < RepeatRate + 5 && strcmp(KeyName, LastKeyName) != 0) {
+                 // TODO debug log
+                 goto is_repeat;
+              }
+:no_repeat
              if (repeat)
                 Put(LastKeyName, false, true); // generated release for previous repeated key
              strn0cpy(LastKeyName, KeyName, sizeof(LastKeyName));
@@ -147,6 +184,11 @@
              timeout = -1;
              }
           else { // repeat of a continuously pressed key
+              if (RepeatRate > 0 && (Delta > RepeatRate + 10 || strcmp(KeyName, LastKeyName) != 0)) { // TODO check if really needed, I never had this case.
+                 // TODO debug log
+                 goto no_repeat;
+              }
+:is_repeat
              if (FirstTime.Elapsed() < (uint)Setup.RcRepeatDelay)
                 continue; // repeat function kicks in after a short delay
              if (LastTime.Elapsed() < (uint)Setup.RcRepeatDelta)

Auch das ist erstmal nur zur Veranschaulichung schnell runter geschrieben, bzw. zusammen kopiert und völlig ungetestet!
Das wird auf Anhieb vermutlich nicht laufen Bzw. ist da sicher noch einiges zu optimieren, auch was den Stil angeht.
Eigentlich wollte ich mir die Arbeit auch nur machen, wenn sich das im lirc.d wirklich nicht lösen lässt, aber ehe wir ewig an einander vorbei reden...
Man sieht so aber auch ganz gut, warum ich das lieber nicht in der lirc.c haben möchte. Die Fehlerbereinigung bläht die Funktion auf etwa die doppelte Größe auf und macht sie dazu noch ziemlich unübersichtlich.

Das mit der automatischen Erkennung sollte so eigentlich funktionieren, da, solange die RepeatRate noch nicht bekannt ist, mit der Erkennung von LIRC gearbeitet wird und die geht ja prinzipiell. Ein oder zwei Preller kann man am Anfang notfalls auch mal tolerieren.

Die grundlegende Funktion sollte der deines Patches RC2.diff.txt entsprechen (so ist das zumindest gedacht).

Quote from jrie

Dann doch lieber zurück zu KISS:

Meine bisheriger Patch ist ja eigentlich nur ein refactoring, der die Funktion vereinfachen und übersichtlicher machen soll.
Eine funktionale Änderung ist nicht (erstmal) angestrebt.

Quote from jrie

Zeile 145 und 146 sind ein Workaround für nicht-toggelnde Protokolle, der aber toggelnde Protokolle stört, und die müssen raus.

So wie es für mich aussieht, würde es mit den Default-Werten auch bei nicht-toggelnden Protokollen zu komischen Effekten kommen.

Evtl. könnte man es aber so machen:

--- lirc.c.shf.v2       2025-12-05 23:41:44.732223113 +0100 
+++ lirc.c      2025-12-09 23:58:59.751888824 +0100 
@@ -139,6 +139,8 @@ 
              continue; 
              } 
           if (count == 0) { // new key pressed 
+              if (strcmp(KeyName, LastKeyName) == 0 && LastTime.Elapsed() < (uint)Setup.RcRepeatDelta + 10) 
+                 continue; // Workaround for remotes with key bounce / chatter. Set RcRepeatDelta 3-5ms below the actual repeatrate of the remote. 
              if (repeat) 
                 Put(LastKeyName, false, true); // generated release for previous repeated key 
              strn0cpy(LastKeyName, KeyName, sizeof(LastKeyName));

Das sollte mit dem default Wert von RcRepeatDelta sicher, da unerreichbar, sein.
Selbst einem höheren Wert ist die Chance, dass man zufällig dieses 10ms Fenster trifft eher gering.

Zum Aktivieren müsste man RcRepeatDelta ca. 3-5ms unter sie Wiederholrate der FB einstellen.
Das ließe sich ganz gut ermittel, in dem man RcRepeatDelta solange erhöht, bis sich die Wiederholgeschwindigkeit schlagartig halbiert. Dann geht man einfach 3-5ms zurück.

Das wäre dann so die Minimallösung um das Prellen wenigstens einigermaßen in den Griff bekommen zu können.
Ob das bei prellenden Fernbedienungen wirklich hilft, müsste aber jemand mit einer Solchen mal probieren. (Ich habe meine derzeit leider nicht am Start, erinnere mich aber, dass mich das Prellen schon ziemlich genervt hat.)

Quote from jrie

Ein weiterer Grund, warum er raus muss

Vom mir aus gerne.
Du glaubst auch nicht, was diese Zeile mich bei der Fehlersuche an Nerven gekostet hat .

Ich kann aber nicht beurteilen, ob es nicht doch irgendwer benutzt. Mit einem RcRepeatDelay von ~120-150ms könnte es zumindest brauchbare Resultate liefern.
Daher mein Vorschlag aus #91, der sollte bei Default-Werten zumindest keinen Schaden anrichten.
Ich bin aber, wie gesagt, nicht sicher, ob man das machen soll.

Quote from jrie

Das timeout muss auch geändert werden, denn sonst würde in #44 nach den ersten 40 ms der timeout auf 60 ms gesetzt, dann der Repeat nach 108 ms fälschlich als Neuer erkannt, und dann die ersten weiteren wegen Delay fälschlich ausgefiltert.

Stimmt, das war auch eine der Überlegungen, warum ich das umgestellt habe. Das habe ich aber vergessen zu erwähnen.

Das mit dem Faktor ist generell ungünstig, da der Jitter konstant ist. Man sollte besser eine feste Zeit addieren.
Um den Fall abzufangen wären da aber mindestens 50ms nötig gewesen.
Da wäre man bei RC-5 etwa bei meinem Vorschlag. (Mit einem Faktor wäre das schon nicht mehr sinnvoll.)

Wenn man eine Timer verwendet müsste man den Wert also nach oben und unten Begrenzen, Bereich etwa: 115...180ms. Den Aufriss spart man sich halt mit einem festen Timeout von 165ms.

Quote from jrie

Außerdem ist noch die Frage #36 offen. Dass es Releases NUR nach Repeats gibt, ist ziemlich ungewöhnlich.

Zur entsprechenden Stelle im VDR-Code habe ich mich bislang nicht vor gearbeitet.
Nach meinen Tests sind Releases aber wirklich NUR nach Repeats nötig.
Außerdem machen es die anderen Eingabe-Methoden auch so.