Subsurface Mobile: Adding mares USB (cp210x) support; how to proceed

[Dirk Hohndel]

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 <charno at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200306/f3071090/attachment.html>