<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On 20 Apr. 2017 5:49 am, "Linus Torvalds" <<a href="mailto:torvalds@linux-foundation.org">torvalds@linux-foundation.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Wed, Apr 19, 2017 at 12:33 PM, Dirk Hohndel <<a href="mailto:dirk@hohndel.org">dirk@hohndel.org</a>> wrote:<br>
><br>
>> It's really just three commits:<br>
>><br>
>>       custom serial: pass device_data_t to bluetooth operation function<br>
>>       Expand 'bluetooth_mode' from a boolean to an emun<br>
>>       Prepare to split the custom serial operations up by RFCOMM-vs-BLE<br>
>><br>
>> and each of them actually tries to be a total no-op at this time. But<br>
>> the intent is to make it possible for core/qtserialbluetooth.cpp to<br>
>> simply have a different set of operations for BLE devices where RFCOMM<br>
>> doesn't work.<br>
><br>
> I looked at the code and it makes sense to me. I assume the debug fprintf<br>
> in the last one is there intentionally... :-)<br>
<br>
</div>Well, you picked up on the *one* change that is actually supposed to<br>
do something.<br>
<br>
Yeah, it's "intentional" in the sense that without that line, I<br>
couldn't see if my code actually did anything or not.<br>
<br>
It's obviously not meant to be real in the end. Once we have code that<br>
actually handles the BLE case, that printf no longer makes sense at<br>
all. Right now it's there to show that "yes, we actually noticed that<br>
the device was a BLE device" .<br>
<div class="quoted-text"><br>
>> In particular, somebody should probably test that it still works with<br>
>> the RFCOMM model. I'm particularly worried about devices that can do<br>
>> *both* traditional bluetooth *and* BLE. Because right now it just says<br>
>> that if the device can do BLE, we'll pick the BLE model. Of course,<br>
>> right now that BLE model ends up falling back to the same old RFCOMM<br>
>> code (which would fail on a BLE-only device), so it should still work<br>
>> with a "RFCOMM *and* BLE" device, but whatever..<br>
>><br>
>> Comments?<br>
><br>
> I need to check back with Shearwater - I think they have some devices that<br>
> do both, rfcomm and BTLE<br>
<br>
</div>Yeah, so that's definitely the most interesting case.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I suspect BLE is generally the "preferred" model (newer, lower power),<br>
but obviously only when we have a working BLE downloader. Which was<br>
why I did that "assume BLE if it's supported".<br>
<br>
If there is somebody who has a RFCOMM mode, _and_ supports BLE, and<br>
then the BLE protocol is something entirely different, we'd really<br>
need the low-level libdivecomputer code to explicitly pick one over<br>
the other.<br>
<br>
It might be something as hacky as the libdivecomputer code doing<br>
<br>
    /* We don't handle BLE yet, force RFCOMM fallback */<br>
    if (device->bluetooth_mode == BT_LE) device->bluetooth_mode = BT_RFCOMM;<br>
<br>
before doing the dc_serial_open() call.<br>
<br>
But hopefully we'd never need anything like that, just because any<br>
dive computer that supports both would use the same protocol and we'd<br>
just prefer BLE.<br>
<font color="#888888"><br>
                     Linus<br>
</font><div class="elided-text">______________________________<wbr>_________________<br>
subsurface mailing list<br>
<a href="mailto:subsurface@subsurface-divelog.org">subsurface@subsurface-divelog.<wbr>org</a><br>
<a href="http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface" rel="noreferrer" target="_blank">http://lists.subsurface-<wbr>divelog.org/cgi-bin/mailman/<wbr>listinfo/subsurface</a><br>
</div></blockquote></div><br></div></div></div>