https://bugs.kde.org/show_bug.cgi?id=526178
Robert August Vincent II (Bob) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|ASSIGNED |RESOLVED Latest Commit| |https://invent.kde.org/plas | |ma/bluedevil/-/commit/e781c | |89310dc7d22cca329171098f252 | |337acee2 --- Comment #3 from Robert August Vincent II (Bob) <[email protected]> --- Git commit e781c89310dc7d22cca329171098f252337acee2 by Robert August Vincent II (Bob). Committed on 24/09/2026 at 15:27. Pushed by davidedmundson into branch 'master'. wizard: always start our own discovery session The discover page only called startDiscovery() when the adapter was not already discovering. If another D-Bus client was discovering at the time, the wizard never became a discovery client itself, so the scan was whatever that client had asked for. KDE Connect's Bluetooth backend keeps a discovery session with a BR/EDR-only transport filter, and while it runs the wizard finds no Bluetooth LE devices at all: keyboards, mice and game controllers never appear. BlueZ tracks discovery per client and merges the filters of every discovering client; one unfiltered client makes it scan both LE and BR/EDR. So start discovery unconditionally. If this client is already discovering, BlueZ returns InProgress, which is harmless. M +2 -2 src/wizard/pages/discover.cpp https://invent.kde.org/plasma/bluedevil/-/commit/e781c89310dc7d22cca329171098f252337acee2 -- You are receiving this mail because: You are watching all bug changes.
