AW: omit qemu from OE build?
hi shawn, qemu NEED gcc 3.x. chees CY Ursprüngliche Nachricht Von: [EMAIL PROTECTED] Datum: 02.09.2007 02:44 An: List for OpenMoko community discussion[EMAIL PROTECTED] openmoko.org Betreff: omit qemu from OE build? After the compiler badness on my one gentoo system (which I have no idea how to resolve) I decided to try on another machine which happens to be 64-bit and with gcc 4.1, so there isn't much hope of getting qemu to run. But openmoko-devel-image or openmoko-image depend on it. Is there a way to remove this dependency so I can just build images for the phone? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (PyGTK demos)
Kristian 'kriss' Mueller skrev: Lars Hallberg wrote: This is a new one (Layout is 'numlock' one): http://www.micropp.se/openmoko/res/key2key.py Nice idea. Had to change the code a bit, as the UI of the current version fires up the keyboard if a text entry has the focus - see patch. I intentionally gave the text entry focus so the cursor was visible. But it's not worth the keyboard popping up :-) That means You tested it on OpenMoko? On a neo even? Very curious :-p For me it was hard to choose the right finger to tapping, so that a second one could be used for actual selection. It's better to just move one finger and release it at the needed key. Anyway I like the idea. That's the intended use. 'Two' in the subject means it was two demo's :-) I guess one could learn to write short texts quite fast with one hand that way. Yes... When one learn where the secondary keys are and can start the stoke immediately it should be pretty fast. The other demo, with 8 drag directions should be slightly faster as the drag target is closer and bigger. But the neighbouring keys should be OK (close), the keys at the screen edges (especialy the corners) should be ok (big). Some keys in the middle and top may be worse. A god layout should take this in account... The demo have only a quick and ugly layout thou. This key2key system have advantages to. The other demo have problems around the edges of the screen (drag going off screen) and less function per key (9 vs 12). I'm trying to speed it up so it be a while before Your fix comes out. Thanks /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
How snappy can the Openmoko GUI get using GTK?
Watching a lot of videos about Openmoko and the GUI I saw that it is very slow and yards away from being snappy. (regarding the application startup and the acting inside an application) I know that speed is not the priority thing in developement at the moment but how fast and snappy can the Openmoko GUI using GTK get? I'm looking at this from the user point of view, I'm not a developer so it would be very interesting to me what can be expected in the future. What are you're expectations? Will it get as snappy as the old PALM Pdas had been? I'm really looking forward for your answers. Regards, Denis. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How snappy can the Openmoko GUI get using GTK?
On 2 Sep 2007, at 14:57, denis wrote: Watching a lot of videos about Openmoko and the GUI I saw that it is very slow and yards away from being snappy. (regarding the application startup and the acting inside an application) I know that speed is not the priority thing in developement at the moment but how fast and snappy can the Openmoko GUI using GTK get? I'm looking at this from the user point of view, I'm not a developer so it would be very interesting to me what can be expected in the future. What are you're expectations? Will it get as snappy as the old PALM Pdas had been? I'm really looking forward for your answers. Regards, Denis. Launch speed is something that can be fixed, I'm not sure if the build system is using pre-linking? if not it will be something to use as this is the cure to application launch speed delays on Unix like systems. The interface is VGA and so there's a lot more to draw and this makes the GUI less responsive than QVGA. The acceleration in the next gen hardware will solve this. The Palm PDAs were using task switching, it wasn't a full multitasking OS, so you have to realise that a Linux based PDA will always lag behind a very simple OS. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How snappy can the Openmoko GUI get using GTK?
On Sunday 02 September 2007 16:17:25 Giles Jones wrote: On 2 Sep 2007, at 14:57, denis wrote: Watching a lot of videos about Openmoko and the GUI I saw that it is very slow and yards away from being snappy. (regarding the application startup and the acting inside an application) I know that speed is not the priority thing in developement at the moment but how fast and snappy can the Openmoko GUI using GTK get? I'm looking at this from the user point of view, I'm not a developer so it would be very interesting to me what can be expected in the future. What are you're expectations? Will it get as snappy as the old PALM Pdas had been? I'm really looking forward for your answers. Regards, Denis. Launch speed is something that can be fixed, I'm not sure if the build system is using pre-linking? if not it will be something to use as this is the cure to application launch speed delays on Unix like systems. Lazy loading is too ... (the problem with delay is that ALL symbols need linkage also those not needed by the current user needs) The interface is VGA and so there's a lot more to draw and this makes the GUI less responsive than QVGA. The acceleration in the next gen hardware will solve this. The Palm PDAs were using task switching, it wasn't a full multitasking OS, so you have to realise that a Linux based PDA will always lag behind a very simple OS. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How snappy can the Openmoko GUI get using GTK?
On Sep 2, 2007, at 7:17 AM, Giles Jones wrote: Launch speed is something that can be fixed, I'm not sure if the build system is using pre-linking? if not it will be something to use as this is the cure to application launch speed delays on Unix like systems. This is probably true. The interface is VGA and so there's a lot more to draw and this makes the GUI less responsive than QVGA. The acceleration in the next gen hardware will solve this. This is definitely not true. I mean, it's true that the QVGA is going to take less time to paint, but paint times aren't the problem - if they were, kinetic scrolling wouldn't look so nice. No, there's something else going on that's making the UI so unresponsive. Possibly something is timing out, or something's running in lock-step that should be asynchronous. The Palm PDAs were using task switching, it wasn't a full multitasking OS, so you have to realise that a Linux based PDA will always lag behind a very simple OS. Again, true, but not likely to produce the results we're seeing. E.g., when an app is running, and a tap on the UI takes seconds to produce a response, this is not something you can attribute to the fact that Linux is a protected-mode multitasking kernel. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How snappy can the Openmoko GUI get using GTK?
On 2 Sep 2007, at 15:58, Ted Lemon wrote: This is definitely not true. I mean, it's true that the QVGA is going to take less time to paint, but paint times aren't the problem - if they were, kinetic scrolling wouldn't look so nice. No, there's something else going on that's making the UI so unresponsive. Possibly something is timing out, or something's running in lock-step that should be asynchronous. VGA is 4x times the data, not two times. That will have a noticable effect. The only VGA device I have owned was a Toshiba E800 PDA, this had an ATI chip and it was still a little sluggish. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How snappy can the Openmoko GUI get using GTK?
On Sep 2, 2007, at 8:24 AM, Giles Jones wrote: VGA is 4x times the data, not two times. That will have a noticable effect. The only VGA device I have owned was a Toshiba E800 PDA, this had an ATI chip and it was still a little sluggish. Hm. The best example of slow draw times that I can find in the Moko UI is the terminal keyboard. The reason this draws slowly is because it's being drawn line by line. If it were just blitted in, it would be quite a bit faster. It's certainly true that you will see slowness as a consequence both of the slow CPU and the lack of a GPU, I would guess particularly when surfing the web. However, this is not why the UI feels slow right now. The UI feels slow right now because when you click on a control, sometimes you get no response at all. Right now, the UI is mainly operating in the realm of you click on something, I do something. This works well when the something happens quickly, but when it doesn't, you want you click on something, I do something to show that your click registered, I do something. The elapsed time will be slightly longer in the second case, but the perceived UI lag will be less because you aren't wondering whether or not your tap registered. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ruby for OpenMoko - got it small
So what do you think guys? Shall I keep going and trying to get it smaller and faster or shall I abandon this and spend my time on something more useful. I for one am very much interested and grateful for your efforts. Having used Ruby as my main programming language for all development work (thus, not only for scripting) for more than two years now, I consider the existence of a carefully optimized ruby engine for openmoko as a very important piece of the puzzle. If, thanks to your work, the ruby interpreter were to find a little corner in the default OM distribution, that would be a key selling point for me. I dug up some of my iPAQ-time scripts and cross compiled ruby 1.8.6 I must say, OE does provide a lot of .h and .so files in only a few places, which makes this an easy-enough task. I measure footprint on the jffs2 image. My ipkgs together are less than 2 MB. Uncompressed, I do not so much care. For your convenience: http://chmeee.dyndns.org/om/ruby/feed/ keep in mind some of those won't work. Openssl bindings are empty, for instance, which I will not change since dropbear is installed by default. Tk is not even provided. Installing readline does not work, same reason. Forcing an install of irb, will make irb work. Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: omit qemu from OE build?
Thanks. I got past qemu now and it's getting stuck on qtopia. (Again, why do I need that for openmoko?) On 9/1/07, Steve [EMAIL PROTECTED] wrote: Steve wrote: The only further suggestion I can give you if to clean out the /var/media/moko/build/tmp/work/x86_64-linux/qemu-native-0.9.0+cvs20070613-r5/ directory to force rebuilding of QEMU from scratch in case there are some improperly build files left over in there from when you linked gcc32 to gcc. I haven't looked into QEMU much so the error doesn't mean a whole lot to me. Reading the wiki, it looks like there's a proper way to do that too, try clean-package-qemu-native or something along those lines. From: http://wiki.openmoko.org/wiki/MokoMakefile in the Reporting Problems section -Steve [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (PyGTK demos)
Lars Hallberg schrieb: This is a new one (Layout is 'numlock' one): http://www.micropp.se/openmoko/res/key2key.py 12 keys... tap a key for main function. Drag to any of the other keys for 11 secondary functions. A total of 12*12=144 combinations. To much to show... You have to press a key to see the secondary keys. Drag outside the keyboard to cancel a keypress. A bit awkward to begin with... might work fast when You learn to know the most common secondary keys. Know of no patent jet. Old demo: http://www.micropp.se/openmoko/res/keys.py Tap key or drag in any of 8 directions. 9 funktions per key, easier strokes (bigger end target, butt less functions per key may need to be compensated with smaller start target). maybe patent encumbered. Both demos can easily be adjusted between 3x4 to 3x6 keys to test the feel. I don't know hove easy it is to get a PyGTK demo running on the phone... and they probably perform horribly. But I would be grateful for any report on hove easy the keys and strokes are to hit. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community I've tested the input system and it works very well even for a beginner like me. It is very intuitive and after a short time of practice I'm very fast writting with it. It would be interesting to test this system combined with word prediction. Regards, Denis. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Two finger input methods (PyGTK demos)
Lars Hallberg wrote: This is a new one (Layout is 'numlock' one): http://www.micropp.se/openmoko/res/key2key.py denis wrote: I've tested the input system and it works very well even for a beginner like me. It is very intuitive and after a short time of practice I'm very fast writting with it. Though I was skeptical due to the apparent complexity in the description :-) I also found it fairly easy to use even without practice. Nice one, Lars. -Andy ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: SMedia 3362
Dnia niedziela, 2 września 2007, Shawn Rutledge napisał: What about the ATI chip used in the iPAQ hx4700? Did anybody figure out anything beyond plain framebuffer support for it? hx4700 use ATI W100 Imageon about which I already wrote. AFAIK it has accelerated framebuffer and X11 driver with XVideo and XRender funtions. It also allow to use VGA/QVGA resolution. -- JID: hrw-jabber.org OpenEmbedded developer/consultant Real programmers don't document. If it was hard to write, it should be hard to understand. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: omit qemu from OE build?
On 9/2/07, Marcin Juszkiewicz [EMAIL PROTECTED] wrote: Dnia niedziela, 2 września 2007, Shawn Rutledge napisał: I got past qemu now and it's getting stuck on qtopia. (Again, why do I need that for openmoko?) qtopia or qmake? Qmake is needed to build webkit which is used by openmoko-feedreader. uicmoc4-native_4.3.1 NOTE: Running task 1206 of 3169 (ID: 2684, /var/media/moko/openembedded/packages/uicmoc/uicmoc4-native_4.3.1.bb, do_compile) NOTE: package uicmoc4-native-4.3.1: started NOTE: package uicmoc4-native-4.3.1-r0: task do_compile: started ERROR: function do_compile failed ERROR: log data follows (/var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/temp/log.do_compile.12240) | NOTE: make CC=gcc CXX=g++ | make: Nothing to be done for `first'. | NOTE: make CC=gcc CXX=g++ | make: Nothing to be done for `first'. | NOTE: make CC=gcc CXX=g++ | make: Nothing to be done for `first'. | NOTE: make CC=gcc CXX=g++ | make: Nothing to be done for `first'. | NOTE: make CC=gcc CXX=g++ | make: Nothing to be done for `first'. | NOTE: make CC=gcc CXX=g++ | make: Nothing to be done for `first'. | NOTE: make CC=gcc CXX=g++ | make: Nothing to be done for `first'. | NOTE: make CC=gcc CXX=g++ | make: Nothing to be done for `first'. | NOTE: make CC=gcc CXX=g++ | make: Nothing to be done for `first'. | NOTE: make CC=gcc CXX=g++ | g++ -Wl,-rpath,/var/media/moko/build/tmp/staging/x86_64-linux/qt4/lib -Wl,-rpath,/var/media/moko/build/tmp/staging/x86_64-linux/qt4/lib -o ../../../bin/uic3 .obj/release-static-emb-x86_64/customwidgetsinfo.o .obj/release-static-emb-x86_64/databaseinfo.o .obj/release-static-emb-x86_64/driver.o .obj/release-static-emb-x86_64/treewalker.o .obj/release-static-emb-x86_64/ui4.o .obj/release-static-emb-x86_64/uic.o .obj/release-static-emb-x86_64/validator.o .obj/release-static-emb-x86_64/cppextractimages.o .obj/release-static-emb-x86_64/cppwritedeclaration.o .obj/release-static-emb-x86_64/cppwriteicondata.o .obj/release-static-emb-x86_64/cppwriteicondeclaration.o .obj/release-static-emb-x86_64/cppwriteiconinitialization.o .obj/release-static-emb-x86_64/cppwriteincludes.o .obj/release-static-emb-x86_64/cppwriteinitialization.o .obj/release-static-emb-x86_64/main.o .obj/release-static-emb-x86_64/ui3reader.o .obj/release-static-emb-x86_64/parser.o .obj/release-static-emb-x86_64/domtool.o .obj/release-static-emb-x86_64/object.o .obj/release-static-emb-x86_64/subclassing.o .obj/release-static-emb-x86_64/form.o .obj/release-static-emb-x86_64/converter.o .obj/release-static-emb-x86_64/widgetinfo.o .obj/release-static-emb-x86_64/embed.o .obj/release-static-emb-x86_64/qt3to4.o .obj/release-static-emb-x86_64/deps.o -L/var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/qtopia-core-opensource-src-4.3.1/lib -lQt3Support -L/var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/qtopia-core-opensource-src-4.3.1/lib -lQtSql -lQtNetwork -lssl -lcrypto -lQtXml -lQtGui -lQtCore -lz -lm -lrt -ldl -lpthread | /var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/qtopia-core-opensource-src-4.3.1/lib/libQtGui.a(qapplication_qws.o): In function `QWSDisplay::Data::waitForQCopResponse()': | qapplication_qws.cpp:(.text+0x13f2): undefined reference to `QAbstractSocket::flush()' | /var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/qtopia-core-opensource-src-4.3.1/lib/libQtGui.a(qapplication_qws.o): In function `QWSDisplay::Data::waitForCreation()': | qapplication_qws.cpp:(.text+0x1495): undefined reference to `QAbstractSocket::flush()' | /var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/qtopia-core-opensource-src-4.3.1/lib/libQtGui.a(qapplication_qws.o): In function `QWSDisplay::Data::waitForConnection()': | qapplication_qws.cpp:(.text+0x14e9): undefined reference to `QAbstractSocket::flush()' | qapplication_qws.cpp:(.text+0x1509): undefined reference to `QAbstractSocket::flush()' | /var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/qtopia-core-opensource-src-4.3.1/lib/libQtGui.a(qapplication_qws.o): In function `QWSDisplay::Data::~Data()': | qapplication_qws.cpp:(.text+0x26e5): undefined reference to `QAbstractSocket::flush()' | /var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/qtopia-core-opensource-src-4.3.1/lib/libQtGui.a(qapplication_qws.o):qapplication_qws.cpp:(.text+0x2ab5): more undefined references to `QAbstractSocket::flush()' follow | /var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/qtopia-core-opensource-src-4.3.1/lib/libQtGui.a(qwindowsystem_qws.o): In function `QWSClient::sendEvent(QWSEvent*)': | qwindowsystem_qws.cpp:(.text+0x146e): undefined reference to `QAbstractSocket::state() const' | /var/media/moko/build/tmp/work/x86_64-linux/uicmoc4-native-4.3.1-r0/qtopia-core-opensource-src-4.3.1/lib/libQtGui.a(qwindowsystem_qws.o): In function `QWSClient::QWSClient(QObject*, QTcpSocket*, int)': | qwindowsystem_qws.cpp:(.text+0x3118): undefined reference to
Re: Two finger input methods (PyGTK demos)
Moin, Am Thu, 30 Aug 2007 20:12:00 +0200 schrieb Lars Hallberg: Both demos can easily be adjusted between 3x4 to 3x6 keys to test the feel. I don't know hove easy it is to get a PyGTK demo running on the phone... and they probably perform horribly. But I would be grateful for any report on hove easy the keys and strokes are to hit. Hmm, I just ran it on a Neo and seems to work okay. The biggest problem is that switching to the second set of displayed keys is awfully slow. Apart from that it's only missing some optimizations of the layout. (For example: Backspace absolutely needs to be a main key. Nobody needs ^ as a main key.) In order to run it on a Neo you need to install python-pygtk, python-pygobject (might need ipkg install -force-overwrite since it pulls in libc6-dev, but that's another story) and python-pycairo. -- Henryk Plötz Grüße aus Berlin ~ Help Microsoft fight software piracy: Give Linux to a friend today! ~ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Convince me NOT to cancel my order.
On 8/31/07, Sean Moss-Pultz [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] My point is starting this topic was to bring attention to the fact that probably 500 to 1000 potential developers were likely to get saddled with GTA01 phones right before the GTA02s were released and that FIC staff were not providing sufficient information about likely delivery dates. We are I really wish we could give more accurate timing information. But please understand that what you're seeing is a product being built from scratch. We're not using reference designs. We're not using 3rd party [...] Product development is messy. There are literally hundreds of components in this device, all needing to be sourced with different lead times from different vendors. If SDRAM becomes scarce, we suffer. If a vendor has yield problems, so we do we. Hi Sean. The opensource software development process is wonderful in its transparency - I think thats where a lot of the frustration about the hardware process is coming from. Your reply email gives no new information about the GTA02. Supply chain delays can delay the product, that makes sense, but surely there is information about what is expected to happen? How about saying what the production plans are? Ive read on this list both October 07 and January 08 as estimated GTA02 completion dates. The readership is left to make their best guess based on essentially rumors. Is it a separate electrical engineering team that is designing the GTA01/02 inside FIC and that is partly why the software devs are in the dark? The GTA01 is in production and its the same story. There has been mention of 'another batch' on Sep 20th, but again no announcements. How about stating 'X GTA01s are available for sale. Y GTA01s are in production with an estimated completion date of Z' and 'On date D1 we expect to stop making new GTA01s and start making GTA02s'. That would be something to chew on, knowing full well that estimates change and surprises happen. Thanks, Don ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Convince me NOT to cancel my order.
Don Park wrote: On 8/31/07, Sean Moss-Pultz [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] My point is starting this topic was to bring attention to the fact that probably 500 to 1000 potential developers were likely to get saddled with GTA01 phones right before the GTA02s were released and that FIC staff were not providing sufficient information about likely delivery dates. We are I really wish we could give more accurate timing information. But please understand that what you're seeing is a product being built from scratch. We're not using reference designs. We're not using 3rd party but surely there is information about what is expected to happen? How about saying what the production plans are? Ive read on this list both October 07 and January 08 as estimated GTA02 completion dates. The readership is left to make their best guess based on essentially rumors. Is it a separate electrical engineering team that is designing the GTA01/02 inside FIC and that is partly why the software devs are in the dark? The GTA01 is in production and its the same story. There has been mention of 'another batch' on Sep 20th, but again no announcements. How about stating 'X GTA01s are available for sale. Y GTA01s are in production with an estimated completion date of Z' and 'On date D1 we expect to stop making new GTA01s and start making GTA02s'. That would be something to chew on, knowing full well that estimates change and surprises happen. Indeed. Knock off 5 days for shipping to end users, 5 days for FIC doing shipping stuff, 5 days for transit from HK to US, 5 days for production and we're getting pretty close to the 'volume production of GTA02 has to start today to get to paying devs in october' date already. Is there sufficient confidence in the current GTA02 rev to actually start volume production in the next week or so? If not, can you please tell us. Is it planned to distribute GTA02 to a select group of external testers first? Personally, I suspect that I've lost several potential dev-months of time for OM, simply as I have not been able to say to people who are very interested in this sort of stuff, and who I have seen coding on random 'cool' gadgets, that if they put down money now, they will get hardware in a week or so. (and in all of those cases, they've only really been interested in coding for a platform after actually getting their hands on the physical object.) ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
