[MPlayer-dev-eng] [PATCH] (v2) Multi-code events get LIRC input out of sync
Reimar Döffinger
Reimar.Doeffinger at stud.uni-karlsruhe.de
Mon Jan 26 14:59:55 CET 2009
On Tue, Jan 27, 2009 at 02:34:47AM +1300, Dennis Vshivkov wrote:
> Yeah, the `right' way seems:
>
> [1] Make lirc_sock non-blocking.
>
> [2] Rework current LIRC handling so that it's not polled
> constantly but made a proper part of top-level select(2).
>
> [3] When top-level select(2) indicates data on lirc_sock, poll
> lirc_nextcode() until no code is returned.
The reason I mentioned this is because I think this is not all.
mp_input_lirc_read must be modified to return _all_ buffered commands,
both those by lirc_nextcode, by lirc_code2char or the cmd_buf itself,
otherwise using select in the top-level will not work.
I wonder why that lirc.c cmd_buf is there anyway, is this outdated code
or is MP_CMD_MAX_SIZE too small or...?
> The v2 of the patch is attached.
Looks good to me, any objections? A well-tested patch to get rid of the
cmd_buf in lirc.c would be welcome :-).
Btw. using select for lirc can be enbled in input.c by changing
the 0 to 1 in the mp_input_add_cmd_fd in line 1771, I just think it
needs more changes to handle very quickly consecutive keypresses
correctly.
Greetings,
Reimar Döffinger
More information about the MPlayer-dev-eng
mailing list