Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-983GitHub issuePublicDecided· Out of scope

Bluetooth audio dropouts on T2 MacBook Pro 16" 2019 — hci_uart_bcm binds instead of hci_bcm4377

Reported by ratandeepbansal · filed Sep 4, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

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

Bluetooth audio dropouts on T2 MacBook Pro 16" 2019 — hci_uart_bcm binds instead of hci_bcm4377revision 1 · captured 2026-09-28 21:24 UTC via poll

System

  • Omarchy version: 4.0.2-1
  • Kernel: 7.1.8-arch1-Watanare-T2-3-t2 (linux-t2)
  • Model: MacBook Pro 16" 2019 (T2 chip)
  • Bluetooth controller: Broadcom BCM4364B3 "Trinidad Olympic" (UART-attached)

Symptom

Bluetooth audio connections (headphones/speaker) drop/stutter randomly mid-playback.
Same symptom as #1288, which was closed without a root cause.

Root cause found

At boot, the generic hci_uart_bcm driver binds to hci0 instead of the
T2-specific hci_bcm4377 module. dmesg:

hci_uart_bcm serial0-0: No reset resource, using default baud rate
Bluetooth: hci0: BCM: failed to write update baudrate (-16)
Bluetooth: hci0: BCM4364B3 Trinidad Olympic GEN (MFG)
Bluetooth: hci0: BCM: firmware Patch file not found, tried: 'brcm/BCM.hcd'

This leaves the controller stuck in manufacturing/bootloader (MFG) mode with
no real firmware patch applied. hci_bcm4377 is loaded but shows 0 uses —
it never attaches. The correct Apple firmware
(brcmbt4377b3-apple,formosa.bin, from apple-bcm-firmware) is present on
disk, but in the format hci_bcm4377 expects, not hci_uart_bcm.

Note: PR #5145 (merged in v3.5.0) already makes hci_bcm4377 load
proactively at boot, but on this system (running v4.0.2-1, well past that
merge) it's still losing the bind race to hci_uart_bcm — so that fix
doesn't fully cover this hardware variant, or something else loads
hci_uart_bcm first regardless.

Untested proposed fix

Blacklisting hci_uart_bcm via /etc/modprobe.d/ so hci_bcm4377 wins the
bind unconditionally. Have not applied this yet — flagging for maintainer/
community input before trying it.

Possibly unrelated, ruled out

  • KDE Connect is a separate documented t2linux cause of BT dropouts (not

installed here / different mechanism).
- Merged kernel quirk for MBP16,1/16,4 (HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER)
addresses a different BT-init bug, not this one.

View raw text
### System
- Omarchy version: 4.0.2-1
- Kernel: 7.1.8-arch1-Watanare-T2-3-t2 (linux-t2)
- Model: MacBook Pro 16" 2019 (T2 chip)
- Bluetooth controller: Broadcom BCM4364B3 "Trinidad Olympic" (UART-attached)

### Symptom
Bluetooth audio connections (headphones/speaker) drop/stutter randomly mid-playback.
Same symptom as #1288, which was closed without a root cause.

### Root cause found
At boot, the generic `hci_uart_bcm` driver binds to hci0 instead of the
T2-specific `hci_bcm4377` module. dmesg:

    hci_uart_bcm serial0-0: No reset resource, using default baud rate
    Bluetooth: hci0: BCM: failed to write update baudrate (-16)
    Bluetooth: hci0: BCM4364B3 Trinidad Olympic GEN (MFG)
    Bluetooth: hci0: BCM: firmware Patch file not found, tried: 'brcm/BCM.hcd'

This leaves the controller stuck in manufacturing/bootloader (MFG) mode with
no real firmware patch applied. `hci_bcm4377` is loaded but shows 0 uses —
it never attaches. The correct Apple firmware
(`brcmbt4377b3-apple,formosa.bin`, from `apple-bcm-firmware`) is present on
disk, but in the format `hci_bcm4377` expects, not `hci_uart_bcm`.

Note: PR #5145 (merged in v3.5.0) already makes `hci_bcm4377` load
proactively at boot, but on this system (running v4.0.2-1, well past that
merge) it's still losing the bind race to `hci_uart_bcm` — so that fix
doesn't fully cover this hardware variant, or something else loads
`hci_uart_bcm` first regardless.

### Untested proposed fix
Blacklisting `hci_uart_bcm` via `/etc/modprobe.d/` so `hci_bcm4377` wins the
bind unconditionally. Have not applied this yet — flagging for maintainer/
community input before trying it.

### Possibly unrelated, ruled out
- KDE Connect is a separate documented t2linux cause of BT dropouts (not
  installed here / different mechanism).
- Merged kernel quirk for MBP16,1/16,4 (`HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER`)
  addresses a different BT-init bug, not this one.

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 10:45 UTC