2011-06-29, 20:00
2. Remote
So you have established that the receiver works. Now you have to have software that receives and interprets those IR signals. In the past, there was only LIRC. But as of Linux 2.6.36, functionality is being moved into the kernel (Kernel Newbies).
While this can potentially be very useful, it does seem to be at the root of the confusion of many people. This is perfectly understandable, as official documentation is very sparse.
The problem seems to be that the kernel now 'catches' all the events and does not let them through to LIRC. And sometimes LIRC also seems to get in the way of the kernel, especially when you've already configured lirc.
So basically LIRC and the in-kernel drivers interfere with each other. Note that I'm using LIRC 0.8.7 (Ubuntu Natty default) and according to the LIRC FAQ you need 0.9.0 with in-kernel drivers. So upgrading will most likely solve this problem, but if you don't feel like upgrading LIRC you can also do what I said before, which was to disable lirc entirely or let the kernel pass through all commands to LIRC.
I think it would also be possible to simply disable the kernel drivers by blacklisting all ir-* and rc-* modules, but I see no reason to do that instead of using passthrough.
In short, there seem to be three possible 'paths' that an incoming IR signal can go through:
2.1 Let the kernel pass the signal through to LIRC
The first one will allow you to follow the traditional LIRC guides. All you have to do is execute
You can add 'ir-lirc-codec' to /etc/modules and the ir-keytable command to /etc/rc.local (or equivalent) if you want to make it persistent.
This should allow irw to function as it has always done, so you can now use hardware.conf, lircd.conf and irrecord as described in the traditional lirc howtos.
If you choose this path, you probably won't be able to emulate keypresses and assign different actions to the same button (I think). You will have to use Lircmap.xml instead of keyboard.xml and the latter looks much more versatile (at least the vanilla ones).
So then the guide stops here and I suggest you follow a good guide about LIRC. I do however, recommend you to switch to the kernel drivers.
2.2 Do everything completely in-kernel
If you use the in-kernel functionality you will be able to easily emulate keyboard presses.
First, start by disabling LIRC. You can disable lirc semi-permanently by changing the START_LIRCD config value to false in /etc/lirc/hardware.conf. Or by simply uninstalling it. We're not going to need it any way. But first stop lirc, because when that variable is set to false, you can't stop or start lirc. Also stop XBMC for the time being, because you don't want your remote to do funny things with XBMC when it starts working.
Then, if you haven't got it-keytable installed yet, do it now and execute
You should see something like this:
The important line is the line "Supported protocols". Like the name says, it indicates which protocols are supported by your receiver. This is important, because your remote and your receiver will have to 'speak' the same protocol.
Based on the very little experience I have, I have found that RC5 (you can ommit the dash) is mainly used by TVs, RC6 by MCE remotes and NEC by most other remotes that are not Sony or JVC based. Apparently there can also be overlap between protocols. For instance, my Sony Bravia TV remote generates events for both RC5 and SONY.
So you may have to find out what protocol your remote 'speaks'. You could probably just select all of them and you'll most likely be fine, but it is also possible that you really have to pick the correct one.
In any case, execute
-c clears your mapping table if you already programmed one.
-p defines which protocols your IR receiver should listen to. Replace $protocols with a comma separated list of all your supported protocols. In my case that would be NEC,RC-5,RC-6,JVC,SONY,LIRC.
-t initiates the test mode. Think of it as the kernel version of irw.
Press some keys. You should now see something like this:
If one button generates two events with entirely different scancodes, your remote probably speaks two protocols, like my Bravia does. It looks like this:
The 1f3f scancode is useless, because it's always the same, no matter which button I press. You can test which protocol is the truly correct one by using ir-keytable again:
One by one you can test each protocol. In my case, when I set the protocol to RC5, it generates the 1f3f codes and when I set it to SONY, it generates the right ones. All the other protocols do not generate anything. So now I know that my Bravia remote uses SONY (duhh).
But like I said you can probably get away with just using all supported protocols at once. The 1f3f scancodes are harmful when left unconfigured.
By the way, once you've set the protocol(s) you wish to use you don't have to enter them again. At least not until you reboot. So from hereon you can simply use `ir-keyable -t` to test. The -c flag you'll only need when you want to reset the table.
So enter `ir-keyable -t` again and see if all your buttons are functional. It's possible not all of them are, but there's little you can do about that I'm afraid.
Now the part that MAY require the most work. You are now capable of generating events, but they have yet to be connected to a certain key press. If you have a common remote, such as the famous MCE remote, it could be as simple as using the right config file (let's say a lircd.conf for ir-keytable). Execute the following command to see the included config files:
If you see anything resembling the remote your wish to use with XBMC, you may be lucky. But let's find out for sure. You could be browsing through all these files manually, but this is *NIX, so there's a command for that. Enter `ir-keyable -t` again and press a standard button, such as the ok, up or down. Then copy the resulting scan code and execute the following command:
For instance, if you get "1309375577.020898: event MSC: scancode = 1e14", execute
The result could be something like:
So that means either file could be appropriate. Compare this file against more scancodes to be sure. If you're lucky, your remote has a preconfigured config file and you can largely skip the next few steps about creating a custom config file. However, in order to map different XBMC actions to one button depending on the context in which this button is pressed, you will have to make modifications. For that, read through part III & IV first. After the section about creating a custom config file you will be able to find how to load this config file into the memory. And do not modify the files in /lib/udev/rc_keymaps, but copy the appropriate file to /etc/rc_keymaps/.
So you have established that the receiver works. Now you have to have software that receives and interprets those IR signals. In the past, there was only LIRC. But as of Linux 2.6.36, functionality is being moved into the kernel (Kernel Newbies).
While this can potentially be very useful, it does seem to be at the root of the confusion of many people. This is perfectly understandable, as official documentation is very sparse.
The problem seems to be that the kernel now 'catches' all the events and does not let them through to LIRC. And sometimes LIRC also seems to get in the way of the kernel, especially when you've already configured lirc.
So basically LIRC and the in-kernel drivers interfere with each other. Note that I'm using LIRC 0.8.7 (Ubuntu Natty default) and according to the LIRC FAQ you need 0.9.0 with in-kernel drivers. So upgrading will most likely solve this problem, but if you don't feel like upgrading LIRC you can also do what I said before, which was to disable lirc entirely or let the kernel pass through all commands to LIRC.
I think it would also be possible to simply disable the kernel drivers by blacklisting all ir-* and rc-* modules, but I see no reason to do that instead of using passthrough.
In short, there seem to be three possible 'paths' that an incoming IR signal can go through:
- Let the kernel pass the signal through to LIRC
- Do everything completely in-kernel
- Let the kernel cooperate with LIRC
2.1 Let the kernel pass the signal through to LIRC
The first one will allow you to follow the traditional LIRC guides. All you have to do is execute
Code:
modprobe ir-lirc-codec
ir-keytable -p LIRCYou can add 'ir-lirc-codec' to /etc/modules and the ir-keytable command to /etc/rc.local (or equivalent) if you want to make it persistent.
This should allow irw to function as it has always done, so you can now use hardware.conf, lircd.conf and irrecord as described in the traditional lirc howtos.
If you choose this path, you probably won't be able to emulate keypresses and assign different actions to the same button (I think). You will have to use Lircmap.xml instead of keyboard.xml and the latter looks much more versatile (at least the vanilla ones).
So then the guide stops here and I suggest you follow a good guide about LIRC. I do however, recommend you to switch to the kernel drivers.
2.2 Do everything completely in-kernel
If you use the in-kernel functionality you will be able to easily emulate keyboard presses.
First, start by disabling LIRC. You can disable lirc semi-permanently by changing the START_LIRCD config value to false in /etc/lirc/hardware.conf. Or by simply uninstalling it. We're not going to need it any way. But first stop lirc, because when that variable is set to false, you can't stop or start lirc. Also stop XBMC for the time being, because you don't want your remote to do funny things with XBMC when it starts working.
Then, if you haven't got it-keytable installed yet, do it now and execute
Code:
ir-keytableYou should see something like this:
Code:
Found /sys/class/rc/rc0/ (/dev/input/event2) with:
Driver mceusb, table rc-rc6-mce
Supported protocols: NEC RC-5 RC-6 JVC SONY LIRC
Enabled protocols: NEC RC-5 RC-6
Repeat delay = 500 ms, repeat period = 33 msThe important line is the line "Supported protocols". Like the name says, it indicates which protocols are supported by your receiver. This is important, because your remote and your receiver will have to 'speak' the same protocol.
Based on the very little experience I have, I have found that RC5 (you can ommit the dash) is mainly used by TVs, RC6 by MCE remotes and NEC by most other remotes that are not Sony or JVC based. Apparently there can also be overlap between protocols. For instance, my Sony Bravia TV remote generates events for both RC5 and SONY.
So you may have to find out what protocol your remote 'speaks'. You could probably just select all of them and you'll most likely be fine, but it is also possible that you really have to pick the correct one.
In any case, execute
Code:
ir-keytable -c -p $protocols -t-c clears your mapping table if you already programmed one.
-p defines which protocols your IR receiver should listen to. Replace $protocols with a comma separated list of all your supported protocols. In my case that would be NEC,RC-5,RC-6,JVC,SONY,LIRC.
-t initiates the test mode. Think of it as the kernel version of irw.
Press some keys. You should now see something like this:
Code:
1309368621.558360: event MSC: scancode = 45b580
1309368622.010326: event MSC: scancode = 45b581
1309368622.465330: event MSC: scancode = 45b551
1309368622.966319: event MSC: scancode = 45b54d
1309368623.814289: event MSC: scancode = 45b522
1309368624.285272: event MSC: scancode = 45b584
1309368625.009254: event MSC: scancode = 45b5de
1309368625.569238: event MSC: scancode = 45b520
1309368626.643231: event MSC: scancode = 45b501
1309368627.080215: event MSC: scancode = 45b502
1309368627.483210: event MSC: scancode = 45b503If one button generates two events with entirely different scancodes, your remote probably speaks two protocols, like my Bravia does. It looks like this:
Code:
1309368864.058322: event MSC: scancode = 1f3f
1309368864.058344: event MSC: scancode = 97008a
1309368864.109318: event MSC: scancode = 1f3f
1309368864.109340: event MSC: scancode = 97008a
1309368864.159316: event MSC: scancode = 1f3f
1309368864.159337: event MSC: scancode = 97008a
1309368866.089281: event MSC: scancode = 1f3f
1309368866.089305: event MSC: scancode = 97008f
1309368866.145265: event MSC: scancode = 1f3f
1309368866.145287: event MSC: scancode = 97008f
1309368866.178268: event MSC: scancode = 1f3f
1309368866.178288: event MSC: scancode = 97008f
1309368866.682269: event MSC: scancode = 1f3f
1309368866.682293: event MSC: scancode = 970090
1309368866.733263: event MSC: scancode = 1f3f
1309368866.733286: event MSC: scancode = 970090
1309368866.783262: event MSC: scancode = 1f3f
1309368866.783288: event MSC: scancode = 970090The 1f3f scancode is useless, because it's always the same, no matter which button I press. You can test which protocol is the truly correct one by using ir-keytable again:
Code:
ir-keytable -c -p $proto -tOne by one you can test each protocol. In my case, when I set the protocol to RC5, it generates the 1f3f codes and when I set it to SONY, it generates the right ones. All the other protocols do not generate anything. So now I know that my Bravia remote uses SONY (duhh).
But like I said you can probably get away with just using all supported protocols at once. The 1f3f scancodes are harmful when left unconfigured.
By the way, once you've set the protocol(s) you wish to use you don't have to enter them again. At least not until you reboot. So from hereon you can simply use `ir-keyable -t` to test. The -c flag you'll only need when you want to reset the table.
So enter `ir-keyable -t` again and see if all your buttons are functional. It's possible not all of them are, but there's little you can do about that I'm afraid.
Now the part that MAY require the most work. You are now capable of generating events, but they have yet to be connected to a certain key press. If you have a common remote, such as the famous MCE remote, it could be as simple as using the right config file (let's say a lircd.conf for ir-keytable). Execute the following command to see the included config files:
Code:
ls /lib/udev/rc_keymaps/If you see anything resembling the remote your wish to use with XBMC, you may be lucky. But let's find out for sure. You could be browsing through all these files manually, but this is *NIX, so there's a command for that. Enter `ir-keyable -t` again and press a standard button, such as the ok, up or down. Then copy the resulting scan code and execute the following command:
Code:
grep -iH $scancode /lib/udev/rc_keymaps/*For instance, if you get "1309375577.020898: event MSC: scancode = 1e14", execute
Code:
grep -iH 1e14 /lib/udev/rc_keymaps/*Code:
/lib/udev/rc_keymaps/dib0700_rc5:0x1e14 KEY_UP
/lib/udev/rc_keymaps/haupp:0x1e14 KEY_UPSo that means either file could be appropriate. Compare this file against more scancodes to be sure. If you're lucky, your remote has a preconfigured config file and you can largely skip the next few steps about creating a custom config file. However, in order to map different XBMC actions to one button depending on the context in which this button is pressed, you will have to make modifications. For that, read through part III & IV first. After the section about creating a custom config file you will be able to find how to load this config file into the memory. And do not modify the files in /lib/udev/rc_keymaps, but copy the appropriate file to /etc/rc_keymaps/.
