The most clear and detailed analysis of the Linux input subsystem by the whole network

Linux Input Analysis II: Deconstructing input_handler, Input_core, Input_device

Input and output is a means of interaction between users and products, so input-driven development is common in Linux-driven development. At the same time, the layered architecture idea of input subsystem is very representative and advanced in the Linux drive design, so it is meaningful to analyze the Linux input subsystem deeply.

This paper continues to study the layered architecture of Linux input subsystem and its realization on the basis of "one of Linuxinput subsystem analysis: Software stratification". Software layering discusses the process of message passing and using of input messages from the underlying hardware to the kernel and application layers, while this article focuses on analyzing the abstraction and hierarchical management and implementation of the input devices by the Linux kernel driver layer.

First, the input subsystem Knowledge Point review

For details, see the article "one of the Linux input subsystem analysis: Software layering." The input subsystem is highly abstracted into the Linux input device driver and is finally divided into three layers, including the input core layer, input event processing layer, and input device driver layer. The input core layer (Input-core) manages input device (input-device) and Input event processing (Input-handler) and forwards messages. Such as:

All of the input device's main device number is 13,input-core through the secondary device to classify input devices, such as 0-31 is the joystick, 32-63 is the mouse (corresponding mouse Handler), 64-95 is an event device (such as touch screen, corresponding to the event Handler).

Ii. the task of the input core layer

Core-level Input-core completed work includes:

1) directly interacting with the character device driver framework, the character device driver framework is managed according to the main device number, while Input-core relies on the secondary device number for classification management. The main device number for all input devices of the inputs subsystem is 13, which corresponds to the structfile_operations input_fops defined by the Input-core. The driver architecture layer is obtained through the main device number 13 to Input_fops, The subsequent processing will be handed over to Input_fops.

2) provides an interface for the event processing layer (Input-handler) and the input device (Input-device) to register, and to find matching event handlers for the input device.

3) forward the messages generated by the Input-device (such as touch screen coordinates and pressure values) to Input-handler, or pass Input-handler messages to Input-device (such as the Mouse Flash command).

Third, input subsystem initialization

1. Input-core Initialization

--driver/input/input.c

Registers the device class in the device model/sys/class directory, generates device information in the/proc/bus/input directory, registers the input subsystem's interface operations collection with the character device driver framework (main device number 13 and Input_fops).

2.input-handler initialization

This is illustrated by the example of a event-handler that supports touch screen TS.

--driver/input/evdev.c

Continue to expand the Input_register_handler interface:

--driver/input/input.c

3.input-device initialization

Take the touchscreen TSC2007 as an example, the touch screen is an I²C bus interface access.

--driver/input/touchscreen/tsc2007.c

The management of the I²c bus is similar to the platform bus, and it will match its managed i²c device list element in the i2c_add_driver of the registered I²c device driver interface, and the I2c_driver probe interface will be called when the match succeeds. For the relationship between bus, device and driver, see Understanding Linux from a demand perspective: bus, device, and drive.

Take a look at the Input-device data structure before continuing to trace Tsc2007_probe:

Continue tracking Tsc2007_probe:

Continue to expand the Input_register_device interface:

--driver/input/input.c

4.input-core Correlation matching Input-device and Input-handler

At the end of the Input_register_handler and Input_register_device, the Input_attach_handler interface is used to match the input device and the corresponding event processor.

Continue tracking Evdev_connect:

--driver/input/evdev.c

The Struct Evdev evdev_table represents the underlying Input-device managed by Evdev_handler (through Input-handle Management) and the application layer's process of opening the device, the associated structure of the synchronization, and the message queue (evdev_ Client record).

Input-handle Associated Input-device and Input-handler at a glance.

So the Input_register_handle interface is easily thought of by input-handle through its own d-node and h-node associated to Input-device and Input-handler instances. This way, Input-device can be found quickly through Input-handler, and Input-handler can be quickly found through Input-device.

As for Evdev_install_chrdev, a Evdev instance is logged to the evdev_table array, declaring its existence.

At this point, we can get the following Evdev-handler management:

Iv. application of the open process

Assume that the touchscreen driver generates/DEV/INPUT/EVENT0 device files during the registration of the input device. Let's track the process of opening this device.

Open ("/dev/input/event0")

1.vfs_open Open the device file, read the inode contents of the file, get the main device number 13 and the second device number 64.

The open of the 2.chardev_open character device driver framework obtains the input_fops operation set of the input subsystem according to the main device number 13.

3.input_fops->open, namely Input_open_file

4. Continue to track the Input-handler layer of Evdev-open, Evdev not only associated with the underlying specific input-device, but also recorded the application layer process to open the device information. Messages generated by Input-device can then be passed to the message queue in Evdev's client. Easy to read at the top.

5. Open of the Input-device layer.

In fact, the tsc2007 driver does not define the Input_dev open interface.

Five, touch screen message delivery process

1. The file_operations corresponding to the FD handle obtained by Open is the evdev_fops of Evdev_handler. So the read interface will eventually call the read interface to Evdev_fops, which is evdev_read. Next we will follow the implementation of this interface. Let's look at the definition of member evdev_client for struct Evdev, which is the data structure that represents the process that opened the input device.

2. Evdev_read

3. Assuming that the message queue is empty, the upper process will sleep until it is woken up for message reading. Who's going to wake it up? Initiated by the hardware interrupt of the underlying input-device, the wake-up signal is emitted when the touchscreen message is eventually delivered to the message queue. The external hardware interrupt service function that is registered in Tsc2007_probe is the initiator.

Take a look at the Interrupt service function TSC2007_IRQ:

Ts-work is tsc2007_work:

Trace Input_report_abs Interface:

Follow up on evdev_event:

It wakes up the process that waits for the message to be read in Evdev_read, proceeds to the following execution, fetches the message from the client's buffer, and returns it to the application via Copy_to_user.

One thing to note is that after each touch-screen message is generated, the x-coordinate, y-coordinate, and pressure values are input-report-abs reported in Tsc2007_work, and then the synchronization events are emitted through the Input-sync interface, and asynchronous notifications are sent to the upper application for reading.

What, should be the entire network to tell the Linux input subsystem the most detailed and the most thorough analysis of it!

Please pay attention to the public number: embedded Penguin ring, Hundred original, embedded Linux and IoT development technology experience, senior embedded software architect author.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

The most clear and detailed analysis of the Linux input subsystem by the whole network