Now the next problem is that the kernel ir drivers generate keyboard scan codes greater than 255 for some keys. Xorg does not recognize these, in fact it ignores them. Until there is an overhaul of Xorg to fix this, we must work around it otherwise XBMC will never get the keys.

Ok, now we need to remap the keys in xbmc to work. Need to add a keyboard.xml to .xbmc/userdata/keymaps. See next post for contents of my keyboard.xml

This is based on the default file and modified to my preferences. Note that there does seem to be an issue with the recent git of xbmc. You use to be able to look for the scancode of unmapped/unknown keys in the log and use something like <key id='65446'>, but the with recent overhauls, this seems to no longer work.

That should be it, it should work. The only thing that's a bit of a pain, is that if you press and hold a key, the repeat frequency seems very, very high. I haven't got around to tuning that yet.

illumilore Wrote:Is there a way to test that keyboard scan codes greater than 255 are working in oneiric since the kernel's mce drivers might have been updated as well?

Its not the kernel drivers that need an update/overhaul. Its xorg server itself. If you google the subject, you'll see its been in discussion for at least a year and is a fairly major change, so I don't think we'll see it anytime soon. Perhaps in 1.12 or in the newer x11 server in development, Wayland Display Server.

if you use the default rc6_mce file then it will generate keycodes greater then 255. Omit "-w /etc/rc_keymaps/rc6_mce" and it should load the default file, forget exactly where its stored. If you have already run ir-keytables with "-w /etc/rc_keymaps/rc6_mce", then you need to specify -w with the path to the default file (will be somewhere under /usr)

Hi I have followed your guide and read about a million pages relating to mce setup in xbmc.

I hate to sound stupid, but in my mind there is a missing link in this chain, and hopefully you can clarify for me ...

I currently have a hauppauge mce rc-6 remote, which appears to work, I have followed your guide, but am having trouble understanding where the special mapping comes in .. basically I can use ir-keytable -t and my remote outputs perfectly .. specifically the OK key shows as KEY_OK ..

I have looked in my keyboard.xml, but cant for the life of me .. see how KEY_OK maps into the keyboard.xml file .. I have tried <KEY_OK>Select</KEY_OK>, expecting this to miraculously work, but it didnt, and I wouldve expected nothing less .. how would XBMC magically know that <KEY_OK> actually meant a remote button .. as opposed to a magical keyboard combo ?? I feel like Im ranting, but this has taken me 4 days of research, and Im no closer to a solution .. but perhaps you can clarify for me please...

All I want, is to be able to push an MCE remote button, find the code or constant name that it generates or maps to, and edit my keyboard.xml file to select a specific XBMC action to map it to ... what on earth am I missing .. please help.

PS, I am a windows person, but have bumbled my way through an Ubuntu oneiric + Latest XBMC install .. so please be gentle ..

The file that is most relevant to your question is the rc6_mce file under /etc/rc_keymaps. The comments to the right are inserted by the original poster.

Using ir-keytable -t, you would find the keycode that's emitted, and because of how IR keycodes work now, you don't map KEY_OK to something anymore (removal of Lircmap.xml is noted in the first couple sentences). Prior to the newer versions of the Linux kernel, we used to modify that to map keycodes to the XBMC command mappings like Select, Escape, and so on.

In your situation, the line that's relevant for you is:

Code:

0x800f0422 KEY_ENTER # Ok

Forget about KEY_OK, it doesn't exist on a regular keyboard, right? You don't have an OK key (unless you're on some really esoteric keyboard that won't work with most consumer PCs).

For another example of how things changed, I added another line to my rc6_keymap file like so:

Code:

0x800f0426 KEY_C # menu button

This line used to map to KEY_EPG (the "Menu" button / program guide button), and now XBMC as well as a bunch of other apps will see it as the 'c' key from the keyboard, which according to the keyboard.xml file brings up the context menu.

Code:

<c>ContextMenu</c>

And if you want to set the repeat frequency / delay, modify the command used in the ir-keytable command.

Your getting KEY_OK because you are still using the default rc keymap file from /lib/udev/rc_keymaps/rc6_mce. Only this file has KEY_OK.

XBMC doesn't know what to do with KEY_OK and you can't define arbitrary keys in keyboard.xml.

There could be two reasons why ir-keytable is using the default file instead of the one I defined. Could be something wrong with the init script that its not running. So try this at at the command line

Code:

/usr/bin/ir-keytable -c -p RC-5,RC-6 -w /etc/rc_keymaps/rc6_mce

Now

Code:

ir-keytable -t

Now check if you still get KEY_OK or KEY_ENTER. If you get KEY_ENTER its your init script, if you still get KEY_OK, then there is something wrong with the /etc/rc_keymap file. Perhaps a type, check that it begins with

Code:

# table rc6_mce, type: RC-6

