2. 程式人生 > >linux input輸入子系統分析《四》：input子系統整體流程全面分析

linux input輸入子系統分析《四》：input子系統整體流程全面分析

阿新 • • 發佈：2018-03-04
總線 返回值 分代 並不是 事件 等等 lag pri 位置

1 input輸入子系統整體流程

本節分析input子系統在內核中的實現，包括輸入子系統（Input Core），事件處理層（Event Handler）和設備驅動層。由於上節代碼講解了設備驅動層的寫法，因此在開頭部分會從設備驅動層做為線索，分析輸入子系統和事件處理層是如何配合的，最後從用戶角度出發，從“/dev/input/*”接口如何使用輸入子系統提供的服務。

既然需要詳細分析，有一個這樣的流程圖能夠幫助我們在被繞進代碼的過程中，找到出口，你能夠知道你現在位於代碼框架的什麽位置，不會忘記正在分析的代碼的“身份”。其實在初識輸入子系統中已經貼出了這張圖，我們再把它拿出來參考一下吧，見下圖6。

技術分享圖片

圖6 linux輸入子系統事件處理機制

1.1 設備驅動層註冊到input子系統

在上一節分析了S3C2440觸摸屏驅動的代碼，初始化函數定義了struct input_devinput結構體，它用於描述一個輸入子系統設備，任何驅動設備如果想標明自己是輸入設備，都應該通過初始化這樣的結構體，並且調用input_allocate_device（）函數進行註冊。

了解這一過程，需要先看一下structinput_dev結構體的內容：

[cpp] view plaincopy
  1. struct input_dev {
  3. void *private; //輸入設備私有指針，一般指向用於描述設備驅動層的設備結構
  5. const char *name; //提供給用戶的輸入設備的名稱
  6. const char *phys; //提供給編程者的設備節點的名稱
  7. const char *uniq; //指定唯一的ID號，就像MAC地址一樣
  8. struct input_id id; //輸入設備標識ID，用於和事件處理層進行匹配
  10. unsigned long evbit[NBITS(EV_MAX)]; //位圖，記錄設備支持的事件類型
  11. unsigned long keybit[NBITS(KEY_MAX)]; //位圖，記錄設備支持的按鍵類型
  12. unsigned long relbit[NBITS(REL_MAX)]; //位圖，記錄設備支持的相對坐標
  13. unsigned long absbit[NBITS(ABS_MAX)]; //位圖，記錄設備支持的絕對坐標
  14. unsigned long mscbit[NBITS(MSC_MAX)]; //位圖，記錄設備支持的其他功能
  15. unsigned long ledbit[NBITS(LED_MAX)]; //位圖，記錄設備支持的指示燈
  16. unsigned long sndbit[NBITS(SND_MAX)]; //位圖，記錄設備支持的聲音或警報
  17. unsigned long ffbit[NBITS(FF_MAX)]; //位圖，記錄設備支持的作用力功能
  18. unsigned long swbit[NBITS(SW_MAX)]; //位圖，記錄設備支持的開關功能
  20. unsigned int keycodemax; //設備支持的最大按鍵值個數
  21. unsigned int keycodesize; //每個按鍵的字節大小
  22. void *keycode; //指向按鍵池，即指向按鍵值數組首地址
  23. int (*setkeycode)(struct input_dev *dev, int scancode, int keycode); //修改按鍵值
  24. int (*getkeycode)(struct input_dev *dev, int scancode, int *keycode); //獲取按鍵值
  26. struct ff_device *ff; //用於強制更新輸入設備的部分內容
  28. unsigned int repeat_key; //重復按鍵的鍵值
  29. struct timer_list timer; //設置當有連擊時的延時定時器
  31. int state; //設備狀態
  33. int sync; //同步事件完成標識，為1說明事件同步完成
  35. int abs[ABS_MAX + 1]; //記錄坐標的值
  36. int rep[REP_MAX + 1]; //記錄重復按鍵的參數值
  38. unsigned long key[NBITS(KEY_MAX)]; //位圖，按鍵的狀態
  39. unsigned long led[NBITS(LED_MAX)]; //位圖，led的狀態
  40. unsigned long snd[NBITS(SND_MAX)]; //位圖，聲音的狀態
  41. unsigned long sw[NBITS(SW_MAX)]; //位圖，開關的狀態
  43. int absmax[ABS_MAX + 1]; //位圖，記錄坐標的最大值
  44. int absmin[ABS_MAX + 1]; //位圖，記錄坐標的最小值
  45. int absfuzz[ABS_MAX + 1]; //位圖，記錄坐標的分辨率
  46. int absflat[ABS_MAX + 1]; //位圖，記錄坐標的基準值
  48. int (*open)(struct input_dev *dev); //輸入設備打開函數
  49. void (*close)(struct input_dev *dev); //輸入設備關閉函數
  50. int (*flush)(struct input_dev *dev, struct file *file); //輸入設備斷開後刷新函數
  51. int (*event)(struct input_dev *dev, unsigned int type, unsigned int code, int value); //事件處理
  53. struct input_handle *grab; //類似私有指針，可以直接訪問到事件處理接口event
  55. struct mutex mutex; //用於open、close函數的連續訪問互斥
  56. unsigned int users; //設備使用計數
  58. struct class_device cdev; //輸入設備的類信息
  59. union { //設備結構體
  60. struct device *parent;
  61. } dev;
  63. struct list_head h_list; //handle鏈表
  64. struct list_head node; //input_dev鏈表
  65. };

也許就這樣赤裸裸的看上面的結構體，會覺得摸不著頭腦，但是有一點是確定的，我們在寫輸入設備驅動時會定義這樣一個輸入設備結構體，並調用input_allocate_device()函數，這個函數的功能是為新添加的輸入設備分配內存，如果成功，將返回input_dev *的指針結構，因此在寫驅動的時候應該接受返回值，作為驅動層獲得了一個新的輸入設備操作的接口。

那麽input_allocate_device()函數做了什麽呢？打開函數看一下（input.c中實現）：

[cpp] view plaincopy
  1. struct input_dev *input_allocate_device(void)
  2. {
  3. struct input_dev *dev;
  5. //動態申請內存，使用GFP_KERNEL方式，註意GFP_KERNEL可能導致睡眠，不能在中斷中調用這個函數
  6. dev = kzalloc(sizeof(struct input_dev), GFP_KERNEL);
  7. //分配成功執行的代碼，進行成員的默認填充
  8. if (dev) {
  9. dev->cdev.class = &input_class; //支持熱插拔的結構體
  10. dev->cdev.groups = input_dev_attr_groups; //描述設備的硬件信息和支持的事件類型
  11. class_device_initialize(&dev->cdev); //類設備初始化，添加進input類設備模型中
  12. mutex_init(&dev->mutex); //初始化互斥鎖
  13. INIT_LIST_HEAD(&dev->h_list); //初始化handle鏈表
  14. INIT_LIST_HEAD(&dev->node); //初始化輸入設備鏈表
  16. }
  17. }

通過input_allocate_device()函數，我們設備驅動現在持有的input_dev裏面就被賦予了input的“形象”，但是還需要我們去充實一下“內在”，因此，設備驅動程序，還需要為自己的設備增加自己的特性，才能創造獨有的設備“形象”。拿上一節的代碼舉例如下：

[cpp] view plaincopy
  1. struct input_dev *input_dev = input_allocate_device();
  2. input_dev->name = "s3c2410 Touchscreen";
  3. input_dev->phys = "s3c2410ts/input0";
  4. input_dev->id.bustype = BUS_HOST;
  5. input_dev->id.vendor = 0x0001;
  6. input_dev->id.product = 0x0002;
  7. input_dev->id.version = 0x0100;
  8. input_dev->evbit[0] = BIT_MASK(EV_SYN) | BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
  9. input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
  10. input_set_abs_params(input_dev, ABS_X, X_AXIS_MIN, X_AXIS_MAX, 0, 0);
  11. input_set_abs_params(input_dev, ABS_Y, Y_AXIS_MIN, Y_AXIS_MAX, 0, 0);
  12. input_set_abs_params(input_dev, ABS_PRESSURE, PRESSURE_MIN, PRESSURE_MAX, 0, 0);

以上的內容在前一節觸摸屏驅動的初始化代碼中也有分析，完成了輸入設備的初始化工作。但是這僅是初始化自己的“特點”，還需要通知輸入子系統有這樣一個新設備誕生了，這就需要調用輸入子系統的註冊函數input_register_device（input_dev）來完成。

input_register_device（）用於註冊一個輸入設備。那麽註冊過程是怎樣的呢？這是一個重點，我們在下面的代碼中進行註釋分析：

[cpp] view plaincopy
  1. int input_register_device(struct input_dev *dev)
  2. {
  3. /* 用於記錄輸入設備名稱的索引值 */
  4. static atomic_t input_no = ATOMIC_INIT(0);
  5. /* 輸入事件的處理接口指針，用於和設備的事件類型進行匹配 */
  6. struct input_handler *handler;
  7. const char *path;
  8. int error;
  10. /* 默認所有的輸入設備都支持EV_SYN同步事件 */
  11. set_bit(EV_SYN, dev->evbit);
  13. /*
  14. * 如果設備驅動沒有指定重復按鍵（連擊），系統默認提供以下的支持
  15. * 其中init_timer為連擊產生的定時器，時間到調用input_repeat_key函數
  16. * 上報，REP_DELAY用於設置重復按鍵的鍵值，REP_PERIOD設置延時時間
  17. */
  18. init_timer(&dev->timer);
  19. if (!dev->rep[REP_DELAY] && !dev->rep[REP_PERIOD]) {
  20. dev->timer.data = (long) dev;
  21. dev->timer.function = input_repeat_key;
  22. dev->rep[REP_DELAY] = 250;
  23. dev->rep[REP_PERIOD] = 33;
  24. }
  26. /* 如果設備驅動沒有設置自己的獲取鍵值的函數，系統默認 */
  27. if (!dev->getkeycode)
  28. dev->getkeycode = input_default_getkeycode;
  30. /* 如果設備驅動沒有指定按鍵重置函數，系統默認 */
  31. if (!dev->setkeycode)
  32. dev->setkeycode = input_default_setkeycode;
  34. /* 重要，把設備掛到全局的input子系統設備鏈表input_dev_list上 */
  35. list_add_tail(&dev->node, &input_dev_list);
  37. /* 動態獲取input設備的ID號，名稱為input*，其中後面的“*”動態獲得，唯一的 */
  38. snprintf(dev->cdev.class_id, sizeof(dev->cdev.class_id),
  39. "input%ld", (unsigned long) atomic_inc_return(&input_no) - 1);
  41. /* 如果這個值沒有設置，系統把輸入設備掛入設備鏈表 */
  42. if (!dev->cdev.dev)
  43. dev->cdev.dev = dev->dev.parent;
  45. /* 在/sys目錄下創建設備目錄和文件 */
  46. error = class_device_add(&dev->cdev);
  47. if (error)
  48. return error;
  50. /* 獲取並打印設備的絕對路徑名稱 */
  51. path = kobject_get_path(&dev->cdev.kobj, GFP_KERNEL);
  52. printk(KERN_INFO "input: %s as %s\n",
  53. dev->name ? dev->name : "Unspecified device", path ? path : "N/A");
  54. kfree(path);
  56. /* 核心重點，input設備在增加到input_dev_list鏈表上之後，會查找
  57. * input_handler_list事件處理鏈表上的handler進行匹配，這裏的匹配
  58. * 方式與設備模型的device和driver匹配過程很相似，所有的input
  59. * 都掛在input_dev_list上，所有類型的事件都掛在input_handler_list
  60. * 上，進行“匹配相親”*/
  61. list_for_each_entry(handler, &input_handler_list, node)
  62. input_attach_handler(dev, handler);
  64. input_wakeup_procfs_readers();
  66. return 0;
  67. }

