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.
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 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.
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 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.
- 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
- Changed make all -> make live to produce .iso files
- Skipped verify-overlay-integrity.sh (corrupts recipe symlinks)
- Added ac_cv_namespace_ok=yes to ICU recipe (toolchain libstdc++ stale)
- Fixed variable reference
- Mini ISO builds successfully via the script
Three fixes for the KWin DRM device discovery failure:
1. drm_scheme_ready(): replace head -c 1 with exec 3< open test.
Reading from a DRM scheme fd blocks because the scheme expects
ioctl-style request/response, not streaming reads. Use open()
success as the scheme availability probe instead.
2. ConsoleKitSession::create(): return nullptr immediately.
The D-Bus isServiceRegistered() call can block indefinitely when
the bus daemon doesn't fully implement org.freedesktop.DBus.
With both LogindSession and ConsoleKitSession returning nullptr,
Session::create() falls through to NoopSession which uses plain
open() for DRM device access.
3. Boot chain deps: redox-drm depends on driver-manager,
greeter depends on evdevd (keyboard/mouse ready before login).
Also includes: KF6 CMake build fixes, Qt6 platform patches,
libdrm Redox ioctl shim, and wayland.toml scheme check fix.
The cookbook resolves patch paths from recipe.dir which is the symlink
path (recipes/libs/libdrm/), not the physical path (local/recipes/).
Fix ../../../patches/libdrm/ → ../../../local/patches/libdrm/ to
match the convention used by kernel, base, relibc, and other recipes.
Add #ifdef __redox__ path to drmGetDeviceFromDevId() that mirrors the
working drmGetDevice2() Redox implementation. On Redox there is no
/dev/dri/ directory — DRM devices are accessed via /scheme/drm/card0.
The patch constructs a drmDevice with both PRIMARY and RENDER nodes
pointing to /scheme/drm/card0, since the redox-drm scheme serves both
roles through a single endpoint.
Also fixes drmParseSubsystemType() to return DRM_BUS_PCI on Redox.
Fix P3 patch paths (strip local/recipes/libs/libdrm/source/ prefix
from diff headers so patches apply correctly during repo fetch).
Wire P1/P2 patches into recipe.toml. Source reflects the full ioctl bridge\nrewrite: VirtGPU NR mappings, EXECBUFFER/GET_CAPS special handlers,\nPCI info bridge for drmGetDevice2, and removal of the old per-ioctl C\nhandler functions in favor of unified redox_drm_simple_ioctl() dispatch.
vasilito