Product / vendor on mobile download

[Dirk Hohndel]

Hi Anton,

> On Jun 19, 2018, at 7:49 AM, Anton Lundin <glance at acc.umu.se> wrote:
> 
> 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?

> 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()
>                                }

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

> 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

> 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?

> 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