question about declared transports

Dirk Hohndel dirk at hohndel.org
Mon Apr 23 08:02:21 PDT 2018


> On Apr 23, 2018, at 7:46 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
> 
> On 2018-04-20 20:25, Linus Torvalds wrote:
>> On Thu, Apr 19, 2018 at 4:29 AM, Jef Driesen <jef at libdivecomputer.org> wrote:
>>> On 2018-04-19 12:10, Dirk Hohndel wrote:
>>>> To the best of my knowledge, no version of the Predator / Petrel / Nerd
>>>> family has a wired serial interface, all they do is BT or BLE (I actually
>>>> checked the website to make sure).
>>> You forgot about the serial port emulation feature of classic bluetooth
>>> (rfcomm). Basically any devices that supports bluetooth classic
>>> (DC_TRANSPORT_BLUETOOTH) can also use the serial port emulation mode
>>> (DC_TRANSPORT_SERIAL). This remains supported, and that's why they are
>>> listed both.
>> I think this would be better left to the user of the library.
>> *ANY* dive computer that does rfcomm is probably able to just say
>> "open as serial line to /dev/rfcomm*".
>> So by that logic, if  a dive computer supports DC_TRANSPORT_BLUETOOTH,
>> then it always supports DC_TRANSPORT_SERIAL.
> 
> Correct, and that's also why they are both listed explicitly.
> 
>> And the thing is, it's actually actively incorrect. The /dev/rfcomm
>> model only exists on Linux, afaik. So now that DC_TRANSPORT_SERIAL is
>> actively wrong on other platforms, like Windows, iOS and OS X.
> 
> You are wrong about that. This is certainly not a Linux only feature. Windows and OS X also support it, and I think the BSD's too. So basically it's supported by all desktop OS'es. In fact, before the I/O refactoring, this serial emulation was the only way to communicate with bluetooth enabled dive computers!

But that's where you are wrong, Jef. "basically" doesn't cut it. For example, you can't do rfcomm on Android.
And for Android this whole notion of DC_TRANSPORT_SERIAL is way too generic. We support SOME FORM of serial transport and not others.
You are writing libdivecomputer - as your own comment above indicates, purely from a desktop OS perspective.

>> In fact, while Android is Linux too, it doesn't do the whole "rfcomm
>> bind" thing, so it's wrong there too.
>> Let's say that you have a platform that supports real serial lines,
>> but doesn't support legacy bluetooth, now  that DC_TRANSPORT_SERIAL is
>> actively  wrong.
>> So adding that DC_TRANSPORT_SERIAL doesn't actually buy you anything,
>> but it does make it harder for the actual users.
>> I think it would be better for us to remove the thing, or perhaps at
>> least make it more accurate by making the serial bit depend on the
>> platform being Linux.
>> We could also do that automatically in subsurface instead. And then we
>> could make it actually depend on finding a /dev/rfcomm* device.
> 
> The dc_descriptor_get_transports() function tells you which transports the dive computer supports, and not underlying platform! That are two completely independent things. If you have a platform that doesn't support a certain transport, then it's up to the application to ignore that bit. That's why there is the new dc_context_get_transports() function, to tell you which (built-in) transports are available on the platform. The intersection of both tells you which transport(s) are usable.

Exactly. So how do I tell on Android, with the information that libdivecomputer gives me, that I can support a Suunto D4 over serial, but not a Mares dive computer (not FTDI) and not a Shearwater divecomputer, unless we also have BT support.

I think the mistake is to assume that "DC_TRANSPORT_SERIAL" is actually a useful way to sufficiently describe the type of transport.

I know that you'll turn around and say "but Oh, the type of serial emulation is a feature of the cable, not the dive computer" and you are of course correct. But that doesn't change the fact that I don't have enough information. You LOVE abstractions. And black boxes. Love them. They are the only way you think about things. Ideally with a hidden binary format that is not documented. I get that. But please understand that the random level at which you decide to mangle information isn't always useful for the apps that want to use your library. That said, I think this is a step in the right direction and I'll just simply continue to filter for certain dive computers manually. Oh well. At least we lucked out and you got the BLE distinction right and we can filter for iOS without filtering by name. Let's celebrate victories.

/D


More information about the subsurface mailing list