vasilito/RedBear-OS
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
36afba773a8ae2de20dbcd954186da77a8536e96
RedBear-OS/local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md
T
vasilito 6c2643bd9c Expand linux-kpi wireless scaffolding, consolidate desktop plan, remove historical report 
Add channel/band/rate/BSS/RX-TX structures to linux-kpi wireless
scaffolding (mac80211.rs, wireless.rs, net.rs, C headers), extend
redbear-iwlwifi linux_port.c with comprehensive PCIe transport, and
create consolidated CONSOLE-TO-KDE-DESKTOP-PLAN.md as the canonical
desktop path document. Remove stale INTEGRATION_REPORT.md (1388 lines)
in favor of current local/docs/ references. Update AGENTS.md, README,
and docs index to point to the new plan.
2026-04-16 13:52:09 +01:00

896 lines
35 KiB
Markdown
Raw Blame History

# Red Bear OS: Console to Hardware-Accelerated KDE Desktop on Wayland
## Purpose
This document is the single authoritative implementation plan for the Red Bear OS path from
console boot to a hardware-accelerated KDE Plasma desktop on Wayland.
It consolidates and replaces the roadmap role previously spread across:
- `docs/03-WAYLAND-ON-REDOX.md`
- `docs/05-KDE-PLASMA-ON-REDOX.md`
- `docs/02-GAP-ANALYSIS.md`
- `local/docs/AMD-FIRST-INTEGRATION.md`
- `local/docs/DESKTOP-STACK-CURRENT-STATUS.md`
- `local/docs/QT6-PORT-STATUS.md`
Those documents still matter for subsystem detail, package status, and implementation history.
This document is the place to answer the higher-level question: what still has to happen, in the
right order, before Red Bear OS can honestly claim a usable KDE Plasma desktop on Wayland, first
on the software path and then on real hardware acceleration.
This plan is grounded in the current repo state, not in older greenfield assumptions. The project
already has substantial build-side progress across relibc, driver infrastructure, Wayland, Mesa,
Qt6, KF6, D-Bus, and desktop-facing profiles. The remaining problem is mostly not package absence.
The remaining problem is the gap between what builds and what is runtime-trusted.
Scope here covers console boot to first working Wayland compositor proof, software-rendered Qt6 on
Wayland, hardware GPU validation for AMD and Intel, KWin session bring-up, and KDE Plasma session
bring-up. It does not cover USB, Wi-Fi, Bluetooth, tutorial-style examples, or repo structure and
build-command reference material already documented elsewhere.
This document uses the current Red Bear hardware policy. AMD and Intel GPUs are equal-priority
desktop targets.
## Current State Baseline
### Evidence model
This plan uses six evidence classes. They are intentionally strict and are not treated as equal.
| Evidence class | Meaning | Safe wording | Not safe wording |
|---|---|---|---|
| **builds** | package compiles and stages | builds | works |
| **boots** | image reaches prompt or known runtime surface | boots | desktop works |
| **enumerates** | scheme, device node, or service surface appears and answers basic queries | enumerates | usable end to end |
| **usable** | a bounded runtime path performs its intended task | usable for this path | broadly stable |
| **validated** | repeated proof on the intended target class with explicit checks | validated | complete everywhere |
| **experimental** | partial, scaffolded, or unproven despite visible progress | experimental | done |
Interpretation rules used throughout this document:
- if something only compiles, it is called **builds**
- if something boots but does not complete a session, it is called **boots**
- if a daemon registers a scheme or device node, it is called **enumerates**
- if the only proof is a bounded QEMU path, the claim stays bounded to that path
- if dependencies are still shimmed or stubbed, the layer remains **experimental**
- nothing is called **validated** without repeated runtime proof on the intended target class
### Honest capability matrix
| Area | Current state | Evidence | Notes |
|---|---|---|---|
| AMD bare-metal boot | present | validated for bounded current claim | ACPI, SMP, x2APIC all work |
| relibc Wayland and Qt unblockers | present | builds | signalfd, timerfd, eventfd, open_memstream, F_DUPFD_CLOEXEC, MSG_NOSIGNAL, bounded waitid, bounded RLIMIT, bounded eth0 networking, shm_open, bounded sem_open, bounded sys/ipc.h, bounded sys/shm.h |
| redox-driver-sys | present | builds | driver substrate |
| linux-kpi | present | builds | compatibility layer for Linux-style drivers |
| firmware-loader | present | builds, boots | scheme registers at boot |
| redox-drm with AMD and Intel | present | builds | runtime hardware validation still open |
| amdgpu C port | present | builds | AMD DC + TTM + linux-kpi compat compiles |
| evdevd | present | builds, boots | scheme registers at boot |
| udev-shim | present | builds, boots | scheme registers at boot |
| libwayland 1.24.0 | present | builds | no full compositor proof yet |
| wayland-protocols | present | builds | build-side blocker removed |
| Mesa EGL + GBM + GLES2 | present | builds | proven runtime path is still software via LLVMpipe |
| libdrm + libdrm_amdgpu | present | builds | package-level success only |
| Qt6 qtbase 6.11.0 | present | builds | Core, Gui, Widgets, DBus, Wayland, OpenGL, EGL |
| qtdeclarative | present | builds | QML JIT disabled |
| qtsvg | present | builds | build-visible |
| qtwayland | present | builds | build-visible |
| D-Bus 1.16.2 | present | builds, bounded runtime wiring | system bus wired in `redbear-full` |
| libinput 1.30.2 | present | builds | runtime integration still open |
| libevdev 1.13.2 | present | builds | runtime integration still open |
| linux-input-headers | present | builds | support package |
| seatd | present | builds | session-management runtime proof still open |
| All 32 KF6 frameworks | present | builds | major build milestone complete |
| kdecoration | present | builds | build-visible |
| plasma-wayland-protocols | present | builds | build-visible |
| kf6-kwayland | present | builds | build-visible |
| kf6-kcmutils | present | builds, reduced | widget-only build |
| `redbear-wayland` | present | builds, boots | bounded Wayland runtime profile |
| `redbear-full` | present | builds, boots | broader desktop plumbing profile |
| `redbear-kde` | present | builds | KDE session-surface profile |
| smallvil path | partial | boots, experimental | reaches xkbcommon init and EGL platform selection in QEMU |
| QEMU graphics truth | present | usable for bounded path | current renderer is llvmpipe, not hardware acceleration |
| D-Bus system bus in `redbear-full` | present | usable for bounded path | not equal to full session integration completeness |
| VirtIO networking in QEMU | present | usable | useful for bounded test environment |
| firmware-loader, evdevd, udev-shim scheme registration | present | enumerates | register during boot |
| KWin | blocked | experimental | recipe exists, blocked by remaining shimmed and stubbed dependencies |
| plasma-workspace | partial | experimental | recipe exists, still experimental |
| plasma-desktop | partial | experimental | recipe exists, still experimental |
| QtNetwork | blocked | intentionally disabled | relibc networking completeness still too narrow |
| hardware GPU acceleration | blocked | not runtime-proven | kernel DMA-BUF fd passing required |
| working Wayland compositor session | blocked | runtime not proven | smallvil does not complete a usable session |
| KWin compositor runtime | blocked | runtime not proven | no working KWin session |
| KDE Plasma session | blocked | runtime not proven | no full Plasma session |
### What is DONE, build-side
The repo has already crossed several major build-side gates.
#### relibc surface that now builds downstream consumers
The current build-visible relibc surface includes signalfd, timerfd, eventfd, open_memstream,
F_DUPFD_CLOEXEC, MSG_NOSIGNAL, bounded waitid, bounded RLIMIT behavior, bounded eth0 networking,
shm_open, bounded sem_open, bounded `sys/ipc.h`, and bounded `sys/shm.h`.
#### driver and runtime-service substrate
redox-driver-sys, linux-kpi, firmware-loader, redox-drm with AMD and Intel paths, the amdgpu C
port, evdevd, and udev-shim all build successfully.
#### Wayland and graphics packages
libwayland 1.24.0, wayland-protocols, Mesa EGL + GBM + GLES2 with `libEGL.so`, `libgbm.so`,
`libGLESv2.so`, `swrast_dri.so`, plus libdrm and libdrm_amdgpu all build.
#### Qt6 and D-Bus
D-Bus 1.16.2 builds. qtbase 6.11.0 builds with Core, Gui, Widgets, DBus, Wayland, OpenGL, and
EGL. qtdeclarative, qtsvg, and qtwayland also build.
#### KF6 and KDE-facing build surfaces
All 32 KF6 frameworks build. The completed set spans ecm, core and widget foundations, config,
internationalization, codecs, GUI add-ons, color and notification layers, job and archive support,
item models and views, Solid, D-Bus and service layers, package and crash handling, text and icon
layers, global shortcuts, KDE declarative support, XML GUI, bookmarks, idle time, KIO, and
KCMUtils. Additional KDE-facing packages that already build include kdecoration,
plasma-wayland-protocols, kf6-kwayland, and kf6-kcmutils.
#### tracked desktop profiles
The tracked desktop-facing profiles are `redbear-wayland`, `redbear-full`, and `redbear-kde`.
These are real achievements and should be presented as such. They are not yet desktop-runtime proof.
### What is runtime-proven, limited scope
The current desktop-related runtime proof is bounded, but real.
#### Boot and machine substrate
Red Bear boots on AMD bare metal, and ACPI, SMP, and x2APIC work for the current bounded claim.
#### bounded Wayland bring-up path
`redbear-wayland` boots in QEMU, and smallvil reaches xkbcommon initialization plus EGL platform
selection on Redox.
#### bounded graphics truth
Current QEMU graphics are software-rendered, the renderer evidence is llvmpipe, QEMU is useful for
compositor and Qt bring-up, and QEMU is not proof of the final hardware-accelerated desktop path.
#### bounded runtime services
D-Bus system bus is wired in `redbear-full`, VirtIO networking works in QEMU, and firmware-loader,
evdevd, and udev-shim register schemes at boot.
### What is NOT DONE
This list must stay explicit.
#### runtime not proven
No GPU hardware-accelerated rendering is proven, no kernel DMA-BUF support exists for the required
desktop path, no working Wayland compositor session is proven, no KWin compositor runtime is
proven, no KDE Plasma session is proven, and Qt6 OpenGL and EGL still have only software-path
runtime proof.
#### builds still blocked or scaffolded
KWin does not build end to end with fully real dependencies. Kirigami is still stub-only, KIO is
still a heavy shim build, libepoxy, libudev, lcms2, and libdisplay-info remain real blockers,
plasma-workspace and plasma-desktop remain experimental, and QtNetwork remains disabled due to
incomplete relibc networking semantics.
### Baseline conclusion
The repo is no longer stuck at package availability. It is now limited by runtime trust, hardware
validation, and KWin or Plasma session assembly. That is the real starting point for the plan below.
## Dependency Stack
### ASCII layer diagram
```text
+--------------------------------------------------------------------------------+
| KDE Plasma Session |
| plasma-workspace, plasma-desktop, shell, panels, launcher, apps |
+---------------------------------------^----------------------------------------+
|
+---------------------------------------|----------------------------------------+
| KWin desktop-session layer |
| KWin, kdecoration, seat and session wiring |
+---------------------------------------^----------------------------------------+
|
+---------------------------------------|----------------------------------------+
| Qt6 and KDE frameworks |
| Qt6 Widgets, QtWayland, QtDBus, QML, KF6, KDE support libs |
+---------------------------------------^----------------------------------------+
|
+---------------------------------------|----------------------------------------+
| Wayland compositor and protocols |
| smallvil first, then KWin, plus libwayland |
+---------------------------------------^----------------------------------------+
|
+---------------------------------------|----------------------------------------+
| Mesa, GBM, EGL, GLES2, libdrm |
| software path first, hardware path after DMA-BUF |
+---------------------------------------^----------------------------------------+
|
+---------------------------------------|----------------------------------------+
| DRM, KMS, firmware, input, device enumeration |
| redox-drm, amdgpu, Intel path, evdevd, udev-shim |
+---------------------------------------^----------------------------------------+
|
+---------------------------------------|----------------------------------------+
| Kernel and libc substrate for desktop bring-up |
| relibc, fd passing, DMA-BUF, IRQ, PCI, schemes |
+---------------------------------------^----------------------------------------+
|
+---------------------------------------|----------------------------------------+
| Hardware and boot substrate |
| AMD64 boot, ACPI, SMP, x2APIC, AMD and Intel GPUs |
+--------------------------------------------------------------------------------+
```
### Reading the dependency stack correctly
This stack has two kinds of blockers.
#### runtime substrate blockers
These sit low in the stack and poison all higher work if they are not validated:
- relibc runtime correctness
- input event correctness
- udev-like device enumeration correctness
- firmware loading correctness
- basic DRM and KMS correctness
- kernel DMA-BUF support for the accelerated path
#### session-assembly blockers
These sit higher and matter after the lower layers are trusted:
- smallvil completion
- Qt6 client display on Wayland
- KWin dependency cleanup
- KWin runtime session wiring
- Plasma shell and workspace integration
The plan must handle these in order. Otherwise failures in KWin or Plasma will really be lower-layer
failures in disguise.
### Layer-by-layer status
#### Layer 0, hardware and boot
Status: **partly runtime-proven**
What is true now:
- AMD bare-metal boot works for the current bounded claim
- ACPI, SMP, and x2APIC work
- AMD and Intel are equal-priority GPU targets
What still needs proof:
- real desktop-path validation on AMD GPUs
- real desktop-path validation on Intel GPUs
#### Layer 1, kernel and libc substrate
Status: **strong build-side, runtime incomplete**
What is true now:
- relibc exposes the build-visible Wayland and Qt unblockers
- redox-driver-sys and linux-kpi exist as the current driver substrate
What still needs proof:
- relibc behavior under real Wayland and Qt event-loop pressure
- kernel DMA-BUF fd passing for the hardware path
#### Layer 2, DRM, firmware, input, enumeration
Status: **build-visible and boot-visible, not runtime-trusted**
What is true now:
- redox-drm builds with AMD and Intel drivers
- amdgpu builds
- firmware-loader, evdevd, and udev-shim register at boot
What still needs proof:
- actual firmware loading by a real consumer
- actual input flow from Redox input sources into compositor-visible event devices
- actual scheme:drm registration and basic KMS query behavior in runtime
- actual AMD and Intel hardware-driver behavior on target machines
#### Layer 3, graphics userland interface
Status: **software path builds, hardware path blocked**
What is true now:
- Mesa EGL, GBM, and GLES2 build
- libdrm and libdrm_amdgpu build
- Qt6 OpenGL and EGL build
- QEMU proof still uses llvmpipe
What still needs proof:
- hardware renderer path through real DRM and real GPU drivers
- GBM allocation on the hardware path
- EGL and GLES stability on the hardware path
#### Layer 4, Wayland protocol and compositor
Status: **partial runtime proof, not complete**
What is true now:
- libwayland and wayland-protocols build
- smallvil is the bounded first runtime target
- smallvil reaches early initialization in QEMU
What still needs proof:
- a complete compositor session
- input routed into the compositor
- Qt6 client display in that compositor
#### Layer 5, Qt6 and KF6
Status: **major build milestone complete, runtime still thin**
What is true now:
- Qt6 builds across core, widgets, DBus, Wayland, OpenGL, and EGL
- qtdeclarative and qtwayland build
- all 32 KF6 frameworks build
What still needs proof:
- real Qt6 Wayland client behavior on Redox
- behavior of QML-heavy pieces under the no-JIT path
- broader networking semantics needed before QtNetwork can be enabled
#### Layer 6, KWin session shell
Status: **experimental and blocked**
What is true now:
- recipes exist
- `redbear-kde` exists
- several KWin-adjacent packages already build
What still needs proof:
- replacement of shimmed and stubbed blockers with real enough dependencies
- KWin compile success against honest dependencies
- KWin runtime as the compositor
#### Layer 7, KDE Plasma session
Status: **not yet proven**
What is true now:
- Plasma recipe surfaces exist
- the stack is far enough along that this is now a session-assembly problem, not a package-startup problem
What still needs proof:
- plasma-workspace integration
- plasma-desktop integration
- panel, launcher, file manager, settings, and session service behavior
### Dependency-stack conclusion
The shortest honest path is not "port more packages". The shortest honest path is "validate the
substrate, finish one software compositor path, finish one KWin session path, finish one Plasma
session path, then land the real hardware renderer path in parallel".
## Phased Work Plan
This plan uses fresh Phase 1 through Phase 5 numbering and does not reuse the old P0 through P6
scheme.
### Phase 1: Runtime Substrate Validation
**Duration:** 4 to 6 weeks
**Goal:** turn the lowest desktop-facing layers from build-visible into runtime-trusted.
This phase matters more than any other because it removes ambiguity from the entire stack. Without
it, later compositor or KDE failures will be impossible to classify correctly.
#### Core work
1. Validate relibc POSIX APIs against real consumers, especially libwayland and Qt6 runtime paths.
2. Validate the evdevd path from Redox input schemes through to `/dev/input/eventX` behavior.
3. Validate udev-shim device enumeration semantics for the current compositor and input stack.
4. Validate firmware-loader and `scheme:firmware` with real firmware blobs and a real consumer path.
5. Validate `scheme:drm/card0` registration and bounded KMS queries in QEMU.
6. Produce a repeatable runtime-service health check for the `redbear-wayland` slice.
#### Why this phase exists
The repo already compiles the lower desktop stack. What it lacks is evidence that the lower stack
behaves correctly under real use. Phase 1 is where builds become runtime-trusted enough to support
the first serious compositor pass.
#### Deliverables
##### relibc runtime validation set
Validate the relibc surfaces already present in-tree:
- signalfd
- timerfd
- eventfd
- open_memstream
- F_DUPFD_CLOEXEC
- MSG_NOSIGNAL
- bounded waitid
- bounded shared-memory and semaphore paths used by Qt6
The standard here is not just "the symbol exists". The standard is that real consumers can use the
API without hidden workarounds, hangs, or broken semantics.
##### evdev input validation set
Validate the current input chain end to end:
- input source emits events
- evdevd exposes expected event devices
- keyboard events arrive with correct semantics
- mouse events arrive with correct semantics
##### udev-shim validation set
Validate that current consumers can discover and classify the devices they need. Full Linux parity
is not required. Sufficient enumeration for the current desktop path is required.
##### firmware-loader validation set
Validate firmware loading with real blobs and a real consumer path. Scheme registration alone is not
enough. The blob must be requestable, discoverable, loadable, and consumable at runtime.
##### redox-drm runtime-surface validation set
Validate bounded runtime behavior first in QEMU:
- scheme registration for `scheme:drm/card0`
- basic KMS queries
- no startup-class failures in the redox-drm path
#### Acceptance criteria
Phase 1 is complete when all of the following are true:
- `redbear-wayland` boots in the bounded validation environment
- Phase 1 runtime services register without startup errors
- relibc runtime checks pass for the selected desktop-facing consumers
- the input path reaches evdevd and yields expected event nodes and bounded test events
- udev-shim exposes the expected bounded device view
- firmware-loader successfully serves at least one real consumer path with real blobs
- `scheme:drm/card0` registers and answers bounded basic queries
#### Exit statement
At the end of Phase 1, the repo should be able to say: the desktop substrate is no longer only a
build artifact. It is runtime-trusted enough to support a compositor completion pass.
### Phase 2: Wayland Compositor Runtime Proof
**Duration:** 4 to 6 weeks
**Goal:** produce the first working Wayland compositor session using software rendering.
This phase stays intentionally narrow. The first complete compositor proof should happen in the
smallest runtime target available, which is still smallvil.
#### Core work
1. Complete the current smallvil runtime path.
2. Wire evdevd input into the compositor.
3. Wire Mesa software rendering through GBM and EGL.
4. Get a Qt6 widget application to display through the compositor.
#### Why smallvil remains the right target
Jumping straight to KWin would combine too many unknowns: compositor runtime, input, QML, session
services, dependency scaffolding, and desktop-shell behavior. smallvil is smaller, easier to debug,
and already present. It is the right place to finish the first software compositor proof.
#### Deliverables
##### complete smallvil runtime path
The current proof stops during early initialization. This phase completes the path into a usable
session.
##### input wired into compositor
Keyboard and mouse must work through the current Redox input stack, not through an artificial bypass.
##### software rendering path confirmed
The proven renderer for this phase is LLVMpipe through Mesa, GBM, and EGL. That is acceptable. The
goal is correctness of compositor and client behavior, not hardware acceleration yet.
##### Qt6 smoke client on Wayland
The first meaningful desktop-facing end-to-end proof is a real Qt6 Wayland client window appearing
inside the compositor.
#### Acceptance criteria
Phase 2 is complete when all of the following are true:
- smallvil launches into a working session in QEMU
- keyboard and mouse work through the current input stack
- Mesa software rendering works through GBM and EGL
- `qt6-wayland-smoke` shows a window inside the compositor in QEMU
#### Exit statement
At the end of Phase 2, the repo should be able to say: Red Bear OS has a working software-rendered
Wayland compositor path with a visible Qt6 client.
### Phase 3: Hardware GPU Enablement
**Duration:** 12 to 20 weeks
**Goal:** replace the software-only graphics proof with real hardware-accelerated display output and
rendering.
This is the highest-uncertainty phase. It includes new kernel work, real hardware-driver proof, and
the first true Mesa hardware path on Redox.
#### Core work
1. Add kernel DMA-BUF fd passing.
2. Validate redox-drm AMD and Intel drivers on real hardware.
3. Validate Mesa hardware rendering path, including real renderer identity.
4. Validate GBM buffer allocation through the hardware path.
#### Why this phase is separate
The software compositor path is the fastest honest route to proving compositor and client behavior.
The hardware path is a different class of systems work. It should run in parallel with later KWin
and Plasma assembly instead of blocking everything else.
#### Deliverables
##### kernel DMA-BUF fd passing
This is the gating feature for the accelerated desktop path. Without it, hardware-accelerated KDE
is not a credible target.
##### real AMD hardware validation
Validate on representative AMD hardware:
- device detection
- MMIO mapping
- firmware loading
- connector detection
- mode enumeration
- bounded modeset proof
##### real Intel hardware validation
Validate on representative Intel hardware:
- device detection
- MMIO mapping
- connector detection
- mode enumeration
- bounded modeset proof
##### Mesa hardware rendering proof
Validate the actual hardware renderer path rather than llvmpipe fallback. For AMD the target is the
radeonsi path. For Intel the target is the intended real Intel hardware path available in the stack.
#### Acceptance criteria
Phase 3 is complete when all of the following are true:
- kernel DMA-BUF fd passing exists and has focused proof coverage
- `modetest -M amd` shows display modes on real AMD hardware
- the equivalent Intel DRM query path shows display modes on real Intel hardware
- the compositor runs through the hardware path rather than llvmpipe on at least one real AMD class
and one real Intel class
- runtime evidence shows a hardware-backed renderer rather than software fallback
#### Exit statement
At the end of Phase 3, the repo should be able to say: Red Bear OS can drive real display hardware
and run the compositor on a hardware-accelerated path.
### Phase 4: Desktop Session Assembly
**Duration:** 6 to 10 weeks
**Goal:** turn the compositor proof into a real desktop-session substrate centered on KWin.
This phase starts after Phase 2. It does not need to wait for the full hardware path. KWin can come
up first on the software renderer and later inherit the accelerated renderer once Phase 3 lands.
#### Core work
1. Resolve KWin shimmed and stubbed blockers.
2. Get KWin to compile with real enough dependencies.
3. Launch KWin as the Wayland compositor.
4. Validate libinput backend behavior.
5. Validate D-Bus session behavior.
6. Validate seatd for the bounded KWin session model.
#### blocked dependency set that must be closed
- kirigami stub-only state
- heavy kio shim state where it blocks honest session claims
- libepoxy
- libudev
- lcms2
- libdisplay-info
#### Deliverables
##### honest KWin build
The milestone is not just that a recipe exists. The milestone is that KWin builds without fake
dependency satisfaction for core runtime behavior.
##### KWin runtime as compositor
KWin must launch as the compositor and own the display path.
##### session services for bounded desktop use
D-Bus session behavior and seatd behavior must be good enough for the bounded KWin target this plan
claims. Linux parity is not required. Correct bounded behavior is required.
#### Acceptance criteria
Phase 4 is complete when all of the following are true:
- KWin builds against real enough dependencies to support honest runtime claims
- KWin launches as the compositor
- KWin takes over display output in the bounded session path
- keyboard and mouse work through the KWin session path
- required D-Bus session behavior for the bounded KWin path works
- seatd behavior is validated for the bounded KWin session model
#### Exit statement
At the end of Phase 4, the repo should be able to say: Red Bear OS has a working Wayland desktop
session substrate centered on KWin.
### Phase 5: KDE Plasma Session
**Duration:** 8 to 12 weeks
**Goal:** boot into a KDE Plasma session with the essential desktop shell and session services
working.
This is the final desktop product phase. By this point the remaining work should mostly be session
assembly, application integration, and shell behavior.
#### Core work
1. Complete plasma-workspace compilation and integration.
2. Complete plasma-desktop compilation and integration.
3. Get the shell, panel, and launcher visible and usable.
4. Get settings and file-manager paths working.
5. Provide bounded network and audio integration suitable for the session claim.
#### Deliverables
##### Plasma shell
The minimum target is not a screenshot. The session must show the shell, panel, and launcher and be
stable through basic interaction.
##### application and settings path
At least one real file-manager path and one settings path must work. Otherwise the session is still
too incomplete to count as a desktop.
##### bounded desktop-service integration
For this phase the question is narrow: can the Plasma session boot into a usable desktop with bounded
network and audio integration. The long-term subsystem plans remain separate.
#### Acceptance criteria
Phase 5 is complete when all of the following are true:
- `redbear-kde` boots into a KDE Plasma session
- KWin is the active compositor
- the Plasma shell, panel, and launcher appear
- an application can be launched from the session
- a file-manager path works through the current kio integration
- a settings path works
- bounded network and audio integration exist for the claimed session profile
#### Exit statement
At the end of Phase 5, the repo should be able to say one of two things:
- if Phase 3 is still incomplete: Red Bear OS has a software-rendered KDE Plasma session on Wayland
- if Phase 3 is complete: Red Bear OS has a hardware-accelerated KDE Plasma session on Wayland
## Critical Path
### primary path to a software-rendered KDE session
```text
Phase 1, runtime substrate validation
-> Phase 2, software Wayland compositor proof
-> Phase 4, KWin desktop-session assembly
-> Phase 5, KDE Plasma session
```
This is the shortest honest path to a KDE desktop claim.
### parallel hardware path
```text
Phase 1, runtime substrate validation
-> Phase 3, hardware GPU enablement
Phase 3 proceeds in parallel with Phase 4 where possible
Phase 3 + Phase 4 + Phase 5
-> hardware-accelerated KDE Plasma desktop
```
### why Phase 1 is the real gate
Phase 1 is the true gateway because it converts lower-layer package progress into runtime trust.
Without it, Phase 2, Phase 4, and Phase 5 failures will be misdiagnosed.
### why Phase 2 comes before KWin
The first complete compositor proof should happen in the smallest environment. smallvil is smaller,
already present, and easier to debug than KWin. It isolates compositor, input, and Qt client issues
before session-shell complexity is added.
### why Phase 3 should not block Phase 4
Hardware acceleration is critical, but KWin and Plasma also have their own blockers: dependency
cleanup, session services, and compositor integration. Those can be solved on the software renderer
while the hardware path matures.
### critical-path summary
The execution order this repo should present is:
1. validate the runtime substrate
2. prove one software compositor path
3. assemble one KWin session path
4. assemble one Plasma session path
5. land hardware acceleration in parallel
## Risk Register
| ID | Risk | Likelihood | Impact | Why it matters | Mitigation |
|---|---|---|---|---|---|
| R1 | relibc runtime gaps are worse than build evidence suggests | Medium | High | Qt6 and Wayland may still fail at runtime even though they build | validate with real consumers in Phase 1 |
| R2 | kernel DMA-BUF fd passing is a new feature with uncertain scope | High | High | hardware acceleration depends on it | isolate design and proof early in Phase 3 |
| R3 | AMD or Intel real-hardware validation reveals fundamental driver issues | High | High | compile success may not survive real modesetting or rendering | validate AMD and Intel separately on representative hardware |
| R4 | KWin porting needs significantly more patches than estimated | Medium | High | KWin sits on the desktop critical path | finish smallvil proof first, then attack KWin with cleaner lower-layer evidence |
| R5 | Kirigami and other QML-heavy pieces do not behave acceptably with QML JIT disabled | Medium | Medium to High | Plasma shell may build but behave badly | keep QML-heavy runtime proof explicit in Phase 4 and Phase 5 |
| R6 | Mesa hardware rendering needs Redox-specific winsys work beyond current estimates | Medium | High | hardware acceleration may stall after modesetting starts working | separate display proof from renderer proof |
| R7 | linux-kpi compatibility gaps only appear during real-hardware execution | High | Medium to High | compile-only success can hide runtime failures | budget for hardware-driven compatibility fixes in Phase 3 |
## Timeline
### planning assumptions
These estimates assume 2 developers, usable access to representative AMD and Intel hardware, and no
major regression from unrelated upstream refresh during the desktop push. They do not assume perfect
first-pass success on real hardware.
### phase estimates with 2 developers
| Phase | Estimate | Notes |
|---|---|---|
| Phase 1, Runtime Substrate Validation | 4 to 6 weeks | must finish honestly before claiming runtime trust |
| Phase 2, Wayland Compositor Runtime Proof | 4 to 6 weeks | can overlap with late Phase 1 cleanup |
| Phase 3, Hardware GPU Enablement | 12 to 20 weeks | parallel track after Phase 1 |
| Phase 4, Desktop Session Assembly | 6 to 10 weeks | starts after Phase 2 |
| Phase 5, KDE Plasma Session | 8 to 12 weeks | starts after Phase 4 |
### total duration with 2 developers
#### to software-rendered KDE Plasma on Wayland
- **22 to 34 weeks**
- roughly **6 to 8 months**
This path is Phase 1 + Phase 2 + Phase 4 + Phase 5.
#### to hardware-accelerated KDE Plasma on Wayland
- **34 to 54 weeks**
- roughly **8 to 13 months**
This path is Phase 1 + Phase 2 + Phase 3 in parallel + Phase 4 + Phase 5.
### rough overlap model
```text
Weeks 1 to 6
Phase 1, runtime substrate validation
Weeks 4 to 12
Phase 2, software compositor proof
Weeks 7 to 26
Phase 3, hardware GPU enablement
Weeks 13 to 22
Phase 4, KWin session assembly
Weeks 23 to 34
Phase 5, KDE Plasma session
```
This is an intended overlap shape, not a guaranteed calendar.
### one-developer estimate
With 1 developer, the overall timeline is roughly 1.5x to 2x the two-developer estimates.
Practical meaning:
- software-rendered KDE path: about 9 to 16 months
- hardware-accelerated KDE path: about 12 to 27 months
The wider range reflects the loss of useful parallelism between hardware work and session work.
### timeline conclusion
The software-rendered KDE target is no longer a greenfield multi-year fantasy. The hardware-
accelerated KDE target is still a serious systems milestone because Phase 3 carries the widest
uncertainty band.
## Relationship to Other Plans
This is the canonical document for the desktop path from console boot to KDE Plasma on Wayland. It
does not replace every subsystem-specific plan. It sets the ordering, scope, and acceptance language
for the desktop path while deeper subsystem documents retain their detailed ownership.
### primary supporting plans
- `local/docs/RELIBC-COMPLETENESS-AND-ENHANCEMENT-PLAN.md` for relibc completeness detail,
ownership of patch-carried behavior, and deeper evidence tracking
- `local/docs/AMD-FIRST-INTEGRATION.md` for deeper GPU-driver and firmware detail, with the caveat
that this desktop plan uses equal-priority AMD and Intel targeting
- `local/docs/QT6-PORT-STATUS.md` for Qt6, KF6, KWin blocker, shim, and stub status
- `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` for the short current-state desktop truth summary
- `local/docs/IRQ-AND-LOWLEVEL-CONTROLLERS-ENHANCEMENT-PLAN.md` for controller, IRQ, MSI, MSI-X,
and IOMMU quality work that supports later hardware desktop validation
- `local/docs/INPUT-SCHEME-ENHANCEMENT.md` for deeper input-path design if the current chain needs
structural cleanup beyond Phase 1 validation
- `local/docs/P2-AMD-GPU-DISPLAY.md` for the code-complete AMD display status and concrete AMD
validation targets such as `modetest -M amd`
### how to use this plan with the supporting plans
Read this document first for execution order, current claim language, completion criteria, and the
critical path. Read the subsystem plans for the exact relibc, driver, package, or input details
behind those higher-level phases.
Reference in New Issue View Git Blame Copy Permalink