Cleaned up and rebased "libdivecomputer-NG" branch

[Dirk Hohndel]

> On Apr 27, 2018, at 11:46 AM, Linus Torvalds <torvalds at linux-foundation.org> wrote:
>> I then finally got Android to connect at all.
> 
> Ok, so the firmware update at least made some change. That's a good sign,
> in that it does imply that at least _some_ of the problems were due to a
> bug that the Shearwater people knew about and fixed.

Yes - but there’s still something seriously broken when talking to Android
devices - both using Subsurface and Sheawater’s own app.
>> Deleting BLE object
>> "4.929: No new dives downloaded from dive computer"
> 
> Hmm. I'm not seeing any errors here either, but I'm surprised to not see
> any actual *communication* debugging.
> 
> I wonder if that got turned off in your version of Qt? Because all the
> messages above are our _own_ qdebug output.
> 
> The actual *data* transfer debugging is from qt itself, and we turn it on
> and off with
> 
>     QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
> true"));
>     QLoggingCategory::setFilterRules(QStringLiteral("qt.bluetooth* =
> false"));
> 
> and I wonder if maybe Qt itself stopped doing those debug messages?
> 
> For example, on my desktop, I see not just the "Found service" messages
> that we output, I also see a lot of other debug data from Qt itself:
> 
>   ..
>   Sending read_by_group_type request, startHandle: b endHandle: ffff 2800
>   Received size: 22 data: "11140b00ffff9d02e73320e0aab03c44ce0e37c225fe"
>   Found uuid: "{fe25c237-0ece-443c-b0aa-e02033e7029d}" start handle: b end
> handle: ffff
>   Found service "{fe25c237-0ece-443c-b0aa-e02033e7029d}"
>   ..
> 
> and your log doesn't have any of that. So then the fact that you *also*
> don't have the actual IO debugging actually makes sense.

I switched to a newer Qt version - it would be strange for them to disable
something as critical as this, but definitely worth investigating further.

>> Finishing the thread Dive data import error dives downloaded 0
>> no new dives downloaded
>> "4.932: DCDownloadThread finished”
> 
> Because this would all be successful for the "no dives on the dive
> computer" case other than the complete lack of debug messages..
> 
>> So we are successfully connecting, are discovering the services and then
> we give
>> up right away. Not sure if this adds any more useful information, but I
> thought I’d
>> pass it along.
> 
> I think "we give up right away" may actually be "we exchanged just a couple
> of packets and found that there were no dives".
> 
> Did the firmware update perhaps reset the dive computer entirely and remove
> all dives on the dive computer?

Nope. I just completed an iOS build with the latest code and that connected
without a problem and downloaded the 20 dives on this dive computer via
BLE. This is with the current master.

/D