[MPlayer-dev-eng] [PATCH] (v2) Multi-code events get LIRC input out of sync
Reimar.Doeffinger at stud.uni-karlsruhe.de
Tue Jan 27 20:28:44 CET 2009
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
> - 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
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
No, I mean this scenario:
keys A and B were pressed, both events are waiting to be read from teh
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...
>  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
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).
More information about the MPlayer-dev-eng