上面的代碼主要的功能有以下幾個功能，也是設備驅動註冊為輸入設備委托內核做的事情：

  • 進一步初始化輸入設備，例如連擊事件；
  • 註冊輸入設備到input類中；
  • 把輸入設備掛到輸入設備鏈表input_dev_list中；
  • 查找並匹配輸入設備對應的事件處理層，通過input_handler_list鏈表

我們需要再分析下這個匹配的過程，“相親”這種事情還是很有意思的，但是需要註意的是下面分析的代碼是我們暫時無法分析的，因為那樣會使得情況變得更加復雜，當我們從應用層往下分析的時候一切都會明白。input_attach_handler匹配過程如下：

const struct input_device_id *id;  
    int error;  
  
/* 如果handler的blacklist被賦值了並且則優先匹配 */  
    if (handler->blacklist && input_match_device(handler->blacklist, dev))  
        return -ENODEV;  
  
    /* 否則利用handler->id_table和dev進行匹配，後面講述匹配什麽和過程 */  
    id = input_match_device(handler->id_table, dev);  
    if (!id)  
        return -ENODEV;  
  
    /* 這是一根“紅線”，雖然你可能覺的是黑色的，但不可否認，他們真的匹配上了 
         * 調用handler->connnect函數進行匹配，匹配詳細過程後面講述 
        */  
    error = handler->connect(handler, dev, id);  
    if (error && error != -ENODEV)  
        printk(KERN_ERR  
            "input: failed to attach handler %s to device %s, "  
            "error: %d\n",  
            handler->name, kobject_name(&dev->cdev.kobj), error);  
  
    return error;

