Yeah, yeah, yeah, I should have studied the commit messages more closely and tried this under Linux (which doesn't work for me right now because I don't run Linux on the hardware, but run it in a VM under Mac OS and there is no BLE pass through into the VM).
> On Jun 27, 2017, at 2:07 PM, Dirk Hohndel <[email protected]> wrote: > >> - in particular, I don't want to change the behavior of the old >> rfcomm code - I don't have anything that uses it, and it supposedly >> works fine for others, and it's a more standardized protocol than the >> BLE GATT hackery of more modern dive computers, so it should remain >> the default mode for those dive computers that support it. > > Yes it should - but as I said earlier, it would be great to have a "prefer > BLE flag" for testing. > >> - HOWEVER, when we scan for the dive computers, we can see that some >> dive computer _only_ supports BLE. When that happens, the first patch >> in this series will now explicitly mark the bluetooth address with a >> "LE:" prefix at scan time, which will allow the rfcomm code to realize >> that it cannot use rfcomm for the device. > > Good - we could then use that to hack that flag that I mentioned earlier. > Easy enough. Which we can already do just fine on Linux by editing the address field. Only we don't have that field on Android - it's all implicit there. I think I may need to rework the Subsurface-mobile UI a bit more with the two target OS is mind. On iOS it will be all BLE only, nothing else will be supported there. And on Android we need a better way to work on serial vs. BT vs. BLE and knowing which dive computers can actually be supported... /D _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
