linux输入子系统分析

首先从handler分析,我们看注册了的handler有那些,joydev.c(游戏杆事件),mousedev.c(鼠标事件),evdev.c(通用的触摸屏,按键,sensor等事件),keyboard.c(usb,ps2键盘事件),这里选一个我们最常用的evdev.c分析,在drivers/input/evdev.c中:

    1002 static struct input_handler evdev_handler = {
    1003     .event      = evdev_event,
    1004     .connect    = evdev_connect,                                                                                      
    1005     .disconnect = evdev_disconnect,
    1006     .fops       = &evdev_fops,
    1007     .minor      = EVDEV_MINOR_BASE,
    1008     .name       = "evdev",
    1009     .id_table   = evdev_ids,
    1010 };
    1011 
    1012 static int __init evdev_init(void)
    1013 {
    1014     return input_register_handler(&evdev_handler);
    1015 }


1003行event就表示该handler处理事件的能力,所有注册到该handler的触摸屏,按键,sensor等上报事件时,都是经过它来处理并上报到用户空间的。先从1014行开始:
    1936 int input_register_handler(struct input_handler *handler)
    1937 {
    1938     struct input_dev *dev;
    1939     int retval;
    1940 
    1941     retval = mutex_lock_interruptible(&input_mutex);
    1942     if (retval)
    1943         return retval;
    1944 
    1945     INIT_LIST_HEAD(&handler->h_list);
    1946 
    1947     if (handler->fops != NULL) {
    1948         if (input_table[handler->minor >> 5]) {
    1949             retval = -EBUSY;
    1950             goto out;
    1951         }
    1952         input_table[handler->minor >> 5] = handler;
    1953     }
    1954     
    1955     list_add_tail(&handler->node, &input_handler_list);
    1956 
    1957     list_for_each_entry(dev, &input_dev_list, node)
    1958         input_attach_handler(dev, handler);
    1959 
    1960     input_wakeup_procfs_readers();
    1961     
    1962  out:
    1963     mutex_unlock(&input_mutex);
    1964     return retval;
    1965 }   


1947行不为NULL,所以将该input_handler放到input_table数组中,其中input_table的定义和handler->minor的值为:
    static struct input_handler *input_table[8];
    #define EVDEV_MINOR_BASE    64
从input_table数组的大小可以看出,linux子系统最多可以注册8个handler,那么每个handler可以处理多少个设备呢,难道和minor >> 5有关,32个?接着往下看就知道了。接着1955行,将改handler加入input_handler_list链表中,input_handler_list链表维护着所有注册到输入子系统的handler。1957行,input_dev_list为所有注册了的input_dev链表(我们后面会看到这一点),list_for_each_entry遍历所有的input_dev,看看这些input_dev是否和该handler匹配,这里假设是input_handler先注册的,所有的input_dev都还没有注册,所以这里input_dev_list为空,这样input_register_handler注册就完成了。
接着看看input_dev的注册过程,就拿一个具体的按键事件分析,在drivers/input/keyboard/imapx800_gpio.c中:
    struct input_dev *input;
    input = input_allocate_device();
    525     input->name = "imap-gpio";
    526     input->phys = "imap-gpio/input0";
    527     input->dev.parent = &pdev->dev;
    528 
    529     input->id.bustype = BUS_HOST;
    530     input->id.vendor = 0x0001;
    531     input->id.product = 0x0001;
    532     input->id.version = 0x0100;
    533     
    534     error = input_register_device(input);
input_allocate_device():
    1660 struct input_dev *input_allocate_device(void)
    1661 {
    1662     struct input_dev *dev;
    1663 
    1664     dev = kzalloc(sizeof(struct input_dev), GFP_KERNEL);
    1665     if (dev) {
    1666         dev->dev.type = &input_dev_type;
    1667         dev->dev.class = &input_class;
    1668         device_initialize(&dev->dev);
    1669         mutex_init(&dev->mutex);
    1670         spin_lock_init(&dev->event_lock);
    1671         INIT_LIST_HEAD(&dev->h_list);
    1672         INIT_LIST_HEAD(&dev->node);
    1673    
    1674         __module_get(THIS_MODULE); 
    1675     }
    1676   
    1677     return dev;
    1678 } 

