Bug 207885

I'm not familiar enough with the architecture to understand exactly what's going on, but here are the symptoms:

If I use ir-keytable -t I get a "lag" of one event. That is to say that if I were to press the IR remote buttons Up, Down, Left, Right then the output would be -, Up, Down, Left. If I then pressed the IR remote button Select, the output would be Right. If I were to press the Select button again, the output would be Select.

If I use ir-ctl -r I see the whole event _except for_ receive timeout (ev.timeout in lirc_dev.c) and described here as "Signal Free": http://slydiman.narod.ru/scr/kb/rc6.htm

This happens across all IR protocols. It would appear to me that lirc_dev.c is not receiving a call to ir_lirc_raw_event where ir_raw_event.timeout is true, and so it dispatches the event as far as it is understood when it receives the reset space at the start of the next event.

This is an example single button press from ir-ctl -r:
-9960 +2573 -913 +415 -498 +415 -498 +415 -913 +415 -913 +830 -498 +415 -498 +415 -498 +415 -498 +415 -498 +830 -913 +830 -498 +415 -498 +415 -913 +415 -498 +415 -498 +830 -913 +830 -498 +415 -913 +830 -913 +415 

I would expect it to terminate with some gap representing the receive timeout, e.g. -10000 if the timeout was 10000:

        /* Packet end */
        } else if (ev.timeout) {
                if (dev->gap)
                        return;

                dev->gap_start = ktime_get();
                dev->gap = true;
                dev->gap_duration = ev.duration;

                sample = LIRC_TIMEOUT(ev.duration / 1000);
                dev_dbg(&dev->dev, "timeout report (duration: %d)\n", sample);


I have written my own code to interpret such a sequence, but it occurred to me that with the sequence piped to my own interpreter, it's impossible to know that the data is complete without making an assumption about the data length - and I expect this is the reason the event device is not returning until the start of the next event.

It might simply be the case that gap is erroneously set to true (or that the test for gap already being true is itself erroneous?) Again, I don't know enough about the in-depth implementation to know for sure - otherwise I'd just submit my own PR.