Input subsystem analysis [input event evdev]

From: http://blog.csdn.net/colorant/archive/2007/04/12/1561837.aspx

1. Input subsystem Architecture Overview

Shows the input subsystem architecture.

 

The input subsystem consists of the input core, the driver layer, and the event handler layer. An input event, such as moving the mouse, pressing the keyboard, and moving joystick, arrives at the user space and passes it to the application in the order of driver-> inputcore-> eventhandler-> userspace.
The input core is the input layer implemented by driver/input. C and related header files. Provides the device driver interface and the event handler layer programming interface.

1.1 Main Data Structure

Table 1Input subsystem main Data Structure

Data Structure	Purpose	Define location	Data structure Allocation and initialization
Struct input_dev	Basic Data Structure of the driver layer physical Input Device	Input. h	Usually assign and fill in the specific device structure in the specific device driver
Struct evdev Struct mousedev Struct keybdev...	Data Structure of the logic input device at the event handler Layer	Evdev. c Mousedev. c Keybdev. c	Evdev. c/mouedev. C... Medium allocation
Struct input_handler	Event Handler Structure	Input. h	The event handler layer defines a specific event handler.
Struct input_handle	Used to create the linked list item structure of the drive layer Dev and handler linked lists	Input. h	Event Handler layer allocation, including in evdev/mousedev... .

 

1.2 example of input subsystem architecture

Figure 2 example of input subsystem architecture

2. process of creating input links

The input sub-system separates the input process of an input device into two independent parts: Drive to input core, input core to event handler. Therefore, the interfaces of the entire link are created independently.

2.1 registration of hardware devices

The driver layer is responsible for dealing with underlying hardware devices. It converts the responses of underlying hardware to user input into standard input events and then sends them to the input core.
The driver layer registers and deregisters the input device from the input subsystem by calling the input_register_device function and the input_unregister_device function.
The parameters used to call these two functions are an input_dev structure defined in Driver/input. h. The driver layer needs to fill in some fields in this structure before calling input_register_device.

# Include <Linux/input. h>
# Include <Linux/module. h>
# Include <Linux/init. h>

Module_license ("GPL ");

Struct input_dev exmo-dev;

Static int _ init ex1_init (void)
{
/* Extra safe initialization */
Memset (& exshortdev, 0, sizeof (struct input_dev ));
Init_input_dev (& exmo-dev );

/* Set up descriptive labels */
Excludev.name = "Example 1 device ";
/* Phys is unique on a running system */
Exdeskdev.phys = "A/fake/path ";
Exdeskdev.id.bustype = bus_host;
Exdeskdev.id.vendor = 0x0001;
Exdeskdev.id.product = 0x0001;
Excludev.id.version = 0x0100;

/* This device has two keys (a and B )*/
Set_bit (ev_key, exmo-dev.evbit );
Set_bit (key_ B, exmo-dev.keybit );
Set_bit (key_a, exmo-dev.keybit );

/* And finally register with the input core */
Input_register_device (& exmo-dev );

Return 0;
}

