Android and libusb
Dirk Hohndel
dirk at hohndel.org
Mon Sep 30 08:40:31 PDT 2019
Apparently my OSTC was just as tired as I was (I sent that last email at 3:30am).
Replacing the (new) AA Alkaline with an (old) Saft battery was enough to give it the
boost to start up again.
So for now I'm back in business with a "working" FTDI dive computer (the DC has
been broken for a long time, but it at least responds on FTDI and therefore I can
test any FTDI connection issues)
> On Sep 30, 2019, at 3:30 AM, Dirk Hohndel <dirk at hohndel.org> wrote:
>
> 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...
So this is a textual representation of what we get:
UsbDevice[mName=/dev/bus/usb/001/002,mVendorId=1027,mProductId=24577,mClass=0,mSubclass=0,mProtocol=0,mManufacturerName=HW,mProductName=HeinrichsWeikamp OSTC3,mVersion=6.00,mSerialNumber=A4SHCQSJ,mConfigurations=[\nUsbConfiguration[mId=1,mName=null,mAttributes=128,mMaxPower=50,mInterfaces=[\nUsbInterface[mId=0,mAlternateSetting=0,mName=HeinrichsWeikamp OSTC3,mClass=255,mSubclass=255,mProtocol=255,mEndpoints=[\nUsbEndpoint[mAddress=129,mAttributes=2,mMaxPacketSize=64,mInterval=0]\nUsbEndpoint[mAddress=2,mAttributes=2,mMaxPacketSize=64,mInterval=0]]]]"
What we need is
struct libusb_device {
/* lock protects refcnt, everything else is finalized at initialization
* time */
usbi_mutex_t lock;
int refcnt;
struct libusb_context *ctx;
uint8_t bus_number;
uint8_t port_number;
struct libusb_device* parent_dev;
uint8_t device_address;
uint8_t num_configurations;
enum libusb_speed speed;
struct list_head list;
unsigned long session_data;
struct libusb_device_descriptor device_descriptor;
int attached;
PTR_ALIGNED unsigned char os_priv[ZERO_SIZED_ARRAY];
};
bus/port should be 1/2
what do I use as parent_dev?
what's the device_address and num_configurations
I assume that the list is something that libusb maintains internally?
And then of course I still need a device_descriptor - which has plenty of other fields to fill...
struct libusb_device_descriptor {
/** Size of this descriptor (in bytes) */
uint8_t bLength;
/** Descriptor type. Will have value
* \ref libusb_descriptor_type::LIBUSB_DT_DEVICE LIBUSB_DT_DEVICE in this
* context. */
uint8_t bDescriptorType;
/** USB specification release number in binary-coded decimal. A value of
* 0x0200 indicates USB 2.0, 0x0110 indicates USB 1.1, etc. */
uint16_t bcdUSB;
/** USB-IF class code for the device. See \ref libusb_class_code. */
uint8_t bDeviceClass;
/** USB-IF subclass code for the device, qualified by the bDeviceClass
* value */
uint8_t bDeviceSubClass;
/** USB-IF protocol code for the device, qualified by the bDeviceClass and
* bDeviceSubClass values */
uint8_t bDeviceProtocol;
/** Maximum packet size for endpoint 0 */
uint8_t bMaxPacketSize0;
/** USB-IF vendor ID */
uint16_t idVendor;
/** USB-IF product ID */
uint16_t idProduct;
/** Device release number in binary-coded decimal */
uint16_t bcdDevice;
/** Index of string descriptor describing manufacturer */
uint8_t iManufacturer;
/** Index of string descriptor describing product */
uint8_t iProduct;
/** Index of string descriptor containing device serial number */
uint8_t iSerialNumber;
/** Number of possible configurations */
uint8_t bNumConfigurations;
};
Some of those are obvious, others... not so much.
I'll keep hacking on this and see how far I get. Any insights and pointers in the meantime would be welcome
/D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20190930/f15a9fc5/attachment-0001.html>
More information about the subsurface
mailing list