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

Christof Arnosti charno at charno.ch
Fri Mar 6 14:00:37 PST 2020


Hi Dirk,

Am 06.03.20 um 20:02 schrieb 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... :-)
I'm very happy to see that it doesn't just work on my computer! :-)
>
>> On Mar 6, 2020, at 8:44 AM, Christof Arnosti <charno at charno.ch
>> <mailto: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...
Me too! And finally I found the time to do it.
>
>>>>> 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)
A special "advanced" option would be nice for sure!
>
>> 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.
Agree.
>
>>> 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 :-)

Hmm... This works for me? At least the download screen gets opened,
without details since the VID/PID is just some generic CP2102 pair.

While testing I did just abort the popup and open the computer manually.
This is a habit since I first startet working with your libusb-branch
and then I wasn't sure if libusb did somehow break the androd USB host
stack...

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

Best regards
Christof

>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20200306/9d4bd98e/attachment-0001.html>


More information about the subsurface mailing list