Progress
- Implemented userspace input reader
- Parsed
/dev/input/eventX using Python
- Decoded EV_KEY events (press only)
- Mapped key codes to logical actions (short / long / double click)
- Controlled ACT LED via sysfs interface
- Verified full pipeline from hardware to application
System Validation
GPIO Button
↓
Input Driver (kernel)
↓
/dev/input/eventX
↓
Python Application
↓
LED Control (sysfs)
Observations
- evtest shows raw input events but no behavior
- input events must include both press (1) and release (0)
- userspace applications typically only react to press (value = 1)
- LED control requires setting trigger to "none"
/sys/class/leds/ACT is usable as a simple output device
- event device is accessible only with root privilege
Issues
- evtest not installed initially → fixed via package install
- sed-based device detection failed → replaced with awk parsing
- LED trigger default not manual → required explicit configuration
- event device number (eventX) is dynamic → solved by auto-detection
Result
✔ Input events successfully parsed in userspace
✔ Short / long / double click correctly identified
✔ LED behavior matches application logic
✔ End-to-end pipeline validated
Key Takeaways
- Input subsystem separates event generation from behavior
- Kernel driver should not define application logic
- Userspace is responsible for interpreting events
- Same input event can produce different behavior depending on application
- Input model is fundamentally event-driven (not data-driven like IIO)
Comparison Insight
Char Driver:
kernel handles everything
IIO:
kernel provides data
userspace interprets data
Input:
kernel provides events
userspace defines behavior
Reflection
- Transition from kernel-space thinking to system-level thinking
- Better understanding of Linux design philosophy (mechanism vs policy)
- Experience building a complete input pipeline across layers
- Reinforced importance of userspace integration in driver design
Summary
Day43:
kernel generates input events
Day44:
userspace consumes and uses events
Full stack:
hardware → kernel → subsystem → userspace → application