527行,这里的dev.parent指向&pdev->dev,pdev为platform_device,看354行的重点部分:
    int input_register_device(struct input_dev *dev)
    {
        ........................
        1866     dev_set_name(&dev->dev, "input%ld",
        1867              (unsigned long) atomic_inc_return(&input_no) - 1);
        1868    
        1869     error = device_add(&dev->dev);
        1870     if (error)
        1871         return error;
        1872    
        1873     path = kobject_get_path(&dev->dev.kobj, GFP_KERNEL);
        1874     pr_info("%s as %s\n",
        1875         dev->name ? dev->name : "Unspecified device",
        1876         path ? path : "N/A");
        1877     kfree(path);
        1878 
        1879     error = mutex_lock_interruptible(&input_mutex);
        1880     if (error) {
        1881         device_del(&dev->dev);
        1882         return error;
        1883     }
        1884    
        1885     list_add_tail(&dev->node, &input_dev_list);
        1886    
        1887     list_for_each_entry(handler, &input_handler_list, node)
        1888         input_attach_handler(dev, handler); 
        ....................
    }


1885行,将该input_dev挂到input_dev_list链表中,该链表前面注册handler的时候就遇到过,所以我们可以发现,不管是先注册handler还是input_dev,他们都会遍历对方的链表,从而进行匹配。看重点的1887行,这里的input_handler_list挂的就是前面evdev.c中的handler,当然还可能有别的handler,如游戏杆等。进入input_attach_handler函数中:
     908 static int input_attach_handler(struct input_dev *dev, struct input_handler *handler)                          
     909 {
     910     const struct input_device_id *id;
     911     int error;
     912 
     913     id = input_match_device(handler, dev);
     914     if (!id)
     915         return -ENODEV;
     916 
     917     error = handler->connect(handler, dev, id);
     918     if (error && error != -ENODEV)
     919         pr_err("failed to attach handler %s to device %s, error: %d\n",
     920                handler->name, kobject_name(&dev->dev.kobj), error);
     921 
     922     return error;
     923 }


913行的input_match_device匹配规则:
     867 static const struct input_device_id *input_match_device(struct input_handler *handler,
     868                             struct input_dev *dev)
     869 {
     870     const struct input_device_id *id;
     871     int i;
     872 
     873     for (id = handler->id_table; id->flags || id->driver_info; id++) {
     874 
     875         if (id->flags & INPUT_DEVICE_ID_MATCH_BUS)                                                            
     876             if (id->bustype != dev->id.bustype)
     877                 continue;
     878 
     879         if (id->flags & INPUT_DEVICE_ID_MATCH_VENDOR)
     880             if (id->vendor != dev->id.vendor)
     881                 continue;
     882 
     883         if (id->flags & INPUT_DEVICE_ID_MATCH_PRODUCT)
     884             if (id->product != dev->id.product)
     885                 continue;
     886 
     887         if (id->flags & INPUT_DEVICE_ID_MATCH_VERSION)
     888             if (id->version != dev->id.version)
     889                 continue;
     890 
     891         MATCH_BIT(evbit,  EV_MAX);
     892         MATCH_BIT(keybit, KEY_MAX);
     893         MATCH_BIT(relbit, REL_MAX);
     894         MATCH_BIT(absbit, ABS_MAX);
     895         MATCH_BIT(mscbit, MSC_MAX);
     896         MATCH_BIT(ledbit, LED_MAX);
     897         MATCH_BIT(sndbit, SND_MAX);
     898         MATCH_BIT(ffbit,  FF_MAX);
     899         MATCH_BIT(swbit,  SW_MAX);
     900 
     901         if (!handler->match || handler->match(handler, dev))
     902             return id;
     903     }
     904 
     905     return NULL;
     906 }


这里873行的handler->id_table为evdev.c中input_handler结构体指向的:
     995 static const struct input_device_id evdev_ids[] = {
     996     { .driver_info = 1 },   /* Matches all devices */
     997     { },            /* Terminating zero entry */
     998 };


