Product / vendor on mobile download

Discussion:

Product / vendor on mobile download

Anton Lundin

2018-06-18 22:49:56 UTC

Hi.

I got myself a new android device running 8.1, one of those who actually
runs selinux in enforcing mode and was planing to take a look at the
whole ftdi situation, but got sidetracked with that the whole download
thingie was broken.

What actually fixed the issue in the end was:

diff --git i/mobile-widgets/qml/DownloadFromDiveComputer.qml w/mobile-widgets/qml/DownloadFromDiveComputer.qml
index 2f488586f..5a05d31fe 100644
--- i/mobile-widgets/qml/DownloadFromDiveComputer.qml
+++ w/mobile-widgets/qml/DownloadFromDiveComputer.qml
@@ -188,7 +188,9 @@ Kirigami.Page {
// strip any BT Name from the address
var devName = manager.DC_devName
manager.DC_devName = devName.replace(/^(.*) /, "")
- manager.appendTextToLog("DCDownloadThread started for " + manager.product + " on "+ manager.DC_devName)
+ manager.DC_vendor = comboVendor.currentText
+ manager.DC_product = comboProduct.currentText
+ manager.appendTextToLog("DCDownloadThread started for " + manager.DC_vendor + "/" + manager.DC_product + " on "+ manager.DC_devName)
progressBar.visible = true
downloadThread.start()
}

I have no clue what so ever about qml, but to me it looked like the
onVisibleChanged thingie wasn't called, or the visible flag wasn't set
there, so the DC_vendor / DC_product was never set, and then the
descriptor lookup didn't match anything and we passed NULL to
dc_descriptor_get_transports, and it returned NONE and we just exited
with no transports supported.

The whole chain just stomped on with no useful error message at all. Not
very nice.

Why that didn't fire on Android 8.1 I don't know, but it looks like it
works on Android 7.1 on my old device.

I was also trying to test the usb code for the suunto eon steel, but the
whole went sideways and as far as I've read the code there's no way to
enable the libdivecomputer logging. Even when I changed all the saveLog
/ data.libdc_log to a hard coded true I didn't get any logs.

The whole call chain and variable bouncing makes my head spin, so I
think its really hard to get anywhere here.

//Anton

--
Anton Lundin +46702-161604

Dirk Hohndel

2018-06-19 17:03:15 UTC

Hi Anton,

Post by Anton Lundin
Hi.
I got myself a new android device running 8.1, one of those who actually
runs selinux in enforcing mode and was planing to take a look at the
whole ftdi situation, but got sidetracked with that the whole download
thingie was broken.

And by "whole download thingie broken" you mean... that FTDI currently
doesn't work at all?

Post by Anton Lundin
diff --git i/mobile-widgets/qml/DownloadFromDiveComputer.qml w/mobile-widgets/qml/DownloadFromDiveComputer.qml
index 2f488586f..5a05d31fe 100644
--- i/mobile-widgets/qml/DownloadFromDiveComputer.qml
+++ w/mobile-widgets/qml/DownloadFromDiveComputer.qml
@@ -188,7 +188,9 @@ Kirigami.Page {
// strip any BT Name from the address
var devName = manager.DC_devName
manager.DC_devName = devName.replace(/^(.*) /, "")
- manager.appendTextToLog("DCDownloadThread started for " + manager.product + " on "+ manager.DC_devName)
+ manager.DC_vendor = comboVendor.currentText
+ manager.DC_product = comboProduct.currentText
+ manager.appendTextToLog("DCDownloadThread started for " + manager.DC_vendor + "/" + manager.DC_product + " on "+ manager.DC_devName)
progressBar.visible = true
downloadThread.start()
}

If this fixes the issue, are you sending a PR?

Post by Anton Lundin
I have no clue what so ever about qml, but to me it looked like the
onVisibleChanged thingie wasn't called, or the visible flag wasn't set
there, so the DC_vendor / DC_product was never set, and then the
descriptor lookup didn't match anything and we passed NULL to
dc_descriptor_get_transports, and it returned NONE and we just exited
with no transports supported.

Hard to tell without more debug output. Unfortunately this code has seen
a few unrelated changes - and since I still have no device where I could
test FTDI download, I didn't notice when it broke

Post by Anton Lundin
The whole chain just stomped on with no useful error message at all. Not
very nice.
Why that didn't fire on Android 8.1 I don't know, but it looks like it
works on Android 7.1 on my old device.

That's just weird. And it confuses me as we have people claiming that
it no longer works for them on any device. Does your Android 7.1 device
run the same build as the 8.1 device?

Post by Anton Lundin
I was also trying to test the usb code for the suunto eon steel, but the
whole went sideways and as far as I've read the code there's no way to
enable the libdivecomputer logging. Even when I changed all the saveLog
/ data.libdc_log to a hard coded true I didn't get any logs.

Are you still talking about Android? That should always turn on the
libdivecomputer log.
But again, I've never been able to test any of this - I've enabled it, but no
one ever gave feedback on it, which made me think that no one actually
cared (given that the EON Core/Steel work with BLE)

/D

Thomas Fänge

2018-06-19 19:30:06 UTC

Hi,

What several people have mentioned and tested, is that version 4.7.4.280 in
the Android app seems to work with USB OTG, but any version after that
fails. I'm running Oreo 8.0, and I have other apps that work with my DC
using OTG, so Oreo and the HW supports it.

Best regards,
Thomas

Post by Dirk Hohndel
Hi Anton,

Post by Anton Lundin
Hi.
I got myself a new android device running 8.1, one of those who actually
runs selinux in enforcing mode and was planing to take a look at the
whole ftdi situation, but got sidetracked with that the whole download
thingie was broken.

And by "whole download thingie broken" you mean... that FTDI currently
doesn't work at all?

Post by Anton Lundin
diff --git i/mobile-widgets/qml/DownloadFromDiveComputer.qml

w/mobile-widgets/qml/DownloadFromDiveComputer.qml

Post by Anton Lundin
index 2f488586f..5a05d31fe 100644
--- i/mobile-widgets/qml/DownloadFromDiveComputer.qml
+++ w/mobile-widgets/qml/DownloadFromDiveComputer.qml
@@ -188,7 +188,9 @@ Kirigami.Page {
// strip any BT Name from the

address

Post by Anton Lundin
var devName = manager.DC_devName
manager.DC_devName =

devName.replace(/^(.*) /, "")

Post by Anton Lundin
-

manager.appendTextToLog("DCDownloadThread started for " + manager.product
+ " on "+ manager.DC_devName)

Post by Anton Lundin
+ manager.DC_vendor =

comboVendor.currentText

Post by Anton Lundin
+ manager.DC_product =

comboProduct.currentText

Post by Anton Lundin
+

manager.appendTextToLog("DCDownloadThread started for " +
manager.DC_vendor + "/" + manager.DC_product + " on "+ manager.DC_devName)

Post by Anton Lundin
progressBar.visible = true
downloadThread.start()
}

If this fixes the issue, are you sending a PR?

Post by Anton Lundin
I have no clue what so ever about qml, but to me it looked like the
onVisibleChanged thingie wasn't called, or the visible flag wasn't set
there, so the DC_vendor / DC_product was never set, and then the
descriptor lookup didn't match anything and we passed NULL to
dc_descriptor_get_transports, and it returned NONE and we just exited
with no transports supported.

Hard to tell without more debug output. Unfortunately this code has seen
a few unrelated changes - and since I still have no device where I could
test FTDI download, I didn't notice when it broke

Post by Anton Lundin
The whole chain just stomped on with no useful error message at all. Not
very nice.
Why that didn't fire on Android 8.1 I don't know, but it looks like it
works on Android 7.1 on my old device.

That's just weird. And it confuses me as we have people claiming that
it no longer works for them on any device. Does your Android 7.1 device
run the same build as the 8.1 device?

Post by Anton Lundin
I was also trying to test the usb code for the suunto eon steel, but the
whole went sideways and as far as I've read the code there's no way to
enable the libdivecomputer logging. Even when I changed all the saveLog
/ data.libdc_log to a hard coded true I didn't get any logs.

Are you still talking about Android? That should always turn on the
libdivecomputer log.
But again, I've never been able to test any of this - I've enabled it, but no
one ever gave feedback on it, which made me think that no one actually
cared (given that the EON Core/Steel work with BLE)
/D
_______________________________________________
subsurface mailing list
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Dirk Hohndel

2018-06-20 11:51:04 UTC

Hi,
What several people have mentioned and tested, is that version 4.7.4.280 in the Android app seems to work with USB OTG, but any version after that fails. I'm running Oreo 8.0, and I have other apps that work with my DC using OTG, so Oreo and the HW supports it.

Could you try the latest Android beta. I'm not able to test it, but there's a chance that I un-broke what got broken since 4.7.4.280.
I'd love to hear feedback good or bad. Preferably with log files (you can now get those by clicking on the button in the About screen which copies all the logs to the clipboard for easy pasting into email)

Thanks

/D

