Linux Input Subsystem Framework analysis (1)

In Linux input device keyboard, touch screen, mouse, etc. can be used in the input subsystem to achieve the drive. The input subsystem is divided into three layers, the core layer and the device driver layer, and the event layer. The core layer and the event layer are implemented by the Linux input subsystem itself, and the device driver layer is implemented by us. We escalate the input event to the core layer input.c at the device driver layer, the core layer finds the matching event layer, passes the event to the event layer processing, and the event layer is processed and passed to the user space.

The final thing we need to figure out is how the user space calls open and read finally in the kernel, how to deal with the incident to the kernel, who processed, after processing how to pass to the user space?

The above two graphs are the framework of the input subsystem.

The following example analyzes the workflow of the input subsystem using the key driver.

Device driver Layer:

Called Input_allocate_device () in the Init entry function of the device driver layer, the allocation returns a Input_dev struct, populates the struct, calls Input_register_device (Button_dev), registers the device. Trace Input_register_device are as follows:

List_add_tail (&dev->node, &input_dev_list); Put the INPUT_DEV structure into the input_dev_list list
List_for_each_entry (handler, &input_handler_list, node) traversal input_handler_list Each handler in a linked list

Input_attach_handler (Dev, handler); Compare Input_dev and handler

Input_match_device (handler->id_table, Dev);<*input.c*>
Handler->connect (handler, dev, id);<*input.c*> comparison is by comparing handler id_table and Input_dev, if you find to a matching handler, the handler connect method is called.

Called in the evdev_connect (struct Input_handler *handler, struct input_dev *dev,const struct input_device_id *id) Input_register_handle, call handle before populating member Dev and handler structures in handle.

Evdev->handle.dev = Input_get_device (dev);
Evdev->handle.handler = handler;

in Input_register_handle list_add_tail_rcu (&handle->d_node, &dev->h_list) List_add_tail (& Handle->h_node, &h andler->h_list) Two functions add handle to the handler list of h_list and Dev . Through dev->h_list can find handle, through handle Find Handle.handler, similarly, through handler->h_list can find handle, and find Handle.dev.

The key question is coming? What the hell is handler? Who is registered? handler is a function registered by the event layer called the core layer.

Event layer: (EVDEV.C,KEYBOARD.C,TS.C)

 static struct INPUT_ Handler Evdev_handler = {//handler struct
. Event = evdev_event,
. Connect = Evdev_connect,
. Disconnect = Evdev_disconnect,
. FoPs = &evdev_fops,
. Minor = Evdev_minor_base,
. Name =" Evdev ",
. id_table = Evdev_ids,
};

In the Evdev_init (void) entry function, call Input_register_handler (&evdev_handler) to register the handler, and the registered handler will be placed in the input_table[] array.

Core layer: (INPUT.C)

The ingress function of the core layer Input_init (void) registers the device input.

When Open is called at the application layer, input_open_file (struct inode *inode, struct file *file) is called in the kernel, accordingto Handler = input_table[ Iminor (Inode) >> 5]; Gets the corresponding handler registered from the array input_table according to the secondary device number of the open file.

New_fops = Fops_get (handler->fops) Gets the new FOP from handler.

File->f_op = New_fops;
err = New_fops->open (inode, file); Open is finally called Handler->fops->open. the original device-driven open and other methods are self-written, now input subsystem of the event layer to help us write the open and other device methods. Similarly, the call to read in the application layer invokes read in the event layer, that is, handler->fops->read, which is evdev_fops. Read, which is blocked in read. Until the Input_report_key escalation event is over in the device driver layer:

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); Call the event method in handler, after processing the escalated thing , wake the dormant read, and then read out the processing result of the event.

Summarize:

Calling open in user space will eventually call the open device method of the handler in the event layer, specifically to match to EVDEV.C or KEYBOARD.C handler of Input_dev structure to be populated according to the device-driven init entry function id_ Table The user space call to read will call handler's read. In the device driver through the Input_event escalation event to the core layer, and finally call the corresponding handler event method to handle events, after processing through read to the user space. So we can figure out who called the Open? Who is the call to read?