Very timid beginning framework for BLE communication

[Dirk Hohndel]

On Wed, Apr 19, 2017 at 12:17:41PM -0700, Linus Torvalds wrote:
> Dirk, Anton, (and possibly others who currently use RFCOMM),
> 
> would you mind taking a look at my "ble-prep" branch in
> 
>       https://github.com/torvalds/subsurface-for-dirk.git ble-prep
> 
> that I have *not* made into a pull request yet, because I don't
> actually have anything to test with.

I'll get you two devices tomorrow, one that does BTLE (Perdix AI) and one
that does rfcomm (Petrel).

> It's really just three commits:
> 
>       custom serial: pass device_data_t to bluetooth operation function
>       Expand 'bluetooth_mode' from a boolean to an emun
>       Prepare to split the custom serial operations up by RFCOMM-vs-BLE
> 
> and each of them actually tries to be a total no-op at this time. But
> the intent is to make it possible for core/qtserialbluetooth.cpp to
> simply have a different set of operations for BLE devices where RFCOMM
> doesn't work.

I looked at the code and it makes sense to me. I assume the debug fprintf
in the last one is there intentionally... :-)

> My plan (which may or may not work) would actually be to turn the
> Suunto EON Steel into a user of the serial emulation code too, for the
> BLE case there - even though the native model for the EON Steel isn't
> really "serial" at all, but a packet format with command/reply on top
> of USB HID (and now on top of BLE GATT with the new firmware). But I
> think it should probably be possible to use the same serial
> abstraction to then write the BLE packets instead.

At least with the Perdix AI that should in theory be all that it takes.

> But that series of three commits doesn't do any of that. It just tries
> to do no-op prep on code that I don't actually know at all, which is
> why I'd like somebody else to take a look at it.
> 
> In particular, somebody should probably test that it still works with
> the RFCOMM model. I'm particularly worried about devices that can do
> *both* traditional bluetooth *and* BLE. Because right now it just says
> that if the device can do BLE, we'll pick the BLE model. Of course,
> right now that BLE model ends up falling back to the same old RFCOMM
> code (which would fail on a BLE-only device), so it should still work
> with a "RFCOMM *and* BLE" device, but whatever..
> 
> Comments?

I need to check back with Shearwater - I think they have some devices that
do both, rfcomm and BTLE

> And yes, if somebody who actually knows that code (I'm looking at you,
> Anton) actually knows the Qt bluetooth interfaces and would fill in
> the open/close/read/write cases for the GLE GATT case, that would be
> great. Because right now I have a device that can do BLE, but going
> from "USB HID" to "BLE GATT" is a fairly big step. For example, it's a
> packetized protocol, and the packet size has changed.
> 
> In contrast, somebody who has a Perdix and already knows it, may have
> a much simpler time with the protocol that is already just a serial
> stream and isn't really packetized (and the BLE GATT thing is just a
> transport for that).

See above. I'll get you the hardware tomorrow (I'll fly home tonight).
But that shouldn't stop Anton from commenting / working on the code :-)

/D