Android 输入系统架构 笔记3

Input设备在内核中的注册过程

在linux系统中，输入设备的结构体名是input_dev,在编写输入设备驱动时，我们需要给设备分配一个input_dev结构体，并使用input_allocate_device函数给设备分配内存空间，并初始化设备的结构体。

    

Kernel/drivers/input/input.c
 
struct input_dev *input_allocate_device(void)
{
struct input_dev *dev;   
dev = kzalloc(sizeof(struct input_dev), GFP_KERNEL);

if (dev) {  
dev->dev.type = &input_dev_type;    
dev->dev.class = &input_class;
device_initialize(&dev->dev);        
mutex_init(&dev->mutex);
spin_lock_init(&dev->event_lock);       
INIT_LIST_HEAD(&dev->h_list);    
INIT_LIST_HEAD(&dev->node);       
__module_get(THIS_MODULE);    
}      
return dev; 
}

分配好了input_dev结构体所要的内存后,将dev的成员赋值初始化后就可以调用内核API input_register_device来向input子系统注册。

Kernel/drivers/input/input.c
 
int input_register_device(struct input_dev *dev)
{
……
error = device_a
dd(&dev->dev);
……
list_add_tail(&dev->node, &input_dev_list);
……
list_for_each_entry(handler, &input_handler_list, node)      
input_attach_handler(dev, handler);
……
}

设备的注册还是和所有的linux设备注册一样调用device_add将设备注册进linux设备模型。同时将设备添加到linux内核全局链表input_dev_list。然后通过list_for_each_entry来为设备找到属于自己的handler。介绍下linux的input子系统的三个重要概念input_dev(代表一个input设备)input_handler(响应并处理input事件)input_handle(像个红娘一样将input设备和对应的input_handler连接在一起其中就包含一个input_dev和input_handler的链表)。 

Input_handler的注册过程

一般来说input_handler的注册会在input_dev之前来注册常见的input_handler，有mousedev handler(处理来自鼠标类的input事件)、joydev_handler(处理摇杆类事件)、kdev_handler(处理来自键盘类事件)，evdev_handler(响应绝大部门的事件默认的input处理事件)。先看input的handler的注册函数API input_register_handler。 

Kernel/drivers/input/input.c
 
int input_register_handler(struct input_handler *handler) 
{
……
INIT_LIST_HEAD(&handler->h_list);
if (handler->fops != NULL) {
if (input_table[handler->minor >> 5]) {
retval = -EBUSY;  
goto out;
}

input_table[handler->minor >> 5] = handler;
}
……
list_add_tail(&handler->node, &input_handler_list);
list_for_each_entry(dev, &input_dev_list, node)
input_attach_handler(dev, handler);
……
}

函数先初始化了input handler在linux内核链表，然后如果handler的文件操作不为空就会为这个handler分配一个次设备号，从handler->minor >> 5，handler通过32为倍数来区分的换句话说每个handler处理的input event不能超过32。现在可以看到无论是设备的注册还是handler注册都会调用input_attach_handler。

static int input_attach_handler(struct input_dev *dev, struct input_handler *handler)
{
……
id = input_match_device(handler, dev);
……
error = handler->connect(handler, dev, id);
……
}

每个handler在注册的时候都有自己的id_table，如果设备和input handler能够匹配成功的话，就会调用input handler的connect函数。在input_match_device中会将input device的id.bus type,id.vendor,id.product和id.version首先匹配。然后会去match的evbit,keybit,relbit,absbit等。

Kernel/drivers/input/input.c
 
static const struct input_device_id *input_match_device(struct input_handler *handler, struct input_dev *dev)
{
……
for (id = handler->id_table; id->flags || id->driver_info; id++) {  
if (id->flags & INPUT_DEVICE_ID_MATCH_BUS)       
if (id->bustype != dev->id.bustype)              
continue;
……
MATCH_BIT(evbit,  EV_MAX);
……
if (!handler->match || handler->match(handler, dev))   
return id;
}
}

如果handler和device能够match的话，就会调用handler的match回调函数，但是在linux input Handler中不是所以的handler都实现了这个回调函数，只有joydev handler实现了。在看看evdev handler的id_table。

Kernel/driver/input/evdev.c
 
static const struct input_device_id evdev_ids[] = {
{ .driver_info = 1 },   /* Matches all devices */
{ },                    /* Termina
ting zero entry */
};

可以看到evdev是作为一个通用的handler去处理input device的事件。也就是说一旦有设备注册就会去调用evdev的connect函数。

Kernel/driver/input/evdev.c
 
static int evdev_connect(struct input_handler *handler, struct input_dev *dev  const struct input_device_id *id)
{
……
evdev = kzalloc(sizeof(struct evdev), GFP_KERNEL);
……
evdev->handle.dev = input_get_device(dev);
evdev->handle.name = dev_name(&evdev->dev)
evdev->handle.handler = handler;
evdev->handle.private = evdev;
evdev->dev.devt = MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor);
evdev->dev.class = &input_class;
evdev->dev.parent = &dev->dev;
evdev->dev.release = evdev_free;
device_initialize(&evdev->dev);
error = input_register_handle(&evdev->handle);
……
error = device_add(&evdev->dev);
……
}

