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