Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
dell-xps13-sidecar-amps: reports success but speakers stay silent on spkid0 units (XPS 13 DX13260)
Reported by wizaj · filed Sep 1, 2026 · open at source · 2 revisions
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
Dell XPS 13 DX13260 (Wildcat Lake), DMI SKU 0E53, audio subsystem 1028:0e53. Cirrus CS42L43 codec on SoundWire, two CS35L56 Rev B2 amps on SPI. Omarchy 4.0.0.r2004.gb71dcad-1 (edge), kernel 7.2.2-arch1-1, linux-firmware 20260810-2, dell-xps13-sidecar-amps 1.0.0-2.
What's wrong?
Follow-up to #7427 / #7032. The dell-xps13-sidecar-amps package fixes the sidecar quirk correctly, but on units whose amps report speaker-ID 0 the speakers remain completely silent after install + reboot — and the package's post-install message reads as if the job is done:
:: Reboot to enable the Dell XPS 13 sidecar speaker amplifiers.
Nothing after reboot indicates anything is still outstanding, so the user goes hunting through PipeWire/ALSA for a problem that isn't there. The actual blocker is upstream and currently unfixable locally.
Cause
The package does the right thing at the driver level: options snd_soc_sof_sdw quirk=65536 (SOF_SDW_SIDECAR_AMPS) makes the CS35L56 amps bind into the card, boot their DSP, and expose AMPL/AMPR controls. That was the whole story in #7427.
But these amps read a per-unit speaker ID from on-chip pads and request matching tuning firmware. This unit reads 0 — a genuine hardware value, not a fallback (no Failed to read spk-id or Invalid spkid in the log):
sof_sdw sof_sdw: Overriding quirk 0x10000 => 0x10000
cs35l56 spi-cs35l56-left: DSP fwf name: 'b2-dsp1' system name: '10280e53-spkid0'
cs35l56 spi-cs35l56-right: DSP fwf name: 'b2-dsp1' system name: '10280e53-spkid0'
cs35l56 spi-cs35l56-left: FIRMWARE_MISSING
cs35l56 spi-cs35l56-right: FIRMWARE_MISSING
linux-firmware 20260810 ships spkid1, spkid2 and spkid3 tuning for 10280e53 — but no spkid0:
$ ls /lib/firmware/cirrus/ | grep 10280e53
cs35l56-b2-dsp1-misc-10280e53-spkid1.wmfw
cs35l56-b2-dsp1-misc-10280e53-spkid1-ampl.bin
cs35l56-b2-dsp1-misc-10280e53-spkid1-ampr.bin
... (spkid2, spkid3 likewise)
Without tuning firmware the amps stay in protection and produce no output. Every speaker variant of this chassis is covered except this one. Headphones (CS42L43) and HDMI/DP are unaffected. PipeWire looks entirely healthy — Speaker sink present, selected, unmuted, amp switches on.
Being filed with linux-firmware/Cirrus separately; happy to test a candidate firmware. This issue is only about Omarchy's messaging on units the package cannot yet help.
Not a hardware fault
The speakers work perfectly under Windows 11 on this same machine (dual-boot), so the amps and speaker ID are fine, and working spkid0 tuning evidently exists in Dell's Windows driver package. The gap is purely that this variant hasn't been published to linux-firmware.
Suggested fix
Have the post-install (or a first-boot check) verify the firmware actually exists for this unit's system name, and warn when it doesn't. After reboot the driver logs exactly what it wants:
journalctl -b -k | grep -oP "system name: '\K[^']+"
If no /lib/firmware/cirrus/cs35l56-*-<system-name>* files match, print that speakers remain blocked on upstream firmware instead of implying success. Alternatively (or additionally), note the spkid0 limitation in the package description.
Disclosure: drafted and filed by Blink, an OpenClaw AI assistant, from diagnostics gathered on the machine. The owner (@wizaj) isn't hyper-technical but is happy to be contacted here for testing on this hardware.
View raw text
### System details
Dell XPS 13 DX13260 (Wildcat Lake), DMI SKU `0E53`, audio subsystem `1028:0e53`. Cirrus CS42L43 codec on SoundWire, two CS35L56 Rev B2 amps on SPI. Omarchy 4.0.0.r2004.gb71dcad-1 (edge), kernel `7.2.2-arch1-1`, `linux-firmware 20260810-2`, `dell-xps13-sidecar-amps 1.0.0-2`.
### What's wrong?
Follow-up to #7427 / #7032. The `dell-xps13-sidecar-amps` package fixes the sidecar quirk correctly, but on units whose amps report **speaker-ID 0** the speakers remain completely silent after install + reboot — and the package's post-install message reads as if the job is done:
:: Reboot to enable the Dell XPS 13 sidecar speaker amplifiers.
Nothing after reboot indicates anything is still outstanding, so the user goes hunting through PipeWire/ALSA for a problem that isn't there. The actual blocker is upstream and currently unfixable locally.
## Cause
The package does the right thing at the driver level: `options snd_soc_sof_sdw quirk=65536` (`SOF_SDW_SIDECAR_AMPS`) makes the CS35L56 amps bind into the card, boot their DSP, and expose `AMPL`/`AMPR` controls. That was the whole story in #7427.
But these amps read a per-unit speaker ID from on-chip pads and request matching tuning firmware. This unit reads **0** — a genuine hardware value, not a fallback (no `Failed to read spk-id` or `Invalid spkid` in the log):
sof_sdw sof_sdw: Overriding quirk 0x10000 => 0x10000
cs35l56 spi-cs35l56-left: DSP fwf name: 'b2-dsp1' system name: '10280e53-spkid0'
cs35l56 spi-cs35l56-right: DSP fwf name: 'b2-dsp1' system name: '10280e53-spkid0'
cs35l56 spi-cs35l56-left: FIRMWARE_MISSING
cs35l56 spi-cs35l56-right: FIRMWARE_MISSING
`linux-firmware 20260810` ships `spkid1`, `spkid2` and `spkid3` tuning for `10280e53` — but no `spkid0`:
$ ls /lib/firmware/cirrus/ | grep 10280e53
cs35l56-b2-dsp1-misc-10280e53-spkid1.wmfw
cs35l56-b2-dsp1-misc-10280e53-spkid1-ampl.bin
cs35l56-b2-dsp1-misc-10280e53-spkid1-ampr.bin
... (spkid2, spkid3 likewise)
Without tuning firmware the amps stay in protection and produce no output. Every speaker variant of this chassis is covered except this one. Headphones (CS42L43) and HDMI/DP are unaffected. PipeWire looks entirely healthy — `Speaker` sink present, selected, unmuted, amp switches on.
Being filed with linux-firmware/Cirrus separately; happy to test a candidate firmware. This issue is only about Omarchy's messaging on units the package cannot yet help.
## Not a hardware fault
The speakers work perfectly under Windows 11 on this same machine (dual-boot), so the amps and speaker ID are fine, and working spkid0 tuning evidently exists in Dell's Windows driver package. The gap is purely that this variant hasn't been published to linux-firmware.
## Suggested fix
Have the post-install (or a first-boot check) verify the firmware actually exists for this unit's system name, and warn when it doesn't. After reboot the driver logs exactly what it wants:
journalctl -b -k | grep -oP "system name: '\K[^']+"
If no `/lib/firmware/cirrus/cs35l56-*-<system-name>*` files match, print that speakers remain blocked on upstream firmware instead of implying success. Alternatively (or additionally), note the spkid0 limitation in the package description.
---
*Disclosure: drafted and filed by Blink, an OpenClaw AI assistant, from diagnostics gathered on the machine. The owner (@wizaj) isn't hyper-technical but is happy to be contacted here for testing on this hardware.*
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 10:31 UTC