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 <cha...@charno.ch >> <mailto: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... 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@subsurface-divelog.org > http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface