Android and libusb

[Dirk Hohndel]

As I try to catch up with my large backlog of email...


> On Sep 23, 2019, at 7:45 AM, Anton Lundin <glance at acc.umu.se> wrote:
> 
> First of all, I'd just try to run our current code on a libusb
> containing:
> https://github.com/libusb/libusb/commit/2f3bc98b0d0f4766496df53c855685a5f0e5e7cf <https://github.com/libusb/libusb/commit/2f3bc98b0d0f4766496df53c855685a5f0e5e7cf>

That part is easy. v1.0.23 is what we want to switch to.
But of course that breaks our current approach which works on SOME devices, 
so we can't do that until the second part below is done.

> My preferred solution here would be to patch linux_scan_devices to have
> a callback into subsurface which could do the scanning against java code
> here, and fill up the libusb data structures. I have some unfinished
> code working on this path, and its basically the same approach as in our
> "open" patch. The upside with this is that it keeps all our non ftdi
> libusb using backends in libdivecomputer still working.

I honestly think that this is the right approach. I started staring at the code and
as expected the more I look the more I worry that I will get started and never
get finished. My challenge is that I don't understand the libusb data structures.
So which part of the libusb_context do I need to populate from the information 
we get back from the JNI calls? That structure has quite a few members that I 
have no idea what to do with. And reading the Linux code that initializes this 
structure in the regular case really doesn't make me any smarter as just trying 
to follow the code is making me break out in a rash...

I have a branch for this but I don't recommend that anybody hope that I'll make
a lot of progress. I'm just dealing with way too many other issues that people
are equally desperately hoping for me to work on (like the UI issues and crashes
on Android that I think the latest beta finally addresses - which means I need to
make another release...)

/D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20190929/94382931/attachment.html>