我們先來看下input_match_device（）函數，看一下這個匹配的條件是什麽，如何匹配的過程是怎樣的，匹配的結果會是什麽？

/* 事件處理層中的對應flags如果設置或者driver_info被設置則進行匹配 */  
    for (; id->flags || id->driver_info; id++) {  
        /* 以下通過flags中設置的位來匹配設備的總線類型、經銷商、生產ID和版本ID 
          如果沒有匹配上將進行MATCH_BIT匹配 */  
        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;  
          
        /* MATCH_BIT用於匹配設備驅動中是否設置了這些為，MATCH_BIT的宏 
        * 被定義在input.c中，我們在設備驅動中設置的事件類型會與事件鏈表中的 
        * 所有事件類型進行比較，匹配成功了將返回id，證明真的很合適，否則NULL 
        */  
        MATCH_BIT(evbit,  EV_MAX);  
        MATCH_BIT(keybit, KEY_MAX);  
        MATCH_BIT(relbit, REL_MAX);  
        MATCH_BIT(absbit, ABS_MAX);  
        MATCH_BIT(mscbit, MSC_MAX);  
        MATCH_BIT(ledbit, LED_MAX);  
        MATCH_BIT(sndbit, SND_MAX);  
        MATCH_BIT(ffbit,  FF_MAX);  
        MATCH_BIT(swbit,  SW_MAX);  
  
        return id;  
    }  
  
    return NULL;

既然證明是合適的，接下來就應該登記註冊，並公證了。還記得handler->connect(handler, dev, id)函數吧，當input_match_device（）找到最合適的事件處理層驅動時，便執行handler->connect函數進行公證了，看下面這部分代碼（假如說找到了evdev類型的驅動，在input/evdev.c中）：

