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.
Alienware 17 (Realtek ALC3661): headphone/aux jack never appears in output picker — jack-sense split across mismatched pin, no live PipeWire switching
Reported by HosseinParahi · filed Aug 28, 2026 · open at source
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
Alienware 17 (board 068R5X, BIOS A16), Realtek ALC3661 (HDA Intel PCH), Omarchy 4.0.1-1, Linux 7.1.9-arch1-2
What's wrong?
Plugging a 3.5mm aux/headphone cable into this laptop never surfaces a selectable
output device, and audio silently keeps going to the internal speaker. pactl/wpctl
show every port (Speakers, Headphones, Headphones 2) with availability unknown
at all times, plugged or not.
Root cause (confirmed via codec dump + amixer)
The ALC3661 exposes two separate "Headphones" pin complexes for what is physically
one jack:
- NID 0x15 ("Headphones", assoc 0x1) — the pin PipeWire picks by default, DAC-routed
and does produce audio, but its Headphone Front Jack ALSA jack-sense control
(amixer -c PCH cget iface=CARD,name='Headphone Front Jack') is permanently
stuck off, plugged or not.
- NID 0x16 ("Headphones 2", assoc 0x2) — also DAC-routed and also produces audio,
and its Headphone Surround Jack control correctly toggles on/off in sync
with the physical plug.
So the BIOS pin table ties real jack-sense to the "wrong" (secondary) pin complex.
Confirmed with cat /proc/asound/card0/codec#0 — both pins showPincap ... Detect and Unsolicited: enabled=1, but only 0x16 ever actually fires.
Separately: WirePlumber's stock alsa.lua monitor (upstream, not Omarchy-specific)
hardcodes api.acp.auto-port = false / api.acp.auto-profile = false for every
ALSA device before any user monitor.alsa.rules are applied. Overriding that back
to true for this card (via a monitor.alsa.rules conf matchingdevice.name = "alsa_card.pci-0000_00_1b.0") did not restore live switching on
unplug/replug — the correct port only ever got picked at WirePlumber startup
(likely from restored session state), not from a live jack event. So even the one
pin complex with working hardware detection never reaches PipeWire as a live signal
on this board.
Workaround
Since even the working jack-sense line (Headphone Surround Jack) never produces a
live PipeWire event, I ended up polling it directly and driving the port switch by
hand — a small systemd --user service that checksamixer -c PCH cget iface=CARD,name='Headphone Surround Jack' once a second and
runs pactl set-sink-port ... analog-output-headphones-2 /... analog-output-speaker accordingly. Works reliably, ~1s latency.
Ask
This is likely too hardware-specific for a built-in fix (similar to #5334), but:
1. A documented troubleshooting path for "jack-sense present but never reaches
PipeWire live" (check /proc/asound/cardN/codec#0 for multiple Headphones pin
complexes with only one wired to Detect, then poll the working one) would save
the next person the multi-hour codec dump investigation.
2. If useful, happy to share the exact monitor.alsa.rules conf + polling script +
systemd unit as a reference workaround, same pattern as #5334's modprobe fix.
Can attach full omarchy-debug output, codec dump, and the poller script on request.
View raw text
### System details
Alienware 17 (board 068R5X, BIOS A16), Realtek ALC3661 (HDA Intel PCH), Omarchy 4.0.1-1, Linux 7.1.9-arch1-2
### What's wrong?
Plugging a 3.5mm aux/headphone cable into this laptop never surfaces a selectable
output device, and audio silently keeps going to the internal speaker. `pactl`/`wpctl`
show every port (`Speakers`, `Headphones`, `Headphones 2`) with `availability unknown`
at all times, plugged or not.
### Root cause (confirmed via codec dump + amixer)
The ALC3661 exposes two separate "Headphones" pin complexes for what is physically
one jack:
- NID 0x15 ("Headphones", assoc 0x1) — the pin PipeWire picks by default, DAC-routed
and does produce audio, but its `Headphone Front Jack` ALSA jack-sense control
(`amixer -c PCH cget iface=CARD,name='Headphone Front Jack'`) is permanently
stuck `off`, plugged or not.
- NID 0x16 ("Headphones 2", assoc 0x2) — also DAC-routed and also produces audio,
and its `Headphone Surround Jack` control correctly toggles `on`/`off` in sync
with the physical plug.
So the BIOS pin table ties real jack-sense to the "wrong" (secondary) pin complex.
Confirmed with `cat /proc/asound/card0/codec#0` — both pins show
`Pincap ... Detect` and `Unsolicited: enabled=1`, but only 0x16 ever actually fires.
Separately: WirePlumber's stock `alsa.lua` monitor (upstream, not Omarchy-specific)
hardcodes `api.acp.auto-port = false` / `api.acp.auto-profile = false` for every
ALSA device before any user `monitor.alsa.rules` are applied. Overriding that back
to `true` for this card (via a `monitor.alsa.rules` conf matching
`device.name = "alsa_card.pci-0000_00_1b.0"`) did *not* restore live switching on
unplug/replug — the correct port only ever got picked at WirePlumber startup
(likely from restored session state), not from a live jack event. So even the one
pin complex with working hardware detection never reaches PipeWire as a live signal
on this board.
### Workaround
Since even the working jack-sense line (`Headphone Surround Jack`) never produces a
live PipeWire event, I ended up polling it directly and driving the port switch by
hand — a small systemd --user service that checks
`amixer -c PCH cget iface=CARD,name='Headphone Surround Jack'` once a second and
runs `pactl set-sink-port ... analog-output-headphones-2` /
`... analog-output-speaker` accordingly. Works reliably, ~1s latency.
### Ask
This is likely too hardware-specific for a built-in fix (similar to #5334), but:
1. A documented troubleshooting path for "jack-sense present but never reaches
PipeWire live" (check `/proc/asound/cardN/codec#0` for multiple Headphones pin
complexes with only one wired to Detect, then poll the working one) would save
the next person the multi-hour codec dump investigation.
2. If useful, happy to share the exact `monitor.alsa.rules` conf + polling script +
systemd unit as a reference workaround, same pattern as #5334's modprobe fix.
Can attach full `omarchy-debug` output, codec dump, and the poller script on request.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 09:43 UTC