Merge upstream libdivecomputer from Jef:
- support the Scubapro Aladin A2
- improve Cressi Goa support
- parse and report Oceanic firmware versions
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Report the firmware version in the devinfo event
Refactor the version string matching to use one table
Parse the firmware version
Add support for Cressi Goa gauge and freedives
Add the extra 5 bytes containing the divemode
Add a function to insert data anywhere in the buffer
Add support for the Scubapro Aladin A2
This merges the FIT file parsing extensions to actually parse the
pressure data from the new Garmin Descent Mk2i.
There is more data there about cylinder sizing etc that we can parse,
but this is enough to make things useful. At least for the test cases I
have access to so far.
* Garmin-Mk2i:
Garmin Descent Mk2i: add support for parsing cylinder pressure data
Garmin: add skeleton for the new fields for the Descent Mk2/Mk2i
Very early trial at parsing the pressure data from the Garmin tank pods.
It seems to work for the test-cases I have.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds the field definitions, but doesn't actually report the data
yet. But just having the definitions makes the debug output a lot
easier to read through.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If the caller provides us with a path name, we should not try to connect to the
dive computer via MTP, but instead read the .FIT files from the path provided.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Create parallel helper functions that use libmtp to walk the file tree on the
device and to then read a specific file from the device into our dc_buffer.
MTP is not a file system, it's an object storage, that just happens to allow
object names and parent/child relationships between objects. As a result we
need to remember those file ids for MTP downloads.
The mtp_get_file_list function is rather complex as it includes both the
initial communication with the device and the code to walk the object tree and
then create the list of file.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Breaking things into helper function makes it much easier to then support both
regular file operations and MTP.
This includes some mild whitespace cleanups for consistency.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Just like for the Descent Mk1 this uses the internal Garmin model number (as
indicated in the FIT format) as model, not the USB product ID.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We do this for a few other device where we need slightly different behavior,
depending on the specific model.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With just a single table, the version string matching not only becomes
simpler, but adding new layouts also requires no code changes anymore.
For devices that need different layouts depending on the firmware
version (e.g. Oceanic Atom 2.0 and Aeris Manta), the table may contain
multiple entries with the different firmware versions. The only
requirement is that the entry with the highest firmware version must be
listed first.
The patterns used for the version string have the firmware version
masked out because it varies. We can re-use those masks to extract the
firmware version.
The gauge and freedives have a slightly different data format compared
to scuba dives. The main difference is the size of the header and two
new sample types.
The logbook header has 5 bytes extra, which are not present in the dive
header. Those 5 extra bytes contain the dive mode, which is required for
parsing the dive data. Therefore, insert all 5 bytes again and update
the parser.
The remaining 4 bytes appear to be some 32 bit address. They are not
used for anything right now, but are preserved as well in case they are
needed in the future.
The memory buffer already supported appending and prepending data, but
not inserting data anywhere in the buffer. That's exactly what the new
function does. The free space is still maintained at either the start or
the end of the buffer.
This actually got broken long ago (and before the new "Subsurface-DS9"
branch: when I converted the Garmin parser to use the generic field
cache, I missed the fact that the parser now cleared _only_ that generic
part of the per-dive cache in between different dives.
The GPS information, and the general dive information would be left
alone in between dives, and could leak from one dive to the next.
Most of the time you don't notice, because dives tend to all have the
same information, so the stale data would get overwritten when parsing
the next dive. But that isn't _always_ true - particularly for the GPS
information, not all the data necessarily always exists.
So clear all the per-dive data when starting to parse a new dive.
This puts the non-gps data all in one sub-structure, so that it's easy
to clear that too in one go - even though that part of the data probably
always does get opverwritten by the new dive data.
Reported-by: @brysconsulting
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge updates from Jef's upstream branch.
Fix Mares Genius salinity parsing, and a possible buffer overflow in the
Liquivision Lynx parser.
This also has Jef's copy of Dirk's Shearwater PNF parsing fix that we
already had in our tree.
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Fix a buffer overflow
fix Shearwater PNF parsing for Petrel / Petrel 2
Fix a bug in the salt and fresh water parsing
The existing check accepts the number of array elements as a valid
index. That's clearly wrong for zero based indexing, and would result in
a buffer overflow.
At some point (possibly around v71 of their firmware), Shearwater implemented
PNF for the Petrel and Petrel 2. Those are of course not air integrated, and
apparently don't support adjustable sample rate, so the log data doesn't include
opening and closing record 5. Instead of failing when those aren't found, we
should simply only access those when they actually exist.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Pull Shearwater PNF parsing fix from Dirk:
"The parser assumed that all opening/closing records were required.
But it seems that for the Petrel / Petrel 2 they actually aren't,
specifically record 5 is missing.
Which makes sense, as that one only contains air integration stuff
plus the sample interval (which isn't configurable on the older dive
computers)"
* 'shearwaterPNFfix' of github.com:Subsurface-divelog/libdc:
fix Shearwater PNF parsing for Petrel / Petrel 2
At some point (possibly around v71 of their firmware), Shearwater implemented
PNF for the Petrel and Petrel 2. Those are of course not air integrated, and
apparently don't support adjustable sample rate, so the log data doesn't include
opening and closing record 5. Instead of failing when those aren't found, we
should simply only access those when they actually exist.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The original Mares Genius support was based on Mares Dive Organizer
2.25, which has a bug in the salinity parsing. The latest version 2.26
has this bug fixed.
Reported-by: Greg McLaughlin <gregm@somemore.com>
Pull McLean Extreme fix from Jef Driesen.
The McLean Extreme sample interval was wrong, causing imported dives to
appear twice as long as long as they should.
* git://github.com/libdivecomputer/libdivecomputer:
Fix the sample interval
The McLean Extreme records a sample every 10 seconds instead of every 20
seconds. This resulted in dive durations that were twice as long as
expected.
Reported-by: David Carron <david_de_carron@hotmail.com>
This mostly reverts commit cb7f47b ("Shearwater Teric: add support for
the TAG INFO_EVENT") because upstream libdivecomputer now does this
natively as of commit 3e89e1b ("Add support for parsing info events").
Also, the way this had been done, it looks like it had basically
disabled the support for LOG_RECORD_FREEDIVE_SAMPLE, although nobody
seems to have ever complained, so presumably there aren't a lot of
freedivers using Shearwater dive computers and subsurface.
With this, our main differences with Jef are just the string interface
code, and the fact that we still stop parsing at LOG_RECORD_FINAL.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge Dirk's Peregrine support with Jef's.
Jef had some extra logic, and otherwise the same, so this is just a
history merge with no content difference.
* 'Subsurface-DS9' of github.com:Subsurface-divelog/libdc:
Add basic detection for Shearwater Peregrine
Merge upstrean libdivecomputer updates from Jef Driesen:
- a different way to work around the windows 'instance' craziness
- minor updates to the Shearwater parser
* git://github.com/libdivecomputer/libdivecomputer:
Add support for parsing info events
Add support for the Shearwater Peregrine
Fix a conflict with the Windows header files
Add a missing parameter for the USB HID filter
In one of the Windows system header files, an "interface" macro is
defined as:
#define interface struct
This results in some very strange build errors when also including the
descriptor-private.h header file. That's because the dc_usb_params_t
struct has a member field named "interface":
typedef struct dc_usb_params_t {
unsigned int interface;
unsigned char endpoint_in;
unsigned char endpoint_out;
} dc_usb_params_t;
As a workaround, define the WIN32_LEAN_AND_MEAN macro before including
the windows.h header file. This excludes some less common Windows API
declarations, including the above one.
In commit 57f0ce6d7902117cfc4d0d6b401b516fc93ca488, an extra parameter
was added to the dc_descriptor_filter() function. But I only updated the
libusb code path and forgot to do the same for the hidapi variant.
It turns out that Windows is more of a PoC than I ever imagined. The
system headers will have something like this in it:
#define __STRUCT__ struct
#define interface __STRUCT__
which means that using the identifier "interface" will result in
completely indecipherable error messages from a Windows compiler.
That's some truly broken stinking garbage. It's not like "interface" is
even a bad identifier.
Let's just #undef this crazy feature.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When Jef added a filter parameter in commit 57f0ce6 ("Add support for
filter parameters") he didn't do the HIDAPI case, because who uses
HIDAPI?
Windows and OS X, it would seem.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge upstream changes by Jef Driesen:
- add support for Liquivision dive computers
- add support for the Aqualung i470TC
- extract out Atomic Aquatics Cobalt USB support as a iostream
- misc fixes
* git://github.com/libdivecomputer/libdivecomputer:
Fix the OSTC4 firmware upgrade
Handle a negative number of bytes as an error
Update the example application
Use the new USB transport for the Atomic Aquatics Cobalt
Add an I/O implementation for USB communication
Add support for filter parameters
Disable direct access to the filter function
Increase the receive timeout to 5 seconds
Fix the McLean Extreme bluetooth name
Add support for Liquivision dive computers
Add support for the Aqualung i470TC
Commit d1b865d192afc9efde337b5cff8a239366f15565 breaks the OSTC4
firmware upgrade because the OSTC4 expects to receive the service init
command and the service key all at once, before sending any response.
The hwOS firmware still reads the service init command one byte at a
time, and sends the echo immediately after each byte. But in the
meantime, the hwos firmware has also been optimized. The processing time
for an incoming byte is now always faster then the time it takes for the
next byte to physically arrive via the serial line between the USB/BT
chip and the processor. Thus, even without any buffering, sending all
bytes at once should no longer be a problem.
This partially reverts commit d1b865d192afc9efde337b5cff8a239366f15565.
Reported-by: Anton Lundin <glance@acc.umu.se>
Suggested-by: Ralph Lembcke <mail@ralph-lembcke.de>
There is no reason for libusb to ever return a negative number of bytes,
but due to the use of a signed integer, it's technically possible. And
because libdivecomputer returns an unsigned integer, such a negative
number would be reported as a very large size.
Replace the hardcoded libusb based code with the new USB I/O transport.
This enables the use of a custom I/O on platforms where libusb is not
available.
The USB communication is now also implemented as an I/O stream
transport. Unlike most I/O devices, USB communication supports multiple
interfaces and endpoints. This requires some some special care:
In the general case, autodetection isn't really possible without
additional knowledge. Hence the need for the filter parameters to pass
this kind of information.
The implementation assumes two bulk endpoints for the standard
read/write interface. Communication with the control endpoint is
supported through the new DC_IOCTL_USB_CONTROL_{READ,WRITE} ioctl's.