这里面又有个设备注册的过程，重新创建了一个evdev设备，存在于/dev/input/eventX。这就是上面提到的Android上层需要直接操作的文件节点就是在这个时候注册的。
Input_register_handle也只是将匹配好的input设备和input handler分别加到自己的input设备链表和handler链表。

Linux input事件上报流程 

一般input事件在底层上报都是通过中断方式按键或者触摸。以一个具体的触摸屏的驱动为例分析下事件的上报过程。

input_report_abs(dev, ABS_X, MTOUCH_GET_XC(mtouch->data)); 
input_report_abs(dev, ABS_Y, MTOUCH_MAX_YC-MTOUCH_GET_YC(mtouch->data));
input_report_key(dev, BTN_TOUCH, MTOUCH_GET_TOUCHED(mtouch->data));
input_sync(dev)

上面就是一具体触摸屏接收到中断信号，调用中断处理函数来处理事件所调用的方法来完成一次上报事件，以input_sync来表示一次完成的事件上报。在input.h的头文件中这个函数都会统一调用input_event来进行处理。

Kernel/driver/input/input.c
 
void input_event(struct input_dev *dev,unsigned int type, unsigned int code, int value)
{
……
input_handle_event(dev, type, code, value);
……
}
 
static void input_handle_event(struct input_dev *dev, unsigned int type, unsigned int code, int value)
{
……
int disposition = INPUT_IGNORE_EVENT;
……
if (disposition & INPUT_PASS_TO_HANDLERS)         
input_pass_event(dev, type, code, value);
……
}

在input_handle_event函数中会有个disposition的变量来判定事件是交由谁来处理，有交给device来处理，handler处理和device和handler共同处理。一般大部分情况都是交给handler来处理。也就是说会又input_pass_event函数来继续处理。

Kernel/driver/input/input.c
 
static void input_pass_event(struct input_dev *dev,unsigned int type, unsigned int code, int value)
{
…
…
handle = rcu_dereference(dev->grab);
if (handle)     
handle->handler->event(handle, type, code, value);
……
}

在之前的handler或者device注册的时候，每当一个device和handler发生匹配都会注册一个handle，然后将handler和device都加到自己链表中，这时候就可以通过hand来调用handler的event函数。 

Kernel/driver/input/evdev.c
 
static struct input_handler evdev_handler = {
.event  = evdev_event,
……
}
 
static void evdev_event(struct input_handle *handle,  unsigned int type, unsigned int code, int value)
{
struct evdev_client *client;
……
client = rcu_dereference(evdev->grab);
if (client)
evdev_pass_event(client, &event);
……
if (type == EV_SYN && code == SYN_REPORT)   
wake_up_interruptible(&evdev->wait);
……
}
 
static void evdev_pass_event(struct evdev_client *client, struct input_event *event)
{
……
client->buffer[client->head++] = *event;
……
}

这里有个叫evdev_client的关键结构体，我们比较关注里面的3个结构体成员，client->buffer这个是用来存放input event事件。而head和client是用来标识input HAL也就是前面eventHub读的时候会不会阻塞的条件。这里有个type==EV_SYN也就是标识同步一次input事件，当每接收到一次input事件就会去唤醒一次evdev->wait。说道这里还是看看evdev->wait是在哪里阻塞的。 

Kernel/driver/input/evdev.c
 
static ssize_t evdev_read(struct file *file, char __user *buffer,size_t count, loff_t *ppos)
{
……
if (!(file->f_flags & O_NONBLOCK)) {    
retval = wait_event_interruptible(
evdev->wait,                
client->packet_head != client->tail || !evdev->exist);
                
if (retval)              
return retval;
}
 
while (retval + input_event_size() <= count && evdev_fetch_next_event(client, &event)) {               
if (input_event_to_user(buffer + retval, &event))                        
return -EFAULT;        
retval += input_event_size();
}
 
static int evdev_fetch_next_event(struct evdev_client *client, struct input_event *event)
{
……
if (have_event) {  
*event = client->buffer[client->tail++];
client->tail &= client->bufsize-1;
if (client->head == client->tail)
wake_unlock(&client->wake_lock);
}
……
}

等待队列唤醒的条件是client->tail和client->packet_head不相等，初始化的时候两个都为0，也就是说如果没有input事件上报的话，这个读事件是一直阻塞的。当有input事件上报就会掉到evdev_pass_event中并且将client->head++。这样head和tail就不相等了，满足了唤醒条件，然后调用wake_up_interruptible(&evdev->wait)就可以唤醒之前eventHub读的时候阻塞的进程通过input_event_to_user。就可以将input事件从内核空间拷贝到用户态空间。从而完成了数据的传递。当然了为了达到同步，每处理完一次事件后，就会继续阻塞使进程睡眠，需要一个同步的工作，evdev_fetch_next_event会将client->tail++。这样他们有相等了可以继续满足睡眠的条件等待下一次的input事件上报将进程唤醒。