Input Subsystem - Userspace Integration¶

This note describes how input events generated by kernel drivers are consumed and interpreted in userspace.

End-to-End Data Flow¶

Hardware (GPIO button)
    ↓
Kernel Driver (input_report_key)
    ↓
Input Core
    ↓
evdev (/dev/input/eventX)
    ↓
Userspace (udev / libinput / application)

Input Event vs Behavior¶

Input event:
    KEY_ENTER / KEY_ESC / KEY_SPACE

Behavior:
    newline / toggle / UI action

👉 Important:

Input event ≠ system behavior

Event Model Recap¶

EV_KEY:
    value = 1 → press
    value = 0 → release

input_sync():
    flush event frame

Userspace Layers¶

1. evdev¶

Interface: /dev/input/eventX
Raw event stream
Used by tools and applications

Example:

read("/dev/input/eventX")

2. udev¶

Detects device type
Adds properties

Example:

udevadm info /dev/input/eventX

Typical output:

ID_INPUT=1
ID_INPUT_KEY=1
ID_INPUT_KEYBOARD=1

3. libinput / GUI stack¶

Used by Wayland / X11
Maps input events to UI actions

4. Application¶

Custom logic defined by user

Example:

KEY_ENTER → toggle LED
KEY_ESC   → LED ON
KEY_SPACE → LED OFF

Mechanism vs Policy¶

Linux design principle:

Kernel:
    provides mechanism (event generation)

Userspace:
    defines policy (event meaning)

Example: GPIO Button Application¶

Kernel driver:

input_report_key(KEY_ENTER)
input_sync()

Userspace application:

if KEY_ENTER:
    toggle LED

Why Behavior Is Not in Kernel¶

Reasons:

Different applications need different behavior
Avoid hardcoding policy in kernel
Improve flexibility and reusability

Input vs IIO vs Char Driver¶

Model	Kernel Role	Userspace Role
Char Driver	everything	minimal
IIO	data provider	decode
Input	event provider	interpret

Summary¶

Input Subsystem:
    kernel generates events
    userspace decides behavior

Key Insight¶

Same input event can result in different behaviors depending on userspace application.