Phase 56

Display And Input Architecture

m3OS gains a real display and input model: one userspace-owned display service controls presentation, keyboard and mouse events are routed through an explicit focus-aware protocol, and multiple graphical clients can coexist without raw framebuffer conflicts.

Planned

Learning goal

Understand how a userspace display server separates kernel mechanism from GUI policy.

Why this phase matters

How it works in m3OS

The roadmap entry defines the learning scope for this phase; a deeper implementation doc has not been matched yet.

How it builds on earlier phases

This phase builds on Hardware Substrate and turns that foundation into Display And Input Architecture.

Implementation outline

Define the display-service ownership model and the client protocol.
Implement or complete the keyboard and mouse event model needed by the first graphical session.
Wire the display service into the existing service/session startup path.
Add multi-client presentation and focus management.
Validate crash/recovery behavior and fallback to administration paths.
Document the protocol, service graph, and non-goals for the first graphical architecture.

Task progress snapshot

No checklist tasks were discovered for this phase yet.

Documentation targets

Documentation deliverables have not been listed yet.

Deferred follow-on work

Rich widget/toolkit ecosystems
Hardware-accelerated composition
USB HID breadth beyond the needs of the first supported session
Desktop polish such as clipboard managers, notifications, and richer shells

Source materials

Roadmap entry

Important code

Code spotlight cards

When the phase lands, bump kernel/Cargo.toml and any release/version references to 0.56.0.

View on GitHub

Key files

kernel/Cargo.toml — When the phase lands, bump kernel/Cargo.toml and any release/version references to 0.56.0.

How real OSes differ

Mature desktop systems ship with far richer compositing, security, toolkit, and graphics-driver stacks.
Linux desktops rely on much deeper DRM/KMS and Wayland/X11 ecosystems than m3OS should try to copy immediately.
m3OS should prioritize one clear, restartable, userspace-owned display architecture over feature-rich but premature compatibility layers.

Success criteria

A userspace display service owns the primary display path.
At least two graphical clients can coexist without raw-framebuffer conflicts.
Keyboard and mouse events are routed through a documented focus-aware input model.
The display/input protocol is documented well enough for later clients to target without guesswork.
A display-service crash is recoverable or, at minimum, its failure mode and recovery path are explicitly documented and testable.

Related phases

Keep exploring the roadmap

Hardware Substrate

m3OS supports a small, deliberate reference-hardware matrix with a documented driver strategy, a reusable hardware-access layer, and at least one serious real-hardware storage and networking path. The project stops talking about hardware support as a vague future aspiration and starts treating it as a bounded support promise.

Audio And Local Session

m3OS supports a minimal local interactive session that feels like a system rather than a demo: there is a defined graphical session entry path, a basic terminal or launcher workflow, and audible PCM output on the supported platform.