Input Subsystem Use Cases¶

This note summarizes when the Linux input subsystem should be used, what kinds of events it supports, and how to choose between Input, IIO, and other subsystems.

1. What Is the Input Subsystem?¶

The Linux input subsystem is designed for devices that generate human interaction events.

Typical examples:

Keyboard
Mouse
Touchscreen
Touchpad
GPIO button
Rotary encoder
IR remote controller
Lid switch
Headphone jack switch
Stylus / pen tablet

The key idea is:

Input Subsystem = human interaction events

It is not mainly for continuous sensor measurement data.

2. Input Subsystem Data Model¶

Input devices report events to the kernel input core.

The common flow is:

Hardware
    ↓
Input Driver
    ↓
Input Core
    ↓
evdev
    ↓
/dev/input/eventX
    ↓
Userspace application / libinput / GUI / terminal

The driver reports events by using APIs such as:

input_report_key()
input_report_abs()
input_report_rel()
input_sync()

Userspace reads events from:

/dev/input/eventX

3. Mechanism vs Policy¶

A very important Linux design concept:

Kernel:
    provides mechanism

Userspace:
    defines policy

For input devices:

Kernel driver:
    reports what happened

Userspace:
    decides what it means

Example:

KEY_ENTER event:
    terminal may treat it as newline
    GUI may treat it as confirm
    custom app may treat it as LED toggle

The same input event can produce different behavior depending on the userspace application.

4. Common Input Event Types¶

Input events are grouped by EV_* types.

4.1 EV_KEY¶

EV_KEY is used for buttons, keys, and binary press/release events.

Typical examples:

Keyboard keys
GPIO buttons
Mouse buttons
Remote control buttons
Power button
Volume buttons

Example key codes:

KEY_ENTER
KEY_ESC
KEY_SPACE
KEY_POWER
KEY_VOLUMEUP
KEY_VOLUMEDOWN
BTN_LEFT
BTN_RIGHT
BTN_TOUCH

Typical usage:

input_report_key(input, KEY_ENTER, 1);  // press
input_sync(input);

input_report_key(input, KEY_ENTER, 0);  // release
input_sync(input);

Event value meaning:

Value	Meaning
0	Released
1	Pressed
2	Auto-repeat

Use EV_KEY when the device produces a discrete action or button-like event.

4.2 EV_REL¶

EV_REL is used for relative movement.

Typical examples:

Mouse movement
Mouse wheel
Trackball

Common codes:

REL_X
REL_Y
REL_WHEEL

Example:

input_report_rel(input, REL_X, dx);
input_report_rel(input, REL_Y, dy);
input_sync(input);

Use EV_REL when the device reports movement relative to the previous position.

4.3 EV_ABS¶

EV_ABS is used for absolute position or analog-like input values.

Typical examples:

Touchscreen
Touchpad
Joystick
Stylus
Slider
Touch IC with position output

Common codes:

ABS_X
ABS_Y
ABS_Z
ABS_PRESSURE
ABS_DISTANCE
ABS_MT_POSITION_X
ABS_MT_POSITION_Y
ABS_MT_TRACKING_ID

Example:

input_report_key(input, BTN_TOUCH, 1);
input_report_abs(input, ABS_X, x);
input_report_abs(input, ABS_Y, y);
input_sync(input);

Use EV_ABS when the device reports a position or absolute value.

4.4 EV_SW¶

EV_SW is used for switch state.

Typical examples:

Laptop lid switch
Headphone inserted
Tablet mode switch
Docking state

Common codes:

SW_LID
SW_HEADPHONE_INSERT
SW_TABLET_MODE

Use EV_SW when the device state is persistent rather than a momentary press.

Example:

lid open  → SW_LID = 0
lid close → SW_LID = 1

4.5 EV_SYN¶

EV_SYN is used to mark event synchronization.

Most drivers do not report EV_SYN directly. Instead, they call:

input_sync(input);

This generates:

EV_SYN / SYN_REPORT

Meaning:

This group of input events is complete.

Example:

input_report_key(input, BTN_TOUCH, 1);
input_report_abs(input, ABS_X, x);
input_report_abs(input, ABS_Y, y);
input_sync(input);

