Files

T

vasilito fd60edc823 Refresh status docs and add a visible changelog

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-openagent)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>

2026-04-14 10:50:04 +01:00

44 KiB

Raw Blame History

Red Bear OS Integration Report: Wayland, KDE Plasma, and Linux Driver Support

Date: April 11, 2026 Project: Red Bear OS Build System (based on Redox OS) Status: Assessment Complete

Status correction (2026-04-14): This report is a historical assessment snapshot and is no longer an accurate statement of current repository status. The repo now contains substantial work that this report still describes as missing, including redox-driver-sys, linux-kpi, firmware-loader, redox-drm, the AMD display path, the Qt6 stack, config/redbear-kde.toml, and a large local/recipes/kde/ tree.

Current Snapshot

Area	Current repo state
ACPI / bare-metal	Complete in-tree
Driver infrastructure	Present and compiling in `local/recipes/drivers/`
DRM / display	Present and compiling in `local/recipes/gpu/`; hardware validation still pending
POSIX/input	Implemented in-tree with remaining validation work
Wayland	Partial runtime path
KDE	In progress with a mix of true builds and scaffolding

Read this file as historical context, not as the canonical current-state document.

Executive Summary

Red Bear OS is based on Redox OS, a microkernel-based operating system written in Rust with comprehensive documentation on integrating Wayland, KDE Plasma, and Linux drivers. The project has:

Active development: 21+ Wayland recipes, 19+ KDE WIP recipes
Build system: Fully functional, using Rust-based repo tool and Makefiles
Documentation: Extensive, detailed implementation paths already documented
Blockers identified: 7 POSIX gaps in relibc, no GPU acceleration, missing DRM/KMS scheme
Estimated timelines: 6-10 months to KDE Plasma, 6-8 months to Linux drivers

1. Compilation Status

Build System Analysis

Build System: Rust-based repo tool with Makefile orchestration

Key Directories:

config/ - Build configurations (minimal, desktop, wayland, x11)
recipes/ - Package recipes (9.6GB total, 60+ redox.patch files)
mk/ - Makefile infrastructure (config.mk, depends.mk, podman.mk, etc.)
src/ - Build system source (cookbook tool in Rust)
build/ - Output directory (build/{ARCH}/{CONFIG}/)

Available Configs:

minimal - Bare minimum bootable system
server - Server-oriented (no GUI)
desktop-minimal - Orbital + basic GUI
desktop - COSMIC apps + installer
wayland - Wayland compositor (experimental)
x11 - X.org + MATE desktop
demo - Demo apps

Build Test Results

Prerequisites Status:

✅ Rust toolchain installed (via rustup)
✅ Cargo available
✅ Make installed
✅ QEMU available
✅ Prebuilt toolchain exists: prefix/x86_64-unknown-redox/
✅ Build system binary compiled: target/release/repo

Build Attempt Results:

Kernel Source Fetch: ✅ SUCCESS
- Cloned 21452 objects from gitlab.redox-os.org
- Source located at: recipes/core/kernel/source/

Build Attempt: ⚠️ PARTIAL
- FUSE filesystem issue encountered (ioctl error 25)
- Kernel source successfully downloaded
- Build system infrastructure validated

Issue Identified: FUSE mount-related error during build, likely due to stale mounts or filesystem permissions. This is a build environment issue, not a project issue. The build system itself is functional.

2. Wayland Integration: Concrete Path

Current State (Experimental/WIP)

Existing Components:

config/wayland.toml - Wayland configuration (21 packages)
recipes/wip/wayland/ - 21 Wayland packages:
- libwayland (1.24.0) - Patched with redox.patch
- cosmic-comp - Partial working, no keyboard input
- smallvil (Smithay) - Basic compositor running
- wlroots - Not compiled/tested
- sway - Not compiled/tested
- hyprland - Not compiled/tested
- niri - Needs Smithay port
- xwayland - Partially patched
- Wayland protocols, xkbcommon, etc.

Blockers Identified (from docs/03-WAYLAND-ON-REDOX.md):

2.1 POSIX Gaps in relibc (CRITICAL BLOCKER)

7 Missing APIs (all stubbed in libwayland/redox.patch):

API	Used By	Effort	File Location
`signalfd`/`signalfd4`	libwayland event loop	Medium	`relibc/src/header/signal/mod.rs`
`timerfd_create/settime/gettime`	libwayland timers	Medium	`relibc/src/header/sys_timerfd/` (NEW)
`eventfd`/`eventfd_read/write`	libwayland server	Low	`relibc/src/header/sys_eventfd/` (NEW)
`F_DUPFD_CLOEXEC`	libwayland fd management	Low	`relibc/src/header/fcntl/mod.rs`
`MSG_CMSG_CLOEXEC`	libwayland socket recv	Low	`relibc/src/header/sys_socket/mod.rs`
`MSG_NOSIGNAL`	libwayland connection	Low	`relibc/src/header/sys_socket/mod.rs`
`open_memstream`	libdrm, libwayland	Low	`relibc/src/header/stdio/src.rs`

Total Estimated Effort: ~870 lines of Rust code (1-2 weeks)

2.2 Missing Input Stack

Components Needed:

evdev daemon (evdevd) - Translate Redox input schemes to /dev/input/eventX
- Location: recipes/core/evdevd/ (NEW)
- Implementation: ~500 lines of Rust
- Effort: 4-6 weeks
udev shim - Device enumeration and hotplug
- Location: recipes/wip/wayland/udev-shim/ (NEW)
- Implementation: ~500 lines of Rust
- Effort: 2-3 weeks
libinput port - Input abstraction layer
- Location: recipes/wip/wayland/libinput/ (NEW)
- Effort: 3-4 weeks

Total Input Stack Effort: 9-13 weeks

2.3 Missing DRM/KMS Scheme

Components Needed:

