> [!IMPORTANT]
> **Correction (updated 2026-10-01):** the spkid1 alias workaround I suggested in [an earlier comment](https://github.com/omacom/omarchy/issues/9687#issuecomment-5501254396) was **wrong — please don't use it**. Struck-through text in this thread is the original, superseded analysis.
>
> The amps reading speaker-ID 0 is a **driver bug, not a real hardware value**: the ACPI GPIO resource contains two speaker-ID pins, but `spk-id-gpios` describes only one, so Linux reads a single bit. With Richard Fitzgerald's (Cirrus) `spi: cs42l43: Workaround for ACPI with wrong spk-id-gpios` patch, this unit reads **spkid2** and loads the existing `10280e53-spkid2` firmware — no aliases needed, sound is correct ([details](https://github.com/omacom/omarchy/issues/9687#issuecomment-5601662946)). Dell's Windows driver also uses the ss2/spkid2 tuning on this hardware ([confirmation](https://github.com/omacom/omarchy/issues/9687#issuecomment-5924862433)).
>
> - Upstream patch: https://lore.kernel.org/linux-spi/[email protected]/
> - Kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=221956
>
> The proper Omarchy fix is to carry that spi-cs42l43 patch in the shipped kernel (or a compatible module package), not firmware aliases. Once a patched kernel is installed, remove any local spkid0 aliases — files in `/usr/lib/firmware/updates/` take precedence.

---

### 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.*