Hi,
I'm using recently added lirc remotes support and I'm having some problems, so would like to discuss few things with other users and also Pluto stuff...
Let me first explain briefly how lirc works:
dcerouter_260:~$ irw
00000014e20d0000 00 1 ATI_Remote_Wonder
00000014e20d0000 01 1 ATI_Remote_Wonder
00000014e20d0000 02 1 ATI_Remote_Wonder
00000014e20d0000 03 1 ATI_Remote_Wonder
00000014e20d0000 00 1 ATI_Remote_Wonder
00000014e20d0000 01 1 ATI_Remote_Wonder
00000014e20d0000 02 1 ATI_Remote_Wonder
00000014e20d0000 03 1 ATI_Remote_Wonder
When key is pressed then first message is produced (it's numberred 00 - second column). If key stays pressed, then every few moments another messages are generated that are numbered accordingly....
In code section there are 8 messages that are generated from two keypresses. So for 'normal' use of keys those messages should be filtered on majority of keys - to detect keypress only once (like up, down, enter). On other keys (volume, brightness, etc...) filtering os not necessary cause we can act on each message (as long as key is pressed)...
To make things harder - time lag between two messages can vary a lot on different remotes....
Looking at DCE_LIRC log one can see that messages are generated for all events, so one can have problems on some fast remotes cause many events are generated instead of one. DCE_LIRC translates numbers into repeat parameter - but I'm not sure if this is used in further processing in Infrared plugin (if I understand right)...
So my proposition for dealing with this problem is to do it in higher level (so one can define along with other key mappings in default device also if keys are filtered (one event per keypress) or not...).
if this is already done, then take my writting just as additional info on how Lirc works....
I guess these problems are not related on remotes with custom drivers cause probably they deal with this already...
HTH,
regards,
Rob.
