说到evdev handler这个名字，相信大家一定再熟悉不过了，就是那个妻妾成群孩子成堆的家伙，一个让世界上很多男人都望尘莫及的家伙。嫉妒吧，羡慕吧，这些或许都已不重要，为了解解恨，我们还得想办法搞定她跟akm
input设备大妈生下的那个女儿了。不过想搞定他女儿，咱得先搞定她爸。只要她爸开口了，后面的事情可能就好说了一些。不管怎样，还是来熟悉一下这位evdev handle大叔。
static struct input_handler evdev_handler = {
.event = evdev_event,
.connect = evdev_connect,
.disconnect = evdev_disconnect,
.fops = &evdev_fops,
.minor = EVDEV_MINOR_BASE,
.name = "evdev",
.id_table = evdev_ids,
};
其实我们对他里面的几个函数已经有所了解。比如evdev_connect()（上一节刚分析过，不要告诉我你不知道？那样我会很伤心地，）那么evdev_disconnect()顾名思义就是完成相反的动作（抛妻弃女）。.id_table =
evdev_ids（择偶标准），.name = "evdev"孩子的姓，再加一个摇篮编号就是姓名了，显示在/dev相关目录下。.minor=
EVDEV_MINOR_BASE,，还记得第7节中的那一行代码吗？evdev->dev.devt
= MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor);可以看到通过这条代码生成了设备的设备号。好了还剩下两个咚咚我们还不了解的。
即evdev_event,和evdev_fops。evdev_event是么子东西，这里不讲，留个悬念先后面我会详细道来…..我们来看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
};
记忆力好的哥们马上会想到我第一节所说的话了。没错，这就是input子系统为我们提供的那些文件操作集函数函数，还记得鲁迅先生说过什么了吗？不记得的话，建议回头再看看第一节的内容，让他老人家去的安心。没错，我们的应用层开发者最终都会用到它。想泡美眉的哥们绝对要记住这个结构体了，因为只有用到它，才能让这位handler叔的女儿拜倒在你的石榴裙下。
好好把握它，你就可以想打开她的心就打开她的心（open），向往她的内心写东西就可以随便写（write），想从她内心读出很多故事，她就让你读（read），最关键的是，你可以随意操作她（evdev_ioctl）。是不是很high啊。还记得我们第二节中描述的如何关于在linux中把akm这个设备注册成一个input设备吗？不记得的话，可以回头看看。关于那短短的几行代码我们基本上分析完了，不过还有一个没有分析：
input_report_abs(data->input_dev, ABS_RX, rbuf[0]);
input_report_abs(data->input_dev, ABS_RY, rbuf[1]);
input_report_abs(data->input_dev, ABS_RZ, rbuf[2]);
等几行代码。前面提过，他就是向我们的input子系统报告发生的一些事情，然后我们的input 子系统就会把它进行处理，最终提交到我们的应用层，然后就可以用上面的evdev_fops进行读写操作了。整个过程是不是有一些些明白了。
好了，关于这几个函数是如何提交我们的设备信息的，那就要跟前面evdev_handler中那个evdev_event扯上关系了。该来的它终究还是回来的，逃也逃不掉。这就是我们下一节要讨论的东东。