Re: project customers
-[ Sat, Apr 17, 2010 at 12:46:28AM -0300, Werner Almesberger ] I'd worry a lot more about GUI and applications than about any bit of hardware. Agreed, and iPad imitators are probably going to discover once again that software is a very important component that can not be copied as easily as the hardware. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Introducing FoxtrotGPS (was: Forking TangoGPS)
Hello, everyone-- I'd like to formally introduce the foxtrotGPS project: FoxtrotGPS is an offshoot of Marcus Bauer's excellent tangoGPS application http://www.tangogps.org/, with a focus on cooperation and fostering community innovation. You can find more information, including a link to our public version-control repository, on the project's website: http://www.foxtrotgps.org/ FoxtrotGPS' commitment is to improving on the extensibility and maintainability of what we'd like to consider our `sister project': rather than competing with tangoGPS, foxtrotGPS exists to channel the developer-energy that's been bouncing around the community without having a clear way to fit into the tangoGPS development model. We intend to help grow the developer community, in part by working to extend support for open standards and open architecture in the foxtrotGPS codebase; more specific details are available on the `roadmap' page of the foxtrotGPS web-site: http://www.foxtrotgps.org/roadmap.html Users and developers are invited to connect and collaborate-- with each other and with the foxtrotGPS leadership--via the foss-gps e-mail list http://wiki.osgeo.org/wiki/FOSS-GPS, as well as on the #foxtrotGPS IRC channel irc://irc.freenode.net/#foxtrotGPS. We encourage anyone who's found frustration in developing or maintaining patches against tangoGPS thus far to participate in foxtrotGPS instead of agressing the tangoGPS leadership: the foxtrotGPS `fork' is being done with all possible respect, and our hope is that we will be able to remain on the best possible terms-- that things can be kept cordial and professional between the two projects, and that we will find plenty of code to continue to share. We invite Marcus to incorporate whichever of our changes make sense for him to use in his project, on whatever schedule is appropriate for him. Please join us to share your insights, experiences, wishes, and most of all your patches. Thank you, all. (And--again: thank you, Marcus, especially!) Let's dance! :) -rozzin. -- Don't be afraid to ask (λf.((λx.xx) (λr.f(rr. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 179, Issue 23
Em 17-04-2010 10:02, Christoph Pulster escreveu: I consider the idea, that the future of open source hardware could be this: taking high-quality hardware from big players like Apple, which are sexy and free of bugs. But jailbreaking/reflashing the bootloader, installing a free OS. Sure, we get in some dependencies of the HW manufactorer and this is not the 100% clean way like Copyleft-concept of Qi is (well this is a very European idea, maybe some Russian crackers are more intelligent in some practical way). Won't work. One word why: drivers. You'll always produce a sub-standard alternative to the official OS that comes with the device. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community Digest, Vol 179, Issue 23
2010-04...@10:28 Rui Miguel Silva Seabra Won't work. One word why: drivers. You'll always produce a sub-standard alternative to the official OS that comes with the device. Rui yeah...and producers of closed hw like apple can (and they will do) change the firmware or some chip without notice (keeping the final product nearly the same) and you are out because those changes are not (at least fully) documented. you (we) can only guess what was affected between revisions but it's impossible to get the full scenario of the changes. -- ALFA21 IS PROVIDED AS IS AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Bug 1024
another cause maybe: [quoting from wiki about debian] echo 500 /sys/module/glamo_mci/parameters/sd_max_clk echo 3 /sys/module/glamo_mci/parameters/sd_drive If that resolves the problem and installation completes, you are that much wiser. However, SD card performance is reduced even from the default, power consumption increases and SD card power could interfere with GPS functionality. [/quote] ...and qtmoko uses sd_max_clk in /etc/init.d/qpe.sh for compatibility reasons -- ALFA21 IS PROVIDED AS IS AND WITHOUT WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
of books and pads (was Re: community Digest, Vol 179, Issue 23)
[ Let's use a meaningful subject. ] Christoph Pulster wrote: The format Pad is no new idea. The industrial product range use it since many years. This is, by the way, one sector likely to be able to limit the complexity of tasks, as I described in my previous post. In fact, the possibilities and mechanical complexity of a laptop would just get in the way in many cases. I consider the idea, that the future of open source hardware could be this: taking high-quality hardware from big players like Apple, which are sexy and free of bugs. But jailbreaking/reflashing the bootloader, installing a free OS. That's the anti-vendor port approach. FSO had high hopes for it. A while back, Mickey sounded disappointed with the feasibility of this. But maybe things have gotten better since ? I did my share of reverse engineering as well. It's not so bad if you have plenty of time, the device isn't overly complex, and most of the functionality is already openly documented. E.g., for the Psion S5, we had documentation for the SoC, we left all the hardware bringup to the native operating system, and we got leaked information for their custom ASIC. We figured out almost everything we needed to know. Storage (CF) was a bit shaky but still usable. Phones are quite a bit more complex. Also, there are areas where you're currently unlikely to get proper documentation, such as the modem. So you need to plan around them, e..g, by substituting a highly integrated solution with a SoC without modem plus a black box modem. There is little reason for a manufacturer of Closed phones to make such a choice. So you won't find any mass-market devices that do this for you. There are other components where you can choose between Open and Closed. If Open is not a design objective and you're used to sign lots of NDAs (or you have blanket NDAs with various chip makers already), the decision may be fairly arbitrary. Thus each chip lowers the probability that the overall design will be Open-friendly. That's why I think it's indispensable to be able to choose which chips you put into your design, and to negotiate with chip makers before selecting components. Once you've committed yourself, it's nearly impossible to change the conditions. (In Openmoko alone, we have two examples: GTA01's GPS and GTA02's WLAN. In a university project I did some years ago, there was a competing project from another university. We had insisted on permission to GPL our driver, while our competitors accepted an NDA that didn't let them. Ironically, even after we released our driver they never managed to get that NDA changed.) - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MC Navi
yes, I plan to add other toolkits in future, but the first will be bada or windows. But this is very far future On 04/09/2010 03:33 PM, arne anka [via Openmoko Public Mailinglists] wrote: had a short glance over the sources. did you mix your algorithm inseparably with illume/esomething/whatever-the-name? or would it be possible to add another toolkit's interface to it? given the current state of navit on the n900, it would be interesting to maybe create an qt interface and try to run it on the n900, too. ___ Openmoko community mailing list [hidden email] http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=4877091i=0 http://lists.openmoko.org/mailman/listinfo/community View message @ http://n2.nabble.com/MC-Navi-tp4835841p4877091.html To unsubscribe from MC Navi, click here (link removed) ==. -- View this message in context: http://n2.nabble.com/MC-Navi-tp4835841p4918293.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: project customers
Em 16-04-2010 23:02, Kosa escreveu: I ain't no expert on this, but since iPad is being a succesful mobil device, we could give a chance for a BIGGER Freerunner. Of course iPad won't sell as many pices as the iPhone has, but 400k seems good for a start. There's a huge market for the big touchscreen devices. There is a project for such a pad at the OLPC. Joining the effort seems like the wisest choice, to me. http://www.google.pt/search?q=olpc+tablet It's would be a real killer if it has a reflexive screen like XO-1 and XO-1.5 * low energy requirements when backlight is off * visible even with direct sunlight * color! (well, I don't know if reflexive mode can support it, in current XO's it can't) Add to it new Comix/Evince/etc... interfaces oriented to touch screens, and you'll have a huge success if it's cheap, so featureful and open. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
The target device of my experiments is the openmoko. For this reason I put the openmoko-dev list to cc, maybe somebody is interested there. oddd. lossy uses libjpeg. BOTH use eet. eet uses jpeg compression for lossy and zlib for comp. there is also raw that doesnt compress at all. well.. then I do not understand why it crashes I use libjpeg.7 .. Anyway it is not the main point now. I changed to COMP and it works. anyway ... my experiment was not really successful... support for sdl and directfb seems to be broken at elementary lib level... tried to add myself the different cases in elm_wind_add and brohters, but did not work, I found a a patch on a a thread here to make directfb working, but it did not. The intention of my experience was to see if evas/ecore would behave better on top of a potentially accelerated directfb backend. However as far I understood from the code evas/ecore would have zero benefit from a 2d accelerated directfb driver. My question is: 1. as was reading on some other threads that one wants to get rid of Xrender. Would however efl be able to use some 2d acceleration (blit from videa ram to videa ram, draw/fill rectangle etc.) 2. is there any interface to inject some 2d accelerated code into the fb driver? For example the most annoying on openmoko freerunner is slow scrolling. For example your map example becomes the same sluggish. This could be probably solved by scrolling through a temp invisible video memory buffer. -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: [SHR-T-Latest] PISI problems
OK, this took some time (terrible sorry for that!) but now here is the requested output: -- r...@om-gta02 ~ $ pisi -v contacts_dbussim contacts.vcf *** ** PISI** *** ** PISI is synchronizing information ** ** http://projects.openmoko.org/projects/pisi/ *** *** PHASE 0 - Configuration *** Verbose mode on In case of conflicts I use the following strategy: Skip Reading configfile: /home/root/.pisi/conf Traceback (most recent call last): File /bin/pisi, line 156, in module pisicli.startCLI() File /opt/pisi/pisicli.py, line 215, in startCLI source = pisi.importModules(configfolder, config, modulesToLoad, modulesNamesCombined, soft) File /opt/pisi/pisi.py, line 78, in importModules modulename = config.get( modulesToLoad[i], 'module' ) File /usr/lib/python2.6/ConfigParser.py, line 531, in get raise NoSectionError(section) ConfigParser.NoSectionError: No section: 'contacts_dbussim' Thanks Tony On Tue, Apr 6, 2010 at 6:20 PM, Michael Pilgermann kichka...@gmx.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi tony, this problem is still there? Could you please start pisi from a shell and provide some debug output?? thx, best Michael On 04/06/2010 06:11 PM, Tony Berth wrote: any chance to draw some attention to this one below? Thanks Tony -- Forwarded message -- From: *Tony Berth* tonybe...@googlemail.com mailto:tonybe...@googlemail.com Date: Mon, Apr 5, 2010 at 12:20 AM Subject: [SHR-T-Latest] PISI problems To: List for Openmoko community discussion community@lists.openmoko.org mailto:community@lists.openmoko.org Dear Team, did a fresh install of the latest SHR-Testing image and tried to import my SIM contacts via PISI. The progress bar goes up to: 'Finished (40%)' and then stops. Needless to say that no contacts were imported. Thanks for your help Tony ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLu19KAAoJECyCaNMbCftRjNQIAI9eA/JY/mpBNie+OWfFUUeO oouZ6QFHQp/awxlZohmJgsvv52Mc9T375JnXZUS/KNm3nAz++3niZrvEAWxR0PvN asc729vDqG5Hkde87q60Ve+QwIbq58gzTixqSzep56UDZI/rfz8AdwMgnlbGXu8V Fg3J6CpoGRpVnOQCtjRfwGiQJyBuC7QmwH2V7ZPrFrfuFapXHvae+BObEJD+/jSY 04U7KyE8h0jeco1z0nIoDDtgcQptQnXdic3MptuuifkKTv5N9+r8DKV4Af6xB2I1 RJ+R/mqubRrUpBHb/WEivB/x3NmSwRO9AlGXVXAFkANU0CLXBzilZvGkQndXanE= =PY1R -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
On Sat, 17 Apr 2010 20:27:06 +0200 mobi phil m...@mobiphil.com said: The target device of my experiments is the openmoko. For this reason I put the openmoko-dev list to cc, maybe somebody is interested there. oddd. lossy uses libjpeg. BOTH use eet. eet uses jpeg compression for lossy and zlib for comp. there is also raw that doesnt compress at all. well.. then I do not understand why it crashes I use libjpeg.7 .. Anyway it is not the main point now. I changed to COMP and it works. ess is there is something my guess odd in your build environment - i assume its some sort of cross-compile setup. as suc openembedded builds a non-x11 efl as native binaries to get to have edje_cc work. and it all worked last i looked. anyway ... my experiment was not really successful... support for sdl and directfb seems to be broken at elementary lib level... tried to add myself the different cases in elm_wind_add and brohters, but did not work, I found a a patch on a a thread here to make directfb working, but it did not. if you are talking of directfb accelerated on top of glamo - good luck. last i checked it wasn't and you'd have something a LOT slower. the hardware there is a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if not better. for that matter if its sdl on x11 - evas's own software-x11 layer will do much better. sdl doesnt offer anything here. opengl support for sdl doesnt do anything accelerated either except set up and sdl buffer with a gl context attached - all the acceleration comes from using opengl. as such directfb is little-loved and not maintained. as and engine. sdl is being loved/used on the palm pre (webos) and it works there, so no idea what's up with you there, but they seem to be having some fine success. The intention of my experience was to see if evas/ecore would behave better on top of a potentially accelerated directfb backend. However as far I understood from the code evas/ecore would have zero benefit from a 2d accelerated directfb driver. in theory they would - fact is directfb won't be accelerated. all the rendering is done by evas - ecore isn't involved there beyond providing events and mainloop. but dfb is not maintained and behind. as such it's very little used in real life and not worth the trouble. nothing dfb does can't be done in x11. My question is: 1. as was reading on some other threads that one wants to get rid of Xrender. Would however efl be able to use some 2d acceleration (blit from videa ram to videa ram, draw/fill rectangle etc.) useless when all the other ops are slow. waste of time and effort. i've been wasting and waiting for a decade. i've had enough of it. xrender engine is already partly broken as it doesn't support some of the modern things like map. note that on glamo xrender als is not accelerated and in fact is not able to be properly accelerated and you will have lots of software fallbacks doing read/modify/write across the anemic video bus to glamo. i've been here. long ago. i have the full glamo hw docs. i read them in entirety and made decisions off that. what you see in the checkbox list of features vs what glamo actually does makes you think again about it as a useful chip. 2. is there any interface to inject some 2d accelerated code into the fb driver? no. you do a new engine. eg fb-glamo. it will fail becauuse in the end you will create something very complex that is actually no faster. you will win on operation a and then lose on operation b. glamo's problem is its operations are asymmetric. you can use rgba as src - but never create rgba as a dest - only rgb565. pointless for intermediate buffers than now need fallbacks. also leads to cumulative rendering error when dropping down to rgb565 and quality will suffer badly. For example the most annoying on openmoko freerunner is slow scrolling. For example your map example becomes the same sluggish. This could be probably solved by scrolling through a temp invisible video memory buffer. the freerunner itself is slow - it's a very poor piece of hardware. it''s the worst one i've ever working with in a decade. the original ipaq3660 i worked on at the start of my embedded games was far better performance-wise. you can polish a turd - but a turd is still a turd. all you will do is create a mess that is simply not maintainable in the long run in the name of a broken bit of hardware. been there. done that. :) scrolling in efl is a redraw. why? because doing otherwise is nuts - especially if you want to support things like opengl. also in the need when people want their translucent list items with static bg's etc. - you do redraws anyway. you can cut out some redraw with intermediate buffers - but then you pay a price in memory usage. you can do this via map... but.. gasp.. that needs an intermediate buffer and... glammo cant generate those other than in
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
Thanks for the detailed answer... You told me what I did not find out in weeks :)... nevertheless: if you are talking of directfb accelerated on top of glamo - good luck. last i checked it wasn't and you'd have something a LOT slower. No.. there is nothing... was thinking to write sthg. on top of Thomas White's: http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html drm/kms work. My main point was to have sthg. that is common to both X world, and fb (Qt, non-X elf etc, other lightweight fb apps), the lowest c. denominator. And that could have been directfb, but I am more convinced that not. One of usage of this c. denominator would have been to have a global keyboard, that would cold be rendered on top of any application. taping the rendering engine, probably would have been easy. the hardware there is a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if not better. in this situation, I admit, no point to have nor directfb nor sdl. Just a broken illusion, that efl on top of directfb would make things faster. But I can draw very fast the conclusion that in case of glamo, running illume and other apps, there is no point to have X windows... I wonder if anybody from the openmoko community can confirm that efl would be faster with accelerated X, what I doubt... probably the opposite, at least what concerns loading times, as less binary has to cross the narrow channel. as such directfb is little-loved and not maintained. as and engine. sdl is being loved/used on the palm pre (webos) and it works there, so no idea what's up with you there, but they seem to be having some fine success. Honestly I just discovered, that you guys do a superset of directfb features. And directfb did not evolve the last 4-5 years since I keep an eye on it.. The intention of my experience was to see if evas/ecore would behave better on top of a potentially accelerated directfb backend. However as far I understood from the code evas/ecore would have zero benefit from a 2d accelerated directfb driver. Sorry.. what do you mean as far as I understood ... you did not write that part? in theory they would - fact is directfb won't be accelerated. all the rendering is done by evas - ecore isn't involved there beyond providing events and mainloop. but dfb is not maintained and behind. as such it's very little used in real life and not worth the trouble. nothing dfb does can't be done in x11. My question is: 1. as was reading on some other threads that one wants to get rid of Xrender. Would however efl be able to use some 2d acceleration (blit from videa ram to videa ram, draw/fill rectangle etc.) useless when all the other ops are slow. waste of time and effort. i've been wasting and waiting for a decade. i've had enough of it. xrender engine is already partly broken as it doesn't support some of the modern things like map. note that on glamo xrender als is not accelerated and in fact is not able to be properly accelerated and you will have lots of software fallbacks doing read/modify/write across the anemic video bus to glamo. i've been here. long ago. i have the full glamo hw docs. i read them in entirety and made decisions off that. what you see in the checkbox list of features vs what glamo actually does makes you think again about it as a useful chip. 2. is there any interface to inject some 2d accelerated code into the fb driver? no. you do a new engine. eg fb-glamo. it will fail becauuse in the end you will create something very complex that is actually no faster. you will win on operation a and then lose on operation b. glamo's problem is its operations are asymmetric. you can use rgba as src - but never create rgba as a dest - only rgb565. pointless for intermediate buffers than now need fallbacks. also leads to cumulative rendering error when dropping down to rgb565 and quality will suffer badly. hm... did not know this issue with rgb565... You mean I cannot blit from an unvisible VRAM area to the visible one? The idea was, when scrolling (like when moving maps) to redraw only new parts, and the rest do by two copies inside the VRAM. I wonder if there is sthg. similar implemented for scrolling in Xglamo.. For example the most annoying on openmoko freerunner is slow scrolling. For example your map example becomes the same sluggish. This could be probably solved by scrolling through a temp invisible video memory buffer. the freerunner itself is slow - it's a very poor piece of hardware. We know that... And the most annoying is the scrolling when everything has to be redrawn, whereas only parts should be. Well.. in the worst case I will understand that it is impossible (hower it does not seem to be).. scrolling in efl is a redraw. why? because doing otherwise is nuts - especially if you want to support things like
Re: [E-devel] X11 dependencies hardcoded in ecore_evas
On Sun, 18 Apr 2010 03:05:24 +0200 mobi phil m...@mobiphil.com said: Thanks for the detailed answer... You told me what I did not find out in weeks :)... nevertheless: if you are talking of directfb accelerated on top of glamo - good luck. last i checked it wasn't and you'd have something a LOT slower. No.. there is nothing... was thinking to write sthg. on top of Thomas White's: http://www.bitwiz.org.uk/s/dri-for-the-freerunner.html drm/kms work. My main point was to have sthg. that is common to both X world, and fb (Qt, non-X elf etc, other lightweight fb apps), the lowest c. denominator. And that could have been directfb, but I am more convinced that not. One of usage of this c. denominator would have been to have a global keyboard, that would cold be rendered on top of any application. taping the rendering engine, probably would have been easy. dfb isnt common to fb and x11 - it is an enitre display system of its own. there is a specific xdirectfb server on top of dfb. but it is not a common component. i think you misunderstand directfb... :) but - you'd need all the acceleration written and even then the chip simply is not capable of many ops you need or it makes them needlessly complex (you will need to go via the 3d unit and that limits all pixel primitives to 256x256 as a source and output cant be more than 512x512 for any buffer - you'd need to do complex tiling of all input and output and that will wreak havoc on things like transforms/scaling to make it look right - and effectively make it impossible). trust me - have full hw docs. had them from the day i started with glamo long before gta02 came out. after some reading i went from excited to despondent. glamo does not live up to what it seems to appear reading its checklist features. sure - it's possible to go accelerate some things and get some benefit. for each of those you now have a downside as u need a software fallback for the ones you can't - and... those now get more complex WITH more overhead. you make operation a 2x faster and operation b gets half the speed. and so on. my bet is that even if you do it all as optimally as possible with glamo+gta02 arch - you will have spent a mountain of effort going nowhere. ie not be able better in general. some things improved, some worse. and now you have a monster of complexity that has no future. glamo is a dead end chip. openmoko a dead end product line. a source base that will not be useful for any future hardware developed nor even todays hardware. the future is mostly opengl-es2 based with the ability to punt off preparation pipeline stages to multiple cpu cores - or if you are lucky, some dsp cores. as such even without this punting off to multiple cores, with gl-es2 - things work damned well - silky smooth on a modern soc. thats including rendering everything at 32bpp, compositor in x11, and more. the hardware there is a dead end. sdl doesn't provide any acceleration itself anyway - sdl is a wrapper to get a dumb fb. evas's raw fb engine/support will be just as good, if not better. in this situation, I admit, no point to have nor directfb nor sdl. Just a broken illusion, that efl on top of directfb would make things faster. :) But I can draw very fast the conclusion that in case of glamo, running illume and other apps, there is no point to have X windows... i disagree. how do u think you get a vkbd up on screen separate to the app, or the top-shelf (place for app name, battery, reception etc.) ? i think you are under the illusion also that somehow windows have some massive overhead in x11 - they don't - they are simply clipping regions for doing draws - that go to the framebuffer (with compositing - different story with redirection but you end up producing the same design no matter the display system). clip regions are just a list of rectangles only draw within this region when drawing. you ask x11 to do the drawing to the fb for you to make sure all of this is co-ordinated and the clip regions obeyed. x11 is also asynchronous and buffers so its NOT: draw thing, wait for x, x sends draw done,... draw next thing, wait for x, x sends draw done... that'd be stupid. you CAN write code that works like that with x11 - but then i'd shoot you to save the world a little more oxygen as you'd be using up too much of it. :) (joking! but you would be stupid) :) in x11 (with efl) it's like this: prepare stuff locally, send draw, send draw, send draw, prepare locally, send draw, send draw, send draw, frame finished at frame finish it waits for x (to syncronise and make sure app doesnt go and queue many frames ahead of what x has managed to draw/copy to the screen). all those prepare/send happens in the app without context switching to x11 - there is no overhead compared to anything fb oriented. I wonder if anybody from the openmoko community can confirm that efl would be faster with accelerated X, what I doubt... probably the opposite, at
