More Bluetooth LE work

[Linus Torvalds]

So attached are three patches that currently allow me to download
dives from my Shearwater Perdix AI, and that I assume works with the
regular Perdix too (which has some newer versions that are BLE-only
and no longer support rfcomm).

HOWEVER. BIG CAVEAT!

Right now that third patch is a disgusting hack that can not be
committed, because it will break *other* LE dive computers (ie Suunto
EON Steel and Scubapro G2). The issue is that the Shearwaters use a
slightly different model for connecting and their BLE packet sending,
and rather than do the sane thing and discover that dynamically, that
third patch just hardcodes the Shearwater way.

The two first patches are good to go, though, and you should consider
the third patch a "hey, I want to test my Shearwater download" special
patch that you do not actually commit, you just apply to your build
tree for testing.

CAVEAT NUMBER TWO!

The Perdix AI has some new fields for actual air integration, and
those new fields will presumably need libdivecomputer support, and I
haven't got any test data for it. So while I have a Perdix AI download
working fine, I'm not saying it's all perfect.

Anyway, with those caveats out of the way, some explanations:

 - the same bluetooth device may support both legacy bluetooth
(rfcomm) _and_ the BLE GATT model. That's true of the older Shearwater
Perdix, for example, and our current custom_io model actually
describes both modes at the same time, so that the libdivecomputer
backend can just pick whichever it wants.

 - in particular, I don't want to change the behavior of the old
rfcomm code - I don't have anything that uses it, and it supposedly
works fine for others, and it's a more standardized protocol than the
BLE GATT hackery of more modern dive computers, so it should remain
the default mode for those dive computers that support it.

 - HOWEVER, when we scan for the dive computers, we can see that some
dive computer _only_ supports BLE. When that happens, the first patch
in this series will now explicitly mark the bluetooth address with a
"LE:" prefix at scan time, which will allow the rfcomm code to realize
that it cannot use rfcomm for the device.

 - the first patch then also makes the actual BLE packet code ignrioe
the possible "LE:" prefix (but not having that prefix is ok too for
the packet code, for the dual BT support case).  The rfcomm case will
obviously fail with the "LE:" prefix, but it would have failed anyway
since rfcomm doesn't work over LE.

 - the second patch then hooks into the rfcomm code, and instead of
just failing, it says "dammit, if I see that LE prefix, I know that I
can't use rfcomm, but I'll instead do my own serial emulation over the
packets I can send".

 - this is what makes the Perdix AI "just work" without any extra
effort (well, as long as we have the hack in place to do the packet
accesses properly for the shearwater case) - the libdivecomputer
backend will just use the same old serial code, never even realizing
that now it goes over BLE.

 - this *also* allows people who currently happily use rfcomm to play
with the LE back-end. So if you have an older Perdix, and it currently
works with rfcomm, what you can do is to just hand-edit the bluetooth
address to have that "LE:" prefix, and that will force the new BLE
GATT path. It might be faster and lower energy. And it might not. It
might not work for you at all. It's a crapshoot.

 - that third patch really is crap. Don't look at it. Don't commit it.
I'm sorry. But you currently need it to make the BLE GATT code work
with shearwater dive computers.

Anything I forgot?

People who have non-Shearwater dive computers that use rfcomm but
might use BLE, you might *try* to apply the two first patches, and it
might just work for you (and use the "LE:" trick to force LE mode).
Maybe. Don't apply the third one, I suspect Shearwater is alone in how
they do that odd "one single characteristic, two descriptors" thing
(Suunto and Scubapro use two separate characteristics - one for
reading ("notify") and one for writing).

But tit's really worth noting once again the fact that BLE GATT really
isn't standardized wrt exactly how to send packets and what they mean,
meaning that there is really no reason to expect that things will
"JustWork". I suspect each BLE dive computer will need some packet
sniffing and some hackery. So far every single one I've worked on has
been very different (in some ways: the ScubaPro G2 and Suunto EON
Steel are similar in how the packets are being sent and received, but
have different encodings). The Perdix AI has a very plain encoding,
but instead uses a different approach to send and receive the packets.

                Linus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Bluetooth-make-LE-only-devices-add-LE-as-an-address-.patch
Type: text/x-patch
Size: 2881 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170626/ac359398/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-BT-serial-recognize-LE-only-devices-and-fall-back-to.patch
Type: text/x-patch
Size: 8421 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170626/ac359398/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Local-hack-don-t-use.patch
Type: text/x-patch
Size: 2828 bytes
Desc: not available
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170626/ac359398/attachment-0002.bin>