Thomas Fänge

2018-06-20 12:13:53 UTC

Hi Dirk,

Absolutely, I'll do that when I get home, and I'll let you know the result,
with logs etc.

I have some different Android phones and tablets (different cookies) to
test with, and a Mares Puck Pro DC.

Best regards,
Thomas

Post by Thomas FÃ¤nge
Hi,
What several people have mentioned and tested, is that version 4.7.4.280

in the Android app seems to work with USB OTG, but any version after that
fails. I'm running Oreo 8.0, and I have other apps that work with my DC
using OTG, so Oreo and the HW supports it.
Could you try the latest Android beta. I'm not able to test it, but
there's a chance that I un-broke what got broken since 4.7.4.280.
I'd love to hear feedback good or bad. Preferably with log files (you can
now get those by clicking on the button in the About screen which copies
all the logs to the clipboard for easy pasting into email)
Thanks
/D

Thomas Fänge

2018-06-20 14:07:37 UTC

Hi Dirk,

No success, it just behaves as before, same log as before, but the
reference to "localBtDevice isn't valid or not connect" I don't recognize
from before. I still think that the log at 27.556:"Unsupported operation"
should tell us something.

"27.553: DCDownloadThread started for Mares Puck Pro on FTDI"
Starting download from ftdi
Starting the thread 0
Finishing the thread Unable to open %s %s (%s) dives downloaded 0
"27.556: Unsupported operation"
no new dives downloaded
"27.557: DCDownloadThread finished"
localBtDevice isn't valid or not connecta

Same on all devices I tested on.

I also noticed that I had to disable Bluetooth for FTDI to appear as a
valid option for connection.

Nor can I test with version 4.7.4.280 that other claims should work, since
Mares DC is not enabled in that version. ð

And yes, I have new dives on the DC... ð

Best regards,
Thomas

---------- subsurface.log ----------
Empty filename passed to function
"0.005: Successfully opened logfile /storage/emulated/0/subsurface.log at
Wed Jun 20 15:46:54 2018"
"0.005: Starting Subsurface-mobile:2.1.0(4.7.8.387):Android Oreo
(8.0):arm:en-US"
"0.006: built with libdivecomputer v0.7.0-devel-Subsurface-NG
(e97a47cca55973199715df0f818b4955e60d3a31)"
"0.006: built with Qt Version 5.10.1, runtime from Qt Version 5.10.1"
"0.006: built with libgit2 0.26.0"
localBtDevice isn't valid or not connectable
"Created position source android"
"0.013: Created position source android"
"Set GPS service update interval to 300 s"
"0.013: Set GPS service update interval to 300 s"
"0.013: location service is available"
"0.466: Synchronising data file"
"0.481: Load dives from local cache"
"0.535: Successfully opened dive data"
"0.557: AppState changed to active with save ongoing and no unsaved changes"
"0.559: 109 dives loaded from cache"
"0.560: have cloud credentials, but user asked not to connect to network"
"Set GPS service update interval to 300 s"
"0.561: Set GPS service update interval to 300 s"
Using the following font: Roboto
qqwindow devicePixelRatio 3 3
Supported dive computers:
"Aeris: 500 AI (SERIAL), A300 (SERIAL), A300 AI (SERIAL), A300CS (SERIAL),
Atmos 2 (SERIAL), Atmos AI (SERIAL), Atmos AI 2 (SERIAL), Compumask
(SERIAL), Elite (SERIAL), Elite T3 (SERIAL), Epic (SERIAL), F10 (SERIAL),
F11 (SERIAL), Manta (SERIAL), XR-1 NX (SERIAL), XR-2 (SERIAL)"
"Aqualung: i200 (SERIAL), i300 (SERIAL), i450T (SERIAL), i550 (SERIAL),
i750TC (SERIAL)"
"Atomic Aquatics: Cobalt (USB), Cobalt 2 (USB)"
"Beuchat: Mundial 2 (SERIAL), Mundial 3 (SERIAL), Voyager 2G (SERIAL)"
"Cochran: Commander I (SERIAL), Commander II (SERIAL), Commander TM
(SERIAL), EMC-14 (SERIAL), EMC-16 (SERIAL), EMC-20H (SERIAL)"
"Genesis: React Pro (SERIAL), React Pro White (SERIAL)"
"Heinrichs Weikamp: Frog (SERIAL, BT), OSTC (SERIAL), OSTC 2 (SERIAL, BT,
BLE), OSTC 2 TR (SERIAL, BT, BLE), OSTC 2C (SERIAL), OSTC 2N (SERIAL), OSTC
3 (SERIAL), OSTC 4 (SERIAL, BT, BLE), OSTC Mk2 (SERIAL), OSTC Plus (SERIAL,
BT, BLE), OSTC Sport (SERIAL, BT, BLE), OSTC cR (SERIAL)"
"Hollis: DG02 (SERIAL), DG03 (SERIAL), TX1 (SERIAL)"
"Mares: Puck Pro (SERIAL), Quad (SERIAL), Smart (SERIAL)"
"Oceanic: Atom 1.0 (SERIAL), Atom 2.0 (SERIAL), Atom 3.0 (SERIAL), Atom 3.1
(SERIAL), Datamask (SERIAL), F10 (SERIAL), F11 (SERIAL), Geo (SERIAL), Geo
2.0 (SERIAL), OC1 (SERIAL), OCS (SERIAL), OCi (SERIAL), Pro Plus 2
(SERIAL), Pro Plus 2.1 (SERIAL), Pro Plus 3 (SERIAL), VT 4.1 (SERIAL), VT
Pro (SERIAL), VT3 (SERIAL), VT4 (SERIAL), VTX (SERIAL), Veo 1.0 (SERIAL),
Veo 180 (SERIAL), Veo 2.0 (SERIAL), Veo 200 (SERIAL), Veo 250 (SERIAL), Veo
3.0 (SERIAL), Versa Pro (SERIAL)"
"Scubapro: Aladin Sport Matrix (BLE), Aladin Square (USBHID), G2 (USBHID,
BLE), G2 Console (USBHID, BLE)"
"Seemann: XP5 (SERIAL)"
"Shearwater: Nerd (SERIAL, BT), Nerd 2 (BLE), Perdix (SERIAL, BT, BLE),
Perdix AI (BLE), Petrel (SERIAL, BT), Petrel 2 (SERIAL, BT, BLE), Predator
(SERIAL, BT)"
"Sherwood: Amphos (SERIAL), Amphos Air (SERIAL), Insight (SERIAL), Insight
2 (SERIAL), Vision (SERIAL), Wisdom (SERIAL), Wisdom 2 (SERIAL), Wisdom 3
(SERIAL)"
"Subgear: XP-Air (SERIAL)"
"Suunto: Cobra (SERIAL), Cobra 2 (SERIAL), Cobra 3 (SERIAL), D3 (SERIAL),
D4 (SERIAL), D4f (SERIAL), D4i (SERIAL), D6 (SERIAL), D6i (SERIAL), D9
(SERIAL), D9tx (SERIAL), DX (SERIAL), EON Core (USBHID, BLE), EON Steel
(USBHID, BLE), Eon (SERIAL), Gekko (SERIAL), HelO2 (SERIAL), Mosquito
(SERIAL), Solution (SERIAL), Solution Alpha (SERIAL), Solution Nitrox
(SERIAL), Spyder (SERIAL), Stinger (SERIAL), Vyper (SERIAL), Vyper 2
(SERIAL), Vyper Air (SERIAL), Vyper Novo (SERIAL), Vytec (SERIAL), Zoop
(SERIAL), Zoop Novo (SERIAL)"
"Tusa: Element II (IQ-750) (SERIAL), Zen (IQ-900) (SERIAL), Zen Air
(IQ-950) (SERIAL)"
"Uwatec: Aladin Air Twin (SERIAL), Aladin Air Z (SERIAL), Aladin Air Z
Nitrox (SERIAL), Aladin Air Z O2 (SERIAL), Aladin Pro (SERIAL), Aladin Pro
Ultra (SERIAL), Aladin Sport Plus (SERIAL), Memomouse (SERIAL)"
qqwindow screen has ldpi/pdpi 72 162.923
"27.553: DCDownloadThread started for Mares Puck Pro on FTDI"
Starting download from ftdi
Starting the thread 0
Finishing the thread Unable to open %s %s (%s) dives downloaded 0
"27.556: Unsupported operation"
no new dives downloaded
"27.557: DCDownloadThread finished"
localBtDevice isn't valid or not connectable

---------- libdivecomputer.log ----------
Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------

Post by Thomas FÃ¤nge
Hi Dirk,
Absolutely, I'll do that when I get home, and I'll let you know the
result, with logs etc.
I have some different Android phones and tablets (different cookies) to
test with, and a Mares Puck Pro DC.
Best regards,
Thomas

Post by Thomas FÃ¤nge
Hi,
What several people have mentioned and tested, is that version

