[MPlayer-dev-eng] [PATCH] (v2) Multi-code events get LIRC input out of sync

[Reimar Döffinger]

On Wed, Jan 28, 2009 at 05:03:04AM +1300, Dennis Vshivkov wrote:
>  > I wonder why that lirc.c cmd_buf is there anyway,
> 
> There's two twists to lirc_code2char():
> 
>     - it can produce multiple commands per code, however it
>       needs to be called multiple times for that, producing one
>       command per call, hence the presence of cmd_buf at all;

That does not explain why cmd_buf is used instead of writing into dest
directly...

>     - it can produce NO commands for a code, only changing its
>       internal state or simply ignoring it; hence the existence
>       of MP_INPUT_RETRY (lirc.c is its only user).

That does not make any sense to me. First, there is already a loop to
call lirc_code2char multiple times. Second, MP_INPUT_RETRY can not work
for that purpose since lirc_nextcode would return NULL and
lirc_code2char would not be called again.
Which of course raises the additional question: what is the point of
returning MP_INPUT_RETRY...
I think MP_INPUT_RETRY is just a way to avoid another loop around
lirc_nextcode, so it is not something really necessary.

>  > I just think it needs more changes to handle very quickly
>  > consecutive keypresses correctly.
> 
> You mean, to handle cases when MP_CMD_MAX_SIZE is indeed too
> small?

No, I mean this scenario:
keys A and B were pressed, both events are waiting to be read from teh
fd.
Select sees there is data available, calls mp_input_lirc_read.
lirc_nextcode reads both, returns only A.
A creates a command, which is returned.
Since a command was returned (thus no MP_INPUT_RETRY) and select does
not show any data waiting, mp_input_lirc_read will not be called, thus
key B will not be processed.
Getting rid of MP_INPUT_RETRY and adding a loop around lirc_nextcode
instead would fix this...

> [1] The mp_input_read_cmd() code already drops commands that are
> longer than that.  Since that's acceptable, perhaps extending
> this lack of care for overly long commands to trailing parts of
> overly long sequences of commands that come at once can be
> tolerated?

Actually I think this is mostly desirable, it avoids that a single key
press with a far too high repeat rate can make MPlayer unusable (e.g.
consider a single keypress that creates 1000 seek events, that will make
MPlayer hang for quite some time).

Greetings,
Reimar Döffinger