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... :-)
> On Mar 6, 2020, at 8:44 AM, Christof Arnosti <cha...@charno.ch> wrote:
>>
>> I will definitely look at that later this afternoon (Pacific Time). I will
>> comment / send questions about the pull request on GitHub.
> I'm looking forward! :)
As you noticed, I was too impatient to wait. This is something that I had
wanted to see for so long...
>>>> This sounds like a good idea. I don't know Qt / qml at all, so that's
>>>> possibly work for another person.
>>>>
>>>> What I think would be a nice way would be to provide a list similar to
>>>> this:
>>>> - <UsbDeviceName> usb-serial-for-android (autodetect driver)
>>>> - <UsbDeviceName> usb-serial-for-android (Cp21xx)
>>>> - <UsbDeviceName> usb-serial-for-android (Ftdi)
>>>> - <UsbDeviceName> usb-serial-for-android (Prolific)
>>>> - <UsbDeviceName> usb-serial-for-android (Ch34x)
>>>> - <UsbDeviceName> usb-serial-for-android (CdcAcm)
>>>> - <UsbDeviceName> libftdi (deprecated)
>>>>
>>
>> That's a lot and might make things harder on small screens.
>> Also, under which circumstances do you think that the deprecated libftdi
>> solution would be preferable? Wouldn't we just want to remove that?
>> 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?
>> I'm just trying to understand how this would be used (and how we would
>> document things).
> 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.
>
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.
Maybe we can hide the additional options behind an advanced menu? Or a special
setting?
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.
I can certainly work on that part of the code (as that requires UI changes in
QML)
> 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.
>
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.
That's why I think it should be hidden by default.
>> 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.
> 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.
>
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).
This no longer appears to work. Something for me to play with :-)
> 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.
>
> 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.
>
Cool
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.
/D
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