DRM daemon (drmd) - Register scheme:drm/card0

Location: recipes/core/drmd/ (NEW)

Structure:

src/
  ├── main.rs              - daemon entry, scheme registration
  ├── scheme.rs            - "drm" scheme handler
  ├── kms/                 - KMS object management
  │   ├── crtc.rs
  │   ├── connector.rs
  │   ├── encoder.rs
  │   ├── plane.rs
  │   └── framebuffer.rs
  ├── gem.rs                - GEM buffer management
  ├── dmabuf.rs            - DMA-BUF export/import
  └── drivers/
      ├── mod.rs          - driver trait
      └── intel.rs        - Intel GPU driver (modesetting)

Effort: 8-12 weeks

Intel GPU driver (native Rust modesetting)
- Location: redox-drm/src/drivers/intel/
- Documentation: Intel GPU PRM
- Effort: 6-8 weeks (part of drmd)
Mesa hardware backend
- Location: Mesa winsys for Redox DRM (NEW)
- Effort: 4-6 weeks

Total DRM/KMS Effort: 12-16 weeks

2.4 Wayland Compositor Path

Recommended: Smithay/smallvil first, then KWin

Why Smithay First:

Pure Rust - no C++ toolchain issues
Already has Redox branch
Pluggable input/DRM/EGL backends
Gets working compositor months before KWin

Implementation Steps:

Phase 1: Smithay Redox Backends (4-6 weeks)

// smithay/src/backend/input/redox.rs (NEW)
pub struct RedoxInputBackend {
    devices: Vec<EvdevDevice>,
}

impl InputBackend for RedoxInputBackend {
    fn dispatch(&mut self) -> Vec<InputEvent> {
        // Read from /dev/input/eventX via evdevd
        // Translate to Smithay's InternalEvent
    }
}

// smithay/src/backend/drm/redox.rs (NEW)
pub struct RedoxDrmBackend {
    drm_fd: File,  // opened from /scheme/drm/card0
}

impl DrmBackend for RedoxDrmBackend {
    fn create_surface(&self, size: Size) -> Surface {
        // Create framebuffer via DRM GEM
        // Set KMS mode via scheme:drm
    }

    fn page_flip(&self, surface: &Surface) -> Result<VBlank> {
        // DRM page flip via scheme
    }
}

// smithay/src/backend/egl/redox.rs (NEW)
pub struct RedoxEglDisplay {
    // Mesa EGL display integration
}

Phase 2: smallvil Recipe (1-2 weeks)

Modify recipes/wip/wayland/smallvil/recipe.toml:

[source]
git = "https://github.com/jackpot51/smithay"
branch = "redox"

[build]
template = "cargo"
dependencies = [
    "libffi",
    "libwayland",
    "libxkbcommon",
    "mesa",        # for EGL
    "libdrm",      # for DRM backend
    "evdevd",      # for input
    "seatd",       # for session management
]
cargopackages = ["smallvil"]

Phase 3: Verification (1-2 weeks)

smallvil launches with DRM backend - takes over display
Keyboard and mouse work via evdevd
libcosmic-wayland_application renders a window on compositor
Screenshot shows window

Phase 4: Enable Other Compositors

cosmic-comp: Uncomment libinput dependency, rebuild
wlroots: Build with libdrm + libinput + GBM
sway: Should work once wlroots builds
KWin: See Section 3

2.5 Wayland Implementation Timeline

Phase	Duration	Milestone
POSIX gaps (relibc)	1-2 weeks	libwayland builds without patches
Input stack (evdevd + udev + libinput)	4-6 weeks	libinput works
DRM/KMS (drmd + Intel driver)	8-12 weeks	libdrm works, modesetting functional
Smithay backends + smallvil	4-6 weeks	Working Wayland compositor
Total to Wayland Compositor	~26 weeks (6 months)	Functional Wayland on Red Bear OS

Parallel Execution: Input stack (4-6 weeks) can run in parallel with DRM/KMS (8-12 weeks), reducing total to ~20-24 weeks (5-6 months) with 2 developers.

3. KDE Plasma Integration: Concrete Path

Prerequisites (MUST be complete first)

From docs/05-KDE-PLASMA-ON-REDOX.md:

✅ relibc POSIX gaps fixed (from Wayland Phase 1)
✅ evdevd + libinput working (from Wayland Phase 2)
✅ DRM/KMS scheme working (from Wayland Phase 3)
✅ Wayland compositor running (from Wayland Phase 4)
✅ Mesa EGL + software OpenGL (already ported)

Phase KDE-A: Qt Foundation (8-12 weeks)

Step 1: Port `qtbase` (6-8 weeks)

Create recipe: recipes/wip/qt/qtbase/recipe.toml

[source]
tar = "https://download.qt.io/official_releases/qt/6.8/6.8.2/submodules/qtbase-everywhere-src-6.8.2.tar.xz"
patches = ["redox.patch"]

[build]
template = "custom"
dependencies = [
    "libwayland",
    "mesa",
    "libdrm",
    "libxkbcommon",
    "zlib",
    "openssl1",
    "glib",
    "pcre2",
    "expat",
    "fontconfig",
    "freetype2",
]

script = """
DYNAMIC_INIT

mkdir -p build && cd build

cmake .. \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DCMAKE_BUILD_TYPE=Release \
    -DQT_BUILD_EXAMPLES=OFF \
    -DQT_BUILD_TESTS=OFF \
    -DFEATURE_wayland=ON \
    -DFEATURE_wayland_client=ON \
    -DFEATURE_xcb=OFF \
    -DFEATURE_xlib=OFF \
    -DFEATURE_opengl=ON \
    -DFEATURE_openssl=ON \
    -DFEATURE_dbus=ON \
    -DFEATURE_system_pcre2=ON \
    -DFEATURE_system_zlib=ON \
    -DINPUT_opengl=desktop \
    -DQT_QPA_PLATFORMS=wayland \
    -DQT_FEATURE_vulkan=OFF

cmake --build . -j${COOKBOOK_MAKE_JOBS}
cmake --install . --prefix ${COOKBOOK_STAGE}/usr
"""

