device autoprobing and changig bluetooth handling

[Jef Driesen]

On 2013-03-03 00:59, Dirk Hohndel wrote:
> On Mar 2, 2013, at 3:24 PM, Jan Schubert wrote:
>> Knowing which connection type to use - USB or Bluetooth, do we also 
>> have
>> IR? - should be defined by the selected divecomputer and easily 
>> known to us.

This is actually something I have on my todo list for libdivecomputer. 
The dc_descriptor_t should be extended to include some sort of flag to 
indicate the underlying communication type (serial, usb, IrDA, etc). 
Then the application can use that to provide a specific UI. For example 
serial communication needs a device name, while IrDA does not 
(technically IrDA needs an address, but we enumerate internally, and 
automatically pick the device based on the name).

One possible issue here is that usb-serial and bluetooth devices are 
used through a serial emulation layer, and as far as libdivecomputer is 
concerned these devices are no different than real serial devices.

> Yes, in theory libdivecomputer supports at least one IR attached dive
> computer, but I don't think anyone ever tried that with Subsurface

Maybe not with subsurface, but libdivecomputer has certainly been 
confirmed to work fine with IrDA devices (Uwatec Smart/Galileo) on 
linux. So it should work from subsurface too.

>> Autoprobing USB ports and devices should be not that tricky!? I 
>> guess
>> there is some way of recognizing active USB ports and autoprobing 
>> all of
>> them, one by one or also in parallel. In rare cases where someone 
>> has
>> connected several dive computers at once we should add a disclaimer
>> saying he should not do so or have an expert menu for specifying the
>> port manually (might also be needed in other cases?).
>
> Oh this is all very easy. And that CNC machine behind that USB/serial
> cable certainly won't mind when you send it random bytes over its 
> control
> port, nor will the GPS, the sensor network or any other of a number 
> of
> devices that frequently sit on the other end of these cables.
>
> The problem is that the cables are easy to identify, but what's on 
> the
> other end is NOT. And I absolutely despise software that goes around
> and randomly sends data to devices that it finds.

I agree with Dirk. Autoprobing is a *really* bad idea, and there are 
multiple reasons against it:

  * As Dirk already pointed out, sending data to random devices might be 
dangerous in some cases, because you don't know what is actually 
connected. In the worst case scenario, the download dives command for 
one device might be something very different on another one (e.g. erase 
the firmware). We already experienced such a case in libdivecomputer. If 
you try to communicate with a Mares Matrix using the Mares Icon HD 
protocol, it will lock up, and you have to reset it by taking out the 
battery. There is no permanent damage, but not something you want to do 
by default!

  * Some devices can't be probed at all. For example with the Uwatec 
Aladin/Memomouse the transfer has to be initiated on the device, not the 
host. So you can't probe these devices.

  * Autoprobing will be slow like hell. If there is no device connected, 
or one of the wrong type, you'll start hitting timeouts. It's not 
unusual for a failure to take several seconds. Multiply that by the 
number of backends (or even devices) supported by libdivecomputer, an 
you'll easily be waiting several minutes. I won't be surprised if the 
probing takes longer than the actual download.

Because of all this, and especially the first argument, I'll never 
accept this type of general autoprobing in libdivecomputer. Of course 
that doesn't mean we can't assist the user by listing the available 
serial ports, offering the most likely candidate, etc. But ultimately 
only the user can make the final decision.

Note that there are indeed some types of autoprobing that are safe, and 
we already make use of that in libdivecomputer, but those happen at a 
whole different level. For example in many cases (but not all!) the 
actual model within the family can be autodetected. That makes it 
possible to select any device within the same family, and it will 
equally work well as if you had selected the correct model. But this is 
something that is supported by the protocol itself (e.g. there is a 
model number somewhere in the data). Another example is the probing of 
the baudrate for the Suunto D4i, D6i and D9tx. But in this case we 
happen to know this is safe, because Suunto does it too.

>> Things gets more complicated when we talk about bluetooth. 
>> Autoprobing
>> of typical Bluetooth ports should also be possible, but as of now 
>> there
>> is a need to do some nasty manual work before the box is setup to 
>> use
>> such a port. Not sure if you have read the corresponding section 4.3 
>> in
>> the user manual, but IMHO setting up bluetooth is a PITA in Linux. 
>> And
>> also using Windows it is much more complicated to download from
>> Shearwater Predator to Subsurface than using the Shearwater Desktop
>> where the user has to specify just nothing at all and also do not 
>> have
>> to pair the unit before. Same is true when using JDiveLog, they seem 
>> to
>> use some Java Bluecove bluetooth stack doing all the work. I've not 
>> been
>> able to get it running so far but it is said, that it is just 
>> working
>> without the need for pairing before. And things go worse in Windows: 
>> In
>> my (only) experience using Subsurface on Windows it turned out that
>> pairing the Predator with Windows prevents downloading in Shearwater
>> desktop, so this might fall back to Subsurface as users will for 
>> sure
>> use both application on Windows at least for some time.
>
> That last part puzzles me - but overall Bluetooth is actually much 
> easier
> than USB/serial. The Bluetooth devices tell us their name. The 
> problem
> is that there are so many Bluetooth stacks to get this right with. 
> There are
> seemingly half a dozen under Windows and two (at least) under Linux.
> And it's not entirely obvious how to get the name of all Bluetooth 
> devices
> that the computer can see.

The bluetooth experience is indeed less then ideal. But the lack of a 
standard bluetooth framework is exactly the reason why I'm using the 
serial emulation in libdivecomputer. At the moment, I simply don't have 
a better solution.

BTW, on linux binding the rfcomm device node can be automated using a 
simple /etc/bluetooth/rfcomm.conf file. See here for some more info:

http://gpsd.berlios.de/bt.html

Jef