<div dir="ltr">Hi Linus (et al)<br><div><div class="gmail_extra"><br><div class="gmail_quote">On 20 April 2017 at 06:49, Rick Walsh <span dir="ltr"><<a href="mailto:rickmwalsh@gmail.com" target="_blank">rickmwalsh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div class="gmail-h5"><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" target="_blank">torvalds@linux-foundation.org</a><wbr>> wrote:<br type="attribution"><blockquote class="gmail-m_-6265252539289790786quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-6265252539289790786quoted-text">On Wed, Apr 19, 2017 at 12:33 PM, Dirk Hohndel <<a href="mailto:dirk@hohndel.org" target="_blank">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="gmail-m_-6265252539289790786quoted-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></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></blockquote><div><br></div><div>So I just tested with my Petrel 2, using the USB Bluetooth controller that came with the DC.  I don't think that controller actually supports BLE.  I received the insufficient privileges error.<br>[0.000099] ERROR: No such file or directory (2) [in ../../src/serial_posix.c:177 (dc_serial_open)]<br>[0.000153] ERROR: Failed to open the serial port. [in ../../src/shearwater_common.c:46 (shearwater_common_open)]<br><br>For comparison, I downloaded with Master (51ee9d4 Latest translations) fine.<br><br></div><div>Next, I tried a different controller (Targus Bluetooth 4.0), which says on the packet that it does support BLE.  I had to go through the pairing thing again, but pairing wouldn't work with the ble-prep branch.<br>qt.bluetooth.bluez: Discovered:  "00:13:43:0E:6B:D0" "Petrel" Num UUIDs 1 total device 3 cached RSSI -59 Class 0<br>qt.bluetooth.bluez: Updating RSSI for "4A:4F:4D:FE:1B:B6" QVariant(short, -80)<br>qt.bluetooth.bluez: Updating RSSI for "1C:1A:C0:92:76:54" QVariant(short, -76)<br>qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"<br>qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"<br>qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"<br>qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"<br>qt.bluetooth.bluez: Failed to create pairing "org.bluez.Error.InProgress"<br>qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"<br>qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"<br>qt.bluetooth.bluez: Failed to create pairing "org.bluez.Error.InProgress"<br>qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"<br>qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"<br>qt.bluetooth.bluez: Failed to create pairing "org.bluez.Error.InProgress"<br>qt.bluetooth.bluez: Failed to create pairing "org.freedesktop.DBus.Error.NoReply"<br><br>I paired the device from Subsurface master build, then tested download from the ble-prep build again.  This time the download worked.<br>qt.bluetooth.bluez: Discovered:  "00:13:43:0E:6B:D0" "Petrel" Num UUIDs 1 total device 0 cached RSSI 0 Class 0<br>qt.bluetooth.bluez: Discovered:  "1C:1A:C0:92:76:54" "1C-1A-C0-92-76-54" Num UUIDs 0 total device 1 cached RSSI 0 Class 0<br>qt.bluetooth.bluez: Discovered:  "4A:4F:4D:FE:1B:B6" "4A-4F-4D-FE-1B-B6" Num UUIDs 0 total device 2 cached RSSI 0 Class 0<br>qt.bluetooth.bluez: Discovered:  "90:00:DB:C6:98:B0" "Galaxy S6" Num UUIDs 14 total device 3 cached RSSI 0 Class 5898764<br>qt.bluetooth.bluez: Updating RSSI for "4A:4F:4D:FE:1B:B6" QVariant(short, -85)<br>qt.bluetooth.bluez: Updating RSSI for "1C:1A:C0:92:76:54" QVariant(short, -76)<br>qt.bluetooth.bluez: void QBluetoothDeviceDiscoveryAgentPrivate::stop()<br>Using bluetooth mode 2<br>qt.bluetooth.bluez: void QBluetoothSocketPrivate::_q_readNotify() 16 error: -1 "Resource temporarily unavailable"<br><br></div><div>I think the bluetooth mode 2 means it was using BLE.<br></div><div><br></div><div>I don't know why it gave the error 16 at the end of the terminal output, but download worked and no error was shown in the ui.<br></div><div><br></div><div>Summary of brief testing, it appears:<br></div><div>- download works with a BLE controller<br></div><div>- this breaks pairing (at least for me)<br>- this breaks bluetooth support for at least one non-BLE controller<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><span class="gmail-"><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail-m_-6265252539289790786quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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="gmail-m_-6265252539289790786elided-text">______________________________<wbr>_________________<br>
subsurface mailing list<br>
<a href="mailto:subsurface@subsurface-divelog.org" target="_blank">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-divelo<wbr>g.org/cgi-bin/mailman/listinfo<wbr>/subsurface</a><br>
</div></blockquote></div><br></div></div></span></div>
</blockquote></div><br></div></div></div>