struct evdev *evdev;  
    struct class_device *cdev;  
    dev_t devt;  
    int minor;  
    int error;  
  
    /* EVDEV_MINORS為32，代表共能容納32個evdev事件層設備，下面代碼在找到空的地方，用於保存evdev事件層的數據，即上面定義的evdev */  
    for (minor = 0; minor < EVDEV_MINORS && evdev_table[minor]; minor++);  
    /* 這說明內核已經沒辦法再分配這種類型的設備了 */  
    if (minor == EVDEV_MINORS) {  
        printk(KERN_ERR "evdev: no more free evdev devices\n");  
        return -ENFILE;  
    }  
    /* 開始給evdev事件層驅動分配空間了 */  
    evdev = kzalloc(sizeof(struct evdev), GFP_KERNEL);  
    if (!evdev)  
        return -ENOMEM;  
  
    /* 初始化client_list列表和evdev_wait隊列，後面介紹 */  
    INIT_LIST_HEAD(&evdev->client_list);  
    init_waitqueue_head(&evdev->wait);  
  
    /* 初始化evdev結構體，其中handle為輸入設備和事件處理的關聯接口 */  
    evdev->exist = 1;  
    evdev->minor = minor;  
    evdev->handle.dev = dev;  
    evdev->handle.name = evdev->name;  
    evdev->handle.handler = handler;  
    evdev->handle.private = evdev;  
    sprintf(evdev->name, "event%d", minor);  
  
    /* 重要，上層訪問時通過次設備號找到事件處理的接口 */  
    evdev_table[minor] = evdev;  
  
    /* evdev事件設備的此設備號的基準值INPUT_MAJOR, EVDEV_MINOR_BASE */  
    devt = MKDEV(INPUT_MAJOR, EVDEV_MINOR_BASE + minor),  
  
    /* 創建用戶事件驅動層設備訪問接口/dev/input/event* */  
    cdev = class_device_create(&input_class, &dev->cdev, devt,  
                   dev->cdev.dev, evdev->name);  
    if (IS_ERR(cdev)) {  
        error = PTR_ERR(cdev);  
        goto err_free_evdev;  
    }  
  
    /* 提供/sys目錄的用戶空間接口 */  
    error = sysfs_create_link(&input_class.subsys.kobj,  
                  &cdev->kobj, evdev->name);  
    if (error)  
        goto err_cdev_destroy;  
  
    /* input_dev設備驅動和handler事件處理層的關聯，由handle完成 */  
    error = input_register_handle(&evdev->handle);

通過上述代碼的執行，最終，輸入設備在input_register_handle（）的關聯下與已經匹配上的handler結合，代碼如下：

struct input_handler *handler = handle->handler;  
    /* 將d_node鏈接到輸入設備的h_list，h_node鏈接到事件層的h_list鏈表上 
    * 因此，在handle中是輸入設備和事件層的關聯結構體，通過輸入設備可以 
    * 找到對應的事件處理層接口，通過事件處理層也可找到匹配的輸入設備 
    */  
    list_add_tail(&handle->d_node, &handle->dev->h_list);  
    list_add_tail(&handle->h_node, &handler->h_list);  
  
    /* 如果start函數有定義則調用，但是evdev結構體中並未初始化這個函數 */  
    if (handler->start)  
        handler->start(handle);

以上是輸入設備驅動註冊的全過程，牽涉的代碼比較多，需要從宏觀上理順。縱觀整個過程，輸入設備驅動最終的目的就是能夠與事件處理層的事件驅動相互匹配，但是在drivers/input目錄下有evdev.c事件驅動、mousedev.c事件驅動、joydev.c事件驅動等等，我們的輸入設備產生的事件應該最終上報給誰，然後讓事件驅動再去處理呢？知道了這麽個原因再看上面代碼就會明白，其實evdev.c、mousedev.c等根據硬件輸入設備的處理方式的不同抽象出了不同的事件處理接口幫助上層去調用，而我們寫的設備驅動程序只不過是完成了硬件寄存器中數據的讀寫，但提交給用戶的事件必須是經過事件處理層的封裝和同步才能夠完成的，事件處理層提供給用戶一個統一的界面來操作。

由於以上的這些原因，才有了上述代碼的關聯過程，通過下圖7，看一下整個關聯註冊的過程：

技術分享圖片

圖7 input_dev與handler關聯圖

通過上圖我們可以看到input輸入設備匹配關聯的關鍵過程以及涉及到的關鍵函數和數據。這一節主要是從input設備驅動程序的角度去看輸入子系統的註冊過程和三層之間的關聯，下一節將從應用層的角度分析事件的接受過程和處理過程以及三層之間是如何配合處理輸入事件的。

1.2 從應用層的角度出發看input子系統

以上部分已經借助input子系統把input設備驅動層與事件驅動層進行了關聯，我們以前面幾節所介紹的s3c2440_ts.c（輸入設備層驅動）和evdev.c（事件處理層驅動）為例，來分析這一過程。

由於s3c2440_ts.c中上報的事件類型為按鍵、絕對值坐標，而evdev事件驅動程序是全匹配的，因此早在s3c2440_ts.c註冊的過程中，就會創建設備節點/dev/input/event0（假設內核中沒有其他的event類型的輸入設備，這裏就是event0），當然由於我的內核是2.6.22，這個節點的名字是/dev/event0。因此需要註意你的內核版本，以確定設備節點的位置，我們以“/dev/event0”為例來說明。

我們知道，應用層使用設備的第一步，是open(“/dev/event0”)，因此這裏event0的主設備號成為關鍵，因為主設備號將表明你是什麽設備，我們ls -l查看/dev/event0發現：

crw-r-----1 root root 13, 64 2012-07-26 14:32 /dev/input/event0

