Created attachment 196515 [details] btmon excerpts: stock wizard gets BR/EDR-only discovery (0 LE adverts), patched wizard gets BR/EDR+LE (42 LE adverts) while kdeconnectd holds a bredr filter Product: plasmashell Component: Bluetooth in general Version: 6.6.4 Summary: Bluetooth Add Device wizard (bluedevil-wizard) finds no Bluetooth LE devices while another client (e.g. KDE Connect) holds a BR/EDR-filtered discovery session STEPS TO REPRODUCE 1. Have KDE Connect running with its Bluetooth backend enabled (the default). kdeconnectd keeps a discovery session open with SetDiscoveryFilter({"Transport": "bredr"}). 2. Open System Settings > Bluetooth > Add Device. 3. Put a Bluetooth LE device (e.g. a BLE keyboard or a current Xbox Wireless Controller) into pairing mode. OBSERVED RESULT The device never appears in the list. An HCI trace (btmon) taken while the wizard is open shows only MGMT Start Service Discovery with address type BR/EDR (0x01): a 10.24 s classic inquiry, repeating every minute on kdeconnectd's schedule. There is no LE scan and no advertising report. `bluetoothctl scan on` finds the same device at once. EXPECTED RESULT The wizard finds LE and BR/EDR devices whatever other clients are doing. CAUSE DiscoverPage::initializePage() and DiscoverPage::usableAdapterChanged() call Adapter::startDiscovery() only when !adapter->isDiscovering(). When another D-Bus client is already discovering, the wizard never becomes a discovery client of its own, so it inherits that client's filter. BlueZ tracks discovery per client and merges the filters of all discovering clients. If any of them has no filter, it runs a regular dual-mode discovery (merge_discovery_filters() in src/adapter.c: `if (!item) { has_regular_discovery = true; ... }`). So calling startDiscovery() unconditionally is enough to get both transports. When the wizard is already discovering, BlueZ returns InProgress, which is harmless. Disabling the KDE Connect Bluetooth backend works around it: qdbus6 org.kde.kdeconnect /modules/kdeconnect \ org.kde.kdeconnect.daemon.setLinkProviderState BluetoothLinkProvider false SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 26.04, kernel 7.0.0-31-generic KDE Plasma Version: 6.6.4 (bluedevil 6.6.4) KDE Frameworks Version: 6.24.0 Qt Version: 6.10.2 BlueZ: 5.85 KDE Connect: 25.12.3 Adapter: Intel AX211 (8087:0033) TESTED With the patch applied to 6.6.4 and kdeconnectd discovering (BR/EDR filter active), btmon shows the wizard's session widening the merged discovery to BR/EDR + LE Public + LE Random. In 20 s the stock wizard got 0 LE advertising reports and the patched one got 42. A K808 BLE keyboard and an Xbox Wireless Controller, neither of which appeared in the stock wizard, both showed up within seconds and paired. ADDITIONAL INFORMATION Merge request with the fix: <link to be added>
A possibly relevant merge request was started @ https://invent.kde.org/plasma/bluedevil/-/merge_requests/262
Merge request with the fix: https://invent.kde.org/plasma/bluedevil/-/merge_requests/262
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
Git commit 51daada4109a1a8184a821b10325faa663606591 by David Edmundson. Committed on 24/09/2026 at 17:54. Pushed by ngraham into branch 'Plasma/6.8'. 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. (cherry picked from commit aa2c9639b4ae9889cc161403a20f5d45ee146daa) Co-authored-by: Robert August Vincent II (Bob) <pillarsdotnet@gmail.com> M +6 -2 src/wizard/pages/discover.cpp https://invent.kde.org/plasma/bluedevil/-/commit/51daada4109a1a8184a821b10325faa663606591