可以看到, id->flags为0, id->driver_info为1,所以前面的if条件都不成立了,到901行,这里handler->match为空,所以返回了该id,即handler->id_table。接着handler->connect(handler, dev, id)调用了handler结构体中的connect指向的函数,这里在evdev.c中有定义,所以进入该函数:
     922 static int evdev_connect(struct input_handler *handler, struct input_dev *dev,
     923              const struct input_device_id *id)
     924 {
     925     struct evdev *evdev;
     926     int minor;
     927     int error;
     928 
     929     for (minor = 0; minor < EVDEV_MINORS; minor++)
     930         if (!evdev_table[minor])
     931             break;
     932 
     933     if (minor == EVDEV_MINORS) {
     934         pr_err("no more free evdev devices\n");
     935         return -ENFILE;
     936     }
     937 
     938     evdev = kzalloc(sizeof(struct evdev), GFP_KERNEL);
     939     if (!evdev)
     940         return -ENOMEM;
     941 
     942     INIT_LIST_HEAD(&evdev->client_list);
     943     spin_lock_init(&evdev->client_lock);
     944     mutex_init(&evdev->mutex);
     945     init_waitqueue_head(&evdev->wait);
     946 
     947     dev_set_name(&evdev->dev, "event%d", minor);
     948     evdev->exist = true;                                                                                      
     949     evdev->minor = minor;
     950 
     951     evdev->handle.dev = input_get_device(dev);
     952     evdev->handle.name = dev_name(&evdev->dev);
     953     evdev->handle.handler = handler;
     954     evdev->handle.private = evdev;
     955                                                                                                           
     956     evdev->dev.devt = MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor);
     957     evdev->dev.class = &input_class;
     958     evdev->dev.parent = &dev->dev;
     959     evdev->dev.release = evdev_free;
     960     device_initialize(&evdev->dev);
     961 
     962     error = input_register_handle(&evdev->handle);
     963     if (error)
     964         goto err_free_evdev;
     965 
     966     error = evdev_install_chrdev(evdev);
     967     if (error)
     968         goto err_unregister_handle;
     969 
     970     error = device_add(&evdev->dev);
     971     if (error)
     972         goto err_cleanup_evdev;
     973 
     974     return 0;
     975 
     976  err_cleanup_evdev:
     977     evdev_cleanup(evdev);
     978  err_unregister_handle:
     979     input_unregister_handle(&evdev->handle);
     980  err_free_evdev:
     981     put_device(&evdev->dev);
     982     return error;
     983 }


929行,这里的EVDEV_MINORS定义为:
    #define EVDEV_MINORS        32 
这里就是把input_dev添加到evdev_table数组中,而且933行,我们发现,如果如果添加的input_dev大于32过的话,就不能继续添加了,说明该handler最都只能挂32个设备,也证实了前面的猜想是正确的。
938行创建evdev结构体,该结构体有一个成员input_handle,该handle用来连接handler和input_dev,我们可以从951和953行看到,他保存了handler和input_dev的位置以便后续查找
956行创建设备节点的主设备和从设备号,可以看到,挂在该输入子系统的主设备号是一样的,从设备号从0-255,所以输入子系统最多可以挂256个设备。
接着962行,就是把handle注册进input子系统。996行evdev_install_chrdev将evdev保存起来以便后面用到:
     871 static int evdev_install_chrdev(struct evdev *evdev)
     872 {
     873     /*
     874      * No need to do any locking here as calls to connect and
     875      * disconnect are serialized by the input core
     876      */
     877     evdev_table[evdev->minor] = evdev;                                                                                               
     878     return 0;
     879 }

970经过device_add后,节点就出现在了dev/input目录下面,如event0,event1,event2,event3,编号是按照注册顺序在947行递增的。
接着来看数据的上报过程,首先在上层打开设备节点,如dev/input/event0,我们开看这个过程。用户空间open后,调用drivers/input/input.c的file_operations中的open:
    2146 static const struct file_operations input_fops = {
    2147     .owner = THIS_MODULE,
    2148     .open = input_open_file,
    2149     .llseek = noop_llseek,
    2150 };
