Remember Bluetooth on/off through the rfkill soft block (#6682)

* Turn Bluetooth off with an rfkill soft block

BlueZ never persists an adapter's Powered property, so turning Bluetooth off in
the panel lasted only until the next boot. Omarchy's answer was AutoEnable=false,
which persists nothing either — it just means "never power the adapter on", so
Bluetooth came up off every boot whatever the user had chosen.

The soft block already does the job. systemd-rfkill saves every switch under
/var/lib/systemd/rfkill and restores it early on the next boot; that is the
entire purpose of the unit. Blocking also covers every controller at once, where
bluetoothctl only ever addresses the default one.

So the block becomes the state and BlueZ follows it: with AutoEnable back at its
stock default, lifting the block is enough for bluetoothd to power the adapter up
on its own. Powered still tracks the block, so the panel switch and icon read it
exactly as before. Everything that turns Bluetooth on or off goes through
omarchy-bluetooth-power, because bluetoothctl power on fails while a block is set.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Carry installed machines over to the rfkill block

Existing installs have AutoEnable=false, so their adapter is down at every boot
and Powered is the only record of what the user actually wants. Read it before
anything changes, hand it to the block, then put AutoEnable back to its default
so bluetoothd can act on that block. Only the exact line Omarchy wrote is
reverted, so a hand-edited opt-out survives.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Ask the power helper for a direction, not a toggle

The helper runs detached and the switch only moves once BlueZ catches up, so a
second click inside that window re-read the pre-click state and undid the first.
The panel already knows which way it wants to go, so let it say.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Read every controller and bound the power-up wait

The block hits every Bluetooth radio at once, but the state was read from a bare
bluetoothctl show, which reports the default controller only. A powered dongle
sitting behind a powered-down internal controller read as off and got blocked
along with it. Enumerate the controllers and take any powered one as on, exposed
as is-on so callers do not each reinvent the read.

The wait counted probes rather than time, so a wedged D-Bus turned a two-second
bound into roughly fifty across a full power-up. One deadline around the whole
wait holds it near nine.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Change the radio through sudo in the migration

/dev/rfkill is only writable unelevated from an active graphical seat, so an
update run over SSH failed here with EACCES. Migrations run under bash -e, so
that aborted before the config revert and the marker, and aborted again on every
retry. The privilege guidance already calls for sudo on machine-wide work run
from a visible terminal.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
David Heinemeier Hansson
2026-08-10 20:27:40 +02:00
committed by GitHub
co-authored by Claude Opus 5
parent 567e24cd90
commit c53190be07
7 changed files with 367 additions and 22 deletions
+36
View File
@@ -0,0 +1,36 @@
echo "Remember Bluetooth on and off through the rfkill soft block"
marker="${OMARCHY_BLUETOOTH_MIGRATION_MARKER:-/var/lib/omarchy/migrations/1786380259}"
main_conf="${OMARCHY_BLUETOOTH_MAIN_CONF:-/etc/bluetooth/main.conf}"
# Machine-wide work, but migration completion is recorded per user, so a second
# account would run it again and undo whatever an administrator changed in
# between. Written last, so an interrupted run is retried rather than skipped.
if [[ -e $marker ]]; then
exit 0
fi
# Read the machine as it stands before anything below changes it. Powered is the
# only record of what the user chose, and with AutoEnable=false holding the
# adapter down at every boot, no daemon to ask means off is what they have been
# living with.
#
# sudo because this runs machine-wide and /dev/rfkill is only writable without it
# from an active graphical seat — an update over SSH would otherwise abort here,
# before the marker, and abort again on every retry.
if omarchy-bluetooth-power is-on; then
sudo omarchy-bluetooth-power on
else
sudo omarchy-bluetooth-power off
fi
# Omarchy set AutoEnable=false believing bluetoothd would then restore the last
# power state. It has no such behaviour, so all the flag ever did was keep
# Bluetooth off at every boot. Left in place it would also stop bluetoothd from
# powering the adapter up when the block above is lifted. Only the exact line
# Omarchy wrote is reverted, so a hand-edited opt-out survives.
if [[ -f $main_conf ]]; then
sudo sed -i 's/^AutoEnable=false$/#AutoEnable=true/' "$main_conf"
fi
sudo install -Dm644 /dev/null "$marker"