[LB06]

Hi,
I'm experiencing the same thing than gazrat. I recently bought a origen ae m10 with an imon vfd/ir display an rushing through various installations since then, starting with debian and now struggling with natty.
Since I tried 64 as well as 32 bit natty I can say, they behave differently at some points (by the way upstart is annoying, it drives me crazy, since errors appear and dissappear randomly): Where in natty amd64 ir-keytable can load a table without problems into the driver, the i386 version fails for me.
I guess it's either the kernel module or ir-keytable which has some sort of overflow in the variable that stores the key-code since my remote produces two groups of codes:
0x020000XX - they seem to get to the driver.
0x800ff4XX - they're all replaced with 7fffffff when ir-keytable tries to load them into the driver.
And as I said: In natty amd64 ir-keytable worked - except - lcdproc seems to have problems with the new imon module, but thats another problem and the same in i386.
I've tried to use the old lirc modules build from lirc-modules-source (forced install, since the kernel version is newer, but doesn't support the display). Lcdproc works just fine with the old lirc_imon module but lirc doesn't receive anything from the remote. Since I took the ubuntu sources of lirc and build them for debian squeeze (lirc in squeeze is awfully old) and the just worked with debians 2.6.32 amd64 kernel and I used the same config, the problem is likely between the newer kernel and the old module - so dead end here.

Thank you for testing! So I guess there's a bug in the i386 version of ir-keytable that prevents some scancodes from getting loaded properly. I'll see if I can submit a proper bug report.

Also thanks for your LIRC guide. Yes, I think the problems were caused by the newer kernel. As I stated in my first post >=2.6.33 and LIRC do not really go hand in hand without some measures (like blacklisting).