Re: Very timid beginning framework for BLE communication

[Linus Torvalds]

On Mon, Apr 24, 2017 at 10:26 AM, Linus Torvalds
 wrote:
> On Mon, Apr 24, 2017 at 12:44 AM, Rick Walsh  wrote:
>>
>> Summary of brief testing, it appears:
>> - download works with a BLE controller
>> - this breaks pairing (at least for me)
>> - this breaks bluetooth support for at least one non-BLE controller
>
> Hmm. The ble-prep branch really should change absolutely nothing
> (because it ends up using the exact same code) apart from the printout

Oh, I take that back.

I see what's up. The BT mode picking depends on having the whole Qt
bluetooth device info filled in, not just the address.

And normally we don't even have that, unless we just scanned the
device and paired with it.

So if you just use the old saved BT pairing information, my new
bluetooth mode code will screw up entirely and think that you
shouldn't use bluetooth at all, because it didn't see a device mode.

So that whole "use the device info to pick RFCOMM or BLE" approach is bogus.

I will have to think more about this, but I think I have an approach
that might work.

 Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Very timid beginning framework for BLE communication

[Linus Torvalds]

On Mon, Apr 24, 2017 at 12:44 AM, Rick Walsh  wrote:
>
> Summary of brief testing, it appears:
> - download works with a BLE controller
> - this breaks pairing (at least for me)
> - this breaks bluetooth support for at least one non-BLE controller

Hmm. The ble-prep branch really should change absolutely nothing
(because it ends up using the exact same code) apart from the printout
of

  Using bluetooth mode 2

that means that it just uses the ble functions (but those functions
are currently the exact same functions as the non-BLE ones).

And in fact the pairing code doesn't even trigger *that* difference.

The fact that it then later worked makes me wonder if your problem is
simply intermittent. The BT code has definitely been flaky for people,
just judging by the discussions even outside of this whole ble-prep
thread..

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Very timid beginning framework for BLE communication

[Rick Walsh]

Hi Linus (et al)

On 20 April 2017 at 06:49, Rick Walsh  wrote:

>
>
> On 20 Apr. 2017 5:49 am, "Linus Torvalds" 
> wrote:
>
> On Wed, Apr 19, 2017 at 12:33 PM, Dirk Hohndel  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.
>

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.
[0.99] ERROR: No such file or directory (2) [in
../../src/serial_posix.c:177 (dc_serial_open)]
[0.000153] ERROR: Failed to open the serial port. [in
../../src/shearwater_common.c:46 (shearwater_common_open)]

For comparison, I downloaded with Master (51ee9d4 Latest translations) fine.

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.
qt.bluetooth.bluez: Discovered:  "00:13:43:0E:6B:D0" "Petrel" Num UUIDs 1
total device 3 cached RSSI -59 Class 0
qt.bluetooth.bluez: Updating RSSI for "4A:4F:4D:FE:1B:B6" QVariant(short,
-80)
qt.bluetooth.bluez: Updating RSSI for "1C:1A:C0:92:76:54" QVariant(short,
-76)
qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Failed to create pairing "org.bluez.Error.InProgress"
qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Failed to create pairing "org.bluez.Error.InProgress"
qt.bluetooth.bluez: Initiating direct pair to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Sending pairing request to "00:13:43:0E:6B:D0"
qt.bluetooth.bluez: Failed to create pairing "org.bluez.Error.InProgress"
qt.bluetooth.bluez: Failed to create pairing
"org.freedesktop.DBus.Error.NoReply"

I paired the device from Subsurface master build, then tested download from
the ble-prep build again.  This time the download worked.
qt.bluetooth.bluez: Discovered:  "00:13:43:0E:6B:D0" "Petrel" Num UUIDs 1
total device 0 cached RSSI 0 Class 0
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
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
qt.bluetooth.bluez: Discovered:  "90:00:DB:C6:98:B0" "Galaxy S6" Num UUIDs
14 total device 3 cached RSSI 0 Class 5898764
qt.bluetooth.bluez: Updating RSSI for "4A:4F:4D:FE:1B:B6" QVariant(short,
-85)
qt.bluetooth.bluez: Updating RSSI for "1C:1A:C0:92:76:54" QVariant(short,
-76)
qt.bluetooth.bluez: void QBluetoothDeviceDiscoveryAgentPrivate::stop()
Using bluetooth mode 2
qt.bluetooth.bluez: void QBluetoothSocketPrivate::_q_readNotify() 16 error:
-1 "Resource temporarily unavailable"

I think the 

Re: Very timid beginning framework for BLE communication

[Martin Gysel]

Am 24.04.2017 um 01:47 schrieb Linus Torvalds:
> On Sun, Apr 23, 2017 at 1:49 PM, Anton Lundin  wrote:
>>
>> As far as I've understood things, even the scan for devices are
>> completely different, so is the reason that Qt merges the two scan
>> results?
> 
> So as far as Qt seems to be concerned, "scan for devices" is all
> exactly the same. Only after the scan does the whole LE vs RFCOMM come
> into play.
> 
> So I'd rather share the scanning code, because I think that all can be common.

