https://bugs.kde.org/show_bug.cgi?id=526178
Bug ID: 526178
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
Classification: Plasma
Product: plasmashell
Version First 6.6.4
Reported In:
Platform: Kubuntu
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Bluetooth in general
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: 1.0
Created attachment 196515
--> https://bugs.kde.org/attachment.cgi?id=196515&action=edit
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>
--
You are receiving this mail because:
You are watching all bug changes.
