[GreatEmerald]

Have you guys tried changind the repeat and delays? Eg:

sudo ir-keytable --delay 500
sudo ir-keytable --period 50

?

See the quote in my post. It's an issue with the way SDL works, it seems.

[cw-kid]

Have you guys tried changind the repeat and delays? Eg:

sudo ir-keytable --delay 500
sudo ir-keytable --period 50

?

See the quote in my post. It's an issue with the way SDL works, it seems.

So that doesn't work then ?

I've been using a Logitech Harmony remote setup as a MCE remote and have not really noticed the problem.

However if I use a bog standard Microsoft MCE remote it does seem a bit more wild when pressing right button say in the movie view, it seems harder to control the navigation in the UI with the standard remote as its whizzing along faster.

[GreatEmerald]

So that doesn't work then ?

I've been using a Logitech Harmony remote setup as a MCE remote and have not really noticed the problem.

However if I use a bog standard Microsoft MCE remote it does seem a bit more wild when pressing right button say in the movie view, it seems harder to control the navigation in the UI with the standard remote as its whizzing along faster.

Yes, it doesn't work. It's easy to see what's happening when using ir-keytable. With a longer delay and period, you will see ir-keytable still showing events at the same, "native" delay and period. Only the keyboard events are sent slower - in essence it just ignores excess events. However, SDL does not take the events, but instead it interfaces directly with the input device, thus circumventing the ir-keytable timing settings altogether. Thus changing the values has no effect for XBMC, but does have an effect on applications that don't use SDL.

[cw-kid]

So that doesn't work then ?

I've been using a Logitech Harmony remote setup as a MCE remote and have not really noticed the problem.

However if I use a bog standard Microsoft MCE remote it does seem a bit more wild when pressing right button say in the movie view, it seems harder to control the navigation in the UI with the standard remote as its whizzing along faster.

Yes, it doesn't work. It's easy to see what's happening when using ir-keytable. With a longer delay and period, you will see ir-keytable still showing events at the same, "native" delay and period. Only the keyboard events are sent slower - in essence it just ignores excess events. However, SDL does not take the events, but instead it interfaces directly with the input device, thus circumventing the ir-keytable timing settings altogether. Thus changing the values has no effect for XBMC, but does have an effect on applications that don't use SDL.

Thanks for the explanation so I guess that means there is no current solution!

[sparticle]

MODS please make this post a sticky!!!

[stef70]

The multiple key repeats are caused by unnecessary timouts in the decoder modules.

I made a patch for the RC5 decoder but it did not attract any attention. RC6 and probably other decoders suffer from the same issues.

My patch is in http://www.spinics.net/lists/linux-media/msg62650.html

A more complete analysis of the problem is in http://www.spinics.net/lists/linux-media/msg62656.html

Simply speaking with the current decoder, the last KEYPRESS occurs 200ms after the last pulse and the final KEYUP occurs 450ms after the last pulse. This causes some unexpected key repeats that are making XBMC almost unusable. One way to mitigage the problem is to raise the key repeat delay to 700ms or above. This must be done inside XBMC sources (It is harcoded to 500ms by a SDL call) but, even then, the remote feels slugish and unreliable.

With my patch, those delays are respectively reduced to almost 0 and 200ms. The remote is a lot more reactive and the probability to have a unexpected key repeat are almost nil.

My posts on the linux-media mailing list were completly ignored so it would be nice if someone else could backup my claims.

In theory, the modification used in my RC5 patch should be applicable to the RC6 decoder.

---

I might be able to produce a patch for the RC6 decoder but not before the next week-end.

[stef70]

For peoples trying to reproduce my finding

- The patch to print the timing is in http://www.spinics.net/lists/linux-media/msg62658.html

The output should go to /var/log/kern.log

- The patch is for the latest git media tree from linuxtv

http://linuxtv.org/wiki/index.php/How_to...ce_Drivers

- If you have a 'universal remote', try some of the Philips codes. Most of them are RC5 (small 16bit scancodes) or RC6 (long 32bit scancodes)

[stef70]

This is not tested but until there is a real patch for RC-6, the following changes in the drivers/media/rc sources could make the current RC6 decoder a lot more usable:

(1) Reduce the timeout value in rc-main controled by the macro IR_KEYPRESS_TIMEOUT which is currently 250ms

The smalled possible value depends of the repeat delay of the protocol which appears to be around 83 ms.
A value of 100ms or 150ms should work file.

(2) Reduce the timeout in the ir driver.

On my system, the driver is ite_cir and its timeout is controled by the macro ITE_IDLE_TIMEOUT = 200ms in ite-cir.h

A value around 50ms should be fine except that 100ms appears to be the minimum for ite_cir (see ITE_MIN_IDLE_TIMEOUT).
Is it a soft or heard limit? I don't know.

THIS IS NOT TESTED and that is likely to break other decoders that may require longer timeouts.

[GreatEmerald]

This is not tested but until there is a real patch for RC-6, the following changes in the drivers/media/rc sources could make the current RC6 decoder a lot more usable:

