Eventlircd translated key presses of kernel input devices ^[20] into Lirc key presses. Basically, this is similar to the function of the remote plugin, with the exception that only these keys are assessed, where a keymap ^[21] is available.

These input devices are e.g. regular keyboards or also remote controls, which are registered as a keyboard by their driver. Other remote controls that are attached to DVB adapters register themselves partially as keyboards, too. Finally, there is an new interface for remote controls which is called rc-core. Jarod Wilson ^[22] ported already most of the existing Lirc drivers as well as some drivers for remote controls connected to DVB adapters to this new interface. Although this interface is not a regular keyboard driver, it registers those devices as kernel input devices.

Inputs from pointer devices (such as mice, touchpads, tablets) are also attached to the input interface. In these cases, eventlircd will forward them without further processing (unless the are remapped to a key event).

Eventlircd recognizes input devices via an udev-attribute, even when a daemon attaches them after the start of the system. This is a one of the greatest advantages of this solution: eventlircd provides a lirc socket for the VDR when it starts, while the input devices are attached afterwards as soon they are recognized.

Eventlircd recognizes the devices in its field of responsibility by attributes that can assigned to the devices during its initalization. This is done by udev rules. For some devices, this is already working in the standard configuration (devices managed by rc-core, devices that are used by yaVDR developers, or also community contributed configurations that were given to the yaVDR team). From the application point of view, the output of eventlircd looks as if it would come from one single input device.

Since some devices can definetely recognized (e.g. USB devices), the proper configuration can be attached via udev rules. The configurations fo all these devices can be stored on your system at the same time because udev activates the configuration only for attached devices.

A translation table can (depending on device and/or driver) be passed to eventlircd to customized the key layout (so called evmaps).

You can instruct Lircd ^[23] via the switch ^[24] --uinput ^[25] to direct its key presses to an device underneath /dev/input/. Thus, lircd can be used together with other input devices. In theory, it is even possible to start multiple lircd instances for different input devices with different configuration at the same time. For USB lirc receivers, an udev rule in /lib/udev/rules.d/98-lircd.rules and the lircd_helper, an instance of the lirc daemon is started, and the drivers and lircd.conf files that specified in the udev rule are used. For these devices, no further configuration via the web interface is required. If there are any lirc receivers that do not work out of the box, the appropriate udev rules have to be created manually.

	Bug when using --uinput
	Sadly, recent lirc version are suffering from a bug when forwarding key presses in combination with --uinput. This results in doubled key presses at the event device (Instead, the key presses at the real lircd socket are ok!). Thus, yaVDR 0.5 facilitates lircd2uinput, to forward key presses from lirc sockets to eventlircd.

	All roads lead to eventlircd
	As shown in the graphics above, depending on the driver and the receiver device or DVB adapter, a keypress can be routed totally different paths until it is processed by eventlircd. This background information is important when eventlircd creates signals that do not match the standard key names specified in the remote.conf file of yaVDR.

The developers referenced the documentation on linux-media (table at the end of page) for the standard layout of yaVDR. The mapping of VDR keys and key names is documented here: new IR integration for yaVDR 0.4

	When are evmaps useful?
	evmaps should only be created for devices where no other option to tweak key names exists. For lirc and rc-core devices, it is preferred to create an appropriate configuration file (either lircd.conf or keymap) for the proper mapping of the buttons.

All key presses that are passed to eventlircd can be modified by translation tables, the so called evmaps ^[26], before they are directed to the VDR. They are located underneath /etc/eventlircd.d/. They are either named by device name, driver or by product- and vendor ID from their udev rule.

Example for the syntax in an evmap: 

KEY_PROG1       = KEY_MENU #I am a comment

In this example, The key event KEY_PROG1 is renamed. VDR will receive the Lirc event KEY_MENU

A first overview whether a receiver is recognized is provided by listing all kernel input devices of the system: 

cat /proc/bus/input/devices

This lists all input devices that have a device node registered underneath /dev/input/. USB lirc receivers that are automatically configured, or for the lirc devices that were configured via the web frontend don’t have a dedicated entry. They can be recognized by the line N: Name="lircd".

Below is an example with multiple input devices:

user@yaVDR:~$ cat /proc/bus/input/devices

Power button at the case. 

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=PNP0C0C/button/input0
S: Sysfs=/devices/LNXSYSTM:00/device:00/PNP0C0C:00/input/input0
U: Uniq=
H: Handlers=kbd event0
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