由此可見主設備是13，輸入命令cat /proc/devices查看主設備為13的是input設備，因此可以確定當我們執行open函數打開event0設備的時候，會調用input設備的open驅動函數，這個函數在input.c中，為了說明這一問題，需要從input驅動註冊過程開始，還是input.c文件：

[cpp] view plaincopy
  1. /* 輸入設備初始化函數 */
  2. static int __init input_init(void)
  3. {
  4. class_register(&input_class);
  5. input_proc_init();
  6. register_chrdev(INPUT_MAJOR,"input", &input_fops);
  7. }

可以看到，輸入設備初始化的過程首先建立了input類，初始化input在proc下的節點，然後註冊input設備，設備名稱為input，操作接口是input_fops，主設備號是INPUT_MAJOR=13。

由以上可知，只要是主設備號為13的設備驅動程序，都是用input_fops接口，即當event0設備使用open函數打開時，會調用到input_fops接口中的open驅動函數，這個結構體的初始化為：

[cpp] view plaincopy
  1. static const struct file_operations input_fops = {
  2. .owner = THIS_MODULE,
  3. .open = input_open_file,
  4. };

可以看到，只實現了一個open功能字段，再看input_open_file的實現：

[cpp] view plaincopy
  1. static int input_open_file(struct inode *inode, struct file *file)
  2. {
  3. struct input_handler *handler =input_table[iminor(inode) >> 5];
  4. const struct file_operations *old_fops,*new_fops = NULL;
  5. if (!handler || !(new_fops =fops_get(handler->fops)))
  6. return -ENODEV;
  7. old_fops = file->f_op;
  8. file->f_op = new_fops;
  9. new_fops->open(inode, file);
  10. }

以上代碼的功能為找到對應事件驅動層的fops，即進行fops的接口轉換，指向對應設備的事件處理接口。其中input_table[iminor(inode)]>>5的input_table是一個全局的input_handler類型的數組，iminor(inode)取得次設備號，並且右移5位索引input_table表中對應的位置，為什麽這樣做呢？這是因為這個表格中填寫的就是事件處理的指針，我們待會分析，先繼續查看下面的代碼。if中將判斷是否為空並且事件處理層中的fops有沒有初始化，如果沒有就不能進行接口轉換，報出設備不存在的錯誤，如果設備存在則把input設備的f_op驅動接口指向input_table表中存在的接口，並調用其open函數。那麽這個input_table裏面到底存放了什麽呢？我們還是拿觸摸屏驅動來講解。由於觸摸屏驅動已經完成了和evdev.c事件處理層的匹配，且次設備號為64，設備名稱為/dev/event0，這是我們通過分析驅動註冊中獲得的內容，既然input核心設備註冊了，s3c2440觸摸屏驅動也註冊了，那會不會evdev設備也會註冊了呢？答案是肯定的，要想知道input_table裏面放了什麽，必須要去查看evdev設備的註冊過程，打開input/evdev.c查看它的註冊過程：

[cpp] view plaincopy
  1. static struct input_handler evdev_handler = {
  2. .event = evdev_event, //事件處理
  3. .connect = evdev_connect, //設備連接
  4. .disconnect = evdev_disconnect, //註銷連接
  5. .fops = &evdev_fops, //驅動功能接口
  6. .minor = EVDEV_MINOR_BASE, //evdev的值為64
  7. .name = "evdev", //設備名稱
  8. .id_table = evdev_ids, //用於匹配設備驅動的數組
  9. };
  11. static int __init evdev_init(void)
  12. {
  13. return input_register_handler(&evdev_handler); //evdev設備驅動註冊
  14. }

由以上的內容可以知道evdev_handler也被作為一個設備來操作，但是它屬於input handler事件處理設備，然而我們在evdev_handler結構體的.fops字段又發現它的驅動接口為字符設備類型，在input中，如果input_table匹配到了evdev_handler，將會把file->f_op=&evdev_fops，那麽如果使用read、write等函數操作，將會調用到evdev_fops中的read、write。

為了進一步查看input_table表中的內容是如何填充的，還需要查看這個註冊的過程：

[cpp] view plaincopy
  1. int input_register_handler(struct input_handler *handler)
  2. {
  3. ……
  4. input_table[handler->minor>> 5] = handler;
  5. ……
  6. }

當然這個註冊過程並不是只有這麽一句話，看到這條語句，相信你應該知道什麽意思了。在input的open函數執行之前，即我們的open代碼打開之前，input_table中的字段已經被事件處理層填充了。由於evdev的次設備號在初始化的時候就設置成了64，因此這裏相當於：

[cpp] view plaincopy
  1. input_table[2]=&evdev_handler；

回到input_open_file函數查看new_fops->open(inode, file)你便知道了調用的是:

[cpp] view plaincopy
  1. evdev_handler.evdev_fops.open（inode, file）；

在分析open函數之前，解釋一下為什麽要右移5位，這說明一個問題，次設備號的低5位被忽略，這說明evdev的最大支持的輸入設備驅動個數為2^5次方等於32個，你可能會看到你的/dev目錄下面有event0、event1、event2等設備，他們的次設備號分別為64、65、66等等。但最大是64+32-1，因此input_table為這些輸入設備增加的一個統一接口，通過上層打開設備時，只要次設備號在64+32-1之間的設備都會重新定位到evdev_handler中，即event*設備打開後執行的底層函數將被重新定義到evdev_handler中。