Userspace receives these events as one logical input frame.

5. Button-like Devices¶

For a simple GPIO button, use:

EV_KEY

Example mapping:

Hardware Action	Input Event
Button press	KEY_ENTER press
Button release	KEY_ENTER release

Example:

input_report_key(input, KEY_ENTER, 1);
input_sync(input);

input_report_key(input, KEY_ENTER, 0);
input_sync(input);

For higher-level patterns such as short click, long click, or double click, there are two possible designs.

5.1 Kernel-side Gesture Detection¶

The driver detects patterns and maps them to key events.

Example:

Gesture	Input Event
Short click	KEY_ENTER
Long click	KEY_ESC
Double click	KEY_SPACE

This is useful for learning or simple embedded systems.

However, it puts more policy into the kernel.

5.2 Userspace Gesture Detection¶

The driver reports raw press/release events only.

Userspace detects:

Short click
Long click
Double click
Combination actions

This is usually more flexible.

Recommended design:

Kernel:
    reports raw button state

Userspace:
    interprets click pattern

6. Touch IC Use Cases¶

A touch IC may be used in different ways.

The correct input event type depends on what the IC provides.

6.1 Touch IC with Touch / No-touch Only¶

If the IC only reports whether a finger is touching:

Use EV_KEY + BTN_TOUCH

Example:

input_report_key(input, BTN_TOUCH, 1);
input_sync(input);

input_report_key(input, BTN_TOUCH, 0);
input_sync(input);

This represents a binary touch state.

6.2 Touch IC with Position Data¶

If the IC reports X/Y position:

Use EV_ABS + ABS_X / ABS_Y
Optionally use BTN_TOUCH

Example:

input_report_key(input, BTN_TOUCH, 1);
input_report_abs(input, ABS_X, x);
input_report_abs(input, ABS_Y, y);
input_sync(input);

This is suitable for:

Touchpad
Touch slider
Touch surface
Touchscreen-like input

6.3 Touch IC with Multi-touch Data¶

If the IC supports multiple fingers:

Use multi-touch ABS_MT_* events

Common events:

ABS_MT_POSITION_X
ABS_MT_POSITION_Y
ABS_MT_TRACKING_ID
ABS_MT_PRESSURE

This is more complex and usually follows the Linux multi-touch protocol.

6.4 Touch IC with Built-in Gesture Recognition¶

If the IC already detects gestures, such as:

Tap
Swipe left
Swipe right
Swipe up
Swipe down

Then the driver may map them to EV_KEY.

Example:

IC Gesture	Input Event
Tap	KEY_ENTER
Swipe left	KEY_LEFT
Swipe right	KEY_RIGHT
Swipe up	KEY_UP
Swipe down	KEY_DOWN

Example:

input_report_key(input, KEY_LEFT, 1);
input_sync(input);

input_report_key(input, KEY_LEFT, 0);
input_sync(input);

This is suitable when the IC itself already provides high-level gesture results.

7. ABS_PRESSURE¶

ABS_PRESSURE is used when the device reports pressure or touch strength.

It is not the same as BTN_TOUCH.

Event	Meaning
BTN_TOUCH	Touch or no touch
ABS_PRESSURE	How strong the touch is

Typical use cases:

Stylus pressure
Drawing tablet
Force touch sensor
Pressure-sensitive touchpad
Touch IC reporting capacitance strength
Resistive touch panel pressure

Example:

input_report_key(input, BTN_TOUCH, 1);
input_report_abs(input, ABS_X, x);
input_report_abs(input, ABS_Y, y);
input_report_abs(input, ABS_PRESSURE, pressure);
input_sync(input);

Do not fake ABS_PRESSURE if the hardware does not provide meaningful pressure or strength data.

If the hardware only provides touch/no-touch, use:

BTN_TOUCH

If the hardware provides touch strength, use:

BTN_TOUCH + ABS_PRESSURE

8. IR Devices¶

IR devices can belong to different subsystems depending on their purpose.

8.1 IR Remote Controller¶

An IR remote is a human input device.

Use:

Input Subsystem
EV_KEY

Example:

