summaryrefslogtreecommitdiffstats
path: root/core/configuredivecomputer.cpp
AgeCommit message (Collapse)Author
2017-09-28Save Subsurface version to libdivecomputer logfileGravatar Miika Turkia
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
2017-06-27Switch over to SSRF_CUSTOM_IO v2Gravatar Linus Torvalds
I hate changing the IO interfaces this often, but when I converted the custom serial interface to the more generic custom IO interface, I intentionally left the legacy serial operations alone, because I didn't want to change something I didn't care about. But it turns out that leaving them with the old calling convention caused extra problems when converting the bluetooth serial code to have the BLE GATT packet fall-back, which requires mixing two kinds of operations. Also, the packet_open() routine was passed a copy of the 'dc_context_t', which makes it possible to update the 'dc_custom_io_t' field on the fly at open time. That makes a lot of chaining operations much simpler, since now you can chain the 'custom_io_t' at open time and then libdivecomputer will automatically call the new routines instead of the old ones. That dc_context_t availability gets rid of all the if (device && device->ops) return device->ops->serial_xyz(..); hackery inside the rfcomm routines - now we can just at open time do a simple dc_context_set_custom_io(context, &ble_serial_ops); to switch things over to the BLE version of the serial code instead. Finally, SSRF_CUSTOM_IO v2 added an opaque "dc_user_device_t" pointer argument to the custom_io descriptor, which gets filled in as the custom_io is registered with the download context. Note that unlike most opaque pointers, this one is opaque to *libdivecomputer*, and the type is supposed to be supplied by the user. We define the "dc_user_device_t" as our old "struct device_data_t", making it "struct user_device_t" instead. That means that the IO routines now get passed the device info showing what device they are supposed to download for. That, in turn, means that now our BLE GATT open code can take the device type it opens for into account if it wants to. And it will want to, since the rules for Shearwater are different from the rules for Suunto, for example. NOTE! Because of the interface change with libdivecomputer, this will need a flag-day again where libdivecomputer and subsurface are updated together. It may not be the last time, either. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-06-22Convert to new libdivecomputer custom IO modelGravatar Linus Torvalds
Instead of being "custom serial", it's a IO model that allows serial or packet modes, independently of each other (ie you can have a bluetooth device that does serial over BT rfcomm and packet-based communication over BLE GATT with the same serial operations that describe both cases). Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-04-29Add SPDX header to remaining core filesGravatar Dirk Hohndel
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-04-13Cleanup some unnecessary include statementsGravatar Jef Driesen
Some of these header files are no longer necessary, and will be removed from libdivecomputer in the near future. Signed-off-by: Jef Driesen <jef@libdivecomputer.org> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2017-03-11We use 'setpoint' in UI. Use it also for documentation and comments. No ↵Gravatar Martin Měřinský
semantic change.
2016-09-17Rewrite libdivecomputer custom serial codeGravatar Anton Lundin
This rewrites the custom serial code to use the new api which I implemented in the Subsurface-branch of libdivecomputer. This is a bit to big patch but I haven't had the time to break it down into more sensible patches. This rewrite enables us to support more ftdi based divecomputer communication and is tested with both a OSTC3, OSTC2N and a Suunto Vyper, all over the libftdi driver. The bluetooth code paths are tested to, and should work as before. Signed-off-by: Anton Lundin <glance@acc.umu.se> Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2016-04-04Move subsurface-core to core and qt-mobile to mobile-widgetsGravatar Dirk Hohndel
Having subsurface-core as a directory name really messes with autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an autocomplete conflict and also was inconsistent with the desktop-widget name for the directory containing the "other" UI. And while cleaning up the resulting change in the path name for include files, I decided to clean up those even more to make them consistent overall. This could have been handled in more commits, but since this requires a make clean before the build, it seemed more sensible to do it all in one. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>