ir-keytable or: How I Learned to Stop Worrying about the LIRC Kernel

This is for kernel's 2.6.35+ and LIRC 0.9.0 and above.

Foreword: I've put off upgrading from Lucid because of the cluster that was LIRC in Kernel (and have not been shy about it). After Natty... I'm not happy about Natty, I'm going back to what every thing else in my house runs. A good proper Debian system. I've finally bit the bullet and started to figure out how to deal with LIRC in the Kernel, because it's not going away. Turns out, its just a little bit of awesome (and a whole lot of work.)

First you're going to need ir-keytable. It's available in natty (not maverick) and Sid & Testing.
apt-get install ir-keytable. ir-keytable turns ... I'm not really sure what ir-keytable really does. But it turns remote presses into LIRC stuff.

This is the flow chart of fun. I'll try and work on this in order.
lirc kernel -> ir-keytable mapping -> LIRC devinput -> lircmap.xml -> remote.xml.

Do not install LIRC yet. Un-install it if you have it. Right now we're going to be futzing without it.

Running ir-keytable by itself will dump out what IR receiver it recognizes in addition to what protocols it supports. I have a real HP receiver & Remote (ID 045e:006d Microsoft Corp. eHome Remote Control Keyboard keys)

RC5/6 are the IR protocols defined by Philips.
NEC aka "Japanese Format" are by NEC. This is the bread and butter protocol as most remotes use this. (At least in my house hold my Yamaha receiver and Samsung TV both use it.)
Sony. Sony ALWAYS does their own thing... I don't have anything in my house that uses this.
JVC. JVC has their own too.
--
First, You're going to be making a hex -> LIRC button name file for each of your remotes. I have 3. MCE Remote, Yamaha Receiver Remote & TV Remote.

The MCE Remote should already be mostly mapped, but if you try to standardize something as non-standard as remotes, you're bound to get a few wrong. Inside of /lib/udev/rc_keymaps/, there should be an rc6_mce. Copy that to /etc/rc_keymaps/, we're going to be editing that instead of creating a brand new file.

1) Open up my dump of valid LIRC keys: http://xbmc.exstatic.org/ir_keys.txt. You can use your own, but these are "standard". These are the names we'll be working
2) I'm opening text files on my laptop for each remote then scping them over. You can edit directly in nano. You can export the /etc/rc_keymaps/. You can use butterflies if you like
3) Run "ir-keytable -c" to clear out the old table. Fire up "ir-keytable -t". If you'd like to think of this as the new "irw", you can. (If you're running LIRC, you didn't follow the directions and you have to at least stop it before running ir-keytable.)

"ir-keytable -t/--test" shows you what is being pressed. This is where the slight bit of awesome comes in. irrecord would NOT record some buttons for me, TV up down. This literally shows me something every time I press the remote. Even weird keys like +10. All of my TV commands, etc.

4) First we're going to go through our rc6 remote and 'correct' any keys that are funky. For example the "Start" key on my remote is KEY_PROG1, I want to change it to KEY_HOME.

5) Repeat this for every remote you want to program. For my Yamaha remote "XBMC" is going to be the DVD button. When I press it on remote the receiver swaps to the correct HDMI and SPDIF in. So when I press the DVD button, it'll now control my XBMC.

Down, Up, Left, Right, Select, Keys 1-0.

I'm personally doing this in TextMate and then just copying it to ssh. The scan codes are in hex. So right now it looks like this:

The first line of the file, best I can figure, MUST look like this:

Again, it's not really documented. But if it didn't look like this, it threw a fit.

6) Edit /etc/rc_maps.cfg ... To what. I really don't know right now. I have no @#)(* clue how it works or what it does.

Right now I'm loading each of the files individually.

Now when you run 'ir-keytable -t' you should see each of the buttons mapped.
You need to specify the protocol otherwise it'll drop one of them based on the rc_keymaps.

7) NOW you can install LIRC. Edit /etc/lirc/hardware.conf so that

To determine where the input device is mapped just do an 'ls' of /dev/input/by-id/. It should be fairly obvious which one it is. If it's not obvious, unplug everything else until your receiver is the only thing left.

Edit /etc/lirc/lircd.conf so that it looks like this:

Fire up lirc. Now when you run irw, you should see the output of each of your remotes, except they're all channeled as devinput.


8-n) From here on out, you're on your own. Read up on LIRC and lircmap.xml

Problems as of now: I literally have no clue WTF rc_maps.cfg does or how to use it. For some crazy reason if LIRC starts in init.d like it should, it won't work. I always have to restart it. So right now, my rc.local looks like this:

All 3 of my remotes work on reboot, and that's better than they used to.

No bug here. Just me being special. Carry. on.

Thank you! I've been scratching my head trying to understand how the change fom the external LIRC module to in-kernel LIRC driver works, and how I could get my remotes working without relying on LIRC.

In my trials I found a couple of things. I think the in-kernel LIRC reads the standard hardware.conf, which specifies devinput as the driver amongst other things. It then turns the scancodes from the remote into keycodes using the ir-keytable mapping. I think these are passed as actual keystrokes so Lircmap.xml and remote.xml never factor into it and I keyboard.xml does the translation.

I think this because none of the changes I was making to Lircmap.xml were having any effect. So I turned on key logging in XBMC, assigned a standard key (M) to a button on my remote using ir-keytable, then pressed it and the M key on my keyboadr. Both show up in the log just the same.

The upshot is that you can assign any KEY_NAME to any button and as long as it's key code is less than 255 it'll work in XBMC. No more futzing around with xml files.

I've now uninstalled Lirc and everything still works just fine.

Caveat: I'm new to XBMC and LIRC, so my conclusions could be very wrong, but I don't think they are

"In Kernel" LIRC reads nothing. It just "is" It's like a keyboard.

hardware.conf tells the standalone lirc program that it should be looking at devinput instead of one of the normal kernel.

And do you have a real deal MCE remote? Because it sounds like you have a fax knockoff where the remote actually does show up like a keyboard and just sends key presses.

Fair enough. So I should be able to delete hardware.conf and lircd.conf?

I've actually got two remotes. One's a Harmony 525 set to emulate an MCE remote, the other is a cheap knock off I bought for the receiver. It's branded HP but shows up as a Fintek (lsusb). Both remotes behave the same.

Is there anyway to tell if the remote is being treated as a keyboard?

In xbmc_dharma_10 ( Ubuntu) in the xbmc.log was key id:
In xbmc_eden_11 debug xbmc.log :

How do I edit keyboard.xml in xbmc_eden on key id?
I was looking for an answer here https://github.com/xbmc/xbmc/tree/master/xbmc/input, but did not find

Are you able to have lirc working if you suspend the pc and resume it?

thnak you

L.

lupick: yep, problems after resume. I just tested it. Tried dumping the kernel modules and reloading them, everything. Probably just another bug from the merge.

bsp134: They're just dumped in hex now. Why they didn't prefix it with 0x you'll have to ask the devs.

lupick: My remotes work after suspend/resume using the in kernel LIRC.

any ideas
its the xbox DVD remote btw, I hate that every single update of ubuntu breaks everything just to add some new stuff that's not needed but what ya gonu do :/