4.7.4.280 in the Android app seems to work with USB OTG, but any version
after that fails. I'm running Oreo 8.0, and I have other apps that work
with my DC using OTG, so Oreo and the HW supports it.
Could you try the latest Android beta. I'm not able to test it, but
there's a chance that I un-broke what got broken since 4.7.4.280.
I'd love to hear feedback good or bad. Preferably with log files (you can
now get those by clicking on the button in the About screen which copies
all the logs to the clipboard for easy pasting into email)
Thanks
/D

Dirk Hohndel

2018-06-20 19:16:05 UTC

Hi Thomas,

Thanks for testing. I wasn't all that optimistic, but based on Anton's post it seemed possible that it was as simple as this.

No success, it just behaves as before, same log as before, but the reference to "localBtDevice isn't valid or not connect" I don't recognize from before. I still think that the log at 27.556:"Unsupported operation" should tell us something.
"27.553: DCDownloadThread started for Mares Puck Pro on FTDI"
Starting download from ftdi
Starting the thread 0
Finishing the thread Unable to open %s %s (%s) dives downloaded 0

I need to fix that debug message. Grmbl.
So we still fail to open the FTDI device - but at least we are trying to open the right thing.

"27.556: Unsupported operation"
no new dives downloaded
"27.557: DCDownloadThread finished"
localBtDevice isn't valid or not connecta
Same on all devices I tested on.
I also noticed that I had to disable Bluetooth for FTDI to appear as a valid option for connection.

That's strange, can you say more? I see FTDI here on my devices with BT enabled.

Nor can I test with version 4.7.4.280 that other claims should work, since Mares DC is not enabled in that version. 😕

Worst case I can go back and hack that, I guess...

And yes, I have new dives on the DC... 😉

The error "unable to open" made it clear that this is not just a "no new dives" issue, but thanks for explicitly stating that.

---------- libdivecomputer.log ----------
Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in /data/android/subsurface/libdivecomputer/src/serial_posix.c:295 (dc_serial_open)]

This sounds like the ftdi code isn't triggered. Maybe that's what is actually broken - when we did the NG merge of libdivecomputer...

Linus, could that be the actual culprit?

/D

Matt Thompson

2018-06-20 19:59:02 UTC

Post by Thomas FÃ¤nge

Post by Thomas FÃ¤nge
---------- libdivecomputer.log ----------
Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer

v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)

Post by Thomas FÃ¤nge
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in /data/android/subsurface/

libdivecomputer/src/serial_posix.c:295 (dc_serial_open)]
This sounds like the ftdi code isn't triggered. Maybe that's what is
actually broken - when we did the NG merge of libdivecomputer...
Linus, could that be the actual culprit?

I think there is something there. When the NG work was happening I
reported that I was unable to download dives from my Suunto D4i on any the
desktop platforms (macOS, Linux, Windows 10) using the NG version but had
no problems with the released versions at the time. Sorry I didn't have
time to continue testing and I just assumed this had been resolved. I'll
grab the latest nightly tonight and test again.

Thomas Fänge

2018-06-20 20:41:36 UTC

Sorry for this, I sent the video directly to Dirk, since it was too large
for the forum mailserver...

Best regards,
Thomas

Hi Dirk!
No problem, happy to help out!
I include a video - easier to explain. When BT is on, I can only see
Mac-addresses in the drop-down box, and when I turn BT off, I can only see
FTDI. Previously both Mac-addresses and FTDI was available even when BT
was on.
I guessed previously that dc_serial_open failed, since Libdivecomputer.log
Subsurface: v4.7.8-213-g6a91611e90cc, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
This I think resulted in the "Unsupported operation" error message.
Best regards,
Thomas

Post by Dirk Hohndel
Hi Thomas,
Thanks for testing. I wasn't all that optimistic, but based on Anton's
post it seemed possible that it was as simple as this.

Post by Thomas FÃ¤nge
No success, it just behaves as before, same log as before, but the

reference to "localBtDevice isn't valid or not connect" I don't recognize
from before. I still think that the log at 27.556:"Unsupported operation"
should tell us something.

Post by Thomas FÃ¤nge
"27.553: DCDownloadThread started for Mares Puck Pro on FTDI"
Starting download from ftdi
Starting the thread 0
Finishing the thread Unable to open %s %s (%s) dives downloaded 0

I need to fix that debug message. Grmbl.
So we still fail to open the FTDI device - but at least we are trying to
open the right thing.

Post by Thomas FÃ¤nge
"27.556: Unsupported operation"
no new dives downloaded
"27.557: DCDownloadThread finished"
localBtDevice isn't valid or not connecta
Same on all devices I tested on.
I also noticed that I had to disable Bluetooth for FTDI to appear as a

valid option for connection.
That's strange, can you say more? I see FTDI here on my devices with BT enabled.

Post by Thomas FÃ¤nge
Nor can I test with version 4.7.4.280 that other claims should work,

since Mares DC is not enabled in that version. ð
Worst case I can go back and hack that, I guess...

Post by Thomas FÃ¤nge
And yes, I have new dives on the DC... ð

The error "unable to open" made it clear that this is not just a "no new
dives" issue, but thanks for explicitly stating that.

Post by Thomas FÃ¤nge
---------- libdivecomputer.log ----------
Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer

v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)

Post by Thomas FÃ¤nge
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in

/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
This sounds like the ftdi code isn't triggered. Maybe that's what is
actually broken - when we did the NG merge of libdivecomputer...
Linus, could that be the actual culprit?
/D

Linus Torvalds

2018-06-20 21:52:04 UTC

Post by Dirk Hohndel
This sounds like the ftdi code isn't triggered. Maybe that's what is actually broken - when we did the NG merge of libdivecomputer...
Linus, could that be the actual culprit?

Very possibly.

I verified the build (on desktop, but with libftdi enabled), but not
that anything _worked_.

But I didn't bring my ftdi computer (HelO2 should still work) with me,
so I still can't test.

I'll at least try to eyeball it.

Linus

Linus Torvalds

2018-06-20 21:54:29 UTC

On Thu, Jun 21, 2018 at 6:52 AM Linus Torvalds

Post by Linus Torvalds

Post by Dirk Hohndel
Linus, could that be the actual culprit?

Very possibly.

Oh, I should have read the whole thread. Apparently the real cause has
been found, and was not the libdivecomputer custom IO changes.

Never mind. That should teach me.

Linus

Thomas Fänge

2018-06-21 06:16:49 UTC

Hi!

Sorry to say, but I still fail to download, the log looks just as it has
done for the last weeks.
I have tried on Android 6, 8 and 9, with both phone and tablet (all Sony
Xperia).
I also tested on a Samsung Galaxy S6 with Android 7, but exactly the same
result (and same here, if BT is on, FTDI is not available in the connection
drop-down).
With the Samsung I also created a new account (empty database), but same
result.

Still the same error from libdivecomputer:

INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]

Are there anyone who has managed to download using OTG and this latest
version of the Android app (2.1.0(4.7.8.389))?

Probably no issue, but one curiosity thou, see the log below at 85.902 and
85.951 (I tried, and tried again a second time) - the text "FTDI" is in
uppercase one time and lower case the second time - how come?
Apparently it is uppercase the first time, and lowercase all following
times ...

Best regards,
Thomas

*First try:*

"85.902: DCDownloadThread started for Mares Puck Pro on *FTDI*"

Starting download from ftdi
Starting the thread 0
Finishing the thread Kunde inte Ã¶ppna fil %s %s (%s) dives downloaded 0
"85.918: Unsupported operation"
no new dives downloaded
"85.920: DCDownloadThread finished"

*Second try directly after the first one:*

"88.951: DCDownloadThread started for Mares Puck Pro on *ftdi*"

Starting download from ftdi
Starting the thread 0
Finishing the thread Kunde inte Ã¶ppna fil %s %s (%s) dives downloaded 0
"88.962: Unsupported operation"
no new dives downloaded
"88.964: DCDownloadThread finished"

---------- subsurface.log ----------
Empty filename passed to function
"0.004: Successfully opened logfile /storage/emulated/0/subsurface.log at
tors juni 21 07:37:56 2018"
"0.005: Starting Subsurface-mobile:2.1.0(4.7.8.389):Android Marshmallow
(6.0):arm:sv-SE"

"0.006: built with libdivecomputer v0.7.0-devel-Subsurface-NG
(e97a47cca55973199715df0f818b4955e60d3a31)"
"0.006: built with Qt Version 5.10.1, runtime from Qt Version 5.10.1"
"0.006: built with libgit2 0.26.0"
"localDevice Xperia Z3 Tablet Compact is valid, starting discovery"
paired BT classic device type 1 with address "04:5D:4B:83:18:F3"
paired BT classic device type 1 with address "8C:DE:52:10:12:35"
Found new device: "WH-1000XM2" "04:5D:4B:83:18:F3"
Not recognized as dive computer
Found new device: "SRS-BTV5" "8C:DE:52:10:12:35"
Not recognized as dive computer
Paired = "WH-1000XM2" "04:5D:4B:83:18:F3"
Paired = "SRS-BTV5" "8C:DE:52:10:12:35"
"Created position source android"
"0.035: Created position source android"

