few weeks ago I added Digimatrix IR remote to my system - at that time I changed RemoteMapping table to remap keys on that remote. Now my problem is that some keys aren't remapped properly to fully support Orbiter and Mythtv.... I'd like to add proper remappings to it to work properly.

- what is currently content of RemoteMapping in Pluto distro ? I'd like to synhronize with that and add changes that are needed to fully support Digimatrix remote...

- any example of mapping that works for remote (including Mythtv's more exotic functions like Menu, Info, etc...) ?

the screen type is in the DesignObj table. for example, if you monitor the log for the orbiter, and change to the main menu, you'll see in the log 'render screen 1255.0.0'. the first number is always the screen number, or we call the DesignObj. In mysql, select * from DesignObj where PK_DesignObj=1255, will let you see the screen type for that object.

the way the remote function works is to always try to find the most specific, reverting to least specific match. There are two criteria, one is the type of remote, and one is the screen type. Some remotes do not have the same button layouts as others. For example, some remotes share the four directional arrows with media skipping. Similarly on some screens, you wanna have different buttons do different things. For example when a the orbiter is at the screen 'DVD menu', you want the up down left right to go to the media player, but when the orbiter is that the main menu, the arrows go to the orbiter itself.

all this functionality is shared in one common base class IRReceiverBase, which is used by all of the infrared receivers. This has a logic to say: i'm on screen 1255, the remote being used is type X, is there a button for that screen and that type of remote. If not, is there a button for that type of remote. If not, for that type of screen. If not, just send the general command.

by the general commands, i mean the record in RemoteMapping where both screentype and remotelayout are not specified.

you have a few options. If what you're doing is general and you feel benefit everyone with every type of remote, or if the buttons on this particular remote are unique to this remote, or if the special buttons on this remote should have the same behavior on any other remote that has a special buttons, then we should put the new commands in a record without remotelayout; in other words everyone with any remote that has that button should get that same behavior. If your remote is something unusual and special, and this particular remote should do something different than another remote that has the same button with the same name, then you'll want to change the remote layouts in the device template for the remote, and add a special recordto the remote mapping to specify the behavior for that type of remote.Use sqlcvs to commit sure changes, and send an e-mail to kirill.b to have them authorized, and he can confirm that they make it into the next release.