Some OSTC 2 and OSTC Plus variants show 'OSTC+ xxxxx' as BLE name and we
recognized this as OSTC 3 (but that one doesn't support BLE). With this
we recognize these models as OSTC 2 (which is identical from a download
perspective to the OSTC Plus) and both of those support BLE.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Detection isn't required, but it makes things easier. For the Mares dive
computers we only see the Bluelink, so we can't tell which dive computer is
connected to it. We guess "Quad", but the user can pick a different one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The previous code would not add the non-LE address for dual stack
devices. Unfortunately, even with this fix we still don't get the
correct result for the dual stack Shearwater Petrel 2 that I have
for testing as Android incorrectly reports it as a BLE-only device.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This converts our old custom IO model to the new model that
libdivecomputer introduced. This is partly based on Jef's rough patch
to make things build, with further work by me.
The FTDI code is temporarily disabled here, because it will need to be
integrated with the new way of opening devices.
The ble_serial code goes away entirely, since now libdivecomputer knows
about BLE transport natively, and doesn't need to have any serial
wrapper around it.
Signed-off-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Each callsite of saveBtDeviceInfo() has a QString, which is converted
to a C-string, passed and immediately converted back. Remove these
conversions by taking a reference to QString directly.
getBtDeviceInfo() is not as clear. Here, the callsite has a C-string
handed down from libdivecomputer. Nevertheless, pass a reference of
QString here as well. Firstly, for reasons of symmetry. Secondly,
to avoid multiple conversions in the getBtDeviceInfo() functions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Mostly replace "return (expression);" by "return expression;" and one
case of "function((parameter))" by "function(parameter)".
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Realistically this is a false positive as we should never use a second
BTDiscovery instance - but there's nothing wrong with being extra certain.
Coverity CID 208319
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On iOS save all discovered devices. Later qt_ble_open queries this
list in order to actually connect to the remove device.
The Desktop code stores this data with the list items and only saves
when the "Save" button is clicked. This is not supported with the
current ConnectionListModel implementation.
Signed-off-by: Murillo Bernardes <mfbernardes@gmail.com>
Some BT devices support both, classical and LE, modes. Users could
choose either by prepending or removing "LE:" in the device address
field. After commit d23bd46a1b, the
device field is always disabled in Bluetooth mode.
Therefore, add a mode combo box to the Bluetooth device selection
dialog. In the default mode (auto), the old code path (based on
the Qt device flags) is used. The two other modes (force LE, force
classical) allow the user to force the preferred behavior.
This feature is meant as a stop-gap measure until a more refined
transport choice is implemented. Therefore, the value of the new
combo box is not saved in the settings, to avoid cluttering of
the preferences with soon to be obsolete entries.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Recognize Aladin as the Bluetooth name of the Scubapro Aladin Sport
Matrix. Note that the Scubapro Aladin H Matrix most likely also
identifies itself using this BT name. But it probably uses the same
BT protocol (i.e. the G2 protocol) and therefore this should not pose
a problem. Ultimately a common name should be found.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
QMap::operator[] creates a new default constructed entry in the map
if no entry with the given key exists. While not problematic (since
typically nullptrs are inserted) this is usually not what you want
for read access.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This commit implements possible switching BT on and off during a session,
so not needing a restart of the app when the user forgot to switch
it on when starting the app.
For this, the following needed to be done: 1) create a handler that
reacts on local BT device status changes. 2) repopulate the connection
list in the download screen when a BT status change is detected.
Notice the subtile change of the Q_INVOKABLE btEnabled() function
to a Q_PROPERTY. This gives a nice dynamic behaviour when
switching BT on/off with the app open.
Fixes: #556
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Right now this will only work if you scan for your BLE dive computer every
time. Ideally we should simply initiate a scan and look for that address if
it's not found in the hash.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Apparently, OSTC Sport has a BT name like OSTCs<space><serial>.
Small code addition to detect this properly. As long as we
do not have an improved way of detection. Notice that most of
the HWs use the same BT hardware, so simple detection on offered
services will not work.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This should be much more robust in getting us the correct Bluetooth address
and the correct vendor / product for our selection.
When we pick a paired device, we extract the address right from its name.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This really doesn't help us as we can't associate a vendor/product with
devices we don't recognize, so we can't download from them, anyway.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For DCs that support both BT and LE, allow the user to connect to both
interface layers. Maybe not usefull in the end (as BT is faster
than LE), but as long as BT on Android is WIP is it very useful
to be able to connect to the interface layer we like.
Just add it to the Paired Devices list twice. The normal way, and
the LE: prepend way.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Major functional change in this commit is the addition of found static BT devices
to the internal administration (on Android), in a way that is equivalent to
mobile-on-desktop. So, in both cases, the list of devices in the app are
as in the list of devices on the host OS (Linux or Android). To minimize code
duplication, the btDeviceDiscovered slot is split in two parts, the part to
act as slot for the Qt BT discovery agent (Linux, so mobile-on-desktop), and
the part only needed for Android.
Remaining to be fixed: the correct handling of the QML UI selection of
vendor/product. The first default dive computer is correctly detected,
all paired devices from the virtual vendow can be selected, but clicking
through vendors results in non logical selections. It is obvious why
this is, but a fix is not straigforward at this point.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a central function to convert a BT name to a vendor/product pair
known to Subsurface. This allows interfacing from a paired BT dive
computer, without actively selecting its type, but by selecting it
from the list of paired BT devices. So, after this, downloading from
multiple (paired) DCs is also possible.
And not the niced piece of code ...
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems a very trivial commit, but it is not. It appears that on an Android
build, with defined(Q_OS_ANDROID) the Q_OS_LINUX variable is also defined.
This results in a very tricky discovery process: 1) the JNI stuff pulls the paired
devices from the local BT controller, and 2) The QT discovry agent gets active
BT devices. 1) is a static list, that is, not dependent on actual
visual/discoverable BT devices; it is just cached data from the phone. 2) On
Android, this results in a list of actively visible (paired and not paired)
devices. On desktop, however (with QT/bluez BT stack) the QT discovery agent
just gets the list of paired devices, so more or less equivalent to the situation
described under 1) for Android.
Ok, a long story, but just do not do a discovery on Android at all. Basically,
we need the BT address, device name, and possibly a specific SPP service UUID. This are
fixed and known for HW and Shearwater at this point, so there is no need for a
(lengthy) discovery process, and making sure the the dive computer is discoverable
at the moment the app wants to construct its data to show in the UI. So, the
static list of paired devices is all we need.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It's possible that the user has more than one dive computer with the
same name paired with their computer / device. So let's just add the
address to the name to make it possible to tell those apart.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Added a list of paired BT devices for the "Paired BT Devices" vendor. The
devices under this vendor represent all BT devces that can be found
from the local BT interface. Some special processing is required, as
the BT provided data is (obviously) missing the specific data needed
to open a BT device using libdc code. This processing is not in
this commit, but will follow. This commit is preparation for that.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This shouldn't be part of the UI (qmlmanager), but part of our
overall handling of dive computers and BT devices.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
