<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Very, very exciting. I was able to download from my FTDI OSTC 3 on a Pixel 3 XL with Android 10. I am trying to revive a couple of my other, older USB serial dive computers to provide some more testing, but I will admit that this single test with the OSTC already has me ridiculously excited... :-)<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 6, 2020, at 8:44 AM, Christof Arnosti <<a href="mailto:charno@charno.ch" class="">charno@charno.ch</a>> wrote:</div><div class=""><div class=""><blockquote type="cite" cite="mid:844AE633-8A07-4B78-B678-9A988AF54D84@hohndel.org" class=""><div class=""><div class=""><div class=""><br class="">
</div>
I will definitely look at that later this afternoon (Pacific
Time). I will comment / send questions about the pull request
on GitHub.</div>
</div>
</blockquote>
I'm looking forward! :)<br class=""></div></div></blockquote><div><br class=""></div>As you noticed, I was too impatient to wait. This is something that I had wanted to see for so long...</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">
<blockquote type="cite" cite="mid:844AE633-8A07-4B78-B678-9A988AF54D84@hohndel.org" class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" cite="mid:7e979a6f-9a54-c942-692b-8fa7a07976cb@charno.ch" class=""><p class="">This sounds like a good idea. I don't know
Qt / qml at all, so that's possibly work for another
person.</p><p class="">What I think would be a nice way would be
to provide a list similar to this:<br class="">
- <UsbDeviceName> usb-serial-for-android
(autodetect driver)<br class="">
- <UsbDeviceName> usb-serial-for-android (<span class="pl-smi">Cp21xx)<br class="">
</span>- <UsbDeviceName>
usb-serial-for-android (Ftdi<span class="pl-smi">)<br class="">
</span>- <UsbDeviceName>
usb-serial-for-android (Prolific<span class="pl-smi">)<br class="">
</span>- <UsbDeviceName>
usb-serial-for-android (Ch34x<span class="pl-smi">)<br class="">
</span>- <UsbDeviceName>
usb-serial-for-android (CdcAcm<span class="pl-smi">)<br class="">
</span>- <UsbDeviceName> libftdi (deprecated)</p>
</blockquote>
</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">That's a lot and might make things harder on small
screens.</div>
<div class="">Also, under which circumstances do you think that the
deprecated libftdi solution would be preferable? Wouldn't we
just want to remove that?</div>
<div class="">One thing that I implemented a while ago was the intent
handling that opened Subsurface-mobile when a serial device
was plugged in; again, which situation would require the
user to specifically select the chipset?</div>
<div class="">I'm just trying to understand how this would be used (and
how we would document things).</div>
</div>
</div>
</blockquote><p class="">If we have a complete list of PID/VIDs, we don't need the
chipset-selection. The chipset selection would be nice to have for
computers which aren't yet in the PID/VID list. <br class=""></p></div></div></blockquote><div>Typically if there's a new PID/VID that means a new dive computer that we'll need more work to support in the first place.</div><div>Maybe we can hide the additional options behind an advanced menu? Or a special setting?</div><div>By default what the current version offers (usb-serial, FTDI, any paired BT/BLE computers) seems nice. And I'd even hide FTDI by default as that will fail on all newer Android devices.</div><div>I can certainly work on that part of the code (as that requires UI changes in QML)</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><p class="">
</p><p class="">The libftdi implementation is superior in the way that it
supports break, so for cochran_commander.c and reefnet_sensuspro.c
computers it's currently the only option. But if we get
break-support in usb-serial-for-android, that's probably really
obsolete.</p></div></div></blockquote><div>Well, but from reading the changes your pull request does nothing to change the existing problem that on almost all Android devices FTDI simply doesn't work - I tested that just in case I managed to confuse myself, but no, on my current Android devices this still simply fails.</div><div>That's why I think it should be hidden by default.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" cite="mid:844AE633-8A07-4B78-B678-9A988AF54D84@hohndel.org" class=""><div class=""><div class="">
Since we should have the UsbDevice object through the intent,
that seems like it should work, no? Or am I missing something
(it's been a while that I tried (and failed) to work on that.</div>
</div>
</blockquote><p class="">I usually work in the way that I manually open the subsurface
divecomputer screen and then select the computer from there. So I
don't get an intent at all.</p></div></div></blockquote><div><br class=""></div><div>This appears to have gotten broken by mistake. At some point in the past when you plugged in a dive computer Subsurface would start, open the download screen and even pick the right vendor / product (where it had sufficient information to do so).</div><div>This no longer appears to work. Something for me to play with :-)</div><blockquote type="cite" class=""><div class=""><div class=""><p class=""> But of course it would be possible to
query UsbManager from there to get a list of UsbDevice-Objects
(which we then can use to fill the connectionlistmodel). Currently
the connectionlistmodel only contains strings, and I didn't have a
look into how it works exactly, so I don't have a good answer
here.</p><p class="">If we have a complete list of PID/VID, we would only have to pass
the UsbDevice-Object to the serial_android_usb_open call. I'll
have a look into it.<br class=""></p></div></div></blockquote><div><br class=""></div>Cool</div><div><br class=""></div><div><br class=""></div><div>I will see if I can get at least one other dive computer with a different chipset to play with (I have, err, a few), but I'm planning to clean up your PR (you added fixes for the things I pointed out at the end - I prefer to just rewrite earlier commits... I will happily do that) and merge it this afternoon.</div><div><br class=""></div><div>/D</div></body></html>