What redox.patch for qtbase needs (~500-800 lines):

Platform detection:

qtbase/src/corelib/global/qsystemdetection.h — add Redox detection
qtbase/src/corelib/io/qfilesystemengine_unix.cpp — Redox path handling

Shared memory:

qtbase/src/corelib/kernel/qsharedmemory.cpp — map to Redox shm scheme

Process handling:

qtbase/src/corelib/io/qprocess_unix.cpp — already works (relibc POSIX)

Network:

qtbase/src/network/ — should compile with relibc sockets

Step 2: Port `qtwayland` (1-2 weeks)

[source]
tar = "https://download.qt.io/official_releases/qt/6.8/6.8.2/submodules/qtwayland-everywhere-src-6.8.2.tar.xz"

[build]
template = "custom"
dependencies = ["qtbase", "libwayland", "wayland-protocols"]

script = """
DYNAMIC_INIT
mkdir -p build && cd build
cmake .. \
    -DCMAKE_PREFIX_PATH=${COOKBOOK_SYSROOT}/usr \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DQT_BUILD_TESTS=OFF
cmake --build . -j${COOKBOOK_MAKE_JOBS}
cmake --install . --prefix ${COOKBOOK_STAGE}/usr
"""

Step 3: Port `qtdeclarative` (QML) (2-3 weeks)

[source]
tar = "https://download.qt.io/official_releases/qt/6.8/6.8.2/submodules/qtdeclarative-everywhere-src-6.8.2.tar.xz"

[build]
template = "custom"
dependencies = ["qtbase"]

script = """
# Same cmake pattern as qtwayland
"""

Step 4: Verification (1-2 weeks)

Build and run a simple Qt Wayland app:

#include <QApplication>
#include <QLabel>
int main(int argc, char *argv[]) {
    QApplication app(argc, argv);
    QLabel label("Hello from Qt on Redox!");
    label.show();
    return app.exec();
}

Milestone: Window with "Hello from Qt on Redox!" appears on Wayland compositor.

Phase KDE-B: KDE Frameworks (8-12 weeks)

KDE Frameworks Tier 1 (2-3 weeks)

Framework	Purpose	Estimated Patches
`extra-cmake-modules`	CMake modules	None — pure CMake
`kcoreaddons`	Core utilities	~50 lines (process detection)
`kconfig`	Configuration	~30 lines (filesystem paths)
`kwidgetsaddons`	Extra Qt widgets	None — pure Qt
`kitemmodels`	Model/view classes	None — pure Qt
`kitemviews`	Item view classes	None — pure Qt
`kcodecs`	String encoding	None — pure Qt
`kguiaddons`	GUI utilities	None — pure Qt

Recipe Pattern (same for all Tier 1):

[source]
tar = "https://download.kde.org/stable/frameworks/6.10/kcoreaddons-6.10.0.tar.xz"
patches = ["redox.patch"]

[build]
template = "custom"
dependencies = ["qtbase", "extra-cmake-modules"]

script = """
DYNAMIC_INIT
mkdir -p build && cd build
cmake .. \
    -DCMAKE_PREFIX_PATH=${COOKBOOK_SYSROOT}/usr \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DBUILD_TESTING=OFF \
    -DBUILD_QCH=OFF
cmake --build . -j${COOKBOOK_MAKE_JOBS}
cmake --install . --prefix ${COOKBOOK_STAGE}/usr
"""

KDE Frameworks Tier 2 (2-3 weeks)

Framework	Dependencies	Notes
`ki18n`	`kcoreaddons`, gettext	Internationalization
`kauth`	`kcoreaddons`	PolicyKit stub needed
`kwindowsystem`	`qtbase`	Window management — needs Wayland backend
`kcrash`	`kcoreaddons`	Crash handler — may need signal adjustments
`karchive`	`qtbase`, zlib	Archive handling — should port cleanly
`kiconthemes`	`kwidgetsaddons`, `karchive`	Icon loading

KDE Frameworks Tier 3 (3-4 weeks) - Plasma essentials

Framework	Purpose	Key for Plasma?
`kio`	File I/O abstraction	Yes — file dialogs, I/O slaves
`kservice`	Plugin/service management	Yes — app discovery
`kxmlgui`	GUI framework	Yes — menus, toolbars
`plasma-framework`	Plasma applets/containments	Yes — desktop shell
`knotifications`	Desktop notifications	Yes — notification system
`kpackage`	Package/asset management	Yes — Plasma packages
`kconfigwidgets`	Configuration widgets	Yes — settings UI

Total frameworks needed for minimal Plasma: ~25

Estimated total patch effort for all frameworks: ~1500-2000 lines

Phase KDE-C: Plasma Desktop (6-8 weeks)

Step 1: Port KWin (4-6 weeks)

[source]
tar = "https://download.kde.org/stable/plasma/6.3.4/kwin-6.3.4.tar.xz"
patches = ["redox.patch"]

[build]
template = "custom"
dependencies = [
    "qtbase", "qtwayland", "qtdeclarative",
    "kcoreaddons", "kconfig", "kwindowsystem",
    "knotifications", "kxmlgui", "plasma-framework",
    "libwayland", "wayland-protocols",
    "mesa", "libdrm", "libinput", "seatd",
    "libxkbcommon",
]

script = """
DYNAMIC_INIT
mkdir -p build && cd build
cmake .. \
    -DCMAKE_PREFIX_PATH=${COOKBOOK_SYSROOT}/usr \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DBUILD_TESTING=OFF \
    -DKWIN_BUILD_SCREENLOCKING=OFF \
    -DKWIN_BUILD_TABBOX=OFF \
    -DKWIN_BUILD_EFFECTS=ON
cmake --build . -j${COOKBOOK_MAKE_JOBS}
cmake --install . --prefix ${COOKBOOK_STAGE}/usr
"""

