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

Lev A. Melnikovsky leva at despammed.com
Tue Jun 21 20:34:45 CEST 2005


Dear Reimar,

   On Tue, 21 Jun 2005 at 1:27pm, Reimar DЖffinger wrote:

>> Modern lirc (0.7.0) sends multiple empty events when "repeat" is specified
>> in the config file. For instance, the line "repeat 32" (my remote sends 32
>> events for each Volume_Up press) will lead to 31 empty events and 1
>> sensible one. The patch makes mplayer swallow all available events at
>> once, not one at a time - this greatly improves responsiveness.
> Of course here the question is why you specify repeat 32?
Otherwise a volume granularity would be 32 (because each key press 
generates 32 events). Please see the excerpt from the lirc doc:

----------------------------------------------------------------------
repeat
        tells the program what shall happen if a key is repeated.  A
        value of zero tells the program to ignore repeated keys.  Any
        other positive value 'n' tells the program to pass the config
        string every 'n'-th time to the according application, when a
        key is repeated. The default for repeat is zero.
----------------------------------------------------------------------

In reality it works as follows: the lirc library does sends n-1 empty 
events then 1 informative, then again...

>
>> +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?

> 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?

Regards
-- 
                       Leva


More information about the MPlayer-dev-eng mailing list