Thx for looking into this! Hm, is there some possibility to test/debug qt ble then? Or should I check (and how) if there is an even lower level problem (kernel/bluez)? BR, Christian
Am 10.01.2018 um 22:02 schrieb Linus Torvalds: > On Wed, Jan 10, 2018 at 10:58 AM, Christian Schneider > <[email protected]> wrote: >> >> I attached the log from libdc and from Subsurface itself, as the libdc >> log isn't very long and the Subsurface log seems to contain some >> communication. > > Subsurface finds the service, but then when it tries to discover the > details, we never seem to finish service discovery. > > You can see the "discovering details" phase in the log, but then it > doesn't get to "enabling notifications" which is where we start to > really talk to the device. > > It fails with "failed to find suitable service on 00:1A:85:E0:0B:FA", > which just means that the Qt BLE service state never went to > ServiceDiscovered. > > (Well, "never" here means "within BLE_TIMEOUT", which is 12 seconds). > > So it never gets to the actual communication phase. > > I'm not sure why that happens. This is all still pretty much entirely > the QT BLE connection phase, there's not really any subsurface or > libdivecomputer part to it all. > > Linus >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