"Set GPS service update interval to 300 s"
"0.035: Set GPS service update interval to 300 s"
"0.036: location service is available"
"1.210: Synkroniserar datafil"
"1.223: Dyk ladade frÃ¥n lokal buffert"
"1.303: Lyckades med att Ã¶ppna dykdata"
"1.379: AppState changed to active with save ongoing and no unsaved changes"
"1.381: 109 dives loaded from cache"
"1.384: have cloud credentials, trying to connect"
"1.384: Have credentials, let's see if they are valid"
Completed connection with cloud storage backend, response "[OK]"

"Set GPS service update interval to 300 s"
"3.045: Set GPS service update interval to 300 s"
Using the following font: Roboto
qqwindow devicePixelRatio 2 2

Supported dive computers:
"Aeris: 500 AI (SERIAL), A300 (SERIAL), A300 AI (SERIAL), A300CS (SERIAL),
Atmos 2 (SERIAL), Atmos AI (SERIAL), Atmos AI 2 (SERIAL), Compumask
(SERIAL), Elite (SERIAL), Elite T3 (SERIAL), Epic (SERIAL), F10 (SERIAL),
F11 (SERIAL), Manta (SERIAL), XR-1 NX (SERIAL), XR-2 (SERIAL)"
"Aqualung: i200 (SERIAL), i300 (SERIAL), i450T (SERIAL), i550 (SERIAL),
i750TC (SERIAL)"
"Atomic Aquatics: Cobalt (USB), Cobalt 2 (USB)"
"Beuchat: Mundial 2 (SERIAL), Mundial 3 (SERIAL), Voyager 2G (SERIAL)"
"Cochran: Commander I (SERIAL), Commander II (SERIAL), Commander TM
(SERIAL), EMC-14 (SERIAL), EMC-16 (SERIAL), EMC-20H (SERIAL)"
"Genesis: React Pro (SERIAL), React Pro White (SERIAL)"
"Heinrichs Weikamp: Frog (SERIAL, BT), OSTC (SERIAL), OSTC 2 (SERIAL, BT,
BLE), OSTC 2 TR (SERIAL, BT, BLE), OSTC 2C (SERIAL), OSTC 2N (SERIAL), OSTC
3 (SERIAL), OSTC 4 (SERIAL, BT, BLE), OSTC Mk2 (SERIAL), OSTC Plus (SERIAL,
BT, BLE), OSTC Sport (SERIAL, BT, BLE), OSTC cR (SERIAL)"
"Hollis: DG02 (SERIAL), DG03 (SERIAL), TX1 (SERIAL)"
"Mares: Puck Pro (SERIAL), Quad (SERIAL), Smart (SERIAL)"
"Oceanic: Atom 1.0 (SERIAL), Atom 2.0 (SERIAL), Atom 3.0 (SERIAL), Atom 3.1
(SERIAL), Datamask (SERIAL), F10 (SERIAL), F11 (SERIAL), Geo (SERIAL), Geo
2.0 (SERIAL), OC1 (SERIAL), OCS (SERIAL), OCi (SERIAL), Pro Plus 2
(SERIAL), Pro Plus 2.1 (SERIAL), Pro Plus 3 (SERIAL), VT 4.1 (SERIAL), VT
Pro (SERIAL), VT3 (SERIAL), VT4 (SERIAL), VTX (SERIAL), Veo 1.0 (SERIAL),
Veo 180 (SERIAL), Veo 2.0 (SERIAL), Veo 200 (SERIAL), Veo 250 (SERIAL), Veo
3.0 (SERIAL), Versa Pro (SERIAL)"
"Scubapro: Aladin Sport Matrix (BLE), Aladin Square (USBHID), G2 (USBHID,
BLE), G2 Console (USBHID, BLE)"
"Seemann: XP5 (SERIAL)"
"Shearwater: Nerd (SERIAL, BT), Nerd 2 (BLE), Perdix (SERIAL, BT, BLE),
Perdix AI (BLE), Petrel (SERIAL, BT), Petrel 2 (SERIAL, BT, BLE), Predator
(SERIAL, BT)"
"Sherwood: Amphos (SERIAL), Amphos Air (SERIAL), Insight (SERIAL), Insight
2 (SERIAL), Vision (SERIAL), Wisdom (SERIAL), Wisdom 2 (SERIAL), Wisdom 3
(SERIAL)"
"Subgear: XP-Air (SERIAL)"
"Suunto: Cobra (SERIAL), Cobra 2 (SERIAL), Cobra 3 (SERIAL), D3 (SERIAL),
D4 (SERIAL), D4f (SERIAL), D4i (SERIAL), D6 (SERIAL), D6i (SERIAL), D9
(SERIAL), D9tx (SERIAL), DX (SERIAL), EON Core (USBHID, BLE), EON Steel
(USBHID, BLE), Eon (SERIAL), Gekko (SERIAL), HelO2 (SERIAL), Mosquito
(SERIAL), Solution (SERIAL), Solution Alpha (SERIAL), Solution Nitrox
(SERIAL), Spyder (SERIAL), Stinger (SERIAL), Vyper (SERIAL), Vyper 2
(SERIAL), Vyper Air (SERIAL), Vyper Novo (SERIAL), Vytec (SERIAL), Zoop
(SERIAL), Zoop Novo (SERIAL)"
"Tusa: Element II (IQ-750) (SERIAL), Zen (IQ-900) (SERIAL), Zen Air
(IQ-950) (SERIAL)"
"Uwatec: Aladin Air Twin (SERIAL), Aladin Air Z (SERIAL), Aladin Air Z
Nitrox (SERIAL), Aladin Air Z O2 (SERIAL), Aladin Pro (SERIAL), Aladin Pro
Ultra (SERIAL), Aladin Sport Plus (SERIAL), Memomouse (SERIAL)"
qqwindow screen has ldpi/pdpi 72 141.613
"6.286: Synkroniserar datafil"
"6.302: Synka med molnlagring"
"7.154: Successful cloud connection, fetch remote"
"8.205: Klar med synkronisering till molnlagring"
"8.216: Cloud sync shows local cache was current"
The item About_QMLTYPE_111(0x9d51f040) is already in the PageRow
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
"85.902: DCDownloadThread started for Mares Puck Pro on FTDI"

Starting download from ftdi
Starting the thread 0
Finishing the thread Kunde inte Ã¶ppna fil %s %s (%s) dives downloaded 0
"85.918: Unsupported operation"
no new dives downloaded
"85.920: DCDownloadThread finished"
"88.951: DCDownloadThread started for Mares Puck Pro on ftdi"

Starting download from ftdi
Starting the thread 0
Finishing the thread Kunde inte Ã¶ppna fil %s %s (%s) dives downloaded 0
"88.962: Unsupported operation"
no new dives downloaded
"88.964: DCDownloadThread finished"
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
The item About_QMLTYPE_111(0x9d51f040) is already in the PageRow
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread

---------- libdivecomputer.log ----------
Subsurface: v4.7.8-213-g6a91611e90cc, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)

INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------

Post by Linus Torvalds
On Thu, Jun 21, 2018 at 6:52 AM Linus Torvalds

Post by Linus Torvalds

Post by Dirk Hohndel
Linus, could that be the actual culprit?

Very possibly.

Oh, I should have read the whole thread. Apparently the real cause has
been found, and was not the libdivecomputer custom IO changes.
Never mind. That should teach me.
Linus

Dirk Hohndel

2018-06-21 06:29:57 UTC

Sorry to say, but I still fail to download, the log looks just as it has done for the last weeks.
I have tried on Android 6, 8 and 9, with both phone and tablet (all Sony Xperia).
I also tested on a Samsung Galaxy S6 with Android 7, but exactly the same result (and same here, if BT is on, FTDI is not available in the connection drop-down).

So this is the first thing that really puzzles me. Your log shows that you are using the correct version. I have the beta on my phone and can definitely switch between FTDI and BT and BLE connections.

With the Samsung I also created a new account (empty database), but same result.
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in /data/android/subsurface/libdivecomputer/src/serial_posix.c:295 (dc_serial_open)]
Are there anyone who has managed to download using OTG and this latest version of the Android app (2.1.0(4.7.8.389))?

Since I just made it available a couple of hours ago, I doubt it.
Based on Anton's comments I would have expected this to work, but it's always possible that he has other changes in his sources that I don't know about.
I'm optimistic that we'll figure it out - but I'm a bit disappointed :-/

Probably no issue, but one curiosity thou, see the log below at 85.902 and 85.951 (I tried, and tried again a second time) - the text "FTDI" is in uppercase one time and lower case the second time - how come?
Apparently it is uppercase the first time, and lowercase all following times ...

Interesting observation, but that should matter. I will however look into it. Since you seem to have been able to use OTG with an Xperia phone in the past I asked around and a friend has offered his wife's old Experia phone to me. So when I'm back home next week I hopefully will have a device that actually will allow me to track this down directly which seems much easier than poking in the dark...