What redox.patch for KWin needs (~1000-1500 lines):

DRM backend:

src/backends/drm/drm_backend.cpp — open DRM scheme instead of device node
src/backends/drm/drm_output.cpp — use scheme ioctl equivalents

libinput backend: Should work via evdevd

src/backends/libinput/connection.cpp — may need path adjustments

EGL/OpenGL:

src/libkwineglbackend.cpp — Mesa EGL should work (already ported)

Session management: KWin expects logind, need stub:

src/session.h/cpp — stub LogindIntegration, use seatd instead

udev:

src/udev.h/cpp — redirect to our udev-shim

Step 2: Port `plasma-workspace` (2-3 weeks)

[source]
tar = "https://download.kde.org/stable/plasma/6.3.4/plasma-workspace-6.3.4.tar.xz"

[build]
template = "custom"
dependencies = [
    "kwin", "plasma-framework", "kio", "kservice",
    "knotifications", "kpackage", "kconfigwidgets",
    "qtbase", "qtwayland", "qtdeclarative",
    "dbus",
]

Key component: plasmashell — desktop shell (panels, desktop containment, applet loader). Depends heavily on QML (qtdeclarative).

Step 3: Create `config/kde.toml`

include = ["desktop.toml"]

[general]
filesystem_size = 4096

[packages]
# Qt
qtbase = {}
qtwayland = {}
qtdeclarative = {}
qtsvg = {}
# KDE Frameworks (minimal set)
extra-cmake-modules = {}
kcoreaddons = {}
kconfig = {}
kwidgetsaddons = {}
ki18n = {}
kwindowsystem = {}
kio = {}
kservice = {}
kxmlgui = {}
knotifications = {}
kpackage = {}
plasma-framework = {}
kconfigwidgets = {}
# KDE Plasma
kwin = {}
plasma-workspace = {}
plasma-desktop = {}
kde-cli-tools = {}
# Support
dbus = {}
mesa = {}
libdrm = {}
libinput = {}
seatd = {}
evdevd = {}
drmd = {}

# Override init to launch KDE session
[[files]]
path = "/usr/lib/init.d/20_orbital"
data = """
requires_weak 10_net
notify audiod
nowait VT=3 orbital orbital-kde
"""

[[files]]
path = "/usr/bin/orbital-kde"
mode = 0o755
data = """
#!/usr/bin/env bash
set -ex

export DISPLAY=""
export WAYLAND_DISPLAY=wayland-0
export XDG_RUNTIME_DIR=/tmp/run/user/0
export XDG_SESSION_TYPE=wayland
export KDE_FULL_SESSION=true
export XDG_CURRENT_DESKTOP=KDE

mkdir -p /tmp/run/user/0

# Start D-Bus
dbus-daemon --system &

# Start D-Bus session
eval $(dbus-launch --sh-syntax)

# Start KWin (Wayland compositor + window manager)
kwin_wayland --replace &

# Start Plasma Shell
sleep 2
plasmashell &
"""

System Integration Points

D-Bus (Already Working)

D-Bus is ported and working in X11 config. KDE uses D-Bus extensively.

Audio: PulseAudio/PipeWire Shim Needed

KDE expects PulseAudio or PipeWire. Redox has scheme:audio.

Options:

A: Port PipeWire (large effort)
B: Write PulseAudio compatibility shim (medium effort)
C: Use KDE without audio initially (skip for now)

Service Management: D-Bus Service Files

KDE services register via D-Bus .service files. Need translation layer that:

