Re: [Libusbx-devel] [libusbx] Enable building on all Android architectures, including MIPS. (#133)

2013-08-20 Thread tobygray
I agree with the architecture change, "all" is a far better choice.

The -llog changes are slightly less straightforward though. The sample and test 
applications for Android don't directly call any Android logging code, so 
shouldn't need to have liblog.so added to their NEEDED sections.

Comparing the linker line from armeabi:
```
Executable : dpfp
~/Android/android-ndk-r8e/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++
 -Wl,--gc-sections -Wl,-z,nocopyreloc 
--sysroot=~/Android/android-ndk-r8e/platforms/android-3/arch-arm 
./obj/local/armeabi/objs/dpfp/__/__/examples/dpfp.o -lgcc 
./obj/local/armeabi/libusb1.0.so -no-canonical-prefixes  -Wl,--no-undefined 
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now   -lc -lm -o 
./obj/local/armeabi/dpfp   
Install: dpfp => libs/armeabi/dpfp
```
to the linker line for mips:
```
Executable : dpfp
~/Android/android-ndk-r8e/toolchains/mipsel-linux-android-4.6/prebuilt/linux-x86_64/bin/mipsel-linux-android-g++
 -Wl,--gc-sections -Wl,-z,nocopyreloc 
--sysroot=~/Android/android-ndk-r8e/platforms/android-9/arch-mips 
./obj/local/mips/objs/dpfp/__/__/examples/dpfp.o -lgcc 
./obj/local/mips/libusb1.0.so -no-canonical-prefixes  -Wl,--no-undefined 
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now   -lc -lm -o ./obj/local/mips/dpfp
~/Android/android-ndk-r8e/toolchains/mipsel-linux-android-4.6/prebuilt/linux-x86_64/bin/../lib/gcc/mipsel-linux-android/4.6/../../../../mipsel-linux-android/bin/ld:
 warning: liblog.so, needed by ./obj/local/mips/libusb1.0.so, not found (try 
using -rpath or -rpath-link)
./obj/local/mips/libusb1.0.so: undefined reference to `__android_log_write'
```

The linker lines for the two appear to have the same options. I suspect that 
this is actually a bug in the mips toolchain in the NDK not invoking the linker 
in the same way as other toolchains.

An alternative would be to tell the linker to be happy to have unresolved 
symbols in shared library dependencies (APP_LDFLAGS := 
-Wl,--allow-shlib-undefined), but that still issues warnings for the MIPS 
builds and would let through other issues.

Instead of adding all the extra LDFLAGS to all the mk files I'd suggest just 
adding APP_LDFLAGS := -llog to Application.mk along the lines of:
```
# Workaround for MIPS toolchain linker being unable to find liblog dependency 
of shared object
# in NDK versions at least up to r9
APP_LDFLAGS := -llog
```

Could you update your pull request to use APP_LDFLAGS? If not then I'm happy to 
generate a new patch which uses it.

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/133#issuecomment-22935387
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


Re: [Libusbx-devel] [libusbx] android support (#132)

2013-08-20 Thread Toby Gray

On 20/08/13 05:44, Anton Smirnov wrote:

2013/8/19 Toby Gray mailto:toby.g...@realvnc.com>>

On 18/08/13 13:01, Anton Smirnov wrote:


Android can return file descriptor for native code:

http://developer.android.com/reference/android/hardware/usb/UsbDeviceConnection.html#getFileDescriptor()


Does libusbx support it?



Not currently. It would be quite a change to be able to support it
as libusb would need to map the open file descriptor back to a bus
and device, which would be hard.


Not sure that it's true but anyway. Behind the scene libusb get's file 
descriptor as int and holds it in internal structure. So android just 
returns exactly the same int file descriptor, so there is no need to 
open file using liusb_open() - we just need to inject ready file 
descriptor.


For the Linux backend, which is the backend currently used on Android, a 
libusb_device is not a file descriptor. Part of a libusb_device_handle 
is a file descriptor, but a libusb_device_handle also includes a 
reference to a libusb_device. A libusb_device accesses sysfs entries for 
some libusb API calls, e.g. libusb_get_configuration: 
https://github.com/libusbx/libusbx/blob/master/libusb/os/linux_usbfs.c#L564




An alternative choice would be to add an Android backend which
makes use of JNI to invoke the UsbDeviceConnection APIs, although
that would be equally tricky.


This is already done in this project (see introduced 
voidusb_device_set_open_close_func(..)

https://github.com/keesj/librtlsdr-android/blob/android/include/libusb.h


While usb_device_set_open_close_func(..) is clearly suitable for the 
librtlsdr-android project, I would feel that it isn't suitable as an API 
for addition to libusb. I'm not a maintainer of libusb so my opinion 
isn't important, but I would send strongly worded emails about it :)


In my mind the correct solution would be to add an Android backend which 
invoked the appropriate APIs via JNI. In fact I've now added that to my 
TODO list as it'll be an interesting thing to look into, but that 
probably means many years before I actually get around to it!




What are you trying to do?


I'm trying to communicate with usb device that uses FTDI chip on Android.


Sorry, I should have been clearer in my question. It sounds to me like 
you are writing native code to use libftdi to talk to an FTDI chip and 
libftdi uses libusb. Is that correct?





If you want to get a list of devices for use with libusb you
should call the libusb API for it ( libusb_get_device_list). If
you want to use the android.hardware.usb.* APIs to access the
device you should use those APIs.


This already works for me using libusb_get_device_list().
The problem is that any request fails with -32 error even if request 
data is exactly the same as required.


I didn't want to assume that this is the same issue you were talking 
about on the libusb mailing list, but it sounds like it is. Do you have 
access to a USB bus analyser to check if the request is ever making it 
onto the bus? If not then is there any chance of you being able to put a 
custom kernel on the Android device to get a usbmon trace?


The same code works great for CDC-devices so general approach is 
working for me.


Does libftdi support CDC-devices? Or have you written your own code 
which calls libusb APIs to talk to CDC-devices?


libftdi is a small lib to create vendor-specific usb requests (to set 
baud rate, line controls, etc), so it does not make sense in general.
the problem is that it works over libusb for usb interaction and it's 
libusb error, not libftdi.



Ok.

Regards,

Toby
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


Re: [Libusbx-devel] [libusbx] Enable building on all Android architectures, including MIPS. (#133)

2013-08-20 Thread Andrew Fernandes
Absolutely it's an NDK bug. I'm guessing that the MIPS toolchain does not get a 
good workout in the wild, hence is more buggy than other platforms.

I don't like the idea of using `--allow-shlib-undefined` unless it is really 
needed; most people usually always want all their symbols defined. Allowing 
undefined symbols by default is probably going to be painful for "normal" 
users; it's such a powerful semantic change that I think it should be "experts 
only".

Also, I had no idea that there was an APP_LDFLAGS flag, and I will regenerate 
my patch to use it. Thanks for that!

Between make, autotools, cmake, bjam, gyp, scons, and ndk-build... too many 
build systems to keep in my head. I had _thought_ I'd read the NDK docs more 
closely than that... but too many build systems to remember with too little 
brain-resources... :-)

Will regenerate my patch sometime today. Cheers!

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/133#issuecomment-22945518
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


Re: [Libusbx-devel] [libusbx] Enable building on all Android architectures, including MIPS. (#133)

2013-08-20 Thread Andrew Fernandes
Closed #133.

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/133
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


[Libusbx-devel] [libusbx] Enable building on all Android architectures, including MIPS (working around an MIPS NDK linker bug). (#134)

2013-08-20 Thread Andrew Fernandes
As per previous pull request.

Cheers!
-Andrew.
You can merge this Pull Request by running:

  git pull https://github.com/adfernandes/libusbx master

Or you can view, comment on it, or merge it online at:

  https://github.com/libusbx/libusbx/pull/134

-- Commit Summary --

  * Enable building on all Android architectures, including MIPS.
  * Change Android toolchain and platform version.
  * Merge branch 'master' of https://github.com/libusbx/libusbx
  * Revert "Change Android toolchain and platform version."
  * Revert "Enable building on all Android architectures, including 
MIPS."
  * Enable building on all Android architectures, including MIPS (working 
around an MIPS NDK linker bug).

-- File Changes --

M android/jni/Application.mk (7)

-- Patch Links --

https://github.com/libusbx/libusbx/pull/134.patch
https://github.com/libusbx/libusbx/pull/134.diff

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


Re: [Libusbx-devel] [libusbx] Enable building on all Android architectures, including MIPS (working around an MIPS NDK linker bug). (#134)

2013-08-20 Thread Ludovic Rousseau
Can you merge all your 6 commits into only 1 please?

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/134#issuecomment-22958234
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


Re: [Libusbx-devel] [libusbx] Enable building on all Android architectures, including MIPS (working around an MIPS NDK linker bug). (#134)

2013-08-20 Thread Andrew Fernandes
What?! Six patches... obviously I still have a lot to learn about git. I 
usually work with svn and hg... git's nice, but...

Thanks (again!) for the pointer; I think I did the rebase correctly...

Cheers,
-A.

---
Reply to this email directly or view it on GitHub:
https://github.com/libusbx/libusbx/pull/134#issuecomment-22962487
--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


Re: [Libusbx-devel] [libusbx] Enable building on all Android architectures, including MIPS (working around an MIPS NDK linker bug). (#134)

2013-08-20 Thread Nathan Hjelm
git is much more powerful than hg. What you will probably want to do is 
something like this:

git rebase -i HEAD~6  (rebase the last 6 commits)

And use the squash command to squash the commits into 1.

-Nathan

On Aug 20, 2013, at 11:32 AM, Andrew Fernandes  wrote:

> What?! Six patches... obviously I still have a lot to learn about git. I 
> usually work with svn and hg... git's nice, but...
> 
> Thanks (again!) for the pointer; I think I did the rebase correctly...
> 
> Cheers,
> -A.
> 
> —
> Reply to this email directly or view it on GitHub.
> 
> --
> Introducing Performance Central, a new site from SourceForge and 
> AppDynamics. Performance Central is your source for news, insights, 
> analysis and resources for efficient Application Performance Management. 
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
> libusbx-devel mailing list
> libusbx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libusbx-devel

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel


Re: [Libusbx-devel] Doing a libusbx 1.0.17-rc1 release

2013-08-20 Thread Xiaofan Chen
On Mon, Aug 19, 2013 at 11:34 PM, Hans de Goede  wrote:
> Hi All,
>
> I was hoping someone else would take care of this while I was otherwise
> occupied, but alas ...
>
> It also seems we've accumulated a little bit more then I was hoping for
> when I suggested to do a quick bugfix release a while back, again alas ...
>
> Since we've accumulated quite a bit already, it makes sense to me to
> drop the quick bugfix release plan, and instead incorporate some
> other outstanding patches too, specifically I'm thinking about adding:
>
> "[Libusbx-devel] Improving linux hotplug disconnect" (Charles Dickens)
> "[PATCH] Clarify alignment requirements for the control transfer
>   buffer" (Paul Fertser)
> "openbsd backend updates" (Martin Pieuchot)
> "[PATCH] Android: Add further documentation to Android README file" (Toby 
> Gray)
>
> My plan is to merge these into master tomorrow, then I'll give people
> until Thursday evening to test things from git-master and I'll
> release 1.0.17-rc1 on Friday.
>

Sounds good.

Milestone updated here:
https://github.com/libusbx/libusbx/issues/milestones

Feel free to edit if you think we need to mention more things there.



-- 
Xiaofan

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel