On 2014-03-03 15:41, Dirk Hohndel wrote:
On Mon, 2014-03-03 at 15:24 +0100, Anton Lundin wrote:
For subsurface we don't need no stinking jni wrappers, we run real
code! =)
Correct. As native app we can call native code directly.
I'm aware of that, but I'm thinking a bit broader. Subsurface isn't the
only application using libdivecomputer :-)
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.
Yes, being able to get rid of the bluetooth emulation would be really
nice.
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.
What I have been thinking about is to turn the serial code into an
interface, and then we can have multiple implementations of that
interface. The current serial backend would be one of those
implementation. For the application, instead of passing the device node
for the serial port to the dc_device_open() function, it would create an
instance of the new interface and pass that. Then the application can
pick the right implementation. For Linux, Windows and Mac OS X, the
default implementation would be sufficient.
Thus in the application, the code would look something like this:
dc_serial_t *serial = NULL;
dc_device_t *device = NULL;
/* Create an instance of the serial port interface.
* Here I just use the default implementation, but
* that can of course be replaced with another one. */
dc_serial_open(&serial, devname);
/* Open a connection to the device. */
dc_device_open(&device, ..., serial);
/* Close the connection. */
dc_device_close(device);
dc_serial_close(serial);
The downside is the extra code on the application side. Although a nice
side effect is that it would also solve the enumeration problem. Right
there is a function to enumerate serial ports, but because the serial
code is private, applications can't really use it.
Jef
_______________________________________________
subsurface mailing list
[email protected]
http://lists.hohndel.org/cgi-bin/mailman/listinfo/subsurface