相信上面的問題已經描述清楚，如果還是不明白，你最起碼應該知道的是，input設備中的open函數只是一個接口，通過次設備號才找到了真正的事件處理接口。接下來要看新的open接口的實現了，evdev_handler-> fops->open實現如下：

/*evdev字符設備驅動接口 */  
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  
};  
/*evdev設備open函數的實現過程 */  
static int evdev_open(struct inode *inode, struct file *file)  
{  
       struct evdev_client *client;  
       struct evdev *evdev;  
       /* 如果是event0，對於evdev設備來說，次設備號當然是0 */  
       int i = iminor(inode) - EVDEV_MINOR_BASE;  
       int error;  
       /* 如果大於32，說明超出了evdev能夠容納的最大輸入設備個數 */  
       if (i >= EVDEV_MINORS)  
              return -ENODEV;  
       /* 由於evdev中能容納32個輸入設備，因此通過設備號event0中的0定位到是要處理的是哪一個輸入設備，evdev_table中的內容在輸入設備驅動註冊時通過evdev_connect填充 */  
       evdev = evdev_table[i];  
       /* 判斷是否設備接口存在，evdev_exist也是在evdev_connect填充為1 */  
       if (!evdev || !evdev->exist)  
              return -ENODEV;  
       /* 存在則分配evdev中的client來處理event* */  
       client = kzalloc(sizeof(struct evdev_client),GFP_KERNEL);  
       if (!client)  
              return -ENOMEM;  
   
       /* 把event*中的接口指向evdev_table中對應項 */  
       client->evdev = evdev;  
       /* 把client->node鏈接到evdev子集中 */  
       list_add_tail(&client->node,&evdev->client_list);  
       /* 如果open是第一個打開，則會執行input_open_device*/  
       if (!evdev->open++ &&evdev->exist) {  
              error =input_open_device(&evdev->handle);  
              if (error) {  
                     list_del(&client->node);  
                     kfree(client);  
                     return error;  
              }  
       }  
       /* 將file私有指針指向client*/  
       file->private_data = client;  
       return 0;  
}  
由上的代碼可以看出，最終是要執行input_open_device去執行設備驅動程序中的代碼，然而我們在定義設備驅動的時候並沒有給input_dev中的open字段填充內容，因此可以看到input_open_device函數的執行過程：  
if(!dev->users++ && dev->open)  
              err = dev->open(dev);  
   
       if (err)  
              handle->open--;

上面截取了片段，並沒有執行到open函數，open進行自減操作，表示沒有調用過open，這個值主要是為了close中判斷open為0時釋放資源使用。

不僅如此，我們在觸摸屏驅動中也沒有定義read、write，那當觸摸屏上報事件時，是如何處理的呢？我們需要先到觸摸屏驅動程序中找到上報事件的函數再做進一步分析。

1.3 輸入設備上報事件的處理過程

觸摸屏驅動程序上報事件的函數為：

[cpp] view plaincopy
  1. input_report_abs(dev,ABS_X, s3c2440_ts->tc.xp);
  2. input_report_abs(dev,ABS_Y, s3c2440_ts->tc.yp);
  3. input_report_abs(dev,ABS_PRESSURE, s3c2440_ts->tc.pressure);
  4. input_report_key(dev,BTN_TOUCH, s3c2440_ts->pendown);
  5. input_sync(dev);

然而他們其實是input_event函數的封裝，調用的都是input_event函數，這一函數在input.c中實現如下：

[cpp] view plaincopy
  1. void input_event(struct input_dev *dev, unsigned int type, unsigned int code, intvalue)
  2. {
  3. struct input_handle *handle;
  5. if (type > EV_MAX || !test_bit(type,dev->evbit))
  6. return;
  7. switch (type) {
  8. case EV_SYN:
  9. switch (code) {
  10. case SYN_CONFIG:
  11. if(dev->event)
  12. dev->event(dev,type, code, value);
  13. break;
  14. case SYN_REPORT:
  15. if(dev->sync)
  16. return;
  17. dev->sync= 1;
  18. break;
  19. }
  20. break;
  21. case EV_KEY:
  22. case EV_SW:
  23. case EV_ABS:
  24. case EV_REL:
  25. case EV_MSC:
  26. case EV_LED:
  27. case EV_SND:
  28. case EV_REP:
  29. case EV_FF:
  30. }
  32. if (type != EV_SYN)
  33. dev->sync = 0;
  35. if (dev->grab)
  36. dev->grab->handler->event(dev->grab,type, code, value);
  37. else
  38. list_for_each_entry(handle,&dev->h_list, d_node)
  39. if (handle->open)
  40. handle->handler->event(handle,type, code, value);
  41. }

代碼被做了精簡，其中就是在匹配上報的事件，並根據事件的類型調用驅動程序中相應的函數來完成，但是由於我們並，沒有定義過這些函數，因此執行最後的handle_handler_event函數，由事件處理層evdev_event函數來完成事件的保存工作，具體過程如下：

[cpp] view plaincopy
  1. list_for_each_entry(client,&evdev->client_list, node) {
  2. client->buffer[client->head].type= type;
  3. client->buffer[client->head].code= code;
  4. client->buffer[client->head].value= value;
  5. client->head= (client->head + 1) & (EVDEV_BUFFER_SIZE - 1);
  6. }

