2、Linux输入子系统框架：input核心层、input设备驱动层、input事件处理层、设备节点(/dev/input/eventX)

好，咱们今天聊聊Linux输入子系统的框架。说实话，这个框架我研究了很久，刚接触那会儿也觉得挺绕的。但搞明白之后，你会发现它设计得非常巧妙。

Linux输入子系统，说白了就是一套标准化的"输入管理方案"。它把触摸屏、键盘、鼠标这些乱七八糟的输入设备，统一管理起来。你想想看，如果没有这个框架，每个驱动都得自己想办法把数据送到用户空间，那得多乱？

我个人习惯把输入子系统分成三层来理解：核心层、设备驱动层、事件处理层。咱们一层一层拆开看。

2.1 三层架构总览

先看一张我手绘的架构图（嗯，虽然这里没法画图，但我用文字描述一下）：

用户空间应用程序（如Qt、Wayland）
        ↑
  设备节点 /dev/input/eventX
        ↑
┌─────────────────────────────┐
│   事件处理层 (Event Handler) │  → evdev.c, joydev.c, mousedev.c
├─────────────────────────────┤
│   输入核心层 (Input Core)    │  → input.c, input-compat.c
├─────────────────────────────┤
│   设备驱动层 (Device Driver) │  → 你的触摸屏驱动、键盘驱动等
└─────────────────────────────┘
        ↑
   硬件设备（触摸屏、键盘等）

这个结构，我称之为"三明治架构"。上下两层是具体的，中间是抽象的。我在项目中遇到过不少新手，一上来就扎进驱动层写代码，结果对上层怎么处理数据完全没概念，最后调试起来特别痛苦。

2.2 设备驱动层——最底层的"搬运工"

这一层离硬件最近。你的触摸屏驱动就属于这一层。

驱动层的核心任务就两个：

• 注册输入设备：告诉内核"我这儿有个输入设备，它长什么样"
• 上报输入事件：当硬件有动静时，把数据扔给核心层

看个最简单的例子，我写触摸屏驱动时常用的注册流程：

// 1. 分配一个input_dev结构体
struct input_dev *touch_dev = input_allocate_device();

// 2. 设置设备支持的事件类型和按键码
set_bit(EV_ABS, touch_dev->evbit);      // 支持绝对坐标
set_bit(EV_KEY, touch_dev->evbit);      // 支持按键事件
set_bit(BTN_TOUCH, touch_dev->keybit);  // 触摸按键

// 3. 设置触摸屏的坐标范围
input_set_abs_params(touch_dev, ABS_X, 0, 1024, 0, 0);
input_set_abs_params(touch_dev, ABS_Y, 0, 768, 0, 0);

// 4. 注册设备
input_register_device(touch_dev);

这里有个坑，我曾经踩过：事件类型的bit位一定要设置对。有一次我忘了设置EV_ABS，结果坐标数据死活报不上去，查了两天才发现是这里的问题。

2.3 输入核心层——承上启下的"调度中心"

核心层在drivers/input/input.c里。它不直接跟硬件打交道，也不直接跟用户空间打交道。它的角色是"中间人"。

核心层主要干这几件事：

• 管理所有注册进来的输入设备
• 管理所有注册进来的事件处理器
• 把设备驱动上报的事件，分发给对应的事件处理器

我记得核心层里有个很重要的函数——input_event()。设备驱动上报数据时，最终都会调用它。它的内部逻辑大概是这样的：

void input_event(struct input_dev *dev, 
                 unsigned int type, 
                 unsigned int code, 
                 int value)
{
    // 1. 检查设备是否支持该事件类型
    if (!test_bit(type, dev->evbit))
        return;

    // 2. 把事件放入缓冲区
    // 3. 通知所有关联的事件处理器
    // 4. 唤醒等待数据的进程
}

你想想看，核心层就像一个交换机。设备驱动把数据扔进来，核心层根据设备类型，把数据转发给对应的事件处理器。这个设计，说白了就是"发布-订阅"模式。

2.4 事件处理层——连接用户空间的"桥梁"

这一层，用户空间能直接感受到。最常见的实现是evdev。

事件处理层做的事情：

• 为每个输入设备创建一个/dev/input/eventX节点
• 把内核事件转换成用户空间能读的数据结构
• 管理用户空间的读/写/ioctl操作

用户空间读到的数据结构长这样：

struct input_event {
    struct timeval time;  // 时间戳
    __u16 type;           // 事件类型（EV_ABS, EV_KEY等）
    __u16 code;           // 事件码（ABS_X, BTN_TOUCH等）
    __s32 value;          // 事件值（坐标值、按键状态等）
};

每个事件固定16字节。我调试触摸屏时，经常用hexdump /dev/input/event0来裸看数据流。嗯，这个方法虽然土，但特别管用。

2.5 设备节点 /dev/input/eventX 的秘密

这个节点是怎么来的？

当你的驱动调用input_register_device()时，核心层会：

1. 分配一个次设备号（64 + X，X从0开始）
2. 调用事件处理层的connect函数
3. 事件处理层创建对应的设备节点

所以，/dev/input/event0、event1、event2... 这些节点的顺序，取决于设备注册的顺序。我曾经遇到过一个问题：系统启动后触摸屏是event0，但插上USB键盘后，触摸屏变成了event1。应用程序写死了event0，结果就出问题了。

2.6 数据流全景——从触摸到响应

咱们把整个流程串起来，看看一次触摸操作是怎么走完的：

步骤	发生位置	具体动作
1	硬件	手指按下，触摸屏产生中断
2	设备驱动层	中断服务程序读取坐标，调用input_report_abs()上报
3	输入核心层	input_event()处理事件，分发给evdev
4	事件处理层	evdev把事件放入缓冲区，唤醒用户空间进程
5	用户空间	应用程序通过read()读取input_event结构体
6	应用程序	解析事件，更新UI或执行操作

2.7 小结

Linux输入子系统的三层架构，其实不复杂。你只要记住：

• 设备驱动层：负责跟硬件对话，上报原始数据
• 输入核心层：负责调度，把数据分发给正确的处理器
• 事件处理层：负责翻译，把内核数据变成用户空间能读的格式

搞明白这个框架，后面写触摸屏驱动就顺了。下一章，咱们会深入设备驱动层，手把手写一个触摸屏驱动。到时候，你会看到这些概念是怎么落地的。