Linux输入子系统框架分析(1)
2017-04-09 13:45
543 查看
在Linux下的输入设备键盘、触摸屏、鼠标等都能够用输入子系统来实现驱动。输入子系统分为三层,核心层和设备驱动层。事件层。核心层和事件层由Linux输入子系统本身实现,设备驱动层由我们实现。我们在设备驱动层将输入事件上报给核心层input.c,核心层找到匹配的事件层,将事件交给事件层处理,事件层处理完后传递到用户空间。
我们终于要搞清楚的是在用户空间调用open和read终于在内核中是如何处理的,向内核上报的事件又是谁处理的,处理完后是如何传递到用户空间的?
![](http://my.csdn.net/uploads/201205/14/1337005184_8437.jpg)
![](https://pic002.cnblogs.com/images/2012/289617/2012022512004698.jpg)
上面两个图是输入子系统的框架。
以下以按键驱动为例分析输入子系统的工作流程。
设备驱动层:
在设备驱动层的init入口函数中调用input_allocate_device(),分配返回一个input_dev结构体,填充该结构体,调用input_register_device(button_dev),注冊设备。跟踪input_register_device例如以下:
list_add_tail(&dev->node, &input_dev_list);将input_dev结构体放进input_dev_list链表中
list_for_each_entry(handler, &input_handler_list, node)遍历input_handler_list链表中的每个handler
input_attach_handler(dev, handler);将input_dev和handler比較
input_match_device(handler->id_table, dev);<*input.c*>
handler->connect(handler, dev, id);<*input.c*>比較的方式是通过对照handler的id_table和input_dev。若找
到匹配的handler。则调用handler的connect方法。
在evdev_connect(struct input_handler *handler, struct input_dev *dev,const struct input_device_id *id)中调用了
input_register_handle,调用handle之前填充handle中成员dev和handler结构体。
evdev->handle.dev = input_get_device(dev);
evdev->handle.handler = handler;
在input_register_handle中list_add_tail_rcu(&handle->d_node, &dev->h_list)list_add_tail(&handle->h_node, &h andler->h_list)两个函数将handle增加进handler和dev的h_list链表中。
通过dev->h_list能够找到handle。通过
handle找到handle.handler,同理。通过handler->h_list能够找到handle,再找到handle.dev。
关键的问题来了?handler究竟是什么?由谁注冊的?handler是事件层调用核心层的函数注冊的。
事件层:(evdev.c,keyboard.c,ts.c)
static struct input_handler evdev_handler = {//handler结构体
.event
= evdev_event,
.connect
= evdev_connect,
.disconnect
= evdev_disconnect,
.fops = &evdev_fops,
.minor
= EVDEV_MINOR_BASE,
.name = "evdev",
.id_table
= evdev_ids,
};
在evdev_init(void)入口函数中调用input_register_handler(&evdev_handler)来注冊handler,注冊的handler会放入input_table[ ]数组中。
核心层:(input.c)
核心层的入口函数input_init(void)注冊设备input。
当在应用层调用open时会在内核中调用input_open_file(struct inode *inode, struct file *file)。依据handler =
input_table[iminor(inode) >> 5];依据打开的文件的次设备号从数组input_table中得到已注冊的相应的handler。
new_fops = fops_get(handler->fops)从handler中得到新的fop。
file->f_op = new_fops;
err = new_fops->open(inode, file);open终于调用的是handler->fops->open。
原来的设备驱动的open等方法是自
己写的。如今输入子系统中的事件层帮我们写好了open等设备方法。同理在应用层调用read会调用事件层中的
read。即handler->fops->read,即evdev_fops.read,在read中会堵塞。直到在设备驱动层中过input_report_key
上报事件:
input_event(dev, EV_KEY, code, !!value);
input_handle_event(dev, type, code, value);
input_pass_event(dev, type, code, value);
handle->handler->event(handle,type, code, value);调用handler中的event事件方法。处理完上报的事
件后,唤醒休眠的read,再read出事件的处理结果。
总结:
在用户空间调用open将终于调用事件层中handler的fops的open设备方法。详细是匹配到evdev.c还是keyboard.c的handler要依据设备驱动init入口函数中填充的input_dev结构体的id_table。
用户空间调用read将调用handler的read。
在设备驱动中通过input_event上报事件到核心层。终于调用相应的handler的event方法来处理事件,处理完后通过read传递到用户空间。
这样就搞清楚了open是谁调用的?read是谁调用的?
我们终于要搞清楚的是在用户空间调用open和read终于在内核中是如何处理的,向内核上报的事件又是谁处理的,处理完后是如何传递到用户空间的?
![](http://my.csdn.net/uploads/201205/14/1337005184_8437.jpg)
![](https://pic002.cnblogs.com/images/2012/289617/2012022512004698.jpg)
上面两个图是输入子系统的框架。
以下以按键驱动为例分析输入子系统的工作流程。
设备驱动层:
在设备驱动层的init入口函数中调用input_allocate_device(),分配返回一个input_dev结构体,填充该结构体,调用input_register_device(button_dev),注冊设备。跟踪input_register_device例如以下:
list_add_tail(&dev->node, &input_dev_list);将input_dev结构体放进input_dev_list链表中
list_for_each_entry(handler, &input_handler_list, node)遍历input_handler_list链表中的每个handler
input_attach_handler(dev, handler);将input_dev和handler比較
input_match_device(handler->id_table, dev);<*input.c*>
handler->connect(handler, dev, id);<*input.c*>比較的方式是通过对照handler的id_table和input_dev。若找
到匹配的handler。则调用handler的connect方法。
在evdev_connect(struct input_handler *handler, struct input_dev *dev,const struct input_device_id *id)中调用了
input_register_handle,调用handle之前填充handle中成员dev和handler结构体。
evdev->handle.dev = input_get_device(dev);
evdev->handle.handler = handler;
在input_register_handle中list_add_tail_rcu(&handle->d_node, &dev->h_list)list_add_tail(&handle->h_node, &h andler->h_list)两个函数将handle增加进handler和dev的h_list链表中。
通过dev->h_list能够找到handle。通过
handle找到handle.handler,同理。通过handler->h_list能够找到handle,再找到handle.dev。
关键的问题来了?handler究竟是什么?由谁注冊的?handler是事件层调用核心层的函数注冊的。
事件层:(evdev.c,keyboard.c,ts.c)
static struct input_handler evdev_handler = {//handler结构体
.event
= evdev_event,
.connect
= evdev_connect,
.disconnect
= evdev_disconnect,
.fops = &evdev_fops,
.minor
= EVDEV_MINOR_BASE,
.name = "evdev",
.id_table
= evdev_ids,
};
在evdev_init(void)入口函数中调用input_register_handler(&evdev_handler)来注冊handler,注冊的handler会放入input_table[ ]数组中。
核心层:(input.c)
核心层的入口函数input_init(void)注冊设备input。
当在应用层调用open时会在内核中调用input_open_file(struct inode *inode, struct file *file)。依据handler =
input_table[iminor(inode) >> 5];依据打开的文件的次设备号从数组input_table中得到已注冊的相应的handler。
new_fops = fops_get(handler->fops)从handler中得到新的fop。
file->f_op = new_fops;
err = new_fops->open(inode, file);open终于调用的是handler->fops->open。
原来的设备驱动的open等方法是自
己写的。如今输入子系统中的事件层帮我们写好了open等设备方法。同理在应用层调用read会调用事件层中的
read。即handler->fops->read,即evdev_fops.read,在read中会堵塞。直到在设备驱动层中过input_report_key
上报事件:
input_event(dev, EV_KEY, code, !!value);
input_handle_event(dev, type, code, value);
input_pass_event(dev, type, code, value);
handle->handler->event(handle,type, code, value);调用handler中的event事件方法。处理完上报的事
件后,唤醒休眠的read,再read出事件的处理结果。
总结:
在用户空间调用open将终于调用事件层中handler的fops的open设备方法。详细是匹配到evdev.c还是keyboard.c的handler要依据设备驱动init入口函数中填充的input_dev结构体的id_table。
用户空间调用read将调用handler的read。
在设备驱动中通过input_event上报事件到核心层。终于调用相应的handler的event方法来处理事件,处理完后通过read传递到用户空间。
这样就搞清楚了open是谁调用的?read是谁调用的?
相关文章推荐
- 输入服务子系统框架代码分析(韦东山的视频总结及针对linux-2.6.30.4)
- Linux输入子系统框架分析及输入设备驱动编程
- Linux输入子系统框架分析(1)
- LINUX 输入子系统分析
- Linux输入子系统分析(二)
- linux input输入子系统分析《四》:input子系统整体流程全面分析
- linux input输入子系统分析《三》:S3C2440的触摸屏驱动实例
- LINUX 输入子系统架构分析
- Linux输入子系统分析 (1) -- 输入子系统初始化
- linux驱动—input输入子系统—The simplest example(一个最简单的实例)分析(2)
- [完结]Linux内核中的V4L2核心框架分析(V4L2 framework,video for linux 2,linux视频子系统)
- linux input输入子系统分析《一》:初识input输入子系统
- linux input输入子系统分析《二》:s3c2440的ADC简单驱动实例分析
- Linux输入子系统分析(三)
- linux设备之输入子系统框架及API
- Linux输入子系统分析(转载)
- Linux输入子系统分析(一)
- Linux输入子系统分析(五)
- Linux输入子系统分析(六)
- Android4.1输入子系统框架介绍和性能分析