Re: how long freerunner will be produce ?
Thanks, Don't be worried. Just keep in touch with me about your requirements and we can plan accordingly. Mickael LABROUSSE wrote: Thanks for answering me. For the moment we have bought to one of your distributors providing us a very good price. It's very difficult for us to estimate how many GTA02 we are going to sell because it is part of a full offer. It can be be 50 or 100 or 500 per year. The other problem is that for some others reasons we don't think really sell so much this year but really start in 2010. I a little bit worried for our future with the GTA02. Thanks, Mickael. Steve Mosher a écrit : Hi. Mickael LABROUSSE wrote: Hi everyone, I work in a french compagny making up a produce based on the freerunner. Sorry to open a new thread about this but I read everywhere on the Internet that Openmoko cancels gta03 and sometimes news talk about gta02 too !! GTA03 was postponed. There is anew list on openmoko.org that will be dedicated to a community driven definition for this product. The whole product process will be opened up. So a simple question how long freerunner will be produce ?? As sean noted we have a good level of inventory for the retail demand that we currently see. In addition, we have Kits of components that can sustain production through 2009. Because we have some major potential customers we also monitor parts availability in case volume ramps dramatically. Go ahead and contact me at st...@openmoko.com and we can talk about your specific requirements, volume, pricing, timing. Thanks a lot. Mickael ___ 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Slashdotted
http://ostatic.com/blog/openmoko-steps-back-re-evaluates-road-ahead___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone (0.20 - alpha release) Elementary based mplayer frontend
c_c cchan...@yahoo.com writes: Hi, Here is a newer version with some bug fixes and seeking. intone_0.21_arm.ipk Hi! With seeking it is a nice finger friendly player, thanks for that! Works great for me on shr-unstable. I want to mention three minor issues/requests [1]: 1. Please consider moving /home/root/.intone/art to /usr/share/intone, it is quite strange to install files in to user directory. 2. Same for /home/root/.intone/intone_songs.db, after upgrading to 0.21 my previous db was overwritten. If you change the db structure I understand you may not bother to upgrade user db on this level of development, but if not it would be better to create this file only if user does not have one. 3. Improve on my personal use case: I mainly use intone (was pythm before) to listen to lectures, so for me it would be great if intone after restart remembered position in the file so after hitting play it will continue playing where I have paused it in previous run. [1] For now I will not find time to write a patch, but if you will be interested I may consider it in a distant future :). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
ReMoko on SHR - python error
Do you mean changing: from remoko.remoko_server import * to remoko_server import * in /usr/bin/remoko? Yes, you're right. But the PYTHONPATH-environment variable must be set to /usr/lib/python2.6/site-packages/remoko/ The directory-variables in the python-code aim to /usr/share/remoko/data/ instead of /usr/share/remoko. So you have to copy the files in this directory, or fit the code to /usr/share/remoko (see http://nublog.im-blog.de). Now it should run, but I think it's not working. There are still some errors with dbus (I think they come with bluez) ... error in proxy ... ERROR: isRunning d-bus call not present ... Error in d-bus system ... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.2.1 and atd-over-fso (now works on SHR-testing)
Ahh, yes, it works now. Thanks. :D ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Graphics Performance
On Tue, 07 Apr 2009 11:35:41 -0400 Iain B. Findleton ifindle...@videotron.ca said: this is one of the problems with glamo. as i know it will not be used in any future products beyond gta02. no other phones i know use it - no other linux devices. writing an app totally around the glamo and how it works or doesnt work well will simply heavily screw with the ability to port to any other new/future/different platforms. fi glamo was less limited with less gotchas - it'd be sane ad you use what is a generic common pipeline and simply speed it up on glamo - all of the pipeline fits. and the next device has a different gfx chip..and again - all the pipeline fits. i can say doing things like draw to offscreen pixmap then copy to screen to avoid draping using the blitter will in fact impact you badly on MANY MANY MANY platforms as you add an extra copy to the pipeline you don't need. MOST platforms in the embedded world - and pc/desktop world, have FAST framebuffer WRITE access. for just this reason. so for the sake of 1 gfx chip - you impact performance on most other platforms (note - ecore_evas does actually abstract this - it's an option for a canvas window. avoid damage renders to a offscreen pixmap to avoid redraws and copies the pixmap to the window on updates or exposes, so it can be turned on, but for other things like SDL using apps you'll have to specially change the pipeline. this of course is a simple part of it. the complicated make the most of glamo involves specially limiting 3d window sizes and filling the rest with non-gl drawn window parts like toolbars, which are pointless on other systems. limiting all your textures to 256x256 and now having to add complicated texture meshing code that now also impacts in nasty ways on scaling and interpolation quality... i can get into having to avoid the software pipeline bits of xrender - were you to partially accelerate it in glamo (its partially possible - but not enough of it to the point where i'd consider it a win to do).). yes. glamo can accel. yes - xglamo accelerates blits, fills and xvideo. its not unaccelerated. yes it can to gles1.1 (at a very low/limited spec). in my playing with gles even the high-powered gles chipsets (sgx and 6410) are not fast. they are quite slow - at least trying to get them to do 2d and comparing them to software routines doing the same (blending, fillts, blits, etc.). xrender (thus aa text that uses xft etc.) can be sped up partially, but not fully. the moment you can't fully accelerate a whole subsystem.. you need to stand back and think some bits speed up - some bits slow down (compared to doing to 100% in software). you need to weight up will the sped up bits outweigh the slowed down bits so overall i win?. that call - at least when i looked at it, i made in favor of unlikely to be a win - chances are you will just break even, and have spent a lot of time on code and debugging it, making it stable, just to have gone precisely nowhere. that was my conclusion. others may disagree. that is fine. if you disagree strongly enough - implement the acceleration and show to me i am wrong.. and i'll happily go oops - well. i was wrong! :) i know i dont want to spend months of my time on acceleration i believe will go nowhere. i can get better gains from spending that time on other code :) That should be fine. Of course, if the phone has no future Thomas White wrote: On Fri, 03 Apr 2009 21:14:16 +0100 Ian Stirling openm...@mauve.plus.com wrote: What is the bandwidth for memory moves? About 6-8 or so - with 100% CPU utilisation Or one pixel per 2D engine clock cycle for moves inside Glamo's memory using its blitter (i.e. VRAM-VRAM). I think that in the Freerunner the relevant clock runs at 50MHz, but I haven't managed to properly decipher what's going on in that regard. Tom ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Iain B. Findleton Tel: 514-457-0744 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Upadated - Intone (0.21 - alpha release) Elementary based mplayer frontend
Hi, 1. Please consider moving /home/root/.intone/art to /usr/share/intone, it is quite strange to install files in to user directory. Sorry for that one. I was doing that so I could test on my laptop (and forgot that the release was last generated on my PC). Will release a fix today. 2. Same for /home/root/.intone/intone_songs.db, after upgrading to 0.21 my previous db was overwritten. Actually, your old db should be there in /usr/share/intone. I changed the location of this file in this release. Don't you think a file that gets changed frequently should be in the users home directory? 3 .if intone after restart remembered position in the file so after hitting play it will continue playing where I have paused it in previous run. Well, I have catered for remembering the last file that was playing - but not impemented it yet. Will add remembering the pause position too. Should be done today. I have added a few icons - and the CPU usage has gone up to about 2.5%. Using a smaller play list (instead of the default 0 All Songs) reduces CPU usage to ~ 1.5%. Just thought I'll share this too. @ Treviño - Well, I don't have OM 2008 to test this on - but that is strange. Can you confirm the newer version also does this? I guess I'll have to download OM2008 now! -- View this message in context: http://n2.nabble.com/Intone-%280.20---alpha-release%29-Elementary-based-mplayer-frontend-tp2587826p2602528.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: Upadated - Intone (0.21 - alpha release) Elementary based mplayer frontend
c_c cchan...@yahoo.com writes: Hi, 1. Please consider moving /home/root/.intone/art to /usr/share/intone, it is quite strange to install files in to user directory. Sorry for that one. I was doing that so I could test on my laptop (and forgot that the release was last generated on my PC). Will release a fix today. 2. Same for /home/root/.intone/intone_songs.db, after upgrading to 0.21 my previous db was overwritten. Actually, your old db should be there in /usr/share/intone. I changed the location of this file in this release. Don't you think a file that gets changed frequently should be in the users home directory? Same was referring to it is quite strange to install files in to user directory, but it could mislead to refer to consider moving which I did not intended to propose here. For sure it is the best place to have users files in ~/.intone, but /home/root/.intone/intone_songs.db was one of the files in the package (as shown by opkg files intone) so the songs db was overwritten on the install with the one from the package. I had to delete it and start with the empty one. /usr/share/intone is now empty, but I have all sound files in single directory, so it took less of my time to recreate the db than to write this sentence :). By the way when adding files it would be nice to have (if not a progress bar) a message of the form Adding directory %s, %d files scanned (or similar) updated every second (or may be twice a second), so the user knows something is going on and the program is not frozen. 3 .if intone after restart remembered position in the file so after hitting play it will continue playing where I have paused it in previous run. Well, I have catered for remembering the last file that was playing - but not impemented it yet. Will add remembering the pause position too. Should be done today. Great! I have added a few icons - and the CPU usage has gone up to about 2.5%. Using a smaller play list (instead of the default 0 All Songs) reduces CPU usage to ~ 1.5%. Just thought I'll share this too. @ Treviño - Well, I don't have OM 2008 to test this on - but that is strange. Can you confirm the newer version also does this? I guess I'll have to download OM2008 now! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
