Very timid beginning framework for BLE communication

[Rick Walsh]

On 20 Apr. 2017 5:49 am, "Linus Torvalds" <torvalds at linux-foundation.org>
wrote:

On Wed, Apr 19, 2017 at 12:33 PM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
>> 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... :-)

Well, you picked up on the *one* change that is actually supposed to
do something.

Yeah, it's "intentional" in the sense that without that line, I
couldn't see if my code actually did anything or not.

It's obviously not meant to be real in the end. Once we have code that
actually handles the BLE case, that printf no longer makes sense at
all. Right now it's there to show that "yes, we actually noticed that
the device was a BLE device" .

>> 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

Yeah, so that's definitely the most interesting case.


The Petral 2 does both, and I think the "original" Perdix too. I might have
a chance to test with my Petral 2 this weekend but not before.


I suspect BLE is generally the "preferred" model (newer, lower power),
but obviously only when we have a working BLE downloader. Which was
why I did that "assume BLE if it's supported".

If there is somebody who has a RFCOMM mode, _and_ supports BLE, and
then the BLE protocol is something entirely different, we'd really
need the low-level libdivecomputer code to explicitly pick one over
the other.

It might be something as hacky as the libdivecomputer code doing

    /* We don't handle BLE yet, force RFCOMM fallback */
    if (device->bluetooth_mode == BT_LE) device->bluetooth_mode = BT_RFCOMM;

before doing the dc_serial_open() call.

But hopefully we'd never need anything like that, just because any
dive computer that supports both would use the same protocol and we'd
just prefer BLE.

                     Linus
_______________________________________________
subsurface mailing list
subsurface at subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170420/11385ecf/attachment-0001.html>