On Mon, 2014-03-03 at 15:24 +0100, Anton Lundin wrote: > > The serial api may not be exposed to the java world, but it is certainly > > usable from native code. As far as I know, you only needed a few minor > > tweaks to compile libdivecomputer for Android [1]. Once we have that, an > > Android application can simply use libdivecomputer, and there is no longer a > > need to have access to the serial api directly. For a java applications a > > JNI wrapper will of course be necessary. > > > [1] > > https://github.com/glance-/libdivecomputer/commit/0f7ef245a9d0c8be533e5045b475e51acacec520 > > Yepp, i wrote that code =) > > But its good to reference it form there, for the rest of the world and > for the archives. > > For subsurface we don't need no stinking jni wrappers, we run real code! =)
Correct. As native app we can call native code directly. > > The main problem are indeed the kernel drivers. It's a pity enabling the > > usb-serial kernel modules on an Android phone is non trivial (compared to > > installing an application). Because that would be the least amount of work: > > the kernel divers already exist and just needs to be enabled. Re-writing the > > usb-serial drivers in userspace, will require a different driver for every > > type of chip, and there are at least 4 of them (ftdi, prolific, silabs, > > cdc-acm). > > Kernel drivers is a no-go if you would like to support anything but > hand-built roms. Not even CM ships any kernel-modules. > > I've seen libusb based drivers for at least ftdi and acm based things, > and ftdi is what my dc's use so I'm happy with atleast that =) ftdi is one of the most common ones. But there are a few more. And of course there are a few divecomputers that use different protocols. Let's forget for a moment about the iRDA ones... but there's Bluetooth (shouldn't be too hard - Android does have a Bluetooth stack... all we need is to use that directly instead of the serial emulation that current libdivecomputer still uses), some use full USB - with libusb available, that should be possible, too. And then of course there is the UEMIS that simulates a FAT filesystem. That should be reasonably straight forward as well. > > Assume we manage to implement the necessary userspace driver, how do we > > integrate this nicely into libdivecomputer? This a question for which I have > > no good answer at the moment. Right now, an application simply passes the > > device node (e.g. /dev/ttyXXX), and libdivecomputer takes care of opening > > the serial port. This works well because there is just one driver for each > > platform. But once we have multiple serial drivers, we'll also need some > > mechanism to select the right driver. > > From what I've understod about usb-devices on android is that you need > to call a user consent dialog from your app (java thingie, but you can > call into java from c++ so thats not a problem), and then the system > chown/setfacl the device so your app have rights to access it. > > My guess would be to have a way to map all the serial calls in > libdivecomputer to external functions that can be implemented outside > libdivecomputer, for ex in the app that interfaces with the rest of the > world. > > From the top of my head that would be building libdivecomputer without > any serial_*.c or maybe a serial_external.c that implements all the > things that libdivecomputer needs, that can be enabled compile time. That sounds like the right approach. > > >I don't know now the Gsoc ideas list work, but his might be a interesting > > >task to put on that list. A good scope would probably be to create a > > >downloader-only port of subsurface for the time being. > > > > I think this is a very interesting and challenging idea indeed. > > I hope that someone bites the bullet and starts hacking on this one =) You and me both. As I said before - this is the GSoC idea that I am most interested in seeing implemented. /D _______________________________________________ subsurface mailing list [email protected] http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
