Mares Smart Dive Computer + Bluelink pro

Linus Torvalds torvalds at linux-foundation.org
Wed Sep 26 11:43:10 PDT 2018


On Wed, Sep 26, 2018 at 10:40 AM Linus Torvalds
<torvalds at linux-foundation.org> wrote:
>
> I suspect I need to put the "repeat read" condition inside
> libdivecomputer itself. Because right now the "user passed in a NULL
> actual pointer" case is insane: dc_iostream_read() will happily return
> a partial buffer with no way to see how much of it was filled.

I have now done that.

Dirk - I have updated the libdivecomputer branch with the current tip being

   e97886a994c1 ("Fix dc_iostream_{read,write} debugging implementation")

which handles the case of a dc_iostream_read/write() user that is not
able or willing to handle partial IO results.

That, together with the subsurface pull request that I just did on
github, should finally fix this issue.

I have actually "tested" this by not only verifying that yes, the EON
Core still works, I also made a fake (and broken) EON Core backend
change that tried to read both partial packets and multi-packet full
buffers. The iostream layer now does the right thing, and the qt-ble
case only needs to handle the partial packet case.

Two notes:

 - the subsurface pull request also implements the 'hh:mm:ss' parsing.
I've tested that too with a manually edited XML file, it seems fine.

 - the subsurface pull request does *not* update the libdivecomputer
submodule, but for the Mares BlueLink to work, you need *both* the new
libdivecomputer _and_ the subsurface change.

UPS tracking shows that my BlueLink dongle was loaded on the delivery
vehicle this morning, so hopefully I'll be able to finally test this
later today. But all actual credit obviously does to Fabio for his
patience in testing various broken versions and sending back debug
information showing which parts needed fixing.

                            Linus


More information about the subsurface mailing list