[MPlayer-dev-eng] [PATCH] lirc repeat patch

Reimar Döffinger Reimar.Doeffinger at stud.uni-karlsruhe.de
Tue Jun 21 22:25:19 CEST 2005


Hi,
On Tue, Jun 21, 2005 at 10:34:45PM +0400, Lev A. Melnikovsky wrote:
> In reality it works as follows: the lirc library does sends n-1 empty 
> events then 1 informative, then again...

Why on earth does it send "empty" events the instead of just swallowing
them??

> >>+while(1) {
> >>   while((r = select(fd+1,&fds,NULL,NULL,&tv)) <= 0) {
> >>     if(r < 0) {
> >>       if(errno == EINTR)
> >> continue;
> >>       mp_msg(MSGT_INPUT,MSGL_ERR,"Select error : %s\n",strerror(errno));
> >>       return MP_INPUT_ERROR;
> >>-    } else
> >>+    } else  if(cmd_buf) // return the first command in the buffer
> >>+return mp_input_lirc_read(fd,dest,s);
> >>+    else
> >>       return MP_INPUT_NOTHING;
> >>   }
> >>
> >>@@ -99,10 +102,8 @@
> >>
> >>   if(r < 0)
> >>     return MP_INPUT_DEAD;
> >>-  else if(cmd_buf) // return the first command in the buffer
> >>-    return mp_input_lirc_read(fd,dest,s);
> >>-  else
> >>-    return MP_INPUT_NOTHING;
> >>+}
> >>+
> >Why did you move that if(cmd_buf) thing up, shouldn't just adding the
> >while(1) loop be enough?
> How would the loop terminate then?

Well, there are a lot of returns in that code part, but I can't test
(and am not familiar with the code).

> >Also if there are two events followed very closely by each other, won't 
> >the first one be simply ignored by your patch?
> I do not think so. All events are sequentially collected in cmd_buf. Am I 
> missing something?

no, probably not. That half-recursive calling of mp_input_lirc_read had
me confused...

Though that kind of functionality might be more appropriate in input.c,
around line 701. I looks like something like that is already
half-implemented??
I don't know, but maybe you can introduce an MP_INPUT_RETRY return
value (that is sent for such an empty event) and do a continue;
in that switch statement in input.c. Don't know if you can detect those
"empty" events easily though.
But that would be a solution others could maybe profit from as well...

Greetings,
Reimar Döffinger




More information about the MPlayer-dev-eng mailing list