2148行input_open_file:
    2106 static int input_open_file(struct inode *inode, struct file *file)
    2107 {
    2108     struct input_handler *handler;
    2109     const struct file_operations *old_fops, *new_fops = NULL;
    2110     int err;
    2111 
    2112     err = mutex_lock_interruptible(&input_mutex);
    2113     if (err)
    2114         return err;
    2115 
    2116     /* No load-on-demand here? */
    2117     handler = input_table[iminor(inode) >> 5];                                                                  
    2118     if (handler)
    2119         new_fops = fops_get(handler->fops);
    2120 
    2121     mutex_unlock(&input_mutex);
    2122 
    2123     /*
    2124      * That's _really_ odd. Usually NULL ->open means "nothing special",
    2125      * not "no device". Oh, well...
    2126      */
    2127     if (!new_fops || !new_fops->open) {
    2128         fops_put(new_fops);
    2129         err = -ENODEV;
    2130         goto out;
    2131     }
    2132 
    2133     old_fops = file->f_op;
    2134     file->f_op = new_fops;
    2135 
    2136     err = new_fops->open(inode, file);
    2137     if (err) {
    2138         fops_put(file->f_op);
    2139         file->f_op = fops_get(old_fops);
    2140     }
    2141     fops_put(old_fops);
    2142 out:
    2143     return err;
    2144 }

2117行,iminor(inode)找到从设备号,由于evdev.c中的handler从设备号码是EVDEV_MINOR_BASE + minor,其中minor为0~31,EVDEV_MINOR_BASE为64,所以从设备号 >> 5后就是1,这样就找到了前面evdev.c中注册的handler。
2119行,取得handler的file_operations结构体;2136行,将open指向了handler中file_operations的open。从这里可以看出,input.c中的open只是起了一个回调函数的作用,最后就是回调各自handler自己实现的file_operations中的open函数。所以进入evdev.c中:
     855 static const struct file_operations evdev_fops = {
     856     .owner      = THIS_MODULE,
     857     .read       = evdev_read,
     858     .write      = evdev_write,
     859     .poll       = evdev_poll,
     860     .open       = evdev_open,                                                                                            
     861     .release    = evdev_release,
     862     .unlocked_ioctl = evdev_ioctl,
     863 #ifdef CONFIG_COMPAT
     864     .compat_ioctl   = evdev_ioctl_compat,
     865 #endif
     866     .fasync     = evdev_fasync,
     867     .flush      = evdev_flush,
     868     .llseek     = no_llseek,
     869 };
860行evdev_open:
     283 static int evdev_open(struct inode *inode, struct file *file)
     284 {
     285     struct evdev *evdev;
     286     struct evdev_client *client;
     287     int i = iminor(inode) - EVDEV_MINOR_BASE;
     288     unsigned int bufsize;
     289     int error;
     290 
     291     if (i >= EVDEV_MINORS)                                                                                             
     292         return -ENODEV;
     293 
     294     error = mutex_lock_interruptible(&evdev_table_mutex);
     295     if (error)
     296         return error;
     297     evdev = evdev_table[i];
     298     if (evdev)
     299         get_device(&evdev->dev);
     300     mutex_unlock(&evdev_table_mutex);
     301 
     302     if (!evdev)
     303         return -ENODEV;
     304 
     305     bufsize = evdev_compute_buffer_size(evdev->handle.dev);
     306 
     307     client = kzalloc(sizeof(struct evdev_client) +
     308                 bufsize * sizeof(struct input_event),
     309              GFP_KERNEL);
     310     if (!client) {
     311         error = -ENOMEM;
     312         goto err_put_evdev;
     313     }
     314 
     315     client->bufsize = bufsize;
     316     spin_lock_init(&client->buffer_lock);
     317     snprintf(client->name, sizeof(client->name), "%s-%d",
     318             dev_name(&evdev->dev), task_tgid_vnr(current));
     319     wake_lock_init(&client->wake_lock, WAKE_LOCK_SUSPEND, client->name);
     320     client->evdev = evdev;
     321     evdev_attach_client(evdev, client);
     322 
     323     error = evdev_open_device(evdev);
     324     if (error)
     325         goto err_free_client;
     326 
     327     file->private_data = client;
     328     nonseekable_open(inode, file);
     329 
     330     return 0;
     331 
     332  err_free_client:
     333     evdev_detach_client(evdev, client);
     334     wake_lock_destroy(&client->wake_lock);
     335     kfree(client);
     336  err_put_evdev:
     337     put_device(&evdev->dev);
     338     return error;
     339 }

     191 static void evdev_attach_client(struct evdev *evdev,                                                               
     192                 struct evdev_client *client)
     193 {
     194     spin_lock(&evdev->client_lock);
     195     list_add_tail_rcu(&client->node, &evdev->client_list);
     196     spin_unlock(&evdev->client_lock);
     197 }

