subsurface/core/qtserialbluetooth.cpp

349 lines
8.8 KiB
C++
Raw Normal View History

// SPDX-License-Identifier: GPL-2.0
#include <errno.h>
#include <QtBluetooth/QBluetoothAddress>
#include <QtBluetooth/QBluetoothSocket>
Core: fix BT on Linux, workaround Qt bug on 5.12.0 After upgrading to Qt 5.12.0, download over BT from a DC did not work any more. On the console the message "Connecting to port is not supported (Uuid required)". Linus noticed earlier that we do rather strange processing in this part of the code related to selecting port 1 or port 5. This all seems not needed (any more), but broader testing is advised. This being stripped from the code, the mentioned error from Qt persisted. That is strange in itself, as we did not reference port numbers any more. Step 2 in this commit is actually using an uuid to the call to connectToService. Choosing an uuid seems relatively straightforward as we can use the same one we already use for Android. That is the default BT RFCOMM Serial Port Profile uuid. Interestingly, when changing to this uuid we run immediately in a Qt runtime error telling us "QDBusPendingReply: type ManagedObjectList is not registered with QtDBus.". For these 2 unexpected Qt messages, QTBUG-72742 was made. Studying the Qt source code at this point reveals a possible workaround. Simply create a local QBluetoothLocalDevice object, which, behind the scenes registers the Qt internal ManagedObjectList with QtDBus. In the meantime, Qt agrees that QTBUG-72742 is valid, and that a fix is to be expected in a future version. At that point in time, the declaration of the QBluetoothLocalDevice can be deleted again. In the end, interfacing over BT works again. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2018-12-23 08:17:30 +00:00
#include <QBluetoothLocalDevice>
#include <QEventLoop>
#include <QTimer>
#include <QThread>
#include <libdivecomputer/version.h>
Switch over to SSRF_CUSTOM_IO v2 I hate changing the IO interfaces this often, but when I converted the custom serial interface to the more generic custom IO interface, I intentionally left the legacy serial operations alone, because I didn't want to change something I didn't care about. But it turns out that leaving them with the old calling convention caused extra problems when converting the bluetooth serial code to have the BLE GATT packet fall-back, which requires mixing two kinds of operations. Also, the packet_open() routine was passed a copy of the 'dc_context_t', which makes it possible to update the 'dc_custom_io_t' field on the fly at open time. That makes a lot of chaining operations much simpler, since now you can chain the 'custom_io_t' at open time and then libdivecomputer will automatically call the new routines instead of the old ones. That dc_context_t availability gets rid of all the if (device && device->ops) return device->ops->serial_xyz(..); hackery inside the rfcomm routines - now we can just at open time do a simple dc_context_set_custom_io(context, &ble_serial_ops); to switch things over to the BLE version of the serial code instead. Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer argument to the custom_io descriptor, which gets filled in as the custom_io is registered with the download context. Note that unlike most opaque pointers, this one is opaque to *libdivecomputer*, and the type is supposed to be supplied by the user. We define the "dc_user_device_t" as our old "struct device_data_t", making it "struct user_device_t" instead. That means that the IO routines now get passed the device info showing what device they are supposed to download for. That, in turn, means that now our BLE GATT open code can take the device type it opens for into account if it wants to. And it will want to, since the rules for Shearwater are different from the rules for Suunto, for example. NOTE! Because of the interface change with libdivecomputer, this will need a flag-day again where libdivecomputer and subsurface are updated together. It may not be the last time, either. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-27 18:59:11 +00:00
#include <libdivecomputer/context.h>
#include <libdivecomputer/custom.h>
Update to new libdivecomputer version Jef has changed the libdivecomputer iostream layer and extended it in two different ways: - iostram's now have a 'poll()' method, which does what the name implies: waits for data to be available with a timeout. - iostreams now have a 'ioctl()' method, which can be used to implement miscellaneous operations. Right now the two ones that you can do are "set latency" (this replaces the old 'set_latency()' method) and "get BLE name" (this replaces our 'get_name()' method that was never part of the upstream libdivecomputer interfaces) Neither of these is all that complicated, and the transition is fairly obvious. HOWEVER. I have absolutely no idea how to do 'poll()' on Windows sockets, and I have no intention of figuring it out. We use a direct socket interface to implement the (non-BLE) RFCOMM bluetooth serial protocol, and I'm not sure why Windows is so special here. I suspect - but cannot test - that we should just switch the Windows RFCOMM implementation over to the use the same QtBluetooth code that we use on other platforms. I assume that the Windows Bluetooth support was originally not sufficiently good for that, but these days we depend on Qt doing BLE for us even on Windows, so presumably FRCOMM works too. That would be a nice cleanup, and would make 'poll()' work on RFCOMM under Windows too. However, since I can't test it, I've not done that, but instead just made the Windows RFCOMM 'poll()' method always return success. That may or may not get the thing limping along. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-01-26 20:42:57 +00:00
#include <libdivecomputer/serial.h>
#ifdef BLE_SUPPORT
# include "qt-ble.h"
#endif
#include "errorhelper.h"
QList<QBluetoothUuid> registeredUuids;
void addBtUuid(QBluetoothUuid uuid)
{
registeredUuids << uuid;
}
template<typename T>
static std::string to_str(const T &v)
{
return v.toString().toStdString();
}
typedef struct qt_serial_t {
/*
* RFCOMM socket used for Bluetooth Serial communication.
*/
QBluetoothSocket *socket;
long timeout;
} qt_serial_t;
static dc_status_t qt_serial_open(qt_serial_t **io, dc_context_t*, const char *devaddr)
{
// Allocate memory.
qt_serial_t *serial_port = (qt_serial_t *) malloc (sizeof (qt_serial_t));
if (serial_port == NULL) {
return DC_STATUS_NOMEMORY;
}
// Default to blocking reads.
serial_port->timeout = -1;
// Create a RFCOMM socket
serial_port->socket = new QBluetoothSocket(QBluetoothServiceInfo::RfcommProtocol);
// Wait until the connection succeeds or until an error occurs
QEventLoop loop;
loop.connect(serial_port->socket, SIGNAL(connected()), SLOT(quit()));
loop.connect(serial_port->socket, SIGNAL(error(QBluetoothSocket::SocketError)), SLOT(quit()));
// Create a timer. If the connection doesn't succeed after five seconds or no error occurs then stop the opening step
QTimer timer;
int msec = 5000;
timer.setSingleShot(true);
loop.connect(&timer, SIGNAL(timeout()), SLOT(quit()));
QBluetoothAddress remoteDeviceAddress(devaddr);
#if defined(Q_OS_ANDROID)
QBluetoothUuid uuid = QBluetoothUuid(QUuid("{00001101-0000-1000-8000-00805f9b34fb}"));
report_info("connecting to Uuid %s", to_str(uuid).c_str());
serial_port->socket->setPreferredSecurityFlags(QBluetooth::Security::NoSecurity);
serial_port->socket->connectToService(remoteDeviceAddress, uuid, QIODevice::ReadWrite | QIODevice::Unbuffered);
#else
Core: fix BT on Linux, workaround Qt bug on 5.12.0 After upgrading to Qt 5.12.0, download over BT from a DC did not work any more. On the console the message "Connecting to port is not supported (Uuid required)". Linus noticed earlier that we do rather strange processing in this part of the code related to selecting port 1 or port 5. This all seems not needed (any more), but broader testing is advised. This being stripped from the code, the mentioned error from Qt persisted. That is strange in itself, as we did not reference port numbers any more. Step 2 in this commit is actually using an uuid to the call to connectToService. Choosing an uuid seems relatively straightforward as we can use the same one we already use for Android. That is the default BT RFCOMM Serial Port Profile uuid. Interestingly, when changing to this uuid we run immediately in a Qt runtime error telling us "QDBusPendingReply: type ManagedObjectList is not registered with QtDBus.". For these 2 unexpected Qt messages, QTBUG-72742 was made. Studying the Qt source code at this point reveals a possible workaround. Simply create a local QBluetoothLocalDevice object, which, behind the scenes registers the Qt internal ManagedObjectList with QtDBus. In the meantime, Qt agrees that QTBUG-72742 is valid, and that a fix is to be expected in a future version. At that point in time, the declaration of the QBluetoothLocalDevice can be deleted again. In the end, interfacing over BT works again. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2018-12-23 08:17:30 +00:00
QBluetoothLocalDevice dev;
QBluetoothUuid uuid = QBluetoothUuid(QUuid("{00001101-0000-1000-8000-00805f9b34fb}"));
report_info("Linux Bluez connecting to Uuid %s", to_str(uuid).c_str());
Core: fix BT on Linux, workaround Qt bug on 5.12.0 After upgrading to Qt 5.12.0, download over BT from a DC did not work any more. On the console the message "Connecting to port is not supported (Uuid required)". Linus noticed earlier that we do rather strange processing in this part of the code related to selecting port 1 or port 5. This all seems not needed (any more), but broader testing is advised. This being stripped from the code, the mentioned error from Qt persisted. That is strange in itself, as we did not reference port numbers any more. Step 2 in this commit is actually using an uuid to the call to connectToService. Choosing an uuid seems relatively straightforward as we can use the same one we already use for Android. That is the default BT RFCOMM Serial Port Profile uuid. Interestingly, when changing to this uuid we run immediately in a Qt runtime error telling us "QDBusPendingReply: type ManagedObjectList is not registered with QtDBus.". For these 2 unexpected Qt messages, QTBUG-72742 was made. Studying the Qt source code at this point reveals a possible workaround. Simply create a local QBluetoothLocalDevice object, which, behind the scenes registers the Qt internal ManagedObjectList with QtDBus. In the meantime, Qt agrees that QTBUG-72742 is valid, and that a fix is to be expected in a future version. At that point in time, the declaration of the QBluetoothLocalDevice can be deleted again. In the end, interfacing over BT works again. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2018-12-23 08:17:30 +00:00
serial_port->socket->connectToService(remoteDeviceAddress, uuid, QIODevice::ReadWrite | QIODevice::Unbuffered);
#endif
timer.start(msec);
loop.exec();
if (serial_port->socket->state() == QBluetoothSocket::SocketState::ConnectingState ||
serial_port->socket->state() == QBluetoothSocket::SocketState::ServiceLookupState) {
// It seems that the connection step took more than expected. Wait another 20 seconds.
report_info("The connection step took more than expected. Wait another 20 seconds");
timer.start(4 * msec);
loop.exec();
}
Core: fix BT on Linux, workaround Qt bug on 5.12.0 After upgrading to Qt 5.12.0, download over BT from a DC did not work any more. On the console the message "Connecting to port is not supported (Uuid required)". Linus noticed earlier that we do rather strange processing in this part of the code related to selecting port 1 or port 5. This all seems not needed (any more), but broader testing is advised. This being stripped from the code, the mentioned error from Qt persisted. That is strange in itself, as we did not reference port numbers any more. Step 2 in this commit is actually using an uuid to the call to connectToService. Choosing an uuid seems relatively straightforward as we can use the same one we already use for Android. That is the default BT RFCOMM Serial Port Profile uuid. Interestingly, when changing to this uuid we run immediately in a Qt runtime error telling us "QDBusPendingReply: type ManagedObjectList is not registered with QtDBus.". For these 2 unexpected Qt messages, QTBUG-72742 was made. Studying the Qt source code at this point reveals a possible workaround. Simply create a local QBluetoothLocalDevice object, which, behind the scenes registers the Qt internal ManagedObjectList with QtDBus. In the meantime, Qt agrees that QTBUG-72742 is valid, and that a fix is to be expected in a future version. At that point in time, the declaration of the QBluetoothLocalDevice can be deleted again. In the end, interfacing over BT works again. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2018-12-23 08:17:30 +00:00
if (serial_port->socket->state() != QBluetoothSocket::SocketState::ConnectedState) {
// Get the latest error and try to match it with one from libdivecomputer
QBluetoothSocket::SocketError err = serial_port->socket->error();
report_info("Failed to connect to device %s. Device state %d. Error: %d", devaddr, static_cast<int>(serial_port->socket->state()), static_cast<int>(err));
free (serial_port);
switch(err) {
case QBluetoothSocket::SocketError::HostNotFoundError:
case QBluetoothSocket::SocketError::ServiceNotFoundError:
return DC_STATUS_NODEVICE;
case QBluetoothSocket::SocketError::UnsupportedProtocolError:
return DC_STATUS_PROTOCOL;
case QBluetoothSocket::SocketError::OperationError:
return DC_STATUS_UNSUPPORTED;
case QBluetoothSocket::SocketError::NetworkError:
return DC_STATUS_IO;
default:
return DC_STATUS_IO;
}
}
*io = serial_port;
return DC_STATUS_SUCCESS;
}
static dc_status_t qt_serial_close(void *io)
{
qt_serial_t *device = (qt_serial_t*) io;
if (device == NULL)
return DC_STATUS_SUCCESS;
if (device->socket == NULL) {
free(device);
return DC_STATUS_SUCCESS;
}
device->socket->close();
delete device->socket;
free(device);
return DC_STATUS_SUCCESS;
}
static dc_status_t qt_serial_read(void *io, void* data, size_t size, size_t *actual)
{
qt_serial_t *device = (qt_serial_t*) io;
if (device == NULL || device->socket == NULL || !actual)
return DC_STATUS_INVALIDARGS;
*actual = 0;
for (;;) {
int rc;
if (device->socket->state() != QBluetoothSocket::SocketState::ConnectedState)
return DC_STATUS_IO;
rc = device->socket->read((char *) data, size);
if (rc < 0) {
if (errno == EINTR || errno == EAGAIN)
continue;
return DC_STATUS_IO;
}
*actual = rc;
if (rc > 0 || !size)
return DC_STATUS_SUCCESS;
// Timeout handling
QEventLoop loop;
QTimer timer;
timer.setSingleShot(true);
loop.connect(&timer, SIGNAL(timeout()), SLOT(quit()));
loop.connect(device->socket, SIGNAL(readyRead()), SLOT(quit()));
timer.start(device->timeout);
loop.exec();
if (!timer.isActive())
return DC_STATUS_TIMEOUT;
}
}
static dc_status_t qt_serial_write(void *io, const void* data, size_t size, size_t *actual)
{
qt_serial_t *device = (qt_serial_t*) io;
if (device == NULL || device->socket == NULL || !actual)
return DC_STATUS_INVALIDARGS;
*actual = 0;
for (;;) {
int rc;
if (device->socket->state() != QBluetoothSocket::SocketState::ConnectedState)
return DC_STATUS_IO;
rc = device->socket->write((char *) data, size);
if (rc < 0) {
if (errno == EINTR || errno == EAGAIN)
continue;
return DC_STATUS_IO;
}
*actual = rc;
return rc ? DC_STATUS_SUCCESS : DC_STATUS_IO;
}
}
Update to new libdivecomputer version Jef has changed the libdivecomputer iostream layer and extended it in two different ways: - iostram's now have a 'poll()' method, which does what the name implies: waits for data to be available with a timeout. - iostreams now have a 'ioctl()' method, which can be used to implement miscellaneous operations. Right now the two ones that you can do are "set latency" (this replaces the old 'set_latency()' method) and "get BLE name" (this replaces our 'get_name()' method that was never part of the upstream libdivecomputer interfaces) Neither of these is all that complicated, and the transition is fairly obvious. HOWEVER. I have absolutely no idea how to do 'poll()' on Windows sockets, and I have no intention of figuring it out. We use a direct socket interface to implement the (non-BLE) RFCOMM bluetooth serial protocol, and I'm not sure why Windows is so special here. I suspect - but cannot test - that we should just switch the Windows RFCOMM implementation over to the use the same QtBluetooth code that we use on other platforms. I assume that the Windows Bluetooth support was originally not sufficiently good for that, but these days we depend on Qt doing BLE for us even on Windows, so presumably FRCOMM works too. That would be a nice cleanup, and would make 'poll()' work on RFCOMM under Windows too. However, since I can't test it, I've not done that, but instead just made the Windows RFCOMM 'poll()' method always return success. That may or may not get the thing limping along. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-01-26 20:42:57 +00:00
static dc_status_t qt_serial_poll(void *io, int timeout)
{
qt_serial_t *device = (qt_serial_t*) io;
if (!device)
return DC_STATUS_INVALIDARGS;
if (!device->socket)
return DC_STATUS_INVALIDARGS;
QEventLoop loop;
QTimer timer;
timer.setSingleShot(true);
loop.connect(&timer, SIGNAL(timeout()), SLOT(quit()));
loop.connect(device->socket, SIGNAL(readyRead()), SLOT(quit()));
timer.start(timeout);
loop.exec();
if (!timer.isActive())
Update to new libdivecomputer version Jef has changed the libdivecomputer iostream layer and extended it in two different ways: - iostram's now have a 'poll()' method, which does what the name implies: waits for data to be available with a timeout. - iostreams now have a 'ioctl()' method, which can be used to implement miscellaneous operations. Right now the two ones that you can do are "set latency" (this replaces the old 'set_latency()' method) and "get BLE name" (this replaces our 'get_name()' method that was never part of the upstream libdivecomputer interfaces) Neither of these is all that complicated, and the transition is fairly obvious. HOWEVER. I have absolutely no idea how to do 'poll()' on Windows sockets, and I have no intention of figuring it out. We use a direct socket interface to implement the (non-BLE) RFCOMM bluetooth serial protocol, and I'm not sure why Windows is so special here. I suspect - but cannot test - that we should just switch the Windows RFCOMM implementation over to the use the same QtBluetooth code that we use on other platforms. I assume that the Windows Bluetooth support was originally not sufficiently good for that, but these days we depend on Qt doing BLE for us even on Windows, so presumably FRCOMM works too. That would be a nice cleanup, and would make 'poll()' work on RFCOMM under Windows too. However, since I can't test it, I've not done that, but instead just made the Windows RFCOMM 'poll()' method always return success. That may or may not get the thing limping along. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-01-26 20:42:57 +00:00
return DC_STATUS_SUCCESS;
return DC_STATUS_TIMEOUT;
}
static dc_status_t qt_serial_ioctl(void *io, unsigned int request, void *data, size_t size)
{
return DC_STATUS_UNSUPPORTED;
}
static dc_status_t qt_serial_purge(void *io, dc_direction_t)
{
qt_serial_t *device = (qt_serial_t*) io;
if (device == NULL)
return DC_STATUS_INVALIDARGS;
// TODO: add implementation
return DC_STATUS_SUCCESS;
}
static dc_status_t qt_serial_get_available(void *io, size_t *available)
{
qt_serial_t *device = (qt_serial_t*) io;
if (device == NULL || device->socket == NULL)
return DC_STATUS_INVALIDARGS;
*available = device->socket->bytesAvailable();
return DC_STATUS_SUCCESS;
}
/* UNUSED! */
static int qt_serial_get_transmitted(qt_serial_t *device) __attribute__ ((unused));
static int qt_serial_get_transmitted(qt_serial_t *device)
{
if (device == NULL || device->socket == NULL)
return DC_STATUS_INVALIDARGS;
return device->socket->bytesToWrite();
}
static dc_status_t qt_serial_set_timeout(void *io, int timeout)
{
qt_serial_t *device = (qt_serial_t*) io;
if (device == NULL)
return DC_STATUS_INVALIDARGS;
device->timeout = timeout;
return DC_STATUS_SUCCESS;
}
static dc_status_t qt_custom_sleep(void *io, unsigned int timeout)
{
QThread::msleep(timeout);
return DC_STATUS_SUCCESS;
}
#ifdef BLE_SUPPORT
dc_status_t
ble_packet_open(dc_iostream_t **iostream, dc_context_t *context, const char* devaddr, void *userdata)
{
dc_status_t rc = DC_STATUS_SUCCESS;
void *io = NULL;
static const dc_custom_cbs_t callbacks = {
.set_timeout = qt_ble_set_timeout,
.set_break = nullptr,
.set_dtr = nullptr,
.set_rts = nullptr,
.get_lines = nullptr,
.get_available = nullptr,
.configure = nullptr,
.poll = qt_ble_poll,
.read = qt_ble_read,
.write = qt_ble_write,
.ioctl = qt_ble_ioctl,
.flush = nullptr,
.purge = nullptr,
.sleep = qt_custom_sleep,
.close = qt_ble_close,
};
rc = qt_ble_open(&io, context, devaddr, (device_data_t *) userdata);
if (rc != DC_STATUS_SUCCESS) {
return rc;
}
return dc_custom_open (iostream, context, DC_TRANSPORT_BLE, &callbacks, io);
}
#endif /* BLE_SUPPORT */
dc_status_t
rfcomm_stream_open(dc_iostream_t **iostream, dc_context_t *context, const char* devaddr)
{
dc_status_t rc = DC_STATUS_SUCCESS;
qt_serial_t *io = NULL;
static const dc_custom_cbs_t callbacks = {
.set_timeout = qt_serial_set_timeout,
.set_break = nullptr,
.set_dtr = nullptr,
.set_rts = nullptr,
.get_lines = nullptr,
.get_available = qt_serial_get_available,
.configure = nullptr,
.poll = qt_serial_poll,
.read = qt_serial_read,
.write = qt_serial_write,
.ioctl = qt_serial_ioctl,
.flush = nullptr,
.purge = qt_serial_purge,
.sleep = qt_custom_sleep,
.close = qt_serial_close,
};
rc = qt_serial_open(&io, context, devaddr);
if (rc != DC_STATUS_SUCCESS) {
return rc;
}
return dc_custom_open (iostream, context, DC_TRANSPORT_BLUETOOTH, &callbacks, io);
}