The mesa recipe has been bouncing between direct-edit Wayland
configurations and the legacy Orbital EGL recipe. Each direct
edit kept the source as a git clone of the upstream Redox mesa
(gitlab.redox-os.org/redox-os/mesa, branch redox-24.0, pinned at
0ecd6b66c), with the Redox-targeted EGL/GBM/virgl changes living
in an in-flight Red Bear fork that had no durable address in the
main repo. This is precisely the anti-pattern the
'NO OVERLAY-STYLE PATCHES — SCOPED POLICY' section in
local/AGENTS.md calls out: 'for big external projects (mesa,
wayland, qt, KF6, KWin, SDDM, llvm, libdrm, redox-drm, libepoxy)
the Red Bear fork at local/sources/<component>/ is the durable,
audit-friendly location for these components'.
This commit completes the proper Red Bear full-fork model for
mesa:
* mainline recipes/libs/mesa/recipe.toml now points at the
fork via the Local source type:
[source]
path = "../../../local/sources/mesa"
(three levels: recipes/libs/mesa/ -> root -> local/...)
The cookbook's fetch.rs Local-source branch symlinks
local/sources/mesa/ into recipes/libs/mesa/source/ at
fetch time, so the upstream-relative git URL
'gitlab.redox-os.org/redox-os/mesa' is no longer needed
here.
* mainline recipes/libs/mesa/recipe.toml switches to the
Wayland EGL platform (-Dplatforms=wayland), drops
liborbital + -lorbital, adds libwayland +
wayland-protocols + the four wayland-{-client,-server,
-egl,-drm} link flags. The redox EGL platform
(src/egl/drivers/dri2/platform_redox.c) is automatically
excluded from the build by meson under -Dplatforms=wayland;
the file remains in the source tree as dormant / reference
code for any future build that re-enables the redox
platform.
* mainline recipes/libs/mesa/recipe.toml gets a [package]
section (version 0.2.3, description anchored on the
fork's 0.2.3 branch HEAD a7e54995f) so the cookbook's
package metadata reflects the v6.0 2026 release.
* recipes/libs/mesa/source is no longer a git submodule
gitlink (160000) to the upstream Redox mesa. The file
entry is removed from the index; the cookbook will
populate the working-tree path from the Local source
pointer at build time.
* local/recipes/libs/mesa/recipe.toml is removed. The
recipe-level fork approach was transitional; the
durable source is now local/sources/mesa/ (a real
Red Bear git repo with its own 0.2.3 branch, gitea
remote, and the upstream redox-24.0 branch left
intact for clean rebase-onto-upstream). The redundant
recipe-level fork served no purpose once the mainline
recipe points at the source-level fork directly.
* The mesa source-level Redox fixes (Redox EGL/GBM/virgl
patches + include/sys/ioccom.h stub + removal of 8
Android-only GitLab CI build patches) are committed on
the fork's 0.2.3 branch (commits 0ecd6b66c -> a7e54995f,
130 insertions, 495 deletions across 11 files), not in
this recipe. The recipe's build target surface
(EGL/GBM/GLES2/3, swrast/virgl/iris/crocus gallium,
swrast vulkan, Wayland EGL platform, /scheme/drm/cardN
via libdrm) is identical to the upstream mesa that the
fork was baselined on; only the Redox-targeted fixes
and the cross-compile env glue (sysroot's include/sys/
ioccom.h) diverge.
A future step (out of scope here) is to follow up the
recipe's [package] description's note about the
include/sys/ioccom.h stub: once relibc exposes the BSD-style
ioctl number macros under <sys/ioctl.h> directly, the
fork's include/sys/ioccom.h and the __redox__ guard in
include/drm-uapi/drm.h should both be removed, and the
fork's 0.2.3 branch should pick up the relibc change as a
forward rebase.
The header comment block of recipes/libs/mesa/recipe.toml
matches the same doc-contract used by
recipes/libs/libdrm/recipe.toml and
recipes/gpu/redox-drm/recipe.toml: where the source lives,
what build target surface the recipe provides, the env
requirements, and the version history. Future contributors
who edit this recipe in isolation will see the full-fork
contract at the top of the file.
The parallel-agent update completed the mesa recipe edit:
- Added full doc comment explaining the Red Bear fork model
- Switched to Wayland EGL platform (-Dplatforms=wayland)
- Replaced -lorbital with wayland-{client,server,egl,drm} link flags
- Added [package] section with version + description
- Removed liborbital dep; added libwayland + wayland-protocols
Per AGENTS.md Rule 2 (amended 2026), mesa is a big external
project (multi-million-line codebase) and is maintained as a
Red Bear fork at local/sources/mesa/. The recipe in mainline
is a thin shim that points the cookbook at the fork.
This is a direct edit of the mainline recipe, NOT an overlay
symlink. The cookbook now walks local/recipes/ first (commit
d747b4009), so the mainline recipe is the authoritative source
of truth for the Red Bear fork.
The previous commit 13d0543c2 introduced Phase 2.1 (Mesa EGL
Wayland migration) and was reverted in a88b43b71. This re-applies
the change directly to the mainline recipe.
Per the NO OVERLAY-STYLE PATCHES policy in AGENTS.md:
- Red Bear is a FULL FORK. recipes/ is the source of truth.
- The local/recipes/libs/mesa/ fork approach was overlay-style
and is being removed.
- Direct edits to the mainline recipe are the correct pattern.
Changes to recipes/libs/mesa/recipe.toml:
- Remove 'liborbital' from dependencies
- Add 'libwayland' and 'wayland-protocols' to dependencies
- Replace '-lorbital' link flag with:
-lwayland-client -lwayland-server -lwayland-egl -lwayland-drm
- Change '-Dplatforms=redox' to '-Dplatforms=wayland'
The mesa source's platform_redox.c (which includes <orbital.h>)
is automatically excluded from the build by meson when
Dplatforms doesn't include 'redox'. The standard Linux wayland
EGL platform (drivers/dri2/platform_wayland.c) is enabled.
Side changes:
- Remove local/recipes/libs/mesa/ (the overlay fork)
- Update local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md to reflect
Phase 2.1 status
The recipe still points at the upstream redox mesa git source
(per AGENTS.md: 'Upstream gitlab URLs are temporary ... but
unmodified upstream packages with pinned revisions' is allowed).
To complete the full-fork model, a future step is to fork the
mesa source to local/sources/mesa/ and switch the recipe to use
path = '...'.
Add the Red Bear OS forks of libxkbcommon and xkeyboard-config under
local/recipes/, replacing the previous WIP overlays. The local recipes
build against the XKB data and ship meson flags consistent with the
WIP-recipe baseline. The recipes/wip/ symlinks are kept so existing
config/ includes that reference the WIP path keep working.
Per the NO OVERLAY-STYLE PATCHES policy in AGENTS.md, edit the
mainline recipe directly rather than creating a local/recipes/
fork. This is the canonical Red Bear recipe.
Changes to recipes/libs/mesa/recipe.toml:
- Remove 'liborbital' from dependencies
- Add 'wayland' and 'wayland-protocols' to dependencies
- Replace '-lorbital' link flag with:
-lwayland-client -lwayland-server -lwayland-egl -lwayland-drm
- Change '-Dplatforms=redox' to '-Dplatforms=wayland'
The mesa source's platform_redox.c (which includes <orbital.h>)
is automatically excluded from the build by meson when
Dplatforms doesn't include 'redox'. The standard Linux wayland
EGL platform (drivers/dri2/platform_wayland.c) is enabled.
Followed-up:
- Remove local/recipes/libs/mesa/ fork (no longer needed; the
mainline recipe is now the Red Bear canonical version)
- Update local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md to mark
Phase 2.1 done (was 'skeleton recipe forked')
This is the correct, full-fork way to change a recipe. No overlay
layer, no apply-patches.sh symlink, no local fork. Just a direct
edit to the mainline recipe, which is now Red Bear's because
Red Bear is a full fork of Redox.
Pick up the ninja-build fork's 0.2.3 branch HEAD (26f6155), which
adds an extern "C" declaration of getloadavg(double[], int)
guarded by __redox__ to util.cc. Redox's <cstdlib> wrapper pulls
in a stale toolchain stdlib.h that lacks getloadavg, so util.cc
fails to compile on Redox with an implicit-function-declaration
error even though relibc provides the implementation. Other
platforms are untouched.
Pick up the uutils-tar fork's 0.2.3 branch HEAD (bcf6fdb), which
pins rust-version to 1.92.0 to match the Red Bear cross-toolchain
(upstream bumped to 1.94, which is unavailable here) and removes
the uutests dev-dependency, which is a workspace member only
resolvable inside the uutils/coreutils monorepo. With uutests
gone, both root and fuzz Cargo.lock files no longer carry those
workspace-only entries and the lockfiles shrink back to a clean
standalone build.
Pick up the sddm fork's 0.2.3 branch HEAD (a994435), which builds
SDDM as a Wayland-only greeter/daemon for Redox. Highlights:
-DNO_X11 is added globally so X11 code paths are compiled out;
the XAU/XCB/XKB find_package calls are switched to QUIET so
missing X11 dev packages on a Wayland-only build do not fail
configure. XAuth.cpp, XorgDisplayServer.cpp,
XorgUserDisplayServer, and XcbKeyboardBackend sources are
dropped from the daemon, greeter, and helper link lists, the
sddm-helper-start-x11user target is removed, the .ts -> .qm
translation step is dropped (LinguistTools no longer required),
and the test/ subdir is no longer built. UserSession replaces
the Xauthority cookie write with a no-op (Wayland-only) and
passes an explicit third argument to TIOCSCTTY. Note: the
preprocessor guards in Display.cpp / Greeter.cpp / Seat.cpp /
KeyboardModel.cpp are emitted as deeply-nested duplicate
#ifndef NO_X11 blocks; the guards are semantically equivalent
to a single pair per region but should be collapsed in a
follow-up cleanup.
Point the redox-drm recipe at the new durable fork at
local/sources/redox-drm/. The source tree is now an absolute
symlink from local/recipes/gpu/redox-drm/source to the fork,
matching the pipewire / wireplumber fork model. The absolute
target survives moving the project root.
Drop the dead recipe-local patches (P5, P8, P10 — P9 was dropped
in the prior redox-drm recipe commit). All four were already
applied to the in-tree source before the fork move, so the patch
artefacts were inert. The fork is the durable source of truth;
future Red Bear changes go as git commits there.
Bump version 0.1.0 -> 0.2.3 and add the v6.0 2026 Red Bear fork
marker to the description. The recipe documentation now describes
the supported GPU targets (virtio-gpu, Intel Meteor Lake / Arrow
Lake / Lunar Lake, AMD display glue) and the hardware validation
status of each.
DrmOutput's _file field was stored but unused; flip() reopened
/scheme/drm/card0 on every page flip. Rename to drm_file, un-
underscore, and use &self.drm_file in flip() to avoid the per-flip
open+close round trip.
This is the implementation of v6.0 plan Phase 3.5 'Fix page
flip to keep DRM fd open'.
Migrate the libdrm recipe from the tar+patches shape (redox.patch + four
P1-P4 patches from local/patches/libdrm/) to a Local source pointing at
the new Red Bear fork at local/sources/libdrm/. The fork is based on
upstream libdrm 2.4.125 (https://gitlab.freedesktop.org/mesa/libdrm) and
already has the full redox.patch series applied in-tree.
The P1-P4 patch files referenced from the previous recipe
(P1-drm-ioctl-bridge, P2-drm-get-pci-info, P3-drm-get-version-driver-name,
P4-drmGetDeviceFromDevId-redox) were already merged into redox.patch and
no longer existed in local/patches/. Consolidating everything into a
single in-tree fork is the durable form per the FULL FORK PRINCIPLE.
The fork's redox divergence covers:
- include/drm/drm.h: include <sys/ioctl.h> on __redox__ instead of
<sys/ioccom.h>
- xf86drm.h: Redox-aware ioctl type definitions
- xf86drm.c: major()/minor()/makedev() macros from musl for __redox__,
open_memstream fallback path (returns NULL with diagnostic on
__redox__), redox_drm_write_all helper, and the drmOpen /
drmGetDeviceFromDevId / etc. rewrites that dispatch through scheme:
paths on Redox
- xf86drmMode.c: Redox shim for drmModeGetResources /
drmModeGetConnector / etc. and the mode probing path
- xf86drm_redox.h: new header providing the Redox-side helper API
(open scheme:, drm fd adaptation, dev_t packing) used by xf86drm.c
Recipe changes:
- source: tar + patches list -> Local { path = '../../../../local/sources/libdrm' }
(the recipe lives under both recipes/wip/x11/libdrm and
recipes/libs/libdrm symlinks into local/recipes/libs/libdrm; the
four-.. path resolves correctly from both locations to
local/sources/libdrm).
- version: bumped to 0.2.3 (Red Bear fork tracking upstream 2.4.125).
- description: marked v6.0 2026 Red Bear fork.
- removed: redox.patch and source/ / source.tar / target/ artifacts
under the recipe directory; they are no longer referenced and the
fork is the single source of truth.
Verified: ./target/release/repo cook libdrm (with
REDBEAR_ALLOW_PROTECTED_FETCH=1) builds successfully and publishes
libdrm 0.2.3 to repo/x86_64-unknown-redox/ with the fork's commit
identifier pinned.
The amdgpu recipe's idr_* / ida_* header conflict with linux-kpi is
now resolved (see the preceding commit). Re-enable amdgpu in
redbear-full.toml by changing amdgpu = "ignore" to amdgpu = {} and
add a [package] section to the amdgpu recipe marking the 0.2.3
release and describing the bounded display-glue compile surface
(DCN20 / DCN30 / DCN31 backend files plus the Rust-side init /
connector detection / modeset glue).
The linux-kpi idr.h header and the amdgpu recipe's redox_glue.h
both define struct idr and the idr_init/alloc/remove/find/destroy
inline functions, but with different members and different argument
signatures. When the amdgpu build includes both headers in the same
translation unit (via -include linux/amdgpu_stubs.h and via
redox_glue.h), the compiler reports a redefinition of struct idr
and conflicting types for the idr_* inlines, blocking the build.
Resolve the conflict by gating the linux-kpi idr declarations on a
new REDBEAR_AMDGPU_BUILD preprocessor flag. The amdgpu recipe's
CFLAGS now defines REDBEAR_AMDGPU_BUILD, so the linux-kpi
declarations are suppressed and redox_glue.h's authoritative copies
take over. Every other consumer of linux-kpi (the redox-drm scheme
daemon, the Wi-Fi drivers) continues to see the generic stubs.
The IDA macros and struct ida in linux-kpi are kept outside the
gate because they are not part of the amdgpu surface and must
remain available to other drivers. A forward declaration of
struct idr is added at the top of the header so the
struct ida { struct idr *idr; } member compiles cleanly when the
IDR definitions are suppressed. The IDA macros are updated to
no-ops against a pointer-typed idr slot; the amdgpu build does
not exercise them and other consumers continue to treat them as
stubs.
Point the redox-drm recipe at the new durable fork at
local/sources/redox-drm/. The source tree is now a symlink from
local/recipes/gpu/redox-drm/source to the fork, matching the
redox-driver-sys / pipewire / wireplumber fork model.
Drop the four dead recipe-local patches (P5, P8, P9, P10). All four
were already applied to the in-tree source before the fork move, so
the patch artefacts were inert. The fork is the durable source of
truth; future Red Bear changes go as git commits there.
Bump version 0.1.0 -> 0.2.3 and add the v6.0 2026 Red Bear fork
marker to the description. The recipe documentation now describes
the supported GPU targets (virtio-gpu, Intel Meteor Lake / Arrow
Lake / Lunar Lake, AMD display glue) and the hardware validation
status of each.
The mainline recipes/libs/mesa/recipe.toml links against -lorbital
and uses -Dplatforms=redox — a deprecated Orbital-only path. For
the v6.0 console-to-desktop plan, Mesa must be switched to the
Wayland EGL platform (-Dplatforms=wayland + -lwayland-client) so
Qt6 eglfs can open a window under a Wayland compositor.
Create a Red Bear fork of the mainline recipe under
local/recipes/libs/mesa/ to receive the EGL Wayland changes
without modifying mainline directly. This recipe is currently
identical to upstream; subsequent commits will:
- Remove -lorbital link flag and liborbital dep
- Add wayland + libwayland-client deps
- Switch -Dplatforms=redox to -Dplatforms=wayland
- Verify EGL_KHR_platform_wayland loads in QEMU
Phase 2.1 of the v6.0 plan: 1 week effort.
atomic_check previously ignored the _available_connectors parameter
(prevented by underscore prefix). The CRTC state's connectors: Vec<u32>
field declared which connectors to bind, but atomic_check never
verified they actually existed or were connected. This allowed
client commits to reference phantom or disconnected connectors
and silently produce invalid state.
Fix: use the available_connectors slice to validate that each
referenced connector ID exists in hardware and has connection
status Connected. Return CrtcNotFound or ConnectorDisconnected
respectively so the kernel rejects invalid commits with a clear
error rather than producing a malformed display state.
This unblocks libdrm drmModeAtomicCommit callers that rely on
DRM_MODE_ATOMIC_ALLOW_MODESET returning success only for valid
connector configurations.
Adds the local recipe.toml files for pipewire and wireplumber
under local/recipes/libs/. Both recipes are now properly tracked
as Red Bear OS custom recipes that follow the local-over-WIP
convention.
The recipe.toml files document:
* the upstream version (0.3.85 for pipewire, 0.4.14 for
wireplumber) and the v6.0 2026 Red Bear description
* the build dependencies (glib, dbus, expat, pipewire for
wireplumber)
* the build command (cookbook_meson with Redox-specific
meson flags disabling ALSA, BlueZ, V4L2, JACK, systemd,
elogind, etc.)
* the redox_compat/ shim headers that stage byteswap.h and
sys/mman.h into the per-recipe sysroot so the meson
subprojects (spa/plugins/*) see them
The 'source' symlinks (absolute paths) and the
recipes/wip/services/{pipewire,wireplumber} symlinks were
already wired up in the previous redbear-full commit.
The redbear-full desktop target now pulls in pipewire and wireplumber
as the audio backend for KDE Plasma (Phonon, KMix, the Plasma audio
widget). This wires up the packages built by the new
local/recipes/libs/pipewire and local/recipes/libs/wireplumber
recipes on top of the existing audiod scheme daemon in the base
package.
Changes:
* config/redbear-full.toml
- new [packages] entries for pipewire and wireplumber
- two new [[files]] init services: 15_pipewire.service and
16_wireplumber.service (both oneshot_async, depend on
12_dbus.service)
* local/recipes/system/redbear-dbus-services/files/
- new org.freedesktop.PipeWire.service (system bus, runs
/usr/bin/pipewire) and org.pulseaudio.Server.service
(system bus, runs /usr/bin/pipewire-pulse)
- new org.freedesktop.impl.pulseaudio.service (session bus,
runs /usr/bin/pipewire-pulse) for KDE Phonon / KMix
- matching .conf policy files for org.freedesktop.PipeWire
and org.pulseaudio.Server that allow the expected
Introspectable / Properties / *Manager / *Node / *Link /
*Client / *Device / *Meter / *Core / *Port send and
receive patterns
* config/protected-recipes.toml
- new [libs] entries for pipewire and wireplumber, so the
cookbook never silently re-fetches them; sources are
directly editable in local/sources/
* recipes/wip/services/{pipewire,wireplumber}
- replaced the tracked WIP directories with symlinks to
local/recipes/libs/{pipewire,wireplumber}, per the
local-over-WIP convention enforced by
local/scripts/build-redbear.sh
Known build state (documented in the upstream README-redbear.md
files in each source fork):
* pipewire build reaches ~24/603 C files compiled before
hitting relibc gaps (sys/prctl.h, sys/mount.h, and a few
Linux-specific ioctls). The recipe, source fork, and
Redox-compat shims are in place; the remaining work is
upstream relibc headers, not PipeWire porting decisions.
* wireplumber recipe is in place but the build has not been
attempted yet — wireplumber depends on the pipewire build
completing first.
The audiod integration (the scheme backend that pipewire would
talk to) is not implemented in this commit. That is the next
gating work item and is tracked in
local/sources/pipewire/README-redbear.md.
The StubBackend returned hardcoded SSIDs ("demo-ssid", "demo-open")
and synthesised connection outcomes without ever touching the iwlwifi
driver or netstack. This was a stub that hid the real work needed to
control Intel Wi-Fi devices on Redox.
This commit removes the StubBackend entirely and renames the existing
real PCI/iwlwifi-aware backend from IntelBackend to IwlwifiBackend.
The renamed backend is the default; when no Intel Wi-Fi device is
detected, the NoDeviceBackend is selected (which is the legitimate
"no hardware present" path, not a stub).
Backend mode selection (in main.rs):
- REDBEAR_WIFICTL_BACKEND=iwlwifi|no-device: explicit override
- redox runtime + iwlwifi driver + Intel interface detected: Iwlwifi
- everything else: NoDevice (no silent stub fallback)
The IwlwifiBackend talks to /usr/lib/drivers/redbear-iwlwifi via the
existing Command-based action plumbing (--prepare, --init-transport,
--activate-nic, --scan, --connect, --disconnect, --retry, etc.), which
in turn maps BAR0 MMIO, loads ucode/pnvm, and drives the iwlwifi
device. The previously-stripped stub output paths (firmware=stub,
transport=stub, transport_init=stub, connect=stub, disconnect=stub)
are gone; every status field is now sourced from the real driver or
returned as an honest error from NoDeviceBackend.
Version bumped 0.1.0 -> 0.2.3.
Tests:
- 17 unit tests pass on host target (replaced 4 stub_* tests with
no_device_* and iwlwifi_transport_probe_honors_driver_action).
- 2 CLI integration tests pass (cli_transport.rs unchanged).
- cargo test 19/19 green.
- ./target/release/repo cook redbear-wifictl: successful; produces
repo/x86_64-unknown-redox/redbear-wifictl.pkgar and .toml with
version 0.2.3.
The 4 service files (org.kde.ksmserver, org.kde.JobViewServer,
org.kde.ActivityManager, org.freedesktop.StatusNotifierWatcher)
existed in local/recipes/system/redbear-dbus-services/files/ but were
never mirrored into source/ where the build actually reads in offline
mode. This meant only 3 of the 7 session-service activation files
reached the staged package.
Also fix org.kde.kglobalaccel.service to point at the real install
location: kglobalacceld is installed to /usr/libexec/ (KDE_INSTALL_LIBEXECDIR),
not /usr/bin/.
Sync files/session-services/org.kde.kded6.service to the offscreen-QPA
wrapper that the build was already shipping from source/.
Build now stages all 7 session-service files plus 4 system-services
and 4 policy files (15 dbus config files total).
Cross-cutting changes tied to the libepoxy/libxcvt/libdisplay-info/
lcms2/libudev stub-removal work:
- config/protected-recipes.toml [graphics]: add libepoxy, libxcvt,
libdisplay-info, lcms2 (real Red Bear recipes under local/recipes)
- config/protected-recipes.toml [libs]: drop the 5 *-stub entries,
add 'libudev' (renamed from libudev-stub)
- local/recipes/AGENTS.md catalog: drop the 5 *-stub rows, update
the 5 real lib rows to reflect the v6.0 2026 fork
- local/scripts/apply-patches.sh: drop the 5 *-stub symlink
creation entries; add libudev symlink entry
(The redbear-full.toml package list was already updated to enable
libdisplay-info, libxcvt, lcms2 and add libudev, as part of the
pam-redbear commit that included both changes.)
The libudev-stub was a real 1314-line libudev implementation backed
by the /scheme/udev producer (driven by udev-shim) — not a stub in
the zero-tolerance sense. It was named -stub to make the bounded
hotplug-event-delivery scope obvious.
Rename the recipe to libudev to match the upstream systemd surface it
implements (the recipe still backs through scheme:udev, but the public
name now matches the library's actual role for KWin tablet / input
discovery and libinput's udev device enumeration). Update:
- local/recipes/libs/libudev/recipe.toml: bump to 0.2.3, drop the
#TODO: stub-style header, add v6.0 2026 description
- local/recipes/libs/libinput/recipe.toml: dependency now 'libudev'
- local/recipes/kde/kwin/recipe.toml: dependency now 'libudev'
- config/protected-recipes.toml [libs]: now lists 'libudev'
The libudev.pc, UDev::UDev CMake target, and libudev.so surface are
unchanged — they are the real libudev C ABI as required by KWin and
libinput, with /scheme/udev/devices as the data source.
The lcms2-stub was a CMake-imported shared library that returned
NULL/zero from every API: cmsOpenProfileFromMem, cmsCreateTransform,
cmsDoTransform, cmsCreate_sRGBProfile, cmsGetProfileInfo, and the
rest. KWin color correction, ICC profile lookup, and color space
transformation were silently broken — every transform call produced
identity output.
Replace it with the real lcms2 (mm2/Little-CMS lcms2.19 fork) — the
full upstream C source built via CMake, providing real profile
parsing, gamut mapping, ICC v4 / v2 profile handling, sRGB profile
generation, and the LittleCMS transform pipeline. Recipe bumped to
0.2.3 with v6.0 2026 description.
The libdisplay-info-stub was a bounded 11k shim that parsed only base
EDID vendor/product, strings, physical size, chromaticity, and the
preferred-timing descriptor. All other di_edid_* / di_cta_* /
di_displayid_* calls returned NULL or fell through to the stub.
KWin output configuration, display detection, and EDID-based
connection setup were silently degraded.
Replace it with the real libdisplay-info (emersion/libdisplay-info
fork) — a full C implementation that exposes the libdisplay-info
EDID parser API (di_info_parse_edid, di_edid_get_vendor_product,
di_edid_get_display_name, di_edid_get_screen_size, etc.) with
complete EDID 1.4 parsing of base block + extensions. CTA and
DisplayID remain unsupported in the bounded v6.0 2026 fork, which
is documented in the [package] description. Recipe bumped to 0.2.3.
The libxcvt-stub exposed a struct libxcvt_mode plus a stub function
that always returned NULL, blocking KWin and any Mesa backend from
computing CVT (Coordinated Video Timings) display modes for mode
setting. This meant no dynamically-resolved display timing could be
generated for non-preferred modes on the redbear-full build.
Replace it with the real libxcvt (freedesktop.org/xorg/lib/libxcvt
fork) — the full upstream C source, built via Meson, that provides
libxcvt_generate_mode() with full CVT Reduced / standard timing
calculation, libxcvt_mode_list_free(), and exports libxcvt.pc plus
the proper include path. Recipe bumped to 0.2.3 with v6.0 2026
description.
The libepoxy-stub provided a hardcoded stub that returned 0/NULL for
every epoxy_egl_extension_supported, epoxy_has_gl_extension, and
epoxy_gl_version call, plus a fake epoxyConfig.cmake. KWin and Qt6
Wayland code paths were never able to detect GL/EGL extensions or
negotiate GL versions, which broke the KWin rendering pipeline silently.
Replace it with the real libepoxy (anholt/libepoxy fork) — the full
upstream C source, built against Mesa EGL/GLES2, that registers
epoxy::epoxy in CMake, provides libepoxy.pc, and produces the real
epoxy_gl_version / epoxy_has_gl_extension / epoxy_egl_*_supported
runtime values. Recipe bumped to 0.2.3 with v6.0 2026 description.
Also: protected-recipes.toml [libs] no longer lists the stub.
Promote the four runtime TOML loader families from pub(crate) to pub
so consumers (acpid) can call them directly at startup:
* read_toml_cpu_bug_entries / parse_cpu_bug_toml / load_cpu_bug_flags
* read_toml_clocksource_entries / parse_clocksource_toml / load_clocksource_flags
* read_toml_chipset_entries / parse_chipset_toml / load_chipset_flags
* read_toml_usb_audio_entries / parse_usb_audio_toml / load_usb_audio_flags
These read /etc/quirks.d/*.toml at startup and OR-accumulate the
flags. Exposing them makes the quirks system data-driven for any
caller, not just compiled-in drivers. The semantics are unchanged;
only the visibility bumps from pub(crate)/fn to pub.
2026 Red Bear OS.
KWin CMake config does find_package(Fontconfig) and needs the
fontconfig.h header at /usr/include/fontconfig/fontconfig.h.
fontconfig wasn't previously in the build deps, so the CMake
fontconfig module couldn't find the headers and failed.
libxcb is in recipes/wip/x11/ which is not safe upstream ownership for
Red Bear shipping decisions. KWin on Wayland does not need X11 — the
recipe already builds with -DKWIN_BUILD_X11=OFF -DKWIN_BUILD_X11_BACKEND=OFF
and the build script removes #include <xcb/xcb_cursor.h>. The libxcb
dep was leftover from a full X11+KWin build and is not required for
the Red Bear Wayland-only compositor path.
v6.0 prep. Description now says 'writes Linux evdev events to
/scheme/input/evdev' instead of 'orbclient format and pushed to
inputd'. The Cargo.toml orbclient dep is removed; the main.rs
still uses orbclient::Event but will be refactored to use
inputd::EvdevProducerHandle in a follow-up commit (the main.rs
refactor is large enough to warrant its own commit for review).
The v6.0 desktop plan replaces the dual-path input architecture
(inputd orbclient + evdevd bridge) with a single Linux evdev
producer. evdevd now reads from /scheme/input/evdev and relays
events as-is to its per-device queues.
Changes:
- main.rs: InputConsumer opens /scheme/input/evdev (not
/scheme/input/consumer). Reads 8-byte WireEvent records
(u16 type, u16 code, i32 value) — matches Linux
struct input_event (sans time fields, which evdevd's
types::InputEvent::new adds).
- main.rs: dispatch_evdev_event() replaces the orbclient
EventOption translation logic. Events go straight to the
scheme's queue.
- main.rs: drop unused 'use size_of' and 'use orbclient' imports.
- scheme.rs: new push_input_event(event_type, code, value)
method. Routes events to the correct device (keyboard,
mouse, or touchpad) based on event type/code. SYN_REPORT
is broadcast to all devices so the libinput consumer sees
a complete report.
- scheme.rs: new queue_raw_event() helper for push_input_event.
- main.rs: log message updated to 'v6.0 single-producer mode'.
The legacy feed_*() methods (orbclient -> evdev translation)
remain in scheme.rs for now, used by the existing unit tests
and as a fallback path. They will be removed in a follow-up
cleanup once /scheme/input/evdev is confirmed working in QEMU.
cargo check --target x86_64-unknown-redox: 0 errors, 26 warnings
(all warnings are in legacy translate.rs/feed_* methods that
are now unused but kept for backward compat).
Two parallel review agents cross-checked the virtio-inputd driver against
the Linux 7.1 reference (drivers/virtio/virtio_input.c, virtio_input.h)
and the proven redox-drm virtio transport. 12 issues were found across
BLOCKER, MAJOR, MINOR, and NIT severity, all fixed in this commit before
runtime testing.
BLOCKERs (would have prevented the driver from working in QEMU):
1. fill_avail() never wrote avail_idx after pushing the 64 ring
entries. The device reads avail_ring[avail_idx % size] to discover
new buffers, so without publishing avail_idx = size, the device
saw avail_idx = 0 and ignored all initial buffers. Fix: explicit
'fence(Release); write_avail_idx(self.size)' with a spec citation.
2. drain() recycled IDs derived from 'last_used_idx - drained_count',
which is wrong when the used ring wraps and a single drain cycle
spans more than one full ring revolution. Fix: collect the actual
drained 'id' values in a stack '[u16; 64]' array during the drain
loop, then push those exact ids back to the avail ring. The
doc-comment explains why the derivation is unsafe.
3. config_read_string() and config_read_bitmap() used
'self.device_cfg.size()' (the MMIO region size = 40) instead of
the device-reported config size from offset 2. Fix: use
'config_read_size()' to read the actual size field.
4. config/redbear-full.toml: device_id_range was a TOML string
('0x1042..=0x107F') but serde's Range<u16> deserializes from a
sequence, not a string. pcid-spawner would have silently failed
to load the fragment. Fix: use serde array form
'device_id_range = [0x1042, 0x107F]'.
MAJORs (silent failure modes or runtime bugs):
5. activate_queue() had no fence between address writes and
'queue_enable = 1'. A CPU write buffer may reorder writes to
distinct MMIO addresses. Fix: explicit 'fence(SeqCst)' with
a comment citing virtio spec 2.8 and Linux's virtio_wmb.
6. No 'reset_device()' on error path after partial init. The device
would be left in ACKNOWLEDGE|DRIVER with no driver active,
requiring a guest reboot to recover. Fix: wrap init in a closure;
any error calls 'transport.reset_device()' before propagating.
7. Drain loop never checked DEVICE_NEEDS_RESET or DEVICE_STATUS_FAILED.
If the device entered an unrecoverable state, the driver would
poll forever with stale state. Fix: 'device_in_error_state()' on
the transport; loop checks it each iteration and exits cleanly.
8. The abs_count probe used 'config_read_size() == 24', which was
always false (virtio_input_absinfo is 20 bytes, not 24). The
count was always logged as 0. Fix: '>= 20' per spec.
MINORs / NITs (hardening, no functional impact):
9. config_read_absinfo() returned AbsInfo without validating
device-reported size. Now returns Option<AbsInfo> and validates
size >= 20.
10. map_cap_region() missing bounds check: capability range may
extend past BAR end (QEMU is permissive; bare-metal is not).
Added 'cap_end > bar_size' check with spec reference.
11. Legacy device 0x1052 entry in pcid fragment caused spurious
spawn + log noise. Removed.
12. notify_queue() error silently dropped with .ok(). Now logs warn
and continues.
Plan update:
The CONSOLE-TO-KDE-DESKTOP-PLAN.md v5.1 changelog now has a new
'9.1.1 Phase 5.1 review-driven fixes' section documenting all 12
findings with file:line, severity, and fix. Future maintainers can
trace the BLOCKERs back to specific commits to understand the
critical-path safety net this review provided.
Verification: cargo check zero errors, 64 warnings (all unused
keycode constants reserved for Phase 5.2 expansion). The driver
is now ready for runtime testing in QEMU.
Add a real, QEMU-targeted virtio-input driver as a new Red Bear recipe at
local/recipes/drivers/virtio-inputd/. The driver handles virtio-input-host-pci,
virtio-input-keyboard, virtio-input-mouse, and virtio-input-tablet devices and
closes Gap #19 of the v5.0 desktop plan.
The driver:
* Walks the PCI capability list to find the modern virtio 1.0 capability
block (common_cfg, notify_cfg, isr_cfg, device_cfg) using MmioRegion
mappings via redox-driver-sys. Rejects legacy virtio-input (device 0x1052)
which lacks the modern transport.
* Negotiates VIRTIO_F_VERSION_1 only (the only required feature).
* Allocates one event virtqueue (size up to 64) backed by four DMA buffers
(desc, avail, used, event_buffers) and pre-fills the avail ring.
* Polls the used ring at 60 Hz, drains completed events, decodes each
virtio_input_event (8-byte type/code/value), and recycles drained buffers
back to the avail ring.
* Translates events to orbclient format and pushes them to inputd via
ProducerHandle (Orbital path):
- EV_KEY -> KeyEvent (with US-QWERTY character mapping)
- EV_REL -> MouseRelativeEvent (REL_X/REL_Y) or ScrollEvent (REL_WHEEL)
- EV_SYN -> dropped (inputd multiplexes)
- Other -> dropped (Phase 5.2 will add evdevd path)
Probe-time checks:
* Vendor 0x1AF4, device_id >= 0x1042, revision >= 1
* Caps include a device_cfg block with virtio type == 18 (virtio_input)
Configuration: a pcid-spawner fragment is added to config/redbear-full.toml
under /etc/pcid.d/virtio-inputd.toml matching class=0x09 vendor=0x1AF4 with
device_id_range 0x1042..=0x107F (and a separate 0x1052 entry that the driver
intentionally rejects).
Verification: cargo check produces 0 errors and 65 warnings, all of which are
unused input-event-codes.h constants reserved for the Phase 5.2 expansion.
Linking the binary requires the Redox cross-toolchain (relibc provides
redox_sys_call_v0); this is provided by the build system, not the host
toolchain.
Plan: this is Phase 5.1 of CONSOLE-TO-KDE-DESKTOP-PLAN.md v5.0. The plan is
updated to v5.1 with: (a) a 'What Changed Since v5.0' section, (b) Gap #19
marked DONE, (c) Phase 5 row marked DONE with sub-task status, (d) Gate E
updated, (e) Input pipeline section updated to reflect the (c) path is now
implemented. Phase 5.2 (evdevd producer path + virtio-snd) is documented as
the next planned work but not yet implemented.
- Complete OHCI 1.0 driver supporting USB 1.1 full/low speed devices
- PCI enumeration via BAR0 MMIO mapping
- HCCA and frame list DMA buffer allocation
- Controller reset and initialization sequence
- Port polling and device enumeration via control transfers
- Root hub port status handling with connect/disconnect detection
- Scheme registration for USB device access (/scheme/usb)
- Full ED/TD structures for control transfers
- OHCI spec-compliant register definitions and timing
Gap 7 (OHCI) from LOWLEVEL plan v1.1
- Complete PCI enumeration (class 0x0C, subclass 0x03, prog-if 0x00)
- I/O port register access (inb/outb style via volatile ptr)
- BAR4: I/O port range for operational registers (USBCMD, USBSTS, etc.)
- MMIO-mapped FLBASEADD for frame list base address
- 1024-entry frame list with QH pointers
- Control QH chain for transfer scheduling
- Full controller reset and initialization sequence
- Port polling with connect/disconnect detection
- Device enumeration via control transfers (GET_DESCRIPTOR, SET_ADDRESS)
- Port reset with proper timing (50ms hold, 10ms settle)
- Transfer descriptor (TD) construction for setup/data/status phases
- Wait-for-completion loop with error detection
- All registers documented in registers.rs per UHCI spec
- Scheme interface for scheme:usb access
Completes the daemon side of the Gap 11 fix from LOWLEVEL plan v1.1.
The kernel exposes /scheme/irq/remapping for the iommu daemon to
control the MSI validation gate (set_iommu_remapping_active in
kernel/src/scheme/irq.rs). This change:
- Adds IommuScheme::has_interrupt_remapping() that returns true once at
least one AMD-Vi or Intel VT-d unit has been initialized.
- Adds set_kernel_remapping(active: bool) helper in main.rs that opens
/scheme/irq/remapping and writes "1" (activate) or "0" (deactivate).
- Calls set_kernel_remapping(true) in the main loop after the first
request that leaves a unit initialized. Idempotent: subsequent writes
are harmless.
- Calls set_kernel_remapping(false) unconditionally on exit so the
kernel does not retain stale state if the daemon terminates.
The write failures are non-fatal: in environments where the scheme is
not available (QEMU without PCI passthrough, very early boot), the
daemon continues and MSI delivery works without remapping, which the
kernel handles correctly via the existing fallback in iommu_validate_msi_irq().
The acpid `_OSI` interceptor was incomplete: firmware that
calls `_OSI("Windows 2015")` or `_OSI("Windows 2020")`
would fall through to the AML interpreter and return 1 (true)
even on systems with `OSI_DISABLE_*` flags set, because
the interceptor only knew about Vista/7/8 strings.
- redox-driver-sys::quirks::AcpiQuirkFlags gains
OSI_DISABLE_WIN10 (bit 14) and OSI_DISABLE_WIN11 (bit 15)
with explicit no-collision guard against the existing
R11/R21 bits (0-13).
- ACPI_FLAG_NAMES in toml_loader.rs maps
`osi_disable_win10` and `osi_disable_win11` to the
new bitflag constants.
- acpid::acpi::AcpiContext::try_intercept_osi now matches
"Windows 2015" → OSI_DISABLE_WIN10 and "Windows 2020"
→ OSI_DISABLE_WIN11, alongside the existing Vista/7/8
string matches.
Source: linux-7.1 drivers/acpi/osi.c (dmi_system_id[] for
Win10/11 laptops that need the kernel to lie about the
host OS to keep ACPI firmware from misbehaving).
cargo test --package redox-driver-sys: 132 passed; 0 failed.
Two findings from the R7 comprehensive review:
1. Boot order race (CRITICAL)
00_driver_manager.service and 00_acpid.service both have the
00_ prefix and no explicit dependency. If driver-manager
enumerates PCI before acpid publishes /scheme/acpi/dmi, every
device gets empty quirk_flags because
redox_driver_sys::quirks::dmi::read_dmi_info() returns Err(())
when the file doesn't exist yet. The OR-accumulation is frozen
at enumeration time so hotplug won't pick up later-published
DMI data.
Fix: add 00_acpid.service to requires_weak for both
00_driver_manager.service (redbear-device-services.toml) and
13_iommu.service (redbear-mini.toml + redbear-full.toml).
2. xHCI typo (CRITICAL)
quirks.d/25-xhci.toml:38 has 'broken_port_pec' which doesn't
exist in the flag name table. The correct flag is
'broken_port_ped' (Port Enabled/Disabled, bit 25 in
XhciControllerQuirkFlags). The typo causes the flag to be
silently dropped at runtime, leaving Intel ICH6 xHCI
(vendor=0x8086, device=0x1E31) without the intended
BROKEN_PORT_PED quirk.
Fix: corrected typo to 'broken_port_ped'.
R12: All 5 ConnectorInfo construction sites (kms/connector.rs
synthetic_displayport, intel/display.rs, intel/mod.rs ..connector
inheritance, virtio/mod.rs both sites, amd/display.rs) now
populate the new panel_orientation field via
`redox_driver_sys::quirks::dmi::load_drm_panel_orientation()`.
The 36 panel orientation rules from 50-drm-panel.toml (Linux
7.1 drm_panel_orientation_quirks.c: Jupiter 0x0B57, Galileo
0x0B47, etc.) now apply to every connector detected.
R13: main.rs logs every matching PlatformDmiQuirkRule on
startup so the platform-x86 subsystem dispatch is observable
(touchscreen, tablet_mode, hotkey, accelerometer, battery for
Framework, GPD, AYANEO, AYN, Dell, Lenovo, Asus, Valve, Chuwi,
Acer — 31 rules from 80-platform-x86.toml).
R21: main.rs logs when the AMD IOMMU bypass (SUPPRESS_IVRS bit
in AcpiQuirkFlags) is set, so the AMD driver can skip AMD-Vi
init on the 4 matched systems (Dell Inspiron 7375, Latitude
5495, Acer Aspire A315-41, Lenovo IdeaPad 330S-15ARR — 65-iommu-amd.toml).
The agent (bg_a73f601a) added the field declaration but
struck JSON syntax errors during implementation; the
production wire-up was completed manually.
cargo check: builds clean (pre-existing E0382 in drivers/fence.rs
test is unrelated).
vasilito
Kellito