Conversation
neheb
force-pushed
the
fix/bluetooth-power-state-recovery
branch
3 times, most recently
from
September 17, 2026 22:56
e7156ac to
ff24918
Compare
Member
|
Please try to find a non polling way of doing this. |
outfoxxed
force-pushed
the
master
branch
2 times, most recently
from
October 6, 2026 04:21
72a1ce2 to
11ca60b
Compare
A new adapter's initial properties come from the InterfacesAdded snapshot, but its PropertiesChanged match rule is only installed afterwards, when the adapter object is constructed. Any change BlueZ emits in between is never delivered, so an adapter registered while powering on or off (e.g. after a controller swap) could stay stuck on a transitional PowerState forever. Issue a single GetAll once the snapshot has been applied. It is ordered after the match rule on the bus, so it picks up anything that was missed, and every later change is guaranteed to arrive as a signal. Signed-off-by: Rosen Penev <rosenp@gmail.com>
neheb
force-pushed
the
fix/bluetooth-power-state-recovery
branch
from
October 6, 2026 04:24
ff24918 to
93a822f
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
2 participants
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.