Control LinuxMCE using an Infrared remote

Version	Status	Date Updated	Updated By
710	Unknown	N/A	N/A
810	Unknown	N/A	N/A
1004	Unknown	N/A	N/A
1204	Unknown	N/A	N/A
1404	Unknown	N/A	N/A
Usage Information

How to set it up

• In LinuxMCE Admin Website-->Wizard-->Devices-->Media Directors, choose the type of Infrared Receiver you have from the pull-down. The list of choices includes LIRC drivers. Most users can use the "default" driver.
• Add the "Infrared remote controls you will use". You can have as many as you want. LinuxMCE Admin will then add an Infrared Receiver device and a device for each remote control you add.
• Wizard-->Restart-->Quick Reload Router to reload all device descriptions in the router.

How to use it

A Media Director displays an on-screen Orbiter User Interface with a menu of buttons (which appears similar to the interface seen on webpads and PDAs). The button functions on the infrared remote control are context-sensitive. Sometimes the buttons control the Media Director's on-screen Orbiter, and sometimes the buttons control the media device you're using.

Here's an example. Let's say your Media Director controls your satellite TV box as well as a regular DVD player. The satellite TV control, the DVD player, and the Media Director all have infrared sensors. You have a universal remote control which you added to LinuxMCE as described above.

The on-screen Orbiter is visible on the TV. As you hit the up/down/left/right/enter buttons on the remote you will see that you can select the menu options on the Orbiter. You select the button to watch "Satellite TV", and the TV appears.

Now when you hit up/down/left/right/enter LinuxMCE knows you obviously want to control the satellite TV box. So, when you press those buttons LinuxMCE translates the infrared codes into ones that your satellite TV box understands, and the same arrows on the remote control will now control the satellite TV.

You hit 'Power Off', and the satellite box shuts off. Now the Orbiter's menu is again visible. The arrows will again control the Orbiter.

