inputd

inputd is the normalized input routing service.

EriX is a clean-room, capability-based microkernel operating system written entirely in Rust.

Technical requirements are tracked in the EriX requirements, conventions, and project documentation.

See:

• docs for design documents, specifications, and development plans.
• Related architecture repositories for kernel, services, libraries, drivers, and integration tooling.

Purpose of This Repository

This repository implements the EriX input service daemon. Its purpose in EriX is to provide the input service role through explicit IPC and startup authority.

Functionally, it implements the daemon runtime, state model, IPC handling, and validation tests. The repository keeps the implementation, interface contracts, tests, and documentation for that behavior in one reviewable ownership boundary.

The maintained responsibilities are:

• implement the input service runtime and state model
• validate startup authority before accepting IPC requests
• push ordinary and trusted input through distinct ttyd-only routes
• retain events in the exact deployment-selected typed arena
• handle length-checked service operations through the assigned endpoint set
• keep service behavior, tests, and authority invariants documented

The authenticated startup bundle may omit the ordinary/trusted ttyd sender pair when framebuffer terminal input is disabled. Partial pairs are rejected; each omitted slot is checked absent once at startup and never polled or called later. Normalized keyboard/pointer events still reach inputd's provider ring, without terminal request IDs or trusted-key state changes. Logging policy is independent.

Clean-Room Policy

EriX follows a strict clean-room philosophy:

• No external source code may be copied.
• No external Rust crates are allowed.
• No code generation tools that embed third-party code.
• All code must be authored within the project.

Violations will result in rejection of the contribution.

License

All EriX repositories are licensed under the ISC License.

Development Model

EriX development is modular, deterministic, reproducible, authority-explicit, security-first, and self-hosting oriented.

This repository follows the project roadmap and the validation rules documented in its own roadmap.

Feature flags

• inputd-runtime
• inputd-runtime-input
• inputd-integration-smoke
• inputd-integration-force-fail
• inputd-integration-input

Build and test

cargo fmt --all -- --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-targets --all-features

Dependencies

• lib-bootstrap
• lib-capabi
• lib-ipc
• ipc-syscall-x86_64

No third-party crates are used.

The signed executable's generation-3 trusted-key policy recognizes Ctrl+Alt+Delete as secure attention. While Ctrl+Alt is held, Left/Right select the previous/next session, G inspects active grants, and K requests emergency termination of the focused session. Y, N, and Enter remain ordinary physical key events, even with Ctrl+Alt held; they never emit approval or denial intents. Ttyd alone captures answers for its exact visible prompt and confirms a decision on Enter. Inputd adds no prompt identity, lookup, or decision authority. Every control make becomes an exact sessionless trusted ttyd push; repeats and the matching release are consumed by the same policy. Ttyd derives focus and requires the matching secure-attention generation before acting. The public status exposes only the monotonic number of exact successful trusted acknowledgements for operational and VM evidence. All other key and pointer input uses the physically distinct ordinary ttyd route. Serial input remains outside inputd and cannot acquire trusted control authority through this policy.

The startup contract logic now lives in src/startup.rs, keeping the main event-loop implementation in src/main.rs below 1 kLoC. src/state_storage.rs validates the packaging-authenticated event-record count and exposes only that exact typed prefix of the dedicated state arena. src/tty_runtime.rs owns trusted-key classification and exact ttyd request/reply correlation.

Dynamic Boot Artifact Evidence

The image build packages inputd as an ELF64 x86_64 ET_DYN executable with .erix_dynlink metadata in the signed dynlink-store and mirrors it under /lib/erix/dynlink with its required shared objects.

Startup remains rootd through procd staged dynamic creation before dynlinkd. Authority remains explicit: inputd receives keyboard and mouse append receivers, distinct ordinary and trusted ttyd senders, and its narrow deviced peer. It receives no framebuffer, serial, service-discovery, session, or prompt authority and does not self-register; rootd publishes its read/status endpoint after observed readiness. Dynamic packaging and filesystem mirror records are evidence and launch inputs only; they do not grant filesystem, loader, object-store, discovery, provider-bypass, block-device, or dynlinkd authority.

Governance Principles

inputd governance is scoped to input event aggregation and dispatch.

The scoped governance rules are:

• The public endpoint accepts read/status operations only.
• Keyboard and mouse appends arrive through separate driver-only receivers. Endpoint identity derives the stored source role and constrains the event kind. Root has no synthetic-event ingress.
• Ttyd replies must echo the exact request, operation, and event identities.
• Ttyd transport and queue backpressure are retried with the same event identity and no daemon-local attempt or time ceiling. A no-focus result remains an explicit rejection and is not recorded as accepted input.
• Trusted-key classification cannot name a ttyd session, grant, object, or powerbox prompt and never converts a trusted chord into ordinary input.
• It bounds the event queue through explicit deployment policy, without a daemon-local record ceiling, and preserves ordering expected by consumers.
• It separates input routing policy from device-specific driver behavior.
• It does not manage driver processes or hardware ownership.

Authority Boundaries

• inputd operates only through startup-assigned service capabilities.
• Rootd owns inputd publication after startup readiness; inputd has no directory mutation authority.
• New authority must be represented in bootstrap/capability validation and integration tests before use.
• Runtime requests and peer replies carry no capability receipts. Unexpected receipts are retired before rejection; malformed receipt metadata fails stop because its installed-authority state cannot be proven clean.

Contact

Development occurs in EriX organization and discussions happen in issues and design documents.

No decisions are considered valid without documented rationale.

Maintainers can be reached via email: admin@erikinkinen.fi.