Note that we don't really have libdivecomputer support for it yet, only
newly added model numbers etc. But the name detection should make it
easier for people to at least download a memory dump.
In addition to the libdivecomputer model number updates, this also has a
merge of Jef's upstram libdivecomputer changes.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is just a trivial update to recognize the BT name, and a
libdivecomputer submodule update to get the updates to libdivecomputer
to recognize the new USB IDs etc.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
See https://www.kdab.com/goodbye-q_foreach/
This is reduced to the places where the container is const or can be made const
without the need to always introduce an extra variable. Sadly qAsConst (Qt 5.7)
and std::as_const (C++17) are not available in all supported setups.
Also do some minor cleanups along the way.
Signed-off-by: Rolf Eike Beer <eike@sf-mail.de>
And offer an option to show all devices in the settings. This is intentionally
not stored in the preferences as this should never be needed. We don't support
BT or BLE dive computers that we don't recognize. This is a last resort in case
a new firmware were to change the name or some other weird issue causes us not
to recognize a dive computer - and that should be fixed instead of worked
around.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
By default we'll only show devices that we believe to be dive computers,
but the user can override that with the recently introduced check box.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
At least on a Mac we can get here without a discoveryAgent if BT is off,
so don't derefence the NULL pointer in that case.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is an attempt to fix issue #1896. While this seems a Qt issue in
combination with very specific Android devices, this might be a fix. Do
not check for a very specific state of the local BT controller, but just
check if it is powered on.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Just like with the Aqualung i770R in 7697003498 this name follows the
pattern of a model number in ASCII encoding, followed by the serial
number of the device.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The name seems crazy until you realize that FQ is 0x4651 which is the model
number of the i770R. And the six digits are the serial number of the device.
Still crazy, but at least now you understand WHY.
Thanks to Jef for decoding that.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes no sense, but apparently we need to start a fresh scan in order to be able
to talk to a different BLE dive computer on the Mac.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On macOS, we cannot connect to a BT/BLE device until we have scanned it. Right
now this just sits quietly and waits, which given how long this can take is
rather unsatisfying and might look like Subsurface is hung.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since we trigger a scan even without the dialog to pick the right
device, we need to remember all devices that we find.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of only starting the scan when explicitly asked to do so in the BT
dialog, create the discovery agent when the download dialog opens, since on
macOS we cannot connect to a device without having scanned for it first.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
