Lirc: strange behaviour (key being repeated twice)

everything about the next not so big update

Moderator: Moderator

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Tue Mar 13, 2007 11:39 pm

Excellent :D

esprit
master
Posts: 503
Joined: Tue Dec 06, 2005 5:50 pm
Location: France
Contact:

Postby esprit » Wed Mar 14, 2007 9:15 am

arj wrote:Well you can fix it by defining the navigation keys as not fast keys. Lirc is really strange in this regard. On my remote the irdata.serial will start from 0 and to about 7 and then it will idle for a little while even though I'm holding down the button and then it will sometimes continue and sometimes just reset to 0.

Are you talking of setting multiple key presses to no ?
But this is really useful when browsing audio folders, I don't want to have to press the button each time I want to go down.

By the way, an interesting thing in the lircrc doc :
begin
prog = ...
remote = ...
button = ...
repeat = ...
delay = ...
config = ...
mode = ...
flags = ...
end

Bringing it to the point the above says which program (prog) should do what (config, mode, flags) if you press a certain button (remote, button) a specified time (repeat, delay).

prog
gives the name of the program that should receive the configstring given in config.
remote, button
specify a key of a remote control that launches an action. Key sequences can be specified by giving more then one remote/button string. The character '*' can be used as a wild card for remote or button. The default for remote is '*'. The remote name must always be given before its according button. When using key sequences a given remote is valid for all following buttons until you specify another remote.
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.
delay
tells the program to ignore the specified number of key repeats before using the "repeat" configuration directive above. This is used to prevent double triggers of events when using a fast repeat rate. A value of zero, which also is the default, will disable the delay function.

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Wed Mar 14, 2007 9:39 am

esprit wrote:Are you talking of setting multiple key presses to no ?
But this is really useful when browsing audio folders, I don't want to have to press the button each time I want to go down.

The way it works for me, either I disable fast keys or I can't use the remote control (this affects any key, not just the arrow ones). Mind you, disabling the fast keys means a key-press is accepted and processed each time lirc returns an output with '0' as repeat count, which, with my settings, happens every 400ms even if I press a button and I never release it. :roll: (I haven't actually tested it with fast keys disabled, but this is what I can infer from the code).

In other words, it is a workaround if your remote control is like mine, but if lirc behaves properly on your PC and the remote control is usable, you don't have to do it.
By the way, an interesting thing in the lircrc doc :
[...]


Mms uses /etc/input-lirc to match remote keys with actions. Are you suggesting that it should use lircrc and the lirc_code2char() API to parse it? In my case it wouldn't make things better, although a "repeat delay" option may be a good thing for some people...

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Wed Mar 14, 2007 10:22 am

lorenzodes wrote:
esprit wrote:Are you talking of setting multiple key presses to no ?
But this is really useful when browsing audio folders, I don't want to have to press the button each time I want to go down.

The way it works for me, either I disable fast keys or I can't use the remote control (this affects any key, not just the arrow ones). Mind you, disabling the fast keys means a key-press is accepted and processed each time lirc returns an output with '0' as repeat count, which, with my settings, happens every 400ms even if I press a button and I never release it. :roll: (I haven't actually tested it with fast keys disabled, but this is what I can infer from the code).


Well using your old patch it would accept one each 200ms so it's not that much different?

The delay option according to that quote works the same way as the current code works if fast or multiple is enabled for a key. The only difference is that it's hardcoded to 2 instead of being variable. Maybe we should add that if it's useful?

For me it would actually be useful to set it to zero since that would make my remote faster. But that's not acceptable to esprit and acmelabs since that made their remote too fast to be usable :)

What kind of repeat values do you have in your .lircrc file for mplayer?

esprit
master
Posts: 503
Joined: Tue Dec 06, 2005 5:50 pm
Location: France
Contact:

Postby esprit » Wed Mar 14, 2007 10:37 am

Yeah, in fact I was suggesting to have the same kind of delay management in mms then with lircrc.
Your code changes seems to do quite the same thing then lircrc delay, so why not adding a configuration option in the input-lirc config to give that delay for each command ?

Code: Select all

# Syntax:
# mode, command, key, multiple keypresses, delay


So Anders could want no delay (0, should be default), you could want 200ms, 100ms for me (I don't know), ...

Possible ? not possible ? easy to implemente ? not easy ? good idea ? bad idea ?

I let you answer those questions :D

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Wed Mar 14, 2007 10:38 am

arj wrote:Well using your old patch it would accept one each 200ms so it's not that much different?


It's exactly the same thing, i.e. a key event is processed every 400 ms (now I know why I couldn't make it any faster by setting timeinterv to 100 or even 50ms in my patch) :oops:

