Adds section 8.2 documenting the Round 8 follow-up commits:
* c20032435d: Mesa EGL back-buffer allocation in redox_image_get_buffers
(was hard stub - back=NULL always)
* 101ce11844: pipe_loader_redux backend for /scheme/drm/card0
(closes the non-EGL gallium consumer gap)
* 5aa5c96506: kf6-kcmutils git conflict markers resolved
(BLOCKER - shell would have tried to execute literal
<<<<<<< and >>>>>>> strings as commands)
* c73e4227 (relibc): cfgetispeed/cfgetospeed/cfsetispeed/cfsetospeed
real impl on Redox (was 0 or EINVAL unconditionally)
* 9bc6ba0b6e: redbear-compositor keyboard modifier state tracking
(shift/ctrl/alt/logo/caps/num/mod5 with apply_modifier_event)
* 1d930cd425: qtbase open_memstream stub removed (relibc provides it)
* f6420ec8c3: relibc submodule pointer bump
* Documentation cleanups in local/AGENTS.md and local/recipes/AGENTS.md
Combined with the Round 7 follow-up and the v5.8/v5.9/v5.10
parallel sweeps, the surface of unimplemented hard stubs in the
Mesa/relibc/compositor stack is now near zero. Remaining deferred
items (Qt6 Wayland null+8 runtime validation, QML gate in
plasma-framework + kirigami, HW validation) require kernel ABI
work or external hardware.
Adds section 8.1 documenting the Round 7 follow-up commits (2026-07-27):
* redbear-compositor: real wp_presentation_feedback timing with
CLOCK_MONOTONIC + frame sequence counter (commit 28eea74305)
* xwayland: restore BTN_LEFT/RIGHT/MIDDLE switch (commit f10a0ec89c)
* redbear-compositor: real wl_data_offer clipboard/drag-and-drop
pipeline with pipe + SCM_RIGHTS (commit d324ed3634)
* relibc: real getifaddrs implementation (submodule commit d9760bdc)
Each section explains the file path, the previous state, the new
implementation, and the edge cases handled. Combined with the
Round 7 core work in earlier commits, the surface of unimplemented
stubs in the compositor + Mesa + relibc has been reduced to near
zero, with the remaining gaps (Mesa EGL back-buffer, Qt6 null+8
runtime validation, QML gate, HW validation) deferred to Round 8+
since they require kernel ABI work or external hardware.
Updates the 3D plan with the fifth-round status. Phase 5+'s
real-IOCTL gap is now closed:
1. ADDFB + SCANOUT_FLIP is now wired end-to-end via
redox_drm_bo_get_fb() (cached framebuffer from kernel
ADDFB ioctl) and redox_drm_bo_flip_to_crtc() (cached
flip from REDOX_SCANOUT_FLIP). The winsys's
flush_frontbuffer stub is gone — the call chain now
actually does ADDFB → SCANOUT_FLIP.
2. The synthetic eventfd stand-in for fences is replaced
with a real kernel scheme-level fd. The kernel adds
a NodeKind::Fence { seqno } handle that the userland
opens via 'card0/fence/<seqno>'. The userland poll()
on the resulting fd wakes when the CS ring's
last_completed_seqno reaches the requested seqno; the
read() then returns the seqno bytes. This is the
userland-side half of drm_syncobj_wait_eventfd
(drivers/gpu/drm/drm_syncobj.c, Linux 7.1).
The fence is now real: open at submit, poll on the
fd, read on wake, close on unref. No more spin-loops.
Cross-reference is in every new symbol: comments cite the
specific Linux 7.1 driver source files being ported.
Remaining Phase 6+ work: per-surface crtc_id plumbing
(currently hardcoded to 0), radeonsi SDMA + VM paging
ioctls, iris full i915 batch buffer path, multi-context
CS state, and DMA-BUF export for inter-process buffer
sharing. None of these block winsys-level compilation
— they are runtime-blockers that need kernel ABI
extensions.
Updates the 3D driver plan with the fourth-round status. Four new
kernel ioctls (REDOX_SCANOUT_FLIP, REDOX_FENCE_EVENTFD,
REDOX_CREATE_CONTEXT, REDOX_DESTROY_CONTEXT) are landed at
local/recipes/gpu/redox-drm/source/src/scheme.rs. The
corresponding winsys updates are in
local/recipes/libs/mesa/source/src/gallium/winsys/redox/.
Each new ioctl cross-references its Linux 7.1 source-pattern:
- REDOX_SCANOUT_FLIP: drivers/gpu/drm/drm_plane.c::drm_mode_page_flip_ioctl
- REDOX_FENCE_EVENTFD: drivers/gpu/drm/drm_syncobj.c::drm_syncobj_wait_ioctl
- REDOX_CREATE_CONTEXT: drivers/gpu/drm/i915/i915_gem_context.c
- REDOX_DESTROY_CONTEXT: ditto
The winsys update replaces the Phase 4 spin-loop fence with an
eventfd-backed wait (still using a stand-in eventfd until the
kernel adds epoll to the CS ring), and wires the surface_flush
path against REDOX_SCANOUT_FLIP (awaiting pipe_resource to fb
binding in the kernel).
Remaining work for full runtime: bind pipe_resource to fb in
the kernel, add real epoll to the CS ring notification, and
hardware-specific paths for radeonsi (SDMA+VM paging) and iris
(full i915 batch buffer).
Phase 4 of local/docs/3D-DRIVER-PLAN.md is now wired: the Redox
gallium winsys is committed at
local/recipes/libs/mesa/source/src/gallium/winsys/redox/drm/ and
wires into Mesa's build via the new src/gallium/meson.build.
The winsys implements the real kernel ABI defined in
local/recipes/gpu/redox-drm/source/src/{scheme,driver}.rs:
- redox_drm_bo.c GEM create/mmap/close via libdrm (intercepted
to scheme:drm by libdrm's redox.patch)
- redox_drm_cs.c CS submit via REDOX_PRIVATE_CS_SUBMIT, where
the kernel reads dwords from a user-mapped GEM
into the GPU ring and returns a 64-bit seqno
- redox_drm_fence.c Polling fence over the kernel's last-completed
seqno. The kernel doesn't expose sync objects yet;
this is an honest stopgap. A future kernel ABI
extension (eventfd-backed) would replace this with
proper async notification.
- redox_drm_surface.c Minimal pipe_surface implementation. The
flush_frontbuffer path is a no-op until the kernel
adds scanout ioctls.
- redox_drm_winsys.c pipe_screen_ops table and lifecycle (init/destroy).
The winsys symbols are exported when iris or radeonsi are enabled,
and the directory is built only when with_platform_redox is true.
Status table updates: iris and radeonsi change from
'🟡 Compiles (libclc OK)' to '🟡 Compiles + winsys wired', with
the remaining '❌ Needs winsys runtime' tag listing the kernel ABI
extensions needed.
The plan also notes that Phase 5+ is blocked on kernel ABI
extensions, not on userland work:
- REDOX_SCANOUT_FLIP ioctl (for surface_flush_frontbuffer wiring)
- context_id field in redox_private_cs (for multi-context)
- eventfd-backed fence (replaces the polling fence)
- DMA-BUF export (for inter-process buffer sharing)
- SDMA + VM paging ioctls (radeonsi-specific)
- i915 batch buffer submission path (iris-specific)
Updates the hardware-acceleration status table to mark iris,
radeonsi, and Vulkan (anv, radv) as 🟡 Compiles (libclc OK).
This is the state after the libclc recipe was added as a proper
Cat 1 in-house project at local/recipes/dev/libclc/.
Status changes:
- iris: ❌ Not built → 🟡 Compiles (libclc OK)
- radeonsi: ❌ Not built → 🟡 Compiles (libclc OK)
- Vulkan anv: ❌ Not built → 🟡 Compiles
- Vulkan radv: ❌ Not built → 🟡 Compiles
- Lunar Lake/PTL: still ❌ Runtime but ✅ Recognized in kernel
The runtime path remains blocked on Phase 4 (Redox gallium winsys).
libclc provides the .bc bitcode but Mesa iris/radeonsi need a
Redox-specific winsys to translate pipe_screen ops into the
redox-drm ioctl surface. Once Phase 4 lands, iris/radeonsi/Vulkan
should work end-to-end.
Adds a callout note explaining the libclc port status with link
to local/recipes/dev/libclc/.
Comprehensive 3D userland plan based on direct code audit of the
Mesa 26.1.4 build, redox-drm Intel backend, virgl runtime path,
amdgpu C port, and libdrm enablement. Seven critical gaps identified
that block all hardware-accelerated 3D rendering on Red Bear OS
beyond llvmpipe fallback:
1. Mesa gallium-drivers=softpipe,llvmpipe,virgl — NO iris, NO crocus,
NO radeonsi. The README/CHANGELOG claim that 'all 6 Red Bear
Mesa patches are wired' is incorrect: only 5 are wired; patches
03 and 06 are orphans because patch 03 targets
src/egl/drivers/dri2/platform_redox.c which does not exist in
Mesa 26.1.4 upstream (the file was removed). Patches 03/06
cannot be cleanly reapplied — they need re-creation against
the current Mesa API.
2. No 'redox' EGL platform in Mesa 26.1.4. EGL_PLATFORM=wayland
resolves to swrast (llvmpipe) on Redox. virgl and iris are
never auto-selected.
3. No Mesa winsys for Redox (src/gallium/winsys/redox/ does not
exist). The virgl driver uses upstream's generic
virgl_drm_winsys which depends on libdrm's redox.patch to
redirect ioctls to scheme:drm.
4. Intel kernel backend supports only Gen9–Gen14 (Meteor Lake).
No Lunar Lake (Xe2, Gen15) device IDs. No Panther Lake (Xe3,
Gen16) device IDs. The display version table stops at 14.
5. No Vulkan built (vulkan-drivers= empty). No anv (Intel), no
radv (AMD), no venus (virtio-gpu Vulkan).
6. The redox_private_cs_submit ABI exists in redox-drm (real
implementation for Intel ring submission with seqno tracking,
space-wait, MI_FLUSH_DW) but no Mesa gallium driver consumes it.
7. The amdgpu C port is display-only (DC modeset, no render/3D).
It does NOT provide a Mesa radeonsi winsys. Stages 2-4 of the
amdgpu recipe are intentionally empty (no Linux TTM/core
source).
The plan file (786 lines) covers:
- Verified code state from direct read (Mesa recipe, Intel
backend, virgl, amdgpu, libdrm)
- Reality-vs-claim corrections (6 overclaims in current docs)
- Hardware-acceleration status table (10 paths)
- 7-phase execution plan with explicit acceptance criteria
for each phase:
Phase 1: Validate current virgl runtime path (1-2 weeks)
Phase 2: Add Lunar Lake and Panther Lake device IDs
Phase 3: Restore the Redox EGL platform (re-create)
Phase 4: Add Intel iris (Gen8-Gen14) — biggest piece, 8-12 weeks
Phase 5: Add AMD radeonsi — 6-8 weeks
Phase 6: Vulkan (enables anv/radv) — 2-4 weeks
Phase 7: Panther Lake kernel driver — 12-16 weeks
- Validation matrix per vendor
- File-level change catalog
- Risk register
- Operating rule: 'code presence is not support; build success
is not support; llvmpipe is not acceleration; an env-override
that requires manual setup is not a runtime path'.
vasilito