Dell XPS 13 (DX13260, SKU 0E53): internal speakers quiet and tinny — CS35L56 sidecar amps never enabled, and no spkid0 firmware for this SKU

[bicyclesandbarbecue]

Summary

On a 2026 Dell XPS 13 (product XPS 13 DX13260, PCI SSID / DMI SKU 1028:0e53, Wildcat Lake), Omarchy 4.0.1 on kernel 7.1.9 plays speaker audio through the CS42L43 codec's low-power direct output. The two Cirrus CS35L56 amplifiers probe and bind but are never added to the sound card, so speakers are audibly quiet and thin.

Two separate gaps are involved. Both have userspace workarounds that Omarchy could carry the same way it carries per-model speaker tunings, until upstream catches up.

Gap 1 — kernel quirk table (fixed upstream, missing in 7.1.9)

Mainline sound/soc/intel/boards/sof_sdw.c has:

SND_PCI_QUIRK(0x1028, 0x0e53, "Dell XPS WCL", SOC_SDW_SIDECAR_AMPS),

Kernel 7.1.9 ships the full sidecar implementation (asoc_sdw_bridge_cs35l56_add_sidecar etc. in snd-soc-sdw-utils) but not that table entry. Symptoms: No SoundWire machine driver found for the ACPI-reported configuration, fallback to sof-sdca-1amp-id2.tplg, zero AMPL/AMPR ALSA controls, snd_soc_cs35l56_spi usecount 0.

Workaround (reproduces mainline exactly, no rebuild):

# /etc/modprobe.d/sof-sdw-xps13.conf
options snd_soc_sof_sdw quirk=65536    # SOC_SDW_SIDECAR_AMPS = BIT(16)

After reboot: Overriding quirk 0x1 => 0x10000, both amps join the card (24 AMPL/AMPR controls, usecount 2, DSP1: Firmware: 1a00d6 ... 42 algorithms).

Gap 2 — no speaker-ID 0 firmware in linux-firmware (still open)

With the amps enabled, playback is completely silent until DSP firmware loads, because the CS35L56 audio path runs through its DSP. The driver reads Speaker ID = 0 and requests:

cirrus/cs35l56-b2-dsp1-misc-10280e53-spkid0.wmfw   -> ENOENT

linux-firmware 20260810 ships only spkid1, spkid2, spkid3 for 10280e53, while every other Dell SKU in the package ships a spkid0. There is no module parameter to override the ID.

Workaround: symlink spkid0 to one of the shipped variants:

cd /lib/firmware/cirrus
ln -s cs35l56-b2-dsp1-misc-10280e53-spkid1.wmfw.zst      cs35l56-b2-dsp1-misc-10280e53-spkid0.wmfw.zst
ln -s cs35l56-b2-dsp1-misc-10280e53-spkid1-ampl.bin.zst  cs35l56-b2-dsp1-misc-10280e53-spkid0-ampl.bin.zst
ln -s cs35l56-b2-dsp1-misc-10280e53-spkid1-ampr.bin.zst  cs35l56-b2-dsp1-misc-10280e53-spkid0-ampr.bin.zst

Result: firmware loads, Calibration applied on both amps from the CirrusSmartAmpCalibrationData EFI variable, and sound is dramatically better. Which of spkid1/2/3 matches the fitted speakers is unknown; 1 sounds good and is usable.

Notes for Omarchy

• omarchy audio tuning only matches SKUs 0DB9/0DBA (XPS 14/16); 0E53 matches nothing and --force does not override the SKU test. A tuning entry is not the fix here — the missing amplifier is.
• Both workarounds are one file each and could ship as a hardware-specific migration keyed on SSID 1028:0e53, like the existing Dell audio handling.

Possibly relevant

omarchy#6001 (ThinkPad X1 Gen 14, missing CS42L45 topology) turned out to be resolved by a BIOS update once the upstream pieces landed. It is possible Dell will ship the missing speaker-ID handling or a BIOS-side firmware preload the same way; this machine is on BIOS 1.3.0 (06/25/2026) and fwupd is not installed on Omarchy by default, so LVFS has not been checked yet.

System details

Omarchy 4.0.1-1 · linux 7.1.9-arch1-2 · linux-firmware 20260810-2 · sof-firmware 2025.12.2-1 · alsa-ucm-conf 1.2.16.1-1 · BIOS 1.3.0 (06/25/2026) · PipeWire 1.6.8

[adenta]

I think this is a bios issue

I’m using the same spkid0 → spkid1 workaround on an XPS 13 DX13260, SKU 0E53. The speakers sound much better, but I noticed a change after updating BIOS 1.3.0 → 1.6.0.
Before the BIOS update, both CS35L56 amplifiers logged:
Calibration applied
Afterward:

• Both still load firmware v4.5.9 and report the same tuning IDs.
• Neither logs Calibration applied.
• This EFI variable is no longer present:/sys/firmware/efi/efivars/CirrusSmartAmpCalibrationData-02f9af02-7734-4233-b43d-93fe5aa35db3
• The behavior persists across reboots, although the speakers still sound normal.
  The kernel remained 7.2.3-arch1-3, and linux-firmware-cirrus remained 20260810-2 across the BIOS update.

Has anyone running BIOS 1.6.0 checked whether that variable exists and whether both amplifiers still report calibration being applied? I’m trying to determine whether the update changed how factory calibration is exposed to Linux, and whether there’s a documented recovery procedure. I haven’t established that the data was erased.