Dell XPS 13 DX13260 (0E54) on Omarchy: issues and workarounds

[samo-fillit]

Dell XPS 13 DX13260 (0E54) on Omarchy: issues and workarounds

Collected on one unit over its first two days on Omarchy (8–9 October 2026). Each issue lists what happened, the evidence, and the workaround now in place. Everything here was applied and checked on this machine unless marked otherwise.

System

Component	Details
Model	Dell XPS 13 DX13260, SKU 0E54, PCI subsystem 1028:0e54, Panther Lake
BIOS	1.6.0
Panel	Sharp SHP5597 (EDID SHP15DD), 2560×1600 at 120 Hz, adaptive sync 30–120 Hz
Audio	Cirrus CS42L43 codec with two CS35L56 Rev B2 amps on SPI (spk:cs35l56-bridge)
Omarchy	4.0.4-1
Kernel	linux-omarchy 7.2.5-3
Firmware	linux-firmware-cirrus 20260810-2, linux-firmware-cirrus-dx13260 20260810-1, sof-firmware 2025.12.2-1
Audio stack	PipeWire 1.6.8, WirePlumber 0.5.17, alsa-ucm-conf 1.2.16.1

Summary

#	Issue	Where it belongs	Status
1	Speakers silent: no tuning for the speaker ID the kernel reads	Omarchy firmware package, kernel	Worked around
2	Display: jittery scrolling, or a purple flickering bar	Kernel display driver, Omarchy hardware fix	Worked around
3	Sound card sometimes fails to start at boot (-16)	Kernel	Open
4	No Omarchy speaker tuning for the XPS 13	Omarchy	Request
5	omarchy-toggle-nightlight can hang callers that read its output (minor)	Omarchy	Worked around

Third-party plugin bugs and minor log messages are listed at the end.

1. Speakers silent: missing tuning for speaker ID 0

What happened. After install the internal speakers were silent. A test tone sent straight to the Speaker sink, bypassing all filters, played nothing. Both amps logged missing firmware:

cs35l56 spi-cs35l56-left: FIRMWARE_MISSING
cs35l56 spi-cs35l56-left: Calibration disabled due to missing firmware controls
cs35l56 spi-cs35l56-left: Can't read tuning IDs

