QBluetoothSocket enum values were tied to QAbstractSocket enum values.
But there is no dependency, the coupling is not required. This patch
removes the coupling and changes to scoped enums for improved type
safety.
Task-number: QTBUG-62877
Change-Id: I206b1d438d74b976d3e0d32da5713d22b597dd90
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
Since this is how we call this OS these days.
Change-Id: I679fbe888c0b695e2eefe5369c095c5dcab01600
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Implement the proper interface from QBluetoothSocketBasePrivate,
remove a dummy base class. Remove all public API from
qbluetoothsocket_osx.mm and re-use the code in qbluetoothsocket.cpp.
The code generally is the same, a bit of re-hashin/deletion.
Task-number: QTBUG-75348
Change-Id: I0034dfd283daf9d51775d8f9551b85d2d436aa85
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
MSDN documentation states that the recommended way of RFCOMM service
connection is via connectionHostName and connectionServiceName (see
https://docs.microsoft.com/en-us/uwp/api/windows.devices.bluetooth.rfcomm.rfcommdeviceservice).
So whenever possible, we should use this information from the native
device service when connecting directly to the discovered service.
As QBluetoothServiceInfo is basically just a wrapper for the attributes
map this information is stored in its private pendant and extracted when
a connection attempt is being made.
Task-number: QTBUG-62520
Change-Id: I95be5df89a722531393b45fd136d37f302393ca8
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
SDP discovery on Android only returns a flat list of uuids. It mixes
service class uuid and service uuids. Furthermore it is unable to detect
whether a serial connection uses rfcomm or l2cp as base protocol. The
last limitation is the fact that serial sockets can only be established
using rfcomm (no l2cp).
This poses a serious challenge because there is no way to say whether
a given custom service uuid is indeed an SPP based service or whether
it uses rfcomm. The only way to know for sure is to connect and check
whether it succeeds.
This also means QBluetoothServiceInfo instances returned by
QBluetoothServiceDiscoveryAgent may or may not mark a serial service
with SPP uuid or rfcomm protocol tag. Currently, it guess that that a
custom uuid together with SPP uuid implies an rfcomm setup. If the SPP
uuid was not found, rfcomm is never set (but is a requirement for
QBluetoothSocket). This patch makes QBluetoothSocket on Android a bit
more forgiving by assuming every given QBluetoothServiceInfo instance
requires rfcomm. After all that's the only supported protocol on Android.
Fixes: QTBUG-75035
Change-Id: I498ac5acd2a394b198a113fd23d750bbf17a7f7b
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Qt DBus registration for Bluez specific types was done by isBluez5().
However Qt 5.12 introduced bluetoothdVersion() which is a bit more
precise. It became necessary because runtime decisions based on exact
minor release versions of Bluez became necessary. Therefore some code
paths (depending on the user's use case) never called isBluez5() anymore.
Subsequently the dbus registrations were missed out on.
In the future isBLuez5() should be replaced by bluetoothdVersion().
QBluetoothSocket changed its underlying implementation when addressing
QTBUG-68550. It uses dbus sockets to establish rfcomm socket connections
to remote devices. The QBluetoothSocket::connectToService() overload that
expects a port number is no longer possible as Bluez DBus API does not
support connection establishment based on port numbers.
Fixes: QTBUG-72742
Change-Id: If6adb391b0524cabc3a702d761e0cbd263508396
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
The API was introduced earlier than 5.46 already but so far it has not
been tested. For now we use 5.46.
There is another dependency to QLowEnergyController's GATT custom
implementation. Custom GATT only works with the QBluetoothSocket
raw socket implementation. By setting the minimal version for
QBluetoothSocket slightly higher than the 5.42 version for custom
gatt, we ensure that the new dbus socket code is never run together
with the GATT custom stack.
Task-number: QTBUG-68550
Change-Id: I240f7fc8acb116c71e7601df8baf82f61e53c33e
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
or better ensure that the DBus based socket is not used for QBluetoothServer.
The server implementation will continue to use the raw socket implementation
for the foreseeable future. The reason being the DBus version not yet working.
convertAddress() in the server cpp was removed because it was a duplicate
implementation. Including qbluetoothsocket_bluez_p.h pulls in the
qbluetoothsocketbase_p.h which provides the official convertAddress()
implementations.
Unfortunately this requires a new ctor for QBluetoothSocket which is only
specified for BlueZ builds. It is used to permit QBluetoothServer to set
the correct dptr for QBluetoothSocket.
Task-number: QTBUG-68550
Change-Id: I19298f75e9bc2ab93322d9f34e1816ad733ac6d9
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Instead of duplicating that logic everywhere, it can be handled
in one place.
Additionally setOpenMode should be called before setSocketState
so that every member variable is changed, before signals are
emitted.
Change-Id: Ic1d4317ba31046d78d97874ec00c59481a67bb50
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
The private implementation can much more easily determine whether the
socket closure is already done or not.
On Bluez DBus, this avoids disconnected() being
emitted twice. Another platform that is still delayed is Android.
The patch permits the removal of Android specific ifdefs.
Last but not least the patch cleans up missing signals in WinRT.
Task-number: QTBUG-68550
Change-Id: I189e1dbc9f6d410522da1a82113fdf4fe79a4cbd
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The new code is not yet enabled in QBluetoothSocket because
the server side implementation is still missing.
Task-number: QTBUG-68550
Change-Id: I2f94dac9f7665c8d4ba5d675e91c5ab81af8504a
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
The new name fits the class better.
Task-number: QTBUG-68550
Change-Id: I7445f48134f8a9fe8b6b6291184f404b3b2faa89
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Lubomir I. Ivanov <neolit123@gmail.com>
This permits each platform to customize the implementations without
the need for ifdefs. Upcoming changes such as the BLuez DBuS addition
will increase the platform differences.
Task-number: QTBUG-68550
Change-Id: I8fc9a74d3ce704466f0bf2c16287e32f222c4376
Reviewed-by: Lubomir I. Ivanov <neolit123@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The goal is to move the various QBluetoothSocket::connectoService()
implementations into the private classes. Common parts can be split into
QBluetoothSocketBasePrivate and the platform specific code. The code
becomes cleaner and has less ifdefs.
However this creates a symbol clash with the currently existing private
implementation as it has a function with the same signature but different
purpose. This rename provides the foundation for future changes.
Task-number: QTBUG-68550
Change-Id: I121f08d93e00790c1619c0449629f47bca8a964d
Reviewed-by: Lubomir I. Ivanov <neolit123@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
At the same time we reshuffle the inclusion of qbluetoothsocket_p.h
in bluetooth.pro based on usage pattern.
Task-number: QTBUG-68550
Change-Id: I3ae3f61c65e71a57d238f5c67289720ff63a1b0f
Reviewed-by: Lubomir I. Ivanov <neolit123@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Uses the new QBluetoothSocketBasePrivate interface to separate the Linux
implementations from other platforms. On Linux, there will be the
existing raw socket implementation and a BlueZ5 DBus implementation.
The DBus implementation is required for very recent Bluez5 deployments
(v5.4x+) which restrict access to traditional SDP discovery means like
sdptool.
For now the DBus implementation is non-existing/dysfunctional.
Task-number: QTBUG-68550
Change-Id: Idd248ecdb2a443a95cde521ced929218d40df3fe
Reviewed-by: Lubomir I. Ivanov <neolit123@gmail.com>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
This patch introduces a generic interface towards QBluetoothSocketPrivate.
Later on, the QBluetoothSocketPrivate class will be split into
platform specific overloads/interfaces.
Ultimately, this will be needed to support runtime selection of
the QBluetootSocket d-pointer on Linux. The Linux Bluez5 implementation is
significantly different from the Bluez4 (raw socket) implementation.
Since recent Bluez5 releases the raw socket implementation is no longer
functional and/or the user has to have root permission
and enable bluetooth --compat mode. Therefore a second QBluetoothSocket
for the dbus socket API is needed. QBLuetoothSocket has to choose at runtime
(during its instanciation) which implementation to use.
Task-number: QTBUG-68550
Change-Id: I5d0b8e24b8acd1b149b897f52f0d82eade7f3823
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Lubomir I. Ivanov <neolit123@gmail.com>
This fixes the problem for all supported platforms.
Task-number: QTBUG-67672
Change-Id: I9cecfbe8a73df46070293eba1870ea3bee738b7b
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
qbluetoothsocket.h: In member function 'void QBluetoothSocket::connectToService(
const QBluetoothAddress&, QBluetoothUuid::ServiceClassUuid, QIODevice::OpenMode)':
qbluetoothsocket.h:111:5: error: declaration of 'openMode' shadows a member of 'this' [-Werror=shadow]
Change-Id: Ib9478027799b287430721d99bebee4002a1e5896
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Prior to this change passing a QBluetoothUuid::ServiceClassUuid to
connectToService() caused the port overload to be called rather than
the QBluetoothUuid version. This patch introduces a ServiceClassUuid
overload that avoids relying on implicit type conversion.
There is a remote chance that this patch breaks existing code if
the remote port was in the same range as the ServiceClassUuid range.
In general the Bluetooth ports are below 100 though.
Task-number: QTBUG-65831
Change-Id: I6574291ae6fee284466d84ecb91f21e3be89f6b2
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
The remaining cases (e.g. in QBluetoothServiceDiscoveryAgent)
are connected to Q_PRIVATE_SLOT usage which requires a redesign.
Change-Id: I9227b5459b81228a7aa2660193d5b984c036b74f
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Change-Id: Ia68da10c26ed0baff95a1f696b5a248595d23b1d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Not all platforms use txbuffer for writes. Fortunately those platforms
who do not use it do not use any buffering at all. Hence bytesToWrite()
returned the correct value as txbuffer always had size zero. Therefore
this patch is effectively a NOP.
Nevertheless this patch encourages the right implementation across the
platform.
This does not affect macOS as it has a separate implementation for
QBluetoothSocket::bytesToWrite().
Task-number: QTBUG-58190
Change-Id: Ic05f4358b079f612ee7e0e4dbb7fb9aa78fd6556
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
On Android, the socket's read buffer is managed in the Java thread.
QBluetoothSocket::canReadLine() is public API (most likely) being called
by in the main Qt thread though. The function directly called into the
Java buffer instance without proper locking. This can create race conditions.
Starting with this patch canReadLine() calls another QBluetoothSocketPrivate
indirection to allow a platform specific implementation. This affects
WinRT, BlueZ and the dummy backend too.
This is not an issue on macOS as its implementation of QBluetoothSocket
is separate and does not have to deal with multiple
QBluetoothSocketPrivate implementations.
Task-number: QTBUG-58190
Task-number: QTBUG-60830
Change-Id: Idae19f1aee6f809699d36519b01a3c68ad9c563d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Attempt to connect to a service using a socket with UnknownProtocol
socket type will fail, but can result in an incorrect UnknownSocketError
reported and also can start a device discovery (then finally failing to
connect after all). Check this condition early before trying to actually
connect/do device discovery and report error properly
as UnsupportedProtocolError.
Task-number: QTBUG-55073
Change-Id: Ib39e1ca7ad401e07d6387201a4664a1185d38d39
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
As of version 10.12 (Sierra), the name of Apple's desktop operating
system will be macOS. Change all occurrences where the platform is
discussed to use the macro \macos (defined in the documentation
configuration in qtbase).
Change-Id: I97f7a0d6d2ca351395bed518f01d4365b986500a
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
QBluetoothSocket::connectToService() performs its own service discovery
if the remote RFCOMM channel is not known. This may happen if the passed
in BluetothServiceInfo object was obtained via a minimal service
discovery (which does not perform a channel discovery) or if the
connectToService(const QBluetoothAddress &address, const QBluetoothUuid
&uuid, OpenMode openMode = ReadWrite);
overload was called.
This was not an issue with Bluez4 as every type of discovery
provided the RFCOMM channel id.
The internal discovery required at least the service's ServiceId to be
known. However a lot of SerialPort profiles do not set a custom service
uuid as ServiceId nor do they set the SerialPort UUID as ServiceId. Often they
provide the SerialPort uuid via the ServiceClassIds only.
This patch ensures that the internal service discovery is started if the
ServiceId is known or if the ServiceClassIds contains the SerialPort
uuid.
Furthermore the internal discovery did not apply the complete uuid filter.
If a ServiceClassId was added then the ServiceId was discarded which
could lead to services not being found.
Task-number: QTBUG-47593
Change-Id: Ia6e52d1a9def0f770080fd70e2b6deb40e69fa69
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Christian Kandeler <christian.kandeler@theqtcompany.com>
Reviewed-by: Alex Blasche <alexander.blasche@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>
This permits the API user to determine the security parameters for the
connect attempt to the remote SPP service.
Task-number: QTBUG-46377
Change-Id: I1ed5ea0f5a32aa08dcedc46a34b0377654e420b2
Reviewed-by: Timur Pocheptsov <Timur.Pocheptsov@digia.com>
[ChangeLog][QtBluetooth][Platform Specific Changes] Removed
support for Blackberry 10.
Change-Id: I431c4f34bb10aa3668542df7a8b3403b61bf4705
Reviewed-by: Rafael Roquetto <rafael.roquetto@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Andreas Buhr
Timur Pocheptsov
Oliver Wolff
Qt Forward Merge Bot
Alex Blasche
Edward Welbourne
Liang Qi
Timur Pocheptsov
Topi Reinio
Alex Blasche
Antti Kokko