Thanks for your patience :-)

"85.902: DCDownloadThread started for Mares Puck Pro on FTDI"

Now this is interesting... I thought the Mares Puck Pro cable was based on Silicon Labs, not FTDI...
Did you say this used to work for you before? With this dive computer?

That's REALLY strange.

/D

Thomas Fänge

2018-06-21 06:36:07 UTC

Hi Dirk,

No, I have not been able to use OTG with my phones and Subsurface before
(Mares was not enabled back then), but when I tried I got the same problem
(same error log) as others using other DC which had worked before.

But - if I try with other programs (like DiveMate), it can find and
download from the Puck (so the phone, cable, and Android version I have
works with OTG and Mares, but not Subsurface on the same phone/tablet ...).

Best regards,
Thomas

Post by Thomas FÃ¤nge

Post by Thomas FÃ¤nge
Sorry to say, but I still fail to download, the log looks just as it has

done for the last weeks.

Post by Thomas FÃ¤nge
I have tried on Android 6, 8 and 9, with both phone and tablet (all Sony

Xperia).

Post by Thomas FÃ¤nge
I also tested on a Samsung Galaxy S6 with Android 7, but exactly the

same result (and same here, if BT is on, FTDI is not available in the
connection drop-down).
So this is the first thing that really puzzles me. Your log shows that you
are using the correct version. I have the beta on my phone and can
definitely switch between FTDI and BT and BLE connections.

Post by Thomas FÃ¤nge
With the Samsung I also created a new account (empty database), but same

result.

Post by Thomas FÃ¤nge
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in

/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]

Post by Thomas FÃ¤nge
Are there anyone who has managed to download using OTG and this latest

version of the Android app (2.1.0(4.7.8.389))?
Since I just made it available a couple of hours ago, I doubt it.
Based on Anton's comments I would have expected this to work, but it's
always possible that he has other changes in his sources that I don't know
about.
I'm optimistic that we'll figure it out - but I'm a bit disappointed :-/

Post by Thomas FÃ¤nge
Probably no issue, but one curiosity thou, see the log below at 85.902

and 85.951 (I tried, and tried again a second time) - the text "FTDI" is in
uppercase one time and lower case the second time - how come?

Post by Thomas FÃ¤nge
Apparently it is uppercase the first time, and lowercase all following

times ...
Interesting observation, but that should matter. I will however look into
it. Since you seem to have been able to use OTG with an Xperia phone in the
past I asked around and a friend has offered his wife's old Experia phone
to me. So when I'm back home next week I hopefully will have a device that
actually will allow me to track this down directly which seems much easier
than poking in the dark...
Thanks for your patience :-)

Post by Thomas FÃ¤nge
"85.902: DCDownloadThread started for Mares Puck Pro on FTDI"

Now this is interesting... I thought the Mares Puck Pro cable was based on
Silicon Labs, not FTDI...
Did you say this used to work for you before? With this dive computer?
That's REALLY strange.
/D

Dirk Hohndel

2018-06-21 06:53:15 UTC

Post by Thomas FÃ¤nge
Hi Dirk,
No, I have not been able to use OTG with my phones and Subsurface before (Mares was not enabled back then), but when I tried I got the same problem (same error log) as others using other DC which had worked before.

Ah - that's the confusion.
We think the Mares BlueLink Pro adapter might work (still looking for more information from testers), but we don't believe that the Silicon Labs cable will work with the current version. Sorry for the confusion there :-(

Post by Thomas FÃ¤nge
But - if I try with other programs (like DiveMate), it can find and download from the Puck (so the phone, cable, and Android version I have works with OTG and Mares, but not Subsurface on the same phone/tablet ...).

Yes, that's because they access devices differently than we do. This is something that we want to add, but so far no developer with the right skill set has had the time AND motivation to implement the missing code.

/D

Thomas Fänge

2018-06-21 13:01:20 UTC

Hi again,

Just to be sure that we talk about the same things ...

Post by Thomas FÃ¤nge

Post by Dirk Hohndel
Yes, that's because they access devices differently than we do. This is

something that we >> want to add, but so far no developer with the right
skill set has had the time AND motivation >> to implement the missing code.

In issue #1403 Tobias mention that he no longer can download from his
Oceanic using OTG cable (as I read it, a physical cable between the phone
and DC, no BT). But, backing the app to the old version 4.7.4.280 it works
again. And I've seen other comments about this, ie. using pre 4.7.5
versions works with a OTG cable but after that it fails.

So, this functionality actually worked before 4.7.5 but was apparently
broken from that version. Or the old implementation was replaced by a new
which doesn't work for this use case.

Maybe I could use some days to look into the difference between 4.7.4.280
and the next release and try to understand what was changed between these
two releases in this area ... ;)

Best regards,
Thomas

Post by Thomas FÃ¤nge

Post by Dirk Hohndel
Hi Dirk,
No, I have not been able to use OTG with my phones and Subsurface before

(Mares was not enabled back then), but when I tried I got the same problem
(same error log) as others using other DC which had worked before.
Ah - that's the confusion.
We think the Mares BlueLink Pro adapter might work (still looking for more
information from testers), but we don't believe that the Silicon Labs cable
will work with the current version. Sorry for the confusion there :-(

Post by Dirk Hohndel
But - if I try with other programs (like DiveMate), it can find and

download from the Puck (so the phone, cable, and Android version I have
works with OTG and Mares, but not Subsurface on the same phone/tablet ...).
Yes, that's because they access devices differently than we do. This is
something that we want to add, but so far no developer with the right skill
set has had the time AND motivation to implement the missing code.
/D

Anton Lundin

2018-06-21 20:37:45 UTC

Post by Dirk Hohndel

Sorry to say, but I still fail to download, the log looks just as it has done for the last weeks.
I have tried on Android 6, 8 and 9, with both phone and tablet (all Sony Xperia).
I also tested on a Samsung Galaxy S6 with Android 7, but exactly the same result (and same here, if BT is on, FTDI is not available in the connection drop-down).

So this is the first thing that really puzzles me. Your log shows that you are using the correct version. I have the beta on my phone and can definitely switch between FTDI and BT and BLE connections.

With the Samsung I also created a new account (empty database), but same result.
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in /data/android/subsurface/libdivecomputer/src/serial_posix.c:295 (dc_serial_open)]
Are there anyone who has managed to download using OTG and this latest version of the Android app (2.1.0(4.7.8.389))?

Since I just made it available a couple of hours ago, I doubt it.
Based on Anton's comments I would have expected this to work, but it's always possible that he has other changes in his sources that I don't know about.
I'm optimistic that we'll figure it out - but I'm a bit disappointed :-/

I shouldn't have had any other changes in my tree which could affect
this.

My guess is that this is a slilicon labs cable.

We should rewrite the frontend to look for connected usb devices, and
only present the ftdi option if a matching device is connected.

Also, if we detect a ftdi device, we should expose all "serial" dive
computers as choices, instead of the current guesswork with "who has
ftdi cables". This can also solve the whole dive-dongle-debacle in a
decent way.

This way we can support the "pure usb" devices like EON Steel/Core,
Scubapro G2 and Cobalt in a more obvious way, and letting the user choose
the appropriate device in the box to use that in the open call instead
of just grabbing the first one.

There are probably only a few users who ever have multiple ftdi devices
attached, I'm one of those crazy ones.

//Anton

--
Anton Lundin +46702-161604

Linus Torvalds

2018-06-21 06:53:26 UTC

Post by Thomas FÃ¤nge
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in /data/android/subsurface/libdivecomputer/src/serial_posix.c:295 (dc_serial_open)]

Note: this is "normal".

The DC_TRANSPORT_SERIAL first just calls dc_serial_open(), and only if
that fails will it then try to fall back on the "ftdi_open()" case.

rc = dc_serial_open(&data->iostream, context, data->devname);
if (rc == DC_STATUS_SUCCESS)
return rc;

#ifdef SERIAL_FTDI
if (!strcmp(data->devname, "ftdi")) {
rc = ftdi_open(&data->iostream, context);
if (rc == DC_STATUS_SUCCESS)
return rc;
}
#endif

so an error from dc_serial_open() is actually expected.

I guess we could move the ftdi check up.

If the FTDI open fails, it should print an error message right *after*
the one from dc_serial_open(). But you cut out the rest of the
output..

Linus

Thomas Fänge

2018-06-21 07:26:13 UTC

Hi Linus,

Yes, you are right, failure in dc_serial_open drops down to ftdi_open.

Post by Thomas FÃ¤nge

But you cut out the rest of the output..

No, that all there was in the libdivecomputer.log, after that error the log
was empty (and proceeding this is only version information), so the INFO
and ERROR line is the complete log.

---------- libdivecomputer.log ----------
Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------

Somewhere along these lines, DC_STATUS_UNSUPPORTED is returned which causes
the output "Unsupported operation", don't know if this is pointing
somewhere, or is just also expected information ... ;)