I: Bus=0019 Vendor=0000 Product=0001 Version=0000
N: Name="Power Button"
P: Phys=LNXPWRBN/button/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
U: Uniq=
H: Handlers=kbd event1
B: PROP=0
B: EV=3
B: KEY=10000000000000 0

Attached keyboards. 

I: Bus=0011 Vendor=0001 Product=0001 Version=ab41
N: Name="AT Translated Set 2 keyboard"
P: Phys=isa0060/serio0/input0
S: Sysfs=/devices/platform/i8042/serio0/input/input2
U: Uniq=
H: Handlers=sysrq kbd event2
B: PROP=0
B: EV=120013
B: KEY=402000000 3803078f800d001 feffffdfffefffff fffffffffffffffe
B: MSC=10
B: LED=7

directly attached remote contol (here: Hama MCE Remote with keyboard and mouse function). 

I: Bus=0003 Vendor=05a4 Product=9881 Version=0110 
N: Name="HID 05a4:9881"
P: Phys=usb-0000:00:02.0-2/input0
S: Sysfs=/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.0/input/input3
U: Uniq=
H: Handlers=sysrq kbd event3 
B: PROP=0
B: EV=120013
B: KEY=e080ffdf01cfffff fffffffffffffffe
B: MSC=10
B: LED=7

I: Bus=0003 Vendor=05a4 Product=9881 Version=0110 
N: Name="HID 05a4:9881"
P: Phys=usb-0000:00:02.0-2/input1
S: Sysfs=/devices/pci0000:00/0000:00:02.0/usb2/2-2/2-2:1.1/input/input4
U: Uniq=
H: Handlers=kbd mouse0 event4 
B: PROP=0
B: EV=17
B: KEY=1f0000 2020000 3878d801d001 1e000000000000 0
B: REL=103
B: MSC=10

Eventlircd. 

I: Bus=0003 Vendor=05a4 Product=9881 Version=0110
N: Name="eventlircd"
P: Phys=/dev/input/event4
S: Sysfs=/devices/virtual/input/input5
U: Uniq=
H: Handlers=mouse1 event5
B: PROP=0
B: EV=7
B: KEY=10000 0 0 0 0
B: REL=3

This input device is always present while eventlircd is running. It is a virtual input device that gathers all key presses of the connected and receivers and forwards themo the VDR.

rc-core receiver. 

I: Bus=0018 Vendor=0000 Product=0000 Version=0000
N: Name="i2c IR (Hauppauge WinTV PVR-350"
P: Phys=i2c-2/2-0018/ir0
S: Sysfs=/devices/virtual/rc/rc0/input6 
U: Uniq=
H: Handlers=kbd event6
B: PROP=0
B: EV=100013
B: KEY=108fc010 2468d100000000 0 18000 18040002801 8e168000000000 ffe
B: MSC=10

Lirc device with --uinput. 

I: Bus=0000 Vendor=0000 Product=0000 Version=0000
N: Name="lircd"
P: Phys=
S: Sysfs=/devices/virtual/input/input7
U: Uniq=
H: Handlers=sysrq rfkill kbd event7
B: PROP=0
B: EV=100003
B: KEY=ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff ffffffffffffffff fffffffffffffffe

The following command prints the mapping of scan codes and key names for a given receiver. This is especially useful when a keymap is loaded, while the naming of the buttons does not comply with the naming convention.

sudo ir-keytable -r

With ir-keytable, you can determine key codes of the remote control, e.g. to verify whether or not key presses are recognized at all, or to create a keymap that fits to the file /vdr/lib/vdr/remote.conf from yaVDR. Since eventlircd captures key presses, you have to stop this service before. Also, it is recommended to stop the VDR upfront, to avoid unintented use of it.

example output without loaded keytable. 

user@yavdr:~$ sudo ir-keytable -t
Testing events. Please, press CTRL-C to abort.
1310546299.271540: event MSC: scancode = 3d
1310546300.071543: event MSC: scancode = 3b
1310546301.471538: event MSC: scancode = 01
1310546301.871547: event MSC: scancode = 02
1310546302.271537: event MSC: scancode = 03

You can now create keymap that fits to your own remote control. Therefore, the hexadecimal scancode needs to to be assigned to a function of the key. scancode = 3d will become 0x003d, scancode = 01 becomes 0x0001 etc.

