Fix for Apple remote repeat problem in lirc-0.8.3

[Will]

The current implementation of the macmini remote in lirc-0.8.3 has a
problem with repeats. It is not possible to tell the difference
between holding down a key and pressing a key rapidly. Using irw as a
test application, if you repeatedly press a remote button rapidly, you
should get the following output:

0000000087ee180d 00 MINUS Apple_IR
0000000087ee180d 00 MINUS Apple_IR
0000000087ee180d 00 MINUS Apple_IR
0000000087ee180d 00 MINUS Apple_IR
0000000087ee180d 00 MINUS Apple_IR
0000000087ee180d 00 MINUS Apple_IR

If you hold down a remote button you should get a different output:

0000000087ee180d 00 MINUS Apple_IR
0000000087ee180d 01 MINUS Apple_IR
0000000087ee180d 02 MINUS Apple_IR
0000000087ee180d 03 MINUS Apple_IR
0000000087ee180d 04 MINUS Apple_IR
0000000087ee180d 05 MINUS Apple_IR
0000000087ee180d 06 MINUS Apple_IR

This is how programs that interface with lirc can tell the difference
between holding down a button and pressing a button rapidly. With the
current macmini implementation in lirc-0.8.3 the irw output is the
same regardless of whether you hold a button or rapidly press it:

0000000087ee180d 00 MINUS Apple_IR
0000000087ee180d 01 MINUS Apple_IR
0000000087ee180d 02 MINUS Apple_IR
0000000087ee180d 03 MINUS Apple_IR
0000000087ee180d 04 MINUS Apple_IR
0000000087ee180d 05 MINUS Apple_IR
0000000087ee180d 06 MINUS Apple_IR

This means that lirc cannot tell the difference between holding down a
button and pressing it rapidly. This, in turn messes up how the
"repeat" and "delay" parameters in lircrc work. Currently people are
using the lircrc "repeat" setting to slow down how rapidly the buttons
on the remote repeat so they can let go of the button before it
triggers another press. This work-around causes another problem. You
can't press the remote buttons rapidly to navigate around the menus,
which makes the remote unresponsive for people like me that like to
fly through the menus.

Below is a patch for lirc-0.8.3 that fixes this problem. It's kind of
a hack because the timeout is hardcoded to 120msec. A better solution
would be to use the "gap" time from lircd.conf. I think there's even
functionality in lirc that uses the gap time to control repeats
automatically. But I haven't followed up on it.

With this patch in place you can set lircrc "repeat" to 0 for buttons
that you don't want to repeat. You can still press the button rapidly
and get presses each time. Or you can set "repeat" to 2 and set delay
to 7. This gives the remote buttons a delayed repeat, like a keyboard
key. When you press and hold the remote button you get one press
followed by rapidly repeating presses after a short delay. You can
also press the remote button rapidly and get presses each time.

--- lirc-0.8.3/daemons/hw_hiddev.c 2008-04-28 14:17:31.000000000 -0400
+++ lirc-0.8.3/daemons/hw_hiddev.c 2009-04-28 13:11:00.000000000 -0400
@@ -582,10 +582,14 @@
}
main_code = old_main_code;
}
- if (old_main_code == main_code)
+ if ((old_main_code == main_code) && (time_elapsed
(&time_of_last_code, &now) < 120000))
{
repeat_flag = 1;
}
+ else
+ {
+ repeat_flag = 0;
+ }
old_main_code = main_code;
time_of_last_code = now;

[Peter Korsgaard]

>>>>> "Will" == Will <wck...@gmail.com> writes:

Hi,

Will> The current implementation of the macmini remote in lirc-0.8.3
Will> has a problem with repeats. It is not possible to tell the
Will> difference between holding down a key and pressing a key
Will> rapidly. Using irw as a test application, if you repeatedly
Will> press a remote button rapidly, you should get the following
Will> output:

Thanks, have you sent this to the lirc list?

--
Bye, Peter Korsgaard

[Will Koehler]

I just posted on the lirc list a few minutes ago. Thanks for the
suggestion.

But now that I've done it I think there may be a better solution. The
Apple remote supposedly sends a repeat code when you hold a button
down. On the first press, the remote sends the button code, but when
you hold the button down the remote then sends a repeat code instead
of the code of the button you are holding down. They did this to
conserve battery as the repeat code is shorter than the button code.

At the level I am working in LIRC that repeat code has been replaced
with the button ID of the button that is being held down. So all I see
are button codes. I think this is done by a lower layer - maybe the
usbhid driver? If I can find that, I can have the lower layer send
LIRC the repeat code and then fix LIRC to translate the repeat code
and handle repeats correctly. I would no longer need the timeout check.