But, I guess Dirk is right, there is still some confusion about using OTG
cable, Bluetooth Link, FTDI etc, so there are still some hurdles to pass ...

Best regards,
Thomas

tors 21 juni 2018 kl 08:53 skrev Linus Torvalds <

Post by Thomas FÃ¤nge

INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in

/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
Note: this is "normal".
The DC_TRANSPORT_SERIAL first just calls dc_serial_open(), and only if
that fails will it then try to fall back on the "ftdi_open()" case.
rc = dc_serial_open(&data->iostream, context,
data->devname);
if (rc == DC_STATUS_SUCCESS)
return rc;
#ifdef SERIAL_FTDI
if (!strcmp(data->devname, "ftdi")) {
rc = ftdi_open(&data->iostream, context);
if (rc == DC_STATUS_SUCCESS)
return rc;
}
#endif
so an error from dc_serial_open() is actually expected.
I guess we could move the ftdi check up.
If the FTDI open fails, it should print an error message right *after*
the one from dc_serial_open(). But you cut out the rest of the
output..
Linus

Thomas Fänge

2018-06-21 07:51:03 UTC

Hi Dirk,

Sorry for spamming, but I just noticed a "bug" after checking the
libdivecomputer.log-file after the mail from Linus.

Check the log below - that was copied this morning by using the copy-button
on the About-page in the app and the app copies both the Subsurface.log and
the libdivecomputer.log.
But look at the version number of the app in the two logs:

---------- subsurface.log ----------
Empty filename passed to function
"0.002: Successfully opened logfile /storage/emulated/0/subsurface.log
at Thu Jun 21 06:18:14 2018"
"0.003: Starting Subsurface-mobile:*2.1.0(4.7.8.**389)*:Android Oreo
(8.0):arm:en-US"

---------- libdivecomputer.log ----------
Subsurface: *v4.7.8-287*-g76f61468e690, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)

Apparently the app just copy the log-file that is present in the root, and
as in this case, the libdivecomputer.log is an old log!
The date of that log-file is from the 3/6, so almost two weeks old!
Why is the libdivecomputer.log not updated when I run the app? I searched
the fs but this is the only file I found ... hmm ...

If I removed that file and try again, then there is no libdivecomputer.log
anymore, neither in the fs nor in the copied log-data from the app ...

Sorry for introducing erroneous logs ... :(

Best regards,
Thomas

---------- subsurface.log ----------
Empty filename passed to function
"0.002: Successfully opened logfile /storage/emulated/0/subsurface.log at
Thu Jun 21 06:18:14 2018"
"0.003: Starting Subsurface-mobile:2.1.0(4.7.8.389):Android Oreo
(8.0):arm:en-US"
"0.003: built with libdivecomputer v0.7.0-devel-Subsurface-NG (
e97a47cca55973199715df0f818b4955e60d3a31)"
"0.003: built with Qt Version 5.10.1, runtime from Qt Version 5.10.1"
"0.003: built with libgit2 0.26.0"
localBtDevice isn't valid or not connectable
"Created position source android"
"0.009: Created position source android"
"Set GPS service update interval to 300 s"
"0.009: Set GPS service update interval to 300 s"
"0.009: location service is available"
"0.332: Synchronising data file"
"0.338: Load dives from local cache"
"0.360: Successfully opened dive data"
"0.362: 109 dives loaded from cache"
"0.362: have cloud credentials, but user asked not to connect to network"
"Set GPS service update interval to 300 s"
"0.363: Set GPS service update interval to 300 s"
Using the following font: Roboto
qqwindow devicePixelRatio 3 3
Supported dive computers:
"Aeris: 500 AI (SERIAL), A300 (SERIAL), A300 AI (SERIAL), A300CS (SERIAL),
Atmos 2 (SERIAL), Atmos AI (SERIAL), Atmos AI 2 (SERIAL), Compumask
(SERIAL), Elite (SERIAL), Elite T3 (SERIAL), Epic (SERIAL), F10 (SERIAL),
F11 (SERIAL), Manta (SERIAL), XR-1 NX (SERIAL), XR-2 (SERIAL)"
"Aqualung: i200 (SERIAL), i300 (SERIAL), i450T (SERIAL), i550 (SERIAL),
i750TC (SERIAL)"
"Atomic Aquatics: Cobalt (USB), Cobalt 2 (USB)"
"Beuchat: Mundial 2 (SERIAL), Mundial 3 (SERIAL), Voyager 2G (SERIAL)"
"Cochran: Commander I (SERIAL), Commander II (SERIAL), Commander TM
(SERIAL), EMC-14 (SERIAL), EMC-16 (SERIAL), EMC-20H (SERIAL)"
"Genesis: React Pro (SERIAL), React Pro White (SERIAL)"
"Heinrichs Weikamp: Frog (SERIAL, BT), OSTC (SERIAL), OSTC 2 (SERIAL, BT,
BLE), OSTC 2 TR (SERIAL, BT, BLE), OSTC 2C (SERIAL), OSTC 2N (SERIAL), OSTC
3 (SERIAL), OSTC 4 (SERIAL, BT, BLE), OSTC Mk2 (SERIAL), OSTC Plus (SERIAL,
BT, BLE), OSTC Sport (SERIAL, BT, BLE), OSTC cR (SERIAL)"
"Hollis: DG02 (SERIAL), DG03 (SERIAL), TX1 (SERIAL)"
"Mares: Puck Pro (SERIAL), Quad (SERIAL), Smart (SERIAL)"
"Oceanic: Atom 1.0 (SERIAL), Atom 2.0 (SERIAL), Atom 3.0 (SERIAL), Atom 3.1
(SERIAL), Datamask (SERIAL), F10 (SERIAL), F11 (SERIAL), Geo (SERIAL), Geo
2.0 (SERIAL), OC1 (SERIAL), OCS (SERIAL), OCi (SERIAL), Pro Plus 2
(SERIAL), Pro Plus 2.1 (SERIAL), Pro Plus 3 (SERIAL), VT 4.1 (SERIAL), VT
Pro (SERIAL), VT3 (SERIAL), VT4 (SERIAL), VTX (SERIAL), Veo 1.0 (SERIAL),
Veo 180 (SERIAL), Veo 2.0 (SERIAL), Veo 200 (SERIAL), Veo 250 (SERIAL), Veo
3.0 (SERIAL), Versa Pro (SERIAL)"
"Scubapro: Aladin Sport Matrix (BLE), Aladin Square (USBHID), G2 (USBHID,
BLE), G2 Console (USBHID, BLE)"
"Seemann: XP5 (SERIAL)"
"Shearwater: Nerd (SERIAL, BT), Nerd 2 (BLE), Perdix (SERIAL, BT, BLE),
Perdix AI (BLE), Petrel (SERIAL, BT), Petrel 2 (SERIAL, BT, BLE), Predator
(SERIAL, BT)"
"Sherwood: Amphos (SERIAL), Amphos Air (SERIAL), Insight (SERIAL), Insight
2 (SERIAL), Vision (SERIAL), Wisdom (SERIAL), Wisdom 2 (SERIAL), Wisdom 3
(SERIAL)"
"Subgear: XP-Air (SERIAL)"
"Suunto: Cobra (SERIAL), Cobra 2 (SERIAL), Cobra 3 (SERIAL), D3 (SERIAL),
D4 (SERIAL), D4f (SERIAL), D4i (SERIAL), D6 (SERIAL), D6i (SERIAL), D9
(SERIAL), D9tx (SERIAL), DX (SERIAL), EON Core (USBHID, BLE), EON Steel
(USBHID, BLE), Eon (SERIAL), Gekko (SERIAL), HelO2 (SERIAL), Mosquito
(SERIAL), Solution (SERIAL), Solution Alpha (SERIAL), Solution Nitrox
(SERIAL), Spyder (SERIAL), Stinger (SERIAL), Vyper (SERIAL), Vyper 2
(SERIAL), Vyper Air (SERIAL), Vyper Novo (SERIAL), Vytec (SERIAL), Zoop
(SERIAL), Zoop Novo (SERIAL)"
"Tusa: Element II (IQ-750) (SERIAL), Zen (IQ-900) (SERIAL), Zen Air
(IQ-950) (SERIAL)"
"Uwatec: Aladin Air Twin (SERIAL), Aladin Air Z (SERIAL), Aladin Air Z
Nitrox (SERIAL), Aladin Air Z O2 (SERIAL), Aladin Pro (SERIAL), Aladin Pro
Ultra (SERIAL), Aladin Sport Plus (SERIAL), Memomouse (SERIAL)"
qqwindow screen has ldpi/pdpi 72 162.923
"1.134: AppState changed to active with no save ongoing and no unsaved
changes"
"1.861: AppState changed to inactive with no save ongoing and no unsaved
changes"
"1.931: AppState changed to suspended with no save ongoing and no unsaved
changes"
"46.448: AppState changed to active with no save ongoing and no unsaved
changes"
"47.456: AppState changed to inactive with no save ongoing and no unsaved
changes"
"47.676: AppState changed to suspended with no save ongoing and no unsaved
changes"
"LocalDeviceBroadcastReceiver::onReceive() - event:
android.bluetooth.adapter.action.SCAN_MODE_CHANGED"
btHostModeChange to QBluetoothLocalDevice::HostMode(HostConnectable)
"localDevice Xperia XZ2 Compact is valid, starting discovery"
paired BT classic device type 1 with address "F8:DF:15:02:29:86"
paired BT classic device type 1 with address "20:18:1C:00:06:73"
paired BT classic device type 1 with address "44:D4:E0:90:15:7D"
paired BT classic device type 1 with address "84:C7:EA:FF:28:10"
paired BT classic device type 1 with address "04:5D:4B:83:18:F3"
paired BT classic device type 1 with address "20:18:0E:00:02:3D"
Found new device: "SRS-XB31" "F8:DF:15:02:29:86"
Not recognized as dive computer
Found new device: "PaMu" "20:18:1C:00:06:73"
Not recognized as dive computer
Found new device: "BSP10" "44:D4:E0:90:15:7D"
Not recognized as dive computer
Found new device: "SBH24" "84:C7:EA:FF:28:10"
Not recognized as dive computer
Found new device: "WH-1000XM2" "04:5D:4B:83:18:F3"
Not recognized as dive computer
Found new device: "PaMu" "20:18:0E:00:02:3D"
Not recognized as dive computer
Paired = "SRS-XB31" "F8:DF:15:02:29:86"
Paired = "PaMu" "20:18:1C:00:06:73"
Paired = "BSP10" "44:D4:E0:90:15:7D"
Paired = "SBH24" "84:C7:EA:FF:28:10"
Paired = "WH-1000XM2" "04:5D:4B:83:18:F3"
Paired = "PaMu" "20:18:0E:00:02:3D"
"2652.307: AppState changed to active with no save ongoing and no unsaved
changes"
"LocalDeviceBroadcastReceiver::onReceive() - event:
android.bluetooth.adapter.action.SCAN_MODE_CHANGED"
btHostModeChange to QBluetoothLocalDevice::HostMode(HostPoweredOff)
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
"2718.041: AppState changed to inactive with no save ongoing and no unsaved
changes"
"2718.179: AppState changed to suspended with no save ongoing and no
unsaved changes"
"2725.767: AppState changed to active with no save ongoing and no unsaved
changes"
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
"2755.938: AppState changed to inactive with no save ongoing and no unsaved
changes"
"2756.024: AppState changed to suspended with no save ongoing and no
unsaved changes"
"2757.943: AppState changed to active with no save ongoing and no unsaved
changes"
"2788.113: AppState changed to inactive with no save ongoing and no unsaved
changes"
"2788.166: AppState changed to suspended with no save ongoing and no
unsaved changes"
"2795.412: AppState changed to active with no save ongoing and no unsaved
changes"
"2825.652: AppState changed to inactive with no save ongoing and no unsaved
changes"
"2825.730: AppState changed to suspended with no save ongoing and no
unsaved changes"
"2833.502: AppState changed to active with no save ongoing and no unsaved
changes"
"LocalDeviceBroadcastReceiver::onReceive() - event:
android.bluetooth.adapter.action.SCAN_MODE_CHANGED"
btHostModeChange to QBluetoothLocalDevice::HostMode(HostConnectable)
"localDevice Xperia XZ2 Compact is valid, starting discovery"
paired BT classic device type 1 with address "F8:DF:15:02:29:86"
paired BT classic device type 1 with address "20:18:1C:00:06:73"
paired BT classic device type 1 with address "44:D4:E0:90:15:7D"
paired BT classic device type 1 with address "84:C7:EA:FF:28:10"
paired BT classic device type 1 with address "04:5D:4B:83:18:F3"
paired BT classic device type 1 with address "20:18:0E:00:02:3D"
Found new device: "SRS-XB31" "F8:DF:15:02:29:86"
Not recognized as dive computer
Found new device: "PaMu" "20:18:1C:00:06:73"
Not recognized as dive computer
Found new device: "BSP10" "44:D4:E0:90:15:7D"
Not recognized as dive computer
Found new device: "SBH24" "84:C7:EA:FF:28:10"
Not recognized as dive computer
Found new device: "WH-1000XM2" "04:5D:4B:83:18:F3"
Not recognized as dive computer
Found new device: "PaMu" "20:18:0E:00:02:3D"
Not recognized as dive computer
Paired = "SRS-XB31" "F8:DF:15:02:29:86"
Paired = "PaMu" "20:18:1C:00:06:73"
Paired = "BSP10" "44:D4:E0:90:15:7D"
Paired = "SBH24" "84:C7:EA:FF:28:10"
Paired = "WH-1000XM2" "04:5D:4B:83:18:F3"
Paired = "PaMu" "20:18:0E:00:02:3D"
"2852.760: AppState changed to inactive with no save ongoing and no unsaved
changes"
"2853.312: AppState changed to suspended with no save ongoing and no
unsaved changes"
"3032.536: AppState changed to active with no save ongoing and no unsaved
changes"
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
"3051.225: AppState changed to inactive with no save ongoing and no unsaved
changes"
"3051.461: AppState changed to suspended with no save ongoing and no
unsaved changes"
"3056.542: AppState changed to active with no save ongoing and no unsaved
changes"
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
QObject::startTimer: Timers cannot be started from another thread
"3063.161: AppState changed to inactive with no save ongoing and no unsaved
changes"
"3063.393: AppState changed to suspended with no save ongoing and no
unsaved changes"
"3086.283: AppState changed to active with no save ongoing and no unsaved
changes"