Is is good practice to store the keymap with a self-explaining name underneath /etc/rc_keymaps/. There, it is save and will not be overwritten by yaVDR updates. The keytables that are provided by yaVDR are stored underneath /lib/udev/rc_keymaps/ and can be used as a template for your own customizations.

Example for a custom keytable, which would be stored in /etc/rc_keymaps/pvr350 (extract). 

# table rc-rc5-tv, type: RC-5 
0x003b KEY_SETUP
0x003d KEY_POWER2
0x0001 KEY_1
0x0002 KEY_2
0x0003 KEY_3
[...]

Comments in the keymaps

ir-keytable does not accept pure comment lines. If a head line is used that specifies the keytable name and the IR protocol, please make sure that you use valid values are used for both parameters. Thus, the example below would be wrong:  # table rc-rc5-tv, type # I am a pure comment line 0x003b KEY_SETUP 0x003d KEY_POWER2 0x0001 KEY_1 0x0002 KEY_2 0x0003 KEY_3 [...] protocol type not specified pure comment lines are not supported Instead, this will be correct:  # table rc-rc5-tv, type: RC-5 0x003b KEY_SETUP #I am a comment 0x003d KEY_POWER2 0x0001 KEY_1 0x0002 KEY_2 0x0003 KEY_3 Complete specification of the keytable name and the used IR protocol Comments behind the key definition are supported

To support the automated loading of keytables, you have to create a rule for the remote control in /etc/rc_maps.cfg. Since this is one of the templated files, you have to create a custom template for your own entries to avoid overwriting by yaVDR update.

/etc/rc_maps.cfg. 

# driver          table                           file
 ir-kbd-i2c      rc-rc5-tv                       /etc/rc_keymaps/pvr350

For testing purposes, you may load or reset the settings for devices attached to ir-core manually.

	How is the rc_maps.cfg file evaluated?
	An udev rule in /lib/udev/rules.d/40-ir-keytable.rules is used that loads the keymaps according to the rules in the /etc/rc_maps.cfg fil (ir-keytable -a /etc/rc_maps.cfg).

loading a keymap manually using ir-keytable. 

user@yavdr:~$ sudo ir-keytable -c  -p rc-5  -w /etc/rc_keymaps/pvr350 

example output of ir-keytable -t for the same keys with appropriate keytable. 

user@yavdr:~$ sudo ir-keytable -t
Testing events. Please, press CTRL-C to abort.
1310546400.571539: event MSC: scancode = 3d
1310546400.571545: event key down: KEY_POWER2 (0x0164)
1310546400.571547: event sync
1310546400.820703: event key up: KEY_POWER2 (0x0164)
1310546400.820705: event sync
1310546401.471543: event MSC: scancode = 3b
1310546401.471551: event key down: KEY_SETUP (0x008d)
1310546401.471553: event sync
1310546401.720700: event key up: KEY_SETUP (0x008d)
1310546401.720703: event sync
1310546406.271547: event MSC: scancode = 01
1310546406.271556: event key down: KEY_1 (0x0002)
1310546406.271558: event sync
1310546406.520700: event key up: KEY_1 (0x0002)
1310546406.520703: event sync
1310546407.071539: event MSC: scancode = 02
1310546407.071543: event key down: KEY_2 (0x0003)
1310546407.071545: event sync
1310546407.320705: event key up: KEY_2 (0x0003)
1310546407.320709: event sync
1310546407.871539: event MSC: scancode = 03
1310546407.871544: event key down: KEY_3 (0x0004)
1310546407.871546: event sync
1310546408.120700: event key up: KEY_3 (0x0004)
1310546408.120702: event sync

Rules in the file /lib/udev/rules.d/98-eventlircd.rules can specify which configurations are loaded by eventlircd for USB remote controls.

Example for an entry in /lib/udev/rules.d/98-eventlircd.rules. 

ENV{ID_VENDOR_ID}=="0419", ENV{ID_MODEL_ID}=="0001", \                      
  ENV{eventlircd_enable}="true",\                                           
  ENV{eventlircd_evmap}="03_$env{ID_VENDOR_ID}_$env{ID_MODEL_ID}.evmap"     

	Corner cases
	Sometimes, it may not be possible to reliably determine the receiver exactly by vendor ID and model ID. (e.g. X10 receivers). Thus, further udev attributes will be evaluate. The special udev rules for these receivers are located in /lib/udev/rules.d/98-eventlircd-names.conf.

