On 2018-04-25 22:12, Linus Torvalds wrote:
On Wed, Apr 25, 2018 at 11:51 AM, Dirk Hohndel <d...@hohndel.org>
wrote:
I have a Petrel (single stack BT) and Petrel 2 (dual stack) and will
test
those over lunch today. I'll try to test Mac and Android
(embarrassingly,
I currently don't have a Linux laptop with working BLE...)
Note that the magic channel/port number thing is Linux
desktop-specific:
#if defined(Q_OS_LINUX) && !defined(Q_OS_ANDROID)
And it was literally the Petrel 2 that triggered that "try channel 5".
I have no idea how that is supposed to work, or what the crazy rules
about rfcomm ports even -are-. I'm just looking at the code, and going
"eww".
Also note that on Linux and Windows, we could just use the
libdivecomputer bluetooth backend that just uses the raw socket.
Also, Jef just uses port 0 for everything.
So the whole "port/channel" thing may be entirely pointless.
In the libdivecomputer rfcomm implementation, port 0 means
auto-detection. On linux it does an SDP discovery internally to find the
correct rfcomm port number, and on Windows it uses the rfcomm uuid
instead of the port number. That way, it should always just work. And on
the hardware I tested, it does indeed.
I also don't know the exact details on how these port numbers are
assigned. I guess it depends on the dive computer firmware and/or its
bluetooth stack. The valid range for rfcomm ports is 1-30 if I remember
correctly.
The Petrel is certainly not the only one which is using a different port
number. I'm currently testing the divecomputer.eu and it seems to use
port 6.
Jef
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
