# `/etc/modprobe.d/omarchy-usb-autosuspend.conf` is a no-op, and the USB autosuspend behaviour it targets still applies

## Summary

`omarchy-settings` (since 4.0.4) ships `/etc/modprobe.d/omarchy-usb-autosuspend.conf`:

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

`usbcore` is built into the kernel (`modinfo usbcore` → `(builtin)`), so a
`modprobe.d` option can never apply to it. `/sys/module/usbcore/parameters/autosuspend`
stays at its default `2`, and per-device autosuspend is not changed at all.

Worse, even setting the parameter where it *can* be set (the kernel command
line) would not achieve the intent, because per-device autosuspend on this
platform is driven by the udev/hwdb layer and `btusb`, not by `usbcore.autosuspend`.

The user-visible symptom this file was presumably meant to address is
Bluetooth LE HID devices (mice/keyboards) failing to reconnect: the Intel
controller is runtime-suspended, so the BLE link never completes and Omarchy's
Bluetooth panel reports a connection timeout until the device is forgotten and
paired again.

## Impact

Any Omarchy machine whose Bluetooth controller is runtime-suspended benefits
from a fix that isn't there. On Intel Bluetooth controllers the practical
result is BLE HID reconnect timeouts (Logitech MX Master 3S and ERGO K860 here,
but the mechanism is generic).

## Root cause

Chain, on this machine (Intel AX201, `8087:0026`):

1. systemd hwdb marks the controller autosuspend-eligible.
   `/usr/lib/udev/hwdb.d/60-autosuspend-chromiumos.hwdb:112` lists
   `usb:v8087p0026*` inside a block whose value is `ID_AUTOSUSPEND=1`
   (line 143). This is the Chromium OS autosuspend allowlist, but it matches
   on every system.

2. udev applies it. `/usr/lib/udev/rules.d/60-autosuspend.rules:11`:

   ```
   ENV{ID_AUTOSUSPEND}=="1", TEST=="power/control", ATTR{power/control}="auto"
   ```

   so the USB device gets `power/control=auto` and
   `power/autosuspend_delay_ms=2000`.

3. The Arch kernel is built with `CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y`, so `btusb`
   participates in runtime PM. The controller suspends ~2s after going idle
   (observed `runtime_status=suspended` after ~7s from cold, i.e. 2s after the
   firmware/HCI setup settles).

4. When a bonded BLE HID device reconnects, the controller is asleep and the
   LE connection does not complete; the panel's 20s timer (`omarchy-bluetooth-device`
   runs `timeout 20s bluetoothctl connect`) expires.

## Why the shipped file cannot work

Verified directly on the affected machine.

`usbcore` is builtin:

```
$ modinfo usbcore | head -2
name:           usbcore
filename:       (builtin)
```

The parameter is untouched at boot:

```
$ cat /sys/module/usbcore/parameters/autosuspend
2
```

And even when the parameter is forced to `-1` at runtime (the value the cmdline
would set, which *is* honoured for a builtin module) and `btusb` is reloaded,
the controller still autosuspends:

```
$ echo -1 > /sys/module/usbcore/parameters/autosuspend   # now reads -1
$ modprobe -r btusb && modprobe btusb
t=01s control=auto delay=2000 status=active
...
t=07s control=auto delay=2000 status=suspended
```

`options btusb enable_autosuspend=n` does not help either, because
`power/control=auto` is already set per-device by the udev rule above.

## Steps to reproduce

1. Install Omarchy 4.0.4 on a machine with an Intel Bluetooth controller
   (or any device listed in `60-autosuspend-chromiumos.hwdb`).
2. `cat /sys/module/usbcore/parameters/autosuspend` → `2` (the shipped file did
   nothing).
3. Pair a BLE HID device, let the controller go idle, then try to reconnect it.
4. Observe the controller suspended (`cat /sys/bus/usb/devices/*/power/runtime_status`)
   and the connection timing out.

## System details

- Omarchy: 4.0.4-1 (`omarchy`, `omarchy-settings` 4.0.4-1)
- Hardware: Razer Blade 15 Base (Early 2021), Intel Core i7-10750H + RTX 3060 Mobile
- Bluetooth: Intel AX201, `usb 8087:0026`, HCI version 11
- Kernel: 7.2.3-arch1-3 (also `linux-omarchy` 7.2.5-3 installed)
- BlueZ: 5.87-2
- systemd: 261.2-1
- `CONFIG_BT_HCIBTUSB_AUTOSUSPEND=y`, `usbcore` builtin

## Working fix (local)

A udev rule that runs after `60-autosuspend.rules` and pins the controller on.
This is what is actually needed; the kernel cmdline and the `btusb` module
parameter do not override the udev/hwdb result.

`/etc/udev/rules.d/61-bluetooth-intel-no-autosuspend.rules`:

```
ACTION=="add|bind|change", SUBSYSTEM=="usb", ATTR{idVendor}=="8087", ATTR{idProduct}=="0026", ATTR{power/control}="on"
```

`udevadm test /sys/bus/usb/devices/<bt-device>` confirms the ordering:

```
60-autosuspend.rules:11     ATTR{power/control}="auto"
61-bluetooth-intel-no-autosuspend.rules:11  ATTR{power/control}="on"
  power/control : on
```

After this, `control=on` and `runtime_status=active` hold, and both BLE HID
devices connect and stay connected.

## Suggested upstream fix

- Remove `/etc/modprobe.d/omarchy-usb-autosuspend.conf` (it cannot do anything),
  **and**
- ship a udev rule (in `omarchy-settings`) that pins `power/control=on` for the
  Intel Bluetooth controllers the chromiumos hwdb wrongly marks
  (`8087:0025`, `8087:0026`, `8087:0029`, `8087:0032`, `8087:0033`, `8087:0036`),
  since that hwdb allowlist is intended for Chromebooks, not a desktop distro.

## Diagnostics

`omarchy debug` does not exist in 4.0.4 (`Unknown Omarchy command`), so the
relevant outputs are included above. Happy to re-run any specific command or
capture a `btmon` trace on request.