Remote Button	Input Event
Power	KEY_POWER
Volume Up	KEY_VOLUMEUP
Volume Down	KEY_VOLUMEDOWN
OK	KEY_ENTER

The driver or IR subsystem decodes the remote signal and reports key events.

8.2 IR Distance / Proximity Sensor¶

An IR distance sensor measures physical data.

Use:

IIO Subsystem

Examples:

Distance
Proximity level
Light intensity
Reflectance

These are measurement values, not human input events.

9. Ultrasonic Sensor¶

An ultrasonic sensor usually measures distance.

Example data:

distance = 120 mm
distance = 35 cm

This is measurement data.

Use:

IIO Subsystem

Do not use the input subsystem unless the ultrasonic sensor is converted into a human-facing event, such as:

object detected → KEY_PROG1
gesture detected → KEY_LEFT / KEY_RIGHT

But in most cases, ultrasonic sensors belong to IIO.

10. Input vs IIO Decision Rule¶

A practical rule:

Human interaction → Input Subsystem
Physical measurement → IIO Subsystem

Examples:

Device	Recommended Subsystem
GPIO button	Input
Keyboard	Input
Mouse	Input
Touchscreen	Input
Touchpad	Input
Touch slider	Input
IR remote	Input
Rotary encoder	Input
Ultrasonic distance sensor	IIO
IR distance sensor	IIO
Temperature sensor	IIO / hwmon
ADC	IIO
Accelerometer	IIO / Input depending on use
Light sensor	IIO
Proximity sensor	IIO, sometimes bridged to Input

11. Hybrid Cases¶

Some devices can be modeled in more than one way.

11.1 Accelerometer¶

If used for measurement:

Use IIO

Example:

accel_x
accel_y
accel_z

If used as an input device for simple orientation or tap detection:

May report Input events

Example:

tap detected → KEY_WAKEUP
orientation change → SW_TABLET_MODE

11.2 Proximity Sensor¶

If reporting distance or proximity value:

Use IIO

If used to generate a specific user interaction event:

May report Input event

Example:

near detected → wake screen
far detected  → no action

In many systems, the kernel exposes raw measurement via IIO, and userspace decides the behavior.

12. Commercial Sensing IC Design¶

For a sensing IC company, a good Linux architecture is often:

Kernel driver:
    exposes standard input or IIO events/data

Userspace library:
    implements proprietary algorithm, gesture recognition, calibration, or policy

This allows:

Use of Linux standard subsystems
Better compatibility
Protection of proprietary algorithms
Cleaner separation of mechanism and policy

Example for touch IC:

Kernel:
    reports ABS_X / ABS_Y / BTN_TOUCH

Userspace:
    detects swipe / tap / gesture

Example for sensor IC:

Kernel:
    reports raw data through IIO

Userspace:
    performs filtering, calibration, classification

Using the input subsystem does not require exposing proprietary userspace algorithms.

13. Design Guidelines¶

Prefer Raw Events When Possible¶

If the hardware provides raw position or state:

Report raw input data
Let userspace interpret behavior

Example:

Touch IC provides X/Y:
    report ABS_X / ABS_Y
    userspace detects gestures

Use Key Events for Already-decoded Gestures¶

If the IC already outputs high-level gestures:

Map gestures to EV_KEY

Example:

SWIPE_LEFT  → KEY_LEFT
SWIPE_RIGHT → KEY_RIGHT
TAP         → KEY_ENTER

Avoid Putting Too Much Policy in Kernel¶

Avoid complex behavior logic in kernel unless necessary.

Examples of logic better placed in userspace:

UI behavior
Gesture policy
Application action
Mode-dependent behavior
Product-specific mapping

14. Summary¶

Input Subsystem:
    for human interaction events

IIO Subsystem:
    for measurement data

Use Input when the device represents:

Button
Key
Switch
Touch
Pointer movement
Human gesture
Remote control input

Use IIO when the device represents:

Temperature
Voltage
Distance
Light
Acceleration
Raw sensor measurement

Final rule:

If the question is "what did the user do?"
    → Input Subsystem

If the question is "what is the measured value?"
    → IIO Subsystem