| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
If the public class is deleted pending lambda invocation can cause
crashes unless QObject context is provided. This fixes a regression
introduced by 819bb06c2cb3372cb1bb9ddd7f3a504f78d3452d.
This was discovered while investigating QTBUG-71479.
Change-Id: I3a49916ce6d9425c684863bb0b04a10bd3e652b9
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a regression introduced by
819bb06c2cb3372cb1bb9ddd7f3a504f78d3452d.
The object context was missing and subsequent calls to QObject::sender()
failed. As a consequence the signalling for the device updates never
happened.
Fixes: QTBUG-71479
Change-Id: I6f057912a9321969b59ded8b0a3e5602653e5f2e
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some cases use the Q_PRIVATE_SLOT logic which does not require QObject
inheritance. Those cases were converted to lambda logic to avoid need for
QObject inheritance.
The Q_PRIVATE_SLOT macro was removed from qbluetoothdevicediscoveryagent.h.
This is not a BC problem because the macro expands to nothing. Only
moc recognizes the pattern.
Change-Id: Ic7cb4cde397f9b230b6fd0b4046e59e504583e58
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
|
|
|
|
|
| |
Change-Id: I7dd2d055c8d667f049d7cb2c371619137bf76030
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For iBeacons and such, it's normal to keep discovering indefinitely,
while the advertisement can sometimes carry changing payload data.
This signal helps keep the UI up-to-date.
Changed setManufacturerData to return a bool indicating whether the
data was really modified or not, to avoid sending deviceUpdated
in case it was not changed.
For convenience QBluetoothDeviceInfo::manufacturerData() was added.
WinRT and Apple platforms do not emit the new signal yet and relevant
TODO items were added.
Done-with: Shawn Rutledge <shawn.rutledge@qt.io>
Task-number: QTBUG-46008
Task-number: QTBUG-69747
Change-Id: I6d6b373f6cc5ee3dd6af2ad05d8640dbd25c5d6a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
|
|
|
|
|
|
|
| |
The initial patch was contributed by Thiemo van Engelen.
Change-Id: I45fad793ba092ab2820e606d8bf8807afa3e911e
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
|
|
|
|
|
|
|
| |
To avoid unnecessary copies, const is used wherever possible.
Change-Id: Ic743716512751cfd24fad5bd37c244b115dd26fe
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
|
|
|
|
|
|
|
| |
Task-number: QTBUG-57575
Change-Id: Ia289bcb1e0172e74bbda7f4b2dbc904ca1f5a856
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
.qmake.conf
Change-Id: I7a55929aefa1f7a4dc96f841317b78b248899f67
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the user chooses to do a BTLE device discovery with
QBluetoothDeviceDiscoveryAgent::setLowEnergyDiscoveryTimeout being set to 0,
we should continuously emit the deviceDiscovered() signal and not only once
per device. This patch checks the timeout value before triggering the
duplication detection for deviceDiscovered() signals.
Task-number: QTBUG-57847
Change-Id: I0e43b779a89b918640fe3d812d2500ed0a016cc3
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
DBus does not expose this information. The Bluetooth Management API
advertises the information but requires CAP_NET_ADMIN. The Management
class monitors DEVICE FOUND events and records the random bit flag
of each new device. QBluetoothDeviceDiscoveryAgent can subsequently
add this information to the internal data set.
Ultimately this makes QLowEnergyController::setRemoteAddressType
obsolete. This function was only ever required on Linux.
Task-number: QTBUG-46776
Change-Id: If10df86d332dfc7cc98b7c783eb28487c3fa9045
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
|
|/
|
|
|
|
|
|
|
|
|
| |
Bluez DBus API does not expose a flag indicating whether a given device
is BTLE or not. For BTLE only cases the device class is still
a fairly good indicator. However more and more devices are hybrids.
This patch takes a closer look at the advertised service uuids and
matches them against the known 0x1800 BTLE service uuids.
Change-Id: Iaad747ff8a7b17be5ee17e51e2f4e329604a708c
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change introduces the new API but does not yet implement the specific selection.
In any case BlueZ does not need any specific implementation as classic and BTLE
devices are found using the same method. iOS does not need any specific implementation
as it only supports BTLE discovery.
Task-number: QTBUG-46253
Change-Id: Ie6365966091effe5f3a68f8a283657c7cb43b692
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
BlueZ 4 does not support timed device search as the relevant API comes
back on its own. BlueZ 5 already had such a timer which we just
connect to the new API elements.
Task-number: QTBUG-53012
Change-Id: Id23fb31aca97932b6a898687fda0970e7d58d95f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This timeout adjusts the BTLE device discovery. Some BTLE devices
require some time to show up in such a search. In general the platforms
use open ended search methodologies as their own usage pattern for
BTLE device discovery too. So far Qt Bluetooth limited the time
through a hardcoded value which the API user could not adjust.
Task-number: QTBUG-53012
Change-Id: Ia37cebd4015b438db998c6b4a265f563c1a2f89f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@theqtcompany.com>
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
|\
| |
| |
| | |
Change-Id: Id8dffff9bb75db396aabf6da2a3acb78505a6476
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This may happen when the device discovery agent is quickly started and
stopped and started again. If the stop-start combination is happening
quicker than dbus can deliver the Discovering flag of the Adapter1
BlueZ interface, BlueZ's stop response will override the new start
discovery request.
Task-number: QTBUG-53715
Change-Id: I6a03fc525c7f390db009fc68a5313352ebba7f79
Reviewed-by: Frank Meerkoetter <frank.meerkoetter@basyskom.com>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Multiple device discovery agents can influence each other as they
monitor the same DBus BlueZ adapter. When one agent started
and another just stopped/finished the discovery process, the newly
started agent is caught in an unprepared state.
The other use case where this might happen is when one agent stopped
the discovery and another agent goes through the same start/stop cycle
in very quick order, then the first agent may still have pending signals
despiter adapter being deleted.
In any case this patch simply ensures that an already inactive
agent doesn't go through the finishing process again.
Task-number: QTBUG-51307
Change-Id: If0e2b944f1ceadb9037179c4fde2f3f79741d0a5
Reviewed-by: dmnikola <dmitry.nikolaev@theqtcompany.com>
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The error(), finished() and canceled() signals notify the user about
internal state changes. Signal handlers may call back into the same
class instance that just emitted the signals. If the instance did not
cleanup its internal state then the sudden reentry can cause weird
behavior.
Adds a comment that the pendingCancel & pendingStart behavior is
to be removed in Qt6. It has little advantage and cuases lots of
headaches. Unfortunately all backends exhibit the behavior and
therefore every backend has to change accordingly.
Task-number: QTBUG-51307
Change-Id: Ia5bf9efd0ed27e015361b10499ced069d16a9c93
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
|
|/
|
|
|
|
|
|
|
|
| |
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I856c13e2a6d4d12c46e1286b0ca1c092ee4608f8
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|\
| |
| |
| | |
Change-Id: I9d78ba7ad02848e3166a29c9f2d4876dd1bc1e96
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We would potentially access a null adapter if stop() was called from a
user slot connected to the deviceDiscovered() signal.
Task-number: QTBUG-48481
Change-Id: I784120dcd7a9f71d9532fac9538ae98e1a329db2
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Decrease complexity from O(N+N*logN) to just O(N) for cases like
foreach (Key key, map.keys())
Value value = map.value(key);
, by rewriting with use of iterators.
Change-Id: I81f1334797f16b624293fcebdee885b2be3c89f1
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Each org.bluez.Adapter.StartDiscovery should be paired with a
corresponding StopDiscovery; it is not enough to merely observe that
an adapter's Discovering property momentarily changes from true to
false.
Change-Id: Iee4ea4119cb4b6cd78982385bf18970d5b48d2de
Task-number: MER#1230
Done-by: Hannu Mallat <hannu.mallat@jollamobile.com>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
|
|/
|
|
|
|
|
|
| |
Errors can't be known until the call runs.
Change-Id: I68687ba8c813da922ca2c0906f9d33414333d87d
Task-number: MER#1231
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Change-Id: I3822a6484e8f7a420330de1cb1aeb0c3d1cf41b7
Reviewed-by: Sergio Ahumada <sahumada@texla.cl>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3 & LICENSE.GPLv2
- Removed LICENSE.GPL
Change-Id: I7a8b8b787fcae9a178794364efdefe1021d10b1b
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Device discovery of BTLE devices fails once the second device discovery
is performed in the current process. The first discovery always succeeds.
BTLE devices are advertised right after the start of the device discovery
session. However the discovery session never seems to stop once it is
done for the first time. This can be seen by the fact that the
Discovering property of the adapter constantly toggles between true
and false. As a consequence the second device discovery won't find
a BTLE device in 99% of all cases. The odds that the API user initiates
the second discovery right between two continues adapter searches
is rather slim.
The fix is to extend the device discovery process beyond
a toggle of a single device discovery cycle. We ignore the
end signal of the first cycle and continue to the end of the second
cycle. At the same time we rely on the perceived bug which restarts
the second cycle automatically. Just for the case that the second cycle
doesn't start automatically we utilize a timer to manually force
an end of the device discovery.
The problem is likely to be a bug in Bluez4. A negative side effect
of this workaround is a longer device discovery process.
Change-Id: I986c8d6498b2cc9ed51f4457267c53813132cf8e
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
|
|
|
|
| |
Change-Id: Idc04620c3941ec92c7ea81e1ba4ec521cf000720
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
src/bluetooth/qbluetoothservicediscoveryagent_bluez.cpp
Change-Id: Ib960b9e8d8800af84d2094bdf26c2652d4c81dba
|
| |
| |
| |
| |
| |
| | |
Change-Id: I59aa5241d33191a8ca8cc167263b63b024f52754
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Function name was slightly adjusted to reflect the fact that it's a
flag.
Change-Id: I9c1a2fe64b93c7ae7bd826d856f8b87f985d7473
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
examples/bluetooth/bluetooth.pro
src/bluetooth/bluez/bluez.pri
src/bluetooth/doc/src/bluetooth-index.qdoc
src/bluetooth/qbluetoothdevicediscoveryagent_bluez.cpp
src/bluetooth/qbluetoothdeviceinfo.cpp
src/bluetooth/qbluetoothservicediscoveryagent_bluez.cpp
src/bluetooth/qbluetoothservicediscoveryagent_p.h
src/bluetooth/qbluetoothservicediscoveryagent_qnx.cpp
Change-Id: I88b22c51a4ee95b067ef8d2b2fddb5cbff4566f8
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Bluez5 docs recommend to use the Alias rather than the Name property.
This ensures that a potentially user chosen device name is used rather
than the actual device name. If no Alias is set the property
automatically reverts back to the Name value.
Change-Id: If2b397cf49df6dc78bb205c1136b8d1dd5e7c02f
Reviewed-by: Bea Lam <bea.lam@jollamobile.com>
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If the discovery process was started by QBluetoothDeviceDiscoveryAgent
and Bluez wasn't already in discovery mode then the RSSI values
are 0. The retrieval of RSSI data takes a bit more time.
To find a compromise between speedy return of device scan information
and the delayed RSSI information we continue to monitor the device scan
and update RSSI information as the values are propagated by Bluez.
However the deviceDiscovered() signal is not emitted again after an
update. Only re-calling discoveredDevices() will return the most
up-to-date RSSI values.
Task-number: QTBUG-32085
Change-Id: Icb6566d51503a6004fa3f25c499fc7f941bd7fee
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
The only exception are generated files and cases where
QLatin1String based overloads are used (e.g. during QString comparisons)
Change-Id: I6f36789fb8acb3b30c1dc1f8a920b118a979d74f
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
|
| |
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-32085
Change-Id: I31ae0dc9f0d09f3979797eb95eb87ed7bd181ae3
Reviewed-by: Oleg Shparber <trollixx@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
Affected: QBluetooth, QBluetoothAddress, QBluetoothDeviceDiscoveryAgent,
QBluetoothDeviceInfo, QBluetoothHostInfo, QBluetoothLocalDevice
Change-Id: Ia5af61f87eafecfba56b75fa61b81014cdd38960
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
examples/bluetooth/bluetooth.pro
src/bluetooth/doc/src/examples.qdoc
src/bluetooth/qbluetoothdevicediscoveryagent_qnx.cpp
src/bluetooth/qbluetoothservicediscoveryagent_bluez.cpp
src/bluetooth/qbluetoothservicediscoveryagent_p.h
src/bluetooth/qbluetoothservicediscoveryagent_qnx.cpp
Change-Id: Ie1577e4b0f469cd5a6b05a61cbe94f180a64448d
|
| |
| |
| |
| |
| |
| |
| |
| | |
This includes unification of error messages, fixes for spelling
mistakes, hints for translators and other forms of simplifications.
Change-Id: Idd0e01614b24ff2d19133f0d19d49649d59e3f57
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
|
| |\
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
src/bluetooth/qbluetoothservicediscoveryagent.cpp
Change-Id: I52831fc8c69062e90c003836fd9402f19d6a0ba5
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
[ChangeLog][QtBluetooth][Platform Specific Changes] Memory leaks fixed
in Bluez device and service discovery implementations.
Change-Id: Ibc7c883d42d81a97310ff44ba40ffa94c71f611f
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Reviewed-by: Aaron McCarthy <mccarthy.aaron@gmail.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
remove trailing whitespace, expand tab
Change-Id: I3361c6c431231c7463bb1dc9b53268935b22a72b
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |/
| |
| |
| |
| |
| | |
Change-Id: I12406b2a0fef831ed2e96340fac73156dfa71848
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
| |
| |
| |
| |
| |
| |
| | |
Task-number: QTBUG-32253
Change-Id: I193162407d0fc7eca83689e31f03e1641a494ab0
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|/
|
|
|
|
|
|
|
| |
Bluez v4.x does not have total support for LE devices, a new approach, using gatttool command was implemented.
Auto-tests and documentation will be in other commits.
Change-Id: Iee711cc111199e15956052eebb7593bd3a5e27c8
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
|
|
|
| |
- Make them more consistent with other Qt modules
- Propagate the error during device discovery to the QBluetoothServiceDiscoveryAgent
Change-Id: Idcd3e0e6061b85e8b6adad248625740f3b91289a
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
|
|
|
| |
This is based on namespace discussions on the Qt project dev mailing list.
We continue to use the Qt namespace.
Change-Id: I6119d06662f7682c11f42d759f3218be1f5a7d6c
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case there are more Bluetooth adapter, device and service search
might give different results.
Addition to Change-Id: Ideddb39460985c18547baec986b15e43946c85de - added option
for setting the device adapter for service search. QBluetoothLocalDevice was used
in both classes (device and service search) for passing an argument for setting
adapter. The reason for this to keep the same approach, because in
QBluetoothServiceDiscoveryAgent class there is already a constructor
with QBluetoothAddress argument.
Auto tests and examples updated.
Change-Id: Ib5d7ff23e4846d9d42dae68d8d424031748811e5
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|
|
|
|
|
|
|
|
| |
In case there are more Bluetooth adapter, device search
might give different results.
Change-Id: Ideddb39460985c18547baec986b15e43946c85de
Reviewed-by: Alex Blasche <alexander.blasche@digia.com>
|