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