---------- libdivecomputer.log ----------
Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in /data/android/subsurface/
libdivecomputer/src/serial_posix.c:295 (dc_serial_open)]
---------- finish ----------

Post by Thomas FÃ¤nge
Hi Linus,
Yes, you are right, failure in dc_serial_open drops down to ftdi_open.

Post by Thomas FÃ¤nge

But you cut out the rest of the output..

No, that all there was in the libdivecomputer.log, after that error the
log was empty (and proceeding this is only version information), so the
INFO and ERROR line is the complete log.
---------- libdivecomputer.log ----------
Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer
v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in
/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
---------- finish ----------
Somewhere along these lines, DC_STATUS_UNSUPPORTED is returned which
causes the output "Unsupported operation", don't know if this is pointing
somewhere, or is just also expected information ... ;)
But, I guess Dirk is right, there is still some confusion about using OTG
cable, Bluetooth Link, FTDI etc, so there are still some hurdles to pass ...
Best regards,
Thomas
tors 21 juni 2018 kl 08:53 skrev Linus Torvalds <

Post by Thomas FÃ¤nge

INFO: Open: name=ftdi
ERROR: No such file or directory (2) [in

/data/android/subsurface/libdivecomputer/src/serial_posix.c:295
(dc_serial_open)]
Note: this is "normal".
The DC_TRANSPORT_SERIAL first just calls dc_serial_open(), and only if
that fails will it then try to fall back on the "ftdi_open()" case.
rc = dc_serial_open(&data->iostream, context,
data->devname);
if (rc == DC_STATUS_SUCCESS)
return rc;
#ifdef SERIAL_FTDI
if (!strcmp(data->devname, "ftdi")) {
rc = ftdi_open(&data->iostream, context);
if (rc == DC_STATUS_SUCCESS)
return rc;
}
#endif
so an error from dc_serial_open() is actually expected.
I guess we could move the ftdi check up.
If the FTDI open fails, it should print an error message right *after*
the one from dc_serial_open(). But you cut out the rest of the
output..
Linus

Dirk Hohndel

2018-06-21 07:59:56 UTC

Hi Thomas

Post by Thomas FÃ¤nge
Hi Dirk,
Sorry for spamming, but I just noticed a "bug" after checking the libdivecomputer.log-file after the mail from Linus.

You aren't spamming at all. Especially not if you are reporting bugs!

Post by Thomas FÃ¤nge
Check the log below - that was copied this morning by using the copy-button on the About-page in the app and the app copies both the Subsurface.log and the libdivecomputer.log.
---------- subsurface.log ----------
Empty filename passed to function
"0.002: Successfully opened logfile /storage/emulated/0/subsurface.log at Thu Jun 21 06:18:14 2018"
"0.003: Starting Subsurface-mobile:2.1.0(4.7.8.389):Android Oreo (8.0):arm:en-US"
---------- libdivecomputer.log ----------
Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
Apparently the app just copy the log-file that is present in the root, and as in this case, the libdivecomputer.log is an old log!
The date of that log-file is from the 3/6, so almost two weeks old!
Why is the libdivecomputer.log not updated when I run the app? I searched the fs but this is the only file I found ... hmm ...

It should be deleted when the app starts. I'll fix that.

/D

Anton Lundin

2018-06-21 20:22:13 UTC

Post by Dirk Hohndel
Hi Thomas

