lirc improvement suggestion

Message ID 44788BE7.6070902@gmx.de
State New
Headers

Commit Message

Joerg Riechardt May 27, 2006, 5:27 p.m. UTC
  I used to use the usbremote plugin, now I switched to lirc, because I
wanted to play with irexec. Since then vdr didn´t react to my remote
control as I was used to any more. I had sometimes double reactions on
one keypress as other people have described and the speed of the
reactions was weird. After investigating I found following solution,
which makes me 100% happy. Maybe other people like it too?

Btw. the count´s provided by lirc are not reliably incoming to the lirc
part of vdr, meaning if I press a key for a long time instead of going
up continously, they start from time to time at zero, sometimes even all
are zero. That is not catched by this patch.

Some more background information:  I compared the remote plugin for the
FF cards with the usbremote plugin for the igorplug (which was taken
from the remote plugin) and the lirc part of vdr. My remote (OFA URC
7541) with RC5 codes on each key toogles the RC5 code on each key press.
(I suppose all RC5 remotes do(?)). The firmware of the driver for the FF
cards changes that to key down/key up (AFAIR). The usbremote plugin
receives the codes as they are sent. Lirc changes the toogled codes into
counts starting from zero. With the igorplug the counts sometimes start
at zero again, with a serial receiver it does always count up. The lirc
part of vdr however has a problem here. I observed that sometimes all
counts are zero with the igorplug, with the serial driver this is much
better, but happens sometimes as well.The remote plugin and the
usbremote plugin work very well, the lirc-vdr didn´t for me. I don´t
know how the RCU processes the RC5 code, and hence don´t understand the
rcu code. The rcu code was taken for lirc in vdr (some adaptations were
made in time). I put a lot of printf´s to see how the code logic
operates and what actually happens on key presses. The improved code,
which is basically just taken from the remote plugin, works perfectly
for me.

Jörg




                   Put(LastKeyName, false, true);
                strcpy(LastKeyName, KeyName);
@@ -104,8 +104,10 @@
                timeout = -1;
                }
             else {
-              if (FirstTime.Elapsed() < REPEATDELAY)
-                 continue; // repeat function kicks in after a short delay
+              if (LastTime.Elapsed() < REPEATFREQ)
+                continue; // repeat function kicks in after a short
delay (after last key instead of first key)
+             if (FirstTime.Elapsed() < REPEATDELAY)
+                continue; // skip keys coming in too fast (for count !=
0 as well)
                repeat = true;
                timeout = REPEATDELAY;
                }
@@ -113,7 +115,7 @@
             Put(KeyName, repeat);
             }
          else if (repeat) { // the last one was a repeat, so let's
generate a release
-           if (LastTime.Elapsed() >= REPEATDELAY) {
+           if (LastTime.Elapsed() >= REPEATTIMEOUT) {
                Put(LastKeyName, false, true);
                repeat = false;
                *LastKeyName = 0;
  

Patch

--- lirc.c.orig.c       2006-01-27 16:59:47.000000000 +0100
+++ lirc.c.new.c        2006-05-26 22:40:26.000000000 +0200
@@ -13,9 +13,9 @@ 
  #include <netinet/in.h>
  #include <sys/socket.h>

-#define REPEATLIMIT  20 // ms
  #define REPEATDELAY 350 // ms
-#define KEYPRESSDELAY 150 // ms
+#define REPEATFREQ 100 // ms
+#define REPEATTIMEOUT 500 // ms
  #define RECONNECTDELAY 3000 // ms

  cLircRemote::cLircRemote(const char *DeviceName)
@@ -94,8 +94,8 @@ 
                continue;
                }
             if (count == 0) {
-              if (strcmp(KeyName, LastKeyName) == 0 &&
FirstTime.Elapsed() < KEYPRESSDELAY)
+              if (strcmp(KeyName, LastKeyName) == 0 &&
FirstTime.Elapsed() < REPEATDELAY)
                  continue; // skip keys coming in too fast
                if (repeat)