subsurface.git/libdivecomputer, branch v4.9.4

iostream: fix incorrect rfcomm error case when writing

2020-03-14T18:34:46Z

This is the exact same case as the previous commit, just for the writing side. Once again, it's the subsurface rfcomm iostream code that can return DC_STATUS_SUCCESS with a byte count of zero when something goes wrong with the write. And once again, our libdivecomputer iostream code didn't try to be robust and protect itself from that case. The fix is equivalent, although slightly simpler, since the write side doesn't have the whole timeout issue. Signed-off-by: Linus Torvalds

iostream: fix incorrect rfcomm error case when reading

2020-03-14T18:34:46Z

We had two independent bugs here, both of which needed to fire for this to cause a problem. This fixes both of them. The first bug was that our rfcomm code would return DC_STATUS_SUCCESS with a zero-sized read when a timeout happened, or when the rfcomm socket had disconnected. That makes absolutely no sense. We should return DC_STATUS_TIMEOUT on timeout, and DC_STATUS_IO if the socket has disconnected without any data. The fix to this is to make the whole rfcomm iostream read logic much simpler: there's no need to loop at all for partial results, because the libdivecomputer iostream side will do the loop for us (and handle partial results much better: it knows if the target backend can handle those partial results or not). The second bug was in our libdivecomputer iostream read() function, which reacted very badly to this bad return value. This updates our libdivecomputer branch to one that is more careful about things. Reported-by: linuxcrash Debugged-by: Jef Driesen Signed-off-by: Linus Torvalds

Update libdivecomputer

2020-02-28T17:48:13Z

Pull upstream libdivecomputer updates from Jef Driesen: - fix lack of "end of deco" on DiveSystem iDive computers by reporting long NDL values - clean up handling of Oceanic empty logbugger - fix BLE download for Oceanic Pro Plus X that doesn't like the serial number handshake. Signed-off-by: Dirk Hohndel

Add Cressi BLE name filtering for bluetooth discovery

2020-02-16T20:52:56Z

.. and update the libdivecomputer submodule to have them marked as BLE capable. Signed-off-by: Linus Torvalds

Update libdivecomputer

2020-02-14T01:15:32Z

- fix Oceanic VT Pro date parsing - add Sherwood Wisdom 4 and Scubapro Aladin A1 IDs from Janice McLaughlin - fix Cressi gasmix index and depth parsing (the gasmix index bit had been misparsed as very deep depth) - Implement the gas mix sample - Limit the depth value to 11 bits - Add support for the Scubapro A1 - Add support for the Sherwood Wisdom 4 - Fix the vtpro datetime parsing Signed-off-by: Dirk Hohndel

Update to new libdivecomputer version

2020-01-27T17:51:31Z

Jef has changed the libdivecomputer iostream layer and extended it in two different ways: - iostram's now have a 'poll()' method, which does what the name implies: waits for data to be available with a timeout. - iostreams now have a 'ioctl()' method, which can be used to implement miscellaneous operations. Right now the two ones that you can do are "set latency" (this replaces the old 'set_latency()' method) and "get BLE name" (this replaces our 'get_name()' method that was never part of the upstream libdivecomputer interfaces) Neither of these is all that complicated, and the transition is fairly obvious. HOWEVER. I have absolutely no idea how to do 'poll()' on Windows sockets, and I have no intention of figuring it out. We use a direct socket interface to implement the (non-BLE) RFCOMM bluetooth serial protocol, and I'm not sure why Windows is so special here. I suspect - but cannot test - that we should just switch the Windows RFCOMM implementation over to the use the same QtBluetooth code that we use on other platforms. I assume that the Windows Bluetooth support was originally not sufficiently good for that, but these days we depend on Qt doing BLE for us even on Windows, so presumably FRCOMM works too. That would be a nice cleanup, and would make 'poll()' work on RFCOMM under Windows too. However, since I can't test it, I've not done that, but instead just made the Windows RFCOMM 'poll()' method always return success. That may or may not get the thing limping along. Signed-off-by: Linus Torvalds

Update libdivecomputer

2019-12-31T16:12:29Z

- Several fixes for Mares divecomputer BLE communication - Fix the Aeris Manta memory layout - Add support for the Oceanic Pro Plus 4 - Strip the source directory from file names Signed-off-by: Dirk Hohndel

Update libdivecomputer

2019-12-21T22:18:13Z

Add initial support for the Oceanic Pro Plus 4 Fix the Oceanic Geo 4.0 memory layout Ignore all empty logbook entries Add a workaround for the hwOS ppO2 firmware bug Use macros to encode the firmware version Use symbolic constants for the sample types Remove the obsolete hwos parameter Limit the tank pressure workaround to hwOS devices Fix the OSTC tank pressure decoding Fix the Scubapro G2 HUD udev rule Add the Mares Genius to the bluetooth filter Add firmware upgrade support for the Ratio computers Signed-off-by: Dirk Hohndel

Update libdivecomputer

2019-10-24T10:33:07Z

- Add support for the Oceanic Geo 4.0 - clean up Shearwater tank pressure handling - minor fixlets Signed-off-by: Dirk Hohndel

Update libdivecomputer to latest version

2019-09-07T19:33:45Z

This just merges with Jef's branch, which should hopefully fix the Mares BLUELINK Pro connection issues. Knock wood - I can no longer test it due to lack of hardware. It also improves on the Ratio iDive cylinder pressure transmitter support. Signed-off-by: Linus Torvalds