這裏列舉了關鍵代碼，即上報的事件被保存到了client_buffer中，其中client_buffer是一個循環緩沖區，client->head表示當前數據的位置，因此每次都寫到client->head的位置，而讀數據時需要到client_tail中讀取。因為在open的時候，client已經被鏈入到了evdev->client_list中，因此通過可以通過list_for_each_entry重evdev->client_list中找到對應的client。

事件的上報都會把數據保存到client->buffer中，以便上層通過read和write進行讀去和寫入。

1.4 通過設備節點讀取輸入事件

還是以觸摸屏驅動程序和evdev事件處理層驅動來分析：

[cpp] view plaincopy
  1. static ssize_t evdev_read(struct file *file, char __user *buffer, size_t count, loff_t*ppos)
  2. {
  3. struct evdev_client *client =file->private_data;
  4. struct evdev *evdev = client->evdev;
  5. int retval;
  7. /* 判斷用戶給的count是否能夠容納事件數據的大小*/
  8. if (count < evdev_event_size())
  9. return -EINVAL;
  11. /* 如果數據不為空並且設備存在並且是阻塞訪問方式才能繼續執行 */
  12. if (client->head == client->tail&& evdev->exist && (file->f_flags & O_NONBLOCK))
  13. return -EAGAIN;
  15. /* 如果數據為空，設置進程等待底層驅動層上報事件到client->buffer中 */
  16. retval =wait_event_interruptible(evdev->wait,
  17. client->head != client->tail|| !evdev->exist);
  18. if (retval)
  19. return retval;
  21. if (!evdev->exist)
  22. return -ENODEV;
  24. /* 循環讀取數據 */
  25. while (client->head != client->tail&& retval + evdev_event_size() <= count) {
  27. struct input_event *event =(struct input_event *) client->buffer + client->tail;
  29. if (evdev_event_to_user(buffer +retval, event))
  30. return -EFAULT;
  32. client->tail = (client->tail+ 1) & (EVDEV_BUFFER_SIZE - 1);
  33. retval += evdev_event_size();
  34. }
  36. return retval;
  37. }

這裏如果沒有數據，進程會睡眠，那由誰來喚醒呢？細心的話可以發現，當設備驅動層調用input_event上報事件調用相應的event函數進行事件寫入時，是會喚醒阻塞等待的進程的。

1.5 通過設備節點寫入輸入事件

寫入過程：

[cpp] view plaincopy
  1. static ssize_t evdev_write(struct file *file, const char __user *buffer, size_t count,loff_t *ppos)
  2. {
  3. /* 循環寫入，調用input_inject_event函數 */
  4. while (retval < count) {
  6. if (evdev_event_from_user(buffer +retval, &event))
  7. return -EFAULT;
  8. input_inject_event(&evdev->handle,event.type, event.code, event.value);
  9. retval += evdev_event_size();
  10. }
  12. return retval;
  13. }

上述代碼中的event是input_event數組，包含了事件的類型、鍵值，通過input_inject_event把數據寫入循環數組client->buffer中，input_inject_event調用的是input_event函數。

1.6 總結

本節對input子系統的整個過程做了分析，並從兩個角度進行考慮，對於寫輸入設備驅動程序的來說，需要掌握的是設備應該上報事件的類型，這樣才能匹配到對應的事件層驅動幫助你保存對應的數據，而對於設備上層開發者來說，應該先使用cat /proc/bus/input/devices查看你操作的設備類型和處理接口，以幫助你更好的對設備操作。

linux input輸入子系統分析《四》：input子系統整體流程全面分析

相關推薦

linux input輸入子系統分析《四》：input子系統整體流程全面分析

總線 返回值 分代 並不是 事件 等等 lag pri 位置 1 input輸入子系統整體流程 本節分析input子系統在內核中的實現，包括輸入子系統（Input Core），事件處理層（Event Handler）和設備驅動層。由於上節代碼講解了設備驅動層的寫法

input子系統整體流程全面分析（觸控式螢幕驅動為例）

input輸入子系統整體流程 　　input子系統在核心中的實現，包括輸入子系統（Input Core），事件處理層（Event Handler）和裝置驅動層。 　　在開頭部分會從裝置驅動層做為線索，分析輸入子系統和事件處理層是如何配合的，最後從使用者角度出發，從“/de

linux驅動由淺入深系列：usb子系統之四（android平臺滑鼠驅動程式碼分析）

android上的usb口是支援OTG(on the go)的，USB OTG既可以作為Host又可以作為Device，我們本文來看一下android手機作為Host連線滑鼠的情況。OTG是如何做到既可以做Host又可以作為Device的呢 標準usb接頭中有四根線：vbu

Linux時間子系統之四：定時器的引擎：clock_event_device

到來 開始 register 工作模式 統一 10個 net 說過 序列 早期的內核版本中，進程的調度基於一個稱之為tick的時鐘滴答，通常使用時鐘中斷來定時地產生tick信號，每次tick定時中斷都會進行進程的統計和調度，並對tick進行計數，記錄在一個jiffies變量

Linux中斷（interrupt）子系統之四：驅動程式介面層 & 中斷通用邏輯層

轉載地址：https://blog.csdn.net/DroidPhone/article/details/7497787 在本系列文章的第一篇：Linux中斷（interrupt）子系統之一：中斷系統基本原理，我把通用中斷子系統分為了4個層次，其中的驅動程式介面層和中斷通用邏輯層的界限實際上不

