Proof Portal

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-408GitHub issuePublicDecided· Out of scope

usbcore autosuspend config has no effect (usbcore is built into the kernel)

Reported by Smax1988 · filed Sep 17, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 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

usbcore autosuspend config has no effect (usbcore is built into the kernel)revision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

/etc/modprobe.d/omarchy-usb-autosuspend.conf (shipped by omarchy-settings) contains:

options usbcore autosuspend=-1

This has no effect. usbcore is built into the kernel (CONFIG_USB=y) in the
stock Arch linux package, and /etc/modprobe.d/ is only consulted when a
module is loaded. Built-in code never goes through modprobe, so the option is
silently ignored.

What was expected

USB autosuspend disabled system-wide, as the config file intends.

Steps to reproduce

On any Omarchy install running the stock Arch kernel:

$ modinfo usbcore | head -2
name:           usbcore
filename:       (builtin)          # <- not a module

$ cat /sys/module/usbcore/parameters/autosuspend
2                                  # <- expected -1

$ grep usbcore /proc/cmdline
                                   # <- nothing; no kernel parameter set either

Impact

USB devices still autosuspend. This is not cosmetic — it breaks USB Bluetooth
adapters: the adapter suspends while idle and tears down the active A2DP link,
producing a repeating connect/disconnect cycle every few minutes during audio
playback.

Observed on a Realtek RTL8822CU (1358:c123), where the adapter had accumulated
28 minutes of runtime_suspended_time since boot:

$ cat /sys/bus/usb/devices/3-2/power/runtime_suspended_time
1690842                            # ms

$ cat /sys/bus/usb/devices/3-2/power/autosuspend_delay_ms
2000

PipeWire also logged `spa.bluez5.sink.media: Missing completion reports for
packet: Bluetooth adapter firmware bug?` — HCI completion packets lost when the
adapter wakes mid-stream. Both symptoms stopped once autosuspend was actually
disabled.

Suggested fix

A udev rule expresses the same intent and works regardless of whether usbcore
is built in:

# /usr/lib/udev/rules.d/50-omarchy-usb-autosuspend.rules
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="on"

It also applies without a reboot, unlike the kernel-parameter alternative
(usbcore.autosuspend=-1 on the kernel cmdline), which would otherwise be the
only way to make the current approach work.

System details

  • Omarchy 4.0.4-1 (omarchy-settings 4.0.4-1)
  • Kernel: stock Arch linux 7.2.3.arch1-3
View raw text
## What happened

`/etc/modprobe.d/omarchy-usb-autosuspend.conf` (shipped by `omarchy-settings`) contains:

```
options usbcore autosuspend=-1
```

This has no effect. `usbcore` is built into the kernel (`CONFIG_USB=y`) in the
stock Arch `linux` package, and `/etc/modprobe.d/` is only consulted when a
module is *loaded*. Built-in code never goes through modprobe, so the option is
silently ignored.

## What was expected

USB autosuspend disabled system-wide, as the config file intends.

## Steps to reproduce

On any Omarchy install running the stock Arch kernel:

```bash
$ modinfo usbcore | head -2
name:           usbcore
filename:       (builtin)          # <- not a module

$ cat /sys/module/usbcore/parameters/autosuspend
2                                  # <- expected -1

$ grep usbcore /proc/cmdline
                                   # <- nothing; no kernel parameter set either
```

## Impact

USB devices still autosuspend. This is not cosmetic — it breaks USB Bluetooth
adapters: the adapter suspends while idle and tears down the active A2DP link,
producing a repeating connect/disconnect cycle every few minutes during audio
playback.

Observed on a Realtek RTL8822CU (`1358:c123`), where the adapter had accumulated
28 minutes of `runtime_suspended_time` since boot:

```bash
$ cat /sys/bus/usb/devices/3-2/power/runtime_suspended_time
1690842                            # ms

$ cat /sys/bus/usb/devices/3-2/power/autosuspend_delay_ms
2000
```

PipeWire also logged `spa.bluez5.sink.media: Missing completion reports for
packet: Bluetooth adapter firmware bug?` — HCI completion packets lost when the
adapter wakes mid-stream. Both symptoms stopped once autosuspend was actually
disabled.

## Suggested fix

A udev rule expresses the same intent and works regardless of whether `usbcore`
is built in:

```
# /usr/lib/udev/rules.d/50-omarchy-usb-autosuspend.rules
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control", ATTR{power/control}="on"
```

It also applies without a reboot, unlike the kernel-parameter alternative
(`usbcore.autosuspend=-1` on the kernel cmdline), which would otherwise be the
only way to make the current approach work.

## System details

- Omarchy 4.0.4-1 (`omarchy-settings` 4.0.4-1)
- Kernel: stock Arch `linux` 7.2.3.arch1-3

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 14:54 UTC