Red Bear is a full fork. The canonical recipe for a Red Bear
package lives in local/recipes/<category>/<pkg>/, NOT in
recipes/<category>/<pkg>/. The recipes/ tree is a frozen snapshot
that will eventually be deleted.
Previously the cookbook only walked recipes/, so local/recipes/
recipes were unreachable unless apply-patches.sh created a
symlink in recipes/. That overlay approach was wrong (per the
NO OVERLAY-STYLE PATCHES policy in AGENTS.md).
This change makes the cookbook walk ['local/recipes', 'recipes']
in that order. When a package exists in both trees, the
local/recipes/ path ALWAYS wins. The conflict resolution in
the walker is updated to enforce this rule explicitly.
Result: local/recipes/<pkg>/recipe.toml is discovered directly,
no symlink needed. 'repo find <pkg>' returns the local path.
'repo cook <pkg>' uses the local recipe.
This makes the full-fork model work end-to-end. local/recipes/
no longer needs an apply-patches.sh symlink; the cookbook
discovers it natively.
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.
Red Bear is a full fork, not an overlay. Document explicitly:
- What the policy is
- What the forbidden anti-patterns are (apply-patches.sh symlinks,
recipes/*/source/ symlinks, mixing local/recipes/ edits with
recipes/ patches, etc.)
- How to fork a Redox package correctly (copy to local/recipes/,
edit there, delete the upstream recipe)
- Why this matters (auditability, build determinism, no stolen
upstream changes, CI reproducibility)
- Historical context of why apply-patches.sh and local/patches/
still exist (transitional remnants, historical-only)
Also update the 'How the build system works' diagram to clarify
that the source/ symlink is for core Red Bear forks (kernel,
base, relibc, bootloader, installer) — NOT for recipes. Recipes
have a different model: either fork entirely in local/recipes/ or
coexist in mainline. No symlinks, no overlay.
Also add a row to the 'Common anti-patterns' table listing the four
specific overlay-style mistakes (apply-patches.sh, recipes/ symlinks,
local/recipes/ + recipes/ mix, etc.) so future agents see them
flagged next to the existing 'don't edit source/' and 'don't add
patches' rules.
The user's 'IF YOU DID PATCHES, REDO ALL' was triggered by my adding
mesa to apply-patches.sh. The 450k line deletion was the cost of
the overlay approach breaking. This commit prevents recurrence.
Revert the mesa pointer bump to d73234bf because the underlying
git objects are not reachable from any current repository. The
mesa source directory at recipes/libs/mesa/source was destroyed
mid-task (likely by build-redbear.sh re-creating local/recipes
symlinks), so the .git directory backing the original commit is
gone. Without those objects the new pointer is dangling.
This reverts fd5f84e6c and restores the recipes/libs/mesa/source
pointer to the original recorded value 0ecd6b66c, matching the
pre-task state. The Redox EGL/GBM/virgl fixes that were captured
in fd5f84e6c must be re-derived from the working tree once mesa's
source is re-fetched from the upstream gitlab URL recorded in
recipes/libs/mesa/recipe.toml.
Follow-up: re-create recipes/libs/mesa/source as a real git clone
of https://gitlab.redox-os.org/redox-os/mesa.git at branch
redox-24.0, replay the platform_redox.c / gbm_dri.c /
virgl_screen.c edits plus the include/sys/ioccom.h stub, and
re-cut the pointer bump.
Pick up the mesa fork's 0.2.3 branch HEAD (d73234bf), which rolls
up a set of bounded Redox-targeted changes:
EGL/Redox platform (src/egl/drivers/dri2/platform_redox.c):
real __DRIimageLoaderExtension implementation
(redox_image_get_buffers, redox_hw_flush_front_buffer), front/back
buffer image plumbing on window surfaces, dri_image_back lifecycle
hooked into redox_free_images, visual set from the pbuffer config,
and a redox_probe_device_hw path that publishes the new extension
set. GBM dumb-prime path (src/gbm/backends/dri/gbm_dri.c): fall
back to drmPrimeHandleToFD on the BO handle for get_fd when no
dri image is attached, and reuse that path from get_plane_fd for
plane 0 on dumb BOs. Virgl disk cache (src/gallium/drivers/virgl/virgl_screen.c):
disable the disk shader cache on Redox because the cache init
path goes through build_id_find_nhdr_for_addr -> dl_iterate_phdr
which is not available on Redox. Build environment: add
include/sys/ioccom.h providing BSD-style _IO/_IOR/_IOW/_IOWR
aliases on top of <sys/ioctl.h> for Mesa's DRM uapi headers, and
remove the eight .gitlab-ci/container/patches/build-*.patch
Android/deqp/skqp patches that only apply under Mesa's GitLab
container CI.
Pick up the llvm21 fork's 0.2.3 branch HEAD (1737762446), which
removes the libfbsdvmcore-hacks and lldb-minimize-processes
patches under lldb/test/API/functionalities/postmortem/FreeBSDKernel/tools.
Those are upstream CI patches for LLDB's FreeBSD kernel core-dump
testing infrastructure; they are not part of the upstream test
suite, are not applied anywhere in the build, and are not used
by Red Bear. Removing them keeps the source tree in sync with
what LLDB actually needs to build and prevents future code search
from surfacing them as in-flight Red Bear work.
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.
Pick up the installer fork's 0.2.3 branch HEAD (b85f274), which
comments out the optional ext4-blockdev path dependency. The crate
is resolved via a relative path that traverses the local/recipes
symlink chain, which breaks path resolution on Red Bear. The
installer already talks to ext4 through the rsext4 crate, so the
optional path dep is unused. Cargo.lock is rolled forward so the
transitive windows-sys entries match the rest of the resolver
graph for this snapshot.
Pick up the kernel fork's 0.2.3 branch HEAD (dd72d764), which calls
handles() in smbios_scheme_id() so the SMBIOS scheme id accessor
initializes the scheme namespace handles on demand. This matches
the pattern used by other scheme id accessors and prevents stale
or unset ids from being observed by bootstrap paths that pre-open
the SMBIOS scheme root for userspace.
Pick up the v6.0 stub-fix work that landed on the 0.2.3 branch of
local/sources/base: full input stack (inputd, ps2d, usbhidd,
i2c-hidd, intel-thc-hidd) on the single-producer evdev pipe, full
USB controller daemons (xhcid MSI-X, usbscsid UAS, virtio-netd MAC),
real PHY and link handling for virtio-netd and rtl8168d, MSI-X
plumbing on nvmed and ixgbed, acpid EC/GPE/AML/Notify implementation
plus TOML quirks loaders, pcid multi-bus MCFG enumeration, and
vesad display hand-off to redox-drm/card0 per the NO VESA policy.
The main-repo submodule pointer advances to 0df7977d.
v6.0 collapses the v5.0 dual-path input design (which was never
built) into a single-producer evdev pipe:
drivers → /scheme/input/evdev (inputd ring buffer)
→ evdevd consumer
→ /dev/input/eventN
→ libinput
Phase 1.1b (inputd scheme daemon) is now real. All five input
drivers + virtio-inputd already use EvdevProducerHandle. The
init system wires evdevd in. Plan status for Phase 1: 8 of 9
steps code-complete; only Step 1.9 (udev-shim eventN mapping
verification) and runtime gate (QEMU boot test) remain.
Also records the small fixes this session: Gap 3 (renderD128
openat path), Gap 5 (host->guest resize events, pre-existing),
Gap 8 (atomic_check connector validation), Phase 3.5 (page
flip keeps DRM fd open), the redox-drm dangling symlink, and
the build-redbear.sh aggressive cache-nuke fix.
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.
Previously, when relibc/kernel/base/bootloader/installer had commits
newer than their pkgar, the script set NO_CACHE=1, which ran
'make repo_clean' and deleted the entire repo/ directory. This
forced rebuilding the full mesa/llvm21/qt6/kwin stack on every
base source change — adding 30+ minutes of wasted work to every
mini build.
Now we only delete the specific stale package's pkgar and target
dir. The cookbook rebuilds that package; downstream packages pick
up the new relibc/kernel/base via their own dependency tracking
without invalidating the rest of the repo. This is the primary
fix for the 'forever build' complaint: base source changes no
longer trigger a full mesa/llvm rebuild.
Gap 5: virtio IRQ handler at virtio/mod.rs:366-403 already reads
VIRTIO_GPU_EVENT_DISPLAY and calls refresh_connectors. Scheme layer
queues the hotplug event so userspace libdrm clients get notified.
Gap 8: atomic_check now validates connectors via the
available_connectors parameter — fixed in commit 32993a9ee.
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.
- STUBS-AUDIT-AND-REWRITE-PLAN.md: master plan, 20 drivers audited
- USB-STUBS-AUDIT.md: USB stack focus, xhcid/usbhubd/usbctl/usbhidd/usbscsid/ucsid
- HID-STUBS-AUDIT.md: HID focus, usbhidd/i2c-hidd/intel-thc-hidd/ps2d/inputd/evdevd
- LOWLEVEL-STUBS-AUDIT.md: ACPI/PCI/IRQ/IOMMU/boot/init, 50+ row coverage
- BOOT-AND-HW-ENABLEMENT-ASSESSMENT.md: kernel to display chain, NO VESA policy
- DESKTOP-SERVICES-ASSESSMENT.md: D-Bus, session, audio, network
- CONFIG-AND-INIT-ASSESSMENT.md: configs, init.d, recipes, layering
- GPU-MESA-KDE-CHAIN-ASSESSMENT.md: Mesa to Plasma build chain
These documents track the v6.0 stub-fix campaign and the comprehensive
Phase 1-5 implementation work. All cited paths and line numbers are
real. Documents are durable in local/docs/ which survives make distclean.
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 initfs already starts inputd (in phase 1) and registers the
'scheme input/evdev'. The rootfs 29_activate_console.service was
calling 'inputd -A 2' from minimal.toml, which the v6.0 inputd
binary does not accept (no -A flag; v6.0 inputd is a pure scheme
daemon that registers the single-producer evdev ring buffer).
Override the rootfs service with a no-op ('true') that satisfies
the unit dependency chain without re-spawning inputd. The actual
input pipeline (drivers writing Linux evdev, evdevd reading from
the scheme, libinput/KWin consuming /dev/input/eventN) works
without this redundant rootfs invocation.
The v6.0 single-producer input architecture registers the input
producer scheme as 'input/evdev' (not the legacy 'input' scheme).
Without this update, the initfs would try to register 'input' but
the inputd binary would attempt to register 'input/evdev' — leading
to a 'scheme already registered' error or a missing scheme entirely.
Also update the description to reflect the v6.0 role: pure evdev
ring buffer (not the legacy VT input and graphics multiplexer).
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.
llvm21 is a Mesa (graphics) build dep used by mesa and libepoxy for
shader compilation. It is NOT required for the redbear-mini or
redbear-grub text-only targets, but the pre-cook list was cooking
it unconditionally, adding a 30+ minute stall to every mini build.
Pre-cook only relibc + icu for mini/grub. The full desktop chain
(including llvm21) is still pre-cooked for redbear-full.
vasilito
Vasili