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.
- 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
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.
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}.
On Redox there is no udev-based DRM device enumeration. KWin's DRM
backend relies on m_udev->listGPUs() which returns nothing without udev.
Add a fallback: when no KWIN_DRM_DEVICES is set and the session is
kde-wayland, inject KWIN_DRM_DEVICES=/scheme/drm/card0 so KWin knows
which device to open. This fixes the 'No suitable DRM devices' error
that prevented KWin from starting on Redox.
Added test: build_environment_sets_kwin_drm_devices_default_for_kde_wayland
to verify the fallback is applied correctly.
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.
Lines 649-651 had VramManager and info!() calls that don't belong
in handle_irq(). These were likely from a bad merge. The variables
fb_phys and fb_size are local to new() and don't exist in handle_irq().
Add regs_gen12.rs implementing IntelRegs trait for Gen12 (TGL/ADL)
and Gen12_7 (MTL/ARL) display engines. Gen12 shares most display
register offsets with Gen9 but has different forcewake and DMC.
- Gen12Regs: same pipe/plane/DDI/cursor/vblank offsets as Gen9
but with Gen12 forcewake (0xa188/0xdfc) and DMC (0x80000+)
- Gen12DisplayRegs: Gen12-specific display registers:
TRANS_DDI_FUNC_CTL (0x60400) — separate transcoder control
DBUF_CTL_S1/S2 (0x45008/0x4500C) — display buffer slices
PLANE_CTL/SURF/STRIDE at standard plane offsets
Update mod.rs generation selector: Gen12/Gen12_7 → Gen12Regs.
Xe2 continues to use Xe2Regs, Gen9 uses Gen9Regs.
Linux reference: intel_display_regs.h, xe_gt_regs.h
Rewrite display_power.rs to support both Gen9 (Skylake) and Xe2
(Arrow Lake/Battlemage) power well initialization.
Gen9 path (unchanged): single POWER_WELL_CTL register at 0x45400
with bitmask for PW1/PW2/DDI_A-E/AUX_A-D domains.
Xe2 path (new): multiple power well controllers:
- HSW_PWR_WELL_CTL1 (0x45400) — PW1/PW2 per-index REQ/STATE
- ICL_PWR_WELL_CTL_AUX1 (0x45440) — 4 AUX channels
- ICL_PWR_WELL_CTL_DDI1 (0x45450) — 4 DDI ports
- DC_STATE_EN (0x45504) — DC power state control
Each well uses 2-bit per-index encoding (REQ=0x2, STATE=0x1).
DisplayPower::new() now takes &IntelDeviceInfo to select
generation-appropriate initialization path.
Linux reference: intel_display_power_well.c (xelpdp_aux_power_well_*)
Kernel, relibc, and base forks now use the full pre-patched source
from the frozen 0.1.0 release archives (including .git history).
Build verification:
- kernel: BUILDS from local/sources/kernel
- relibc: BUILDS from local/sources/relibc
- base: BUILDS from local/sources/base
- redoxfs: BUILDS from local/sources/redoxfs
The mini ISO build fails due to pre-existing cached pkgar signature
issues (not migration-related).
vasilito