Linux Input子系统

先贴代码：

//input.c
int input_register_handler(struct input_handler *handler)
{
    //此处省略很多代码

    list_for_each_entry(dev, &input_dev_list, node)
        input_attach_handler(dev, handler);

    //此处省略很多代码
    return 0;
}
EXPORT_SYMBOL(input_register_handler);

int input_register_device(struct input_dev *dev)
{
    //此处省略很多代码

    list_for_each_entry(handler, &input_handler_list, node)
        input_attach_handler(dev, handler);

    //此处省略很多代码
}
EXPORT_SYMBOL(input_register_device);

发现相似之处了吗？没错就是这样的，和Linux设备驱动模型的总线、驱动和设备神似：注册一个设备就去匹配驱动，注册一个驱动就去匹配设备。

待续……

20170823/20:55:14

439  static int evdev_open(struct inode *inode, struct file *file)
440  {
441      struct evdev *evdev = container_of(inode->i_cdev, struct evdev, cdev);
442      unsigned int bufsize = evdev_compute_buffer_size(evdev->handle.dev);
443      unsigned int size = sizeof(struct evdev_client) +
444                      bufsize * sizeof(struct input_event);
445      struct evdev_client *client;
446      int error;
447  
448      client = kzalloc(size, GFP_KERNEL | __GFP_NOWARN);
449      if (!client)
450          client = vzalloc(size);
451      if (!client)
452          return -ENOMEM;
453  
454      client->bufsize = bufsize;
455      spin_lock_init(&client->buffer_lock);
456      client->evdev = evdev;
457      evdev_attach_client(evdev, client);//edev是client的父类
458  
459      error = evdev_open_device(evdev);
460      if (error)
461          goto err_free_client;
462  
463      file->private_data = client;
464      nonseekable_open(inode, file);
465  
466      return 0;
467  
468   err_free_client:
469      evdev_detach_client(evdev, client);
470      kvfree(client);
471      return error;
472  }

【http://blog.chinaunix.net/uid-20776117-id-3212124.html】

evdev 输入事件驱动,为输入子系统提供了一个默认的事件处理方法。其接收来自底层驱动的大多数事件,并使用相应的逻辑对其进行处理。evdev 输入事件驱动从底层接收事件信息,将其反映到 sys 文件系统中,用户程序通过对 sys 文件系统的操作,就能够达到处理事件的能力。下面先对 evdev 的初始化进行简要的分析。

……

【http://www.zhimengzhe.com/linux/266467.html】

在事件处理层()中结构体evdev_client定义了一个环形缓冲区(circular buffer)，其原理是用数组的方式实现了一个先进先出的循环队列(circular queue)，用以缓存内核驱动上报给用户层的input_event事件。

struct evdev_client {
    unsigned int head;                  // 头指针
    unsigned int tail;                  // 尾指针
    unsigned int packet_head;           // 包指针
    spinlock_t buffer_lock; 
    struct fasync_struct *fasync;
    struct evdev *evdev;
    struct list_head node;
    unsigned int clk_type;
    bool revoked;
    unsigned long *evmasks[EV_CNT];
    unsigned int bufsize;               // 循环队列大小
    struct input_event buffer[];        // 循环队列数组
};

……

上述出现了ringbuffer，臆测已经开始向应用程序适配了。

【转载】

输入输出是用户和产品交互的手段，因此输入驱动开发在Linux驱动开发中很常见。同时，input子系统的分层架构思想在linux驱动设计中极具代表性和先进性，因此对Linux input子系统进行深入分析很有意义。

本文继续在《Linuxinput子系统分析之一：软件分层》的基础上继续深入研究Linux输入子系统的分层架构思想以及其实现。软件分层探讨的是输入消息从底层硬件到内核、应用层的消息传递和使用过程，而本文则是专注剖析Linux内核驱动层对输入设备的抽象分层管理和实现。

一、input子系统知识点回顾

详细请看《Linux input子系统分析之一：软件分层》一文。输入子系统对linux的输入设备驱动进行了高度抽象，最终分成了三层，包括input核心层、input事件处理层和input设备驱动层。input核心层（input-core）对input设备（input-device）和input事件处理（input-handler）进行管理并进行消息转发。如下图：

