rtcd: syscall::openat(0, '/scheme/sys/update_time_offset') used fd 0
(stdin) instead of the namespace fd, causing EACCES. Fixed by using
libredox::call::getns().
acpid: AmlPhysMemHandler captured pci_fd at construction as
Arc<Option<Fd>>, so after set_pci_fd() stored the fd, the handler
never saw it. Changed to Arc<RwLock<Option<Fd>>> shared between
AcpiContext and the handler.
Base fork commits: 770694d0 (rtcd), 84573feb (acpid)
The cub AUR→RBPKGBUILD→recipe.toml conversion pipeline (located at
local/recipes/system/cub/source/) was assessed end-to-end against
12 representative real-world PKGBUILDs:
- libevdev (simple meson)
- fd-find (cargo)
- libpciaccess 0.18.1 (meson)
- fmt (cmake)
- wlroots-git (git source, complex deps)
- libpciaccess 0.19 (extra/-style, meson + ninja)
- ffmpeg (configure + options)
- mesa 24.3 (git+url + multi-source + pkgver())
- gzip (configure + git source + check)
- zlib (simple C, configure)
- openssl (pkgbase split package)
- glib2 (complex deps, real-world)
The assessment found 8 critical bugs that would prevent cub from
producing working Red Bear recipes for any real Arch package. 7 of
the 8 bugs were fixed in the previous commit (7c5b1f36e); the 8th
(custom-template recipes lack DYNAMIC_INIT and cookbook_apply_patches
boilerplate) is deferred as a cookbook-integration concern.
This commit adds two artifacts of the assessment:
1. local/docs/cub-assessment-and-improvement-plan.md (508 lines,
~28KB): the complete assessment document. Sections:
- Executive summary (architecture decision + 8-bug verdict)
- What cub does well (10+ working cases)
- The 8 bugs (location, severity, root cause, fix)
- Test methodology
- Test cases by category (A: conversion success, B: dep mapping,
C: source URL, D: build template, E: edge cases, F: validation)
- Forward improvement plan (16 items in 4 tiers)
- Appendix A: cub architecture map (CLI + 17 modules)
- Appendix B: RBPKGBUILD format spec
- Appendix C: Generated recipe format vs. real Red Bear recipe
2. local/recipes/system/cub/source/cub-assessment/:
a 12-PKGBUILD integration test harness. A standalone binary that
exercises the conversion pipeline on each PKGBUILD and reports
status, warnings, action_items, recipe validity (TOML), and the
first 30 lines of the generated recipe. Used to verify the bug
fixes in 7c5b1f36e — all 12 cases convert successfully
post-fix, including the previously-erroring mesa 24.3 (which
now produces a valid recipe with a multi-source warning).
The test harness lives next to the cub source (cub-assessment/) and
has its own Cargo.toml with [workspace] empty so it doesn't join the
cub workspace. Build/run with:
cd local/recipes/system/cub/source
cargo run --manifest-path cub-assessment/Cargo.toml
The harness is intended for use by future cub maintainers to catch
regressions. It's not wired into CI yet — that would be a separate
task.
This is the final cleanup batch for the Rule 2 big-project migration
work (pipewire, wireplumber, mesa, libdrm all migrated to upstream git
+ external patches in local/patches/<component>/).
Changes:
* local/recipes/libs/libdrm/recipe.toml: upgrade from
template = 'meson' + mesonflags to template = 'custom' +
DYNAMIC_INIT + cookbook_apply_patches + cookbook_meson. This
matches the structural pattern used by the other 3 Rule 2
migration recipes (mesa, pipewire, wireplumber) and gives libdrm
the same flexible shell-script build context for future
cross-compilation tweaks. Adds build dependencies expat,
libpciaccess, meson, ninja-build, pkgconf (the meson template
had these implicit; the custom template requires them explicit).
Patch application still goes through cookbook_apply_patches
(4 dots from local/recipes/libs/libdrm/ to project root).
* local/recipes/AGENTS.md: catalog update reflecting the libdrm
template change (now 'custom' instead of 'meson') and adding
catalog entries for 4 recipes that were created during this
migration round but were missing from the catalog: libxkbcommon,
pam-redbear, pipewire, wireplumber.
* sources/redbear-0.1.0/manifest.json: add a new manifest entry
for 'libs/libdrm' (the historical 0.1.0 archive entry for libdrm,
which uses the patched tarball). This mirrors the existing
'lib/libdrm' entry and gives 'repo restore' a consistent way to
recover the libdrm source from the 0.1.0 release archive.
* Doc updates: AGENTS.md, README.md, local/AGENTS.md,
local/docs/CONSOLE-TO-KDE-DESKTOP-PLAN.md, local/docs/GPU-MESA-
KDE-CHAIN-ASSESSMENT.md, local/recipes/AGENTS.md: bring the
docs in line with the Rule 2 policy and the 4-migration set
(pipewire, wireplumber, mesa, libdrm). Most are catalog or
cross-reference updates.
* local/docs/STUBS-FIX-PROGRESS.md: heavily trimmed (-303 net).
The old document was tracking 346+ stub fixes from earlier
sessions; most of those are now closed and the document has
been condensed to the current state.
* local/docs/SOURCE-OWNERSHIP-MODEL.md: deleted (-89 lines).
This old doc described a 'source ownership' concept that has
been superseded by the amended AGENTS.md Rule 2 (NO OVERLAY-
STYLE PATCHES — SCOPED POLICY) section, which is the canonical
source-ownership model going forward.
Captures the QEMU boot of the redbear-full target after the
VIRTIO_BLK_F_RO read-only fix landed in local/sources/base (commit
cffacf591 virtio-blkd: handle read-only drives gracefully). The
boot now proceeds past the previously-fatal virtio-blkd
assert_eq!(*status, 0) abort and continues through the rest of
the desktop init path, validating the fix end-to-end on the
desktop target.
The pre-fix pair is committed in the previous commit; keeping
pre/post pairs adjacent in main-repo history makes the regression
test reproducible from git alone without having to look up
when each log was captured.
Captured log: 16 893 bytes, 204 lines, same scope as the
pre-fix capture (q35 + OVMF, KVM, virtio-blk readonly ISO).
Marked-up analysis: REDBEAR-FULL-BOOT-POST-VIRTIO-BLKD-FIX-RESULTS.md
documents which init stages now reach the login prompt, which
drivers register, and what the next blocking stage is.
Captures the 300s extended QEMU boot of the redbear-full target
that exposed the virtio-blkd read-only assert. Boot progressed
through:
* PCI enumeration, pcid-spawner bring-up
* nvmed multi-queue registration
* virtio-blkd bring-up (READONLY boot ISO attached)
* ahcid probe
then panicked inside virtio-blkd during a write to the boot
drive. The ISO is attached with readonly=on (per the launcher
contract to protect the build artifact), and the driver received
VIRTIO_BLK_S_IOERR (status = 1) on what it expected to be a
writable block device; the assert_eq!(*status, 0) on line 70 of
drivers/storage/virtio-blkd/src/scheme.rs aborted the daemon.
The kernel caught the user-space invalid-opcode fault from the
aborted daemon and reported UNHANDLED EXCEPTION, CPU #0, PID 19
on the virtio-blkd scheme. Captured log is 16 893 bytes / 204
lines; the marked-up analysis (REDBEAR-FULL-BOOT-EXTENDED-RESULTS.md)
identifies the root cause and the missing VIRTIO_BLK_F_RO feature
negotiation that the follow-up commit in local/sources/base adds.
These two files are the only stable record of the pre-fix
behaviour; without them the regression test for the read-only
fix has no baseline. Both files are markdown + plain serial
console capture (no binary artifacts) and are safe to commit.
The post-fix pair (REDBEAR-FULL-BOOT-POST-VIRTIO-BLKD-FIX-RESULTS.md
+ redbear-full-boot-post-virtio-blkd-fix-20260609-181340.log)
are intentionally split into a separate commit so the pre- and
post-fix captures stay paired to their corresponding source
changes.
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 QEMU boot test results captured on 2026-06-09 from
test-redbear-full-qemu.sh. Two terminal captures (75 s and a longer
~2-min run) accompany the analysis document. The captures and the
analysis document the boot chain for the redbear-full target on
QEMU virtio-gpu, including the relationship to the redbear-mini
reference log.
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.
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.
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.
- 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.
After review push-back on the dual-path (orbclient + evdev) input
architecture, the v6.0 plan is simplified to a single evdev producer
model. The user committed: 'we do not use Orbital and do not plan to
use it. we aim for wayland/kde.'
The dual-path was rejected for:
- Doubling every driver's event-write code
- Doubling per-event syscall cost
- Out-of-order risk between the two producers
- Translating back and forth loses metadata
- No desktop consumer actually needs Orbital
The corrected architecture:
Hardware
-> single /scheme/input/evdev producer (Linux struct input_event)
-> evdevd (pure scheme->/dev/input/eventN adapter)
-> /dev/input/eventN
-> libinput in-process to KWin (user session)
-> libinput in-process to redbear-compositor (greeter)
-> direct evdev fd (Qt6 apps that need raw access)
inputd is deprecated for the desktop config. It stays in the tree
only as a historical daemon.
What this changes:
1. Phase 1 effort drops from 1-2 weeks to 1 week
2. Drivers change ONCE (replace ProducerHandle with
EvdevProducerHandle) instead of dual-writing
3. evdevd refactor is now cleaner: just switch its consumer from
/scheme/input/consumer (orbclient) to /scheme/input/evdev
(Linux evdev)
4. inputd/src/lib.rs gains a new EvdevProducerHandle, EvdevEvent,
keycodes module — committed in the base fork first
Plan updates:
- Section 2 (Unified Input Architecture) rewritten to 'Single-Producer
Input Architecture'
- Critical path Phase 1 row updated to reflect 1-week effort
- Executive summary text updated
- 'Two Architecture Decisions Resolved' updated to reflect
Orbital-out decision
This is a full v6.0 rewrite of the desktop plan, produced after:
1. Booting CachyOS desktop ISO (cachyos-desktop-260426.iso, 2.9GB) in QEMU
11.0.0 to establish the reference baseline.
2. Six parallel research agents that audited the full Red Bear stack
against the CachyOS reference and Linux 7.1 kernel source.
3. Resolution of two architectural questions that v5.x punted on.
Two non-negotiable architecture decisions (v6.0):
A. UNIFIED INPUT ARCHITECTURE: every input driver writes to BOTH
/scheme/input/orbclient (for Orbital) and /scheme/input/evdev (for
KWin + libinput). No more inputd <-> evdevd bridge that loses
metadata (timestamps, axis ranges, vendor IDs, SYN_REPORT).
Matches CachyOS/Linux: one kernel-evdev path, all consumers
read from it.
B. KWIN IS THE PRIMARY COMPOSITOR: redbear-compositor (788-line
Rust) is too small to reach production parity with KWin in any
realistic timeframe. KWin is used for the user session;
redbear-compositor hosts only the greeter (minimal xdg-shell +
wl_keyboard events are still needed for the greeter to function).
Critical path rework (v6.0):
- Phase 0: QML JIT gate (4-6 weeks) — moves to pre-flight because
it blocks 12 KF6 packages and KWin. Without QML, no Plasma.
- Phase 1: Unified input (1-2 weeks) — resolves the inputd/evdevd
proliferation.
- Phase 2: DRM atomic modeset + render node + PRIME real FDs +
RESOURCE_MAP_BLOB (2-3 weeks).
- Phase 3: Mesa EGL Wayland fix (1 week).
- Phase 4: Compositor greeter — redbear-compositor adds
xdg-shell + wl_keyboard events (2-3 weeks).
- Phase 5: KWin real build (2-4 weeks).
- Phase 6: PipeWire + wireplumber + audiod bridge (6-8 weeks).
- Phase 7: Plasma shell (4-6 weeks).
- Phase 8: QEMU E2E validation (1-2 weeks).
- Phase 9: Intel ARC track (parallel) (12-20 weeks).
Coverage inventory (v6.0):
237 components audited across 14 categories.
86 real (36%), 41 partial (17%), 110 missing (46%).
Detailed gap matrix in §8.
Intel ARC support:
Added as Phase 9 parallel track — requires Mesa iris + Xe driver
cross-compile + real hardware validation.
Total: 22-32 weeks to functional software-rendered KDE Plasma
Wayland desktop on QEMU. +4-8 weeks for Mesa virgl. +12-20 weeks
for real Intel ARC hardware.
This supersedes v5.0 and v5.1 in full. The v5.x changelog sections
(§9, §9.1, §9.1.1) are retained as historical record.
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.
Major revision: replaces v4.1 with a code-grounded audit where every claim
is verified by direct source inspection. Corrects several false claims
in v4.1 and adds an honest gap matrix grounded in a live CachyOS
desktop ISO booted in QEMU 11.0 as the functional reference.
Corrections to v4.1:
- audiod EXISTS at local/sources/base/audiod/ (real implementation,
277 lines, mixer with volume control and HANDLE_BUFFER_SIZE=4096)
- redbear-input-headers EXISTS at local/recipes/drivers/redbear-input-headers/
(recipe.toml + source/include/linux/linux/ with input.h, uinput.h)
- inputd is a real producer/consumer multiplexer, not a stub
- synthetic_edid() is not a stub — generates valid 1920x1080@60Hz EDID
with correct checksum
- The Mesa LDFLAGS -lorbital link is the real EGL path issue, not
'EGL works'
New v5.0 findings (not in v4.1):
- ATOMIC ioctl in redox-drm passes empty connectors to set_crtc
(showstopper, scheme.rs:1733)
- No render node (renderD128) — Wayland compositors need this
- PRIME export uses in-memory token, not real DMA-BUF FD — blocks Mesa
- No VIRTIO_GPU_CMD_RESOURCE_MAP_BLOB handler
- No host→guest resize notification processing in IRQ handler
- libdrm missing DRM lease ioctls
- redbear-compositor missing xdg-shell, zwp_linux_dmabuf, wp_presentation,
zwp_linux_explicit_synchronization (showstoppers for modern Wayland)
- redbear-compositor page flip reopens DRM fd every call
- usbhidd/ps2d send to inputd (Orbital path) not to evdevd
- evdevd not in init system of redbear-full
- No virtio-input or virtio-snd drivers (QEMU specific)
Critical path to functional QEMU Wayland desktop (12 weeks, no hardware):
Phase 1: Fix DRM atomic modeset (2-3 weeks)
Phase 2: Fix Mesa EGL Wayland (1 week)
Phase 3: Add compositor protocols xdg-shell + dmabuf + presentation (2-3 weeks)
Phase 4: Wire input pipeline to compositor (1-2 weeks)
Phase 5: Add virtio-input + virtio-snd drivers (1-2 weeks)
Phase 6: QEMU end-to-end validation vs CachyOS (1 week)
Total to software-rendered Wayland desktop on QEMU: 12 weeks.
Total to software-rendered KDE Plasma (QML gate): 18 weeks.
Total to hardware-accelerated QEMU desktop (Mesa virgl): 22 weeks.
Total to real AMD/Intel GPU: 42 weeks (requires hardware).
Cross-referenced every stub/gap claim in v1.0 against actual code and
Linux 7.1 reference (local/reference/linux-7.1/). Four parallel audits.
Key corrections to v1.0:
- kernel/src/arch/x86_shared/sleep.rs:257-276 does NOT exist; real PCI
stubs are in acpid/aml_physmem.rs:375-398 (root cause: pcid never
sends fd to acpid)
- EHCI is ALREADY implemented (1538+ lines); the stubs are OHCI and UHCI
- aml_physmem.rs:195, :274 line numbers were wrong; actual stubs at
:213-232 (map_physical_region panic) and :241-280 (read returns 0)
- MSI stub at irq.rs:231 was fixed 2026-06-08 (this audit's first task)
New gaps added (v1.1):
- Gap 11: IOMMU daemon->kernel IRQ integration missing (kernel has
set_iommu_remapping_active() but daemon never calls it)
- Gap 12: MSI multi-vector not exposed (blocks xhcid, nvmed, ixgbed,
redox-drm)
Other corrections:
- DMAR init should move to iommu daemon, not acpid
- >255 CPU ID is a panic (u8::try_from().expect()), not deferred
- hwd legacy backend stub is acceptable (graceful no-op fallback)
Added new sections:
- Section 13: Concrete Fix List (v1.1, ready to execute) with exact
file paths, line numbers, current code, target code, Linux reference
- Section 14: v1.1 Audit Methodology documenting the cross-reference
approach
All execution plan phases updated with corrected tasks, owners, and
verification gates.
Comprehensive 6-tier plan to address the 1.5h full-rebuild pathology
when making small config changes. Covers content-hash output
fingerprinting, per-crate granularity, public API surface tracking,
restat / equivalence caching, and developer-experience tools.
Synthesizes techniques from Nix, Buildroot, Yocto, GN/Ninja, Cargo,
and Bazel adapted to Red Bear OS's Rust cookbook.
Triggered by: 2-line edit to local/sources/base/Cargo.toml caused
1.5h full rebuild of redbear-mini. Root cause: cookbook tracks at
recipe granularity (one stage.pkgar for 45-member Cargo workspace)
instead of crate granularity.
Documents the two R7 audit findings and the comprehensive plan to
fully utilize the R0-R22 quirks-and-bugs subsystem.
Findings
- cb_intel_ntb_bar_fix was a no-op stub (cleared PCI_COMMAND_MEMORY
and restored it; the device never observed the transient clear).
Replaced with the real Linux quirk_intel_ntb reads at config
offsets 0xD0 and 0xD1. 3 new unit tests. 131/131 redox-driver-sys
tests pass.
- redbear-quirks install script copied only 8 of 30 TOML files,
leaving all R11-R21 data tables inert at runtime. Replaced the
explicit list with a glob.
Utilization plan
- Audit of every other cb_* callback (all justified, no other stubs).
- Full consumer-wiring matrix showing what's wired, what's not, and
the concrete step for each pending consumer.
- Initialization-path wiring from bootloader SMBIOS through kernel
to acpid/pcid/xhcid/usbhidd/evdevd/network/storage/audio/drm.
- 15-task implementation order with estimates (22-32 days sequential,
parallelizable to 2-3 devs in 4-6 weeks).
- Updated test count: 131 host-buildable redox-driver-sys + 13 acpid
dmi + 12 pcid + 7 usbhidd + 4 evdevd + 3 iwlwifi = 170 total.
After the 15 tasks land, every lookup function in redox-driver-sys
has at least one production consumer; the data tables drive real
kernel/userspace behavior; and the R0-R22 infrastructure is fully
automatically made to work on real hardware.
The previous count of 161 in the doc was an error
caused by summing test counts from different build
contexts (host-buildable redox-driver-sys + target
test-runs in consumer trees). The correct counts:
- 128 host-buildable unit tests in redox-driver-sys
(Linux source-of-truth conventions; can run on
any dev machine)
- 13 dmi unit tests in acpid (target-only)
- 12 quirks.rs unit tests in pcid (target-only)
- 7 hid + usb unit tests in usbhidd (target-only)
- 4 hid unit tests in evdevd (target-only, plus
pre-existing test errors out of scope)
- 3 wifi unit tests in redbear-iwlwifi (target-only)
- Plus consumer-side QuirkAction tests in
redox-driver-sys that may run on either target.
The headline '161' was the result of an arithmetic
slip; the corrected figure is 128 in the host-
buildable tree (redox-driver-sys) and ~167 across
all trees including the consumer targets.
This session lands three more phases of the R11-R22
plan on top of R11 (already shipped):
- R12 (87ea8a9ac): DrmPanelOrientation enum +
lookup function + 36-entry 50-drm-panel.toml.
Consumer wiring in redox-drm is deferred until
Phase 4 KDE rotation lands.
- R13 (00e1c9ea1): PlatformDmiQuirkFlags (7 bits) +
PlatformSubsystem enum + 31-entry 80-platform-x86.toml
covering touchscreen / tablet_mode / hotkey /
accelerometer / battery for 2026 hardware.
- R14 (5caab8578): CpuBugFlags (27 bits matching
Linux X86_BUG_*) + CpuId struct + 14-entry
90-cpu-bugs.toml. Kernel-side consumer deferred.
QUIRKS-SYSTEM.md updates:
- Recent Activity (2026-06) table: 3 new rows
(R12, R13, R14) with commit SHAs and summaries.
- Test count progression: 155 → 158 (one new
unit test per phase, all 3 host-buildable).
- Headline: 'R11+R12+R13+R14 RESOLVED' added.
Total data file additions: 4 files, 99 DMI rules.
Consumer wiring is a follow-up:
- acpid: R11 AcpiQuirkFlags (osi_setup calls)
- redox-drm: R12 DrmPanelOrientation (rotation)
- inputd / thermald / redbear-upower: R13
PlatformDmiQuirkFlags (subsystem dispatch)
- kernel context-switch path: R14 CpuBugFlags
(mitigation engine)
R15 (timekeeping / TSC sync) is the next phase. The
audit estimated 3-4 days; the data side is small
(TSC sync status from CPUID), and the consumer is
kernel-side.
R11 lands in two commits this session:
- 5d06b0fa0 (redox-driver-sys): AcpiQuirkFlags (13 bits),
DmiAcpiQuirkRule, DMI_ACPI_QUIRK_RULES,
load_dmi_acpi_quirks, apply_dmi_acpi_quirk_rules,
ACPI_FLAG_NAMES, [[dmi_acpi_quirk]] TOML parser.
+2 unit tests. 122/122 redox-driver-sys tests pass.
- e3c41b834 (redbear-quirks): Four ACPI DMI TOML files
with 18 DMI rules from Linux 7.1 sources
(drivers/acpi/{osi,sleep,button,battery}.c).
QUIRKS-SYSTEM.md updates:
- Recent Activity (2026-06) table: two new rows with
commit SHAs and one-line summaries.
- Test count progression: 153 → 155 across the new
redox-driver-sys tests.
- Headline: 'R11 (ACPI DMI rules) RESOLVED' added.
R12 (ACPI consumer wiring) is the next priority.
R12 is a 1-day task: wire load_dmi_acpi_quirks() into
acpid / acpi-handlers so the matched flags drive
acpi_osi_setup(), acpi_old_suspend_ordering(),
LID_INIT_DISABLED/OPEN, and battery quirk handler
flags. The infrastructure is now ready for this; the
consumer side is the only missing piece.
This session landed four more audit items:
- Blocker 3 (9f250dbe, base fork): usbhidd HID/USB wiring
- Gap 10 (a24cfe64c, evdevd recipe): evdevd HID registration
- Gap 11: redox-drm GPU wiring (was already resolved; the
audit's 'Gap 11 PENDING' was based on a misread of
src/drivers/mod.rs:161 — full.quirks() IS the lookup)
- Gap 12 (1561767ac, redbear-iwlwifi recipe): Wi-Fi NIC quirks
- Gap 15 (98982cc2f, amdgpu recipe): extract pci_*_quirk_flags
out of redox_stubs.c into a new redox_quirk_bridge.c TU
QUIRKS-SYSTEM.md updates:
- Recent Activity (2026-06) table: adds four rows with commit
SHAs and one-line summaries.
- Blocker status block: Blocker 3 promoted to RESOLVED.
- New Gap status block: 4/4 gaps RESOLVED.
- Test count progression: 140 → 153 across the four new
unit test suites.
- Cross-Cutting Consumer Wiring Checklist: rows for evdevd,
redox-drm, iwlwifi, amdgpu promoted from PENDING to
RESOLVED (or ALREADY RESOLVED for redox-drm).
- Implementation Order: Gap 15 + Gap 10-12 entries marked
RESOLVED with commit SHAs and dates.
- Headline: '5/5 P0 critical blockers RESOLVED, 4/4
medium-low gaps RESOLVED'.
R11 is the next priority. With all blockers + gaps landed,
the data tables are live at every consumer site. R11 is
data-only work (mining ~60 ACPI DMI rules into
quirks.d/45-acpi-osi.toml through 48-acpi-battery.toml)
and becomes the first phase to ship user-visible benefit
on real hardware.
The Blocker 1 commit lands in the base fork (commit 676af02e on
redbear-working). This commit:
1. Bumps the three submodule pointers to the new commits that
the gitea force-pushes landed this session (one per fork).
2. Updates QUIRKS-SYSTEM.md to reflect the new state.
In QUIRKS-SYSTEM.md:
- Recent Activity (2026-06) table: adds a row for Blocker 1
with the commit SHA + summary.
- Blocker status block: Blocker 1 promoted to RESOLVED, Blocker
4 re-tagged as reduced to a 1-2 day follow-up (the loop is
mechanically unblocked now that Blocker 1 is in), Blocker 3
flagged as the next priority.
- Test count progression: extends to 140 (12 new pcid unit
tests).
- Blocker 1 section: new 'Status: RESOLVED 2026-06-07' block
with the three pieces (PcidConfigWriter, build_device_info,
apply_pci_quirks), the wiring location, the test coverage,
and the clean check / clippy result.
- Cross-Cutting Consumer Wiring Checklist: pcid row promoted
from PENDING to RESOLVED, with the commit SHA + test count.
The '3 of 5' line below becomes '4 of 5'.
- Adjusted Phase Estimates: R17 and R19 drop from 5-7 days to
2-3 days (the Blocker 1 dependency is gone). New total is
42-62 days (was 47-72); the +2-day remainder is Blocker 3
plus the xhcid QuirkAction follow-up.
- Recommended Implementation Order: Blocker 1 step promoted
from PENDING to RESOLVED, with the new commit SHA and
test count inline.
No other sections changed. The 15 medium/low gaps from the
R1-R10 audit remain PENDING; the next session will land
Blocker 3 (usbhidd HID/USB wiring) as the only remaining P0
critical blocker.
Documents the three-commit chain (bootloader 259a621 + kernel
a4ba465 + acpid fa91cee4) that lands end-to-end SMBIOS delivery
into userspace and updates the audit doc to reflect that Blocker 2
and Blocker 4 are no longer P0 critical blockers.
1. Top of the document: new 'Recent Activity (2026-06)' table
listing every commit this audit/cleanup cycle landed, with
a one-line summary per commit and a Blocker status block.
2. Blocker 2 (acpid DMI producer) section: status updated to
RESOLVED 2026-06-07 with a per-commit report. Documents
- bootloader: find_smbios() searches UEFI Configuration
Tables for SMBIOS3_TABLE_GUID, copies EPS + table to
page-aligned buffers, exposes them via four new u64
KernelArgs fields;
- kernel: new SmbiosScheme serves
/scheme/kernel.smbios/{eps,table} to userspace;
- acpid: new dmi.rs module walks the SMBIOS table, splits
each structure into formatted area + 1-based string
area, fills 9 DmiInfo fields, exposes
/scheme/acpi/dmi and /scheme/acpi/dmi/{field}.
Net effect: every compiled-in DMI rule and every
[[dmi_system_quirk]] / [[dmi_xhci_system_quirk]] TOML
entry now fires against real firmware data, not synthetic
fixtures.
3. Blocker 4 (xhcid full lookup) section: status updated to
RESOLVED with the partial-scope note that DMI lookup is
in but QuirkAction iteration awaits Blocker 1. Documents
the graceful-degradation path: when /scheme/acpi/dmi is
absent, the call falls through to non-DMI rules only.
4. Cross-Cutting Consumer Wiring Checklist: every P0/P1/P2/P3
row now has a 'Status (2026-06-07)' column showing
resolved vs pending. The section heading notes that 3 of
5 P0 critical blockers are RESOLVED, leaving 2 (Blocker 1
+ Blocker 3) as the next priority.
5. Adjusted Phase Estimates: R11 estimate drops from 5-7
days back to 2-3 days (Blocker 2 + Blocker 5 already
resolved; R11 is now data-only). Net total estimate
drops from 65-100 days to 47-72 days. R17, R18, R19
still carry the Blocker 1 / Blocker 3 surcharge since
those blockers are still pending.
6. Recommended Implementation Order: each blocker entry
now shows RESOLVED/PARTIAL/PENDING. R11 status note
updated to call out the chain completion. R12 and R13
prerequisite notes now say DONE 2026-06-07 instead of
'MUST FIX FIRST'.
7. Phase R11 / R12 / R13 entries: 'Infrastructure' notes
updated to point to the resolved commit ids and the
remaining acpid-side work (DMI-rule ownership for
_OSI override dispatch, ec timing consumer, etc.).
The 'three of five' P0 resolution is the headline result:
R11 (ACPI DMI rules) is now data-only and is the next
phase to ship user-visible benefit on real hardware.
Phase R10 audit (2026-06-07) identified that DmiInfo and DmiMatchRule
were missing the bios_vendor and bios_date fields that Linux SMBIOS
Type 0 (BIOS Information) provides. Many DMI-based quirk rules in
Linux drivers/acpi/osi.c, drivers/acpi/ec.c, and drivers/platform/x86/
match on BIOS vendor or BIOS release date for firmware-version
workarounds.
Changes:
- dmi.rs: add bios_vendor: Option<String> and bios_date: Option<String>
to both DmiInfo and DmiMatchRule structs
- dmi.rs: extend is_empty() and matches() to consider the new fields
- dmi.rs: extend parse_dmi_data() to handle bios_vendor and bios_date
keys in /scheme/acpi/dmi text format
- dmi.rs: extend all 8 compiled-in DmiPciQuirkRule literals and 3
DmiInfo test fixtures with the new fields
- toml_loader.rs: extend parse_dmi_match_rule() to parse bios_vendor
and bios_date from [[dmi_system_quirk]] match tables
- toml_loader.rs: extend all 4 DmiInfo test fixtures
- dmi.rs: 5 new unit tests (bios_vendor match, bios_date match,
combined match, parse_dmi_data, is_empty with bios fields)
- toml_loader.rs: 1 new integration test (TOML bios_vendor+date
parse and match, miss, and absent cases)
- QUIRKS-SYSTEM.md: mark Blocker 5 as RESOLVED
Tests: 120/120 pass (was 114, +6 new).
Clippy: +2 warnings (same map_or pattern as existing 7 DMI fields,
follows existing convention; not a new defect).
Source-of-truth: drivers/firmware/dmi_scan.c (dmi_decode_table) and
include/linux/mod_devicetable.h (dmi_system_id).
Depends on Blocker 2 (acpid DMI producer at /scheme/acpi/dmi) for
runtime data; the fields are now in place and will activate when
acpid is updated to populate the new keys.
Synthesize three parallel audit reports (bg_714f844f gap audit,
bg_1219aaa3 consumer audit, bg_c8826a88 adjacent-tech audit) into a
single R1-R10 audit section that captures the current consumer-wiring,
dormant-feature, and adjacent-technology state of the hardware quirks
system after R0-R10 implementation (commits 86902d481, 5e44191c9,
b56b810c0, b324cf67e, 6f1df4f04 on 0.2.3).
Five critical blockers identified:
1. PciConfigWriter production impl missing (QuirkAction dead code)
2. acpid does not serve DMI/SMBIOS at /scheme/acpi/dmi
3. usbhidd has zero HID/USB quirk consumption
4. xhcid does not call lookup_xhci_controller_quirks_full
5. DmiInfo/DmiMatchRule missing bios_vendor + bios_date fields
Fifteen medium/low gaps catalogued (TOML hot-reload, amdgpu stubs,
evdevd/redox-drm/iwlwifi wiring, etc.).
Comprehensive R11-R22 plan specifies for each phase:
- Infrastructure prerequisites (including the 5 blockers above)
- Data sources (compiled-in vs TOML vs DMI vs SMBIOS)
- Consumer drivers that must call lookup functions
- Test coverage expectations
- Runtime verification harness
Cross-cutting consumer wiring checklist ranks the work by priority (P0
through P3). Adjusted phase estimates reflect that the 5 blockers add
~20 days to the 44-68 day baseline, for a 65-100 day total.
Recommended implementation order: Blocker 5 -> Blocker 2 -> Blocker 1 ->
Blocker 3 -> Blocker 4, then Phases R11-R22 incrementally.
Adds:
- local/recipes/system/redbear-quirks/source/quirks.d/40-hid.toml:
967-line runtime override file with all 191 HID quirk entries
(mirrors the compiled-in hid_table.rs; lets operators override,
extend, or disable flags without rebuilding the driver)
- local/docs/QUIRKS-SYSTEM.md: 103-line R10 implementation report
covering scope completed (items 1-6, 8 of the 8-item R10 plan),
item 7 (consumer wiring) deferred to input-stack maturity,
entry-count audit (191 not 500), flag-count audit (24 defined,
9 used), bit-position audit (gaps at 0/8/9/15/24-27 for removed
upstream flags), test progression (106 -> 114, +8 R10 tests)
Follows the commit pattern of R6 (5e44191c9) and R7-R9 (b56b810c0)
where the structural Rust code is committed first, then the runtime
data and docs update are committed as a follow-up.
Phase R7 (xHCI closure, multi-session R7-R10 first commit):
* R7-A xHCI TOML layer: brings xHCI to 3-layer parity with PCI
(compiled-in + TOML + DMI). Adds XHCI_CONTROLLER_FLAG_NAMES (28
entries: 19 pre-R6 + 5 R6 + 3 R7-C with chronological markers),
read_toml_xhci_entries(), parse_xhci_toml(),
load_xhci_controller_quirks_toml(), updated
lookup_xhci_controller_quirks() to OR TOML flags, new
lookup_xhci_controller_quirks_full() as 3-layer entry point.
New quirks.d/25-xhci.toml with 8 example entries sourced from
Linux 7.1 xhci-pci.c.
* R7-B DMI xHCI bridge: mirrors the PCI DMI bridge. Linux itself
has no DMI-based xHCI quirks so DMI_XHCI_QUIRK_RULES is empty;
the wiring exists so future DMI rules can be added without
re-architecting. Adds DmiXhciQuirkRule struct,
apply_dmi_xhci_quirk_rules() OR-accumulator, DMI_XHCI_QUIRK_RULES
constant, load_dmi_xhci_quirks() public function,
read_toml_dmi_xhci_toml()/parse_dmi_xhci_toml() in toml_loader
for the new [[dmi_xhci_system_quirk]] section.
* R7-C 3 high-priority xHCI flags (already in 0.2.3 branch from
R7-C stand-alone commit): DEFAULT_PM_RUNTIME_ALLOW (bit 33),
SNPS_BROKEN_SUSPEND (bit 35), RESET_TO_DEFAULT (bit 44). Bit
positions match Linux 7.1 xhci.h:1586-1660 exactly. Six new
PCI entries: AMD 0x43f7, 0x15e0, 0x15e1, Intel 0x9a13/0x51e0/0x54ee.
Seven new R7-C tests.
Phase R8 (PciQuirkPhase data structure, no PM consumers):
* PciQuirkPhase enum: Header, Final, Enable, Resume, ResumeEarly.
Mirrors Linux DECLARE_PCI_FIXUP_* macro family.
* phase: PciQuirkPhase field on PciQuirkEntry. All 31 existing
compiled-in entries default to Final via ..WILDCARD.
* phase_visible(phase, pm_available) helper. Boot-time phases
always visible; Resume/ResumeEarly gated by pm_available.
* lookup_pci_quirks_full_with_pm() public function gates all
three layers. load_pci_quirks() defaults to pm_available=false
for safe existing-caller behavior.
* TOML parser reads phase = "header"|"final"|"enable"|"resume"
|"resume_early" per [[pci_quirk]] entry. Unknown/omitted
defaults to Final (graceful degradation).
* Seven R8 tests: header/resume/resume_early parse, omitted default,
unknown default, boot-phase visibility, resume-phase gating.
Phase R9 (USB storage gap closure, data-only):
* Resynced 30-storage.toml header to reference Linux 7.1 (was 7.0).
* Fixed one entry: VIA Labs VL817 SATA Bridge (0x2109:0x0715)
revision was "9999-9999" — corrected to wildcard "0000-9999"
to match Linux UNUSUAL_DEV(0x2109, 0x0715, 0x0000, 0x9999, ...).
* Verification: python3 local/scripts/extract-linux-quirks.py
local/reference/linux-7.1/drivers/usb/storage/unusual_devs.h
produces 214 entries. diff against 30-storage.toml = 0 lines.
The R1-R6 review's "108 missing" estimate was stale; the file
is in full sync with Linux 7.1.
Test count: 90 (R7-C) + 9 (R7-A, R7-B) + 7 (R8) = 106/106 passing.
No new clippy warnings beyond two Result<_, ()> stylistic lints
that follow the existing convention (7+ functions use this pattern).
Consumer wiring status: BROKEN_MSI consumer in xhcid main.rs:69,
ZERO_64B_REGS consumer in xhci/mod.rs:524,542. R7-C and R7-A new
flags are observability-only via log_unenforced_xhci_quirks()
(R6) until xhcid's suspend/resume path lands.
Deferred to next session: R10 HID infrastructure (24 flags +
500 entries) and any R7/R8 PM execution work when PM lands.
Multi-session plan: this is the first of 4 atomic commits for
R7-R10. R10 HID lands in a separate session.
Phase R6 (2026-06-07) extends the xHCI controller quirk layer with five
new XHCI_* bit positions from Linux 7.1's drivers/usb/host/xhci.h, three
new PCI table entries from xhci-pci.c, and an xhcid-side observability
hook for the unenforced flags. Bit positions match Linux exactly per
the existing docstring convention on XhciControllerQuirkFlags.
Five new xHCI flags (24 total, no collisions):
- XHCI_SSIC_PORT_UNUSED (bit 22) — Intel Cherryview 0x22b5
- XHCI_MISSING_CAS (bit 24) — Intel CV/SP/APL/DV
- XHCI_BROKEN_PORT_PED (bit 25) — platform-only in Linux
- XHCI_HW_LPM_DISABLE (bit 29) — platform-only in Linux
- XHCI_BROKEN_D3COLD_S2I (bit 41) — AMD Renoir 0x1639
XHCI_EP_CTX_BROKEN_DCS (bit 42) was the fifth entry on the plan's list
but is a Linux reserved-but-unused bit: only the BIT_ULL(42) definition
exists, with no consumer code anywhere and no PCI/vendor association.
Adding it would have been a stub. XHCI_SSIC_PORT_UNUSED is added in its
place — it has both a PCI association and a consumer site.
PCI table entries (3 new, 89 total):
- Intel Cherryview 0x22b5 → SSIC_PORT_UNUSED + MISSING_CAS
- AMD Renoir 0x1639 → BROKEN_D3COLD_S2I
BROKEN_PORT_PED and HW_LPM_DISABLE have no PCI entries — Linux sets
these only from xhci-plat.c / xhci-mtk.c / xhci-histb.c (non-PCI host
adapters). They are defined for forward-compatibility with future
platform xHCI support.
xhcid consumer wiring (in local/sources/base submodule):
- log_unenforced_xhci_quirks() called from Xhci::init() emits a
warn! line for each set-but-unenforced R6 flag, citing the Linux
consumer site and the missing Red Bear code path. Observability,
not fake enforcement.
- Real enforcement for consumer sites that require suspend, LPM,
port-disable, or CAS code paths in xhcid is deferred to Phase R8
(PM infrastructure) and follow-up work.
Tests: 8 new (75 → 83 total passing).
Clippy: 26 warnings, all pre-existing R0–R5 baseline. No new warnings.
TOML validator: 244 entries, 0 undefined (no TOML changes for R6 —
xHCI controller flags are compiled-in only).
Source of truth: Linux 7.1 drivers/usb/host/{xhci.h, xhci-pci.c,
xhci.c, xhci-hub.c, xhci-plat.c, xhci-mtk.c, xhci-histb.c}.
Extract protocol-agnostic FenceTimeline from Intel to shared
src/drivers/fence.rs — atomic-based fence tracking suitable
for Intel, VIRGL, and AMD drivers.
Extract protocol-agnostic SyncobjManager from Intel to shared
src/drivers/syncobj.rs — syncobj create/destroy/signal/reset/
wait/query and sync_file fd export/import.
Wire both into VirtioDriver:
- Add FenceTimeline + SyncobjManager fields
- Implement all 5 GpuDriver syncobj trait methods
(create, destroy, wait, export_fd, import_fd)
- Track fence seqnos in virgl_submit_3d (allocate
before submit, signal after completion)
Intel fence.rs and syncobj.rs converted to thin re-export
modules pointing at shared sources — no behavioral change
for Intel driver.
This gives Mesa VIRGL userspace the standard DRM syncobj
API for GPU/compositor synchronization.
Version 2.0 — reflects current state after ~100 commits:
66 compiled modules, 125 total .rs files, ~20,000 lines
19 dead modules wired, EOI fix, all 8 phases complete
GEM 81% Linux coverage, all 7 PHY types, DP 2.1 + HDMI 2.1
Integration gaps documented with mitigation status
vasilito
Red Bear OS