input 子系统(evdev,input_core,input_handler,input_dev)
文章目录
- 概述
- input-core
- input_dev 以及handler
- input_event
- evbug
- 关于slot A/B协议（本段为摘抄）
- 常用写input 驱动的步骤
- 测试代码(ubuntu16.04下测试通过)
- 驱动代码
- 应用代码
概述
input子系统框架图
1.input-core 输入核心
2.input-event-dev 输入事件驱动程序
3.input-driver 输入设备驱动程序
如何理解：
输入事件是标准的，对于所有输入设备都应该是可以用的，要实现的是输入设备驱动程序。输入设备驱动程序可以选择合适的输入事件驱动程序，通过输入核心以及输入事件驱动程序，向用户层输入数据
通俗讲解：
输入核心：输入核心提供了注册设备驱动以及事件驱动的API，维护着事件驱动的链表以及设备驱动的链表
设备驱动 对应input_dev 负责实际的设备数据读取，通过input core 将数据传递到事件驱动程序，上报给用户层
事件驱动，对应input_handler，负责创建设备节点，负责和应用层进行数据交互以及上报
设备驱动与事件驱动通过id_table进行match，match之后通过connect函数创建事件驱动，事件驱动负责创建设备节点，提供open，close 等文件操作函数包括/dev/input/eventX,或者mouse等，然后通过input_handle进行绑定。维护着client（上层用户）的链表，将数据传递给用户层以及每一个打开文件的client
相关的目录:drivers/input
相关的文件:input.c,evdev.c,input-polldev.c mousedev.c linux/include/input.h include/uapi/linux/input.h
相关的结构体：
/**
* struct input_value - input value representation
* @type: type of value (EV_KEY, EV_ABS, etc)
* @code: the value code
* @value: the value
*/
struct input_value {
__u16 type;
__u16 code;
__s32 value;
};
注：对于所有的input设备，一般向上层应用输出的都是以上的结构体
/**
* struct input_dev - represents an input device
* @name: name of the device
* @phys: physical path to the device in the system hierarchy
* @uniq: unique identification code for the device (if device has it)
* @id: id of the device (struct input_id)
* @propbit: bitmap of device properties and quirks
* @evbit: bitmap of types of events supported by the device (EV_KEY,
* EV_REL, etc.)
* @keybit: bitmap of keys/buttons this device has
* @relbit: bitmap of relative axes for the device
* @absbit: bitmap of absolute axes for the device
* @mscbit: bitmap of miscellaneous events supported by the device
* @ledbit: bitmap of leds present on the device
* @sndbit: bitmap of sound effects supported by the device
* @ffbit: bitmap of force feedback effects supported by the device
* @swbit: bitmap of switches present on the device
* @hint_events_per_packet: average number of events generated by the
* device in a packet (between EV_SYN/SYN_REPORT events). Used by
* event handlers to estimate size of the buffer needed to hold
* events.
* @keycodemax: size of keycode table
* @keycodesize: size of elements in keycode table
* @keycode: map of scancodes to keycodes for this device
* @getkeycode: optional legacy method to retrieve current keymap.
* @setkeycode: optional method to alter current keymap, used to implement
* sparse keymaps. If not supplied default mechanism will be used.
* The method is being called while holding event_lock and thus must
* not sleep
* @ff: force feedback structure associated with the device if device
* supports force feedback effects
* @repeat_key: stores key code of the last key pressed; used to implement
* software autorepeat
* @timer: timer for software autorepeat
* @rep: current values for autorepeat parameters (delay, rate)
* @mt: pointer to multitouch state
* @absinfo: array of &struct input_absinfo elements holding information
* about absolute axes (current value, min, max, flat, fuzz,
* resolution)
* @key: reflects current state of device's keys/buttons
* @led: reflects current state of device's LEDs
* @snd: reflects current state of sound effects
* @sw: reflects current state of device's switches
* @open: this method is called when the very first user calls
* input_open_device(). The driver must prepare the device
* to start generating events (start polling thread,
* request an IRQ, submit URB, etc.)
* @close: this method is called when the very last user calls
* input_close_device().
* @flush: purges the device. Most commonly used to get rid of force
* feedback effects loaded into the device when disconnecting
* from it
* @event: event handler for events sent _to_ the device, like EV_LED
* or EV_SND. The device is expected to carry out the requested
* action (turn on a LED, play sound, etc.) The call is protected
* by @event_lock and must not sleep
* @grab: input handle that currently has the device grabbed (via
* EVIOCGRAB ioctl). When a handle grabs a device it becomes sole
* recipient for all input events coming from the device
* @event_lock: this spinlock is is taken when input core receives
* and processes a new event for the device (in input_event()).
* Code that accesses and/or modifies parameters of a device
* (such as keymap or absmin, absmax, absfuzz, etc.) after device
* has been registered with input core must take this lock.
* @mutex: serializes calls to open(), close() and flush() methods
* @users: stores number of users (input handlers) that opened this
* device. It is used by input_open_device() and input_close_device()
* to make sure that dev->open() is only called when the first
* user opens device and dev->close() is called when the very
* last user closes the device
* @going_away: marks devices that are in a middle of unregistering and
* causes input_open_device*() fail with -ENODEV.
* @dev: driver model's view of this device
* @h_list: list of input handles associated with the device. When
* accessing the list dev->mutex must be held
* @node: used to place the device onto input_dev_list
* @num_vals: number of values queued in the current frame
* @max_vals: maximum number of values queued in a frame
* @vals: array of values queued in the current frame
* @devres_managed: indicates that devices is managed with devres framework
* and needs not be explicitly unregistered or freed.
*/
struct input_dev {
const char *name;
const char *phys;
const char *uniq;
struct input_id id;
unsigned long propbit[BITS_TO_LONGS(INPUT_PROP_CNT)];
unsigned long evbit[BITS_TO_LONGS(EV_CNT)];
unsigned long keybit[BITS_TO_LONGS(KEY_CNT)];
unsigned long relbit[BITS_TO_LONGS(REL_CNT)];
unsigned long absbit[BITS_TO_LONGS(ABS_CNT)];
unsigned long mscbit[BITS_TO_LONGS(MSC_CNT)];
unsigned long ledbit[BITS_TO_LONGS(LED_CNT)];
unsigned long sndbit[BITS_TO_LONGS(SND_CNT)];
unsigned long ffbit[BITS_TO_LONGS(FF_CNT)];
unsigned long swbit[BITS_TO_LONGS(SW_CNT)];
unsigned int hint_events_per_packet;
unsigned int keycodemax;
unsigned int keycodesize;
void *keycode;
int (*setkeycode)(struct input_dev *dev,
const struct input_keymap_entry *ke,
unsigned int *old_keycode);
int (*getkeycode)(struct input_dev *dev,
struct input_keymap_entry *ke);
struct ff_device *ff;
unsigned int repeat_key;
struct timer_list timer;
int rep[REP_CNT];
struct input_mt *mt;
struct input_absinfo *absinfo;
unsigned long key[BITS_TO_LONGS(KEY_CNT)];
unsigned long led[BITS_TO_LONGS(LED_CNT)];
unsigned long snd[BITS_TO_LONGS(SND_CNT)];
unsigned long sw[BITS_TO_LONGS(SW_CNT)];
int (*open)(struct input_dev *dev);
void (*close)(struct input_dev *dev);
int (*flush)(struct input_dev *dev, struct file *file);
int (*event)(struct input_dev *dev, unsigned int type, unsigned int code, int value);
struct input_handle __rcu *grab;
spinlock_t event_lock;
struct mutex mutex;
unsigned int users;
bool going_away;
struct device dev;
struct list_head h_list;
struct list_head node;
unsigned int num_vals;
unsigned int max_vals;
struct input_value *vals;
bool devres_managed;
};
以上结构体描述的是一个输入设备
struct input_handler {
void *private;
void (*event)(struct input_handle *handle, unsigned int type, unsigned int code, int value);
void (*events)(struct input_handle *handle,
const struct input_value *vals, unsigned int count);
bool (*filter)(struct input_handle *handle, unsigned int type, unsigned int code, int value);
bool (*match)(struct input_handler *handler, struct input_dev *dev);
int (*connect)(struct input_handler *handler, struct input_dev *dev, const struct input_device_id *id);
void (*disconnect)(struct input_handle *handle);
void (*start)(struct input_handle *handle);
bool legacy_minors;
int minor;
const char *name;
const struct input_device_id *id_table;
struct list_head h_list;
struct list_head node;
};
以上的结构体描述的是事件驱动程序
struct input_handle {
void *private;
int open;
const char *name;
struct input_dev *dev;
struct input_handler *handler;
struct list_head d_node;
struct list_head h_node;
};
以上的结构体是将输入设备与输入的事件绑定到一起
相关的API
输入设备的驱动程序：
int __must_check input_register_device(struct input_dev *);
void input_unregister_device(struct input_dev *);
void input_reset_device(struct input_dev *);
输入事件的驱动程序:
int __must_check input_register_handler(struct input_handler *);
void input_unregister_handler(struct input_handler *);
设备驱动程序report值:
input_report_key/input_report_rel/input_report_abs/input_report_switch/input_sync
也可以调用:
void input_event(struct input_dev *dev, unsigned int type, unsigned int code, int value);
void input_inject_event(struct input_handle *handle, unsigned int type, unsigned int code, int value);
input-core
input_dev 以及handler
input_event
void input_event(struct input_dev *dev,
unsigned int type, unsigned int code, int value)
{
unsigned long flags;
/測試是否input_dev是否支持該事件,可以通過__set_bit(KEY_POWER, info->idev->keybit)來实现/
if (is_event_supported(type, dev->evbit, EV_MAX)) {
spin_lock_irqsave(&dev->event_lock, flags);
input_handle_event(dev, type, code, value);
spin_unlock_irqrestore(&dev->event_lock, flags);
}
}
整个调用流程是：
input_event->input_handle_event->input_pass_values->handler->event or handler->events
evbug
能够将所有的事件（按键，mouse）打印到系统的log中，是一种调试手段。
关于slot A/B协议（本段为摘抄）
将A/B协议这部分单独拿出来说一方面是因为这部分内容是比较容易忽视的，周围大多数用到input子系统的开发人员也不甚理解；另一方面是由于这部分知识一旦扩展到TP(触摸屏Touch Panel)的多点触摸就要与Middleware/Framework一起结合起来看才能完全掌握，复杂性所在。这里的Middleware/Framework是针对android来说的，本人从事android这几个层次的工作，所以就从android的角度来讲讲这部分内容，其他系统虽然代码不同，但原理上是完全一样的。
B协议又称为slot协议，那么input子系统里面使用的slot是什么，A/B协议究竟是如何划分的？
slot直译为位置、槽，有两层含义，一层是位置，另一层是容器。在Input子系统中，它扮演的就是这两个角色。它产生于这样一个背景：
如果从Device获取的当前数据与上一个数据相同，我们有必要再上报当前数据吗？如果我们不管两次数据是否一致都上报，那就是A协议；如果我们选择不上报，那么既然需要比较，总需要把上一次数据存起来吧，slot就是做这个事情的，显然这就是Slot(B)协议。
其实到这里，对TP不感兴趣的童鞋可以不继续向下看了，了解了两个协议的区别看或者写一般模块的代码不会有问题了。需要注意的是，想要测试Device驱动的input部分是否正常的时候，假如使用的是B协议，input_report数据的时候要记得每次都要report不同的值，否则在HAL层是看不到数据不停上报的，因为前后两个数据相同的时候，B协议是不会上报到系统的。另外，在上层测试数据上报频率的时候，采用 数据总量/时间差 的方法，如果驱动采用的是B协议，测试结果也是不准确的。
下面要说的与TP的多点触摸（MT Multi-touch）的功能关系密切，没有兴趣的可以略过。由于这部分代码不从事TP或者android的人是不会接触到的，所以代码就不贴出来了，有兴趣的童鞋可以单独交流O(∩_∩)O~
我们都知道，在支持MT的手机上多指滑动的时候，多条手指滑动过的轨迹彼此是不相交的，这也是我们所期望的。但这个功能究竟是如何实现的呢？看了上面的分析应该就知道，A/B两种协议方式都可以实现该功能。
A协议不会使用slot，多指处理中，它的报点序列如下（每一个序列都以input_report_***函数实现）：
点击(此处)折叠或打开
• ABS_MT_POSITION_X x[0]
• ABS_MT_POSITION_Y y[0]
• SYN_MT_REPORT
• ABS_MT_POSITION_X x[1]
• ABS_MT_POSITION_Y y[1]
• SYN_MT_REPORT
• …
• SYN_REPORT
上面的序列中需要说明的是系统以SYN_MT_REPORT为一个点的信息的结尾，以SYN_REPORT为一次事件的结尾。也就是说多指触摸的时候，android的中间件部分每收到一次SYN_MT_REPORT就形成一个点信息，收到一个点之后并不会立即处理，而是一个事件完成之后才会处理，SYN_REPORT就是这个事件的标志。A协议比较简单，我们也可以发现在上面的序列中根本就没有轨迹跟踪的信息，有的只是点坐标等信息，那么系统如果去判断当前的多个点各属于哪一条线呢？
我们假设前一次事件共有5个点，本次触摸也有5个点，系统会分别计算前一次5个点与本次5个点的距离，distance[prev_i, curr_j] (i=0,1,…,4; j=0,1,…4)，这样会产生总共5*5=25个数字。然后对这25个数字进行排序，android用的是堆排序。（我们在系统上如果用多指，一般最多也是双值，也就是4个数据，这里采用了堆排序，不知是出于什么情况考虑，感觉换个方法可能更实用些。）下面的任务就是判断哪些当前点与前一次的点最近，那么赋予它们相同的id，应用收到这个信息后，就可以知道当前点属于哪条线了。
手抬起来的时候又用什么样的序列来通知系统呢，
点击(此处)折叠或打开
• SYN_MT_REPORT
• SYN_REPORT
只有SYNC，没有其它任何信息，系统就会认为此次事件为UP。
B协议使用了slot，还有一个新面孔TRACKING_ID.
点击(此处)折叠或打开
• ABS_MT_SLOT 0
• ABS_MT_TRACKING_ID **
• ABS_MT_POSITION_X x[0]
• ABS_MT_POSITION_Y y[0]
• ABS_MT_SLOT 1
• ABS_MT_TRACKING_ID **
• ABS_MT_POSITION_X x[1]
• ABS_MT_POSITION_Y y[1]
• SYN_REPORT
没有SYN_MT_REPORT，那么它用什么来跟踪当前点属于哪一条线呢，用的就是ABS_MT_TRACKING_ID，当前序列中某点的ID值，如果与前一次序列中某点的ID值相等，那么他们就属于同一条线。既然如此，那么android系统中还需要做排序等运算吗？当然不需要。那么手指全部抬起的时候序列又是怎样的的
• ABS_MT_SLOT 0
• ABS_MT_TRACKING_ID -1
• SYN_REPORT
• ABS_MT_SLOT 1
• ABS_MT_TRACKING_ID -1
• SYN_REPORT
这里上报的ABS_MT_TRACKING_ID为-1，也只有这里该值才可以小于零，收到该值，系统就会清除对应的ID。看似简单的两个协议内容到这里就分析完毕了。
看了上面的分析，明显可以看出B协议要由于A协议，但事实上并不如此简单。B协议需要硬件上的支持，ID值并不是随便赋值的，而是硬件上跟踪了点的轨迹；如果硬件上满足不了这个条件，那么采用B协议只能闹成笑话。另外，B协议的复杂性如果掌握不好往往会带来一些莫名其妙的问题，比如如果因为某些因素（同步等），在UP的时候少清除了一个slot的信息，那么下次单击的时候你也会惊奇地发现竟然有两个点（采用了B协议，slot已经保存了点信息，除非明确清除）
常用写input 驱动的步骤
@1 input_allocate_device: 申请一个input_dev
@2 __set_bit(FF_RUMBLE, haptics->input_dev->evbit);设置对应的支持的事件的类型,然后设置__set_bit(FF_RUMBLE, haptics->input_dev->ffbit);
@3 赋值open close等函数，主要是做一些打开休眠的动作
@4 input_register_device()
@5 input_report_rel,input_report_abs,input_report_switch或者使用input_event上报数据
测试代码(ubuntu16.04下测试通过)
驱动代码
#include 应用代码
/*
* $Id: evtest.c,v 1.23 2005/02/06 13:51:42 vojtech Exp $
*
* Copyright (c) 1999-2000 Vojtech Pavlik
*
* Event device test program
*/
/*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*
* Should you need to contact me, the author, you can do so either by
* e-mail - mail your message to , or by paper mail:
* Vojtech Pavlik, Simunkova 1594, Prague 8, 182 00 Czech Republic
*/
#include
#define LONG(x) ((x)/BITS_PER_LONG)
#define test_bit(bit, array) ((array[LONG(bit)] >> OFF(bit)) & 1)
int main (int argc, char **argv)
{
int fd, rd, i, j, k;
struct input_event ev[64];
int version;
unsigned short id[4];
unsigned long bit[EV_MAX][NBITS(KEY_MAX)];
char name[256] = "Unknown";
int abs[5];
if (argc < 2) {
printf("Usage: evtest /dev/input/eventX\n");
printf("Where X = input device number\n");
return 1;
}
if ((fd = open(argv[argc - 1], O_RDONLY)) < 0) {
perror("evtest");
return 1;
}
if (ioctl(fd, EVIOCGVERSION, &version)) {
perror("evtest: can't get version");
return 1;
}
printf("Input driver version is %d.%d.%d\n",
version >> 16, (version >> 8) & 0xff, version & 0xff);
ioctl(fd, EVIOCGID, id);
printf("Input device ID: bus 0x%x vendor 0x%x product 0x%x version 0x%x\n",
id[ID_BUS], id[ID_VENDOR], id[ID_PRODUCT], id[ID_VERSION]);
ioctl(fd, EVIOCGNAME(sizeof(name)), name);
printf("Input device name: %s", name);
memset(bit, 0, sizeof(bit));
ioctl(fd, EVIOCGBIT(0, EV_MAX), bit[0]);
printf("Supported events:\n");
for (i = 0; i < EV_MAX; i++)
if (test_bit(i, bit[0])) {
printf(" Event type %d (%s)\n", i, events[i] ? events[i] : "?");
if (!i) continue;
ioctl(fd, EVIOCGBIT(i, KEY_MAX), bit[i]);
for (j = 0; j < KEY_MAX; j++)
if (test_bit(j, bit[i])) {
printf(" Event code %d (%s)\n", j, names[i] ? (names[i][j] ? names[i][j] : "?") : "?");
if (i == EV_ABS) {
ioctl(fd, EVIOCGABS(j), abs);
for (k = 0; k < 5; k++)
if ((k < 3) || abs[k])
printf(" %s %6d\n", absval[k], abs[k]);
}
}
}
printf("Testing ... (interrupt to exit)\n");
while (1) {
rd = read(fd, ev, sizeof(struct input_event) * 64);
if (rd < (int) sizeof(struct input_event)) {
printf("yyy\n");
perror("/nevtest: error reading");
return 1;
}
for (i = 0; i < rd / sizeof(struct input_event); i++)
if (ev[i].type == EV_SYN) {
printf("Event: time %ld.%06ld, -------------- %s ------------\n",
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].code ? "Config Sync" : "Report Sync" );
} else if (ev[i].type == EV_MSC && (ev[i].code == MSC_RAW || ev[i].code == MSC_SCAN)) {
printf("Event: time %ld.%06ld, type %d (%s), code %d (%s), value %02x\n",
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
events[ev[i].type] ? events[ev[i].type] : "?",
ev[i].code,
names[ev[i].type] ? (names[ev[i].type][ev[i].code] ? names[ev[i].type][ev[i].code] : "?") : "?",
ev[i].value);
} else {
printf("Event: time %ld.%06ld, type %d (%s), code %d (%s), value %d\n",
ev[i].time.tv_sec, ev[i].time.tv_usec, ev[i].type,
events[ev[i].type] ? events[ev[i].type] : "?",
ev[i].code,
names[ev[i].type] ? (names[ev[i].type][ev[i].code] ? names[ev[i].type][ev[i].code] : "?") : "?",
ev[i].value);
}
}
}