Input and output are the means of interaction between users and products, so input-driven development is very common in Linux-driven development. At the same time, the hierarchical architecture of the input subsystem is very representative and advanced in Linux driver design, so it is meaningful to conduct an in-depth analysis of the Linux input subsystem.
This article continues to study the hierarchical architecture idea of Linux input subsystem and its implementation on the basis of " Analysis of Linux Input Subsystem One: Software Layering ". Software layering discusses the message transmission and use process of input messages from the underlying hardware to the kernel and application layer. This article focuses on analyzing the abstract layered management and implementation of input devices by the Linux kernel driver layer.
1. A review of the knowledge points of input subsystem
For details, please see the article " Analysis of Linux Input Subsystem One: Software Layering ". The input subsystem highly abstracts the input device driver of Linux, and is finally divided into three layers, including the input core layer, the input event processing layer and the input device driver layer. The input core layer (input-core) manages the input device (input-device) and input event processing (input-handler) and forwards messages. As shown below:
The major device number of all input devices is 13, input-core classifies input devices through secondary devices, such as 0-31 is a joystick, 32-63 is a mouse (corresponding to Mouse Handler), and 64-95 is an event device (Such as touch screen, corresponding to Event Handler).
Second, the task of the input core layer
The work done by the core layer input-core includes:
1) Directly interact with the character device driver framework. The character device driver framework manages according to the major device number, while the input-core relies on the minor device number for classification management. The main device number of all input devices of the Input subsystem is 13, which corresponds to the structfile_operations input_fops defined by input-core. The driver architecture layer obtains input_fops through the main device number 13, and the subsequent processing is handed over to input_fops.
2) Provide an interface for the event processing layer (input-handler) and input device (input-device) to register, and find a matching event handler for the input device.
3) Forward the message (such as touch screen coordinates and pressure value) generated by the input-device to the input-handler, or pass the message of the input-handler to the input-device (such as the flashing light command of the mouse).
Three, input subsystem initialization
1. Input-core initialization
--driver/input/input.c
Register the device class in the device model /sys/class directory, generate device information in the /proc/bus/input directory, and register the input subsystem interface operation set (main device number 13 and input_fops) with the character device driver framework.
2.input-handler initialization
Take event-handler that supports touch screen TS as an example.
--driver/input/evdev.c
Continue to expand the input_register_handler interface:
--driver/input/input.c
3.input-device initialization
Take the touch screen TSC2007 as an example. The touch screen is accessed via the I2C bus interface.
--driver/input/touchscreen/tsc2007.c
The management of the I2C bus is similar to the platform bus. In the registered I2C device driver interface i2c_add_driver, it will also match the I2C device linked list elements it manages. After the match is successful, the probe interface of i2c_driver will be called. For the relationship between buses, devices, and drivers, please refer to "Understanding Linux from the Perspective of Requirements: Buses, Devices, and Drivers."
继续跟踪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的定义，其即是代表打开该输入设备的进程相关的数据结构。
2. evdev_read
3. 假设消息队列为空时，则上层进程将会睡眠，直到被唤醒再进行消息读取。谁来唤醒它呢？由底层input-device的硬件中断发起，最终将触屏消息送达该消息队列后即会发出唤醒信号。tsc2007_probe中注册的外部硬件中断服务函数即是发起者。
来看看该中断服务函数tsc2007_irq：
ts-work即是tsc2007_work：
跟踪input_report_abs接口：
继续跟进evdev_event:
即会唤醒执行在evdev_read中等待读取消息的进程，继续下面的执行过程，从client的buffer中取出消息，并通过copy_to_user返回给应用程序。
有一点需要注意，每次触屏消息产生后，在tsc2007_work中要input-report-abs报告x坐标，y坐标和压力值，最后再通过input-sync接口发出同步事件，向上层应用发出异步通知进行读取。