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.
usbcore autosuspend config has no effect (usbcore is built into the kernel)
Reported by Smax1988 · filed Sep 17, 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
What happened
/etc/modprobe.d/omarchy-usb-autosuspend.conf (shipped by omarchy-settings) contains:
options usbcore autosuspend=-1This 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 eitherImpact
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
2000PipeWire 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-settings4.0.4-1) - Kernel: stock Arch
linux7.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