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
|
|
|
|
2022-01-29 15:47:56 +00:00
|
|
|
#define MAXIMAL_HW_CREDIT 254
|
2017-07-05 16:37:21 +00:00
|
|
|
#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)) {
|
2022-01-29 15:47:56 +00:00
|
|
|
if (c.uuid() == telit[TELIT_DATA_TX] || c.uuid() == ublox[UBLOX_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)) {
|
2022-01-29 15:47:56 +00:00
|
|
|
if (c.uuid() == telit[TELIT_CREDITS_RX] || c.uuid() == ublox[UBLOX_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
|
|
|
}
|
|
|
|
|
2020-09-16 17:12:56 +00:00
|
|
|
struct uuid_match {
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
const char *uuid, *details;
|
|
|
|
};
|
|
|
|
|
2020-09-16 18:01:09 +00:00
|
|
|
static const char *match_uuid_list(const QBluetoothUuid &match, const struct uuid_match *array)
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
{
|
|
|
|
const char *uuid;
|
|
|
|
|
|
|
|
while ((uuid = array->uuid) != NULL) {
|
2022-02-10 00:13:20 +00:00
|
|
|
if (match == QBluetoothUuid(QUuid(uuid)))
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
return array->details;
|
|
|
|
array++;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// Known BLE GATT service UUID's that we should prefer for the serial
|
|
|
|
// emulation.
|
|
|
|
//
|
|
|
|
// The Bluetooth SIG is a disgrace, and never standardized any serial
|
|
|
|
// communication over BLE. They should just have specified a standard
|
|
|
|
// UUID for serial service, but preferred their idiotic model of
|
|
|
|
// "vendor specific" garbage instead. So everybody has made their own
|
|
|
|
// serial protocol over BLE GATT, which all look fairly similar, but
|
|
|
|
// with pointless and stupid differences just because the BLE SIG
|
|
|
|
// couldn't be arsed to do their job properly.
|
|
|
|
//
|
|
|
|
// Am I bitter? Just a bit. I know that "standards bodies" is just a
|
|
|
|
// fancy way of saying "incompetent tech politics", but still.. It's
|
|
|
|
// not like legacy BT didn't have a standard serial encapsulation.
|
|
|
|
// Oh. It did, didn't it?
|
|
|
|
//
|
2020-09-16 17:12:56 +00:00
|
|
|
static const struct uuid_match serial_service_uuids[] = {
|
2022-01-29 15:47:56 +00:00
|
|
|
{ "0000fefb-0000-1000-8000-00805f9b34fb", "Heinrichs-Weikamp (Telit/Stollmann)" },
|
|
|
|
{ "2456e1b9-26e2-8f83-e744-f34f01e9d701", "Heinrichs-Weikamp (U-Blox)" },
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
{ "544e326b-5b72-c6b0-1c46-41c1bc448118", "Mares BlueLink Pro" },
|
|
|
|
{ "6e400001-b5a3-f393-e0a9-e50e24dcca9e", "Nordic Semi UART" },
|
2020-05-17 19:08:23 +00:00
|
|
|
{ "98ae7120-e62e-11e3-badd-0002a5d5c51b", "Suunto (EON Steel/Core, G5)" },
|
|
|
|
{ "cb3c4555-d670-4670-bc20-b61dbc851e9a", "Pelagic (i770R, i200C, Pro Plus X, Geo 4.0)" },
|
2023-11-02 17:48:23 +00:00
|
|
|
{ "ca7b0001-f785-4c38-b599-c7c5fbadb034", "Pelagic (i330R, DSX)" },
|
2020-05-17 19:08:23 +00:00
|
|
|
{ "fdcdeaaa-295d-470e-bf15-04217b7aa0a0", "ScubaPro G2"},
|
2020-08-21 22:43:38 +00:00
|
|
|
{ "fe25c237-0ece-443c-b0aa-e02033e7029d", "Shearwater (Perdix/Teric/Peregrine)" },
|
2023-11-02 17:38:18 +00:00
|
|
|
{ "0000fcef-0000-1000-8000-00805f9b34fb", "Divesoft" },
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
{ NULL, }
|
|
|
|
};
|
|
|
|
|
|
|
|
//
|
|
|
|
// Sometimes we don't know which is the good service, but we can tell
|
|
|
|
// that a service is NOT a serial service because we've seen that
|
|
|
|
// people use it for firmware upgrades.
|
|
|
|
//
|
2020-09-16 17:12:56 +00:00
|
|
|
static const struct uuid_match upgrade_service_uuids[] = {
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
{ "00001530-1212-efde-1523-785feabcd123", "Nordic Upgrade" },
|
2020-05-17 19:08:23 +00:00
|
|
|
{ "9e5d1e47-5c13-43a0-8635-82ad38a1386f", "Broadcom Upgrade #1" },
|
|
|
|
{ "a86abc2d-d44c-442e-99f7-80059a873e36", "Broadcom Upgrade #2" },
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
{ NULL, }
|
|
|
|
};
|
|
|
|
|
|
|
|
static const char *is_known_serial_service(const QBluetoothUuid &service)
|
|
|
|
{
|
2020-09-16 18:01:09 +00:00
|
|
|
return match_uuid_list(service, serial_service_uuids);
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static const char *is_known_bad_service(const QBluetoothUuid &service)
|
|
|
|
{
|
2020-09-16 18:01:09 +00:00
|
|
|
return match_uuid_list(service, upgrade_service_uuids);
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
}
|
|
|
|
|
2017-06-13 02:47:50 +00:00
|
|
|
void BLEObject::addService(const QBluetoothUuid &newService)
|
|
|
|
{
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
const char *details;
|
|
|
|
|
2017-06-27 11:50:19 +00:00
|
|
|
qDebug() << "Found service" << newService;
|
|
|
|
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
//
|
|
|
|
// Known bad service that we should ignore?
|
|
|
|
// (typically firmware update service).
|
|
|
|
//
|
|
|
|
details = is_known_bad_service(newService);
|
|
|
|
if (details) {
|
|
|
|
qDebug () << " .. ignoring service" << details;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// If it's a known serial service, clear any other previous
|
|
|
|
// services we've found - we'll use this one.
|
|
|
|
//
|
|
|
|
// Note that if it's not _known_ to be good, we'll ignore
|
|
|
|
// any standard services. They are usually things like battery
|
|
|
|
// status or device name services.
|
|
|
|
//
|
|
|
|
// But Heinrich-Weicamp actually has a standard service ID in the
|
|
|
|
// known good category, because Telit/Stollmann (the manufacturer)
|
|
|
|
// applied for a UUID for its product.
|
|
|
|
//
|
|
|
|
// If it's not a known service, and not a standard one, we'll just
|
|
|
|
// add it to the list and then we'll try our heuristics on that
|
|
|
|
// list.
|
|
|
|
//
|
|
|
|
details = is_known_serial_service(newService);
|
|
|
|
if (details) {
|
|
|
|
qDebug () << " .. recognized service" << details;
|
|
|
|
services.clear();
|
2018-10-06 17:50:25 +00:00
|
|
|
} else {
|
|
|
|
bool isStandardUuid = false;
|
|
|
|
|
|
|
|
newService.toUInt16(&isStandardUuid);
|
|
|
|
if (isStandardUuid) {
|
BLE: add list of known good/bad BLE GATT services
We've tried to do this "automagic" service discovery, and it mostly
works, but then occasionally it doesn't.
Making things worse, I think different platforms end up enumerating
services differently, so our "pick the first service that looks like it
might be a serial service" ends up working on some platforms, but not
necessarily on others. Because "first" might be different.
So start a list of known good/bad services - and fall back to the old
logic when you can't decide reliably.
This fills in juat a few cases that I can easily check myself, and the
"details" field for them may be incomplete. For example, I know Nordic
Semiconductor has their vendor-specific UUIDs, and they can be found in
different devices, so calling them "Nordic UART" and "Nordic Flash"
services makes sense.
But the "Scubapro i770R" service? It might indeed be specific to the
Scubapro i770R. Or it might be a general service UUID that Pelagic
uses. Or it might be the service UUID of a particular chip, and found
in dive computers from other designs too (and not necessarily in all
i770R's either).
So this is a preliminary first stab at this, and I'm sure we'll extend
the list and possibly improve on the explanations.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-05-16 18:30:20 +00:00
|
|
|
qDebug () << " .. ignoring standard service";
|
2018-10-06 17:50:25 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-27 12:56:30 +00:00
|
|
|
auto service = controller->createServiceObject(newService, this);
|
2017-06-13 02:47:50 +00:00
|
|
|
if (service) {
|
2020-08-21 22:47:10 +00:00
|
|
|
// provide some visibility into what's happening in the log
|
|
|
|
service->connect(service, &QLowEnergyService::stateChanged,[=](QLowEnergyService::ServiceState newState) {
|
|
|
|
qDebug() << " .. service state changed to" << newState;
|
|
|
|
});
|
2022-02-10 00:13:20 +00:00
|
|
|
#if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
|
|
|
|
service->connect(service, &QLowEnergyService::errorOccurred,
|
|
|
|
#else
|
2020-08-21 22:47:10 +00:00
|
|
|
service->connect(service, QOverload<QLowEnergyService::ServiceError>::of(&QLowEnergyService::error),
|
2022-02-10 00:13:20 +00:00
|
|
|
#endif
|
2020-08-21 22:47:10 +00:00
|
|
|
[=](QLowEnergyService::ServiceError newError) {
|
|
|
|
qDebug() << "error discovering service details" << newError;
|
|
|
|
});
|
2017-06-27 12:56:30 +00:00
|
|
|
services.append(service);
|
2020-08-21 22:47:10 +00:00
|
|
|
qDebug() << "starting service characteristics discovery";
|
2017-06-13 02:47:50 +00:00
|
|
|
service->discoverDetails();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-10-19 16:42:43 +00:00
|
|
|
BLEObject::BLEObject(QLowEnergyController *c, device_data_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
|
|
|
}
|
|
|
|
|
2020-09-16 18:01:09 +00:00
|
|
|
/*
|
|
|
|
* The McLean Extreme has just one vendor service, but then inside that
|
|
|
|
* service it has several characteristics, and it's not obvious which
|
|
|
|
* ones are the read/write ones.
|
|
|
|
*
|
|
|
|
* So just make sure to skip the ones we don't want.
|
|
|
|
*
|
|
|
|
* The proper ones are:
|
|
|
|
*
|
|
|
|
* Microchip service UUID: 49535343-fe7d-4ae5-8fa9-9fafd205e455
|
|
|
|
* TX characteristic: 49535343-1e4d-4bd9-ba61-23c647249616
|
|
|
|
* RX characteristic: 49535343-8841-43f4-a8d4-ecbe34729bb3
|
|
|
|
*/
|
|
|
|
static const struct uuid_match skip_characteristics[] = {
|
|
|
|
{ "49535343-6daa-4d02-abf6-19569aca69fe", "McLean Extreme Avoid" },
|
|
|
|
{ "49535343-aca3-481c-91ec-d85e28a60318", "McLean Extreme Avoid" },
|
|
|
|
{ "49535343-026e-3a9b-954c-97daef17e26e", "McLean Extreme Avoid" },
|
|
|
|
{ "49535343-4c8a-39b3-2f49-511cff073b7e", "McLean Extreme Avoid" },
|
|
|
|
{ NULL, }
|
|
|
|
};
|
|
|
|
|
2018-09-24 23:11:51 +00:00
|
|
|
// a write characteristic needs Write or WriteNoResponse
|
|
|
|
static bool is_write_characteristic(const QLowEnergyCharacteristic &c)
|
|
|
|
{
|
2020-09-16 18:01:09 +00:00
|
|
|
if (match_uuid_list(c.uuid(), skip_characteristics))
|
|
|
|
return false;
|
2018-09-24 23:11:51 +00:00
|
|
|
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)
|
|
|
|
{
|
2020-09-16 18:01:09 +00:00
|
|
|
if (match_uuid_list(c.uuid(), skip_characteristics))
|
|
|
|
return false;
|
2018-09-24 23:11:51 +00:00
|
|
|
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) {
|
2022-02-10 00:13:20 +00:00
|
|
|
#if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
|
|
|
|
WAITFOR(s->state() != QLowEnergyService::RemoteServiceDiscovering, BLE_TIMEOUT);
|
|
|
|
if (s->state() == QLowEnergyService::RemoteServiceDiscovering)
|
|
|
|
#else
|
2018-09-23 19:07:01 +00:00
|
|
|
WAITFOR(s->state() != QLowEnergyService::DiscoveringServices, BLE_TIMEOUT);
|
2020-08-21 22:47:10 +00:00
|
|
|
if (s->state() == QLowEnergyService::DiscoveringServices)
|
2022-02-10 00:13:20 +00:00
|
|
|
#endif
|
2020-08-21 22:47:10 +00:00
|
|
|
qDebug() << " .. service " << s->serviceUuid() << "still hasn't completed discovery - trouble ahead";
|
2018-09-23 19:07:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// 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) {
|
2022-02-10 00:13:20 +00:00
|
|
|
#if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
|
|
|
|
if (s->state() != QLowEnergyService::RemoteServiceDiscovered)
|
|
|
|
#else
|
2018-09-23 19:07:01 +00:00
|
|
|
if (s->state() != QLowEnergyService::ServiceDiscovered)
|
2022-02-10 00:13:20 +00:00
|
|
|
#endif
|
2018-09-23 19:07:01 +00:00
|
|
|
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();
|
2022-01-29 15:47:56 +00:00
|
|
|
int credits_rx = list.length() == 4 ? TELIT_CREDITS_RX : UBLOX_CREDITS_RX;
|
2017-07-05 16:37:21 +00:00
|
|
|
isCharacteristicWritten = false;
|
2022-01-29 15:47:56 +00:00
|
|
|
preferredService()->writeCharacteristic(list[credits_rx],
|
2017-07-05 16:37:21 +00:00
|
|
|
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.
|
|
|
|
*/
|
|
|
|
|
2022-01-29 15:47:56 +00:00
|
|
|
if (allC.length() != 4 && allC.length() != 2) {
|
|
|
|
qDebug() << "This should not happen. HW/OSTC BT/BLE device without 2(UBLOX) or 4(TELIT) Characteristics";
|
2017-07-03 17:24:39 +00:00
|
|
|
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.
|
|
|
|
*/
|
2022-01-29 15:47:56 +00:00
|
|
|
int credits_tx = allC.length() == 4 ? TELIT_CREDITS_TX : UBLOX_CREDITS_TX;
|
|
|
|
QLowEnergyDescriptor d = allC[credits_tx].descriptors().first();
|
2017-07-03 17:24:39 +00:00
|
|
|
preferredService()->writeDescriptor(d, QByteArray::fromHex("0200"));
|
|
|
|
|
|
|
|
/* The Terminal I/O client subscribes to notifications of the UART data TX
|
|
|
|
* characteristic (see 6.2).
|
|
|
|
*/
|
2022-01-29 15:47:56 +00:00
|
|
|
int data_tx = allC.length() == 4 ? TELIT_DATA_TX : UBLOX_DATA_TX;
|
|
|
|
d = allC[data_tx].descriptors().first();
|
2017-07-03 17:24:39 +00:00
|
|
|
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.
|
2020-10-19 16:42:43 +00:00
|
|
|
static int use_random_address(device_data_t *user_device)
|
2018-09-07 00:32:24 +00:00
|
|
|
{
|
|
|
|
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
|
|
|
|
2020-10-19 16:42:43 +00:00
|
|
|
dc_status_t qt_ble_open(void **io, dc_context_t *, const char *devaddr, device_data_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");
|
|
|
|
|
2022-02-14 20:52:02 +00:00
|
|
|
#if defined(Q_OS_MACOS) || defined(Q_OS_IOS) || QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
|
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);
|
2020-08-21 22:57:26 +00:00
|
|
|
// we used to call our addService function the moment a service was discovered, but that
|
|
|
|
// could cause us to try to discover the details of a characteristic while we were still serching
|
|
|
|
// for services, which can cause a failure in the Qt BLE stack.
|
|
|
|
// While that actual error was likely caused by a bug in BLE implementation of a dive computer,
|
|
|
|
// the underlying issue still seems worth addressing.
|
|
|
|
// Finish discovering the services, then add all those services and discover their characteristics.
|
|
|
|
ble->connect(controller, &QLowEnergyController::discoveryFinished, [=] {
|
|
|
|
qDebug() << "finished service discovery, start discovering characteristics";
|
|
|
|
foreach(QBluetoothUuid s, controller->services()) {
|
|
|
|
ble->addService(s);
|
|
|
|
}
|
|
|
|
});
|
2022-02-10 00:13:20 +00:00
|
|
|
#if QT_VERSION >= QT_VERSION_CHECK(6, 0, 0)
|
|
|
|
ble->connect(controller, &QLowEnergyController::errorOccurred, [=](QLowEnergyController::Error newError) {
|
|
|
|
#else
|
2020-08-21 22:57:26 +00:00
|
|
|
ble->connect(controller, QOverload<QLowEnergyController::Error>::of(&QLowEnergyController::error), [=](QLowEnergyController::Error newError) {
|
2022-02-10 00:13:20 +00:00
|
|
|
#endif
|
2020-08-21 22:57:26 +00:00
|
|
|
qDebug() << "controler discovery error" << controller->errorString() << newError;
|
|
|
|
});
|
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);
|
2020-08-21 22:57:26 +00:00
|
|
|
if (controller->state() == QLowEnergyController::DiscoveringState)
|
|
|
|
qDebug() << " .. even after waiting for the full BLE timeout, controller is still in discovering state";
|
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) {
|
2021-03-12 12:20:38 +00:00
|
|
|
if (tmp.type() == QBluetoothUuid::DescriptorType::ClientCharacteristicConfiguration) {
|
2018-09-24 23:11:51 +00:00
|
|
|
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);
|
2023-09-01 18:24:30 +00:00
|
|
|
if (!ble->descriptorWritten()) {
|
|
|
|
qDebug() << "Bluetooth: Failed to enable notifications for characteristic" << c.uuid();
|
|
|
|
report_error("Bluetooth: Failed to enable notifications.");
|
|
|
|
delete ble;
|
|
|
|
return DC_STATUS_TIMEOUT;
|
|
|
|
}
|
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" */
|