# Red Bear OS Desktop Stack — Current Status

## Purpose

This document is the **current build/runtime truth summary** for the Red Bear desktop stack.

It is intentionally narrower than the historical Wayland and KDE roadmap docs. Its job is to answer:

- what the current desktop stack actually builds,
- what the tracked desktop profiles currently expose,
- what is only build-visible,
- what is runtime-proven,
- and what still blocks a trustworthy Wayland/KDE session claim.

Use this document as the current-state summary. Use `docs/03-WAYLAND-ON-REDOX.md` and
`docs/05-KDE-PLASMA-ON-REDOX.md` mainly as design history, rationale, and deeper porting notes.

## Current State Summary

The Red Bear desktop stack is no longer blocked on basic Qt/Wayland package availability.

The repo currently proves:

- `libwayland` builds successfully against the current relibc/Red Bear compatibility surface
- Qt6 core modules build (`qtbase`, `qtdeclarative`, `qtsvg`, `qtwayland`)
- the current relibc overlay and its fresh-source reapply workflow are strong enough to support the
  rebuilt Qt/Wayland stack
- D-Bus builds and is wired into desktop-facing profiles
- `seatd` builds and is wired into the KDE-facing runtime profile
- the `redbear-wayland`, `redbear-full`, and `redbear-kde` profiles exist as real tracked product
  surfaces

The repo does **not** yet prove a generally trustworthy desktop runtime.

The main gap is no longer “can we build the packages?” The main gap is “which parts of the desktop
stack are runtime-trusted rather than just build-visible?”

## Status Matrix

| Area | Current state | What that means |
|---|---|---|
| `libwayland` | **builds** | relibc/Wayland-facing compatibility is materially better than before |
| Qt6 core stack | **builds** | `qtbase`, `qtdeclarative`, `qtsvg`, `qtwayland` are in-tree build surfaces |
| KF6 frameworks | **mixed but strong build progress** | many frameworks build; some higher-level pieces still rely on bounded or reduced recipes |
| KWin / Plasma session | **experimental / incomplete runtime** | recipe/config wiring exists, but runtime trust still trails build success |
| Mesa / hardware graphics path | **partial** | software path exists; current QEMU validation still shows llvmpipe, and hardware-validated Wayland graphics path still lags |
| Input stack | **build-visible and partly wired** | `evdevd`, `libevdev`, `libinput`, `seatd` are present, but runtime trust is still narrower than full desktop support |
| D-Bus session/system plumbing | **builds / wired into profiles** | present in desktop-facing profiles, but not equal to full desktop integration completeness |

## Profile View

### `redbear-wayland`

Role:

- narrow runtime validation profile for Wayland bring-up

Current truth:

- it is the current first-class profile for a bounded Wayland runtime path
- it should be used for small-scope compositor/runtime validation, not broad desktop claims

### `redbear-full`

Role:

- broader desktop/network/session plumbing profile

Current truth:

- it carries D-Bus and broader desktop integration pieces
- it is stronger than `redbear-wayland` for general integration, but still not the same as a stable
  KDE session claim

### `redbear-kde`

Role:

- KDE/Plasma session-surface profile

Current truth:

- it carries the KWin/session wiring and the KDE-facing package set
- it should still be described as experimental until runtime evidence catches up with build success

## Current Blockers

### 1. Runtime trust still trails build success

The project now has real build-visible desktop progress, but build success still exceeds runtime
confidence.

That gap is the main thing older docs sometimes blur.

### 2. Graphics/runtime validation is still thinner than package progress

The software-rendered stack is much further along than the hardware-validated stack.

Current QEMU truth:

- the tracked `redbear-wayland` test harness still uses `-vga std`
- the live compositor path currently reports `GL Renderer: "llvmpipe (LLVM 21.1.2, 256 bits)"`
- therefore the current QEMU Wayland proof is still a software-rendered runtime slice, not a
  hardware-accelerated desktop proof
- QEMU should be treated as a bounded regression/test harness for Wayland/Qt bring-up, not as the
  primary proof target for the final hardware-accelerated desktop claim

The real hardware-accelerated acceptance target remains the bare-metal/runtime-driver path:

- `redox-drm` detects and drives the target GPU family
- Mesa GBM/EGL/GLES2 uses that runtime graphics path
- the compositor and Qt Wayland clients run stably on top of it
- runtime evidence shows the desktop path is using the real accelerated stack rather than a
  software fallback

The desktop stack therefore should not over-claim hardware-ready Wayland/KDE support yet.

### 3. KDE build progress is ahead of session maturity

KDE package and framework progress is real, but the session surface should still be described as an
experimental bring-up target rather than a broadly working desktop.

### 4. Input and seat management are present but not yet a final confidence story

`libinput`, `seatd`, and related runtime pieces matter, but they should still be treated as part of
the runtime-proof gap rather than as already-settled desktop infrastructure.

## Canonical Document Roles

Use the desktop-related docs this way:

- `local/docs/DESKTOP-STACK-CURRENT-STATUS.md` — current build/runtime truth summary
- `local/docs/QT6-PORT-STATUS.md` — Qt/KF6 package-level build/status truth
- `docs/03-WAYLAND-ON-REDOX.md` — historical Wayland implementation path + deeper rationale
- `docs/05-KDE-PLASMA-ON-REDOX.md` — historical KDE implementation path + deeper rationale
- `local/docs/PROFILE-MATRIX.md` — profile role and support-language reference

## Bottom Line

The current Red Bear desktop stack is in a transition phase:

- no longer blocked on basic Qt/Wayland package availability,
- materially stronger on relibc/Wayland-facing compatibility than before,
- but still short of a broad runtime-trusted desktop claim.

That is the current truth this repo should present.