quine-global-labs/quine-linux
1
1
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions 1

Document iMac19,2 speaker silence and Chromium D-Bus activation gap

Browse source 
Adds docs/imac19-2-speaker-fix.md: internal speakers produce no sound
despite correct HDA-level plumbing (unmuted volume, enabled pin, clean
device open). Traces the likely cause to uninitialized external TAS5764L
amp chips and a CS42L83 companion codec behind the CS8409, via sibling-
model prior art (rojoxstar/imac19-2-cs8409-linux, egorenar/snd-hda-codec-
cs8409#31, network-garden-lab's Fedora-specific iMac18,3 patch). No fix
is packaged yet given the amp-register damage risk and the bigger lift
of patching in-tree kernel source rather than an out-of-tree module.

Also adds docs/chromium-dbus-singleton-activation.md and a new "Software
fork directions" README section indexing forward-looking fork/patch
write-ups separately from the hardware-specific patches already shipped.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Philip Peterson 2026-09-29 23:19:34 -08:00
parent a3316eb2a4
commit 30d15773a6
3 changed files with 310 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
README.md
View file

@ -114,3 +114,18 @@ anywhere else in this repo:
and current verification status.
- `patches/snd-hda-codec-cs8409/` — the vendored driver source and patch
backing that fix, built into `Containerfile`'s `kmod-builder` stage.
- [`docs/imac19-2-speaker-fix.md`](docs/imac19-2-speaker-fix.md) — the
internal speakers on iMac19,2 producing no sound at all; investigation and
prior-art writeup, no fix packaged yet.
## Software fork directions
Write-ups of problems found on this image that point at a fork/patch of an
upstream project, kept here before anyone's had time to act on them:
- [`docs/patched-anaconda-installer.md`](docs/patched-anaconda-installer.md)
— active: how to get a forked/patched Anaconda into the install ISO.
- [`docs/chromium-dbus-singleton-activation.md`](docs/chromium-dbus-singleton-activation.md)
— not started: Chromium lacks D-Bus activation, so KDE + Flatpak can't
dedupe a slow-starting launch, and repeated launcher clicks stack up full
duplicate browser instances instead of forwarding to the existing one.

84
docs/chromium-dbus-singleton-activation.md Normal file
View file

@ -0,0 +1,84 @@
# Chromium D-Bus singleton activation (future fork direction)
Not started -- this is a write-up of a problem observed on this machine and
the shape a fix would take in a Chromium fork, kept here so the idea isn't
lost before anyone has time to act on it. Unlike
[`docs/patched-anaconda-installer.md`](patched-anaconda-installer.md), there
is no fork yet.
## Symptom
`flatpak run org.chromium.Chromium`, launched from KDE Plasma's task
manager, appeared to hang indefinitely. What actually happened: the first
launch was slow to map its first window (cold profile/cache, GPU process
init). Re-clicking the launcher icon while waiting didn't focus/wait on that
in-progress launch -- it ran the `.desktop` file's `Exec=` line again. This
repeated a handful of times, producing five fully independent Chromium
process trees (each with its own zygote, GPU process, network/storage
service, and renderers) all fighting over the same CPU cores, disk cache,
and `/dev/dri/renderD128`, which made every one of them even slower to
start -- compounding into what looked like a permanent hang.
## Root cause
Two things stacked:
1. **KDE's task manager has no way to know a launch is in flight** without
the freedesktop startup-notification protocol or an existing window to
match against. With neither available yet, a second click is
indistinguishable from a fresh launch request.
2. **Chromium doesn't use D-Bus activation.** On Linux it implements its own
legacy singleton check (a lock file + Unix domain socket handshake, see
`chrome/browser/process_singleton_posix.cc` upstream) that predates
`org.freedesktop.Application`. That handshake is timeout-based: if the
already-running instance doesn't answer fast enough (because it's still
starting up, or because Flatpak's per-launch sandbox namespacing gets in
the way of the socket), the new process assumes there's no existing
instance and cold-starts a full second browser instead of forwarding the
"open a window" request.
Neither KDE nor Flatpak are missing a check they're supposed to run
themselves -- both already fully support the standard fix (D-Bus
activation: `DBusActivatable=true` in the `.desktop` file + an
`org.freedesktop.Application` implementation), and other well-behaved
Flatpak apps get correct, invisible single-instance behavior for free
through it. Chromium (and Electron apps generally) just never adopted that
contract, because the existing singleton code is shared, cross-platform
logic that already works well enough on Windows/macOS without it.
## Direction for a fork
- Add a Linux-only `org.freedesktop.Application` implementation to
Chromium's browser-process startup, gated behind `BUILDFLAG(IS_LINUX)`
(excluding ChromeOS), that responds to `Activate`/`Open` D-Bus calls the
same way the existing process-singleton IPC responds to a second launch
today.
- Ship a matching `<app-id>.service` file so `flatpak run` (or a native
desktop launch) can be delivered via bus activation instead of always
exec'ing a fresh `chrome` binary; wire `DBusActivatable=true` into the
`.desktop` file.
- Keep the existing lock-file/socket mechanism as the fallback for
non-D-Bus environments (still needed for other embedders, e.g. CEF).
- Flatpak manifest side: the sandbox needs `--own-name=<app-id>` (or the
equivalent `finish-args`) for the bus name the service file activates, so
this doesn't depend on the fragile shared-socket path across sandbox
namespaces at all.
## Why this is genuinely a fork, not just a patch to carry
Chromium's process-singleton code is shared across all desktop platforms;
Linux-specific D-Bus activation is new surface area with its own
maintenance cost, and upstream has historically been conservative about
platform-specific branches in that file. Realistic expectation: this stays
a downstream patch (in the vein of what Vivaldi/Brave carry) rather than
something likely to land upstream quickly, so plan for it to need rebasing
across Chromium version bumps.
## Stopgap in use today
No fork exists yet, so the actual fix on this machine is external to
Chromium: wrap the launcher's `Exec=` in an `flock`-guarded script so a
second launch blocks (or no-ops) on a lockfile instead of racing the first
instance's cold start, and set `StartupNotify=true` /
correct`StartupWMClass` on the `.desktop` file so KDE's task manager shows
a busy state instead of silently permitting a duplicate launch.

