After review push-back on the dual-path (orbclient + evdev) input
architecture, the v6.0 plan is simplified to a single evdev producer
model. The user committed: 'we do not use Orbital and do not plan to
use it. we aim for wayland/kde.'
The dual-path was rejected for:
- Doubling every driver's event-write code
- Doubling per-event syscall cost
- Out-of-order risk between the two producers
- Translating back and forth loses metadata
- No desktop consumer actually needs Orbital
The corrected architecture:
Hardware
-> single /scheme/input/evdev producer (Linux struct input_event)
-> evdevd (pure scheme->/dev/input/eventN adapter)
-> /dev/input/eventN
-> libinput in-process to KWin (user session)
-> libinput in-process to redbear-compositor (greeter)
-> direct evdev fd (Qt6 apps that need raw access)
inputd is deprecated for the desktop config. It stays in the tree
only as a historical daemon.
What this changes:
1. Phase 1 effort drops from 1-2 weeks to 1 week
2. Drivers change ONCE (replace ProducerHandle with
EvdevProducerHandle) instead of dual-writing
3. evdevd refactor is now cleaner: just switch its consumer from
/scheme/input/consumer (orbclient) to /scheme/input/evdev
(Linux evdev)
4. inputd/src/lib.rs gains a new EvdevProducerHandle, EvdevEvent,
keycodes module — committed in the base fork first
Plan updates:
- Section 2 (Unified Input Architecture) rewritten to 'Single-Producer
Input Architecture'
- Critical path Phase 1 row updated to reflect 1-week effort
- Executive summary text updated
- 'Two Architecture Decisions Resolved' updated to reflect
Orbital-out decision
vasilito
d6df6ede5a