[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