Linus Torvalds adb4b66a05 Try to sanely download multiple concurrent cylinder pressures
This tries to sanely handle the case of a dive computer reporting
multiple cylinder pressures concurrently.

NOTE! There are various "interesting" situations that this whole issue
brings up:

 - some dive computers may report more cylinder pressures than we have
   slots for.

   Currently we will drop such pressures on the floor if they come for
   the same sample, but if they end up being spread across multiple
   samples we will end up re-using the slots with different sensor
   indexes.

   That kind of slot re-use may or may not end up confusing other
   subsurface logic - for example, make things believe there was a
   cylidner change event.

 - some dive computers might send only one sample at a time, but switch
   *which* sample they send on a gas switch event.  If they also report
   the correct sensor number, we'll now start reporting that pressure in
   the second slot.

   This should all be fine, and is the RightThing(tm) to do, but is
   different from what we used to do when we only ever used a single
   slot.

 - When people actually use multiple sensors, our old save format will
   start to need fixing.  Right now our save format comes from the CCR
   model where the second sensor was always the Oxygen sensor.

   We save that pressure fine (except we save it as "o2pressure" - just
   an odd historical naming artifact), but we do *not* save the actual
   sensor index, because in our traditional format that was always
   implicit in the data ("it's the oxygen cylinder").

so while this code hopefully makes our libdivecomputer download do the
right thing, there *will* be further fallout from having multiple
cylinder pressure sensors.  We're not done yet.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-07-25 06:11:10 -07:00
2013-12-29 10:34:12 -08:00
2017-03-04 12:08:17 -08:00
2017-04-22 12:49:30 -07:00
2017-03-11 08:09:07 -08:00
2017-07-11 21:21:11 -07:00
2017-04-20 15:58:30 -07:00
2016-09-22 18:15:26 -07:00
2016-09-21 15:28:05 -07:00
2017-04-26 18:46:25 +02:00
2015-01-15 19:48:11 -08:00
2017-03-13 10:28:06 -07:00
2014-11-18 13:15:43 +00:00

This is the README file for Subsurface 4.6.4

Please check the ReleaseNotes.txt for details about new features and
changes since Subsurface 4.6.3 (and earlier versions).

Subsurface can be found at http://subsurface-divelog.org

Our user forum is at http://subsurface-divelog.org/user-forum/
We also try to respond to questions in the ScubaBoard.com dive software
forum at http://www.scubaboard.com/forums/dive-software/

Report bugs and issues at
https://github.com/Subsurface-divelog/subsurface/issues

License: GPLv2

You can get the sources to the latest development version from the git
repository:

git clone https://github.com/Subsurface-divelog/subsurface.git

You can also fork the repository and browse the sources at the same site,
simply using https://github.com/Subsurface-divelog/subsurface

If you want the latest release (instead of the bleeding edge
development version) you can either get this via git or the release tar
ball. After cloning run the following command:

git checkout v4.6.4  (or whatever the last release is)

or download a tar ball from:

http://subsurface-divelog.org/downloads/Subsurface-4.6.4.tgz

Detailed build instructions can be found in the INSTALL file.

Basic Usage:
============

Install and start from the desktop, or you can run it locally from the
build directory:

On Linux:

$ ./subsurface

On Mac:

$ open Subsurface.app

Native builds on Windows are not really supported (the official Windows
installers are both cross-built on Linux).

You can give a data file as command line argument, or (once you have
set this up in the Preferences) Subsurface picks a default file for
you when started from the desktop or without an argument.

If you have a dive computer supported by libdivecomputer, you can just
select "Import from Divecomputer" from the "Import" menu, select which
dive computer you have (and where it is connected if you need to), and
hit "OK".

The latest list of supported dive computers can be found in the file
SupportedDivecomputers.txt.

Much more detailed end user instructions can be found from inside
Subsurface by selecting Help (typically F1). When building from source
this is also available as Documentation/user-manual.html. The
documentation for the latest release is also available on-line
http://subsurface-divelog.org/documentation/


Contributing:
=============

There is a mailing list for developers: subsurface@subsurface-divelog.org
Go to http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
to subscribe.

If you want to contribute code, please open a pull request with signed-off
commits at https://github.com/Subsurface-divelog/subsurface/pulls
(alternatively, you can also send your patches as emails to the developer
mailing lsit).

Either way, if you don't sign off your patches, we will not accept them.
This means adding a line that says "Signed-off-by: Name <email>" at the
end of each commit, indicating that you wrote the code and have the right
to pass it on as an open source patch.

See: http://developercertificate.org/

Also, please write good git commit messages.  A good commit message
looks like this:

	Header line: explain the commit in one line (use the imperative)

	Body of commit message is a few lines of text, explaining things
	in more detail, possibly giving some background about the issue
	being fixed, etc etc.

	The body of the commit message can be several paragraphs, and
	please do proper word-wrap and keep columns shorter than about
	74 characters or so. That way "git log" will show things
	nicely even when it's indented.

	Make sure you explain your solution and why you're doing what you're
	doing, as opposed to describing what you're doing. Reviewers and your
	future self can read the patch, but might not understand why a
	particular solution was implemented.

	Reported-by: whoever-reported-it
	Signed-off-by: Your Name <youremail@yourhost.com>

where that header line really should be meaningful, and really should be
just one line.  That header line is what is shown by tools like gitk and
shortlog, and should summarize the change in one readable line of text,
independently of the longer explanation. Please use verbs in the
imperative in the commit message, as in "Fix bug that...", "Add
file/feature ...", or "Make Subsurface..."


A bit of Subsurface history:
============================

In fall of 2011, when a forced lull in kernel development gave him an
opportunity to start on a new endeavor, Linus Torvalds decided to tackle
his frustration with the lack of decent divelog software on Linux.

Subsurface is the result of the work of him and a team of developers since
then. It now supports Linux, Windows and MacOS and allows data import from
a large number of dive computers and several existing divelog programs. It
provides advanced visualization of the key information provided by a
modern dive computer and allows the user to track a wide variety of data
about their diving.

In fall of 2012 Dirk Hohndel took over as maintainer of Subsurface.
Description
No description provided
Readme 166 MiB
Languages
C++ 74.4%
XSLT 6%
C 5.9%
QML 5.6%
Shell 2.8%
Other 5.1%