mirror of
https://github.com/subsurface/subsurface.git
synced 2025-02-17 21:36:16 +00:00
This is the official upstream of the Subsurface divelog program
We have two different models for setting the deviceid associated with a dive computer: either take the value from the libdivecomputer 'devinfo' field (from the DC_EVENT_DEVINFO event), or generate the device ID by just hashing the serial number string. The one thing we do *not* want to have, is to use both methods, so that the same device generates different device IDs. Because then we'll think we have two different dive computers even though they are one and the same. Usually, this is not an issue, because libdivecomputer either sends the DEVINFO event or gives us the serial number string, and we'll always just pick one or the other. However, in the case of at least the Suunto EON Steel, I intentionally did *not* send the DC_EVENT_DEVINFO event, because it gives no useful information. We used the serial number string to generate a device ID, and everything was fine. However, in commit d40cdb4755ee ("Add the devinfo event") in the libdivecomputer tree, Jeff started generating those DC_EVENT_DEVINFO events for the EON Steel too, and suddenly subsurface would start using a device ID based on that instead. The situation is inherently ambiguous - for the EON Steel, we want to use the hash of the serial number (because that is what we've historically done), but other dive computers might want to use the DEVINFO data (because that is what _those_ backends have historically done, even if they might also implement the new serial string model). This commit makes subsurface resolve this ambiguity by simply preferring whatever previous device ID it has associated with that particular serial number string. If you have no previous device IDs, it doesn't matter which one you pick. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org> |
||
---|---|---|
.tx | ||
android | ||
android-mobile | ||
appdata | ||
cmake/Modules | ||
core | ||
desktop-widgets | ||
dives | ||
Documentation | ||
icons | ||
marbledata | ||
mobile-widgets | ||
packaging | ||
printing_templates | ||
profile-widget | ||
qt-models | ||
ReleaseNotes | ||
scripts | ||
smtk-import | ||
tests | ||
theme | ||
translations | ||
xslt | ||
.clang-format | ||
.gitattributes | ||
.gitignore | ||
CMakeLists.txt | ||
CodingStyle | ||
descriptor3.tsv | ||
export-html.cpp | ||
gpl-2.0.txt | ||
INSTALL | ||
README | ||
Readme.testing | ||
Readme.ubuntu | ||
subsurface-desktop-helper.cpp | ||
subsurface-desktop-main.cpp | ||
subsurface-mobile-helper.cpp | ||
subsurface-mobile-main.cpp | ||
subsurface.debug | ||
subsurface.desktop | ||
subsurface.qrc | ||
subsurface_enabled_translations | ||
SupportedDivecomputers.html | ||
SupportedDivecomputers.txt | ||
terms | ||
TODO.CCR | ||
wreck.jpg |
This is the README file for the development version of Subsurface towards version 4.6 Please check the ReleaseNotes.txt for details about new features and changes since Subsurface 4.5 (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 http://trac.subsurface-divelog.org License: GPLv2 You can get the sources to the latest development version from the git repository: git clone git://git.subsurface-divelog.org/subsurface.git . You can also browse the sources via gitweb at the same site. 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.5.1 (or whatever the last release is) or download a tar ball from: http://subsurface-divelog.org/downloads/Subsurface-4.5.1.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 either send signed-off patches or a pull request with signed-off commits. If you don't sign off on them, 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.