[raven]

Much has been written about this subject, but the more I search and the more I read, it just gets more confusing.

Soundgraph has the support we all know and It only works for windows. On their software for Windows there’s an option to use the Imon IR receiver as a MCE receiver. This option is very useful because my Imon remote is broken and I use a MCE remote instead.
When changing my OS to XBMCBuntu I lost my remote because I can’t change the Imon IR to work as MCE. Everything I tried, failed.

Can anyone please help me? I’m an inexperienced Linux user.

Thanks in advance

[gokudo]

Had the same problem. With help from forum user sparkie I got all problems solved. The thing is, you can't just use this combination out of the box with linux anymore. You have to install ir-keytable and set up a script which loads the right IR-channel and key assignment for your MCE remote in the imon receiver when starting. See here: http://forum.xbmc.org/showthread.php?tid...pid1062125

Look up with cat which imon receiver you have. I have 0038 so in the end this is what worked out for me:

I don't use a custom made /etc/rc_keymaps/imon_pad

Instead of the line mentioned in the post I wrote this line to rc.local:
/usr/bin/ir-keytable -w /lib/udev/rc_keymaps/imon_mce

Next you HAVE to set up LIRC, you'll need it for this. So do the steps mentioned under "Configure lirc in devinput mode:". Of course if you have the 0038 like me you have to choose usb-15c2_0038-event-if00 in the last step there.

Voilá! Start up xbmc, notice any key that dosn't work, you have to add them by looking up ther label on a command line with command 'irw' and pressing them. Sometimes XBMC has to be disabled to see them, so may have to actually leave XBMC (not shutdown of course) to see anything in irw.
Then make custom Lircmap.xml as said in the post, you have to add the missing keys to your prefered actions for them.

[raven]

Thank you very much,

I'll give it a try and post back the results.

Thanks once again

[rickx]

Hi,
I have the same never ending issues with this device. This and the linked threads may be the ones that finally give a solution.
While I'm still testing, I have a question: there are two modules which load on my system: rc_imon_pad and imon. I link the
first one to an mce (rc-6) table. The question is: WHY rc_imon_pad and not rc_imon_mce? What triggers the choice between
this two modules? I'm guessing this is a sort of design error of the whole meccanism...and rc_imon_mce will simply never be loaded.
Am I wrong?

[rickx]

...in the meantime I thought about it a bit more and ended up taking a...deeper approach. I found out that rc_maps.cfg doesn't really do much. rc_imon_pad and the imon-protocol table load also after removing the file completely. So I decided to dig into the kernel sources and found where protocol and map are chosen and commented out some parts. Now I still have to test the remote (batteries are gone) but I succeeded in making rc_imon_mce load, with rc-6 as the default enabled protocol. I still think imon's driver handling sucks, but I may have found a reliable solution.

[rickx]

Ok, I finally found a satisfying solution.
Details here: http://forum.xbmc.org/showthread.php?tid=128972

[steffen_b]

A littlebit strange idea to do it that way. Can't you rather copy imon_mce map to imon_pad , install ir-keytable (which you need then to make rc_maps.cfg to be effective). This still sounds a lot easier, then recompiling. In case the file doesnt contain the protocol you can add it in the first line in the file.

[rickx]

I tried that (obviously). But it means the kernel will continue to load rc-imon-pad on start. As I wrote, rc_maps.cfg does nothing to avoid or change that. So, yes, it sounds easier, but wasn't in my case. When it worked (and that was only using rc.local) it caused ir-keytable to freeze most of the times, with the remote not working as a consequence. When it did not freeze, it still showed "driver imon, table rc-imon-pad" calling sudo ir-keytable. Now I know that ir-keytable's output does not reflect changes you make to the mapping once booted, but I always found that message strange, and disturbing.
The freezing issues may depend on the kernel/driver not really willing to switch protocol, or on some other mysterious reason - I don't care now that the protocol switching is not necessary any more.
Apart from the (relative) complexity of recompiling a kernel, I basically found the protocol switch in one single position: this means you just have to change a 0 to a 1 and that's all. The rest could be left out, it's an extra (adapting the key map). The other reason for choosing the kernel recompiling solution was to try an upcoming imon patch related to urb packages/locks. It's supposed to solve another issue (http://git.kernel.org/?p=linux/kernel/gi...f15a3a5b00).
I agree it's a strange approach, but less strange than all the issues I run after for the last couple weeks trying to solve them. And less strange than the buggy imon drivers: after 4 or 5 years, there's still no reliable and effortless way to use a remote and an lcd. (actually they worked better years ago).