Reads /usr/share/dbus-1/services/*.service files
Maps to Redox init scripts
Responds to D-Bus StartServiceByName calls

Network: NetworkManager Integration

KDE uses NetworkManager. Redox has smolnetd.

Options:

A: Port NetworkManager (massive effort, needs systemd)
B: Write NetworkManager D-Bus shim (medium effort)
C: Skip network config UI initially

KDE Implementation Timeline

Phase	Duration	Milestone
Qt Foundation (qtbase, qtwayland, qtdeclarative)	8-12 weeks	Qt app shows window
KDE Frameworks (25 frameworks)	8-12 weeks	KDE app (Kate) runs
KWin + Plasma Shell	6-8 weeks	KDE desktop visible
KDE Apps (Dolphin, Konsole, Kate)	4-6 weeks	Full KDE ecosystem
Total	~38 weeks (9-10 months)	Full KDE Plasma session

Critical Insight: Qt Foundation is highest-risk phase. If Qt compilation hits unexpected relibc gaps, entire timeline shifts.

4. Linux Driver Compatibility: Concrete Path

Why This Is Needed

Writing native Rust GPU drivers for every vendor is years of work. Linux has mature, vendor-supported GPU drivers. A compatibility layer lets us port them with #ifdef __redox__ patches instead of full rewrites.

Target Drivers (priority order):

i915 (Intel) - Best documented, most relevant for laptops
amdgpu (AMD) - Large market share, good open-source driver
nouveau / nvk (NVIDIA) - Community driver, limited performance
Skip: NVIDIA proprietary (binary-only, impossible without Linux kernel)

Architecture

Two-Mode Design:

Mode A: C Driver Port - Compile Linux C driver against our headers, run as userspace daemon Mode B: Rust Wrapper - Rust crate provides idiomatic API, internally calls compat layer

Both modes share: redox-driver-sys

┌────────────────────────────────────────────────────────────┐
│         Mode A: C Driver Port                          │
│  Linux C driver (i915.ko source)                  │
│  compiled with -D__redox__ against linux-kpi headers │
├────────────────────────────────────────────────────────────┤
│         Mode B: Rust Wrapper                        │
│  Rust crate (redox-intel-gpu) using compat APIs      │
├────────────────────────────────────────────────────────────┤
│         linux-kpi (C header compatibility)             │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐       │
│  │ linux/    │ │ linux/   │ │ linux/   │       │
│  │ slab.h   │ │ mutex.h  │ │ pci.h    │       │
│  └──────────┘ └──────────┘ └──────────┘       │
├────────────────────────────────────────────────────────────┤
│         redox-driver-sys (Rust crate)                  │
│  Provides: memory mapping, IRQ, DMA, PCI, DRM scheme  │
├────────────────────────────────────────────────────────────┤
│         Red Bear OS                                    │
│  scheme:memory  scheme:irq  scheme:pci  scheme:drm      │
└────────────────────────────────────────────────────────────┘

Crate 1: `redox-driver-sys` (2-3 weeks)

Repository: New crate in Redox ecosystem Purpose: Safe Rust wrappers around Redox's scheme-based hardware access

redox-driver-sys/
├── Cargo.toml
├── src/
│   ├── lib.rs              — Re-exports
│   ├── memory.rs           — Physical memory mapping (scheme:memory)
│   ├── irq.rs              — Interrupt handling (scheme:irq)
│   ├── pci.rs              — PCI device access (scheme:pci / pcid)
│   ├── io.rs               — Port I/O (iopl syscall)
│   └── dma.rs              — DMA buffer management

Key Implementations:

// src/memory.rs
pub fn map_physical(phys: u64, size: usize, flags: MapFlags) -> Result<*mut u8> {
    let fd = File::open("scheme:memory/physical")?;
    let ptr = syscall::fmap(fd.as_raw_fd(), &Map {
        offset: phys,
        size,
        flags: flags.to_syscall_flags(),
    })?;
    Ok(ptr as *mut u8)
}

pub fn unmap_physical(ptr: *mut u8, size: usize) -> Result<()> {
    syscall::funmap(ptr as usize, size)?;
    Ok(())
}

// src/irq.rs
pub struct IrqHandle { fd: File }

impl IrqHandle {
    pub fn request(irq_num: u32) -> Result<Self> {
        let fd = File::open(&format!("scheme:irq/{}", irq_num))?;
        Ok(Self { fd })
    }

    pub fn wait(&mut self) -> Result<()> {
        let mut buf = [0u8; 8];
        self.fd.read(&mut buf)?;
        Ok(())
    }
}

// src/pci.rs
pub struct PciDevice {
    bus: u8, dev: u8, func: u8,
    vendor_id: u16, device_id: u16,
    bars: [u64; 6],
    bar_sizes: [usize; 6],
    irq: u32,
}

pub fn enumerate() -> Result<Vec<PciDevice>> {
    // Read from pcid-spawner or scheme:pci
    // Parse PCI configuration space
    // Filter to GPU devices (class 0x030000-0x0302xx)
}

Crate 2: `linux-kpi` (3-4 weeks)

Repository: New crate. Installs C headers for use by Linux C drivers. Purpose: Provides linux/*.h headers that translate Linux kernel APIs to redox-driver-sys

linux-kpi/
├── Cargo.toml
├── src/
│   ├── lib.rs              — Rust API for Rust drivers
│   ├── c_headers/          — C headers for C driver ports
│   │   ├── linux/
│   │   │   ├── slab.h      → malloc/kfree (redox-driver-sys::memory)
│   │   │   ├── mutex.h     → pthread mutex (redox-driver-sys::sync)
│   │   │   ├── spinlock.h  → atomic lock
│   │   │   ├── pci.h       → redox-driver-sys::pci
│   │   │   ├── io.h        → port I/O (iopl)
│   │   │   ├── irq.h       → redox-driver-sys::irq
│   │   │   ├── device.h    → struct device wrapper
│   │   │   ├── kobject.h   → reference-counted object
│   │   │   ├── workqueue.h → thread pool
│   │   │   ├── idr.h       → ID allocation
│   │   │   └── dma-mapping.h → bus DMA (redox-driver-sys::dma)
│   │   ├── drm/
│   │   │   ├── drm.h       → DRM core types
│   │   │   ├── drm_crtc.h  → KMS types
│   │   │   ├── drm_gem.h   → GEM buffer objects
│   │   │   └── drm_ioctl.h → DRM ioctl definitions
│   │   └── asm/
│   │       └── io.h        → inl/outl port I/O
│   └── rust_impl/          — Rust implementations backing C headers
│       ├── memory.rs       — kzalloc, kmalloc, kfree
│       ├── sync.rs         — mutex, spinlock, completion
│       ├── workqueue.rs    — work queue thread pool
│       ├── pci.rs          — pci_register_driver, etc.
│       └── drm_shim.rs     — DRM core shim (connects to scheme:drm)

Example C Header:

// c_headers/linux/slab.h
#ifndef _LINUX_SLAB_H
#define _LINUX_SLAB_H

#include <stddef.h>

#define GFP_KERNEL  0
#define GFP_ATOMIC  1
#define GFP_DMA32   2

void *kmalloc(size_t size, unsigned int flags);
void *kzalloc(size_t size, unsigned int flags);
void kfree(const void *ptr);

#endif

Corresponding Rust Implementation:

// src/rust_impl/memory.rs
use std::alloc::{alloc, alloc_zeroed, dealloc, Layout};

#[no_mangle]
pub extern "C" fn kmalloc(size: usize, _flags: u32) -> *mut u8 {
    unsafe {
        let layout = Layout::from_size_align(size, 64).unwrap();
        alloc(layout)
    }
}

#[no_mangle]
pub extern "C" fn kzalloc(size: usize, _flags: u32) -> *mut u8 {
    unsafe {
        let layout = Layout::from_size_align(size, 64).unwrap();
        alloc_zeroed(layout)
    }
}

#[no_mangle]
pub extern "C" fn kfree(ptr: *const u8) {
    if !ptr.is_null() {
        unsafe {
            // Linux kfree doesn't take size. Need size-tracking allocator.
            // Use HashMap<ptr, Layout> for tracking.
        }
    }
}

Crate 3: `redox-drm` (12-16 weeks, overlaps with Wayland DRM)

Repository: Part of Redox base repo or new crate Purpose: The daemon that registers scheme:drm and talks to GPU hardware

redox-drm/
├── Cargo.toml
├── src/
│   ├── main.rs             — Daemon entry, scheme registration
│   ├── scheme.rs           — "drm" scheme handler (processes ioctls)
│   ├── kms/
│   │   ├── mod.rs          — KMS core
│   │   ├── crtc.rs         — CRTC state machine
│   │   ├── connector.rs    — Hotplug detection, EDID reading
│   │   ├── encoder.rs      — Encoder management
│   │   ├── plane.rs        — Primary/cursor planes
│   │   └── framebuffer.rs   — Framebuffer allocation
│   ├── gem.rs              — GEM buffer object management
│   ├── dmabuf.rs           — DMA-BUF export/import via FD passing
│   └── drivers/
│       ├── mod.rs          — trait GpuDriver
│       └── intel/
│           ├── mod.rs      — Intel driver entry
│           ├── gtt.rs      — Graphics Translation Table
│           ├── display.rs  — Display pipe configuration
│           └── ring.rs     — Command ring buffer (for acceleration later)

Core DRM Scheme Protocol:

// src/scheme.rs
enum DrmRequest {
    // Core
    GetVersion,
    GetCap { capability: u64 },

    // KMS
    ModeGetResources,
    ModeGetConnector { connector_id: u32 },
    ModeGetEncoder { encoder_id: u32 },
    ModeGetCrtc { crtc_id: u32 },
    ModeSetCrtc { crtc_id: u32, fb_id: u32, x: u32, y: u32, connectors: Vec<u32>, mode: ModeModeInfo },
    ModePageFlip { crtc_id: u32, fb_id: u32, flags: u32, user_data: u64 },
    ModeAtomicCommit { flags: u32, props: Vec<AtomicProp> },

    // GEM
    GemCreate { size: u64 },
    GemClose { handle: u32 },
    GemMmap { handle: u32 },

    // Prime/DMA-BUF
    PrimeHandleToFd { handle: u32, flags: u32 },
    PrimeFdToHandle { fd: i32 },
}

Intel Driver (native Rust modesetting):

// src/drivers/intel.rs
pub struct IntelDriver {
    mmio: *mut u8,              // Memory-mapped I/O registers (via scheme:memory)
    gtt_size: usize,            // Graphics Translation Table size
    framebuffer: PhysAddr,      // Current scanout buffer
}

impl IntelDriver {
    pub fn new(pci_dev: &PciDev) -> Result<Self> {
        // Map MMIO registers via scheme:memory/physical
        let mmio = map_physical_memory(pci_dev.bar[0], pci_dev.bar_size[0])?;

        // Initialize GTT and display pipeline
        Ok(Self { mmio, gtt_size, framebuffer })
    }

    pub fn modeset(&self, mode: &ModeInfo) -> Result<()> {
        // 1. Allocate framebuffer in GTT
        // 2. Configure pipe (timing, PLL)
        // 3. Configure transcoder
        // 4. Configure port (HDMI/DP)
        // 5. Enable scanout from new framebuffer
        Ok(())
    }

    pub fn page_flip(&self, crtc: u32, fb: PhysAddr) -> Result<()> {
        // 1. Update GTT entry to point to new framebuffer
        // 2. Trigger page flip on next VBlank
        // 3. VBlank interrupt signals completion (via scheme:irq)
        Ok(())
    }
}

Concrete Porting Example: Intel i915 Driver (3-4 weeks)

Step 1: Extract i915 from Linux kernel

# Clone Linux kernel
git clone --depth 1 https://github.com/torvalds/linux.git
# Extract relevant directories
tar cf intel-driver.tar linux/drivers/gpu/drm/i915/ \
    linux/include/drm/ \
    linux/include/linux/ \
    linux/arch/x86/include/

Step 2: Create recipe

# recipes/wip/drivers/i915/recipe.toml
[source]
tar = "intel-driver.tar"

[build]
template = "custom"
dependencies = [
    "redox-driver-sys",
    "linux-kpi",
    "redox-drm",
]

script = """
DYNAMIC_INIT

# Build i915 driver as a shared library
# linked against linux-kpi and redox-driver-sys
export CFLAGS="-I${COOKBOOK_SYSROOT}/include/linux-kpi -D__redox__"
export LDFLAGS="-lredox_driver_sys -llinux_kpi -lredox_drm"

# Compile driver source files
find drivers/gpu/drm/i915/ -name '*.c' | while read src; do
    x86_64-unknown-redox-gcc -c $CFLAGS "$src" -o "${src%.c}.o" || true
done

# Link into a single shared library
x86_64-unknown-redox-gcc -shared -o i915_redox.so \
    $(find drivers/gpu/drm/i915/ -name '*.o') \
    $LDFLAGS

mkdir -p ${COOKBOOK_STAGE}/usr/lib/redox/drivers
cp i915_redox.so ${COOKBOOK_STAGE}/usr/lib/redox/drivers/
"""

Step 3: Minimal patches needed

For i915 on Redox, typical #ifdef __redox__ changes:

// 1. Replace Linux module init with daemon main()
#ifdef __redox__
int main(int argc, char **argv) {
    return i915_driver_init();
}
#else
module_init(i915_init);
module_exit(i915_exit);
#endif

// 2. Replace kernel memory allocation
#ifdef __redox__
#include <linux/slab.h>  // Our compat header
#else
#include <linux/slab.h>  // Real Linux
#endif

// 3. Replace PCI access
#ifdef __redox__
struct pci_dev *pdev = redox_pci_find_device(PCI_VENDOR_ID_INTEL, device_id);
#else
pdev = pci_get_device(PCI_VENDOR_ID_INTEL, device_id, NULL);
#endif

// 4. Replace MMIO mapping
#ifdef __redox__
void __iomem *regs = redox_ioremap(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
#else
void __iomem *regs = ioremap(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
#endif

Concrete Porting Example: AMD amdgpu Driver (6-8 weeks)

AMD's driver is larger and more complex. Key challenges:

1. Firmware Loading

Need to implement:

scheme:firmware/amdgpu/  — firmware blob storage
request_firmware()       — compat function that reads from scheme

2. TTM Memory Manager

Port TTM to use Redox's memory scheme:

// TTM → Redox mapping:
// ttm_tt → allocated pages via scheme:memory
// ttm_buffer_object → GemHandle in scheme:drm
// ttm_bo_move → page table updates via GPU MMIO

3. Display Core (DC)

AMD's display code is ~100K lines. Need to:

Port DCN (Display Core Next) hardware programming
Adapt to Redox's DRM scheme instead of Linux kernel DRM
Keep most code unchanged, just redirect memory/register access

4. Power Management

amdgpu uses Linux power management APIs. Need stubs:

#ifdef __redox__
// No power management on Redox yet — always-on
#define pm_runtime_get_sync(dev) 0
#define pm_runtime_put_autosuspend(dev) 0
#define pm_runtime_allow(dev) 0
#endif

Estimated patches for amdgpu: ~2000-3000 lines of #ifdef __redox__

Linux Driver Implementation Timeline

Phase	Component	Effort	Delivers
1	`redox-driver-sys` crate	2-3 weeks	Memory, IRQ, PCI, I/O primitives
2	Intel native driver (in `redox-drm`)	6-8 weeks	First working GPU driver, modesetting
3	`linux-kpi` C headers (core subset)	3-4 weeks	Memory, sync, PCI, workqueue headers
4	`linux-kpi` DRM headers	2-3 weeks	DRM/KMS/GEM C API headers
5	i915 C driver port	3-4 weeks	Proves LinuxKPI approach works
6	`linux-kpi` extended (TTM, firmware)	4-6 weeks	Enables AMD driver
7	amdgpu C driver port	6-8 weeks	AMD GPU support

Phase 1-2 is critical path — a native Rust Intel driver proves architecture and provides immediate value. Phases 3-7 can happen in parallel or later.

With 2 developers:

Month 1-2: redox-driver-sys + Intel native driver → first display output
Month 3-4: linux-kpi core + DRM headers → i915 C port proof of concept
Month 5-8: linux-kpi TTM + amdgpu port → AMD support
Total: 6-8 months to support both Intel and AMD GPUs

With 1 developer:

Month 1-3: redox-driver-sys + Intel native driver
Month 4-6: linux-kpi core + i915 port
Month 7-10: amdgpu port
Total: 8-10 months

5. Critical Paths & Dependencies

Dependency Chain: Hardware → KDE Desktop

┌─────────────────────────────────────────────────────────┐
│                    KDE Plasma Desktop                     │
│  (KWin compositor, Plasma Shell, Qt, KDE Frameworks)    │
├─────────────────────────────────────────────────────────┤
│                    Wayland Protocol                       │
│  (libwayland, wayland-protocols, compositor)             │
├─────────────────────────────────────────────────────────┤
│                    Graphics Stack                         │
│  (Mesa3D OpenGL/Vulkan, GBM, libdrm, GPU driver)        │
├─────────────────────────────────────────────────────────┤
│                    Kernel Interfaces                      │
│  (DRM/KMS, GEM/TTM, DMA-BUF, evdev, udev)              │
├─────────────────────────────────────────────────────────┤
│                    Hardware                               │
│  (GPU: AMD/Intel/NVIDIA, Input: keyboard/mouse/touch)   │
└─────────────────────────────────────────────────────────┘

Critical Path to KDE Plasma

M1 (POSIX) ───────────────────────────────────────────┐
                                                        │
M3 (DRM/KMS) ───────────── M4 (Compositor) ── M5 (Qt) ── M6 (KDE) ── M7 (Plasma)
       │                     ↑                      │
M2 (Input) ──────────────┘                       M8 (Linux drivers, parallel)

Shortest path to a desktop: M1 → M2 → M3 (parallel) → M4 → M5 → M6 → M7 Shortest path to GPU drivers: M3 → M8 (can start as soon as redox-driver-sys exists)

Parallel Execution Opportunities

Week 1-4:     M1 (relibc POSIX gaps)
Week 3-12:    M2 (evdev input) ──── parallel ──── M3 (DRM/KMS)
Week 13-16:   M4 (Wayland compositor = M2 + M3 + M1)
Week 13-24:   M8 (Linux driver compat, parallel with M4-M6)
Week 17-24:   M5 (Qt Foundation)
Week 25-32:   M6 (KDE Frameworks)
Week 33-38:   M7 (Plasma Desktop)

Total to KDE Plasma: ~38 weeks (~9 months) with 2 developers Total to Linux driver compat: ~24 weeks (~6 months) in parallel

6. Recommendations & Next Steps

Immediate Actions (Week 1-4)

Fix relibc POSIX gaps (1-2 weeks)
- Implement signalfd, timerfd, eventfd in relibc
- Add F_DUPFD_CLOEXEC, MSG_CMSG_CLOEXEC, MSG_NOSIGNAL
- Implement open_memstream
- Result: libwayland builds natively (no patches)
Start evdev daemon (2-4 weeks, parallel with POSIX)
- Create recipes/core/evdevd/
- Implement scheme protocol and ioctl handlers
- Result: Input stack foundation
Start redox-driver-sys crate (2-3 weeks, parallel with POSIX)
- Implement memory, IRQ, PCI, I/O primitives
- Result: Hardware access foundation for LinuxKPI

Medium-Term Actions (Week 5-16)

Complete input stack (2-3 weeks after evdevd)
- Build udev shim
- Port libinput
- Result: Full input stack for Wayland
Build DRM daemon with Intel driver (8-12 weeks)
- Implement KMS core, GEM, DMA-BUF
- Implement Intel native modesetting
- Result: Hardware display control
Build linux-kpi headers (3-4 weeks, parallel with DRM)
- Implement C headers for Linux kernel APIs
- Implement Rust backing implementations
- Result: Compatibility layer for C drivers

Long-Term Actions (Week 17-38+)

Port Wayland compositor (4-6 weeks after M2+M3+M1)
- Add Redox backends to Smithay
- Build smallvil with Redox backends
- Result: First functional Wayland compositor
Port Qt Foundation (8-12 weeks, parallel with compositor)
- Port qtbase, qtwayland, qtdeclarative
- Fix platform detection and shared memory
- Result: Qt applications can run
Port KDE Frameworks (8-12 weeks)
- Port 25+ frameworks (Tier 1, 2, 3)
- Result: KDE applications can be built
Port KDE Plasma (6-8 weeks)
- Port KWin, plasma-workspace, plasma-desktop
- Create config/kde.toml
- Result: Full KDE Plasma desktop
Port Linux GPU drivers (3-4 weeks after linux-kpi, parallel)
- Port i915 as proof of concept
- Port amdgpu for AMD support
- Result: Broad GPU hardware support

Build System Improvements

Issue Found: FUSE mount error (ioctl 25) during build Recommendation: Add build environment cleanup script:

# scripts/clean-build-env.sh
#!/bin/bash
fusermount3 -u build/x86_64/desktop/filesystem 2>/dev/null || true
fusermount3 -u /tmp/redox_installer 2>/dev/null || true
rm -rf build/x86_64/desktop/filesystem 2>/dev/null || true

Integration: Add to Makefile:

clean: FORCE
    @./scripts/clean-build-env.sh
    # ... rest of clean target

Resource Requirements

Storage: 20GB+ free space (full build with all recipes) RAM: 4GB minimum, 8GB+ recommended Network: Required for downloading sources and toolchain OS: Linux (Arch/Manjaro, Debian/Ubuntu, Fedora, Gentoo)

7. Risk Assessment & Mitigation

High-Risk Areas

Qt Foundation (HIGH RISK)
- Risk: Unexpected relibc gaps blocking Qt compilation
- Impact: Entire KDE timeline shifts by months
- Mitigation: Start Qt porting early, test with software rendering
Linux Driver Porting (MEDIUM RISK)
- Risk: Linux driver code complexity exceeds LinuxKPI capabilities
- Impact: AMD/NVIDIA drivers may not work
- Mitigation: Start with Intel (simplest), prove concept before AMD
Wayland Compositor (LOW-MEDIUM RISK)
- Risk: Smithay Redox backends integration issues
- Impact: Wayland session delayed
- Mitigation: Use native Rust Intel driver first, no LinuxKPI dependency

Technical Risks

No GPU Acceleration
- All rendering is software-only via LLVMpipe
- Performance will be poor for desktop workloads
- Mitigation: Prioritize hardware GPU driver work
Missing System Integration
- No NetworkManager equivalent → no network UI
- No PipeWire → no audio in KDE
- Mitigation: Build minimal shims, skip features initially
Kernel ABI Unstable
- Redox syscall ABI intentionally unstable
- Changes may break compatibility layers
- Mitigation: Work through libredox/relibc, not kernel syscalls directly

8. Conclusion

Red Bear OS has:

✅ Comprehensive documentation with concrete implementation paths
✅ Functional build system with Rust-based tools
✅ Active development with 60+ patches for Linux compatibility
✅ Clear roadmap to Wayland, KDE Plasma, and Linux drivers
⚠️ Identified blockers (7 POSIX gaps, no GPU acceleration, missing DRM/KMS)

Estimated Timelines:

Wayland compositor: 5-6 months (M1 + M2 + M3 + M4)
KDE Plasma desktop: 9-10 months (M1 → M7)
Linux driver compatibility: 6-8 months (M3 + M8)

Key Insights:

POSIX gaps in relibc are the foundational blocker - 1-2 weeks to fix
Input stack and DRM/KMS can be built in parallel (4-12 weeks each)
Qt Foundation is the highest-risk phase - should start early
Native Rust Intel driver is a faster path than full LinuxKPI for initial GPU support
LinuxKPI approach is essential for AMD/NVIDIA long-term support

Recommendation: Start with Milestone M1 (POSIX gaps) immediately, as it unblocks everything else. With 2 developers working in parallel on M2 (input) and M3 (DRM), a functional Wayland compositor is achievable in ~6 months, with KDE Plasma following in ~9 months.

Appendix A: Existing WIP Recipes Inventory

Wayland Recipes (21 packages):

libwayland, wayland-protocols, wayland-utils
libxkbcommon, xkeyboard-config
mesa, libdrm
cosmic-comp, cosmic-panel, libcosmic-wayland
smallvil (Smithay)
wlroots, sway, hyprland, niri, pinnacle, fht-compositor
xwayland, anvil
iced-wayland, winit-wayland, softbuffer-wayland, wayland-rs

KDE Recipes (19 packages):

ark, discover, gcompris, heaptrack, k3b, kamoso, kcachegrind
kde-dolphin, kdenlive, kdevelop, kpatience, krita, ktorrent
kwave, labplot, marble, massif-visualizer, okteta, skanpage

Patches Inventory: 60+ redox.patch files across recipes

END OF REPORT

44 KiB Raw Blame History