Post by Thomas FÃ¤nge
Hi Dirk,
Sorry for spamming, but I just noticed a "bug" after checking the libdivecomputer.log-file after the mail from Linus.

You aren't spamming at all. Especially not if you are reporting bugs!

Post by Thomas FÃ¤nge
Check the log below - that was copied this morning by using the copy-button on the About-page in the app and the app copies both the Subsurface.log and the libdivecomputer.log.
---------- subsurface.log ----------
Empty filename passed to function
"0.002: Successfully opened logfile /storage/emulated/0/subsurface.log at Thu Jun 21 06:18:14 2018"
"0.003: Starting Subsurface-mobile:2.1.0(4.7.8.389):Android Oreo (8.0):arm:en-US"
---------- libdivecomputer.log ----------
Subsurface: v4.7.8-287-g76f61468e690, built with libdivecomputer v0.7.0-devel-Subsurface-NG (e97a47cca55973199715df0f818b4955e60d3a31)
Apparently the app just copy the log-file that is present in the root, and as in this case, the libdivecomputer.log is an old log!
The date of that log-file is from the 3/6, so almost two weeks old!
Why is the libdivecomputer.log not updated when I run the app? I searched the fs but this is the only file I found ... hmm ...

It should be deleted when the app starts. I'll fix that.

This is sort of consistent with my tests. There is no new
libdivecomputer.log created for me.

Why? I couldn't figure out. I hard coded it to true in every place I
could find, but I never got a log file.

//Anton

--
Anton Lundin +46702-161604

Anton Lundin

2018-06-20 20:36:55 UTC

Post by Dirk Hohndel

Hi,
What several people have mentioned and tested, is that version 4.7.4.280 in the Android app seems to work with USB OTG, but any version after that fails. I'm running Oreo 8.0, and I have other apps that work with my DC using OTG, so Oreo and the HW supports it.

Could you try the latest Android beta. I'm not able to test it, but there's a chance that I un-broke what got broken since 4.7.4.280.
I'd love to hear feedback good or bad. Preferably with log files (you can now get those by clicking on the button in the About screen which copies all the logs to the clipboard for easy pasting into email)

Now the selection dialogs works, and I've found what broke all libusb
based communication and sent a PR.

https://github.com/Subsurface-divelog/subsurface/pull/1416

Now I have working ftdi and libusb based downloads for both my OSTC3 and
Suunto Eon Steel.

Spoiler. For 6-7 dives on the Eon Steel its about a bazillion times
faster.

//Anton

--
Anton Lundin +46702-161604

Dirk Hohndel

2018-06-20 21:30:23 UTC

Post by Anton Lundin
Now the selection dialogs works, and I've found what broke all libusb
based communication and sent a PR.
https://github.com/Subsurface-divelog/subsurface/pull/1416 <https://github.com/Subsurface-divelog/subsurface/pull/1416>

Merged, I'll make a new Android beta in a few moments.

Post by Anton Lundin
Now I have working ftdi and libusb based downloads for both my OSTC3 and
Suunto Eon Steel.

Excellent. Eon Steel over USB?

Post by Anton Lundin
Spoiler. For 6-7 dives on the Eon Steel its about a bazillion times
faster.

Eon Steel over BLE is hard to stomach for just downloading a day's worth
of diving. Yes, USB is about a bazillion times faster there.

Awesome

/D

Dirk Hohndel

2018-06-20 03:15:32 UTC

Post by Dirk Hohndel
Hi Anton,

Post by Anton Lundin
Hi.
I got myself a new android device running 8.1, one of those who actually
runs selinux in enforcing mode and was planing to take a look at the
whole ftdi situation, but got sidetracked with that the whole download
thingie was broken.

And by "whole download thingie broken" you mean... that FTDI currently
doesn't work at all?

Post by Anton Lundin
diff --git i/mobile-widgets/qml/DownloadFromDiveComputer.qml w/mobile-widgets/qml/DownloadFromDiveComputer.qml
index 2f488586f..5a05d31fe 100644
--- i/mobile-widgets/qml/DownloadFromDiveComputer.qml
+++ w/mobile-widgets/qml/DownloadFromDiveComputer.qml
@@ -188,7 +188,9 @@ Kirigami.Page {
// strip any BT Name from the address
var devName = manager.DC_devName
manager.DC_devName = devName.replace(/^(.*) /, "")
- manager.appendTextToLog("DCDownloadThread started for " + manager.product + " on "+ manager.DC_devName)
+ manager.DC_vendor = comboVendor.currentText
+ manager.DC_product = comboProduct.currentText
+ manager.appendTextToLog("DCDownloadThread started for " + manager.DC_vendor + "/" + manager.DC_product + " on "+ manager.DC_devName)
progressBar.visible = true
downloadThread.start()
}

If this fixes the issue, are you sending a PR?

Instead of waiting for that, I decided to spend some time on reading that
code in its current form and trying to understand the intended flow of
information (hurray for the off-gasing day after a dive trip). I think I
now understand why this might fail - but I no longer understand why this
works at all for BLE downloads.

I have taken a slightly different approach from you to ensure that the
DC_vendor and DC_product are at all times correct (I hope - QML isn't
always easy to fully understand). Maybe that will address the issue?

My standard caveat - I don't have an Android device that allows me to test
any of this (and I actually didn't bring any FTDI dive computers on this
dive trip, anyway, and neither did Linus, it seems).

/D

Anton Lundin

2018-06-20 20:40:04 UTC

Post by Dirk Hohndel
Hi Anton,

Post by Anton Lundin
I was also trying to test the usb code for the suunto eon steel, but the
whole went sideways and as far as I've read the code there's no way to
enable the libdivecomputer logging. Even when I changed all the saveLog
/ data.libdc_log to a hard coded true I didn't get any logs.

Are you still talking about Android? That should always turn on the
libdivecomputer log.
But again, I've never been able to test any of this - I've enabled it, but no
one ever gave feedback on it, which made me think that no one actually
cared (given that the EON Core/Steel work with BLE)

Still no libdivecomputer log anywhere to be found.

I think we should always enable it, and plumb it up into qDebug() so it
all ends up in the same log buffer.

//Anton

--
Anton Lundin +46702-161604

Dirk Hohndel

2018-06-20 21:26:46 UTC

Post by Anton Lundin

Post by Dirk Hohndel
Hi Anton,

Post by Anton Lundin
I was also trying to test the usb code for the suunto eon steel, but the
whole went sideways and as far as I've read the code there's no way to
enable the libdivecomputer logging. Even when I changed all the saveLog
/ data.libdc_log to a hard coded true I didn't get any logs.

Are you still talking about Android? That should always turn on the
libdivecomputer log.
But again, I've never been able to test any of this - I've enabled it, but no
one ever gave feedback on it, which made me think that no one actually
cared (given that the EON Core/Steel work with BLE)

Still no libdivecomputer log anywhere to be found.
I think we should always enable it, and plumb it up into qDebug() so it
all ends up in the same log buffer.

It is always enabled. I'm confused :-)

When you click on the button in the About page, you get both the
subsurface.log and the libdivecomputer.log -- you saw that in the
email that Thomas sent, for example

/D

26 Replies
3 Views
Permalink to this page
Disable enhanced parsing

Thread Navigation

Anton Lundin 2018-06-18 22:49:56 UTC

Dirk Hohndel 2018-06-19 17:03:15 UTC

Thomas Fänge 2018-06-19 19:30:06 UTC

Dirk Hohndel 2018-06-20 11:51:04 UTC

Thomas Fänge 2018-06-20 12:13:53 UTC

Thomas Fänge 2018-06-20 14:07:37 UTC

Dirk Hohndel 2018-06-20 19:16:05 UTC

Matt Thompson 2018-06-20 19:59:02 UTC

Thomas Fänge 2018-06-20 20:41:36 UTC

Linus Torvalds 2018-06-20 21:52:04 UTC

Linus Torvalds 2018-06-20 21:54:29 UTC

Thomas Fänge 2018-06-21 06:16:49 UTC

Dirk Hohndel 2018-06-21 06:29:57 UTC

Thomas Fänge 2018-06-21 06:36:07 UTC

Dirk Hohndel 2018-06-21 06:53:15 UTC

Thomas Fänge 2018-06-21 13:01:20 UTC

Anton Lundin 2018-06-21 20:37:45 UTC

Linus Torvalds 2018-06-21 06:53:26 UTC

Thomas Fänge 2018-06-21 07:26:13 UTC

Thomas Fänge 2018-06-21 07:51:03 UTC

Dirk Hohndel 2018-06-21 07:59:56 UTC

Anton Lundin 2018-06-21 20:22:13 UTC

Anton Lundin 2018-06-20 20:36:55 UTC

Dirk Hohndel 2018-06-20 21:30:23 UTC

Dirk Hohndel 2018-06-20 03:15:32 UTC

Anton Lundin 2018-06-20 20:40:04 UTC

Dirk Hohndel 2018-06-20 21:26:46 UTC

about - legalese

Loading...