blob: bc6ef00a00f1d7ccfc8a2e3fa4264fc50fd95916 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
|
Purpose of this plugin
======================
Hotplugging of input devices is common nowadays and more or less
required by recent initsystems. E.g. users might want to turn on
their Bluetooth keyboard when VDR has been started already, or the
initsystem might start 'vdr' although the USB remote control has not
been initialized yet.
Naming of input devices is also dynamic, so that the remote control might
be sometimes at /dev/input/event4 and sometimes at /dev/input/event6.
To deal with this situation, this plugin hotplugs (and hotunplugs)
input devices. The corresponding events are generated by 'udev' rules
so that an input devices becomes available to vdr as soon as it has
been attached.
All the configuration (e.g. blacklisting of devices (e.g. the system
keyboard) or installation of keymaps) must be done within custom udev
rules.
Coldplugging
============
It can happen that input devices are created when vdr has not been
started yet. Hotplug events will not be created then and device will
not show up in vdr then.
To deal with this (common) situation, the plugin adds all event devices
from a specific directory at startup. This directory must be filled by
udev rules and by default this directory is /dev/vdr/input.
Manual control
==============
$ socat stdin unix-send:/run/vdr/inputdev
add event3
remove /dev/input/even5
dump all # --> see syslog for results
Keymaps
=======
The aged vdr input system supports only a small subset of the /dev/input
features and is incompatible in some details. The plugin implements a
static mapping of /dev/input events to vdr events. Learning of remote
control codes is *not* supported; the keymap of the input device must be
configured with standard Linux mechanisms (EVIOCSKEYCODE ioctl).
Please see cInputDevice::install_keymap (inputdev.c) for the expected
mapping and contrib/96-vdrkeymap.rules for samples how to setup keymaps.
The 'contrib/' directory contains some keymaps too.
Plugin options
==============
--socket|-s <socket> ... unix dgram socket for hotplug events
(default: /var/run/vdr/inputdev)
Installation
============
1. Build and install the plugin as usual
2. Build the 'vdr-inputdev' udev helper and install it at the 'udev'
program location (usually /lib/udev)
3. Create custom 'udev' rules and install them in the local rules
directory (usually /etc/udev/rules.d)
4. Create keymaps for your remote controls and install them; when
using 'keymap' program from 'udev', the keymaps are searched in
/lib/udev/keymaps but you can specify a full path in the udev
rules too.
Creating keymap rules
=====================
1. Plugin the device
2. Remove it either manually from vdr (see "Manual control" above)
or stop vdr
3. Use a program like 'evtest' or 'keymap' from 'udev' to display
events:
/lib/udev/keymap -i /dev/input/event4
4. Press the keys you want to configure, record their scancode and
the wanted key identifier. See cInputDevice::install_keymap
(inputdev.c) for supported key identifiers.
Magic Keysequence
=================
By default, all input devices -- including the normal keyboard -- will
be grabbed by device and can not be used by other programs anymore.
To allow maintainance tasks like logging in on the console, the plugin
detaches a input device when it recognizes the magic keysequence
SHIFT - SHIFT - ESCAPE - SHIFT
from there.
|
