The redbear-full desktop target now pulls in pipewire and wireplumber
as the audio backend for KDE Plasma (Phonon, KMix, the Plasma audio
widget). This wires up the packages built by the new
local/recipes/libs/pipewire and local/recipes/libs/wireplumber
recipes on top of the existing audiod scheme daemon in the base
package.
Changes:
* config/redbear-full.toml
- new [packages] entries for pipewire and wireplumber
- two new [[files]] init services: 15_pipewire.service and
16_wireplumber.service (both oneshot_async, depend on
12_dbus.service)
* local/recipes/system/redbear-dbus-services/files/
- new org.freedesktop.PipeWire.service (system bus, runs
/usr/bin/pipewire) and org.pulseaudio.Server.service
(system bus, runs /usr/bin/pipewire-pulse)
- new org.freedesktop.impl.pulseaudio.service (session bus,
runs /usr/bin/pipewire-pulse) for KDE Phonon / KMix
- matching .conf policy files for org.freedesktop.PipeWire
and org.pulseaudio.Server that allow the expected
Introspectable / Properties / *Manager / *Node / *Link /
*Client / *Device / *Meter / *Core / *Port send and
receive patterns
* config/protected-recipes.toml
- new [libs] entries for pipewire and wireplumber, so the
cookbook never silently re-fetches them; sources are
directly editable in local/sources/
* recipes/wip/services/{pipewire,wireplumber}
- replaced the tracked WIP directories with symlinks to
local/recipes/libs/{pipewire,wireplumber}, per the
local-over-WIP convention enforced by
local/scripts/build-redbear.sh
Known build state (documented in the upstream README-redbear.md
files in each source fork):
* pipewire build reaches ~24/603 C files compiled before
hitting relibc gaps (sys/prctl.h, sys/mount.h, and a few
Linux-specific ioctls). The recipe, source fork, and
Redox-compat shims are in place; the remaining work is
upstream relibc headers, not PipeWire porting decisions.
* wireplumber recipe is in place but the build has not been
attempted yet — wireplumber depends on the pipewire build
completing first.
The audiod integration (the scheme backend that pipewire would
talk to) is not implemented in this commit. That is the next
gating work item and is tracked in
local/sources/pipewire/README-redbear.md.
The StubBackend returned hardcoded SSIDs ("demo-ssid", "demo-open")
and synthesised connection outcomes without ever touching the iwlwifi
driver or netstack. This was a stub that hid the real work needed to
control Intel Wi-Fi devices on Redox.
This commit removes the StubBackend entirely and renames the existing
real PCI/iwlwifi-aware backend from IntelBackend to IwlwifiBackend.
The renamed backend is the default; when no Intel Wi-Fi device is
detected, the NoDeviceBackend is selected (which is the legitimate
"no hardware present" path, not a stub).
Backend mode selection (in main.rs):
- REDBEAR_WIFICTL_BACKEND=iwlwifi|no-device: explicit override
- redox runtime + iwlwifi driver + Intel interface detected: Iwlwifi
- everything else: NoDevice (no silent stub fallback)
The IwlwifiBackend talks to /usr/lib/drivers/redbear-iwlwifi via the
existing Command-based action plumbing (--prepare, --init-transport,
--activate-nic, --scan, --connect, --disconnect, --retry, etc.), which
in turn maps BAR0 MMIO, loads ucode/pnvm, and drives the iwlwifi
device. The previously-stripped stub output paths (firmware=stub,
transport=stub, transport_init=stub, connect=stub, disconnect=stub)
are gone; every status field is now sourced from the real driver or
returned as an honest error from NoDeviceBackend.
Version bumped 0.1.0 -> 0.2.3.
Tests:
- 17 unit tests pass on host target (replaced 4 stub_* tests with
no_device_* and iwlwifi_transport_probe_honors_driver_action).
- 2 CLI integration tests pass (cli_transport.rs unchanged).
- cargo test 19/19 green.
- ./target/release/repo cook redbear-wifictl: successful; produces
repo/x86_64-unknown-redox/redbear-wifictl.pkgar and .toml with
version 0.2.3.
The 4 service files (org.kde.ksmserver, org.kde.JobViewServer,
org.kde.ActivityManager, org.freedesktop.StatusNotifierWatcher)
existed in local/recipes/system/redbear-dbus-services/files/ but were
never mirrored into source/ where the build actually reads in offline
mode. This meant only 3 of the 7 session-service activation files
reached the staged package.
Also fix org.kde.kglobalaccel.service to point at the real install
location: kglobalacceld is installed to /usr/libexec/ (KDE_INSTALL_LIBEXECDIR),
not /usr/bin/.
Sync files/session-services/org.kde.kded6.service to the offscreen-QPA
wrapper that the build was already shipping from source/.
Build now stages all 7 session-service files plus 4 system-services
and 4 policy files (15 dbus config files total).
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).
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().
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'.
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).
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).
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.
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.
Phase R11 (2026-06-07) — ACPI DMI data side. Four runtime
TOML files land in quirks.d/, each populated with
real Linux 7.1 DMI table entries:
45-acpi-osi.toml — currently empty (no rules landed;
placeholder for concrete hardware
bugs to be added on real targets)
46-acpi-sleep.toml — 13 entries from sleep.c
(HP xw4600, ASUS M2N8L, Matsushita
CF51-2L, ASUS A8N-SLI DELUXE,
Sony VAIO VGN-FW/VPC series,
Everex StepNote, AVERATEC 1000)
covering SLEEP_OLD_ORDERING and
SLEEP_NVS_NOSAVE
47-acpi-button.toml — 4 entries from button.c (Insyde
T701, CherryTrail M882, Lenovo 82BG,
MEDION E2215T) covering LID_INIT
flags
48-acpi-battery.toml — 1 entry from battery.c (NEC
LZ750/LS) covering BATTERY_BIX_BROKEN
Each entry uses the new [[dmi_acpi_quirk]] table type
landed in the previous commit (5d06b0fa0). The
match sub-table is the same DmiMatchRule shape
used by [[dmi_system_quirk]] and [[dmi_xhci_system_quirk]]
(sys_vendor, product_name, board_vendor, board_name,
bios_version, etc).
The data covers 18 DMI rules total. Per the audit,
the compiled-in DMI_ACPI_QUIRK_RULES table stays
empty — runtime TOML is the data surface. As more
hardware bugs are reported on real Red Bear targets,
new entries can be appended to these files without
rebuilding.
Consumer-side: no consumer reads AcpiQuirkFlags yet.
The lookup is wired through load_dmi_acpi_quirks()
which is callable from any acpid / acpi-handler
process. Wiring the consumer is R12.
R1-R10 audit Gap 10: evdevd had zero HID quirk consumption.
The lookup_hid_quirks entry point in redox-driver-sys was
populated by R10 with 191 compiled-in entries + TOML
support, but no consumer read it. Every InputDevice entering
the evdev scheme flew past the HID quirk table.
This change:
- Adds a redox-driver-sys path dependency to
source/Cargo.toml. Path mirrors the depth used by
pcid/usbhidd (4 ../ levels to reach local/, then
recipes/drivers/redox-driver-sys/source).
- Adds source/src/quirks.rs with one public function,
log_hid_quirks(vendor, product, kind), that calls
lookup_hid_quirks and emits an info-level line on a
non-empty result, debug-level on empty.
- Wires the call into EvdevScheme::add_device() at the
moment the InputDevice is created, before it is pushed
onto the device list.
- Adds 'mod quirks' to main.rs module declarations.
Caveat (carried forward from the audit, 2026-06-07):
evdevd currently constructs InputDevice with vendor=0
because the upstream usbhidd produces orbclient::Event
streams without forwarding the real USB vendor/product
IDs. The lookup therefore returns empty flags in
practice. Once the orbclient event pipe is extended to
carry the device IDs, the wiring below will start
logging the matched flag sets without any further code
change. This is documented in the module-level docstring
of quirks.rs.
4 unit tests cover the wiring:
- synthetic zero-vendor returns empty
- synthetic product IDs 0..32 return empty (these are
the IDs evdevd currently assigns)
- a real Linux HID table entry (0x06d6:0x0025 → BADPAD)
returns the expected flag
- the log helper does not panic on any input
Note on pre-existing test errors: cargo test fails to
compile the test binary because of unrelated errors in
src/translate.rs:517,534 and src/gesture.rs:1 (a
'translate_gesture' function that no longer exists).
These pre-date this change and are out of scope for
Gap 10. cargo check is clean (zero new warnings from
this change); the failing tests are in the existing
scheme.rs and device.rs test modules that have nothing
to do with the new quirks module.
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.
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.
Kernel has a use-after-free bug in sys_read triggered by /scheme/sys/msr
access. The probe guard prevents most crashes but the kernel bug can still
trigger during MSR read paths. Removing the MSR fallback eliminates this
crash path entirely. Vendor detection now uses /scheme/sys/cpu only.
cpufreqd:
- Read CPU vendor and frequency from /scheme/sys/cpu (CPUID-based)
- Generate P-states dynamically from detected max/base frequency
- Remove hardcoded 2400-1200 kHz fallback table
- Intel SpeedStep and AMD encoding support
coretempd:
- Detect vendor from /scheme/sys/cpu before MSR probing
- Read CPU count from /scheme/sys/cpu for accuracy
- Fall back to MSR detection only when platform info unavailable
On QEMU's default i440FX machine type, rdmsr on unsupported MSRs
(0x19c IA32_THERM_STATUS, 0x1a2 IA32_TEMPERATURE_TARGET) causes a
kernel #GP that kills the process. Same pattern as cpufreqd: spawn a
child with --probe-msr to test readability before the main loop. If
probe fails, disable all MSR reads and report all CPUs as Unknown.
- 29_activate_console.service: oneshot -> oneshot_async (unblocks init
scheduler, enabling getty 2 -> login)
- 15_coretempd.service: oneshot_async -> {scheme="coretemp"} (init
now correctly registers the scheme fd)
- cpufreqd: child-process MSR probe detects QEMU's lack of MSR 0x199
and gracefully degrades to monitoring-only mode
- coretempd: notification failure is now non-fatal (WARN instead of ?)
- driver-manager: "no match entries" downgraded from warn to debug
(infrastructure daemons intentionally have no hw match)
- Skip binary existence check in probe(): Redox scheme paths
(especially /scheme/initfs/) may block on open/stat indefinitely.
Command::new() spawn fails cleanly if binary missing.
- In initfs mode: use synchronous probe, do bounded deferred
retries, then exit. Rootfs instance handles hotplug.
- Avoids pcid config handle read hang that blocks async threads.
Three fixes for the KWin DRM device discovery failure:
1. drm_scheme_ready(): replace head -c 1 with exec 3< open test.
Reading from a DRM scheme fd blocks because the scheme expects
ioctl-style request/response, not streaming reads. Use open()
success as the scheme availability probe instead.
2. ConsoleKitSession::create(): return nullptr immediately.
The D-Bus isServiceRegistered() call can block indefinitely when
the bus daemon doesn't fully implement org.freedesktop.DBus.
With both LogindSession and ConsoleKitSession returning nullptr,
Session::create() falls through to NoopSession which uses plain
open() for DRM device access.
3. Boot chain deps: redox-drm depends on driver-manager,
greeter depends on evdevd (keyboard/mouse ready before login).
Also includes: KF6 CMake build fixes, Qt6 platform patches,
libdrm Redox ioctl shim, and wayland.toml scheme check fix.
Reads from /scheme/acpi/thermal/, /scheme/acpi/fan/, and /scheme/acpi/cstates/
plus /scheme/sys/cstate_policy to populate the --health dashboard with
hardware thermal status, fan activity, and CPU power-management state.
- Add intel_vtd.rs module with DMAR parsing, DRHD discovery,
register definitions, and basic unit initialization
- Update iommu daemon discovery to detect both AMD-Vi (IVRS)
and Intel VT-d (DMAR) units
- Update IommuScheme to track both amd_units and intel_units
- Intel VT-d init: version check, capability read, disable
translation, report supported features (QI, IR, EIM)
Full DMA remapping enablement (root table, context entries,
page tables, command buffer) remains as TODO for follow-up.
Detect CPU vendor by probing MSRs (Intel IA32_THERM_STATUS vs AMD
TCTL MSR C0010293). Support both Intel Tjmax-based and AMD direct
temperature reading. Log detected vendor per CPU at startup.
New local recipe coretempd reads IA32_THERM_STATUS MSR via the
new sys:msr scheme and exposes per-CPU temperatures via scheme:coretemp.
- Reads IA32_THERM_STATUS (0x19C) and IA32_TEMPERATURE_TARGET (0x1A2)
- Calculates Celsius from digital readout relative to TjMax
- Exposes /scheme/coretemp/ directory with per-CPU temperature files
- Added to redbear-mini.toml (inherited by redbear-full)
- Added 15_coretempd.service init file
vasilito
Vasili