2017-06-25 05:00:52 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2017-06-13 02:47:50 +00:00
|
|
|
#include <errno.h>
|
|
|
|
|
|
|
|
#include <QtBluetooth/QBluetoothAddress>
|
|
|
|
#include <QLowEnergyController>
|
2017-07-03 17:24:39 +00:00
|
|
|
#include <QLowEnergyService>
|
2017-06-27 13:58:36 +00:00
|
|
|
#include <QCoreApplication>
|
|
|
|
#include <QElapsedTimer>
|
2017-06-13 02:47:50 +00:00
|
|
|
#include <QEventLoop>
|
2017-06-27 13:58:36 +00:00
|
|
|
#include <QThread>
|
2017-06-13 02:47:50 +00:00
|
|
|
#include <QTimer>
|
2018-09-24 03:04:08 +00:00
|
|
|
#include <QTime>
|
2017-06-13 02:47:50 +00:00
|
|
|
#include <QDebug>
|
2017-07-06 14:21:04 +00:00
|
|
|
#include <QLoggingCategory>
|
2017-06-13 02:47:50 +00:00
|
|
|
|
|
|
|
#include <libdivecomputer/version.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/ble.h>
|
2017-06-13 02:47:50 +00:00
|
|
|
|
|
|
|
#include "libdivecomputer.h"
|
|
|
|
#include "core/qt-ble.h"
|
2017-09-17 03:21:46 +00:00
|
|
|
#include "core/btdiscovery.h"
|
2019-08-05 17:41:15 +00:00
|
|
|
#include "core/errorhelper.h"
|
2018-05-11 15:25:41 +00:00
|
|
|
#include "core/subsurface-string.h"
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2017-07-04 00:46:22 +00:00
|
|
|
#define BLE_TIMEOUT 12000 // 12 seconds seems like a very long time to wait
|
2018-04-13 23:07:49 +00:00
|
|
|
#define DEBUG_THRESHOLD 50
|
2017-07-06 14:21:04 +00:00
|
|
|
static int debugCounter;
|
2017-07-04 00:46:22 +00:00
|
|
|
|
2017-07-04 14:40:33 +00:00
|
|
|
#define IS_HW(_d) same_string((_d)->vendor, "Heinrichs Weikamp")
|
|
|
|
#define IS_SHEARWATER(_d) same_string((_d)->vendor, "Shearwater")
|
2018-09-07 00:32:24 +00:00
|
|
|
#define IS_GARMIN(_d) same_string((_d)->vendor, "Garmin")
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2017-07-05 16:37:21 +00:00
|
|
|
#define MAXIMAL_HW_CREDIT 255
|
|
|
|
#define MINIMAL_HW_CREDIT 32
|
|
|
|
|
2018-06-20 06:03:57 +00:00
|
|
|
#define WAITFOR(expression, ms) do { \
|
|
|
|
Q_ASSERT(QCoreApplication::instance()); \
|
|
|
|
Q_ASSERT(QThread::currentThread()); \
|
|
|
|
\
|
|
|
|
if (expression) \
|
|
|
|
break; \
|
|
|
|
QElapsedTimer timer; \
|
|
|
|
timer.start(); \
|
|
|
|
\
|
|
|
|
do { \
|
|
|
|
QCoreApplication::processEvents(QEventLoop::AllEvents, ms); \
|
|
|
|
if (expression) \
|
|
|
|
break; \
|
|
|
|
QThread::msleep(10); \
|
|
|
|
} while (timer.elapsed() < (ms)); \
|
|
|
|
} while (0)
|
|
|
|
|
2018-04-18 15:52:30 +00:00
|
|
|
extern "C" {
|
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
void BLEObject::serviceStateChanged(QLowEnergyService::ServiceState newState)
|
2017-06-13 02:47:50 +00:00
|
|
|
{
|
2019-01-21 22:14:03 +00:00
|
|
|
if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)
|
|
|
|
qDebug() << "serviceStateChanged";
|
2017-06-27 12:56:30 +00:00
|
|
|
auto service = qobject_cast<QLowEnergyService*>(sender());
|
|
|
|
if (service)
|
2019-01-21 22:14:03 +00:00
|
|
|
if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)
|
|
|
|
qDebug() << service->serviceUuid() << newState;
|
2017-06-13 02:47:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void BLEObject::characteristcStateChanged(const QLowEnergyCharacteristic &c, const QByteArray &value)
|
|
|
|
{
|
2019-01-21 22:14:03 +00:00
|
|
|
if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)
|
|
|
|
qDebug() << QTime::currentTime() << "packet RECV" << value.toHex();
|
2017-07-04 14:40:33 +00:00
|
|
|
if (IS_HW(device)) {
|
2017-07-03 19:21:02 +00:00
|
|
|
if (c.uuid() == hwAllCharacteristics[HW_OSTC_BLE_DATA_TX]) {
|
2017-07-05 16:37:21 +00:00
|
|
|
hw_credit--;
|
2017-07-03 19:21:02 +00:00
|
|
|
receivedPackets.append(value);
|
2017-07-05 16:37:21 +00:00
|
|
|
if (hw_credit == MINIMAL_HW_CREDIT)
|
2017-07-11 15:11:49 +00:00
|
|
|
setHwCredit(MAXIMAL_HW_CREDIT - MINIMAL_HW_CREDIT);
|
2017-07-03 19:21:02 +00:00
|
|
|
} else {
|
|
|
|
qDebug() << "ignore packet from" << c.uuid() << value.toHex();
|
|
|
|
}
|
|
|
|
} else {
|
2017-07-04 14:40:33 +00:00
|
|
|
receivedPackets.append(value);
|
2017-07-03 19:21:02 +00:00
|
|
|
}
|
|
|
|
}
|
2017-06-28 03:53:11 +00:00
|
|
|
|
2017-07-03 19:21:02 +00:00
|
|
|
void BLEObject::characteristicWritten(const QLowEnergyCharacteristic &c, const QByteArray &value)
|
|
|
|
{
|
2017-07-04 14:40:33 +00:00
|
|
|
if (IS_HW(device)) {
|
2017-07-03 19:21:02 +00:00
|
|
|
if (c.uuid() == hwAllCharacteristics[HW_OSTC_BLE_CREDITS_RX]) {
|
2017-07-05 16:37:21 +00:00
|
|
|
bool ok;
|
|
|
|
hw_credit += value.toHex().toInt(&ok, 16);
|
2017-07-03 19:21:02 +00:00
|
|
|
isCharacteristicWritten = true;
|
|
|
|
}
|
|
|
|
} else {
|
2019-01-21 22:14:03 +00:00
|
|
|
if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)
|
2017-07-06 14:21:04 +00:00
|
|
|
qDebug() << "BLEObject::characteristicWritten";
|
2017-07-03 19:21:02 +00:00
|
|
|
}
|
2017-06-13 02:47:50 +00:00
|
|
|
}
|
|
|
|
|
2018-05-21 15:36:04 +00:00
|
|
|
void BLEObject::writeCompleted(const QLowEnergyDescriptor&, const QByteArray&)
|
2017-06-13 02:47:50 +00:00
|
|
|
{
|
2019-01-21 22:14:03 +00:00
|
|
|
if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)
|
|
|
|
qDebug() << "BLE write completed";
|
2018-10-06 18:26:26 +00:00
|
|
|
desc_written++;
|
2017-06-13 02:47:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void BLEObject::addService(const QBluetoothUuid &newService)
|
|
|
|
{
|
2017-06-27 11:50:19 +00:00
|
|
|
qDebug() << "Found service" << newService;
|
|
|
|
|
2018-10-06 17:50:25 +00:00
|
|
|
if (IS_HW(device)) {
|
|
|
|
/* The HW BT/BLE piece or hardware uses, what we
|
|
|
|
* call here, "a Standard UUID. It is standard because the Telit/Stollmann
|
|
|
|
* manufacturer applied for an own UUID for its product, and this was granted
|
|
|
|
* by the Bluetooth SIG.
|
|
|
|
*/
|
|
|
|
if (newService != QUuid("{0000fefb-0000-1000-8000-00805f9b34fb}"))
|
|
|
|
return; // skip all services except the right one
|
|
|
|
} else {
|
|
|
|
bool isStandardUuid = false;
|
|
|
|
|
|
|
|
newService.toUInt16(&isStandardUuid);
|
|
|
|
if (isStandardUuid) {
|
|
|
|
qDebug () << " .. ignoring standard service" << newService;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-27 12:56:30 +00:00
|
|
|
auto service = controller->createServiceObject(newService, this);
|
2017-06-25 05:32:47 +00:00
|
|
|
qDebug() << " .. created service object" << service;
|
2017-06-13 02:47:50 +00:00
|
|
|
if (service) {
|
2017-06-27 12:56:30 +00:00
|
|
|
services.append(service);
|
2017-06-13 02:47:50 +00:00
|
|
|
service->discoverDetails();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-27 22:14:27 +00:00
|
|
|
BLEObject::BLEObject(QLowEnergyController *c, dc_user_device_t *d)
|
2017-06-13 02:47:50 +00:00
|
|
|
{
|
|
|
|
controller = c;
|
2017-06-27 22:14:27 +00:00
|
|
|
device = d;
|
2017-07-06 14:21:04 +00:00
|
|
|
debugCounter = 0;
|
2017-12-28 08:49:25 +00:00
|
|
|
isCharacteristicWritten = false;
|
2018-10-06 18:43:48 +00:00
|
|
|
timeout = BLE_TIMEOUT;
|
2017-06-13 02:47:50 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
BLEObject::~BLEObject()
|
|
|
|
{
|
2017-06-25 05:32:47 +00:00
|
|
|
qDebug() << "Deleting BLE object";
|
2017-11-01 14:25:24 +00:00
|
|
|
|
2019-04-03 18:25:35 +00:00
|
|
|
qDeleteAll(services);
|
2017-11-01 14:25:24 +00:00
|
|
|
|
|
|
|
delete controller;
|
2017-06-13 02:47:50 +00:00
|
|
|
}
|
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
// a write characteristic needs Write or WriteNoResponse
|
|
|
|
static bool is_write_characteristic(const QLowEnergyCharacteristic &c)
|
|
|
|
{
|
|
|
|
return c.properties() &
|
|
|
|
(QLowEnergyCharacteristic::Write |
|
|
|
|
QLowEnergyCharacteristic::WriteNoResponse);
|
|
|
|
}
|
|
|
|
|
|
|
|
// We need a Notify or Indicate for the reading side, and
|
|
|
|
// a descriptor to enable it
|
|
|
|
static bool is_read_characteristic(const QLowEnergyCharacteristic &c)
|
|
|
|
{
|
|
|
|
return !c.descriptors().empty() &&
|
|
|
|
(c.properties() &
|
|
|
|
(QLowEnergyCharacteristic::Notify |
|
|
|
|
QLowEnergyCharacteristic::Indicate));
|
|
|
|
}
|
|
|
|
|
2017-06-27 22:14:27 +00:00
|
|
|
dc_status_t BLEObject::write(const void *data, size_t size, size_t *actual)
|
2017-06-13 02:47:50 +00:00
|
|
|
{
|
2018-04-17 01:14:59 +00:00
|
|
|
if (actual) *actual = 0;
|
|
|
|
|
BLE: read until no more data in coming in
The current BLE read reads just one 20 bype packet. That packet size is set
in ble_serial_ops, so, without being able to test on anything other than
a OSTC3, I assume that this holds for other BLE DCs too. So, I think is
is weird that those interfaces work with the current read() of just one
packet at the time.
As we need a blocking read (at least for the OSTC parser), just read all
data that is available on the input. And when we think we are done, give
the QtEventloop control to see if there is more, and process that incoming
data as well. All this basically implements a blocking read.
CAVEAT 1: This might break the reading from the currently working BLE devices.
CAVEAT 2: With this, I still cannot read the OSTC3 completely. For
developers familiar with the HW transfer protocol: it just stops while
reading the first full dive (header + profile) command 0x66, despite
correctly reading about 5Kb of data before. For some
reason, I do not believe that this is related to this commit.
CAVEAT 3: All above tested on Linux Desktop with bluez stack, and
confirmed NOT to work on Android 7.1.2, build with Qt 5.9.0, And
yes, I know 5.9.1 recommended.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 07:03:30 +00:00
|
|
|
if (!receivedPackets.isEmpty()) {
|
|
|
|
qDebug() << ".. write HIT with still incoming packets in queue";
|
2018-06-20 06:01:35 +00:00
|
|
|
do {
|
|
|
|
receivedPackets.takeFirst();
|
|
|
|
} while (!receivedPackets.isEmpty());
|
BLE: read until no more data in coming in
The current BLE read reads just one 20 bype packet. That packet size is set
in ble_serial_ops, so, without being able to test on anything other than
a OSTC3, I assume that this holds for other BLE DCs too. So, I think is
is weird that those interfaces work with the current read() of just one
packet at the time.
As we need a blocking read (at least for the OSTC parser), just read all
data that is available on the input. And when we think we are done, give
the QtEventloop control to see if there is more, and process that incoming
data as well. All this basically implements a blocking read.
CAVEAT 1: This might break the reading from the currently working BLE devices.
CAVEAT 2: With this, I still cannot read the OSTC3 completely. For
developers familiar with the HW transfer protocol: it just stops while
reading the first full dive (header + profile) command 0x66, despite
correctly reading about 5Kb of data before. For some
reason, I do not believe that this is related to this commit.
CAVEAT 3: All above tested on Linux Desktop with bluez stack, and
confirmed NOT to work on Android 7.1.2, build with Qt 5.9.0, And
yes, I know 5.9.1 recommended.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 07:03:30 +00:00
|
|
|
}
|
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
foreach (const QLowEnergyCharacteristic &c, preferredService()->characteristics()) {
|
|
|
|
if (!is_write_characteristic(c))
|
|
|
|
continue;
|
2017-09-20 23:19:25 +00:00
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
QByteArray bytes((const char *)data, (int) size);
|
2019-01-21 22:14:03 +00:00
|
|
|
if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)
|
|
|
|
qDebug() << QTime::currentTime() << "packet SEND" << bytes.toHex();
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
QLowEnergyService::WriteMode mode;
|
|
|
|
mode = (c.properties() & QLowEnergyCharacteristic::WriteNoResponse) ?
|
|
|
|
QLowEnergyService::WriteWithoutResponse :
|
|
|
|
QLowEnergyService::WriteWithResponse;
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
preferredService()->writeCharacteristic(c, bytes, mode);
|
|
|
|
if (actual) *actual = size;
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
return DC_STATUS_IO;
|
2017-06-13 02:47:50 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
dc_status_t BLEObject::poll(int timeout)
|
2017-06-13 02:47:50 +00:00
|
|
|
{
|
|
|
|
if (receivedPackets.isEmpty()) {
|
2017-06-27 12:56:30 +00:00
|
|
|
QList<QLowEnergyCharacteristic> list = preferredService()->characteristics();
|
2017-06-13 02:47:50 +00:00
|
|
|
if (list.isEmpty())
|
|
|
|
return DC_STATUS_IO;
|
|
|
|
|
2019-01-21 22:14:03 +00:00
|
|
|
if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)
|
|
|
|
qDebug() << QTime::currentTime() << "packet WAIT";
|
2018-09-24 03:04:08 +00:00
|
|
|
|
2018-10-06 18:43:48 +00:00
|
|
|
WAITFOR(!receivedPackets.isEmpty(), timeout);
|
2018-06-20 06:03:57 +00:00
|
|
|
if (receivedPackets.isEmpty())
|
2019-04-17 16:08:10 +00:00
|
|
|
return DC_STATUS_TIMEOUT;
|
2017-06-13 02:47:50 +00:00
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
|
|
|
dc_status_t BLEObject::read(void *data, size_t size, size_t *actual)
|
|
|
|
{
|
|
|
|
dc_status_t rc;
|
|
|
|
|
|
|
|
if (actual)
|
|
|
|
*actual = 0;
|
|
|
|
|
|
|
|
// Wait for a packet
|
|
|
|
rc = poll(timeout);
|
|
|
|
if (rc != DC_STATUS_SUCCESS)
|
|
|
|
return rc;
|
|
|
|
|
2017-07-11 11:29:41 +00:00
|
|
|
QByteArray packet = receivedPackets.takeFirst();
|
BLE: read until no more data in coming in
The current BLE read reads just one 20 bype packet. That packet size is set
in ble_serial_ops, so, without being able to test on anything other than
a OSTC3, I assume that this holds for other BLE DCs too. So, I think is
is weird that those interfaces work with the current read() of just one
packet at the time.
As we need a blocking read (at least for the OSTC parser), just read all
data that is available on the input. And when we think we are done, give
the QtEventloop control to see if there is more, and process that incoming
data as well. All this basically implements a blocking read.
CAVEAT 1: This might break the reading from the currently working BLE devices.
CAVEAT 2: With this, I still cannot read the OSTC3 completely. For
developers familiar with the HW transfer protocol: it just stops while
reading the first full dive (header + profile) command 0x66, despite
correctly reading about 5Kb of data before. For some
reason, I do not believe that this is related to this commit.
CAVEAT 3: All above tested on Linux Desktop with bluez stack, and
confirmed NOT to work on Android 7.1.2, build with Qt 5.9.0, And
yes, I know 5.9.1 recommended.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 07:03:30 +00:00
|
|
|
|
2018-09-26 18:23:57 +00:00
|
|
|
// Did we get more than asked for?
|
|
|
|
//
|
|
|
|
// Put back the left-over at the beginning of the
|
|
|
|
// received packet list, and truncate the packet
|
|
|
|
// we got to just the part asked for.
|
|
|
|
if ((size_t)packet.size() > size) {
|
|
|
|
receivedPackets.prepend(packet.mid(size));
|
|
|
|
packet.truncate(size);
|
|
|
|
}
|
2017-06-27 22:14:27 +00:00
|
|
|
|
2017-07-11 11:29:41 +00:00
|
|
|
memcpy((char *)data, packet.data(), packet.size());
|
2017-07-12 19:23:02 +00:00
|
|
|
if (actual)
|
|
|
|
*actual += packet.size();
|
BLE: read until no more data in coming in
The current BLE read reads just one 20 bype packet. That packet size is set
in ble_serial_ops, so, without being able to test on anything other than
a OSTC3, I assume that this holds for other BLE DCs too. So, I think is
is weird that those interfaces work with the current read() of just one
packet at the time.
As we need a blocking read (at least for the OSTC parser), just read all
data that is available on the input. And when we think we are done, give
the QtEventloop control to see if there is more, and process that incoming
data as well. All this basically implements a blocking read.
CAVEAT 1: This might break the reading from the currently working BLE devices.
CAVEAT 2: With this, I still cannot read the OSTC3 completely. For
developers familiar with the HW transfer protocol: it just stops while
reading the first full dive (header + profile) command 0x66, despite
correctly reading about 5Kb of data before. For some
reason, I do not believe that this is related to this commit.
CAVEAT 3: All above tested on Linux Desktop with bluez stack, and
confirmed NOT to work on Android 7.1.2, build with Qt 5.9.0, And
yes, I know 5.9.1 recommended.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
2017-07-04 07:03:30 +00:00
|
|
|
|
2019-01-21 22:14:03 +00:00
|
|
|
if (verbose > 2 || debugCounter < DEBUG_THRESHOLD)
|
|
|
|
qDebug() << QTime::currentTime() << "packet READ" << packet.toHex();
|
2018-09-24 03:04:08 +00:00
|
|
|
|
2017-06-13 02:47:50 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2018-09-23 19:07:01 +00:00
|
|
|
//
|
|
|
|
// select_preferred_service() gets called after all services
|
|
|
|
// have been discovered, and the discovery process has been
|
|
|
|
// started (by addService(), which calls service->discoverDetails())
|
|
|
|
//
|
|
|
|
// The role of this function is to wait for all service
|
|
|
|
// discovery to finish, and pick the preferred service.
|
|
|
|
//
|
|
|
|
// NOTE! Picking the preferred service is divecomputer-specific.
|
|
|
|
// Right now we special-case the HW known service number, but for
|
|
|
|
// others we just pick the first one that isn't a standard service.
|
|
|
|
//
|
|
|
|
// That's wrong, but works for the simple case.
|
|
|
|
//
|
|
|
|
dc_status_t BLEObject::select_preferred_service(void)
|
|
|
|
{
|
|
|
|
// Wait for each service to finish discovering
|
2018-09-24 23:11:51 +00:00
|
|
|
foreach (const QLowEnergyService *s, services) {
|
2018-09-23 19:07:01 +00:00
|
|
|
WAITFOR(s->state() != QLowEnergyService::DiscoveringServices, BLE_TIMEOUT);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Print out the services for debugging
|
2018-09-24 23:11:51 +00:00
|
|
|
foreach (const QLowEnergyService *s, services) {
|
2018-09-23 19:07:01 +00:00
|
|
|
qDebug() << "Found service" << s->serviceUuid() << s->serviceName();
|
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
foreach (const QLowEnergyCharacteristic &c, s->characteristics()) {
|
2018-09-23 19:07:01 +00:00
|
|
|
qDebug() << " c:" << c.uuid();
|
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
foreach (const QLowEnergyDescriptor &d, c.descriptors())
|
2018-09-23 19:07:01 +00:00
|
|
|
qDebug() << " d:" << d.uuid();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Pick the preferred one
|
2018-09-24 23:11:51 +00:00
|
|
|
foreach (QLowEnergyService *s, services) {
|
2018-09-23 19:07:01 +00:00
|
|
|
if (s->state() != QLowEnergyService::ServiceDiscovered)
|
|
|
|
continue;
|
|
|
|
|
2018-10-06 17:50:25 +00:00
|
|
|
bool hasread = false;
|
|
|
|
bool haswrite = false;
|
2018-09-23 19:07:01 +00:00
|
|
|
QBluetoothUuid uuid = s->serviceUuid();
|
|
|
|
|
2018-10-06 17:50:25 +00:00
|
|
|
foreach (const QLowEnergyCharacteristic &c, s->characteristics()) {
|
|
|
|
hasread |= is_read_characteristic(c);
|
|
|
|
haswrite |= is_write_characteristic(c);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!hasread) {
|
|
|
|
qDebug () << " .. ignoring service without read characteristic" << uuid;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!haswrite) {
|
|
|
|
qDebug () << " .. ignoring service without write characteristic" << uuid;
|
2018-09-23 19:07:01 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
// We now know that the service has both read and write characteristics
|
2018-09-23 19:07:01 +00:00
|
|
|
preferred = s;
|
|
|
|
qDebug() << "Using service" << s->serviceUuid() << "as preferred service";
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!preferred) {
|
|
|
|
qDebug() << "failed to find suitable service";
|
|
|
|
report_error("Failed to find suitable BLE GATT service");
|
|
|
|
return DC_STATUS_IO;
|
|
|
|
}
|
|
|
|
|
2018-09-25 22:20:33 +00:00
|
|
|
connect(preferred, &QLowEnergyService::stateChanged, this, &BLEObject::serviceStateChanged);
|
|
|
|
connect(preferred, &QLowEnergyService::characteristicChanged, this, &BLEObject::characteristcStateChanged);
|
|
|
|
connect(preferred, &QLowEnergyService::characteristicWritten, this, &BLEObject::characteristicWritten);
|
|
|
|
connect(preferred, &QLowEnergyService::descriptorWritten, this, &BLEObject::writeCompleted);
|
|
|
|
|
2018-09-23 19:07:01 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2017-07-05 16:37:21 +00:00
|
|
|
dc_status_t BLEObject::setHwCredit(unsigned int c)
|
|
|
|
{
|
|
|
|
/* The Terminal I/O client transmits initial UART credits to the server (see 6.5).
|
|
|
|
*
|
|
|
|
* Notice that we have to write to the characteristic here, and not to its
|
|
|
|
* descriptor as for the enabeling of notifications or indications.
|
|
|
|
*
|
|
|
|
* Futher notice that this function has the implicit effect of processing the
|
|
|
|
* event loop (due to waiting for the confirmation of the credit request).
|
|
|
|
* So, as characteristcStateChanged will be triggered, while receiving
|
|
|
|
* data from the OSTC, these are processed too.
|
|
|
|
*/
|
|
|
|
|
|
|
|
QList<QLowEnergyCharacteristic> list = preferredService()->characteristics();
|
|
|
|
isCharacteristicWritten = false;
|
|
|
|
preferredService()->writeCharacteristic(list[HW_OSTC_BLE_CREDITS_RX],
|
|
|
|
QByteArray(1, c),
|
|
|
|
QLowEnergyService::WriteWithResponse);
|
|
|
|
|
|
|
|
/* And wait for the answer*/
|
2018-09-23 18:58:25 +00:00
|
|
|
WAITFOR(isCharacteristicWritten, BLE_TIMEOUT);
|
|
|
|
|
2017-07-05 16:37:21 +00:00
|
|
|
if (!isCharacteristicWritten)
|
|
|
|
return DC_STATUS_TIMEOUT;
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2019-04-01 20:15:19 +00:00
|
|
|
dc_status_t BLEObject::setupHwTerminalIo(const QList<QLowEnergyCharacteristic> &allC)
|
2017-07-03 17:24:39 +00:00
|
|
|
{ /* This initalizes the Terminal I/O client as described in
|
|
|
|
* http://www.telit.com/fileadmin/user_upload/products/Downloads/sr-rf/BlueMod/TIO_Implementation_Guide_r04.pdf
|
|
|
|
* Referenced section numbers below are from that document.
|
|
|
|
*
|
|
|
|
* This is for all HW computers, that use referenced BT/BLE hardware module from Telit
|
|
|
|
* (formerly Stollmann). The 16 bit UUID 0xFEFB (or a derived 128 bit UUID starting with
|
|
|
|
* 0x0000FEFB is a clear indication that the OSTC is equipped with this BT/BLE hardware.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (allC.length() != 4) {
|
|
|
|
qDebug() << "This should not happen. HW/OSTC BT/BLE device without 4 Characteristics";
|
|
|
|
return DC_STATUS_IO;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The Terminal I/O client subscribes to indications of the UART credits TX
|
|
|
|
* characteristic (see 6.4).
|
|
|
|
*
|
|
|
|
* Notice that indications are subscribed to by writing 0x0200 to its descriptor. This
|
|
|
|
* can be understood by looking for Client Characteristic Configuration, Assigned
|
|
|
|
* Number: 0x2902. Enabling/Disabeling is setting the proper bit, and they
|
|
|
|
* differ for indications and notifications.
|
|
|
|
*/
|
|
|
|
QLowEnergyDescriptor d = allC[HW_OSTC_BLE_CREDITS_TX].descriptors().first();
|
|
|
|
preferredService()->writeDescriptor(d, QByteArray::fromHex("0200"));
|
|
|
|
|
|
|
|
/* The Terminal I/O client subscribes to notifications of the UART data TX
|
|
|
|
* characteristic (see 6.2).
|
|
|
|
*/
|
|
|
|
d = allC[HW_OSTC_BLE_DATA_TX].descriptors().first();
|
|
|
|
preferredService()->writeDescriptor(d, QByteArray::fromHex("0100"));
|
|
|
|
|
2017-07-05 16:37:21 +00:00
|
|
|
/* The Terminal I/O client transmits initial UART credits to the server (see 6.5). */
|
|
|
|
return setHwCredit(MAXIMAL_HW_CREDIT);
|
2017-07-03 17:24:39 +00:00
|
|
|
}
|
|
|
|
|
2018-10-01 00:15:52 +00:00
|
|
|
#if !defined(Q_OS_WIN)
|
2018-09-07 00:32:24 +00:00
|
|
|
// Bluez is broken, and doesn't have a sane way to query
|
|
|
|
// whether to use a random address or not. So we have to
|
|
|
|
// fake it.
|
|
|
|
static int use_random_address(dc_user_device_t *user_device)
|
|
|
|
{
|
|
|
|
return IS_SHEARWATER(user_device) || IS_GARMIN(user_device);
|
|
|
|
}
|
2018-10-01 00:15:52 +00:00
|
|
|
#endif
|
2018-09-07 00:32:24 +00:00
|
|
|
|
2018-05-21 15:36:04 +00:00
|
|
|
dc_status_t qt_ble_open(void **io, dc_context_t *, const char *devaddr, dc_user_device_t *user_device)
|
2017-06-13 02:47:50 +00:00
|
|
|
{
|
2017-07-06 14:21:04 +00:00
|
|
|
debugCounter = 0;
|
|
|
|
QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = true"));
|
|
|
|
|
2017-06-27 01:17:06 +00:00
|
|
|
/*
|
|
|
|
* LE-only devices get the "LE:" prepended by the scanning
|
|
|
|
* code, so that the rfcomm code can see they only do LE.
|
|
|
|
*
|
|
|
|
* We just skip that prefix (and it doesn't always exist,
|
|
|
|
* since the device may support both legacy BT and LE).
|
|
|
|
*/
|
|
|
|
if (!strncmp(devaddr, "LE:", 3))
|
|
|
|
devaddr += 3;
|
|
|
|
|
2017-06-13 02:47:50 +00:00
|
|
|
// HACK ALERT! Qt 5.9 needs this for proper Bluez operation
|
|
|
|
qputenv("QT_DEFAULT_CENTRAL_SERVICES", "1");
|
|
|
|
|
2017-09-17 23:31:07 +00:00
|
|
|
#if defined(Q_OS_MACOS) || defined(Q_OS_IOS)
|
2018-02-24 23:17:33 +00:00
|
|
|
QBluetoothDeviceInfo remoteDevice = getBtDeviceInfo(QString(devaddr));
|
2017-09-17 03:21:46 +00:00
|
|
|
QLowEnergyController *controller = QLowEnergyController::createCentral(remoteDevice);
|
2017-09-17 23:31:07 +00:00
|
|
|
#else
|
|
|
|
// this is deprecated but given that we don't use Qt to scan for
|
|
|
|
// devices on Android, we don't have QBluetoothDeviceInfo for the
|
|
|
|
// paired devices and therefore cannot use the newer interfaces
|
|
|
|
// that are preferred starting with Qt 5.7
|
|
|
|
QBluetoothAddress remoteDeviceAddress(devaddr);
|
|
|
|
QLowEnergyController *controller = new QLowEnergyController(remoteDeviceAddress);
|
|
|
|
#endif
|
2017-06-25 05:32:47 +00:00
|
|
|
qDebug() << "qt_ble_open(" << devaddr << ")";
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2018-09-30 14:50:03 +00:00
|
|
|
#if !defined(Q_OS_WIN)
|
2018-09-07 00:32:24 +00:00
|
|
|
if (use_random_address(user_device))
|
2017-06-27 22:14:27 +00:00
|
|
|
controller->setRemoteAddressType(QLowEnergyController::RandomAddress);
|
2018-09-30 14:50:03 +00:00
|
|
|
#endif
|
2017-06-27 22:14:27 +00:00
|
|
|
|
2017-06-27 13:58:36 +00:00
|
|
|
// Try to connect to the device
|
|
|
|
controller->connectToDevice();
|
2017-06-13 02:47:50 +00:00
|
|
|
|
|
|
|
// Create a timer. If the connection doesn't succeed after five seconds or no error occurs then stop the opening step
|
2018-09-23 18:58:25 +00:00
|
|
|
WAITFOR(controller->state() != QLowEnergyController::ConnectingState, BLE_TIMEOUT);
|
2017-06-13 02:47:50 +00:00
|
|
|
|
|
|
|
switch (controller->state()) {
|
|
|
|
case QLowEnergyController::ConnectedState:
|
2017-06-25 05:32:47 +00:00
|
|
|
qDebug() << "connected to the controller for device" << devaddr;
|
2017-06-13 02:47:50 +00:00
|
|
|
break;
|
2017-11-13 22:41:11 +00:00
|
|
|
case QLowEnergyController::ConnectingState:
|
|
|
|
qDebug() << "timeout while trying to connect to the controller " << devaddr;
|
|
|
|
report_error("Timeout while trying to connect to %s", devaddr);
|
|
|
|
delete controller;
|
|
|
|
return DC_STATUS_IO;
|
2017-06-13 02:47:50 +00:00
|
|
|
default:
|
2017-06-25 05:32:47 +00:00
|
|
|
qDebug() << "failed to connect to the controller " << devaddr << "with error" << controller->errorString();
|
2018-02-25 12:51:41 +00:00
|
|
|
report_error("Failed to connect to %s: '%s'", devaddr, qPrintable(controller->errorString()));
|
2017-06-13 02:47:50 +00:00
|
|
|
delete controller;
|
|
|
|
return DC_STATUS_IO;
|
|
|
|
}
|
|
|
|
|
2017-11-01 14:25:24 +00:00
|
|
|
// We need to discover services etc here!
|
|
|
|
// Note that ble takes ownership of controller and henceforth deleting ble will
|
|
|
|
// take care of deleting controller.
|
2018-04-17 01:14:59 +00:00
|
|
|
BLEObject *ble = new BLEObject(controller, user_device);
|
2017-06-13 02:47:50 +00:00
|
|
|
ble->connect(controller, SIGNAL(serviceDiscovered(QBluetoothUuid)), SLOT(addService(QBluetoothUuid)));
|
|
|
|
|
2017-06-25 05:32:47 +00:00
|
|
|
qDebug() << " .. discovering services";
|
2017-06-13 02:47:50 +00:00
|
|
|
|
|
|
|
controller->discoverServices();
|
2017-06-27 13:58:36 +00:00
|
|
|
|
2018-09-23 18:58:25 +00:00
|
|
|
WAITFOR(controller->state() != QLowEnergyController::DiscoveringState, BLE_TIMEOUT);
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2017-06-25 05:32:47 +00:00
|
|
|
qDebug() << " .. done discovering services";
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2018-09-23 19:07:01 +00:00
|
|
|
dc_status_t error = ble->select_preferred_service();
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2018-09-23 19:07:01 +00:00
|
|
|
if (error != DC_STATUS_SUCCESS) {
|
2017-06-27 12:56:30 +00:00
|
|
|
qDebug() << "failed to find suitable service on" << devaddr;
|
|
|
|
report_error("Failed to find suitable service on '%s'", devaddr);
|
2017-11-01 14:25:24 +00:00
|
|
|
delete ble;
|
2018-09-23 19:07:01 +00:00
|
|
|
return error;
|
2017-06-27 12:56:30 +00:00
|
|
|
}
|
|
|
|
|
2017-06-25 05:32:47 +00:00
|
|
|
qDebug() << " .. enabling notifications";
|
2017-06-13 02:47:50 +00:00
|
|
|
|
|
|
|
/* Enable notifications */
|
2017-06-27 12:56:30 +00:00
|
|
|
QList<QLowEnergyCharacteristic> list = ble->preferredService()->characteristics();
|
2018-09-24 23:11:51 +00:00
|
|
|
if (IS_HW(user_device)) {
|
|
|
|
dc_status_t r = ble->setupHwTerminalIo(list);
|
|
|
|
if (r != DC_STATUS_SUCCESS) {
|
|
|
|
delete ble;
|
|
|
|
return r;
|
|
|
|
}
|
|
|
|
} else {
|
2019-04-01 20:15:19 +00:00
|
|
|
for (const QLowEnergyCharacteristic &c: list) {
|
2018-09-24 23:11:51 +00:00
|
|
|
if (!is_read_characteristic(c))
|
|
|
|
continue;
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
qDebug() << "Using read characteristic" << c.uuid();
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2019-04-01 20:15:19 +00:00
|
|
|
const QList<QLowEnergyDescriptor> l = c.descriptors();
|
2018-09-24 23:11:51 +00:00
|
|
|
QLowEnergyDescriptor d = l.first();
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2019-04-01 20:15:19 +00:00
|
|
|
for (const QLowEnergyDescriptor &tmp: l) {
|
2018-09-24 23:11:51 +00:00
|
|
|
if (tmp.type() == QBluetoothUuid::ClientCharacteristicConfiguration) {
|
|
|
|
d = tmp;
|
|
|
|
break;
|
2017-09-17 16:48:52 +00:00
|
|
|
}
|
2018-09-24 23:11:51 +00:00
|
|
|
}
|
2017-09-17 16:48:52 +00:00
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
qDebug() << "now writing \"0x0100\" to the descriptor" << d.uuid().toString();
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
ble->preferredService()->writeDescriptor(d, QByteArray::fromHex("0100"));
|
2018-10-06 18:26:26 +00:00
|
|
|
WAITFOR(ble->descriptorWritten(), 1000);
|
2018-09-24 23:11:51 +00:00
|
|
|
break;
|
2017-06-13 02:47:50 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Fill in info
|
2018-04-17 01:14:59 +00:00
|
|
|
*io = (void *)ble;
|
2017-06-13 02:47:50 +00:00
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2018-04-17 01:14:59 +00:00
|
|
|
dc_status_t qt_ble_close(void *io)
|
2017-06-13 02:47:50 +00:00
|
|
|
{
|
2018-04-17 01:14:59 +00:00
|
|
|
BLEObject *ble = (BLEObject *) io;
|
2017-06-13 02:47:50 +00:00
|
|
|
|
|
|
|
delete ble;
|
|
|
|
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
2017-07-06 14:21:04 +00:00
|
|
|
static void checkThreshold()
|
|
|
|
{
|
|
|
|
if (++debugCounter == DEBUG_THRESHOLD) {
|
|
|
|
QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* = false"));
|
|
|
|
qDebug() << "turning off further BT debug output";
|
|
|
|
}
|
|
|
|
}
|
2017-06-13 02:47:50 +00:00
|
|
|
|
2018-10-06 18:43:48 +00:00
|
|
|
/*
|
|
|
|
* NOTE! The 'set_timeout()' function only affects the timeout
|
|
|
|
* for qt_ble_read(), not for the various general BLE operations.
|
|
|
|
*/
|
|
|
|
dc_status_t qt_ble_set_timeout(void *io, int timeout)
|
|
|
|
{
|
|
|
|
BLEObject *ble = (BLEObject *) io;
|
|
|
|
ble->set_timeout(timeout);
|
|
|
|
return DC_STATUS_SUCCESS;
|
|
|
|
}
|
|
|
|
|
2018-04-17 01:14:59 +00:00
|
|
|
dc_status_t qt_ble_read(void *io, void* data, size_t size, size_t *actual)
|
2017-06-13 02:47:50 +00:00
|
|
|
{
|
2017-07-06 14:21:04 +00:00
|
|
|
checkThreshold();
|
2018-04-17 01:14:59 +00:00
|
|
|
BLEObject *ble = (BLEObject *) io;
|
2017-06-13 02:47:50 +00:00
|
|
|
return ble->read(data, size, actual);
|
|
|
|
}
|
|
|
|
|
2018-04-17 01:14:59 +00:00
|
|
|
dc_status_t qt_ble_write(void *io, const void* data, size_t size, size_t *actual)
|
2017-06-13 02:47:50 +00:00
|
|
|
{
|
2017-07-06 14:21:04 +00:00
|
|
|
checkThreshold();
|
2018-04-17 01:14:59 +00:00
|
|
|
BLEObject *ble = (BLEObject *) io;
|
2017-06-13 02:47:50 +00:00
|
|
|
return ble->write(data, size, actual);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
dc_status_t qt_ble_poll(void *io, int timeout)
|
2018-10-06 18:23:08 +00:00
|
|
|
{
|
|
|
|
BLEObject *ble = (BLEObject *) 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
|
|
|
|
|
|
|
return ble->poll(timeout);
|
2018-10-06 18:23:08 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
dc_status_t qt_ble_ioctl(void *io, unsigned int request, void *data, size_t size)
|
|
|
|
{
|
|
|
|
BLEObject *ble = (BLEObject *) io;
|
|
|
|
|
|
|
|
switch (request) {
|
|
|
|
case DC_IOCTL_BLE_GET_NAME:
|
|
|
|
return ble->get_name((char *) data, size);
|
|
|
|
default:
|
|
|
|
return DC_STATUS_UNSUPPORTED;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-06-13 02:47:50 +00:00
|
|
|
} /* extern "C" */
|