On 05-06-17 17:49, Dirk Hohndel wrote:
On Mon, Jun 05, 2017 at 05:40:10PM +0200, Jan Mulder wrote:
On 05-06-17 16:41, Dirk Hohndel wrote:
We learned from HW that this should never be the case with production
OSTC. Hmm. Not sure what to do here... that's a generic ID for the chip
they used - not sure if it's smart to assume that's an OSTC. But maybe
that's what we should do? Or we need another UI to pick the device...
I think we need another UI to pick the device anyhow (unfortunately). For
example, for divers that that use more than one BT dive computer, or in the
special cases that automatically checking of a long list of paired BT
devices fails.
I think I have an idea how to do that, actually... we could create a
"virtual" vendor "Paired BT Devices" and then as "products" we could have
the paired devices... I'll play with that idea.
/D
Ok, I followed up on the forTomaz branch to see if the idea with a
virtual vendor and a set of paired devices could work. I have things
partly working (not commit ready yet). I see, however, a fundamental
problem with this strategy. In order to do a correct dc_device_open, we
need a real vendor/product pair, and that data is not coming from a
paired BT device. In fact, when we could construct a real vendor/product
pair from only BT discovery data, we wouldn't need a virtual vendor in
the first place.
Obviously, we could construct logic to translate a BT name to a
vendor/product pair and attach that data to virtual vendor/paired device
(and basically we need this anyhow to do automatic discovery of DCs),
but that still does not enable downloading from a paired BT device of
which we could not determine the real vendor/product pair (but would
enable downloading from more than one BT DC from one client).
Concluding, I am a bit stuck ...
--jan
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
