Understanding the Android Input Subsystem: Definitions, Initialization, Registration, Matching, and Event Transmission

Android is built on the Linux kernel, and the kernel serves as the core of the operating system, handling hardware drivers and providing essential system services. To manage the wide variety of input devices (keys, touch screens, gamepads, etc.), the kernel abstracts their processing through the Input subsystem, which standardizes device definitions, handler definitions, core services, and user‑space interfaces.

The subsystem’s main responsibilities are:

Standardizing the definition and data reporting format of Input Devices.

Standardizing the definition of Input Handlers and their required callbacks.

Providing core services for both Devices and Handlers.

Exposing a standardized user‑space interface.

1. Input_dev

The struct input_dev abstracts all input devices. It contains common members (x) and device‑specific members (y1, y2, …). Driver developers only need to fill the relevant members for a particular device.

2. Input_handler

The struct input_handler abstracts event handling. It uses function‑pointer callbacks for matching, connecting, and filtering events, ensuring a uniform processing flow across different devices.

3. Input_handle

The struct input_handle acts as a bridge between an input_dev and an input_handler , allowing many‑to‑many relationships between devices and handlers.

Input Subsystem Workflow

1. Input core initialization

The core registers itself via subsys_initcall to run before device and handler registration. Initialization tasks include:

Registering the input class.

Creating a /proc entry for viewing handlers and devices.

Registering a character device with major number 13.

2. input_dev registration

Device drivers create an input_dev structure and register it with input_register_device , which sets up the device for event reporting.

3. input_handler registration

After filling a struct input_handler , developers call input_register_handler to register the handler.

4. Matching input_handler with input_dev

Both registrations eventually invoke input_attach_handler , establishing the relationship shown in the diagrams. If a handler’s match callback is absent, matching falls back to comparing IDs (e.g., evdev_handler matches all devices).

When a match succeeds, the handler’s connect callback is called (e.g., the evdev_handler connect routine).

5. Input event transmission

Devices report events via input_event . After determining the event’s disposition, the kernel either forwards the event to the device’s own event function or to the handlers via input_handle_event . Events are buffered in dev->vals and flushed to handlers on EV_SYN or when the buffer is full.

The function input_get_disposition decides the disposition based on type and code . For EV_KEY events, the kernel checks !!test_bit(code, dev->key) != !!value to avoid redundant reports.

6. Delivering events to user space

When a user‑space process reads /dev/input/event* , evdev_read retrieves events from the circular buffer ( client->buffer ) and copies them to user space via input_event_to_user . The Android framework’s InputFlinger creates two threads: InputReader (reads raw events from the kernel) and InputDispatcher (dispatches processed events to windows).

References

1. https://www.cnblogs.com/lifexy/p/7542989.html

2. https://blog.csdn.net/qq_39937242/article/details/82631165