You choose the button to watch a DVD in your DVD Player. Now the same arrows will control the DVD player. When you hit pause the DVD player will pause (even though using the LinuxMCE remote instead of the DVD remote.

LinuxMCE translates everything for you so you don't have to juggle remote controls. If you again hit power, the DVD turns off. Hit power again and the the TV shuts off. Hit power a third time and the Media Director turns off.

This is even better than a universal remote control since you don't need to tell it what device you want to control -- LinuxMCE figures it out on its own.

Although you can use all sorts of remote controls (all with different buttons), they will control LinuxMCE in a consistent manner. The media-specific buttons, like rewind/fastforward/ play/pause, will always control whichever media device you are currently using (no matter what screen is visible on the on-screen Orbiter). Navigation buttons, like up/down/left/right/enter and the 10-key number pad, will control the currently active media device (as long as the on-screen Orbiter is showing the remote control menu for that device). Otherwise it controls the on-screen Orbiter. When the main menu is visible on the Orbiter, you can select scenarios with the up/down/left/right/enter buttons (or the 10-key pad).

To use the 10-key pad, choose the type of scenario you want. The categories are numbered: 1=Lighting, 2=Media, 3=Climate, 4=Telecom, 5=Security, 6=Misc. Thus, 22 on the remote will start TV (2=Media category and TV is the 2nd option in the category).

Programmer's Guide

• Read the How To Use It section (above) first.

As you can see, LinuxMCE provides a highly intelligent interpretation of infrared remote buttons, that automatically change their function based on what the user is doing, what type of remote control layout exists, and where the infrared codes are going. If you have ever worked with infrared remote controls, such as LIRC, you know that there is no standard, and all the remote controls have different buttons with different names. Therefore we had to create a database structure that allows for interpreting the different button names into commands which can change depending upon the context and the layout of the remote.

The DCE Devices (i.e. the LinuxMCE binary that handles I/R reception) are specified in the category Peripherals-->Infrared Receivers.

In LinuxMCE Admin Website-->Advanced-->Configuration--> Device Templates, you can see the categories and devices in them. There is a separate folder for the LIRC drivers. In addition to a device for the I/R receiver, there is also a device for the I/T remote. The remote controls are of the type Peripherals --> Remote Controls. Since the definition of the infrared codes for a remote control is stored within the remote control device, and that definition varies depending upon the type of receiver, you will see that there is a separate subcategory for each type of receiver.

For example there is a folder "LIRC Remote Controls" that has all of the remote controls and definition files for the LIRC project. We also created our own DCE devices for other infrared receivers, such as IRTrans and Tira. Although these are supported within the LIRC project, we found that we had better control and greater accuracy when we used the native SDKs for these receivers. So, for example, if you have an IRTrans receiver, and an XPMC remote, you have two possibilities. First you could add the LIRC receiver device, and the XPMC remote device that is within the LIRC remote category. In this case the remote control will be using an LIRC config file. Secondly you could add LinuxMCE's native IRTrans receiver device, and then pick the XMPC remote device that is within the IRTrans remotes category, which stores the button codes in a different format, that is in IRTrans' native format. When you are adding your infrared receiver and remote control using the LinuxMCE Admin Wizard/Devices/Media Directors page, the wizard automatically ensures that when you add a remote control it is the correct category.

For each remote control there is a device data "#59 Configuration" which has the remote controls configuration file (which defines the infrared codes each button will send, and gives each code, or button, a name). The XPMC remote within the LIRC category has a device data #59 that is the LIRC config file. The XPMC remote within the IRTrans category has a device data #59 that has the same button codes, but in IRTrans format.

When the framework starts an IR receiver device, in general this device will first scan for sister devices within the category remote control (and will then write out a configuration file). For example, when LIRC_DCE runs it finds all LIRC remote controls on that machine, grabs the device data "#59 Configuration" for every one of them and writes that out to a lirc.conf file. It then starts LIRC.

The logic is in a base class called IRReceiverBase. LinuxMCE's infrared receiver devices all use this same base class. So the actual code that is specific to each type of receiver is very small, usually around 20 lines. It only needs to write out the configuration file at start up, and then call the member function ReceivedCode within IRReceiverBase when a button is pushed. This function takes the name of the button as a parameter, and converts this into a message.

Since all receivers use a common base class to handle the logic, that means that the translation between buttons and actions is also in a shared database. It does not matter whether you are using LIRC or some other infrared receiver, the translation is the same. There is no unified standard for what the buttons are called. The button "SkipFwd" may be called "Fwd", "Skip+", "Jump->", etc. The table RemoteMapping in the main mysql database, pluto_main, has a field Mapping which lists all the button aliases, followed by the command to be executed when any of those buttons is pushed. For example: chup;skipfwd;ChanUp;SkipNext;|0 -106 1 65 5 +1

Whenever any infrared receiver reports any of those button presses, the message "0 -106 1 65 5 +1" gets triggered. The format of the message is the same as if you typed it with the MessageSend utility: i.e. from device, to device message type, message id, followed by parameters.

If the user presses a button called ChanUp, a message will be sent to device -106 (media plugin) of type 1 (command) id 65 (Jump Position In Playlist) with parameter 5 (Value To Assign) set to "+1". This table is shared betweem all LinuxMCE users, and is updated every time your system upgrades versions. If you make your own manual changes to this table, then the next time your core upgrades it will not upgrade the rows in that table that you modified. SQL CVS does not, by default, overwrite your local changes with global ones.

Therefore, if you have a new remote control with some new buttons that we have not yet mapped, it is recommended that you e-mail us or post us a message in the forum, with the button name and the message and then we can add it to our master database and then your system can remain in sync with other users enhancements. If you want to do some mapping that is just for you, you can change the table and know your changes will not be overwritten.

Note that the RemoteMapping table has 2 optional fields: ScreenType and RemoteLayout. When the IRReceiverBase base class is deciding which message to send in response to abutton press, it first looks for a more specific entry where the screen type matches the type of screen currently visible on the orbiter, and the remote layout matches the layout. The on-screen Orbiters regularly send messages to the infrared receiver telling them what type of screen is currently visible, using the following codes: M=Main Menu, m=other menu, R=LinuxMCE Remote, r=Non-LinuxMCE remote, F=File Listing. This allows for buttons to behave differently depending upon what type of screen is visible.

For example, when the main menu is visible, the arrows on a remote control should send a message to the on-screen Orbiter to move the highlight pointer around on the screen. However, when the user is controlling an external piece of AV equipment, like a DVD player, the arrows should pass through to the DVD player so the user can control its own on-screen menu. Also the type of functionality can vary depending upon the layout of the remote.

For example, Bang & Olufsen remotes are quite simple: there is only a single up/down/left/right button which is used both to navigate on-screen menus as well as to handle rewind fast-forward and skip. Other remotes have dedicated arrows and media navigation buttons. So, one remote layout can be created for Bang & Olufsen-style remote, where the arrows control the menu when there is a menu on screen, and adjust the media when there is not. The remote layout is a device data "#110 Remote Layout" stored with the remote control

When IRReceiverBase looks for a mapping it first looks for records that match the current screen type and remote layout, and then revert to standard records (i.e. ScreenType and RemoteLayout are null) only if there are no matching results.

See also: Add support for new remote controls