Android and libusb

[Dirk Hohndel]

> On Sep 30, 2019, at 12:05 AM, Anton Lundin <glance at acc.umu.se> wrote:
>> 
>> 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...
> 
> 
> Yea, its a quite complex call chain, but I thin it can be simplified to
> filling out struct libusb_device and calling usbi_connect_device on
> those.
> 
> UsbManager.getDeviceList() gives us enough to fill in the libusb_device
> structs.

Hmm - I hadn't planned to go that route. We already have the intent handling
that talks to us when a device is connected. And that gives us the one USB
device that we need to talk to - so why even get that list?

Look at the code here:
https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/android-mobile/src/org/subsurfacedivelog/mobile/SubsurfaceMobileActivity.java#L90 <https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/android-mobile/src/org/subsurfacedivelog/mobile/SubsurfaceMobileActivity.java#L90>

So I have a UsbDevice structure already
https://developer.android.com/reference/android/hardware/usb/UsbDevice <https://developer.android.com/reference/android/hardware/usb/UsbDevice>

But then how do I go from that to fill the libusb_device?
 
>> 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...)
> 
> Do you have a link to that branch?
> 
> https://github.com/glance-/libusb/commit/50e2690f27a04011c4eae215d8b100851278e544
> Is basically the libusb patch needed, the rest of the code needed would
> end up in the callback subsurface would provide.
> 
> I had a half written variant of such code somewhere but I can't find it
> right now.


I have something slightly more hacky in my version, but yeah, same idea.
It's that other half of the code that I'm struggling with.

I started this response email, wanting to send you a dump of what we already
log about the new device that's connected after we get the intent, but unfortunately 
I can't seem to revive my my last FTDI dive computer. It had been super flaky the 
last couple of times I played with it, but I now can't turn it on anymore.

If you connect your FTDI dive computer, we are logging a string representation
of the UsbDevice structure 

https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/core/android.cpp#L179 <https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/core/android.cpp#L179>

Do you have code that can convert that into a libusb_device structure? 
Because if you have that code, I think I can piece the rest together. Well,
maybe. If I had a working FTDI dive computer to test with...

What's the cheapest FTDI dive computer one can buy these days? Or does 
someone have one lying around that they don't need anymore? Like an old
style Suunto with a download cable?

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