所有的输入设备的主设备号都是13，input-core通过次设备来将输入设备进行分类，如0-31是游戏杆，32-63是鼠标（对应Mouse Handler）、64-95是事件设备（如触摸屏，对应Event Handler）。

二、input核心层的任务

核心层input-core完成的工作包括：

1）直接跟字符设备驱动框架交互，字符设备驱动框架根据主设备号来进行管理，而input-core则是依赖于次设备号来进行分类管理。Input子系统的所有输入设备的主设备号都是13，其对应input-core定义的structfile_operations input_fops.驱动架构层通过主设备号13获取到input_fops，之后的处理便交给input_fops进行。

2）提供接口供事件处理层（input-handler）和输入设备（input-device）注册，并为输入设备找到匹配的事件处理者。

3）将input-device产生的消息（如触屏坐标和压力值）转发给input-handler，或者将input-handler的消息传递给input-device（如鼠标的闪灯命令）。

三、input子系统初始化

1. input-core初始化

--driver/input/input.c

在设备模型/sys/class目录注册设备类，在/proc/bus/input目录产生设备信息，向字符设备驱动框架注册input子系统的接口操作集合（主设备号13和input_fops）。

2.input-handler初始化

以支持触摸屏TS的event-handler为例说明。

--driver/input/evdev.c

继续展开input_register_handler接口：

--driver/input/input.c

3.input-device初始化

以触摸屏TSC2007为例，该触摸屏是I2C总线接口访问。

--driver/input/touchscreen/tsc2007.c

I2C总线的管理类似于平台总线，在注册I2C设备驱动接口i2c_add_driver中也会匹配其管理的I2C设备链表元素，匹配成功后即会调用i2c_driver的probe接口。有关总线、设备和驱动的关系请参看《从需求的角度去理解Linux：总线、设备和驱动》。

继续跟踪tsc2007_probe之前先看看input-device的数据结构:

继续跟踪tsc2007_probe：

继续展开input_register_device接口：

--driver/input/input.c

4.input-core关联匹配input-device和input-handler

在input_register_handler和input_register_device最后都会使用input_attach_handler接口来匹配输入设备和对应的事件处理者。

继续跟踪evdev_connect:

--driver/input/evdev.c

Struct evdev evdev_table代表evdev_handler所管理的底层input-device（通过input-handle管理）和应用层已打开该设备的进程、同步的相关结构和消息队列（evdev_client记录）。

input-handle关联input-device和input-handler一目了然。

所以input_register_handle的接口很容易想到是通过input-handle通过自身的d-node和h-node关联到input-device和input-handler实例中。这样通过input-handler可以快速找到input-device，通过input-device也可以快速找到input-handler。

至于evdev_install_chrdev即是将一个evdev实例记录到evdev_table数组，宣告其存在。

至此，我们可以得到以下evdev-handler管理下的示意图：

四、应用open过程

假设触摸屏驱动在注册输入设备过程中生成/dev/input/event0设备文件。我们来跟踪打开这个设备的过程。

Open(“/dev/input/event0”)

1.vfs_open打开该设备文件，读出文件的inode内容，得到主设备号13和次设备号64.

2.chardev_open 字符设备驱动框架的open根据主设备号13得到输入子系统的input_fops操作集。

3.input_fops->open, 即input_open_file

4.继续跟踪input-handler层的evdev-open，至此evdev不仅关联了底层具体的input-device，而且记录了应用层进程打开该设备的信息。之后input-device产生的消息可以传递到evdev的client中的消息队列。便于上层读取。

5. input-device层的open。

实际上，tsc2007驱动并没有定义input_dev的open接口。

五、触屏消息传递过程

1. open获得的fd句柄对应的file_operations是evdev_handler的evdev_fops。因此read接口最终会调用到evdev_fops的read接口，即evdev_read。接下来我们来跟踪这个接口的实现过程。我们先看看struct evdev的成员evdev_client的定义，其即是代表打开该输入设备的进程相关的数据结构。