Skip to content

Four linux related backports

All backports in search of fixing some flaky bluetooth connect/disconnect behavior. As far as I can tell, as far as the backports tracker is concerned, this collection is all that is currently relevant for linux and not about win, mac or android.

Not yet runtime tested.

[PATCH 1/4] Correct error handling in QLowEnergyControllerPrivateBluezDBUS

When a DBUS interface was removed for a device, error handling
just assumed it was the org.bluez.Device1 interface, without checking.
This lead to errors on disconnection if the device has a battery
service: The code sends a disconnection request, then an
InterfaceRemoved event for org.bluez.Battery1 occurs. This was
interpreted as a removal of org.bluez.Device1 which in turn
led to the controller going into UnknownRemoteDeviceError error state.
This patch adds a check whether it is really org.bluez.Device1
which is removed.

Pick-to: 5.15
Change-Id: I449b29cb9528cda23ce972f36f716a8774f01fe5
Reviewed-by: Alex Blasche <>
(cherry picked from commit af5f801c6b8de0bf0d21798bddef54cb14759ecd)

[PATCH 2/4] Fix error handling in BlueZ connectToServiceHelper

QBluetoothSocketPrivateBluezDBus uses asynchronous calls,
then blocking waits for the result and then does error handling.
The blocking wait was missed in one place, rendering the following
error handling code dysfunctional.
This patch adds the required blocking wait.

Fixes: QTBUG-82407
Pick-to: 5.15
Change-Id: Ia45372e3b6cce3617d6c985fe1800a33631bc0fc
Reviewed-by: Alex Blasche <>
(cherry picked from commit 7aa19c8a512fdceac12cf4ee6587626e3de61c25)

[PATCH 3/4] Add server role to BlueZ service registration

In service registration, a profile is created. This profile had
no clien/server flag. If two profiles with the same UUID are
created (one for server side, one for client side) this led to
the wrong profile being used in connection setup.
This patch marks the profile which is created in registerService()
as a server profile which prevents it from being used by BlueZ
in a client context.

Pick-to: 5.15
Change-Id: I95b22657a7c7e45b334476a8513d79920ba9cc96
Reviewed-by: Alex Blasche <>
(cherry picked from commit e74cb54a4cbc8aba188ea48ae3effcf10432df11)

[PATCH 4/4] Always call setOpenMode before setSocketState

setSocketState emits signals and should thus be called last.
I most code, setOpenMode is called before setSocketState. But in some
occasions, setSocketState was called before setOpenMode. This patch
introduces a consistent call order: setOpenMode before setSocketState.

* asturmlechner 2021-12-22: Fix conflicts with e009d67f from dev branch

Pick-to: 5.15
Change-Id: I07f33511c76fbd08c79050a3fcbc1e1dd72fff04
Reviewed-by: Alex Blasche <>
(cherry picked from commit 62da7abae76b78fdc9385a0d997f3483057cf37c)

Merge request reports