libftdi based subsurface communication...

[Anton Lundin]

Or, why does selinux always get in the way of me doing fun tings?

Anyhow...


Last night i wacked together some support for libftdi based
communication with the custom serial based code, by re-purposing some of
Venkatesh old code.

The custom serial code is clearly "streamlined" to support rfcomm, so
there are some operations missing for "real" serial, like setting
baud rate, setting rts/dtr, sending break's and so on. This will need
some refactoring to remove the current differences between the "native"
serial and a custom serial, and implement things like these.


Otherwise, i found a idea on how to handle libusb things on android[1]
and reworked that into a quite simpler solution[2, 3].

That way we don't need to jump hoops and patch every library on the way
just to work around Android NDK vs. "real" Linux incapabilities
surrounding usb devices, and can just patch the relevant bits in libusb.


I've managed to get the libftdi based code to download stuff off my
OSTC3 on my laptop, but some selinux bits gets in the way of me doing it
on Android. Somehow ftdi_new() triggers some libusb code which tries to
probe for devices and gets EACCES with selinux enforcing Android.


Anyhow, all the bits can be found at [4] for anyone who would like to
giggle over how ugly that code currently are, or try to figure out
what/how/why something in ftdi_new() fails.


I'm going road-tripping for a week so theres not going to happen much on
my end but hey, go mental and clean my mess up if anyone would like =)

 
//Anton


1. https://github.com/PointCloudLibrary/mobile/blob/master/3rdparty/android/patches/libusb.patch
2. https://github.com/glance-/subsurface/commit/5b1412effdb9a83ec3fd1398bfaa7f8caa4adba6.patch
3. https://github.com/glance-/subsurface/commit/a4287e8ea363114bcdfb26e0824d7c502fb12322.patch
4. https://github.com/glance-/subsurface/tree/libftdi_wip



-- 
Anton Lundin	+46702-161604