exactly, AFAIK starting with Qt 5.8 it's possible to only scan for e.g.
ble devices which speeds up scanning.

> 
>> That said, I would have liked to see that device pop up as two in the
>> device list, so you can choose if you would like to talk rfcomm to it or
>> btle.
> 
> I have no idea whether that is how it can actually work.
> 
> I *think* it shows up as one device as far as the Qt layer is
> concerned, and then you can look at the device->coreConfigurations()
> to see what different configurations it supports.

I don't thinks so, as classic and low energy devices are completely
different... the almost only things they have in common is the name
bluetooth ;)


/martin

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Very timid beginning framework for BLE communication

[Linus Torvalds]

On Sun, Apr 23, 2017 at 1:49 PM, Anton Lundin  wrote:
>
> As far as I've understood things, even the scan for devices are
> completely different, so is the reason that Qt merges the two scan
> results?

So as far as Qt seems to be concerned, "scan for devices" is all
exactly the same. Only after the scan does the whole LE vs RFCOMM come
into play.

So I'd rather share the scanning code, because I think that all can be common.

> That said, I would have liked to see that device pop up as two in the
> device list, so you can choose if you would like to talk rfcomm to it or
> btle.

I have no idea whether that is how it can actually work.

I *think* it shows up as one device as far as the Qt layer is
concerned, and then you can look at the device->coreConfigurations()
to see what different configurations it supports.

  Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Very timid beginning framework for BLE communication

[Anton Lundin]

On 19 April, 2017 - 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.
> 
> 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.
> 
> 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.
> 
> 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?
> 
> 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).

I finally got around to take a look at this code. I don't really know
that much about the Qt bluetooth as I would like to do, and it was
actually Claudiu Olteanu who wrote that code as a part of his GSOC
project.

I did rewrite the custom serial layer, and thats rather what this
is about.


I did read the code, and it looked fine. The big question in my mind why
we should mix the two custom serial bluetooth layers at all? Why not
just implement them as two completely different "custom serial" layers?

As far as I've understood things, even the scan for devices are
completely different, so is the reason that Qt merges the two scan
results?

The only btle device I have access to talks classic bluetooth to, so I
haven't figured out a sane way to test this.


That said, I would have liked to see that device pop up as two in the
device list, so you can choose if you would like to talk rfcomm to it or
btle.
I haven't actually gotten around to test any btle communication against
it other than hcitool lecc, but I think it talks the exact same protocol
over the two transports.

If we exposed those two different transports to the user, thats a simple
way of handing differences in protocol, transport quality and giving the
user the option to workaround any bugs which they might encounter.


//Anton


-- 
Anton Lundin+46702-161604
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Very timid beginning framework for BLE communication

[Linus Torvalds]

On Wed, Apr 19, 2017 at 3:45 PM, Linus Torvalds
 wrote:
>
> Because as part of reading the Qt Bluetooth docs (I'm resigned to
> having to look at this myself), I noticed that the docs clearly say
> that the "QBluetoothDeviceInfo::address()" data is invalid on MacOS
> and iOS, and that you should use deviceUuid() instead.

Side note: this may or may not be limited to just the BLE side, so
it's possible that the current code works fine with traditional
bluetooth and RFCOMM. The docs aren't obvious.

So even if the current state of Qt bluetooth works fine on MacOS, it
would be good to hear if it still works with the patch, or whether
this is something that needs to be made conditional on the whole
low-energy thing.

Linus
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Very timid beginning framework for BLE communication

[Linus Torvalds]

On Wed, Apr 19, 2017 at 12:17 PM, Linus Torvalds
 wrote:
> Dirk, Anton, (and possibly others who currently use RFCOMM),

Side note: does the bluetooth code actually work on MacOS at all?

Because as part of reading the Qt Bluetooth docs (I'm resigned to
having to look at this myself), I noticed that the docs clearly say
that the "QBluetoothDeviceInfo::address()" data is invalid on MacOS
and iOS, and that you should use deviceUuid() instead.

I have a patch that tries to abstract the address use (attached), but
maybe the docs are just wrong. I have neither a mac nor a rfcomm dive
computer to test with.

So this patch may be pure garbage. Throwing it out here for comments
just in case.

  Linus
From 94f99d0479ad883462a933640c8b7cbe8ca65534 Mon Sep 17 00:00:00 2001
From: Linus Torvalds 
Date: Wed, 19 Apr 2017 15:37:44 -0700
Subject: [PATCH] QtBluetooth: Use deviceUuid() instead of address() on Macs

I don't have any hardware, but the Qt docs say that QBluetoothDeviceInfo
"address()" is garbage on MacOS and iOS:

 "Note: On iOS and macOS this address is invalid. Instead deviceUuid()
  should be used. Those two platforms do not expose Bluetooth addresses
  for found Bluetooth devices and utilize unique device identifiers"