(1) Reduce the timeout value in rc-main controled by the macro IR_KEYPRESS_TIMEOUT which is currently 250ms

The smalled possible value depends of the repeat delay of the protocol which appears to be around 83 ms.
A value of 100ms or 150ms should work file.

Ah, you mean kernel sources at drivers/media/rc/rc-main.c. Interesting, I might test that at some point, given that my HTPC is using Gentoo, where recompiling the kernel is an easy task.

(2) Reduce the timeout in the ir driver.

On my system, the driver is ite_cir and its timeout is controled by the macro ITE_IDLE_TIMEOUT = 200ms in ite-cir.h

A value around 50ms should be fine except that 100ms appears to be the minimum for ite_cir (see ITE_MIN_IDLE_TIMEOUT).
Is it a soft or heard limit? I don't know.

THIS IS NOT TESTED and that is likely to break other decoders that may require longer timeouts.

Huh. Well, in my case I don't use a specific driver for the IR device, as it's bundled with my TV card. Is this second step really necessary for other remotes?

[stef70]

Ah, you mean kernel sources at drivers/media/rc/rc-main.c. Interesting, I might test that at some point, given that my HTPC is using Gentoo, where recompiling the kernel is an easy task.

Are you using RC6?

Huh. Well, in my case I don't use a specific driver for the IR device, as it's bundled with my TV card. Is this second step really necessary for other remotes?

I really don't know but I assume that each ir driver must have some kind of timeout. This is basically needed because the ir driver is calling the decoders after each change in the receiver state (blank to pulse or pulse to blank).

The long blank following each message may actually contain information needed by the decoder (if the message ends by a blank) so the driver must report that long blank after a relatively short delay that should nevertheless be larger than any valid blank inside the message.

Anyways, look in your driver sources for the assigment of the field rdev->timeout where rdev is of type struct rc_dev

I just checked a few drivers (nuvoton, winbond, ttusbir, ...) in the media/rc directory and they all seem to using 100ms which is a already better than the 200ms of ite-cir.

The fact that there is a min_timeout and a max_timout in rc_dev seems to imply that the timeout can be changed within those limits. This is probably possible via the lirc interface.

[GreatEmerald]

Are you using RC6?

I think so. Either that or RC5.

[stef70]

The following C program is using the lirc interface to display the min & max timeout of the ir driver.
When given an argument it can change the current timeout within those bounds.

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <limits.h>
#include <signal.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/ioctl.h>

#include <linux/include/media/lirc.h>

#define DEVICE "/dev/lirc0"

int main(int argc, char**argv)
{
int ok ;
int fd ;
unsigned min_timeout = 0 ;
unsigned max_timeout = 0 ;
unsigned timeout = 0 ;

fd = open( DEVICE , O_RDWR) ;
if (fd<0) {
fprintf(stderr,"Failed to open device\n");
exit(1) ;
}

ok = ioctl(fd, LIRC_GET_MIN_TIMEOUT, &min_timeout) ;
if ( ok!=0 ) {
fprintf(stderr,"Failed LIRC_GET_MINAX_TIMEOUT\n");
exit(1) ;
}
printf("get LIRC_GET_MIN_TIMEOUT = %u\n",min_timeout) ;


ok = ioctl(fd, LIRC_GET_MAX_TIMEOUT, &max_timeout) ;
if ( ok!=0 ) {
fprintf(stderr,"Failed LIRC_GET_MINAX_TIMEOUT\n");
exit(1) ;
}
printf("get LIRC_GET_MAX_TIMEOUT = %u\n",max_timeout) ;

if (argc>1) {
timeout = atoi(argv[1]) ;
ok = ioctl(fd, LIRC_SET_REC_TIMEOUT, &timeout) ;
if ( ok!=0 ) {
fprintf(stderr,"Failed LIRC_SET_REC_TIMEOUT\n");
exit(1) ;
}
printf("set LIRC_SET_REC_TIMEOUT = %u\n",timeout) ;
}

return 0;
}

[stef70]

I just realized that my rc5 patch does not work well when the timeout of the ir driver is 100ms. That is unfortunately the default for most drivers other than ite_cir.

The value RC5_UP_DELAY in my patch should be decreased from 114000000 to something below 100000000 (the ir driver timeout) but above 90000000 (the effective duration of the blank between two repeated messages).

A value such as 95000000 should be fine.

[cw-kid]

When using the in kernel option with ir-keytable no LIRC can you use a remote.xml file? Or just the keyboard.xml file.

Trying to work out how to add new custom commands here, but having problems.

Thanks

[GreatEmerald]

When using the in kernel option with ir-keytable no LIRC can you use a remote.xml file? Or just the keyboard.xml file.

In-kernel LIRC interprets remotes as keyboards, so XBMC uses the keyboard.xml file. You can freely change what button represents what keystroke by modifying the files in /etc/rc_keymaps/. It makes sense to check out the stock keyboard.xml file and rebind your rc_keymaps to closely match the keys in the stock keyboard.xml file (so you don't need to change the XML files to begin with).