297行,evdev_table在前面connect函数中时候已经分析过,evdev_install_chrdev函数中保存的这里根据minor的值取出对应的evdev,这样我们就可以根据evdev的hanle找到对应的input_dev。307行创建保存上报数据的机构体,后续会分析,321行evdev_attach_client,就是将client添加到client_list链表中,323行,做一些open的处理工作,这样open操作就完成了。
接着用户空间会调用read,poll,ioctl等操作来过去事件,我们来看android最常用的poll + read方法,最终调用evdev.c的file_operations中poll:
     433 static unsigned int evdev_poll(struct file *file, poll_table *wait)                                                               
     434 {
     435     struct evdev_client *client = file->private_data;
     436     struct evdev *evdev = client->evdev;
     437     unsigned int mask;
     438 
     439     poll_wait(file, &evdev->wait, wait);
     440 
     441     mask = evdev->exist ? POLLOUT | POLLWRNORM : POLLHUP | POLLERR;
     442     if (client->packet_head != client->tail)
     443         mask |= POLLIN | POLLRDNORM;
     444 
     445     return mask;
     446 }


439行可以看到,poll操作会阻塞在这里,等待底层的上报事件唤醒。所以我们接着看看底层事件的上报,还是前面的drivers/input/keyboard/imapx800_gpio.c中:
    input_event(ptr->input, EV_KEY, ptr->code, 0);
    input_sync(ptr->input);
其中的详细过层这里就不分析了,最终会调用handler的event方法:
      95 static void evdev_event(struct input_handle *handle,                                                                                 
      96             unsigned int type, unsigned int code, int value)
      97 {
      98     struct evdev *evdev = handle->private;
      99     struct evdev_client *client;
     100     struct input_event event;
     101     struct timespec ts;
     102 
     103     ktime_get_ts(&ts);
     104     event.time.tv_sec = ts.tv_sec;
     105     event.time.tv_usec = ts.tv_nsec / NSEC_PER_USEC;
     106     event.type = type;
     107     event.code = code;
     108     event.value = value;
     109 
     110     rcu_read_lock();
     111 
     112     client = rcu_dereference(evdev->grab);
     113     if (client)
     114         evdev_pass_event(client, &event);
     115     else
     116         list_for_each_entry_rcu(client, &evdev->client_list, node)
     117             evdev_pass_event(client, &event);
     118 
     119     rcu_read_unlock();
     120 
     121     if (type == EV_SYN && code == SYN_REPORT)
     122         wake_up_interruptible(&evdev->wait);
     123 }


104~108行对input_event结构体赋值,这就是最终要上报数据的结构体,114行,最终调用 kill_fasync(&client->fasync, SIGIO, POLL_IN)唤醒异用户空间使用步等待读取事件的进程,这是主动唤醒用户空间的方法,122行,唤醒前面用户空间poll的阻塞,所以回到前面poll阻塞的地方,poll_wait已经被唤醒,用户空间知道有数据上报了,接着会调用read去读取数据,这样就调用了file_operations的evdev_read:
     397 static ssize_t evdev_read(struct file *file, char __user *buffer,                                                               
     398               size_t count, loff_t *ppos)
     399 {
     400     struct evdev_client *client = file->private_data;
     401     struct evdev *evdev = client->evdev;
     402     struct input_event event;
     403     int retval;
     404 
     405     if (count < input_event_size())
     406         return -EINVAL;
     407 
     408     if (!(file->f_flags & O_NONBLOCK)) {
     409         retval = wait_event_interruptible(evdev->wait,
     410              client->packet_head != client->tail || !evdev->exist);
     411         if (retval)
     412             return retval;
     413     }
     414 
     415     if (!evdev->exist)
     416         return -ENODEV;
     417 
     418     while (retval + input_event_size() <= count &&
     419            evdev_fetch_next_event(client, &event)) {
     420 
     421         if (input_event_to_user(buffer + retval, &event))
     422             return -EFAULT;
     423 
     424         retval += input_event_size();
     425     }
     426 
     427     if (retval == 0 && file->f_flags & O_NONBLOCK)
     428         retval = -EAGAIN;
     429     return retval;
     430 }
这里主要就是421行了,把数据拷贝到用户空间,这样整个上报过程就完成了。

你可能感兴趣的:(linux输入子系统分析)