Installing linux-firmware-cirrus-dx13260 (from #14017) did not help. The package ships 10280e54 aliases for speaker IDs 1–3 only, and the current kernel reads speaker ID 0 on this unit. omarchy-pkgs#527 reports that 0E54 units actually have speaker ID 3 and the stock driver misreads it.

Aliasing spkid0 to the spkid1 tuning gave sound, but it was thin. Aliasing it to the spkid3 tuning loads a different tuning and calibration, and both speaker pairs are confirmed working (muting the CS42L43 speaker path audibly changes the output).

Workaround in place. Three links in /usr/lib/firmware/updates/cirrus/, matching the package's own spkid3 targets:

cs35l56-b2-dsp1-misc-10280e54-spkid0.wmfw.zst     -> ../../cirrus/cs35l56/CS35L56_Rev4.5.9.wmfw.zst
cs35l56-b2-dsp1-misc-10280e54-spkid0-ampl.bin.zst -> ../../cirrus/cs35l56-b2-dsp1-misc-10280e53-spkid3-ampl.bin.zst
cs35l56-b2-dsp1-misc-10280e54-spkid0-ampr.bin.zst -> ../../cirrus/cs35l56-b2-dsp1-misc-10280e53-spkid3-ampr.bin.zst

The amps load firmware early in boot, so the same three paths go into the initramfs through /etc/mkinitcpio.conf.d/dell-xps13-ptl-spkid0.conf:

FILES+=(
  /usr/lib/firmware/updates/cirrus/cs35l56-b2-dsp1-misc-10280e54-spkid0.wmfw.zst
  /usr/lib/firmware/updates/cirrus/cs35l56-b2-dsp1-misc-10280e54-spkid0-ampl.bin.zst
  /usr/lib/firmware/updates/cirrus/cs35l56-b2-dsp1-misc-10280e54-spkid0-ampr.bin.zst
)

then sudo limine-mkinitcpio and a reboot. Result:

cs35l56 spi-cs35l56-left: DSP1: cirrus/cs35l56-b2-dsp1-misc-10280e54-spkid0-ampl.bin (v1): v4.5.9
cs35l56 spi-cs35l56-right: Calibration applied
cs35l56 spi-cs35l56-left: Calibration applied

Suggestion. Ship the speaker-ID fix from omarchy-pkgs#527. Until then, spkid0 aliases pointing at the spkid3 tuning in linux-firmware-cirrus-dx13260 would make 0E54 units like this one work out of the box. We will remove these links once the kernel fix lands.

2. Display: jittery scrolling or a purple flickering bar

What happened. On stock settings, scrolling and animations are visibly jittery on the built-in panel. #12297 proposed disabling Panel Replay and PSR2 selective fetch for this panel, but that PR was closed without being merged, so stock Omarchy has neither setting.

Disabling Panel Replay cures the jitter but brings a new artefact: a flickering purple vertical bar, the full height of the screen, about one fifth of the way in from the right edge.

• The bar is not in screenshots (12 grim captures, scanned per column), so it is introduced after composition.
• It does not appear in the BIOS setup screen.
• It does appear on the disk-unlock screen, before Hyprland starts.
• Any full modeset clears it: switching eDP-1 to 90 Hz or 60 Hz and back to 120 Hz removes it until the next boot.
• It returns after every boot and after suspend.
• The panel accepts 90 Hz and 60 Hz as custom modes, although its EDID lists only 120 Hz.

Kernel parameter combinations tested:

Kernel parameters	Scrolling	Purple bar
none (stock)	Jittery	No
xe.enable_psr2_sel_fetch=0	Jittery	No
xe.enable_panel_replay=0	Smooth	Yes
xe.enable_psr2_sel_fetch=0 xe.enable_panel_replay=0 (as in #12297)	Smooth	Yes
xe.enable_psr=0 plus both of the above	Smooth	Yes
xe.enable_panel_replay=0 with Hyprland misc.vrr = 1	Jittery	Not checked

Panel Replay itself seems to cause the jitter. With it off, the driver's boot-time takeover of the firmware's display state looks like the source of the bar, since a fresh modeset fixes it.

Workaround in place.

Kernel parameter, in /etc/limine-entry-tool.d/dell-xps13-ptl-display.conf:

KERNEL_CMDLINE[default]+=" xe.enable_panel_replay=0"

A modeset after login, ~/.local/bin/xps-panel-reset:

#!/bin/bash
sleep 3
hyprctl eval 'hl.monitor({ output = "eDP-1", mode = "2560x1600@90", position = "0x0", scale = 2 })' >/dev/null
sleep 1
hyprctl eval 'hl.monitor({ output = "eDP-1", mode = "preferred", position = "0x0", scale = 2 })' >/dev/null

The same reset after waking from suspend, ~/.local/bin/xps-panel-reset-on-wake:

#!/bin/bash
gdbus monitor --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 |
  while read -r line; do
    [[ $line == *"PrepareForSleep (false"* ]] && "$HOME/.local/bin/xps-panel-reset" &
  done

Both start from ~/.config/hypr/autostart.lua:

o.exec_on_start(os.getenv("HOME") .. "/.local/bin/xps-panel-reset")
o.exec_on_start(os.getenv("HOME") .. "/.local/bin/xps-panel-reset-on-wake")

The login reset is confirmed to clear the bar. The wake reset was added after the bar was seen returning from suspend and had not yet been tested across a sleep when this was written. The bar still shows on the disk-unlock screen.

Suggestion. This looks like an xe display driver issue with this panel on Panther Lake. It would be worth reopening #12297 with this data, since its fix trades the jitter for the bar on this unit.

3. Sound card sometimes fails to start at boot

What happened. On 2 of 5 boots on the first day, the SoundWire card failed to instantiate and only a Dummy Output was available until the next reboot. It happened both before and after the firmware workaround:

cs35l56 spi-cs35l56-left: Failed to schedule write: -16
cs35l56 spi-cs35l56-left: ASoC error (-16): at snd_soc_pcm_dai_probe() on cs35l56-asp1
sof_sdw sof_sdw: ASoC: failed to instantiate card -16

Workaround. None beyond rebooting, which has fixed it every time. This matches the probe race described in #10987 for the 0E53.

4. No Omarchy speaker tuning for the XPS 13

omarchy audio tuning status reports "nothing ships for this laptop". The dell-xps-2026 tuning matches SKUs 0DB9 and 0DBA (XPS 14 and 16) only. With the correct Cirrus tuning loaded, the XPS 13 speakers still sound noticeably thinner than on Windows, where Waves processing runs on top.

Request. An XPS 13 DX13260 profile (0E53 and 0E54). We did not borrow the XPS 14 profile, since it is fitted to different speakers.

5. omarchy-toggle-nightlight can hang callers that read its output (minor)

Stock Omarchy is not affected: its keybinding and menu do not read the toggle's output. We hit this through a third-party plugin, OmaSettings, and the fix is a one-liner on either side.

What happened. When hyprsunset is not running, the toggle starts it with setsid uwsm-app -- hyprsunset &. The new hyprsunset inherits the caller's stdout and stderr. Any caller that reads the toggle's output waits for end-of-file and never gets it while hyprsunset runs.

In OmaSettings, the first click turned night light on, then the settings window stayed busy for over ten minutes and ignored later clicks. The stuck command's output pipe was held open by /usr/bin/hyprsunset.

Workaround in place. The caller now discards the toggle's output:

omarchy-toggle-nightlight </dev/null >/dev/null 2>&1

Suggestion. Start hyprsunset with its standard streams redirected inside omarchy-toggle-nightlight, for example setsid uwsm-app -- hyprsunset </dev/null >/dev/null 2>&1 &, the way the shell's own nightlight service already does.

Third-party plugins (for their authors)

• Parametric EQ (prudhviy99/omarchy-parametric-eq 1.0.1). Turning the EQ on crash-loops WirePlumber 0.5.17 (no adapter factory found, then start-limit-hit), which removes every audio device. The generated libpipewire-module-filter-chain component needs requires = [ pw.node-factory.adapter ]. Patched locally.
• OmaSettings (twiking/omasettings 1.3.0). The night light hang from issue 5: set nightlight runs omarchy-toggle-nightlight while its output is piped, so the window waits forever once hyprsunset starts. Patched locally in lib/setters.sh with the redirect shown above.
• Slack desktop 4.52 (AUR slack-desktop). Huddle camera feed is choppy and the huddle window laggy. System checks were fine: native Wayland, GPU rendering, camera in MJPEG 720p at 30 fps. Slack itself sends 640×384 at 15 fps.

Minor log messages (no visible effect so far)

• ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed. Charging works normally at about 47 W.
• ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - \_SB_.IETM.TFN1, repeated at boot.
• xe 0000:00:02.0: [drm] not enough stolen space for compressed buffer (need 35389440 more bytes), disabling.

[samo-fillit]

on omacom/omarchy#11356, the XPS 13 silent-speaker issue: “on my 0E54 the real speaker ID is 3; aliasing spkid0 to the spkid3 tuning fixed it.”

[samo-fillit]

on omacom/omarchy#12297, the display fix: “this fix causes a purple flickering bar on my unit,” with the test table.