new releases

Anton Lundin glance at acc.umu.se
Sat Jun 16 00:26:34 PDT 2018


On 16 June, 2018 - Dirk Hohndel wrote:

> 
> > On Jun 16, 2018, at 3:45 PM, Thomas Fänge <thomas.fange at gmail.com> wrote:
> > 
> > HI all!
> > 
> > Dirk wrote:
> > 
> > >> What other bugs do we know of for either desktop or mobile?
> > 
> > What I would wish for, is that using a DC with OTG cable on the mobile version should work again. Apparently this worked before 4.7.5, and seems to be related to opening a FTDI port on Android (bug #1240).
> 
> I don't have a single Android device where our way of doing this ever worked (and I have six different Android tablets and phones). So I can't help with even testing this.
> What we really need is to fix libusb to be able to open the port.
> It seems that there are two approaches that people have been working on, if anyone with an Android device and an FTDI dive computer wants to give it a try:
> 
> This is the first one - that hasn't seen much activity in the last two years.
> 
> https://gitlab.com/madresistor/libusb/commits/android <https://gitlab.com/madresistor/libusb/commits/android>
> 
> This one seems more active, but again, someone would have to spend some quality time on understanding how this would work from a Subsurface-mobile perspective.
> 
> https://github.com/libusb/libusb/pull/242 <https://github.com/libusb/libusb/pull/242>

I really don't like either of those two approaches. Both of them require
you to rewrite all the libusb-open code, which is going to be a pita for
us. We don't call libusb directly, we just call libdivecomputer or
libftdi which calls into libusb for us.


The approach I've worked on is to replace the discovery code in libusb
with something which jni's into android to provide the list of devices.
That way we still just modify libusb and let all the callers think
they're talking to a bog standard libusb on a normal system.

libusb is old egnough to have multiple backends for talking to different
generations of the usb interfaces so its resonably straight forward to
plumb in a "custom-android" backend which jni's into android filling in
the right data structures.

Somewhere I have some half ass first take at implementing this that
doesn't work.


Another approach to solve the FTDI issue in specific is to replace the
serial_ftdi.c code all together with a implementation using the official
android ftdi driver (d2xx.jar) and doing jni calls into it. The downside
with this is that we would drop support for all pure libusb devices,
like the eon steel, and so on.


//Anton


-- 
Anton Lundin	+46702-161604


More information about the subsurface mailing list