On 01.03.20 22:09, Anton Lundin wrote: > On 01 March, 2020 - Dirk Hohndel wrote: > >>> On Mar 1, 2020, at 10:32 AM, Christof Arnosti <[email protected]> wrote: >>> >>> Soo... I own a Mares Puck Pro, and I want to use Subsurface Mobile to >>> transfer dives from the computer. >>> >>> I found that currently for android a libftdi / libusb-based driver >>> (serial_ftdi.{c,h}) is available for FTDI based serial converters. >> And by 'available' we mean: >> >> IT DOESN'T WORK ON BASICALLY ANY ANDROID DEVICE >> >> This works on some old Android devices. And it can be hacked to work >> on rooted Android devices. But for 90+% of our users this doesn't work >> at all. As you point out below, we have made attempts to fix this and >> admittedly I have spent way too much time on that already... there's even >> a PR on GitHub where I try to make this work but I got stuck... >> >>> The Mares USB cable uses a cp210x based converter. >>> >>> In the FAQ at subsurface-divelog.org I found the following paragraph: >>> >>> "Subsurface-mobile on Android and dive computers with FTDI download cables >>> >>> Subsurface-mobile on Android (but not on iOS beacuse of hardware >>> limitations) is designed to be able to download from some dive computers >>> using FTDI based download cables and a USB OTG adapter. Unfortunately, >>> there is an issue with the way in which Subsurface-mobile opens USB >>> devices on Android. We do this from “native code”, not from a Java >>> application. And while many Android phones allow this method of >>> accessing OTG devices, an (apparently increasing) number of devices >>> don’t. On these Android devices the attempt to download from >>> divecomputers via the USB OTG adapter always fails. We understand in >>> theory how to work around this problem, but haven’t found the right >>> developer who could volunteer their time to help us fix the issue." >> I need to update the FAQ. Initially it was indeed "some" where it failed. >> Now it is basically "all". >> >>> Well... Maybe I want to be this person, and for sure I want to be the >>> person to add cp210x support. I would be glad if somebody could explain >>> what the proposed workaround mentioned in the paragraph would be? >> Paging Anton - but I know that he has explained it on this mailing list a >> few times in the past, so googling for posts from him with Android in the >> title might get you to the right one. >> >>> While recherching I found the git repo >>> https://github.com/mik3y/usb-serial-for-android containing a collection >>> of USB serial converter drivers for android. The drivers are licensed as >>> LGPL2.1 (GPL compatible) and are written in Java using the Android USB >>> Host API. >>> >>> From the code that I have read I have two possible ways to go forward: >>> >>> First (my preferred way): >>> Directly use the java code from usb-serial-for-android, write a small >>> abstraction class in java to provide a convenient interface, and a small >>> class in c to call the java abstraction class (similar to what >>> serial_ftdi does with libftdi). >>> >>> Pros: >>> - This could act as a generic way to access USB serial-based >>> divecomputers, including FTDI ones. >>> - Using the official Android USB Host API means that the chance for >>> support on different phones is quite high. >>> >>> Cons: >>> - More Platform-Specific, non-C code. >>> >>> Second: >>> Translate the CP210x driver from usb-serial-for-android to C code using >>> libusb. >>> >>> Pros: >>> - C-Code >>> >>> Cons: >>> - More work >>> - Chipset-Specific >>> >>> What do you think about this two possibilities? I would prefer to >>> directly use usb-serial-for-android, since for the desktop application >>> there is already existing support for the different USB-Serial chipsets, >>> so portability of the code for non-android builds is not that important >>> in my eyes. With this subsurface would also only need one >>> android-specific driver implementation for different chipsets. >>> >>> I would love to hear your toughts and maybe get some additional pointers >>> I could use while developing. I would mainly work on the task in the >>> next week, since I have holidays and the event I wanted to go to was >>> canceled due to the corona virus. >> Since Anton knows more about this than anyone else on this list (or at >> least I think so), I really hope that tagging him directly on the To: line >> will >> help to catch his attention. It seems much more useful to have him respond... >> >> Thanks for looking into this. It would be amazing to see this fixed. I had >> basically given up hope... > There's bit quite a bit written during the years about this. It can all > be found in the archives. > > usb-serial-for-android is one solution. It's a bit harder to test, > because it's can't be tested outside of android but it supports a bunch > of different devices and it only uses official api's. > > I haven't seen any libusb (or similar abstractions) based cp210x > userspace drivers. Sure, the code can be written, but I think its way > too much work to be worth the effort. > > > I'd suggest you look into writing a custom-serial glue-layer which uses > jni to call into usb-serial-for-android. I'd suggest looking at the > QtAndroidExtras/QAndroidJniObject layer which makes jni way less > horrible. > > > I've bin hoping to get around to doing some of this, but due to personal > reasons I haven't had the time and energy. I'm glad to see you take up > this work and get it done. > > > //Anton
Hi Anton, Hi Dirk, Thank you very much for the pointers! So from a coding perspective I think the tasks became quite clear: - Check the pull-request for android libusb-compatibility at https://github.com/Subsurface-divelog/subsurface/pull/2309, and finish implementing the functionality to get the USB fd by JNI. This will fix the existing serial_ftdi implementation, and libusb-based dive computers. - Import usb-serial-for-android (probably in the build.gradl configuration to keep things easy), and write a glue-layer using JNI. Thanks for the info about QAndroidJniObject! - Probably remove the serial_ftdi implementation if the usb-serial-for-android one works fine. Best regards Christof
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
