Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: xen-kbdfront - fix mouse getting stuck after save/restore
Input: estimate number of events per packet
Input: evdev - indicate buffer overrun with SYN_DROPPED
Input: document event types and codes and their intended use
Input: add KEY_IMAGES specifically for AL Image Browser
Input: twl4030_keypad - fix potential NULL dereference in twl4030_kp_probe()
Input: h3600_ts - fix error handling at connect
Input: twl4030_keypad - avoid potential NULL-pointer dereference
+361
-26
+262
Documentation/input/event-codes.txt
+262
Documentation/input/event-codes.txt
···
1
+
The input protocol uses a map of types and codes to express input device values
2
+
to userspace. This document describes the types and codes and how and when they
3
+
may be used.
4
+
5
+
A single hardware event generates multiple input events. Each input event
6
+
contains the new value of a single data item. A special event type, EV_SYN, is
7
+
used to separate input events into packets of input data changes occurring at
8
+
the same moment in time. In the following, the term "event" refers to a single
9
+
input event encompassing a type, code, and value.
10
+
11
+
The input protocol is a stateful protocol. Events are emitted only when values
12
+
of event codes have changed. However, the state is maintained within the Linux
13
+
input subsystem; drivers do not need to maintain the state and may attempt to
14
+
emit unchanged values without harm. Userspace may obtain the current state of
15
+
event code values using the EVIOCG* ioctls defined in linux/input.h. The event
16
+
reports supported by a device are also provided by sysfs in
17
+
class/input/event*/device/capabilities/, and the properties of a device are
18
+
provided in class/input/event*/device/properties.
19
+
20
+
Types:
21
+
==========
22
+
Types are groupings of codes under a logical input construct. Each type has a
23
+
set of applicable codes to be used in generating events. See the Codes section
24
+
for details on valid codes for each type.
25
+
26
+
* EV_SYN:
27
+
- Used as markers to separate events. Events may be separated in time or in
28
+
space, such as with the multitouch protocol.
29
+
30
+
* EV_KEY:
31
+
- Used to describe state changes of keyboards, buttons, or other key-like
32
+
devices.
33
+
34
+
* EV_REL:
35
+
- Used to describe relative axis value changes, e.g. moving the mouse 5 units
36
+
to the left.
37
+
38
+
* EV_ABS:
39
+
- Used to describe absolute axis value changes, e.g. describing the
40
+
coordinates of a touch on a touchscreen.
41
+
42
+
* EV_MSC:
43
+
- Used to describe miscellaneous input data that do not fit into other types.
44
+
45
+
* EV_SW:
46
+
- Used to describe binary state input switches.
47
+
48
+
* EV_LED:
49
+
- Used to turn LEDs on devices on and off.
50
+
51
+
* EV_SND:
52
+
- Used to output sound to devices.
53
+
54
+
* EV_REP:
55
+
- Used for autorepeating devices.
56
+
57
+
* EV_FF:
58
+
- Used to send force feedback commands to an input device.
59
+
60
+
* EV_PWR:
61
+
- A special type for power button and switch input.
62
+
63
+
* EV_FF_STATUS:
64
+
- Used to receive force feedback device status.
65
+
66
+
Codes:
67
+
==========
68
+
Codes define the precise type of event.
69
+
70
+
EV_SYN:
71
+
----------
72
+
EV_SYN event values are undefined. Their usage is defined only by when they are
73
+
sent in the evdev event stream.
74
+
75
+
* SYN_REPORT:
76
+
- Used to synchronize and separate events into packets of input data changes
77
+
occurring at the same moment in time. For example, motion of a mouse may set
78
+
the REL_X and REL_Y values for one motion, then emit a SYN_REPORT. The next
79
+
motion will emit more REL_X and REL_Y values and send another SYN_REPORT.
80
+
81
+
* SYN_CONFIG:
82
+
- TBD
83
+
84
+
* SYN_MT_REPORT:
85
+
- Used to synchronize and separate touch events. See the
86
+
multi-touch-protocol.txt document for more information.
87
+
88
+
* SYN_DROPPED:
89
+
- Used to indicate buffer overrun in the evdev client's event queue.
90
+
Client should ignore all events up to and including next SYN_REPORT
91
+
event and query the device (using EVIOCG* ioctls) to obtain its
92
+
current state.
93
+
94
+
EV_KEY:
95
+
----------
96
+
EV_KEY events take the form KEY_<name> or BTN_<name>. For example, KEY_A is used
97
+
to represent the 'A' key on a keyboard. When a key is depressed, an event with
98
+
the key's code is emitted with value 1. When the key is released, an event is
99
+
emitted with value 0. Some hardware send events when a key is repeated. These
100
+
events have a value of 2. In general, KEY_<name> is used for keyboard keys, and
101
+
BTN_<name> is used for other types of momentary switch events.
102
+
103
+
A few EV_KEY codes have special meanings:
104
+
105
+
* BTN_TOOL_<name>:
106
+
- These codes are used in conjunction with input trackpads, tablets, and
107
+
touchscreens. These devices may be used with fingers, pens, or other tools.
108
+
When an event occurs and a tool is used, the corresponding BTN_TOOL_<name>
109
+
code should be set to a value of 1. When the tool is no longer interacting
110
+
with the input device, the BTN_TOOL_<name> code should be reset to 0. All
111
+
trackpads, tablets, and touchscreens should use at least one BTN_TOOL_<name>
112
+
code when events are generated.
113
+
114
+
* BTN_TOUCH:
115
+
BTN_TOUCH is used for touch contact. While an input tool is determined to be
116
+
within meaningful physical contact, the value of this property must be set
117
+
to 1. Meaningful physical contact may mean any contact, or it may mean
118
+
contact conditioned by an implementation defined property. For example, a
119
+
touchpad may set the value to 1 only when the touch pressure rises above a
120
+
certain value. BTN_TOUCH may be combined with BTN_TOOL_<name> codes. For
121
+
example, a pen tablet may set BTN_TOOL_PEN to 1 and BTN_TOUCH to 0 while the
122
+
pen is hovering over but not touching the tablet surface.
123
+
124
+
Note: For appropriate function of the legacy mousedev emulation driver,
125
+
BTN_TOUCH must be the first evdev code emitted in a synchronization frame.
126
+
127
+
Note: Historically a touch device with BTN_TOOL_FINGER and BTN_TOUCH was
128
+
interpreted as a touchpad by userspace, while a similar device without
129
+
BTN_TOOL_FINGER was interpreted as a touchscreen. For backwards compatibility
130
+
with current userspace it is recommended to follow this distinction. In the
131
+
future, this distinction will be deprecated and the device properties ioctl
132
+
EVIOCGPROP, defined in linux/input.h, will be used to convey the device type.
133
+
134
+
* BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, BTN_TOOL_TRIPLETAP, BTN_TOOL_QUADTAP:
135
+
- These codes denote one, two, three, and four finger interaction on a
136
+
trackpad or touchscreen. For example, if the user uses two fingers and moves
137
+
them on the touchpad in an effort to scroll content on screen,
138
+
BTN_TOOL_DOUBLETAP should be set to value 1 for the duration of the motion.
139
+
Note that all BTN_TOOL_<name> codes and the BTN_TOUCH code are orthogonal in
140
+
purpose. A trackpad event generated by finger touches should generate events
141
+
for one code from each group. At most only one of these BTN_TOOL_<name>
142
+
codes should have a value of 1 during any synchronization frame.
143
+
144
+
Note: Historically some drivers emitted multiple of the finger count codes with
145
+
a value of 1 in the same synchronization frame. This usage is deprecated.
146
+
147
+
Note: In multitouch drivers, the input_mt_report_finger_count() function should
148
+
be used to emit these codes. Please see multi-touch-protocol.txt for details.
149
+
150
+
EV_REL:
151
+
----------
152
+
EV_REL events describe relative changes in a property. For example, a mouse may
153
+
move to the left by a certain number of units, but its absolute position in
154
+
space is unknown. If the absolute position is known, EV_ABS codes should be used
155
+
instead of EV_REL codes.
156
+
157
+
A few EV_REL codes have special meanings:
158
+
159
+
* REL_WHEEL, REL_HWHEEL:
160
+
- These codes are used for vertical and horizontal scroll wheels,
161
+
respectively.
162
+
163
+
EV_ABS:
164
+
----------
165
+
EV_ABS events describe absolute changes in a property. For example, a touchpad
166
+
may emit coordinates for a touch location.
167
+
168
+
A few EV_ABS codes have special meanings:
169
+
170
+
* ABS_DISTANCE:
171
+
- Used to describe the distance of a tool from an interaction surface. This
172
+
event should only be emitted while the tool is hovering, meaning in close
173
+
proximity of the device and while the value of the BTN_TOUCH code is 0. If
174
+
the input device may be used freely in three dimensions, consider ABS_Z
175
+
instead.
176
+
177
+
* ABS_MT_<name>:
178
+
- Used to describe multitouch input events. Please see
179
+
multi-touch-protocol.txt for details.
180
+
181
+
EV_SW:
182
+
----------
183
+
EV_SW events describe stateful binary switches. For example, the SW_LID code is
184
+
used to denote when a laptop lid is closed.
185
+
186
+
Upon binding to a device or resuming from suspend, a driver must report
187
+
the current switch state. This ensures that the device, kernel, and userspace
188
+
state is in sync.
189
+
190
+
Upon resume, if the switch state is the same as before suspend, then the input
191
+
subsystem will filter out the duplicate switch state reports. The driver does
192
+
not need to keep the state of the switch at any time.
193
+
194
+
EV_MSC:
195
+
----------
196
+
EV_MSC events are used for input and output events that do not fall under other
197
+
categories.
198
+
199
+
EV_LED:
200
+
----------
201
+
EV_LED events are used for input and output to set and query the state of
202
+
various LEDs on devices.
203
+
204
+
EV_REP:
205
+
----------
206
+
EV_REP events are used for specifying autorepeating events.
207
+
208
+
EV_SND:
209
+
----------
210
+
EV_SND events are used for sending sound commands to simple sound output
211
+
devices.
212
+
213
+
EV_FF:
214
+
----------
215
+
EV_FF events are used to initialize a force feedback capable device and to cause
216
+
such device to feedback.
217
+
218
+
EV_PWR:
219
+
----------
220
+
EV_PWR events are a special type of event used specifically for power
221
+
mangement. Its usage is not well defined. To be addressed later.
222
+
223
+
Guidelines:
224
+
==========
225
+
The guidelines below ensure proper single-touch and multi-finger functionality.
226
+
For multi-touch functionality, see the multi-touch-protocol.txt document for
227
+
more information.
228
+
229
+
Mice:
230
+
----------
231
+
REL_{X,Y} must be reported when the mouse moves. BTN_LEFT must be used to report
232
+
the primary button press. BTN_{MIDDLE,RIGHT,4,5,etc.} should be used to report
233
+
further buttons of the device. REL_WHEEL and REL_HWHEEL should be used to report
234
+
scroll wheel events where available.
235
+
236
+
Touchscreens:
237
+
----------
238
+
ABS_{X,Y} must be reported with the location of the touch. BTN_TOUCH must be
239
+
used to report when a touch is active on the screen.
240
+
BTN_{MOUSE,LEFT,MIDDLE,RIGHT} must not be reported as the result of touch
241
+
contact. BTN_TOOL_<name> events should be reported where possible.
242
+
243
+
Trackpads:
244
+
----------
245
+
Legacy trackpads that only provide relative position information must report
246
+
events like mice described above.
247
+
248
+
Trackpads that provide absolute touch position must report ABS_{X,Y} for the
249
+
location of the touch. BTN_TOUCH should be used to report when a touch is active
250
+
on the trackpad. Where multi-finger support is available, BTN_TOOL_<name> should
251
+
be used to report the number of touches active on the trackpad.
252
+
253
+
Tablets:
254
+
----------
255
+
BTN_TOOL_<name> events must be reported when a stylus or other tool is active on
256
+
the tablet. ABS_{X,Y} must be reported with the location of the tool. BTN_TOUCH
257
+
should be used to report when the tool is in contact with the tablet.
258
+
BTN_{STYLUS,STYLUS2} should be used to report buttons on the tool itself. Any
259
+
button may be used for buttons on the tablet except BTN_{MOUSE,LEFT}.
260
+
BTN_{0,1,2,etc} are good generic codes for unlabeled buttons. Do not use
261
+
meaningful buttons, like BTN_FORWARD, unless the button is labeled for that
262
+
purpose on the device.
+21
-12
drivers/input/evdev.c
+21
-12
drivers/input/evdev.c
···
39
39
};
40
40
41
41
struct evdev_client {
42
-
int head;
43
-
int tail;
42
+
unsigned int head;
43
+
unsigned int tail;
44
44
spinlock_t buffer_lock; /* protects access to buffer, head and tail */
45
45
struct fasync_struct *fasync;
46
46
struct evdev *evdev;
47
47
struct list_head node;
48
-
int bufsize;
48
+
unsigned int bufsize;
49
49
struct input_event buffer[];
50
50
};
51
51
···
55
55
static void evdev_pass_event(struct evdev_client *client,
56
56
struct input_event *event)
57
57
{
58
-
/*
59
-
* Interrupts are disabled, just acquire the lock.
60
-
* Make sure we don't leave with the client buffer
61
-
* "empty" by having client->head == client->tail.
62
-
*/
58
+
/* Interrupts are disabled, just acquire the lock. */
63
59
spin_lock(&client->buffer_lock);
64
-
do {
65
-
client->buffer[client->head++] = *event;
66
-
client->head &= client->bufsize - 1;
67
-
} while (client->head == client->tail);
60
+
61
+
client->buffer[client->head++] = *event;
62
+
client->head &= client->bufsize - 1;
63
+
64
+
if (unlikely(client->head == client->tail)) {
65
+
/*
66
+
* This effectively "drops" all unconsumed events, leaving
67
+
* EV_SYN/SYN_DROPPED plus the newest event in the queue.
68
+
*/
69
+
client->tail = (client->head - 2) & (client->bufsize - 1);
70
+
71
+
client->buffer[client->tail].time = event->time;
72
+
client->buffer[client->tail].type = EV_SYN;
73
+
client->buffer[client->tail].code = SYN_DROPPED;
74
+
client->buffer[client->tail].value = 0;
75
+
}
76
+
68
77
spin_unlock(&client->buffer_lock);
69
78
70
79
if (event->type == EV_SYN)
+40
drivers/input/input.c
+40
drivers/input/input.c
···
1746
1746
}
1747
1747
EXPORT_SYMBOL(input_set_capability);
1748
1748
1749
+
static unsigned int input_estimate_events_per_packet(struct input_dev *dev)
1750
+
{
1751
+
int mt_slots;
1752
+
int i;
1753
+
unsigned int events;
1754
+
1755
+
if (dev->mtsize) {
1756
+
mt_slots = dev->mtsize;
1757
+
} else if (test_bit(ABS_MT_TRACKING_ID, dev->absbit)) {
1758
+
mt_slots = dev->absinfo[ABS_MT_TRACKING_ID].maximum -
1759
+
dev->absinfo[ABS_MT_TRACKING_ID].minimum + 1,
1760
+
clamp(mt_slots, 2, 32);
1761
+
} else if (test_bit(ABS_MT_POSITION_X, dev->absbit)) {
1762
+
mt_slots = 2;
1763
+
} else {
1764
+
mt_slots = 0;
1765
+
}
1766
+
1767
+
events = mt_slots + 1; /* count SYN_MT_REPORT and SYN_REPORT */
1768
+
1769
+
for (i = 0; i < ABS_CNT; i++) {
1770
+
if (test_bit(i, dev->absbit)) {
1771
+
if (input_is_mt_axis(i))
1772
+
events += mt_slots;
1773
+
else
1774
+
events++;
1775
+
}
1776
+
}
1777
+
1778
+
for (i = 0; i < REL_CNT; i++)
1779
+
if (test_bit(i, dev->relbit))
1780
+
events++;
1781
+
1782
+
return events;
1783
+
}
1784
+
1749
1785
#define INPUT_CLEANSE_BITMASK(dev, type, bits) \
1750
1786
do { \
1751
1787
if (!test_bit(EV_##type, dev->evbit)) \
···
1828
1792
1829
1793
/* Make sure that bitmasks not mentioned in dev->evbit are clean. */
1830
1794
input_cleanse_bitmasks(dev);
1795
+
1796
+
if (!dev->hint_events_per_packet)
1797
+
dev->hint_events_per_packet =
1798
+
input_estimate_events_per_packet(dev);
1831
1799
1832
1800
/*
1833
1801
* If delay and period are pre-set by the driver, then autorepeating
+4
-2
drivers/input/keyboard/twl4030_keypad.c
+4
-2
drivers/input/keyboard/twl4030_keypad.c
···
332
332
static int __devinit twl4030_kp_probe(struct platform_device *pdev)
333
333
{
334
334
struct twl4030_keypad_data *pdata = pdev->dev.platform_data;
335
-
const struct matrix_keymap_data *keymap_data = pdata->keymap_data;
335
+
const struct matrix_keymap_data *keymap_data;
336
336
struct twl4030_keypad *kp;
337
337
struct input_dev *input;
338
338
u8 reg;
339
339
int error;
340
340
341
-
if (!pdata || !pdata->rows || !pdata->cols ||
341
+
if (!pdata || !pdata->rows || !pdata->cols || !pdata->keymap_data ||
342
342
pdata->rows > TWL4030_MAX_ROWS || pdata->cols > TWL4030_MAX_COLS) {
343
343
dev_err(&pdev->dev, "Invalid platform_data\n");
344
344
return -EINVAL;
345
345
}
346
+
347
+
keymap_data = pdata->keymap_data;
346
348
347
349
kp = kzalloc(sizeof(*kp), GFP_KERNEL);
348
350
input = input_allocate_device();
+12
-1
drivers/input/misc/xen-kbdfront.c
+12
-1
drivers/input/misc/xen-kbdfront.c
···
303
303
enum xenbus_state backend_state)
304
304
{
305
305
struct xenkbd_info *info = dev_get_drvdata(&dev->dev);
306
-
int val;
306
+
int ret, val;
307
307
308
308
switch (backend_state) {
309
309
case XenbusStateInitialising:
···
316
316
317
317
case XenbusStateInitWait:
318
318
InitWait:
319
+
ret = xenbus_scanf(XBT_NIL, info->xbdev->otherend,
320
+
"feature-abs-pointer", "%d", &val);
321
+
if (ret < 0)
322
+
val = 0;
323
+
if (val) {
324
+
ret = xenbus_printf(XBT_NIL, info->xbdev->nodename,
325
+
"request-abs-pointer", "1");
326
+
if (ret)
327
+
pr_warning("xenkbd: can't request abs-pointer");
328
+
}
329
+
319
330
xenbus_switch_state(dev, XenbusStateConnected);
320
331
break;
321
332
+10
-7
drivers/input/touchscreen/h3600_ts_input.c
+10
-7
drivers/input/touchscreen/h3600_ts_input.c
···
399
399
IRQF_SHARED | IRQF_DISABLED, "h3600_action", &ts->dev)) {
400
400
printk(KERN_ERR "h3600ts.c: Could not allocate Action Button IRQ!\n");
401
401
err = -EBUSY;
402
-
goto fail2;
402
+
goto fail1;
403
403
}
404
404
405
405
if (request_irq(IRQ_GPIO_BITSY_NPOWER_BUTTON, npower_button_handler,
406
406
IRQF_SHARED | IRQF_DISABLED, "h3600_suspend", &ts->dev)) {
407
407
printk(KERN_ERR "h3600ts.c: Could not allocate Power Button IRQ!\n");
408
408
err = -EBUSY;
409
-
goto fail3;
409
+
goto fail2;
410
410
}
411
411
412
412
serio_set_drvdata(serio, ts);
413
413
414
414
err = serio_open(serio, drv);
415
415
if (err)
416
-
return err;
416
+
goto fail3;
417
417
418
418
//h3600_flite_control(1, 25); /* default brightness */
419
-
input_register_device(ts->dev);
419
+
err = input_register_device(ts->dev);
420
+
if (err)
421
+
goto fail4;
420
422
421
423
return 0;
422
424
423
-
fail3: free_irq(IRQ_GPIO_BITSY_NPOWER_BUTTON, ts->dev);
425
+
fail4: serio_close(serio);
426
+
fail3: serio_set_drvdata(serio, NULL);
427
+
free_irq(IRQ_GPIO_BITSY_NPOWER_BUTTON, ts->dev);
424
428
fail2: free_irq(IRQ_GPIO_BITSY_ACTION_BUTTON, ts->dev);
425
-
fail1: serio_set_drvdata(serio, NULL);
426
-
input_free_device(input_dev);
429
+
fail1: input_free_device(input_dev);
427
430
kfree(ts);
428
431
return err;
429
432
}
+6
-4
include/linux/input.h
+6
-4
include/linux/input.h
···
167
167
#define SYN_REPORT 0
168
168
#define SYN_CONFIG 1
169
169
#define SYN_MT_REPORT 2
170
+
#define SYN_DROPPED 3
170
171
171
172
/*
172
173
* Keys and buttons
···
554
553
#define KEY_DVD 0x185 /* Media Select DVD */
555
554
#define KEY_AUX 0x186
556
555
#define KEY_MP3 0x187
557
-
#define KEY_AUDIO 0x188
558
-
#define KEY_VIDEO 0x189
556
+
#define KEY_AUDIO 0x188 /* AL Audio Browser */
557
+
#define KEY_VIDEO 0x189 /* AL Movie Browser */
559
558
#define KEY_DIRECTORY 0x18a
560
559
#define KEY_LIST 0x18b
561
560
#define KEY_MEMO 0x18c /* Media Select Messages */
···
604
603
#define KEY_FRAMEFORWARD 0x1b5
605
604
#define KEY_CONTEXT_MENU 0x1b6 /* GenDesc - system context menu */
606
605
#define KEY_MEDIA_REPEAT 0x1b7 /* Consumer - transport control */
607
-
#define KEY_10CHANNELSUP 0x1b8 /* 10 channels up (10+) */
608
-
#define KEY_10CHANNELSDOWN 0x1b9 /* 10 channels down (10-) */
606
+
#define KEY_10CHANNELSUP 0x1b8 /* 10 channels up (10+) */
607
+
#define KEY_10CHANNELSDOWN 0x1b9 /* 10 channels down (10-) */
608
+
#define KEY_IMAGES 0x1ba /* AL Image Browser */
609
609
610
610
#define KEY_DEL_EOL 0x1c0
611
611
#define KEY_DEL_EOS 0x1c1
+6
include/linux/input/mt.h
+6
include/linux/input/mt.h
···
48
48
input_event(dev, EV_ABS, ABS_MT_SLOT, slot);
49
49
}
50
50
51
+
static inline bool input_is_mt_axis(int axis)
52
+
{
53
+
return axis == ABS_MT_SLOT ||
54
+
(axis >= ABS_MT_FIRST && axis <= ABS_MT_LAST);
55
+
}
56
+
51
57
void input_mt_report_slot_state(struct input_dev *dev,
52
58
unsigned int tool_type, bool active);
53
59