Conversation
neheb
force-pushed
the
fix/bluetooth-power-state-recovery
branch
2 times, most recently
from
September 17, 2026 22:52
5f51cc7 to
e7156ac
Compare
BlueZ can leave an adapter in a transitional power state without ever emitting the PropertiesChanged that completes the transition, if the adapter is registered (e.g. re-registered after a controller swap) while it is still powering on or off. The adapter's enabled/state would then be stuck mid-transition forever, even though the device is connected and in use. Re-read the adapter power state after it is observed in a transitional state and keep polling (at most 40 attempts / 10 seconds, paced by a single-shot QTimer that is stopped on any terminal state change) until it settles on a terminal state or the timer is cancelled.
neheb
force-pushed
the
fix/bluetooth-power-state-recovery
branch
from
September 17, 2026 22:56
e7156ac to
ff24918
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
BluetoothAdapter.enabled/statecan get permanently stuck on a transitional power state(
Enabling/Disabling) even though the adapter is actually powered and in use.BlueZ can report an adapter as
off-enabling/on-disablingwithout ever emitting thePropertiesChangedthat completes the transition, for example when a controller isre-registered while it is still coming up (in the reproduction: a dev-id change from
hci1to
hci0). Quickshell applies the transitionalPowered=falsesnapshot and, with no follow-upchange ever arriving, keeps reporting the adapter as "off" forever.
Reproduced live on the omarchy shell (see omacom/omarchy#9561 for
the same bug reported from the shell side):
hci0was tracked withPowerState=Enabling/Powered=falseduringre-registration, and
Powered=truewas never applied afterwards;bluetoothctl showreports the controllerPowered: yes/PowerState: on, and aconnected AirPods Pro is the default PipeWire sink and streaming audio.
Fix
When the adapter is observed in a transitional power state, re-read its properties via
GetAlluntil it settles on a terminal state (
Enabled/Disabled/Blocked) or before that afollow-up properties change arrives. Polling is bounded to 40 attempts at a 250 ms interval
(10 s ceiling) so it always terminates.
These are reads only (no
Set), so the fix cannot interfere withsetEnabledor other clientstoggling the adapter.