211
docs/imac19-2-speaker-fix.md Normal file
View file

@ -0,0 +1,211 @@
# iMac19,2 internal speakers: no sound on playback
## TL;DR
Built-in speaker playback produces no audible sound at all, even though the
HDA plumbing looks correct at every layer PipeWire/ALSA can see (unmuted
volume, un-muted output pin, clean `speaker-test` device open). Root cause
(via sibling-model research, not yet confirmed on this exact iMac19,2):
audio on this hardware doesn't go straight from the CS8409's internal DAC to
the speakers — it's relayed through external Texas Instruments **TAS5764L**
speaker-amplifier chips over I2C, and a Cirrus **CS42L83** companion codec,
neither of which the in-tree (or our currently-vendored) driver ever
initializes. The DAC happily outputs a signal; nothing downstream ever
brings the amps out of reset to play it. **No patch has been written or
applied for this repo yet** — this doc captures the investigation and the
most promising existing prior art. See
[Current verification status](#current-verification-status).
## Hardware / software identification
- Model: Apple iMac19,2 (2019, 21.5")
- Distro: Aurora (uBlue/Fedora Kinoite bootc image), Kinoite variant
`44.20260908.1`
- Kernel: `7.1.8-200.fc44.x86_64` — **stock/in-tree** `snd_hda_codec_cs8409`
(`/lib/modules/.../kernel/sound/hda/codecs/cirrus/snd-hda-codec-cs8409.ko.xz`).
This machine has **not yet been switched** to this repo's own patched
image — the mic fix in
[`docs/imac19-2-mic-fix.md`](imac19-2-mic-fix.md) is also still unverified
on real hardware as of that doc's last update. So whatever's happening
here is a pre-existing quirk in the stock driver, unrelated to our own mic
patch.
- Audio codec: Cirrus Logic CS8409, HDA vendor id `0x10138409`, subsystem id
`0x106b0f00` (same subsystem-id family the mic-fix doc groups with
iMac18,1/iMac18,x).
## Symptom
No audible sound from the built-in speakers under any output. Checked:
- `wpctl status` — sink `Built-in Audio Analog Stereo` present, unmuted,
volume 0.92–1.00, not the wrong default device.
- `amixer -c0 contents` — `PCM Playback Volume` at `245/255` (~-1dB from
max), unmuted (`mute=0` reported, no explicit mute switch present at all
for this control).
- `speaker-test -c2 -twav` opens the ALSA device and runs cleanly (no
`-16 Device or resource busy`, no `-19 No such device`, no other open/setup
error) — the kernel driver accepts the stream without complaint.
## Ruled out, with evidence
- **Wrong/muted PipeWire sink** — `wpctl status` shows the correct sink
selected and unmuted; this is a separate, already-known-good check from
the mic doc's own investigation (that doc independently found and fixed an
unrelated muted-sink issue on the same class of hardware).
- **ALSA-level mute or zero volume** — `PCM Playback Volume` is at 245/255;
there is no separate `Speaker Playback Volume`/`Switch` control at all
(only `PCM`, `Mic`, `Internal Mic`, `Internal Mic Boost` exist per
`amixer -c0 scontrols`), so there's no separate speaker-path mute to check
— consistent with the codec not exposing an amp-capable mixer control on
this path at all (see [Root cause](#root-cause)).
- **HDA pin disabled** — `/proc/asound/card0/codec#0`, Node `0x24`/`0x25`
(`Pin Complex`, `[Fixed] Speaker at Int`, `DefAssociation=0x1`,
`Sequence=0x0`/`0x1`) both show `Pin-ctls: 0x40: OUT` — output enabled at
the pin level, not disabled.
- **Stream open failure** — `speaker-test` opens and runs without any ALSA
error; this isn't a "device doesn't exist"/"busy" failure.
- **Kernel panic or crash on the audio path** — `dmesg`/`journalctl -k`
weren't reachable as this user (`dmesg_restrict=1`, no passwordless sudo
available in this session) so this wasn't directly checked; nothing else
observed (no hang, no dropped SSH/session) is consistent with a crash
either way. Worth checking with root access before further work.
## Root cause
Not confirmed on this exact machine yet, but strongly indicated by prior art
on sibling Apple CS8409 hardware:
- **Companion hardware, not a simple codec quirk**: per
[`rojoxstar/imac19-2-cs8409-linux`](https://github.com/rojoxstar/imac19-2-cs8409-linux)
(already referenced-and-shelved in the mic-fix doc), this exact 2019
iMac's internal speakers are driven by **four TI TAS5764L amplifier
chips** plus a **Cirrus CS42L83** companion codec sitting behind the
CS8409 — not a direct CS8409-DAC-to-speaker path. That project reports
getting internal speakers "audible on both sides at 44.1 kHz" on Ubuntu
with kernel `7.0.0-31-generic`, after amplifier-specific bring-up work,
and explicitly warns: **"Never try speculative TAS gain writes, including
`0xCF`, on the speakers"** — i.e. wrong register writes to these chips are
a real-hardware-damage risk, not just a "no sound" risk.
- **Closer, Fedora-specific precedent**:
[`egorenar/snd-hda-codec-cs8409` issue #31](https://github.com/egorenar/snd-hda-codec-cs8409/issues/31),
"iMac18,3 built-in speakers working on Fedora 43 / kernel 6.19.12 with
additional TAS576 initialization" (iMac18,3 = 2017 27" 5K iMac, PCI
subsystem `0x106b1000` — same subsystem-id family the mic doc already
groups with our `0x106b0f00`). Root cause as described there: the speaker
path needs additional **TAS576 boot/reset initialization** that's simply
missing from the stock driver, and separately, code that cleared speaker
DACs `0x02`/`0x03` during cleanup was *losing* an already-working speaker
state.
- The actual patch for that report lives in a follow-on repo,
[`network-garden-lab/imac18-3-cs8409-fedora-speaker-patch`](https://github.com/network-garden-lab/imac18-3-cs8409-fedora-speaker-patch)
(Fedora-specific, two patch variants for kernel `6.19.12` and
`7.0.12-201.fc44.x86_64` — the latter within one Fedora point release of
our own `7.1.8-200.fc44.x86_64`). Unlike the mic fix's vendored
out-of-tree module, **this is a ~1100-line patch against the in-tree
kernel source itself**
(`sound/hda/codecs/cirrus/cs8409{.c,.h}` and `cs8409-tables.c`), adding
(among others) `imac_tas576_boot_reset_setup()`,
`imac_tas576_tdm_slot_setup()`, `imac_cs42l83_reset()` /
`imac_cs42l83_inithw()`, and a new `CS8409_FIXUP_IMAC_AMP` PCI-quirk
fixup keyed off subsystem id `0x106b1000` specifically (iMac18,3's id,
not ours) — using the TAS576 family at I2C addresses `0xd8/0xda/0xdc/0xde`
and the CS42L83 at `0x90`.
- Its own README calls this "experimental, single-machine tested" and
"a working result and investigation record, not a complete or
upstream-ready solution," and separately warns that changing the sound
profile in desktop sound settings mid-session "may temporarily disturb
or break playback... playback may resume with unexpectedly loud noise."
- **What this doesn't explain yet**: neither prior-art project confirms the
*exact* iMac19,2 / subsystem `0x106b0f00` combination — the closest
confirmed case is iMac18,3 (`0x106b1000`, 27" 5K, likely 2-way stereo amp
layout) and rojoxstar's own iMac19,2 work (4x TAS5764L). Whether our
specific board has 2 or 4 TAS5764L chips, and at which I2C addresses, is
unconfirmed — this needs an actual I2C bus scan on this machine, not
assumed from either project.
## The fix
**Not yet written or applied.** No patch exists in this repo for this issue.
The most promising starting point is adapting
`network-garden-lab/imac18-3-cs8409-fedora-speaker-patch`'s
`imac18-3-cs8409-speaker-fedora-7.0.12.patch` (closest Fedora kernel match)
to our subsystem id and kernel `7.1.8-200.fc44.x86_64`, following the same
sibling-model-adaptation approach the mic fix already used successfully.
This is **not** something to attempt as a quick live edit:
- It patches core in-tree kernel HDA source, not a leaf out-of-tree module —
a materially bigger lift than the mic fix's `kmod-builder` stage. It would
need either a full kernel rebuild or repackaging the same functional
change as an out-of-tree replacement module (mirroring how the mic fix's
`patches/snd-hda-codec-cs8409/` is built and installed into
`/usr/lib/modules/<kver>/extra/` to override the in-tree one — see
[`docs/imac19-2-mic-fix.md`](imac19-2-mic-fix.md#packaging-approach)).
- It writes directly to amplifier-chip registers over I2C. Per the
rojoxstar project's explicit warning, a wrong write here risks damaging
the physical speaker hardware, not just producing no sound or a kernel
warning — this needs real care re-deriving/checking register values
against our actual chip revision before any write is attempted on this
machine, not a copy-paste of another model's values.
- Precisely because of that, this should go through this repo's same
build-image-then-`bootc switch`-then-reboot discipline as the mic fix
(never a live `modprobe`/register-poke on the running system), and
ideally should not even reach that stage until the I2C topology on our
exact board is confirmed to match one of the two prior-art cases above.
## Current verification status
**Investigation only, as of 2026-09-29.** Ruled out the simple
mute/volume/pin-disabled explanations directly on this hardware (see
[Ruled out](#ruled-out-with-evidence)). Identified two independent pieces of
sibling-model prior art pointing at the same TAS5764L/TAS576 +
CS42L83 amplifier-bring-up root cause, with one Fedora-specific patch
(`network-garden-lab/imac18-3-cs8409-fedora-speaker-patch`) close enough in
kernel version to be a realistic starting point. Nothing has been vendored,
patched, or built yet. Next steps, in order:
1. Get root/sudo access on this machine and pull `dmesg`/`journalctl -k`
around a `speaker-test` run, to see whether the stock driver logs
anything about the amp/companion-codec path (the mic fix's own
discovery process relied heavily on this kind of kernel-log evidence).
2. Scan the I2C bus for TAS5764L/CS42L83 addresses actually present on this
board (2 vs 4 amps, and their real addresses) rather than assuming either
prior-art project's numbers apply unmodified.
3. Only then evaluate adapting the `7.0.12-201.fc44.x86_64` patch, following
the same vendor-and-patch-separately discipline as
`patches/snd-hda-codec-cs8409/`.
## Open risks / unknowns
- **Unconfirmed on this exact model**: closest confirmed cases are
iMac18,3 (patch exists, Fedora, close kernel match, different subsystem
id) and rojoxstar's own iMac19,2 work (matching model, but Ubuntu-based,
driver internals not yet compared line-by-line against the Fedora patch).
- **Real hardware-damage risk**: explicit upstream warning against
speculative amp register writes on these speaker amps — this is not a
"worst case is silence" fix like the mic one.
- **Packaging is a bigger lift than the mic fix**: in-tree kernel source
patch vs. a leaf out-of-tree module; needs a build-pipeline decision
before any code is written (full kernel rebuild vs. out-of-tree
replacement module).
- **Playback-instability warning from the patch author**: changing sound
profile/configuration mid-session reportedly can cause temporary
loud/broken playback on iMac18,3 with this patch applied — unknown
whether that's specific to that patch's implementation or a
hardware-level behavior that would recur here too.
- **Root access needed**: this investigation stopped at what a non-root
session could observe (`dmesg`/`journalctl -k` were inaccessible here).
- **Apple DSP / authenticated macOS SSV work in `rojoxstar`'s repo is a
distinct, unrelated blocker** (`docs/apple-dsp/CURRENT-BLOCKER.md` in that
repo, gated on an authenticated macOS Sequoia 24G90 install image) — that
applies to advanced Apple-specific DSP/EQ features, not basic playback,
and should not be confused with what's blocking sound here.
## References
- https://github.com/rojoxstar/imac19-2-cs8409-linux
- https://github.com/egorenar/snd-hda-codec-cs8409/issues/31
- https://github.com/network-garden-lab/imac18-3-cs8409-fedora-speaker-patch
- [`docs/imac19-2-mic-fix.md`](imac19-2-mic-fix.md) — sibling-model
subsystem-id grouping and the vendor-and-patch-separately packaging
precedent this doc leans on.