Shulou(Shulou.com)06/01 Report--

This article mainly introduces the example analysis of the input subsystem of the Linux device model, which is very detailed and has a certain reference value. Interested friends must read it!

The focus of this section is:

The frame structure of the input subsystem

Each layer corresponds to the file location in the kernel

Event handling Mechanism of input Subsystem

The basic operation flow of the driver layer of the input subsystem

Common functions in the driver layer of the input subsystem

Difficulties in this section:

Event handling Mechanism of input Subsystem

Driving workflow of input subsystem

1 first acquaintance of linux input subsystem

The linux input subsystem (linux input subsystem) is implemented by three layers from top to bottom, namely, the input subsystem event processing layer (EventHandler), the input subsystem core layer (InputCore) and the input subsystem device driver layer.

For the device driver layer of the input subsystem, it mainly realizes the read and write access to the hardware devices, interrupts the settings, and converts the events generated by the hardware into the specifications defined by the core layer to submit to the event processing layer.

For the core layer, the specification and interface are provided for the device driver layer. As long as the device driver layer is concerned about how to drive the hardware and obtain the hardware data (such as pressed key data), and then call the interface provided by the core layer, the core layer will automatically submit the data to the event processing layer.

For the event processing layer, it is the user-programmed interface (device node) and handles the data processing submitted by the driver layer.

The framework for the linux input subsystem is shown in figure 1 below:

Fig. 1 frame structure of linux input subsystem

What is shown in the above figure is the hierarchical structure of the linux input subsystem.

The / dev/input directory shows the device programming interfaces that have been registered in the kernel. Users use open these device files to open different input devices for hardware operations.

The event processing layer provides user access and processing interfaces for different hardware types. For example, when we open the device / dev/input/mice, we will call the Mouse Handler to the event handling layer to handle the input events, which also makes the device driver layer do not need to care about the operation of the device file, because the Mouse Handler already has a corresponding event handling method.

The input subsystem is composed of kernel code drivers/input/input.c, which shields the interaction details between user and device driver, and provides a unified interface for device driver layer and event processing layer to communicate with each other.

Figure 2 below briefly describes the event handling mechanism of the linux input subsystem:

Fig. 2 event handling mechanism of linux input subsystem

From the figure above, you can see the support provided by the core layer of the input subsystem and how to report events to input event drivers.

As the driver developer of the input device, you need to do the following steps:

1. In the driver loading module, set the event types supported by your input device. For more information, please see Table 1.

2. Register interrupt handling functions, for example, keyboard devices need to write keys to lift and drop, touch screen devices need to write press, lift, absolute movement, mouse devices need to write click, lift, relative movement, and need to submit hardware data (key values / coordinates / status, etc.) when necessary.

3. Register the input device in the input subsystem

Table 1 data types supported by the Linux input subsystem

EV_SYN 0x00 synchronization event EV_KEY 0x01 keystroke event EV_REL 0x02 relative coordinates (e.g. mouse movement, report offset from the last position) EV_ABS 0x03 absolute coordinates (e.g. touchscreen or joystick Report absolute coordinate position) EV_MSC 0x04 other EV_SW 0x05 switch EV_LED 0x11 button / device lamp EV_SND 0x12 sound / alarm EV_REP 0x14 repeat EV_FF 0x15 force feedback EV_PWR 0x16 power supply EV_FF_STATUS 0x17 force feedback status maximum number of EV_MAX 0x1f event types and provide bitmask support

As can be seen from Table 1, according to the types of events that devices can represent, a device can select one or more event types to report to the input subsystem.

The Linux input subsystem provides a function for the device driver layer to report input events. In include/linux/input.h:

Voidinput_report_key (struct input_dev * dev, unsigned int code, int value); / report button events voidinput_report_rel (struct input_dev * dev, unsigned int code, int value); / report relative coordinate events voidinput_report_abs (struct input_dev * dev, unsigned int code, int value); / / report absolute coordinate events

After submitting the input event generated by the input device, you need to call the following function to notify the input subsystem to handle the complete event generated by the device:

Void input_sync (struct input_dev * dev)

2 simple case of input device driver

Under the documentation/input of the Linux kernel documentation, there is an input-programming.txt file that explains the core steps of writing an input device driver.

The provided case code describes a button device. The generated event is obtained through the BUTTON_PORT pin. When a press / release occurs, the BUTTON_IRQ is triggered. The following is the source code of the driver:

# include # include static struct input_dev * button_dev Static void button_interrupt (int irq, void*dummy, struct pt_regs * fp) {input_report_key (button_dev, BTN_1, inb (BUTTON_PORT) & 1); input_sync (button_dev);} static int _ init button_init (void) {int error If (request_irq (BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {printk (KERN_ERR "button.c: Can't allocate irq% d\ n", button_irq); return-EBUSY;} button_dev = input_allocate_device () If (! button_dev) {printk (KERN_ERR "button.c: Not enough memory\ n"); error =-ENOMEM; goto err_free_irq;} button_dev- > evbit [0] = BIT (EV_KEY); button_dev- > keybit [LONG (BTN_0)] = BIT (BTN_0) Error = input_register_device (button_dev); if (error) {printk (KERN_ERR "button.c: Failed to register device\ n"); goto err_free_dev;} return 0; err_free_dev: input_free_device (button_dev) Err_free_irq: free_irq (BUTTON_IRQ, button_interrupt); return error;} static void _ exit button_exit (void) {input_unregister_device (button_dev); free_irq (BUTTON_IRQ, button_interrupt);} module_init (button_init); module_exit (button_exit)

Writing a device driver based on the input subsystem needs to be included because it contains the interface of the input subsystem and all the macro definitions that need to be used when writing the input device driver.

Button_init function description:

The button_init function is called when the module is loaded (insmod) or during kernel boot. The first thing to do is to obtain the hardware resources (such as memory, IO memory, interrupt and DMA) that can correctly control the hardware device. As the interrupt resource of the BUTTON device in the code, BUTTON_IRQ is applied for registration through the request_irq () function. When a key is pressed / released, the button_interrupt () interrupt handler is called to get the key value BUTTON_PORT (the Imax O resource of the BUTTON device).

So how can the input subsystem know that this device is an input device? Through the eighth behavior device, a device is defined to describe an input device object.

Static struct input_dev * button_dev

Once the button_dev is defined, how do you notify the input subsystem that there is a new input device? Or how to add a new input device to the input subsystem? You can assign an input device through the functions provided in the core layer of the input subsystem, input.c, in line 25 of the code.

Button_dev= input_allocate_device ()

With the description of the input device, how can the input subsystem know the type of event generated by the device when the event occurs? Through 32 and 33 lines of code.

Button_dev- > evbit [0] = BIT (EV_KEY); button_dev- > keybit [LONG (BTN_0)] = BIT (BTN_0)

The evbit and keybit members represent the type of event generated by the device and the reported key value, respectively. Some bit operations NBITS, BIT, LONG of the input subsystem are often used:

# defineNBITS (x) (x) / BITS_PER_LONG) + 1) / / get the length of the array by bit x # defineBIT (x) (1UL)

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.