Further information abot the input device can be gathered via udevadm. This is well suited if you like to determine further attributes for udev rules:

udevadm. 

user@yavdr:~$ sudo udevadm info --query=all --attribute-walk --name=/dev/input/event4

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/virtual/input/input4/event4':
    KERNEL=="event4"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/virtual/input/input4':
    KERNELS=="input4"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{name}=="Sundtek Ltd. Remote Control"
    ATTRS{phys}==""
    ATTRS{uniq}==""
    ATTRS{modalias}=="input:b0003v0000p0000e0001-e0,1,2,4,14,k71,72,73,74,80,9E,A7,AE,CF,161,174,18E,18F,190,191,192,193,ramlsfw"

It is hardly possible to configure serial receivers like e.g. the Atric receiver or homebrew receivers automatically because they can be used with many remote controls. Nevertheless, it is easy to set them up for yaVDR with lirc.

Settings in the web frontend. Check the box "lirc support" in the section remote control of the yaVDR web frontend and select the appropriate receiver in the list. For the Atric wakeup board, the proper entry is "Home-brew (16x50 UART compatible serial port)". Furthermore, you need to specify th serial port where the board is attached. The numbering is usually aligned with the specification in the user manual of your mainboard.

Customization of the lircd.conf file. Now, the correct lircd.conf file has to be copied to /etc/lirc/lircd.conf. The key names have to comply with the naming convention that is defined in th input.h kernel header and should be aligned with the remote.conf, if you like to use them with VDR and XBMC. This will make sure that the remote control can be used with VDR and XBMC without further configuration.

yaVDR 0.3 or the "old" lircd.conf. 

[...]
begin codes
          Up                   0x1794
          Down                 0x1795
          Ok                   0x17A5
          left                 0x1796
          right                0x1797
          info                 0x179B
[...]

yaVDR 0.5 or the "new" lircd.conf. 

[...]
begin codes
          KEY_UP                   0x1794
          KEY_DOWN                 0x1795
          KEY_OK                   0x17A5
          KEY_LEFT                 0x1796
          KEY_RIGHT                0x1797
          KEY_INFO                 0x179B
[...]

After a restart of eventlircd, the remote controls connected to the serial receivers can be used. The key presses from lircd can be monitored by irw reading from /var/run/lirc/lircd.<PID>.

For the Igor USB receivers, you only need to copy an appropriate lircd.conf to /etc/lirc/. An udev rule will automatically start and lircd process, and its output will be evaluated by eventlircd. The socket of lircd is usually at /var/run/lirc/lircd-lirc0 and be monitored by irw.

	Remote control settings in the web frontend!
	Do not activate lirc in the web frontend when using Igor USB receivers. Otherwise, two separate lircd processes will be startet which will block themselfs with the consequence that the remote control is not running!

The yaUsbIr receiver ^[29]] combines an IR receiver and an wakeup device that is connected to the USB port. Thus, it is an interesting alternative to Atric receivers that are currently only available for the serial port. Maybe due to a bug in libusb (there are false "remove" events in Ubuntu), the yaUsbIR cannot be configured via udev rules. So it has to be activated manually in the yaVDR web frontend.

Each Bluetooth device that shall communicate with yaVDR needs to authenticate itself first. To avoid dependencies to adimistration tools with a user interface, we suggest the tools from the package bluez-utils. This package may need to be installed separately.

Display all Bluetooth adapters - provides the hci<X> device. 

hciconfig

Lookup of devices (those have to be visible; for the PS3 Remote BD you have to press "Start" + "Enter" simultanously). 

sudo bluez-test-discovery

Here, you can pick the desired device and note down the value of "Address".

The authentification for devices with a display may require a PIN entry for the pairing, which can be done via: 

sudo bluez-simple-agent hci<X> <address>

For devices such as the PS3 Remote or other bluetooth remote controls and keyboards without a default pin: 

sudo bluez-test-device create <address>
sudo bluez-test-device trusted <address> yes

Connect to the device for test purposes: 

sudo bluez-test-input connect <address>

The PS3 Remote BD is directly usable after the initial pairing. Its keys are configured via the /etc/eventlircd.d/ps3remote.evmap.