The evbit field defines the types of events that the input device supports (generate and respond.
Including:

Ø ev_rst 0x00 Reset
Ø ev_key 0x01 buttons
Ø ev_rel 0x02 relative coordinates
Ø ev_abs 0x03 absolute coordinates
Ø ev_msc 0x04 others
Ø ev_led 0x11 led
Ø ev_snd 0x12 sound
Ø ev_rep 0x14 repeat
Ø ev_ff 0x15 Force Feedback

One device supports one or more event types. Under each event type, you also need to set specific trigger events, such as ev_key events and buttons supported.

2.2 event handler layer 2.2.1 register input Handler

The driver layer only registers the input device to the input subsystem, and does not create a device node in the driver layer code. The event handler layer calls the function in input core to create a device node for applications to deal with devices. Before creating a specific device node, the event handler layer needs to register the input event processing functions and related interfaces of a type of device.
Taking mousedev handler as an example:

Static struct input_handler mousedev_handler = {
Event: mousedev_event,
Connect: mousedev_connect,
Disconnect: mousedev_disconnect,
FoPs: & mousedev_fops,
Minor: mousedev_minor_base,
};

Static int _ init mousedev_init (void)
{
Input_register_handler (& mousedev_handler );

Memset (& mousedev_mix, 0, sizeof (struct mousedev); Z
Init_waitqueue_head (& mousedev_mix.wait );
Mousedev_table [mousedev_mix] = & mousedev_mix;
Mousedev_mix.exist = 1;
Mousedev_mix.minor = mousedev_mix;
Mousedev_mix.devfs = input_register_minor ("mice", mousedev_mix, mousedev_minor_base );

Printk (kern_info "mice: PS/2 mouse device common for all mice/N ");

Return 0;
}

Call input in mousedev_init. the input_register_handler defined in C is used to register a handler of the mouse type. here, handler is not a specific device that users can operate, but a unified processing function interface for mouse devices.

2.2.2 create a device Node

Next, the mousedev_init function calls input_register_minor to register a general-purpose mice device. This is the specific device interface associated with the user. However, the creation of a general mice device in the init function is only a special case of the event handler layer of the mouse. In other types of eventhandler layers, a general device may not be created.
The standard procedure is as follows: after the hardware driver registers a hardware device with the input subsystem, it calls the connect function of all registered input handler in input_register_device, each specific connect function determines whether it is related to itself based on the event types supported by the registered device. If it is related, call input_register_minor to create a specific device node.

Void input_register_device (struct input_dev * Dev)
{
......
While (handler ){
If (handle = Handler-> connect (handler, Dev )))
Input_link_handle (handle );
Handler = Handler-> next;
}
}

In addition, if you have already registered some hardware devices, then register a new type of input handler, the new input handler connect function will also be called for all registered devices to determine whether to create a new device node:

Void input_register_handler (struct input_handler * Handler)
{
......
While (Dev ){
If (handle = Handler-> connect (handler, Dev )))
Input_link_handle (handle );
Dev = Dev-> next;
}
}

From the above analysis, we can see that a type of input handler can be associated with multiple hardware devices to create multiple device nodes. A device may also be associated with multiple input handler to create multiple device nodes.
For the sake of intuition, many-to-many relationships between physical devices, input handler, and logical devices are visible:

Figure 3 physical device, input handler, logical device Relationship Diagram

3. Enable and read/write Devices

The user program uses open, read, write, and other functions of the device node created in the input handler layer to open and read the input device.

3.1 open

The open function of a device node first calls a specific type of open function of input handler to process some general transactions related to this type of device, such as initializing the event buffer. Then, use the input_open_device function in input. C to call the OPEN function of a specific hardware device in the driver layer.

3.2 read

Most input handler read functions are waiting on the wait queue of the event layer logical device. When the device driver sends an event notification to the input subsystem by calling the input_event function, the relevant input handler event function is called, this event function will wait for the queue to wake up after filling the event buffer.
In the driver layer, a possible implementation mechanism for reading device input is to scan the input function to sleep in the waiting queue of the driver device, and wake up the waiting queue in the interrupt function of the device driver, then scan the input function to package the device input into an event to notify the input subsystem.

3.3 write

2.4 There is no fixed mode in the kernel. According to the specific input handler, it may not be implemented, or it may call input_event to notify the input subsystem of the data written in the form of an event again, or call the write function of the device driver.
2.6 In the kernel code, call input_event to notify the input subsystem of the written data again in the form of an event, and then in the input. in C, events that need to be fed back to the physical device are sent to the device driver for processing by calling the event function of the physical device, such as the ev_led event:

Void input_event (struct input_dev * Dev, unsigned int type, unsigned int code, int value)
{
......
Case ev_led:
If (code> led_max |! Test_bit (Code, Dev-> ledbit) | !! Test_bit (Code, Dev-> led) = value)
Return;

Change_bit (Code, Dev-> led );
If (Dev-> event) Dev-> event (Dev, type, code, value );
Break;
......
}

4 others

The analysis of the input subsystem architecture in this article is mainly based on the 2.4.20 kernel. In the 2.6 kernel, the input subsystem is greatly expanded to support many devices (such as touch screens and keyboards ). However, the overall framework is consistent.

In addition, I have referenced two articles on Linux Journal:

 

The Linux USB input subsystem, Part I | Linux Journal
Using the input subsystem, Part II | Linux Journal