so I wonder how that code worked.

Signed-off-by: Linus Torvalds 
---
 desktop-widgets/btdeviceselectiondialog.cpp | 27 ---
 1 file changed, 20 insertions(+), 7 deletions(-)

diff --git a/desktop-widgets/btdeviceselectiondialog.cpp b/desktop-widgets/btdeviceselectiondialog.cpp
index fcc086bf..e1c80c62 100644
--- a/desktop-widgets/btdeviceselectiondialog.cpp
+++ b/desktop-widgets/btdeviceselectiondialog.cpp
@@ -213,12 +213,25 @@ void BtDeviceSelectionDialog::hostModeStateChanged(QBluetoothLocalDevice::HostMo
 #endif
 }
 
+//
+// The Qt BT docs say that on MacOS and iOS you have to use deviceUuid,
+// not address. Don't ask me why.
+//
+static QString get_device_string(const QBluetoothDeviceInfo )
+{
+#ifdef Q_OS_MAC
+	return device.deviceUuid().toString();
+#else
+	return device.address().toString();
+#endif
+}
+
 void BtDeviceSelectionDialog::addRemoteDevice(const QBluetoothDeviceInfo )
 {
 #if defined(Q_OS_WIN)
 	// On Windows we cannot obtain the pairing status so we set only the name and the address of the device
 	QString deviceLabel = QString("%1 (%2)").arg(remoteDeviceInfo.name(),
-		 remoteDeviceInfo.address().toString());
+		 get_device_string(remoteDeviceInfo));
 	QColor pairingColor = QColor(Qt::white);
 #else
 	// By default we use the status label and the color for the UNPAIRED state
@@ -235,7 +248,7 @@ void BtDeviceSelectionDialog::addRemoteDevice(const QBluetoothDeviceInfo 
 	}
 
 	QString deviceLabel = tr("%1 (%2)   [State: %3]").arg(remoteDeviceInfo.name(),
-			  remoteDeviceInfo.address().toString(),
+			  get_device_string(remoteDeviceInfo),
 			  pairingStatusLabel);
 #endif
 	// Create the new item, set its information and add it to the list
@@ -252,7 +265,7 @@ void BtDeviceSelectionDialog::itemClicked(QListWidgetItem *item)
 	// By default we assume that the devices are paired
 	QBluetoothDeviceInfo remoteDeviceInfo = item->data(Qt::UserRole).value();
 	QString statusMessage = tr("The device %1 can be used for connection. You can press the Save button.")
-  .arg(remoteDeviceInfo.address().toString());
+  .arg(get_device_string(remoteDeviceInfo));
 	bool enableSaveButton = true;
 
 #if !defined(Q_OS_WIN)
@@ -261,7 +274,7 @@ void BtDeviceSelectionDialog::itemClicked(QListWidgetItem *item)
 
 	if (pairingStatus == QBluetoothLocalDevice::Unpaired) {
 		statusMessage = tr("The device %1 must be paired in order to be used. Please use the context menu for pairing options.")
-  .arg(remoteDeviceInfo.address().toString());
+  .arg(get_device_string(remoteDeviceInfo));
 		enableSaveButton = false;
 	}
 #endif
@@ -322,11 +335,11 @@ void BtDeviceSelectionDialog::displayPairingMenu(const QPoint )
 
 	if (chosenAction == pairAction) {
 		ui->dialogStatus->setText(tr("Trying to pair device %1")
-	.arg(currentRemoteDeviceInfo.address().toString()));
+	.arg(get_device_string(currentRemoteDeviceInfo)));
 		localDevice->requestPairing(currentRemoteDeviceInfo.address(), QBluetoothLocalDevice::Paired);
 	} else if (chosenAction == removePairAction) {
 		ui->dialogStatus->setText(tr("Trying to unpair device %1")
-	.arg(currentRemoteDeviceInfo.address().toString()));
+	.arg(get_device_string(currentRemoteDeviceInfo)));
 		localDevice->requestPairing(currentRemoteDeviceInfo.address(), QBluetoothLocalDevice::Unpaired);
 	}
 #endif
@@ -420,7 +433,7 @@ void BtDeviceSelectionDialog::deviceDiscoveryError(QBluetoothDeviceDiscoveryAgen
 QString BtDeviceSelectionDialog::getSelectedDeviceAddress()
 {
 	if (selectedRemoteDeviceInfo) {
-		return 

Re: Very timid beginning framework for BLE communication

[Rick Walsh]

On 20 Apr. 2017 5:49 am, "Linus Torvalds" 
wrote:

On Wed, Apr 19, 2017 at 12:33 PM, Dirk Hohndel  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@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: Very timid beginning framework for BLE communication

[Linus Torvalds]

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

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@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: 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
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface