vasilito
4ec01243a0
This is a full v6.0 rewrite of the desktop plan, produced after:
1. Booting CachyOS desktop ISO (cachyos-desktop-260426.iso, 2.9GB) in QEMU
11.0.0 to establish the reference baseline.
2. Six parallel research agents that audited the full Red Bear stack
against the CachyOS reference and Linux 7.1 kernel source.
3. Resolution of two architectural questions that v5.x punted on.
Two non-negotiable architecture decisions (v6.0):
A. UNIFIED INPUT ARCHITECTURE: every input driver writes to BOTH
/scheme/input/orbclient (for Orbital) and /scheme/input/evdev (for
KWin + libinput). No more inputd <-> evdevd bridge that loses
metadata (timestamps, axis ranges, vendor IDs, SYN_REPORT).
Matches CachyOS/Linux: one kernel-evdev path, all consumers
read from it.
B. KWIN IS THE PRIMARY COMPOSITOR: redbear-compositor (788-line
Rust) is too small to reach production parity with KWin in any
realistic timeframe. KWin is used for the user session;
redbear-compositor hosts only the greeter (minimal xdg-shell +
wl_keyboard events are still needed for the greeter to function).
Critical path rework (v6.0):
- Phase 0: QML JIT gate (4-6 weeks) — moves to pre-flight because
it blocks 12 KF6 packages and KWin. Without QML, no Plasma.
- Phase 1: Unified input (1-2 weeks) — resolves the inputd/evdevd
proliferation.
- Phase 2: DRM atomic modeset + render node + PRIME real FDs +
RESOURCE_MAP_BLOB (2-3 weeks).
- Phase 3: Mesa EGL Wayland fix (1 week).
- Phase 4: Compositor greeter — redbear-compositor adds
xdg-shell + wl_keyboard events (2-3 weeks).
- Phase 5: KWin real build (2-4 weeks).
- Phase 6: PipeWire + wireplumber + audiod bridge (6-8 weeks).
- Phase 7: Plasma shell (4-6 weeks).
- Phase 8: QEMU E2E validation (1-2 weeks).
- Phase 9: Intel ARC track (parallel) (12-20 weeks).
Coverage inventory (v6.0):
237 components audited across 14 categories.
86 real (36%), 41 partial (17%), 110 missing (46%).
Detailed gap matrix in §8.
Intel ARC support:
Added as Phase 9 parallel track — requires Mesa iris + Xe driver
cross-compile + real hardware validation.
Total: 22-32 weeks to functional software-rendered KDE Plasma
Wayland desktop on QEMU. +4-8 weeks for Mesa virgl. +12-20 weeks
for real Intel ARC hardware.
This supersedes v5.0 and v5.1 in full. The v5.x changelog sections
(§9, §9.1, §9.1.1) are retained as historical record.
Red Bear OS
A microkernel operating system written in Rust, derived from Redox OS
What is Red Bear OS?
Red Bear OS is a general-purpose, Unix-like operating system with a microkernel architecture, written in Rust. It is a full fork of Redox OS, frozen at release 0.1.0, with added hardware support, filesystem drivers, and a KDE Plasma desktop path.
Goals:
- AMD & Intel parity — first-class support for both platforms on bare metal
- KDE Plasma desktop — Wayland-based desktop environment via the KWin compositor
- Hardware GPU acceleration — AMD GPU (amdgpu) and Intel GPU drivers via
redox-drm - Modern subsystems — USB, Wi‑Fi, Bluetooth, ext4, GRUB, D-Bus
- Offline-first builds — reproducible from archived, BLAKE3-verified sources
Quick Start
Prerequisites
Linux x86_64 host with Rust nightly, QEMU, nasm, and standard build tools.
See the Redox Build Guide for full setup.
Build & Run
# Clone
git clone https://gitea.redbearos.org/vasilito/RedBear-OS.git
cd RedBear-OS
# Build and run the desktop target in QEMU
./scripts/run.sh --build
# Build a live ISO for bare metal
./scripts/build-iso.sh redbear-full
# Build the text-only recovery target
./scripts/run.sh --build --config redbear-mini
Repository Hosting
The canonical Red Bear OS Git server is Gitea at
https://gitea.redbearos.org/vasilito/RedBear-OS.git. GitHub is not a Red Bear OS source of
truth and must not be used for pushes, issues, releases, or project coordination.
Public Scripts
| Script | Purpose |
|---|---|
scripts/run.sh |
Build and run in QEMU (-b to build, -c <config> for target) |
scripts/build-iso.sh |
Build a live ISO for bare-metal boot |
scripts/build-all-isos.sh |
Build all live ISO targets |
scripts/network-boot.sh |
PXE network boot helper |
scripts/dual-boot.sh |
Dual-boot installation helper |
Config Targets
| Target | Type | Description |
|---|---|---|
redbear-full |
Desktop | Wayland + KDE + GPU drivers + D-Bus services |
redbear-mini |
Console | Text-only recovery / install target |
redbear-grub |
Console | Text-only with GRUB boot manager |
Current Status
Red Bear OS boots to a login prompt in QEMU with working wired networking, D-Bus system bus, hardware detection daemons, and filesystem support (RedoxFS, ext4, FAT).
| Area | Status |
|---|---|
| Boot (ACPI/x2APIC/SMP) | ✅ Bare-metal proven |
| Userspace drivers (PCI, storage, net) | ✅ Working in QEMU |
| D-Bus system bus + services | ✅ Working (login1, PolicyKit, UDisks, UPower) |
| ext4 / FAT filesystems | ✅ Compiles, installer-wired |
| POSIX gaps (relibc) | 🚧 Bounded Wayland-facing support |
| DRM/KMS display drivers | 🚧 AMD + Intel compile; HW validation pending |
| Wayland compositor | 🚧 Bounded proof; Qt6/KF6 clients crash at init |
| KDE Plasma desktop | 🔄 In progress (Qt6/KF6 compile; KWin/QML blocked) |
| Wi‑Fi / Bluetooth | 📋 Planned (architected, implementation pending) |
How It Works
Red Bear OS uses a userspace driver model — all drivers run as unprivileged daemons:
Kernel (microkernel)
└── schemes: memory, irq, event, pipe, debug
└── Driver daemons (userspace)
├── pcid → PCI enumeration
├── e1000d → Intel ethernet
├── xhcid → USB controller
└── vesad → Display framebuffer
The kernel provides minimal services (memory, interrupts, IPC). Everything else — filesystems, networking, graphics, input — runs in userspace.
Documentation
- Implementation Plan — roadmap and execution model
- Desktop Path Plan — kernel → DRM → Mesa → Wayland → KDE
- D-Bus Integration — session bus architecture
- USB Plan — USB stack design
- Wi‑Fi Plan — wireless architecture
- Bluetooth Plan — BT stack design
- Documentation Index — full doc map
Contributing
Red Bear OS uses a full fork model. Upstream Redox sources are frozen and archived. All custom work lives in local/:
local/
├── sources/ # Red Bear source forks (git repos, directly editable)
├── recipes/ # Custom packages (drivers, GPU, system)
├── docs/ # Integration and planning docs
└── scripts/ # Build, test, and release tooling
We welcome contributions made with or without AI assistance — we care about quality, not how the code was produced.
License
MIT — same as upstream Redox OS.