Although that looks like a comment, it is mandatory that it appear exactly that way. ir-keytable uses it.

The other explanation is that perhaps you didn't build and replace ir-keytable correctly.

But I see your using oneric, so it may have been fixed in that ubuntu build anyway. If you replaced the ir-keytable executable according to my instructions, try this to check if the oneric version is ok.

djk29a Wrote:The file that is most relevant to your question is the rc6_mce file under /etc/rc_keymaps. The comments to the right are inserted by the original poster.

Using ir-keytable -t, you would find the keycode that's emitted, and because of how IR keycodes work now, you don't map KEY_OK to something anymore (removal of Lircmap.xml is noted in the first couple sentences). Prior to the newer versions of the Linux kernel, we used to modify that to map keycodes to the XBMC command mappings like Select, Escape, and so on.

In your situation, the line that's relevant for you is:

Code:

0x800f0422 KEY_ENTER # Ok

Forget about KEY_OK, it doesn't exist on a regular keyboard, right? You don't have an OK key (unless you're on some really esoteric keyboard that won't work with most consumer PCs).

For another example of how things changed, I added another line to my rc6_keymap file like so:

Code:

0x800f0426 KEY_C # menu button

This line used to map to KEY_EPG (the "Menu" button / program guide button), and now XBMC as well as a bunch of other apps will see it as the 'c' key from the keyboard, which according to the keyboard.xml file brings up the context menu.

Code:

<c>ContextMenu</c>

And if you want to set the repeat frequency / delay, modify the command used in the ir-keytable command.

Thanks for answering .. please correct me if Im wrong ..

Heres a summary if what im getting from your post, I will try to make changes, but I believe you first understand, then fiddle, otherwise you make it worse ..

So the constant name like "KEY_OK" is not always relevant to XBMC, in my case I have 2 different IR codes in my mce_rc6 file, which means when I select the code for "KEY_OK", it is translated to the button "KEY_OK" before getting accepted by XBMC, and because "KEY_OK" is not a proper key, XBMC has no idea what to do with it ..

But, if I change the mce_rc6 file to have "key_ok code" and "KEY_ENTER" on the same line, XBMC will know exactly what to do with "KEY_ENTER" ...

So my understanding then is : XBMC has a list of "usable" keycode constant names, so I need to map IR codes with valid keycode constant names, and Im golden ?

wstewart Wrote:Your getting KEY_OK because you are still using the default rc keymap file from /lib/udev/rc_keymaps/rc6_mce. Only this file has KEY_OK.

XBMC doesn't know what to do with KEY_OK and you can't define arbitrary keys in keyboard.xml.

There could be two reasons why ir-keytable is using the default file instead of the one I defined. Could be something wrong with the init script that its not running. So try this at at the command line

Code:

/usr/bin/ir-keytable -c -p RC-5,RC-6 -w /etc/rc_keymaps/rc6_mce

Now

Code:

ir-keytable -t

Now check if you still get KEY_OK or KEY_ENTER. If you get KEY_ENTER its your init script, if you still get KEY_OK, then there is something wrong with the /etc/rc_keymap file. Perhaps a type, check that it begins with

Code:

# table rc6_mce, type: RC-6

Although that looks like a comment, it is mandatory that it appear exactly that way. ir-keytable uses it.

The other explanation is that perhaps you didn't build and replace ir-keytable correctly.

But I see your using oneric, so it may have been fixed in that ubuntu build anyway. If you replaced the ir-keytable executable according to my instructions, try this to check if the oneric version is ok.

wstewart - you are spot on, checking the mce_rce file showed that it did not indeed have a "KEY_OK" mapping, and running the ir-keytable -c manually then running ir-keytable in test mode, showed that the OK button was indeed then responding as "KEY_ENTER"

Firing up XBMC and testing some buttons then yielded wonderful results, and it behaved exaclty as I had hoped.

So it appears as though my startup script is not persisting, I will follow that up and post back again .. thanks for your help, this is all becoming a lot clearer now.

Managed to sort it, beware, I am a complete Linux noob, so this may be very against Linux security standards etc ...

I was looking at the script, and copied the command into terminal window, when the penny dropped, I forgot, that a lot of your commands needed to be run as root, and often Id run a command and I would get a "you need to run this as root" type error .. when I pasted your script, it needed root privileges to run .. so I did some google trawling on how to run startup scripts as root .. and its working perfectly now.

For anyone else looking for a solution I created a file in /etc/init.d/ called "xbmc-ir-keytable"

jet-lee, glad you got it working. That is odd that the init script didn't work for you. Perhaps there is something different in oneiric compared to Natty.

I couldn't get the init.d script to work in Natty. My explanation was that with upstart it is difficult if not impossible to control the order in which the init.d scripts run compared to the upstart scripts.