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>
Only filter against the hard coded list if no other supported transports
are available for a dive computer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For example, even on platforms that support libusb, libdivecomputer
might be compiled without such support.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user specified bluetooth, we really should pick bluetooth, not
probe and possibly fall back to something else.
We should also honor the users choice of BLE vs classic BT.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In firmware version 2.97 the setting 0x38, SETPOINT FALLBACK, has bin
obsoleted and we get a error when trying to write to it.
This removes this setting.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
On Android we still need to do more filtering as only some of the USB
divecomputers are supported. But on iOS this takes care of it without
the hard coded list.
Additionally, if built without BT or BLE support, the corresponding dive
computers are no longer shown (e.g. Perdix AI on Windows).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This opportunistically uses a cache of 'fingerprints' for already
downloaded dives.
As we download data from a dive computer, we save the fingerprint and
dive ID of the most recent dive in a per-divecopmputer fingerprint cache
file.
The next time we download from that dive computer, we will load the
cache file for that dive computer if it exists, verify that we still
have the dive that is referenced in that cachefile, and if so use the
fingerprint to let libdivecomputer potentially stop downloading dives
early.
This doesn't much matter for most dive computers, but some (like the
Scubapro G2) are not able to download one dive at a time, and need the
fingerprint to avoid doing a full dump. That is particularly noticeable
over bluetooth, where a full dump can be very slow.
NOTE! The fingerprint cache is a separate entity from the dive log
itself. Unlike the dive log, it doesn't synchronize over the cloud, so
if you download using different clients (say, your phone and your
laptop), the fingerprint cache entries are per device.
So you may still end up downloading dives you already have, because the
fingerprint code basically only works to avoid duplicate downloads on
the same installation.
Also, note that we only have a cache of one single entry per dive
computer and downloader, so if you download dives and then don't save
the end result, the fingerprint will now point to a dive that you don't
actually have in your dive list. As a result, next time you download,
the fingerprint won't match any existing dive, and we'll resort to the
old non-optimized behavior.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This creates a new libdivecomputer_device_open() helper, and makes
downloading and configuration use it to open the dive computer device
using the proper protocol.
The IRDA case was tested by Sébastien Dugué - I had initially left it
undone believing that "nobody uses IRDA".
Reported-and-tested-by: Sébastien Dugué <sebastien.dugue.subsurface@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.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>
It makes sense to be able to control this with command line options.
On Travis this avoids the signing problem and makes the build much faster.
Still should be enough to catch iOS breakage.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Disable most warnings for iOS test build as otherwise the Travis log file will
exceed 4MB and the build will fail.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
updated INSTALL to reflect the review comments
Among others made homebrew / manual install equal choices as well
as Xcode / QtCreator.
Signed-off-by: Jan Iversen <jani@apache.org>
INSTALL is updated to reflect how to install/build subusurface
on Mac. It has also been updated with several generic parts.
3 parts are still outstanding (to come soon):
QtWebKit, need to document how to download/build
Mac, final touches
iOS, need to document the build process
Signed-off-by: Jan Iversen <jani@apache.org>
Resolves ERROR: no file at "/usr/lib/libgit2.dylib" when building on MacOS.
[Dirk Hohndel: SOB in PR #1201 - copying it into the commit for consistenty]
Signed-off-by: Allen Hall <revenant83@hotmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Remove a semicolon after Q_OBJECT and a few others after the closing
braces of while loops.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We had turned this off since it caused rendering issues, but that
appears to be fixed now - and it should help to get us smoother
rendering of the dive list.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And maybe this will make it faster as well? Depends on how the binding
is implemented, I guess.
But at least it's less confusing to read now.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way the menu items describe what happens when you tap on that menu
item. That seems more consistent and intuitive.
See #1204
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The proxy for this is a check to see if the Subsurface binary was
created (in which case we assume that the build succeeded).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should have been caught by our build check, but it turns out that
that one isn't correctly reflected in its Travis status.
Oops.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Xcode happily accepted the incorrect plist syntax for a boolean and the app
did the right thing when installed locally - but once you upload to the
iTunes store the error causes that to fail.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