WebRTC原始碼分析四：視訊模組結構

本文在上篇的基礎上介紹WebRTC視訊部分的模組結構，以進一步瞭解其實現框架，只有瞭解了整體框架結構，對區域性演算法修改才能夠胸有成竹。 一、對外介面        對外介面有ViEBase，ViECapture，ViECodec，ViEEncryption，V

nova boot程式碼流程分析(四)：nova與neutron的l2 agent(neutron-linuxbridge-agent)互動

#/nova/virt/libvirt/driver.py:LibvirtDriver # NOTE(ilyaalekseyev): Implementation like in multinics # for xenapi(tr3buchet)

Spring Security原始碼分析四：Spring Social實現微信社交登入

社交登入又稱作社會化登入（Social Login），是指網站的使用者可以使用騰訊QQ、人人網、開心網、新浪微博、搜狐微博、騰訊微博、淘寶、豆瓣、MSN、Google等社會化媒體賬號登入該網站。 前言 在上一章Spring-Security原始碼分析

linux spi驅動開發學習(四)-----spi驅動程式完整流程分析

所有的應用程式使用dev/目錄下建立的裝置,這些字元裝置的操作函式集在檔案spidev.c中實現。 點選(此處)摺疊或開啟 static const struct file_operations spidev_fops = {     .owner =    THIS

ABP原始碼分析四：Configuration

核心模組的配置 Configuration是ABP中設計比較巧妙的地方。其通過AbpStartupConfiguration，Castle的依賴注入，Dictionary物件和擴充套件方法很巧妙的實現了配置中心化。配置中心化是一個支援模組開發的框架必備功能。 ABP中核心功能模組中的一些功能的執行時的

Linux下輸入命令報錯：-bash: command not found

配置環境過程中出錯，導致輸入Linux自帶命令時，就報錯-bash: command not found。原因是環境變數的問題，可echo $PATH檢視環境變數是否正常。 解決辦法： 1、臨時環境變數（重啟後消失） 在命令列裡面輸入：export PATH=$PA

Android 5.0 Camera系統原始碼分析(4)：Camera預覽流程資料流

1. 前言 上一篇講了怎麼讓Camera進入預覽模式，提到了DisplayClient負責顯示影象資料，而CamAdapter負責提供影象資料，這裡主要記錄了CamAdapter怎麼獲取影象，然後DisplayClient怎麼將影象顯示在螢幕上。 2.

Android 5.0 Camera系統原始碼分析(3)：Camera預覽流程控制流

1. 前言 本文分析的是Android系統原始碼，從frameworks層到hal層，記錄了Camera進入預覽模式的重點程式碼，主要為控制流程的程式碼，有關影象buffer的傳遞暫不涉及，硬體平臺基於mt6735。由於某些函式比較複雜，在貼出程式碼時會適當對

12.深入k8s：kubelet建立pod流程原始碼分析

![77225439_p0](https://img.luozhiyun.com/20200926201132.jpg) > 轉載請宣告出處哦~，本篇文章釋出於luozhiyun的部落格：https://www.luozhiyun.com > > 原始碼版本是[1.19](https://github.c

C語言編譯流程全面分析

程式的編譯流程大概分為 前處理器 -> 編譯器 -> 彙編器 -> 連結器，4個階段。 編譯器又可以分為詞法分析 -> 語法分析 -> 語義分析 -> 中間程式碼生成 -> 程式碼優化 ->生成目的碼等階段。

C語言連結裝載流程全面分析

連結的主要內容是把各個模組之間相互引用的部分處理好，使得各個模組之間能夠正確地銜接。 連結的主要過程包括：地址和空間分配（Address and Storage Allocation），符號決議（Symbol Resolution），重定位（Relocation）等。 連結分為靜態連結和動態

Linux內核分析 - 網絡[十四]：IP選項

ria copyto 還要 next 操作 目的 start 套接口 詳細講解 Linux內核分析 - 網絡[十四]：IP選項 標簽： linux內核網絡structsocketdst 2012-04-25 17:14 5639人閱讀 評論(1) 收藏 舉報

專案小結：手機郵箱正則，URL各種判斷返回頁面，input輸入框輸入符合卻獲取不到問題

1.手機郵箱正則 近兩年出來很多新號碼，聽說199什麼的都有了- -導致以前的正則不能用了....這就很難過，總是過一段時間出一種新號碼。因此，我決定使用返樸歸真的手機正則。 手機正則：var reg=/^1[0-9]\d{9}$/; 郵箱正則：var mailReg = /^[a-zA-Z0-9_.-

INPUT輸入子系統的測試方式 evtest

INPUT輸入子系統的測試方式 evtest 2018年04月09日 17:17:43 匠芯 閱讀數：175 版權宣告：匠芯築夢，不負所期，轉載請宣告轉載地址http://blog.csdn.net/qq84395064，謝謝大家。如有技術需要請聯絡博主QQ：84395064 微控制器學習交

Linux之輸入子系統分析

在此節之前，我們學的都是簡單的字元驅動，涉及的內容有字元驅動的框架、自動建立裝置節點、linux中斷、poll機制、非同步通知、同步互斥/非阻塞、定時器去抖動。 其中驅動框架如下: 1)寫file_operations結構體的成員函式: .open()、.read()、.write()