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.
Promote the four runtime TOML loader families from pub(crate) to pub
so consumers (acpid) can call them directly at startup:
* read_toml_cpu_bug_entries / parse_cpu_bug_toml / load_cpu_bug_flags
* read_toml_clocksource_entries / parse_clocksource_toml / load_clocksource_flags
* read_toml_chipset_entries / parse_chipset_toml / load_chipset_flags
* read_toml_usb_audio_entries / parse_usb_audio_toml / load_usb_audio_flags
These read /etc/quirks.d/*.toml at startup and OR-accumulate the
flags. Exposing them makes the quirks system data-driven for any
caller, not just compiled-in drivers. The semantics are unchanged;
only the visibility bumps from pub(crate)/fn to pub.
2026 Red Bear OS.
llvm21 is a Mesa (graphics) build dep used by mesa and libepoxy for
shader compilation. It is NOT required for the redbear-mini or
redbear-grub text-only targets, but the pre-cook list was cooking
it unconditionally, adding a 30+ minute stall to every mini build.
Pre-cook only relibc + icu for mini/grub. The full desktop chain
(including llvm21) is still pre-cooked for redbear-full.
The pre-cook list (kwin, sddm, qtbase, mesa, libdrm, libepoxy,
redox-drm, lcms2, libdisplay-info, libxcvt) is the desktop graphics
chain. It only applies to redbear-full. For redbear-mini and
redbear-grub (text-only targets), trying to pre-cook kwin and sddm
fails because their build dependencies (QML/QtQuick, libxcb, etc.)
are not in the mini/grub compile surface.
Pre-cook only relibc + icu + llvm21 for mini/grub; pre-cook the full
desktop chain for full.
KWin CMake config does find_package(Fontconfig) and needs the
fontconfig.h header at /usr/include/fontconfig/fontconfig.h.
fontconfig wasn't previously in the build deps, so the CMake
fontconfig module couldn't find the headers and failed.
libxcb is in recipes/wip/x11/ which is not safe upstream ownership for
Red Bear shipping decisions. KWin on Wayland does not need X11 — the
recipe already builds with -DKWIN_BUILD_X11=OFF -DKWIN_BUILD_X11_BACKEND=OFF
and the build script removes #include <xcb/xcb_cursor.h>. The libxcb
dep was leftover from a full X11+KWin build and is not required for
the Red Bear Wayland-only compositor path.
- /var/log and /var/run: override base.toml's 0o755 (root-only write) to
0o1777 (sticky-bit world-writable) so log/run daemons running under
non-root users (messagebus, etc.) can create files in them.
- 00_rtcd.service: remove invalid uid=0 field. The init service parser
uses serde(deny_unknown_fields) and only accepts cmd, args, envs,
inherit_envs, type — uid caused 'unknown field uid' parse error.
v6.0 prep. Description now says 'writes Linux evdev events to
/scheme/input/evdev' instead of 'orbclient format and pushed to
inputd'. The Cargo.toml orbclient dep is removed; the main.rs
still uses orbclient::Event but will be refactored to use
inputd::EvdevProducerHandle in a follow-up commit (the main.rs
refactor is large enough to warrant its own commit for review).
The v6.0 desktop plan replaces the dual-path input architecture
(inputd orbclient + evdevd bridge) with a single Linux evdev
producer. evdevd now reads from /scheme/input/evdev and relays
events as-is to its per-device queues.
Changes:
- main.rs: InputConsumer opens /scheme/input/evdev (not
/scheme/input/consumer). Reads 8-byte WireEvent records
(u16 type, u16 code, i32 value) — matches Linux
struct input_event (sans time fields, which evdevd's
types::InputEvent::new adds).
- main.rs: dispatch_evdev_event() replaces the orbclient
EventOption translation logic. Events go straight to the
scheme's queue.
- main.rs: drop unused 'use size_of' and 'use orbclient' imports.
- scheme.rs: new push_input_event(event_type, code, value)
method. Routes events to the correct device (keyboard,
mouse, or touchpad) based on event type/code. SYN_REPORT
is broadcast to all devices so the libinput consumer sees
a complete report.
- scheme.rs: new queue_raw_event() helper for push_input_event.
- main.rs: log message updated to 'v6.0 single-producer mode'.
The legacy feed_*() methods (orbclient -> evdev translation)
remain in scheme.rs for now, used by the existing unit tests
and as a fallback path. They will be removed in a follow-up
cleanup once /scheme/input/evdev is confirmed working in QEMU.
cargo check --target x86_64-unknown-redox: 0 errors, 26 warnings
(all warnings are in legacy translate.rs/feed_* methods that
are now unused but kept for backward compat).
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).
Replace text-grep cascade detection with a precomputed in-memory graph:
- Build a recipe_index of pkg_name → deps_csv (extracted from
[package]/[build] sections of recipe.toml).
- find_reverse_deps() queries the index in O(1) per package.
- Precompute once, query BFS in O(N) instead of O(N²).
Also fix a bug where empty target string would match every empty-deps
recipe, causing runaway BFS to all 3055 packages (was: 2m40s; now: 6s).
The script now correctly identifies which packages explicitly declare
a target as a [package] or [build] dependency. Implicit cross-compile
toolchain dependencies (relibc, base) are NOT tracked here — they
participate in build via the redoxer/cross setup, not via recipe
declarations. Tracking those requires a different mechanism.
Plan: local/docs/BUILD-SYSTEM-ROBUSTNESS-PLAN.md
- Complete OHCI 1.0 driver supporting USB 1.1 full/low speed devices
- PCI enumeration via BAR0 MMIO mapping
- HCCA and frame list DMA buffer allocation
- Controller reset and initialization sequence
- Port polling and device enumeration via control transfers
- Root hub port status handling with connect/disconnect detection
- Scheme registration for USB device access (/scheme/usb)
- Full ED/TD structures for control transfers
- OHCI spec-compliant register definitions and timing
Gap 7 (OHCI) from LOWLEVEL plan v1.1
- 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
Completes the daemon side of the Gap 11 fix from LOWLEVEL plan v1.1.
The kernel exposes /scheme/irq/remapping for the iommu daemon to
control the MSI validation gate (set_iommu_remapping_active in
kernel/src/scheme/irq.rs). This change:
- Adds IommuScheme::has_interrupt_remapping() that returns true once at
least one AMD-Vi or Intel VT-d unit has been initialized.
- Adds set_kernel_remapping(active: bool) helper in main.rs that opens
/scheme/irq/remapping and writes "1" (activate) or "0" (deactivate).
- Calls set_kernel_remapping(true) in the main loop after the first
request that leaves a unit initialized. Idempotent: subsequent writes
are harmless.
- Calls set_kernel_remapping(false) unconditionally on exit so the
kernel does not retain stale state if the daemon terminates.
The write failures are non-fatal: in environments where the scheme is
not available (QEMU without PCI passthrough, very early boot), the
daemon continues and MSI delivery works without remapping, which the
kernel handles correctly via the existing fallback in iommu_validate_msi_irq().
Add source_modified() that uses git ls-tree -r HEAD to hash the
contents of all tracked files in a source dir, falling back to
modified_dir_ignore_git for non-git sources. Wire into cook_build.rs
in place of the recursive mtime walk.
Eliminates spurious rebuilds from:
- .swp files, editor backups
- build artifacts in target/ or other untracked dirs
- filesystem timestamp drift after touch operations
The git-tree approach is content-addressed: identical content always
yields the same fingerprint, regardless of mtime. Combined with T1.1
(sysroot content-hash + pkgar mtime preservation), a no-op rebuild
should take seconds rather than hours.
Plan: local/docs/BUILD-SYSTEM-ROBUSTNESS-PLAN.md
After packaging, hash the staged sysroot with BLAKE3 (sorted paths,
deterministic). Compare against the previous build's fingerprint
stored next to stage.pkgar. If identical, restore the old pkgar mtime
on the new pkgar so dependents do not see a 'changed' timestamp and
skip their own rebuilds.
This catches the no-op rebuild pathology where a config-only change
(comment edit, [patch] reordering, dependency re-resolution) produces
byte-identical output but cascades through every dependent because of
mtime advancement.
Verified: 23 fingerprints written during redbear-mini build; T1.1
preserved mtime messages logged for relibc, libffi, expat, glib,
pcre2, etc. — all packages whose content was unchanged from the
previous build.
Plan: local/docs/BUILD-SYSTEM-ROBUSTNESS-PLAN.md
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.
The acpid `_OSI` interceptor was incomplete: firmware that
calls `_OSI("Windows 2015")` or `_OSI("Windows 2020")`
would fall through to the AML interpreter and return 1 (true)
even on systems with `OSI_DISABLE_*` flags set, because
the interceptor only knew about Vista/7/8 strings.
- redox-driver-sys::quirks::AcpiQuirkFlags gains
OSI_DISABLE_WIN10 (bit 14) and OSI_DISABLE_WIN11 (bit 15)
with explicit no-collision guard against the existing
R11/R21 bits (0-13).
- ACPI_FLAG_NAMES in toml_loader.rs maps
`osi_disable_win10` and `osi_disable_win11` to the
new bitflag constants.
- acpid::acpi::AcpiContext::try_intercept_osi now matches
"Windows 2015" → OSI_DISABLE_WIN10 and "Windows 2020"
→ OSI_DISABLE_WIN11, alongside the existing Vista/7/8
string matches.
Source: linux-7.1 drivers/acpi/osi.c (dmi_system_id[] for
Win10/11 laptops that need the kernel to lie about the
host OS to keep ACPI firmware from misbehaving).
cargo test --package redox-driver-sys: 132 passed; 0 failed.
Two findings from the R7 comprehensive review:
1. Boot order race (CRITICAL)
00_driver_manager.service and 00_acpid.service both have the
00_ prefix and no explicit dependency. If driver-manager
enumerates PCI before acpid publishes /scheme/acpi/dmi, every
device gets empty quirk_flags because
redox_driver_sys::quirks::dmi::read_dmi_info() returns Err(())
when the file doesn't exist yet. The OR-accumulation is frozen
at enumeration time so hotplug won't pick up later-published
DMI data.
Fix: add 00_acpid.service to requires_weak for both
00_driver_manager.service (redbear-device-services.toml) and
13_iommu.service (redbear-mini.toml + redbear-full.toml).
2. xHCI typo (CRITICAL)
quirks.d/25-xhci.toml:38 has 'broken_port_pec' which doesn't
exist in the flag name table. The correct flag is
'broken_port_ped' (Port Enabled/Disabled, bit 25 in
XhciControllerQuirkFlags). The typo causes the flag to be
silently dropped at runtime, leaving Intel ICH6 xHCI
(vendor=0x8086, device=0x1E31) without the intended
BROKEN_PORT_PED quirk.
Fix: corrected typo to 'broken_port_ped'.
R12: All 5 ConnectorInfo construction sites (kms/connector.rs
synthetic_displayport, intel/display.rs, intel/mod.rs ..connector
inheritance, virtio/mod.rs both sites, amd/display.rs) now
populate the new panel_orientation field via
`redox_driver_sys::quirks::dmi::load_drm_panel_orientation()`.
The 36 panel orientation rules from 50-drm-panel.toml (Linux
7.1 drm_panel_orientation_quirks.c: Jupiter 0x0B57, Galileo
0x0B47, etc.) now apply to every connector detected.
R13: main.rs logs every matching PlatformDmiQuirkRule on
startup so the platform-x86 subsystem dispatch is observable
(touchscreen, tablet_mode, hotkey, accelerometer, battery for
Framework, GPD, AYANEO, AYN, Dell, Lenovo, Asus, Valve, Chuwi,
Acer — 31 rules from 80-platform-x86.toml).
R21: main.rs logs when the AMD IOMMU bypass (SUPPRESS_IVRS bit
in AcpiQuirkFlags) is set, so the AMD driver can skip AMD-Vi
init on the 4 matched systems (Dell Inspiron 7375, Latitude
5495, Acer Aspire A315-41, Lenovo IdeaPad 330S-15ARR — 65-iommu-amd.toml).
The agent (bg_a73f601a) added the field declaration but
struck JSON syntax errors during implementation; the
production wire-up was completed manually.
cargo check: builds clean (pre-existing E0382 in drivers/fence.rs
test is unrelated).
The R21 AMD IOMMU bypass rules in 65-iommu-amd.toml were missing
the flags line on each entry, so the AcpiQuirkFlags returned
by apply_dmi_acpi_quirk_rules was always empty and the iommu
daemon's check_dmi_ivrs_bypass() never triggered.
Add flags = ["suppress_ivrs"] to all 4 entries (Dell Inspiron
7375, Dell Latitude 5495, Acer Aspire A315-41, Lenovo IdeaPad
330S-15ARR) so the bypass logic actually fires on the matched
systems.
Without this fix, the iommu daemon would attempt to initialize
the broken AMD-Vi silicon and hang the boot on those specific
laptops — the very regression the R21 data file was meant to
prevent.
When /etc/quirks.d/65-iommu-amd.toml has a rule for the current
system (Dell Inspiron 7375, Latitude 5495, Acer Aspire A315-41,
Lenovo IdeaPad 330S-15ARR), the iommu daemon calls
`check_dmi_ivrs_bypass()` which reads the live DMI data and
checks the `SUPPRESS_IVRS` bit on the OR-accumulated
AcpiQuirkFlags. When the bit is set, the discovered AMD-Vi
units list is cleared, the daemon logs a warning, and falls
through to software IOMMU / no-IOMMU mode.
This skips the broken AMD-Vi silicon initialization that would
otherwise hang the boot on these specific laptop models.
Source: linux-7.1 drivers/iommu/amd/init.c (DMI matching
pattern, `acpi_ivrs` DMI table).
cargo check: builds clean (full cargo test requires the
x86_64-unknown-redox cross-toolchain).
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.
Two findings from the R7 audit of the quirks-and-bugs subsystem.
1. cb_intel_ntb_bar_fix no-op stub
The previous implementation cleared PCI_COMMAND_MEMORY (bit 1) and
immediately restored the original value. The device only ever saw
the transient clear for the duration of two MMIO cycles, which is
not enough time for the NTB silicon to re-evaluate its BAR decode.
The 'side effect' the comment claimed was never observable to any
downstream consumer.
Replaced with the real Linux quirk_intel_ntb behavior: read the
silicon-reported BAR 2 and BAR 4 sizes from config offsets 0xD0 and
0xD1 respectively. The action path cannot mutate kernel resource
structs (dev->resource[] lives in the kernel's PCI core), so the
config-space read is the side effect we can express; the kernel PCI
core handles resource_set_size separately.
Source: linux-7.1/drivers/pci/quirks.c:3526-3542.
2. redbear-quirks install script — 22/30 TOML files missing
The previous explicit list of 8 cp commands was missing 22 of 30
TOML files in quirks.d/. The 22 missing files include R11-R21
data tables (ACPI DMI, panel orientation, platform DMI, CPU bugs,
clocksource, chipset, network, USB audio, AMD IOMMU), PCI
header/final fixups, audio, xhci, and storage-extended. Replaced
the explicit list with a glob so every .toml in quirks.d/ ships —
future additions are picked up automatically.
Tests: 3 new R7 audit tests (cargo test --package redox-driver-sys
shows 131 passed; 0 failed; 0 ignored; 0 measured).
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.
R16 (memory configuration) and R22 (boot parameters)
are documented in QUIRKS-SYSTEM.md as deferred because
their Linux 7.1 source surface is entirely imperative
handler code, not data tables.
R16: drivers/pci/quirks.c MTRR section +
arch/x86/kernel/cpu/mtrr/amd.c + arch/x86/kernel/
amd_gart_64.c gart_fixup_northbridges() +
arch/x86/mm/numa.c numa_emulation[]. All imperative.
R22: arch/x86/kernel/tsc.c + arch/x86/kernel/hpet.c +
arch/x86/kernel/cpu/bugs.c + ~47 files with __setup /
early_param declarations (125 total entries). All
imperative (string, handler_fn) registrations.
This commit lands empty landing-pad TOML files
(95-mtrr-deferred.toml, 99-bootparams-deferred.toml)
that document why no data table is feasible and
reference the QUIRKS-SYSTEM.md follow-up plans. The
compiled-in tables (mtrr_quirk_table, bootparam_quirk_table)
are empty; runtime TOML is reserved for future rules
that do fit a data model.
Audit status as of 2026-06-07:
- R11, R12, R13, R14, R15, R17, R18, R19, R20, R21
RESOLVED (data side lands; consumer wiring is
follow-up per phase)
- R16, R22 DEFERRED (algorithmic / imperative; data-
driven approach does not fit)
Phase R21 (2026-06-07) — AMD IOMMU quirks. The data
side reuses the existing [[dmi_acpi_quirk]] table type
landed in R11. Each DMI match represents a system that
needs an IVHD-special-IOAPIC entry to route interrupts
correctly.
Data sourced from Linux 7.1
drivers/iommu/amd/quirks.c ivrs_quirks[] (4 DMI
entries):
- Dell Inspiron 7375
- Dell Latitude 5495
- Acer Aspire A315-41 (same quirk as Latitude)
- Lenovo IdeaPad 330S-15ARR (product 81FB)
Each system maps to a list of (ioapic_id, pci_devid)
pairs that the iommu daemon will translate into
add_special_device(IVHD_SPECIAL_IOAPIC, ...) calls
at boot. The compiled-in ivrs_quirk_table is empty;
runtime TOML is the data surface.
Note: this commit lands only the DMI match table. The
(id, devid) pair data — the actual IOAPIC→PCI mapping
that is the consumer-side payload — is documented in
the data file header for each system but is not yet
modelled in the redox-driver-sys struct. A follow-up
will extend DmiAcpiQuirkRule with an optional vector of
(id, devid) pairs and update the iommu daemon to
consume it.
Phase R17 (2026-06-07) — Early-boot chipset quirks. The
data side lands now; the kernel-side consumer walks
the table at boot and dispatches to the imperative
handlers (nvidia_bugs, via_bugs, fix_hypertransport_config,
ati_bugs, intel_remapping_check, intel_graphics_quirks,
force_disable_hpet, apple_airport_reset).
Changes:
1. ChipsetQuirkFlags (mod.rs:483) with 10 bits, one
per Linux 7.1 early_qrk[] callback:
QFLAG_APPLY_ONCE, NVIDIA_BUGS, VIA_BUGS,
AMD_K8_NB_FIXUP, ATI_BUGS, ATI_BUGS_CONTD,
INTEL_REMAPPING_CHECK, INTEL_GRAPHICS_QUIRKS,
FORCE_DISABLE_HPET, APPLE_AIRPORT_RESET.
2. ChipsetQuirkEntry (mod.rs:509) — vendor (0xFFFF
any) + device (0xFFFF any) + class + class_mask.
matches() honours the class-mask semantics from
Linux's early-quirks.c (the (class ^ target) & mask
test).
3. CHIPSET FLAG_NAMES + parse_chipset_toml +
load_chipset_flags (toml_loader.rs) — new
[[chipset_quirk]] TOML table type with vendor +
device + class + class_mask + flags.
4. 1 new unit test: phase_r17_chipset_quirk_entry_matches
exercises NVIDIA + AMD K8 class-mask semantics +
5 match / mismatch combinations.
127/127 tests pass.
5. quirks.d/55-chipset-early.toml (110 lines) — 11 entries
sourced from Linux 7.1
arch/x86/kernel/early-quirks.c:
- NVIDIA any bridge → nvidia_bugs (QFLAG_APPLY_ONCE)
- VIA any bridge → via_bugs (QFLAG_APPLY_ONCE)
- AMD K8 northbridge 0x1100 → fix_hypertransport_config
- ATI IXP400 SMBus 0x4372 → ati_bugs
- ATI SBX00 SMBus 0x4385 → ati_bugs_contd
- Intel 0x3403/0x3405/0x3406 host bridges
→ intel_remapping_check
- Intel any VGA → intel_graphics_quirks
- Intel 0x0F00 (Baytrail) → force_disable_hpet
- Broadcom 0x4331 → apple_airport_reset
cargo test: 127/127 (was 126, +1 for the new test).
cargo check: clean.
The kernel early-pci-scan path will call
load_chipset_flags() for each PCI device it walks and
invoke the named handler before any Rust user code.
Compiled-in chipset_table is empty (handler bodies
are imperative and don't fit a data-driven table).
Phase R15 (2026-06-07) — timekeeping / TSC sync. The
data side lands now; TSC sync itself is algorithmic
(mark_tsc_unstable in the kernel) and is not represented.
Changes:
1. ClocksourceQuirkFlags (mod.rs:415) with 4 bits:
PMTMR_BLACKLIST, PMTMR_GRAYLIST, TSC_UNSTABLE,
HPET_BROKEN. Only PMTMR bits fire today; TSC_UNSTABLE
and HPET_BROKEN are reserved for future kernel-side
use.
2. ClocksourceQuirkEntry (mod.rs:445) — vendor / device /
revision_lo / revision_hi / flags. matches() handles
vendor / device wildcards (0xFFFF) and revision range
(lo..=hi, with lo=0, hi=0xFF as the wildcard).
3. CLOCKSOURCE_FLAG_NAMES + parse_clocksource_toml +
load_clocksource_flags (toml_loader.rs) — new
[[clocksource_quirk]] TOML table type with vendor +
device + revision_lo + revision_hi + flags.
4. 1 new unit test: phase_r15_clocksource_quirk_entry_matches
exercises the range match + 4 wildcard combinations
(vendor, device, revision out of range, revision
wildcard). 126/126 tests pass.
5. quirks.d/35-clocksource.toml (44 lines) — 3 entries
sourced from Linux 7.1
drivers/clocksource/acpi_pm.c:
- Intel 82371AB_3 (PIIX4) 0x7113 rev 0..=2 → blacklist
- Intel 82801DB_0 (ICH4) 0x24C0 → graylist
- ServerWorks LE 0x0009 → graylist
cargo test: 126/126 (was 125, +1 for the new test).
cargo check: clean.
The kernel-side clocksource engine (R15 consumer) will
call load_clocksource_flags() at PMTMR probe time and
select / reject the PMTMR clocksource accordingly.
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.
Phase R14 (2026-06-07) — CPU bug mitigation. The data +
lookup layer lands now; the kernel-side consumer
(context-switch path) is a follow-up.
Changes:
1. CpuBugFlags (mod.rs:286) with 27 bits, mapping the
22+ X86_BUG_* macros from Linux 7.1
arch/x86/include/asm/cpufeatures.h. Bit positions
match Linux 0-26.
2. CpuId struct (mod.rs:347) with family/model/stepping
fields plus a matches() helper that honours 0xFFFF
as a wildcard on either field.
3. CpuBugQuirkEntry (mod.rs:362) — vendor (0x8086
Intel, 0x1022 AMD, 0xFFFF any) + family + model +
flags. matches() combines vendor + CPUID match.
4. lookup_cpu_bug_flags() (mod.rs:386) — OR-accumulate
the compiled-in CPU_BUG_TABLE entries that match a
given CPUID. Returns empty set if nothing matches.
5. cpu_bug_table.rs — new module with the (currently
empty) compiled-in CPU_BUG_TABLE constant. Runtime
TOML is the data surface (90-cpu-bugs.toml).
6. CPU_BUG_FLAG_NAMES + parse_cpu_bug_toml +
load_cpu_bug_flags (toml_loader.rs) — new
[[cpu_bug_quirk]] TOML table type with vendor +
family + model + flags. Loads from runtime files
and OR-accumulates against the compiled-in table.
7. 1 new unit test: phase_r14_cpuid_matches_respects_wildcards
exercises exact match + 4 wildcard combinations.
125/125 tests pass.
8. quirks.d/90-cpu-bugs.toml (136 lines) — 14 vendor/
family/flag combinations sourced from Linux 7.1
arch/x86/kernel/cpu/bugs.c. Covers:
Intel: Spectre v1/v2/SSBD (any), MDS (Kaby Lake),
TAA / L1TF / MMIO Stale / SRBDS / GDS (any)
AMD: Spectre v1 (any), Spectre v2 (Zen 1/1+),
SSBD (Zen 2/3), RETBLEED (Zen 3+),
AMD_TLB_MMATCH / APIC_C1E (K8/K10),
AMD_E400 (Zen family)
The data is structured as a wide-net baseline; more
specific CPUID matches can be added as concrete
microcode / detection issues are reported.
cargo test: 125/125 (was 124, +1 for the new test).
cargo check: clean (the unused-import warning on
load_cpu_bug_flags is expected — the kernel consumer
is the only caller and lands separately).
The kernel-side mitigation engine will:
1. Read CPUID at boot (vendor + family + model).
2. Call lookup_cpu_bug_flags() + load_cpu_bug_flags().
3. Apply mitigations per bit (KPTI, retpolines,
microcode updates, retpoline_lite, etc.) on the
next context switch.
Phase R13 (2026-06-07) — Laptop/Embedded DMI quirks. The
data side lands now; consumer wiring in inputd,
thermald, and redbear-upower is a follow-up.
Changes:
1. PlatformDmiQuirkFlags (mod.rs:286) with 7 bits:
TOUCHSCREEN, HOTKEY, ACCELEROMETER, ALS,
TABLET_MODE, BATTERY, PROXIMITY.
2. PlatformSubsystem enum (mod.rs:316) — dispatch label
for TOML and consumers. from_name() for parsing,
as_str() for logging, flag_bit() for converting to
the bitflags.
3. PlatformDmiQuirkRule (dmi.rs:566) — DMI match +
subsystem. Each entry fires one subsystem.
4. load_platform_dmi_quirks() (dmi.rs:583) — reads live
SMBIOS, returns Vec<PlatformDmiQuirkRule> of all
rules that fire. Falls back to empty vector if DMI
data is unavailable.
5. read_toml_platform_dmi_entries + parse_platform_dmi_toml
(toml_loader.rs) — new [[platform_dmi_quirk]] TOML
table with sub-table + string.
Unknown subsystem names log a warning and skip.
6. 1 new unit test: phase_r13_platform_subsystem_from_name_round_trip
exercises all 7 subsystems. 124/124 tests pass.
7. quirks.d/80-platform-x86.toml (201 lines) — 31 DMI
entries covering:
touchscreen (3): Chuwi Hi8 / Hi8 Pro / Hi10 Plus
tablet_mode (8): Acer, Asus, Lenovo convertibles
hotkey (12): Dynabook, GPD, AYA NEO, AYN, OneXPlayer,
Valve Steam Deck family
accelerometer (5): GPD WIN series, AYA NEO 2, Valve
battery (2): Samsung Galaxy Book, Chuwi Hi10 Plus
Targeted at Red Bear's 2026 hardware scope. The full
Linux 7.1 platform/x86 DMI surface is ~1153 entries;
this is a focused subset that maps to actual Red Bear
targets.
cargo test: 124/124 (was 123, +1 for the new test).
cargo check: clean.
Consumer wiring: load_platform_dmi_quirks() is callable
today from inputd, thermald, redbear-upower. Each
consumer can filter on rule.subsystem to dispatch the
appropriate behavior. This is a follow-up commit.
Phase R12 (2026-06-07) — DRM panel orientation quirks.
The data side lands now; consumer wiring in redox-drm is
deferred until compositor rotation lands (Phase 4 KDE).
Changes:
1. DrmPanelOrientation enum (mod.rs:225) with four
values: Normal, RightUp, LeftUp, BottomUp. Sourced
from Linux 7.1 include/drm/drm_panel_orientation.h.
Provides from_name() for TOML parsing and as_str()
for logging.
2. DmiDrmPanelQuirkRule (dmi.rs:517) — DMI match + panel
orientation, mirrors the existing DmiAcpiQuirkRule
shape from R11.
3. DMI_DRM_PANEL_QUIRK_RULES (dmi.rs:531) — empty
compiled-in table; runtime TOML is the data surface
(see 50-drm-panel.toml).
4. load_drm_panel_orientation() (dmi.rs:537) — reads
live SMBIOS via read_dmi_info, applies the
compiled-in + TOML rules, returns the orientation.
Falls back to Normal if DMI data is unavailable or
no rule matches.
5. read_toml_drm_panel_entries + parse_drm_panel_toml
(toml_loader.rs) — new [[drm_panel_quirk]] TOML
table type with sub-table +
string. Unknown orientation names log a warning
and skip the entry.
6. load_drm_panel_orientation (toml_loader) — applies
the first matching TOML rule, returns Normal if
none match.
7. 1 new unit test: phase_r12_drm_panel_orientation_from_name_round_trip
exercises all four orientation values + a bogus
name. 123/123 redox-driver-sys tests pass.
8. quirks.d/50-drm-panel.toml (234 lines) — 36 DMI
entries sourced from Linux 7.1
drivers/gpu/drm/drm_panel_orientation_quirks.c.
Covers Acer, Anbernic, Asus, AYA NEO (full range
including 2/2S, 2021, AIR, FLIP, Founder, GEEK,
NEXT, KUN, SLIDE), AYN (Loki Max, Loki Zero),
Chuwi, Dynabook, GPD (MicroPC, WIN Max, Pocket 2/3,
WIN2/3/4, WIN Max 2), Lenovo, OneXPlayer, OrangePi,
Samsung Galaxy Book, Valve Jupiter/Galileo
(Steam Deck family), ZOTAC. The data spans
laptop, tablet, and handheld form factors.
cargo test: 123/123 (was 122, +1 for the new test).
cargo check: clean.
cargo clippy: no new warnings in this code.
Consumer wiring is R12.1 (out of scope for this turn):
redox-drm will call load_drm_panel_orientation() at
connector enumeration time and apply the returned
transform once the compositor supports rotation.
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.
vasilito
vasilito