你好！这里是风筝的博客，
欢迎和我一起交流。
（文章写得比较早，当时自己也是一知半解，描述的不好，后来我参考了网上的大量资料，重新写了一篇：嵌入式Linux驱动笔记(二十五)------Input子系统框架）
基于设备驱动分层的思想，其实理解了platform总线，输入子系统也是可以很好理解的。
以kernel 4.8.17为例:
input.c文件:
static char *input_devnode(struct device *dev, umode_t *mode)
{
return kasprintf(GFP_KERNEL, "input/%s", dev_name(dev));
}
struct class input_class = {
.name = "input",
.devnode = input_devnode,
};
static int __init input_init(void)
{
int err;
err = class_register(&input_class);
if (err) {
pr_err("unable to register input_dev class\n");
return err;
}
err = input_proc_init();
if (err)
goto fail1;
err = register_chrdev_region(MKDEV(INPUT_MAJOR, 0),
INPUT_MAX_CHAR_DEVICES, "input");
if (err) {
pr_err("unable to register char major %d", INPUT_MAJOR);
goto fail2;
}
return 0;
fail2: input_proc_exit();
fail1: class_unregister(&input_class);
return err;
}
初始化的工作主要做了：
创建一个input_class类.
在/proc下创建入口项.即/proc/bus/input目录产生设备信息.
注册字符设备input，主设备号为13(#define INPUT_MAJOR13)
至于input_class结构体下的input_devnode，我也不知道干什么的......
值得注意的是注册input设备的时候都是在这个input下，即/dev/input/event0等等......
好吧，input注册后，基于设备驱动分层的思想，总要有设备文件和驱动文件吧，下面可以看下evdev.c文件,(为什么看这个文件?其实我想看gpio_key.c这个文件的，但是这个驱动文件里的probe涉及到设备树，目前还不会搞，脑阔疼......)
evdev.c：
static struct input_handler evdev_handler = {
.event = evdev_event,
.events = evdev_events,
.connect = evdev_connect,
.disconnect = evdev_disconnect,
.legacy_minors = true,
.minor = EVDEV_MINOR_BASE,
.name = "evdev",
.id_table = evdev_ids,
};
static int __init evdev_init(void)
{
return input_register_handler(&evdev_handler);
} 向输入子系统注册驱动handler，注意哦，这里是handler，译为:处理者，
之后还会看到一个词:handle,译为:手柄，这两个不要搞混了。
接下来进入input_register_handler函数:
int input_register_handler(struct input_handler *handler)
{
struct input_dev *dev;
int error;
error = mutex_lock_interruptible(&input_mutex);
if (error)
return error;
INIT_LIST_HEAD(&handler->h_list);
list_add_tail(&handler->node, &input_handler_list);
list_for_each_entry(dev, &input_dev_list, node)
input_attach_handler(dev, handler);
input_wakeup_procfs_readers();
mutex_unlock(&input_mutex);
return 0;
} 初始化h_list链表.
14、15行，重头戏，遍历链表，寻找handler匹配的设备.
跟踪进入input_attach_handler函数:
static int input_attach_handler(struct input_dev *dev, struct input_handler *handler)
{
const struct input_device_id *id;
int error;
id = input_match_device(handler, dev);
if (!id)
return -ENODEV;
error = handler->connect(handler, dev, id);
if (error && error != -ENODEV)
pr_err("failed to attach handler %s to device %s, error: %d\n",
handler->name, kobject_name(&dev->dev.kobj), error);
return error;
} 这里面有一个匹配函数，就像platform总线一样，会把设备和驱动两两匹配起来。
如果匹配成功，这会执行connect函数进行连接(就好比probe函数一样).
设备和驱动是怎么匹配的：
static const struct input_device_id *input_match_device(struct input_handler *handler,
struct input_dev *dev)
{
const struct input_device_id *id;
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;
if (id->flags & INPUT_DEVICE_ID_MATCH_VENDOR)
if (id->vendor != dev->id.vendor)
continue;
if (id->flags & INPUT_DEVICE_ID_MATCH_PRODUCT)
if (id->product != dev->id.product)
continue;
if (id->flags & INPUT_DEVICE_ID_MATCH_VERSION)
if (id->version != dev->id.version)
continue;
if (!bitmap_subset(id->evbit, dev->evbit, EV_MAX))
continue;
if (!bitmap_subset(id->keybit, dev->keybit, KEY_MAX))
continue;
if (!bitmap_subset(id->relbit, dev->relbit, REL_MAX))
continue;
if (!bitmap_subset(id->absbit, dev->absbit, ABS_MAX))
continue;
if (!bitmap_subset(id->mscbit, dev->mscbit, MSC_MAX))
continue;
if (!bitmap_subset(id->ledbit, dev->ledbit, LED_MAX))
continue;
if (!bitmap_subset(id->sndbit, dev->sndbit, SND_MAX))
continue;
if (!bitmap_subset(id->ffbit, dev->ffbit, FF_MAX))
continue;
if (!bitmap_subset(id->swbit, dev->swbit, SW_MAX))
continue;
if (!handler->match || handler->match(handler, dev))
return id;
} 很遗憾，这个match函数我也看不懂他们是怎么具体匹配的..........伤心啊 。
不过据我了解，evdev.c的handler可以适应任何的dev设备，即分配一个input_dev结构体，即使什么都不做，也能和evdev.c的handler匹配成功。而且这个match的时候，即使匹配成功了也没用break跳出，所以会出现一个dev对应多个handler的情况......
当它们匹配成功后，就会调用connect函数.这个connect函数是什么呢，就是之前input_register_handler传入的结构体里的成员，函数如下：
static int evdev_connect(struct input_handler *handler, struct input_dev *dev,
const struct input_device_id *id)
{
struct evdev *evdev;
int minor;
int dev_no;
int error;
/*比较长，省略了一部分代码*/
dev_set_name(&evdev->dev, "event%d", dev_no);
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, 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);
if (error)
goto err_free_evdev;
cdev_init(&evdev->cdev, &evdev_fops);
evdev->cdev.kobj.parent = &evdev->dev.kobj;
error = cdev_add(&evdev->cdev, evdev->dev.devt, 1);
/*比较长，省略了一部分代码*/
return 0;
} 注意第10行，注册input的时候，就是这样会在/dev/input下生成event0、1、2...n.
还有注意handle(不是handler哦) ，之前说过，这里会把dev、name、handler、private通过evdev->handle记录下来，并注册handle(23行,即把dev和handler添加到h_list链表中)，这样通过handle就可以找到dev与handler，实现设备和驱动的连接了。
最后，通过device_add就实现设备的注册了("关于正真设备文件的创建（不是指sys下的文件）， 最终是由device_add函数里头的kobject_uevent(&dev->kobj, KOBJ_ADD)完成的对hotplug_helper的调用的。
如果想了解uevent的详情，可以阅读 《Linux设备模型浅析之uevent篇》或者他的一系列文章。
")
上面讲的是驱动部分，接下来就是设备部分，原理是一样的：
就在input.c文件里的input_register_device函数，方法是一模一样的，
调用:
list_for_each_entry(handler, &input_handler_list, node)
input_attach_handler(dev, handler); 所以说，不管事设备先注册还是驱动先注册，他们都会去寻找、等待自己的另一半(好好的码着代码，突然就虐狗了............)
驱动和设备建立好连接后，怎么用呢？
当然是通过event上报event(事件)到Handler层进行处理，然后提交给用户了。
input_event->input_handle_event->input_pass_values->input_to_handler->handler->events(handle, vals, count);
所以看下evdev.c文件里的evdev_event函数:
static void evdev_event(struct input_handle *handle,
unsigned int type, unsigned int code, int value)
{
struct input_value vals[] = { { type, code, value } };
evdev_events(handle, vals, 1);
} 它会调用evdev_events函数，如下:
static void evdev_events(struct input_handle *handle,
const struct input_value *vals, unsigned int count)
{
struct evdev *evdev = handle->private;
struct evdev_client *client;
ktime_t ev_time[EV_CLK_MAX];
ev_time[EV_CLK_MONO] = ktime_get();
ev_time[EV_CLK_REAL] = ktime_mono_to_real(ev_time[EV_CLK_MONO]);
ev_time[EV_CLK_BOOT] = ktime_mono_to_any(ev_time[EV_CLK_MONO],
TK_OFFS_BOOT);
rcu_read_lock();
client = rcu_dereference(evdev->grab);
if (client)
evdev_pass_values(client, vals, count, ev_time);
else
list_for_each_entry_rcu(client, &evdev->client_list, node)
evdev_pass_values(client, vals, count, ev_time);
rcu_read_unlock();
} 可以看出，刚开始对读操作上锁，防止被干扰，之后进行填充数据，完成之后再解锁。
填充数据由evdev_pass_values函数完成。
evdev_pass_values函数：
static void evdev_pass_values(struct evdev_client *client,
const struct input_value *vals, unsigned int count,
ktime_t *ev_time)
{
struct evdev *evdev = client->evdev;
const struct input_value *v;
struct input_event event;
bool wakeup = false;
if (client->revoked)
return;
event.time = ktime_to_timeval(ev_time[client->clk_type]);
/* Interrupts are disabled, just acquire the lock. */
spin_lock(&client->buffer_lock);
for (v = vals; v != vals + count; v++) {
if (__evdev_is_filtered(client, v->type, v->code))
continue;
if (v->type == EV_SYN && v->code == SYN_REPORT) {
/* drop empty SYN_REPORT */
if (client->packet_head == client->head)
continue;
wakeup = true;
}
event.type = v->type;
event.code = v->code;
event.value = v->value;
__pass_event(client, &event);
}
spin_unlock(&client->buffer_lock);
if (wakeup)
wake_up_interruptible(&evdev->wait);
} 值得注意的是，当事件的类型为EV_SYN、事件代码为SYN_REPORT，并且client->packet_head != client->head(buffer采用的是环形方式存储，即当设备的信息包的头!=设备的头?不知道怎么理解)时,会唤醒 指定的注册在等待队列上的进程.
即通过input_sync函数产生：
static inline void input_sync(struct input_dev *dev)
{
input_event(dev, EV_SYN, SYN_REPORT, 0);
} 当然，这个不是我们现在关心的，先码住，心理默念：会唤醒某个东西，会唤醒某个东西，会唤醒某个东西，，，，，，，我们比较关心__pass_event函数，就是在这个函数里填充消息。
__pass_event函数:
static void __pass_event(struct evdev_client *client,
const struct input_event *event)
{
client->buffer[client->head++] = *event;
client->head &= client->bufsize - 1;
if (unlikely(client->head == client->tail)) {
/*
* This effectively "drops" all unconsumed events, leaving
* EV_SYN/SYN_DROPPED plus the newest event in the queue.
*/
client->tail = (client->head - 2) & (client->bufsize - 1);
client->buffer[client->tail].time = event->time;
client->buffer[client->tail].type = EV_SYN;
client->buffer[client->tail].code = SYN_DROPPED;
client->buffer[client->tail].value = 0;
client->packet_head = client->tail;
}
if (event->type == EV_SYN && event->code == SYN_REPORT) {
client->packet_head = client->head;
kill_fasync(&client->fasync, SIGIO, POLL_IN);
}
} 就这样，将消息填充到了buffer中......
那用户应用程序又怎么操作的？
还记得之前说的evdev_connect函数吗？
里面有一句：cdev_init(&evdev->cdev, &evdev_fops);
chardevice的初始化，evdev_fops如下:
static const struct file_operations evdev_fops = {
.owner = THIS_MODULE,
.read = evdev_read,
.write = evdev_write,
.poll = evdev_poll,
.open = evdev_open,
.release = evdev_release,
.unlocked_ioctl = evdev_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = evdev_ioctl_compat,
#endif
.fasync = evdev_fasync,
.flush = evdev_flush,
.llseek = no_llseek,
}; 终于又回到了我们最熟悉的字符设备的file_operations啊，真是 这里的山路十八弯~不容易啊......
进入read函数看一看，evdev_read：
static ssize_t evdev_read(struct file *file, char __user *buffer,
size_t count, loff_t *ppos)
{
struct evdev_client *client = file->private_data;
struct evdev *evdev = client->evdev;
struct input_event event;
size_t read = 0;
int error;
if (count != 0 && count < input_event_size())
return -EINVAL;
for (;;) {
if (!evdev->exist || client->revoked)
return -ENODEV;
if (client->packet_head == client->tail &&
(file->f_flags & O_NONBLOCK))
return -EAGAIN;
/*
* count == 0 is special - no IO is done but we check
* for error conditions (see above).
*/
if (count == 0)
break;
while (read + input_event_size() <= count &&
evdev_fetch_next_event(client, &event)) {
if (input_event_to_user(buffer + read, &event))
return -EFAULT;
read += input_event_size();
}
if (read)
break;
if (!(file->f_flags & O_NONBLOCK)) {
error = wait_event_interruptible(evdev->wait,
client->packet_head != client->tail ||
!evdev->exist || client->revoked);
if (error)
return error;
}
}
return read;
} 有点长，但是为了最后的胜利，忍了..........
分析下这个函数：
第10行：如果读取的消息不为0且长度小于消息buffer里的长度
第17行：又见环形缓存存储，当信息包的头等于设备的尾时?不知道，估计想描述buffer是否为空时吧，当消息为空并且文件是非阻塞方式打开时，立即返回.......
第31行：最重要的一行了，input_event_to_user这个函数里面会调用copy_to_user函数，把buffer里的数据传输到应用空间，这样，即实现了应用程序的数据读取。
第40行：如果文件不是以非阻塞方式打开，则会执行wait_event_interruptible休眠等待。嘿嘿，还记得之前默念的东西吗，就是这里！！！！别慌，好好睡觉，当input_sync函数调用时，我就来叫你起床，嘿嘿嘿......
好了，写到这里好像写了挺多的了，累了，，，剩下的write、open之类的懒得分析了，套路都是一样的，剩下的自己练练手咯，祝你们成功！
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