The delay option according to that quote works the same way as the current code works if fast or multiple is enabled for a key. The only difference is that it's hardcoded to 2 instead of being variable. Maybe we should add that if it's useful?

That would be good for people whose remote is too fast, so that they can adjust it according to their taste. As I said in my previous post, unluckly it is not my case :/

For me it would actually be useful to set it to zero since that would make my remote faster. But that's not acceptable to esprit and acmelabs since that made their remote too fast to be usable :)

:)

What kind of repeat values do you have in your .lircrc file for mplayer?

Repeat is set to 0 for all of them. I feel a bit stupid :oops:

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Wed Mar 14, 2007 11:09 am

esprit wrote:Yeah, in fact I was suggesting to have the same kind of delay management in mms then with lircrc.
Your code changes seems to do quite the same thing then lircrc delay, so why not adding a configuration option in the input-lirc config to give that delay for each command ?

Code: Select all

# Syntax:
# mode, command, key, multiple keypresses, delay


So Anders could want no delay (0, should be default), you could want 200ms, 100ms for me (I don't know), ...

Possible ? not possible ? easy to implemente ? not easy ? good idea ? bad idea ?

I let you answer those questions :D


"Delay" in lircrc doesn't work as you describe it. It is used to tell lirc to ignore key events that have a repeat count >0 and <=$delay. That would be easy to implement because it's already in mms. :)

A timer (i.e. accept key events every xxxmilliseconds) would be easy to do too, but as global option. Anyway what would be the point of having different values for different keys?

p.s.: mms is a great piece of software, now 2 friends of mine who are about to buy a new plasma TV also want "that penguin thingie that runs on your pc and that you use to play DVDs e listen to music" :P

User avatar
acmelabs
Overlord
Posts: 2365
Joined: Mon Feb 20, 2006 9:18 pm
Location: Germany
Contact:

Postby acmelabs » Wed Mar 14, 2007 11:59 am

I really encourage everybody in this discussion, but please don't change input-lirc, since input-lirc-helper has to be reworked completely.

Thanks,

Andreas

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Wed Mar 14, 2007 3:23 pm

acmelabs wrote:I really encourage everybody in this discussion, but please don't change input-lirc, since input-lirc-helper has to be reworked completely.

Thanks,

Andreas


Just to add my 2 cents (again). I second your opinion, there's no need to change the format or contents of input-lirc, a global option in /etc/mms/config would do. Can I propose something on the line of my original patch? I.e. let the user decide how many mseconds should pass between a valid remote key event and the next one.

With regard to your problems with the remote control, could you try this little proggie?

Code: Select all

#ifdef HAVE_CONFIG_H
# include <config.h>
#endif

#include <errno.h>
#include <unistd.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <lirc/lirc_client.h>

char *progname;

int main(int argc, char *argv[])
{
        struct timeval tv;
        if(lirc_init("lirctest",1)==-1) exit(EXIT_FAILURE);

                char *code =0;
                while(lirc_nextcode(&code)==0)
                {
                        if(code==NULL) continue;
                        gettimeofday(&tv,NULL);
                        printf("seconds: %d  milliseconds: %d    -", tv.tv_sec,tv.tv_usec/1000);
                        printf (code);
                        if(code)
                         free(code);

                }

        lirc_deinit();
        exit(EXIT_SUCCESS);
}

User avatar
arj
Site Admin
Posts: 2316
Joined: Thu Dec 01, 2005 8:51 pm
Location: Denmark
Contact:

Postby arj » Wed Mar 14, 2007 9:29 pm

Could you try revno 1109? In it delay has been implemented as a new config string. Default is 200. Please as many as possible test! I have had esprit test my patch so it should also work for acmelabs :) But I would really like to hear if it fixes the problem for you lozenzodes? And if other could test for regressions please!

lorenzodes
master
Posts: 772
Joined: Sun Mar 11, 2007 4:50 pm
Location: move.l 4.w,a6

Postby lorenzodes » Wed Mar 14, 2007 9:53 pm

arj wrote:Could you try revno 1109? In it delay has been implemented as a new config string. Default is 200. Please as many as possible test! I have had esprit test my patch so it should also work for acmelabs :) But I would really like to hear if it fixes the problem for you lozenzodes? And if other could test for regressions please!


A value of 200 ms works well for me, so problem solved :D

Thanks arj :)


Return to “1.0.9”

Who is online

Users browsing this forum: No registered users and 1 guest