Re: Very basic and fundamental question about the Neo
[...] Look at the answer from Mickey on the post with subject 'Neo faulty?' from Jan, 1st. It explains what you're looking for. no, it doesn't. It only explains power leaking when Neo is off problem. Nicolas is asking why the Neo sucks the power so fast when it is on. Nicolas check this one out: http://wiki.openmoko.org/wiki/Neo1973_GTA01_Power_Management The page is saying that the power management software is in very beginning stage. Lets hope that this is only a software and no another hidden bug in hardware. regards, Piotr ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Compiling problems
Hi Alberto, Alberto Garfagnini wrote: As you can see from the detailed output (posted at the URL: http://pastebin.ca/842530), the compile procedure complains about openmoko-terminal2 which cannot be found in the repository. Build works fine for me. My local.conf looks like this MACHINE = fic-gta01 DISTRO = openmoko BUILD_ARCH = i686 INHERIT += rm_work make update-makefile make clean make setup update all Cheers, Marc ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New screen?
Matthew S. Hamrick wrote: Actually... I'm pretty sure this is the same screen we're using on the myPhone project, and it's actually quite usable. The 4.3 480x272 has the advantages that: * it's a tad cheaper than the 3.8 640x480 screen, way cheaper in volume * it has slightly better color * there seems to be a metric butt-load of them in the supply chain * it is widescreen (16x9) :P I finally got mplayer working on my myPhone (albeit only for a few seconds at a time), and it's actually quite a nice screen for videos. not that I don't have enough projects, but google is giving a lot of stuff that I don't think is the myphone project - I know it is a bit off topic for this list, but could you send me a link to the 'home'? Much appreciated. josh ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Toolchain alpha release
John Lee wrote:
http://downloads.openmoko.org/toolchains/openmoko-x86_64-arm-linux-gnueabi-toolchain.tar.bz2
I found one little problem with setup-env: when I try to build u-boot
or the kernel with it, ld fails due to the LDFLAGS, which are defined
as follows:
export LDFLAGS=-L${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib
-Wl,-rpath-link,${OMTOOL_DIR}/arm/arm-angstrom-linux-gnueabi/lib -Wl,-O1
Now, both u-boot and kernel invoke ld directly and not through cc
or gcc. Unfortunately, ld doesn't understand the option -Wl, so
it fails.
We couldn't just omit the -Wl, since gcc doesn't understand -rpath-link,
and we wouldn't want to unconditionally compile with -O1 anyway. But in
what scenario do we actually need to set these flags ? As far as I can
tell, just plain use of arm-angstrom-linux-gnueabi-gcc or
arm-angstrom-linux-gnueabi-ld gets all the search paths right.
If we do have to set LDFLAGS, I can think of the following ways to work
around breaking u-boot and kernel builds:
1) don't use setup-env but define only PATH (which is all kernel and
u-boot really need anyway)
2) make LDFLAGS= ...
3) LDFLAGS= make ...
What I don't like about 2) and 3) is that they make an already too long
command even longer, and that this may let more environment variables
slip through and cause subtle breakage. 1) looks much safer.
Would you agree that, if we have to keep LDFLAGS in setup-env, 1) best
reflects proper use of the toolchain in these cases ? If not, how would
you propose to solve this problem ?
- Werner
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
FW: Moseycode
Thought this blog post might interest a few people on the openmoko list as well, although the Moseycode application is designed for the Android OS there's no reason why it should be possible on OpenMoko as well. Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] +1-212-203-4357 Ph +61-2-9016-5642 (Sydney in-dial). From: Dean Collins Sent: Saturday, 5 January 2008 4:46 PM To: '[EMAIL PROTECTED]' Subject: Moseycode If you want to see the 3d cube video mentioned below you'll need to go to my blog at www.collins.net.pr/blog Otherwise I know this is going to interest some of you on this list who have been involved with various 2d code projects. If anyone reading this runs a marketing company/interactive agency and would like to understand how/why this is pretty hot stuff contact me to arrange a briefing session, I've got a commercialization concept that will blow any client you pitch to out of the water (FMCG preferred). Regards, Dean Collins Cognation Pty Ltd [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] +1-212-203-4357 Ph +61-2-9016-5642 (Sydney in-dial). MoseyCode So I was hanging out this cold and dreary Saturday afternoon and being the geek that I am... :)... was just browsing around catching up on 2D bar coding developments. I happened to stumble across this link about a new 2D encoding standard called MoseyCode (in the first breath I went - Oh brother just what we need yet another 2D encoding standard.even if he Tom Gibra is releasing it without any patent encumberances). Have a read below http://thenextweb.org/2008/01/05/moseycode-a-new-chapter-in-mobile-barco ding/ What was interesting however is this Although Peter's blog post doesn't explain it very well what you are seeing is the the introduction of a 3rd axis. Instead of 2d codes just having X Y axis information, the Moseycode can tell when the information is 'tilted' and introducing a Z axis. The Cube in the video above is being superimposed on the Moseycode Card itself, allowing for a 'visual superimposement' on the Android display of any object you decide to 'upload' (I have questions about this as per my post reply below-so looking forward to understanding the limitations). Now whilst I have very big concerns about the 'functionality' of this and the usefulness in a number of situations about this - there are certain areas where this has some very neat uses. I wanted to post on my blog the reply I sent to Peter. I will also be sending Tom Gibara some questions and will post below in the comments further information as it comes to hand but like I said.interesting and I thought it might interest a few of you out there. Peter, At first I was prepared to dismiss this as yet another proprietary 2d code. I read Tom's documentation (as brief as it is) and whilst it has some interesting points there I think (honestly it's only a guess as the information provided at the moment isn't enough to actually make a conclusion) that what is occurring in these videos is the android OS is downloading visual information from a web server and inserting it into the x,y,z axis. Whilst this is neat and 'nice' (particularly the 3 dimensional cube demonstration- for reasons too lengthy to go into here), it doesn't allow for 'inbuilt' coding of any more information at 96 bits than other standards. 2d codes are often about providing information 'on the spot' in a self contained situation without needing to go 'out elsewhere' to gather information. I love that Moseycode is going to be free of patent constraints and I love the 3d (really the Z axis) component but wonder if this is going to be enough..would also be very interested in understanding the ramifications of moving the code to other backward mobile OS (and what kind of physical constraints are required for the camera hardware). Thanks for bringing it to my attention, will be looking with interest as this is further developed. Regards, Dean Collins www.Cognation.net ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New screen?
On 06/01/2008, Joshua Layne [EMAIL PROTECTED] wrote: not that I don't have enough projects, but google is giving a lot of stuff that I don't think is the myphone project - I know it is a bit off topic for this list, but could you send me a link to the 'home'? hbmobile.org that has lots of info on myphone, plus other open phone projects, including tuxphone ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
