« Previous -
Version 9/39
(diff) -
Next » -
Current version
christian, 01/01/2015 03:31 pm
Background¶
LinHES 7 introduced a number of changes to the way remotes and associated devices are handled. This is largely being picked up from changes in the Linux base. The way remotes are now handled is significantly different and also requires a different tool set to build and diagnose an implementation. In general this new implementation is a significant improvement in what was previously a rather adhoc structure.
This guide will attempt to introduce you to the new architecture and tool sets relevant to LinHES.
Architecture¶
The following picture is a logical representation of how various blocks in LinHES are connected.
As of LinHES 7, the remote drivers are included in the kernel whereas previously they were part of the lirc subsystem. If Lircd is not running then by default the Remote Driver will issue keyboard and/or mouse events. These events will be seen by higher level applications such as X and MythTV as if normal keyboard and mouse events occurred. Thus if you do not require certain lirc functions such as irexec then you can quite happily not use lirc at all. Note, some remotes actually do issue mouse events such as certain imon remotes.
Remote Receiver¶
Each Remote Receiver will be identified by a unique device ID which will be associated by a driver that recognizes that ID. In most cases this should automatically make the needed associations. In some rare cases more than one driver may try to associate with the device which can cause conflicts. In these exceptional cases, this device can be blacklisted from the driver or the driver itself can be blacklisted.
The device ID can normally be found using tools such "lsusb" where you may see an entry similar to:
Bus 003 Device 002: ID 15c2:0043 SoundGraph Inc.
Remote Driver¶
The driver does not actually know about the remote, it only sees the IR codes received by and translated by the Remote Receiver. The Remote Receiver may use any number of protocols (e.g. RC6, imon, etc) and its associated driver will normally understand all of the protocol variants that the Remote Receiver supports.
The Remote Driver will interact with the Remote Receiver in order to maintain the device and of course receive information from the remote itself. Depending on the Remote Receiver and associated Remote, the driver may separate the events as keyboard and mouse events. In this case you may see entries in "/dev/input/by-id" with entries such as "usb-15c2_0043-event-if00" and "usb-15c2_0043-event-mouse". Note in customization it is generally safer to specify a driver using its "/dev/input/by-id" path rather than the "/dev/input" path.
ir-keytable¶
ir-keytable interacts with the driver and normalizes its output. It utilizes a keymap file normally found in "/etc/rc_keymaps" and the default association with the driver will be defined by "/etc/rc_maps.cfg"
There are a number of things that you can do with ir-keytable including:- Identify the driver and its protocols (eg. ir-keytable)
- Monitor the driver output of received events from the Remote Receiver (eg. ir-keytable -t)
- configure the driver for items such as protocols (eg. ir-keytable -p RC6, LIRC, etc)
- Load a specific or custom keymap for a driver (eg. ir-keytable -w /etc/rc_keymaps/imon_mce)
For example, in one of my systems ir-keytable returns:
# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event7) with:
Driver imon, table rc-imon-pad
Supported protocols: RC-6 other
Enabled protocols: RC-6
Repeat delay = 500 ms, repeat period = 33 ms
I also force my imon receiver to use the RC6 protocol and the imon_mce keytable instead of the default imon protocol and imon keymap using:
/usr/bin/ir-keytable -c -p RC6 -w /etc/rc_keymaps/imon_mce
Tools¶
Mode2 is no longer relevant.
