Re: FOSDEM2010
Great idea, an Openmoko community-managed table or devroom would be a strong reason for me to come this year, so +1 from my side! If it's going to be a devroom, I would offer a presentation on FSO: Origins, Status, and Future. Cheers, :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
One thing I have noticed with 0.2 is that the alarm isn't very loud and the FR seems to go to sleep before the alarm gets loud enough to hear - its inaudible except when there is nearly no environment noise. 0.1 seems to get a lot louder, and faster. Something to think of for your todo list is checking the profile setting before sounding the alarm - an alarm going off in a meeting is just as disruptive as a phone ring. I disagree. There is nothing worse than sleeping in, because you forgot to put your phone back into ring-mode. Also, I don't wont to be woken up during night from calls and sms. Richard ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Tue, 2009-10-27 at 08:09 +0100, Richy wrote: One thing I have noticed with 0.2 is that the alarm isn't very loud and the FR seems to go to sleep before the alarm gets loud enough to hear - its inaudible except when there is nearly no environment noise. 0.1 seems to get a lot louder, and faster. Something to think of for your todo list is checking the profile setting before sounding the alarm - an alarm going off in a meeting is just as disruptive as a phone ring. I disagree. There is nothing worse than sleeping in, because you forgot to put your phone back into ring-mode. Also, I don't wont to be woken up during night from calls and sms. Richard Again, perhaps something thats suited to a config setting. When I set a phone to be silent, I want it/need it to be totally silent - something important might depend on it. The treo650 has the best solution Ive ever seen to this :) In shr its possible to set up any of the 4 profiles - perhaps add another thats All silent, or have a checkbox to set it to phone or all. Thinking on it, its not really ffalarms responsibility, but squarely a profile setting for a master audio kill switch. BillK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QtMoko] mediaplayer issue
Hello, list! Nowdays I have some problems with mediaplayer on the QtMoko v14 image. I installed codecs package form the repository and set it up, but mediaplayer still cannot play mp3 files... When I try to play ogg files - I receive a very bad performance, the music twitch every 2 seconds. Playing wav files is ok for now... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
OK Tuxbrain will be there, :) so we have Qalee , and FSO presented by his creators, yummy Is not very clear yet but we had in mind to do a #1024 rework party in Barcelona after the FOSDEM , so we will try to make it in FOSDEM too, just to make clear this time the rework will not be for free, but we will try to adjust the price as much as possible. Well I have full fill the form for ask for a devroom for the Openmoko-community on 2009-11-29 we will know if we were approved or rejected, Please all interested in present/share/hack with his projects there post in this tread, later on I will make a wiki page to try to organice it , until now we have 3 proposals, Qalee, FSO, #1024 rework. QtMoko, SHR, Hackable:1 any one? David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/10/26 Christophe M meumeu1...@gmail.com: Hi ! I think I can be there and help for anythink and, why not, present Qalee. David, do you want to move there ? Christophe 2009/10/26 Pieter Colpaert freep...@gmail.com Dear list, Saturday 6 and Sunday 7 February 2010 there is another FOSDEM. We (openmoko-community) haven't been to FOSDEM lately (correct me if I'm wrong) and that got to change. What about having our own devroom and give a sign to the world this community has not died since all what happened lately. So my question is: Who would like to come and represent openmoko? Any thoughts on FOSDEM? Pieter ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- -- Openmoko phone gui : http://www.qalee.org ___ 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: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) wrote: Also, I installed Qtv14 (thanks to Radek for that distribution), and that I see? I is fast enought, scrolls fast, react fast, and so on. So, scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. if you make the theme SIMPLER with just solid rectangles, like qt - efl will begin to be closer to the same speed. all that pretty stuff comes at a cost. and people want their pretty. tone down the theme to bare rectangles and text and it'll be faster. comparing qt and efl is apples vs oranges. efl simply does a hell of a lot more in the graphics department. and people are using that hell of a lot more AHAHAHAHAH.Guy, please go home I followed this thread and read too much bul***it but now it's very very interesting your position! So E it's a very optimized-full_of_fancy-magical-biggest window manager BUT all of his stuff works like Qt only if you don't use them! :D VERY FUNNY! Please stop spitting sh*t on the Glamo and the Freerunner, E is simply a pain-in-the-a** and nothing more. It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card Be serious please... E and E's programs just need optimizations. Openembedded in all sucks, as it brings no benefit (same glibc and kernel) with bunch of drawbacks - no easy way to compile for it, so (for me) it's uneasy to figure out that's going on with E. No oprofile where. you have no idea how many optimisations they have. saying they need them is like saying linux needs virtual memory! it just needs it!. it HAS it. in spades. read the code. you wont find routines for rendering faster in most of the world. (when it comes to software). the other engines can full offload to a subsystem (gl, xrender, etc. etc.) *IF* it is there. WHAT e is doing is different to qt because thats how it is being used. if you reduce what its doing to be the same as qt, you will find the speed becomes similar. the reason qt looks faster is that it is simply doing less. So E it's not as optimized ;) I prefer to reduce that doing-thing but have a responsive device instead of have to read the code to look how much is optimized to render like a Commodore 64 I wish E to be faster! Gennady. I wish E to be fired ;) I consider Glamo the worthiest thing Sean and his staff ever thought to add on the Freerunner but Qt with framebuffer are the proof that optimized and well written code is possible and even with Glamo some smooth and fancy GUI are possible... Nothing personal... Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 10:01:58 +0100 DJDAS dj...@djdas.net said: AHAHAHAHAH.Guy, please go home I followed this thread and read too much bul***it but now it's very very interesting your position! So E it's a very optimized-full_of_fancy-magical-biggest window manager BUT all of his stuff works like Qt only if you don't use them! :D VERY FUNNY! Please stop spitting sh*t on the Glamo and the Freerunner, E is simply a pain-in-the-a** and nothing more. It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card Be serious please... you show and immense amount of knowledge here, both of the hardware, of software and graphics in general. i'm amazed. i shall take your advice as you obviously are someone of massive experience. i see that people reporting that its faster and better on a gta01 @ 266 mhz (2/3 the cpu powerd), same screen and no glamo are obviously wrong. you indeed know much more. the smooth rendering on a 206mhz strong arm is obviously just incorrect and i'm a fool to think so. i shall be quiet and let your amazing skills make everything blindingly fast and smooth. -- - 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: Centralization of graphical awesomeness
DJDAS a écrit : It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). I beg to differ, your personal experience is not mine (E17 being damn fast comparing to xfce). E17 is fuck**g fast on limited hardware. I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card Be serious please... I think you miss the point : - qtmoko/qtopia is pretty because of good skin and good uniformity - qt in qtmoko is very simple (for example no transparency, no fancy controls...) - E17 as used in shr/om200x uses more advanced things than qt in QtMoko - E17 as used in shr/om200x is not as pretty as qt in qtmoko (well done qtopia team !) If you put the same things in both qt and E17 -- for example if you try to mimic qtmoko gui with E17 and if you disable everything in E17 that is useless in order to produce qtmoko gui-- E17 will be faster. A fast FR means a simple GUI and QtMoko is simple and pretty... I would say it's well balanced indeed, it fits well the FR. But E17 displaying same simple gui controls would be faster, no doubt. Xavier Cremaschi. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Thanks Xavier, for stopping what was going to be a flamefest. On Tue, Oct 27, 2009 at 10:23 AM, Xavier Cremaschi omega.xav...@gmail.comwrote: DJDAS a écrit : It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). I beg to differ, your personal experience is not mine (E17 being damn fast comparing to xfce). E17 is fuck**g fast on limited hardware. I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card Be serious please... I think you miss the point : - qtmoko/qtopia is pretty because of good skin and good uniformity - qt in qtmoko is very simple (for example no transparency, no fancy controls...) - E17 as used in shr/om200x uses more advanced things than qt in QtMoko - E17 as used in shr/om200x is not as pretty as qt in qtmoko (well done qtopia team !) If you put the same things in both qt and E17 -- for example if you try to mimic qtmoko gui with E17 and if you disable everything in E17 that is useless in order to produce qtmoko gui-- E17 will be faster. A fast FR means a simple GUI and QtMoko is simple and pretty... I would say it's well balanced indeed, it fits well the FR. But E17 displaying same simple gui controls would be faster, no doubt. Xavier Cremaschi. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Atilla Filiz Eindhoven University of Technology Embedded Systems, Master's Programme ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: FOSDEM2010
Content-Type: text/plain; charset=windows-1256 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Well I have full fill the form for ask for a devroom for the Openmoko-community on 2009-11-29 we will know if we were approved or rejected I already contacted the organisation quite a while ago to check if they were interested. Looking at their reply, which I received just recently, I would assume they'll be happy to welcome the Freerunner stuff. Niels. -- Re: Openmoko Freerunner Speaker/Devroomþ Van: Jan-Frederik Martens (jfmart...@fosdem.org) Verzonden: woensdag 21 oktober 2009 22:07:17 Aan: Niels Heyvaert (nielsheyva...@hotmail.com) CC: i...@fosdem.org Hi Niels, Sorry for the late reply but you know what they say: Better late than never! Would it be an option for you guys to include a speaker and/or a devroom time window for the Openmoko Freerunner? Sure we are open to all suggestions. If you know of someone closely involved with the development of this phone (hard or software) be sure to point them to the call for papers on our website http://fosdem.org/2010. As the matter of fact the Android platform will get a significant spot for the 2010 edition have a look at the site . Kind regards, Jan-Frederik -- Jan-Frederik Martens jfmart...@fosdem.org +32496959400 -- Fosdem 2009: 07 08/02/2009 _ Windows 7: helpt je meer voor elkaar te krijgen. Ontdek Windows 7. http://windows.microsoft.com/windows-7 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
I am thinking about giving a presentation about GNUstep/QuantumSTEP on Openmokos. GNUstep is also asking for a devroom, so don't know if I am allowed to give it twice :-) Am 27.10.2009 um 09:48 schrieb David Reyes Samblas Martinez: OK Tuxbrain will be there, :) so we have Qalee , and FSO presented by his creators, yummy Is not very clear yet but we had in mind to do a #1024 rework party in Barcelona after the FOSDEM , so we will try to make it in FOSDEM too, just to make clear this time the rework will not be for free, but we will try to adjust the price as much as possible. Well I have full fill the form for ask for a devroom for the Openmoko-community on 2009-11-29 we will know if we were approved or rejected, Please all interested in present/share/hack with his projects there post in this tread, later on I will make a wiki page to try to organice it , until now we have 3 proposals, Qalee, FSO, #1024 rework. QtMoko, SHR, Hackable:1 any one? +1 What about GTA02-core? David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/10/26 Christophe M meumeu1...@gmail.com: Hi ! I think I can be there and help for anythink and, why not, present Qalee. David, do you want to move there ? Christophe 2009/10/26 Pieter Colpaert freep...@gmail.com Dear list, Saturday 6 and Sunday 7 February 2010 there is another FOSDEM. We (openmoko-community) haven't been to FOSDEM lately (correct me if I'm wrong) and that got to change. What about having our own devroom and give a sign to the world this community has not died since all what happened lately. So my question is: Who would like to come and represent openmoko? Any thoughts on FOSDEM? Pieter ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- -- Openmoko phone gui : http://www.qalee.org ___ 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: ffalarms 0.3 -- recurring alarms
||
| Message|
||
||
| [Turn off slider] |
| [ACK slider] (*) |
||
| {Close button} (*) |
||
||
don't forget to fit in the Snooze slider too, please :)
Petr
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
Again, perhaps something thats suited to a config setting. When I set + configurable unlock shr-today upon wake up :) Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
Ok, openmobile.nl will be there too. Ghislain -- View this message in context: http://n2.nabble.com/FOSDEM2010-tp3895254p3898041.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: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) wrote: you show and immense amount of knowledge here, both of the hardware, of software and graphics in general. i'm amazed. i shall take your advice as you obviously are someone of massive experience. i see that people reporting that its faster and better on a gta01 @ 266 mhz (2/3 the cpu powerd), same screen and no glamo are obviously wrong. you indeed know much more. the smooth rendering on a 206mhz strong arm is obviously just incorrect and i'm a fool to think so. i shall be quiet and let your amazing skills make everything blindingly fast and smooth. Given that I never said to be an expert but simple telling my point of view as an end user, and given that I don't want to start a flame, I simply say that I work as an IT manager on embedded system since 2001, I wrote code for palmtops, mobile phones and more embedded devices like POS terminals and custom cards (always in C/C++), so I think I can speak with a bit of knowledge. I'm NOT a graphic expert (never said this) so all my respect to people who carve the bits and write graphic drivers and all the stuff rounding graphic world. My considerations were a bit of business-like words, because I think too many times you shut people complaints saying you bought a shit*y hardware so don't bother me and I don't think it's a winning approach (I won't say to a customer you fool, you bought a bad phone so my fantastic program doesn't work because of you). Technically speaking I didn't look at your code (and won't) so I don't criticize how it's written/commented/optimized and so on, I criticize your approach and, let me say, I would prefer you said something like I preferred to write some *specifically* for the Freerunner but someone told me not to because of business choices instead of I tried to adapt something working perfectly (which is not for me, indeed) on a loser device :) It's simply a matter of approach. I repeat nothing personal, just some suggestions ;) Bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Tuesday 27 October 2009, Petr Vanek wrote:
||
| Message|
|
|
| [Turn off slider] |
| [ACK slider] (*) |
|
| {Close button} (*) |
|
||
don't forget to fit in the Snooze slider too, please :)
It shouldn't need a separate slider. If you turn off but don't ACK it should
be equivalent to a snooze.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
I think this post should be very helpful in optimizing our distros (SHR first - 'cause i seems to be the most used). Thanks for the helpful hints, but maybe now we should move in producing something that works for all, something as a click and enjoy approach. Thanks (hope that some shr-dev are listening) d ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Please wait... (WAS: [QtMoko] Calling problems)
When I boot into QtMoko v14 without a sim card(and sometimes with a sim card) The home screen gets stuck at PIN dialog, saying Please wait... I can hold the AUX button and run applications by adding them to my favourites first, but when I try to go home, I go to the Please wait... screen. I think this is connected to the calling problem somehow. I didn't have time to try with a sim card again, as I keep my only sim card(Vodafone NL) in my other phone. On Tue, Oct 20, 2009 at 2:11 PM, ghislain ghisl...@basetrend.nl wrote: Radek Polak wrote: Definitely it should be there. Btw do you have latest gsm firmware? In System info the modem should display Revision: gsm_acts0-Moko11 That's not entirely true, I have a SIM-card (Vodafone, prepaid, NL) which if used under QtMoko it does'nt show the modem-info. The SIM-card works correctly, I can make phonecalls, receive calls, send / receive SMS, use GPRS etc, but there is no info under the modem-tab. When I use another SIM (KPN-NL) on the same phone, I can see the modem-info. -- View this message in context: http://n2.nabble.com/QtMoko-Calling-problems-tp3844430p3858530.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 -- - Atilla Filiz Eindhoven University of Technology Embedded Systems, Master's Programme ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Regarding the whole discussion. I would rather have a glamo chip that's 10x slower and be able to receive phone calls and text messages. Seriously, the whole software stack all the way from the bootloader to the GUIs (ok not all of them) is in alpha stage. Why bitch about slow hardware? 2009/10/27 Davide Scaini dsca...@gmail.com I think this post should be very helpful in optimizing our distros (SHR first - 'cause i seems to be the most used). Thanks for the helpful hints, but maybe now we should move in producing something that works for all, something as a click and enjoy approach. Thanks (hope that some shr-dev are listening) d ___ 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: [QtMoko] Calling problems
Yes, I see my A5 modem there, without my simcard. I didn't try looking there with simcard yet. On Tue, Oct 20, 2009 at 8:16 AM, Torfinn Ingolfsen tin...@gmail.com wrote: Hi, On Mon, Oct 19, 2009 at 9:08 PM, Atilla Filiz atilla.fi...@gmail.comwrote: That wasn't the case with me. My FR didn't respond for about 20 seconds, and it wasn't suspended. I also couldn't call other pnoes, 3 times in a row. Something seems wrong with the modem. Ok. Does your modem show up in Applications - System Info (under the Modem tab)? -- Regards, Torfinn ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Atilla Filiz Eindhoven University of Technology Embedded Systems, Master's Programme ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Bah, I write too slowly. Started when this mail arrived, didn't read the other responses yet... This seems to be, in part, an issue of talking about different things... (see below) On Tuesday 27 October 2009 10:01:58 DJDAS wrote: Carsten Haitzler (The Rasterman) wrote: scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. if you make the theme SIMPLER with just solid rectangles, like qt - efl will begin to be closer to the same speed. all that pretty stuff comes at a cost. and people want their pretty. tone down the theme to bare rectangles and text and it'll be faster. comparing qt and efl is apples vs oranges. efl simply does a hell of a lot more in the graphics department. and people are using that hell of a lot more AHAHAHAHAH.Guy, please go home I followed this thread and read too much bul***it but now it's very very interesting your position! So E it's a very optimized-full_of_fancy-magical-biggest window manager BUT all of his stuff works like Qt only if you don't use them! :D VERY FUNNY! Your wording is far nastier than needed, but you're still sort of correct - E works *like Qt* only if you don't use those parts of E that Qt doesn't have (or doesn't use). However, in this case, people are doing things with E that they aren't doing with Qt (possibly because Qt can't do those things?), leading to more work for E than for Qt, and do you *really* believe that it's possible to do more work in the same or less time, all other things being equal? Please stop spitting sh*t on the Glamo and the Freerunner, E is simply a pain-in-the-a** and nothing more. It never NEVER worked in an acceptable manner in EVERY my desktop system since 4 years (with nVidia graphics cards, not GLAMO or Freerunner), Compiz+XFCE are light-years way faster and optimized than that E's bunch of uncommented and always-in.beta (and not standards compliant) code... Please don't fool our brains and simply admit you are not able to work on embedded systems as on desktop (and personally I've got some doubts even on this). You seem to be the one comparing desktop and embedded performance here... And if Compiz+XFCE is so much better than E, why aren't you using that instead of E on the FR? Oh, right... Compiz doesn't work there, does it? Yet, E does. I can't accept to read something like my code is highly optimized BUT as you have a shi**y device you cannot run on it unless you deactivate all its featuresgo work in Micro$oft and write their optimized Aero GUI pretending to work on a 10Ghz quadcore Cray processor with 1TB RAM and 4 graphics card That's not what he seems to be saying to me. Seems more like with this badly performing device, you can still use the features if you want, but don't expect it to be fast - if you want fast, don't use the fancy features. Basically, there's a tradeoff between fancy features and speed. Fancy features = more work, and more work = more time used. The way I see it, if Qt was configured to do the same things as E is doing in the current GUI (assuming it's even capable of doing those things), it would be at least as slow as E is. Conversely, if E was configured to only do the things Qt is, it would do them as fast as Qt is. Qt being fast thus being a result of it not using the fancy features, such as alpha blending with a background image (which E is doing). Be serious please... Same to you. To me, you don't seem to be acting very seriously in this mail. you have no idea how many optimisations they have. saying they need them is like saying linux needs virtual memory! it just needs it!. it HAS it. in spades. read the code. you wont find routines for rendering faster in most of the world. (when it comes to software). the other engines can full offload to a subsystem (gl, xrender, etc. etc.) *IF* it is there. WHAT e is doing is different to qt because thats how it is being used. if you reduce what its doing to be the same as qt, you will find the speed becomes similar. the reason qt looks faster is that it is simply doing less. So E it's not as optimized ;) I prefer to reduce that doing-thing but have a responsive device instead of have to read the code to look how much is optimized to render like a Commodore 64 You're comparing apples to oranges - optimized code with optimized-for-the- device GUI. The two are vastly different things, with different solutions. Configuring which features to use is an issue of optimization - optimizing the GUI for the (limitations of the) device and the desires of the users. An example of a GUI optimization that could be done here, is dropping the background image (the gradient) from the launcher, and using a solid color instead - if done
Re: Centralization of graphical awesomeness
Xavier Cremaschi wrote: I beg to differ, your personal experience is not mine (E17 being damn fast comparing to xfce). E17 is fuck**g fast on limited hardware. World is beautiful because it's various ;) I think you miss the point : - qtmoko/qtopia is pretty because of good skin and good uniformity Because it's well studied and designed - qt in qtmoko is very simple (for example no transparency, no fancy controls...) I prefer to not have transparency if this would result in more than 10fps in GUI responsiveness (not calculated but perceived which is what end user counts on) - E17 as used in shr/om200x uses more advanced things than qt in QtMoko At which cost? - E17 as used in shr/om200x is not as pretty as qt in qtmoko (well done qtopia team !) You answered yourself ;) If you put the same things in both qt and E17 -- for example if you try to mimic qtmoko gui with E17 and if you disable everything in E17 that is useless in order to produce qtmoko gui-- E17 will be faster. My experience in embedded devices is don't disable something, REMOVE it because it costs CPU, memory and can cause more bugs, or better rewrite it in order to squeeze that fuc*ing hardware A fast FR means a simple GUI and QtMoko is simple and pretty... I would say it's well balanced indeed, it fits well the FR. But E17 displaying same simple gui controls would be faster, no doubt. This doesn't mean E17 is written better than qt, but the exactly opposite ;) Please consider I don't want to start a flame war, listen to my previous answer to Raster for many comments to my previous words :) Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tuesday 27 October 2009 11:47:22 DJDAS wrote: Xavier Cremaschi wrote: A fast FR means a simple GUI and QtMoko is simple and pretty... I would say it's well balanced indeed, it fits well the FR. But E17 displaying same simple gui controls would be faster, no doubt. This doesn't mean E17 is written better than qt, but the exactly opposite I think there's a terminology problem here, that probably causes some confusion. E17 is not the name of the interface. It is the name of the libraries used to build the interface. The standard home interface on SHR, which uses E17, is called Illume, I believe. Thus, what I think you mean, is that while E17 may have faster code than Qt, *Illume* (the interface) is not written better than the Qt-based interface, because it uses too many of the features (such as the earlier mentioned transparency), instead of being well adapted to the FR (to be responsive). -Frode ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Hi guys ! I don't want to feed the troll but lets compare what's comparable ... You compare Qt framebuffer with E over Xorg ... In one case you have a Xorg who is running in the other it's directly accessed ... To compare, let's take ( for example :) ) Qalee it run a Qt over Xorg with transparency, ... When developing it I've made some tests, everything that's move on the screen is slooow and it's even more slow when we have transparency effect applied. So during the development I've banned scrolling and thinks that are moving. The feedback I received is that it's more fast than other thinks ( except Qtmoko, no X ). I personally think the problem is not the toolkit ( but no, I don't like E ), I think Qt can do the same thinks (or more?) as fast as Enlightenment It's the way it's developed. We have an hardware that is slow for some reason ( graphic drivers ?, hardware problem?, ... ), we have to work with it ( and think how get can improve it ), so don't take an application that work on other hardware and push it as it on the phone and complain it's slow, if you like E, just remove thinks that doesn't work on the freerunner ... or use Qalee :) Christophe -- -- Openmoko phone gui : http://www.qalee.org ( Last alpha before first stable core release coming soon ) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 11:11:04 +0100 DJDAS dj...@djdas.net said: Carsten Haitzler (The Rasterman) wrote: you show and immense amount of knowledge here, both of the hardware, of software and graphics in general. i'm amazed. i shall take your advice as you obviously are someone of massive experience. i see that people reporting that its faster and better on a gta01 @ 266 mhz (2/3 the cpu powerd), same screen and no glamo are obviously wrong. you indeed know much more. the smooth rendering on a 206mhz strong arm is obviously just incorrect and i'm a fool to think so. i shall be quiet and let your amazing skills make everything blindingly fast and smooth. Given that I never said to be an expert but simple telling my point of well.. you're telling the one that wrote the graphics code, that has read the glamo hw docs, has worked on it long before freerunner was on sale, who has written graphics code for many platforms, manye cpus of many varying levesl of speed (from 7mhz 68k up), many gpu's from old console hardware to 3d gl... that he's talking bullshit (and being very rude about it, providing no evidence, numbers or anything else to back anything you say up) about exactly the things he's deeply involved in. thus.. you must be an expert beyond my experience and abilites. you, sir, are rude. that much i definitely know about you. the rest. you have no idea of what you speak. you showed it in your previous mail. your opinions on this are the equivalent of me giving my opinions on tcp stack design. worthless. the other people in this thread have actually read what i said and gotten it right. but you, have not. you have simply resorted to an incredibly rude and disrespectful outburst. with no provocation. if you are an IT manager, i am amazed you got that far and stayed. it's one thing to be frank and be factual. it's another to behave like you. if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. i have been factual, realistic and constructive. i have stated that freerunner is a limited platform. it's one of the slowest (if running at its native resolution i have ever worked on, and i've worked on a fair few. there is a limited amount you'll get out of it. and it's not an architecture you're going to see again. so how much effort do you put into a 1 -off that will not gain more units in the general user population over time? you find quick ways to make it do what you want. i have constructively suggested those - 1. simplify theme so its solid rects and text and it will look like qtopia.. and begin to run like qtopia does. but it is NOT being used like that. people are using themes that have scaled image backgrounds and buttons and list items with multiple layers of graphics rendered on top of eachother. make this simple and.. speed will follow. no one has to go change their toolkits and listen to you. the other easy and feasible option is lower resolution - draw fewer pixels and you'll get more speed. these are developers talking to other developers. i am telling 1. the users and developers that insist on vga, that they are paying a high price for their insistence. the hardware simply wasnt designed to be optimal on vga. trust me. i've read the glamo docs. vga is the top LIMIT of its capabilities. it's being stretched. these developers ALSO decide the themes they use as part of building SHR for example. the default is a generic default - it's not tuned for really slow systems. tune away for what you have. i havent shut anyone up. i have told them they are stuck with slow hardware. don't expect miracles. make a sacrifice. the device, the theme or the resolution. choose the lamb for the slaughtering. enlightenment and illume have seen pretty close to zero attention since i left openmoko. it's a BUSINESS CHOICE. no one is paying me to work on it. i am getting paid to put EFL on significantly superior devices that handle it wonderfully. everyone i talk to in the world of actually producing products, and with whom i work, aim far beyond openmoko. they want gui's that are smooth, silky, fluid and beautiful. they have ui designer requirements for things like translucent lists with static backgrounds. EFL does for them what no other toolkit can do. MEET BUSINESS REQUIREMENTS. if you like to use that word. and it's doing that wonderfully for them. the benefit to the openmoko users and community is that the work to improve things there gives them improvements too. it also paves the way for when SHR and so on are fully ported to better devices, like the palm pre for example. GTA02 in comparison to a palm pre is a very very very weak device... except in 1 respect. screen resolution. as for e17 not runing on any desktop acceptably. i really have to laugh at that, as i have had it run acceptably on an hp mini-note 2133. 1 ghz via c3. really slow. e is just fine on it. just compile and run. compiz doesn't even
Re: Centralization of graphical awesomeness
On Tue, Oct 27, 2009 at 04:42:21PM +1100, Carsten Haitzler wrote: On Tue, 27 Oct 2009 06:31:26 +0100 ri...@happyleptic.org said: -[ Tue, Oct 27, 2009 at 11:52:04AM +1100, Carsten Haitzler ] E is nice thing, but it look like highly unoptimized. i beg to differ. it's more optimised than pretty much anything out there. scrolling is different in qt. it is a simple blit. in efl it's a redraw. efl is very much like GL. you get a lot of power and abilities with it, but you do pay a price for it. unlike qt, efl's scrollers have smoothly scaled item contents, backgrounds, translucency and everything. So, probably unoptimized is not the right term. Maybe it's just _inapropriate_ to do these things on such a device, and that E, because it does so many things, is not such a good choice however optimized it may be ? Or maybe people really want it that way, unusable but good looking ? well as i said. it works fine and fluidly on many other devices. you are free to ditch efl and use gtk or qt if you want. it's your choice. of course if you are not developing apps... it's kind of not your choice :) but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. I personally belive that the gta02-core project is a wonderful idea and that Openmoko Inc should have done it that way from the start. So in terms of openness and freedom this is a big step forward and I hope we will eventually see a gta03 (even a gta02 without glamo as the current plan is should improve graphic performance as you previously explained). Besides there are no real alternatives which provides the same kind of openess. So all in all I think we should focus on getting the best out of our current open platform this will at the same time guarantee that it will be lightening fast on a newer device. Marc -- Marc Andre Tanner http://www.brain-dump.org/ GPG key: CF7D56C0 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tuesday 27 October 2009 12:46:01 Marc Andre Tanner wrote: but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. I personally belive that the gta02-core project is a wonderful idea and that Openmoko Inc should have done it that way from the start. So in terms of openness and freedom this is a big step forward and I hope we will eventually see a gta03 (even a gta02 without glamo as the current plan is should improve graphic performance as you previously explained). +1 Besides there are no real alternatives which provides the same kind of openess. So all in all I think we should focus on getting the best out of our current open platform this will at the same time guarantee that it will be lightening fast on a newer device. +1 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher Release 0.39
Hi, vendion wrote: Yea the version that I have is libelementary-ver-svn-04.so.0 so I had to create the soft links to get it to work How did you get to svn-04? i've been updating regularly and I don't get any updates! Selective updating - that's a new one ;-) From what I know, the mrmoku testing images are using these libs - I haven't gotten around to using them with all the travelling I'm doing currently (hence the delays in replying too). So I really cant help you there - In fact there might be more regressions if opim has changed too. Petr Vanek wrote: no problem, here it is, including a few highlighted comments: http://pastebin.com/m31f4202e These seem to be e-dbus errors - and with them, probably, nothing will work. Can you confirm they're been resolved or not? Mario Huelsegge wrote: Hi, i just tried out the launcher, and the contacts application seems to have problems with opimd tel. number fields different from phone. Programs like opimd-contacts and pisi sync use names like Home phone and Cell phone. Can you give me more specific examples of the field types? The standard field was supposed to be tel:number. Just point me how it is in other apps and I'll modify launcher to support those. @KaZeR - Those should be one off errors and wont cause any harm. I've been making changes to the db and now there are so many different versions - it's getting a little difficult to test :-) But no data is lost. -- View this message in context: http://n2.nabble.com/Launcher-Release-0-39-tp3859743p3898629.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: Launcher Release 0.39
Hi, Well, I've been thinking about making a few more changes like :- 1. a second screen to the right that shows up on a finger slide with the category toolbar and program icons 2. a home screen with :- (a) some widgets (weather, facebook etc) (b) lists for tasks/calendars/events etc (c) a grid based (drag and drop) layout for some regularly used apps In order to do this, I need pointers / ideas / help about :- 1. how to implement a C framework that can be used by other dev's / users to create widgets using e17 2. help in creating the theme / edge files 3. maybe some pointers to code I can re-use All ideas, code and pointers (and anything else however whacky) are welcome. I do need some coding help too - launcher is getting rather large for me to maintain - and has a lot of poor design decisions that need rework too. -- View this message in context: http://n2.nabble.com/Launcher-Release-0-39-tp3859743p3898668.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: Centralization of graphical awesomeness
On Tue, Oct 27, 2009 at 6:42 AM, Carsten Haitzler ras...@rasterman.com wrote: I would only rise couple of points here: Scrolling is not optimized at the maximum. Look at ipod or nintendo DS, they do *discrete* scrolling and it is amazingly fast. They dont do kinetics, or pixel perfect scrolling like iphone. Also on a side note if the content is a bit bigger, the scrolling is exponentially slows down... but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. Lets count the elementary apps here. How many of them written for the Freerunner? Sad true: almost all usable elementary app are written for the Freerunner. Where are the other future devices to developing for? There is none. Maybe Palm Pre reverse engineering will change things a little, but its only a hope right now. (and also a dead-end, as the Palm Pixi is a no-go, and probably the future devices will be also) So fixing some annoying things because of the Freerunners actually makes sense, as we are a huge e userbase with a couple of *usable* real world apps. Not demos;-) In my personal view, even the Freerunner would be 10 times better hardware-wise, would not change to many things. As the lowlevel apps is getting in usable shape just now. I can use my phone like a month *reliably* thanks to frameworkd. I think in a year or so we will grow out the Freerunner. But until then there is a lot of small usable apps to write!;-) Best regards, Laszlo ps: Im still figthing with the bad audio experience after 7(!) months... Yeah, the Freerunner could be better. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tuesday 27 October 2009, DJDAS wrote: Xavier Cremaschi wrote: - qt in qtmoko is very simple (for example no transparency, no fancy controls...) I prefer to not have transparency if this would result in more than 10fps in GUI responsiveness (not calculated but perceived which is what end user counts on) Then use a theme that doesn't use transparency! Bernd Prünster has done great work on producing themes that run much faster than the default while still looking good. They don't degrade with the 16 bit renderer either, and that runs even faster. The themes should be in the shr repos by now. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, Oct 27, 2009 at 10:01 AM, DJDAS dj...@djdas.net wrote: AHAHAHAHAH.Guy, please go home I followed this thread and read too much bul***it but now it's very very interesting your position! So E it's a very optimized-full_of_fancy-magical-biggest window manager BUT all of his stuff works like Qt only if you don't use them! :D VERY FUNNY! Dude, what is lacking in your comment is some respect. Raster has some deep knowledge in graphical libraries, and more then 10 years of experience. So raster knows more then most of us will ever learn in his whole life...;-) Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher Release 0.39
c_c wrote: Hi, Well, I've been thinking about making a few more changes like :- 1. a second screen to the right that shows up on a finger slide with the category toolbar and program icons 2. a home screen with :- (a) some widgets (weather, facebook etc) (b) lists for tasks/calendars/events etc (c) a grid based (drag and drop) layout for some regularly used apps In order to do this, I need pointers / ideas / help about :- 1. how to implement a C framework that can be used by other dev's / users to create widgets using e17 2. help in creating the theme / edge files Just tell me how you want it to look like and i'll do it. 3. maybe some pointers to code I can re-use All ideas, code and pointers (and anything else however whacky) are welcome. I do need some coding help too - launcher is getting rather large for me to maintain - and has a lot of poor design decisions that need rework too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
I am sorry, but my letter is not about trolling and blaming but about optimization, qt and e, speed is interesting for me, not blaming. Calm down guys! I've numbered separate points overwise my letter will look endless :) 1. First, bit about qt scrolling - It's not so simple Carlsen want it to be. I see background image, rendered text and 1-2 relativaly small image each line. Apllications menu have ~40 entries. All scrolling very smooth, and no rectangles where. Carlsen, have you run qtmoko? Buttons are changing only then you press them. What prevents E from prerendering contents of scrollable area, it is not changing on the fly? Lack of this optimization makes menus and scrollable areas much slower. 2. Second point of my letter was that Glamo seem should not be blamed for everything. I wrote simple program to measure simple memcpy speed on om... This program just allocates 2 buffers of defined size and outputs count of memcpys of defined size it did in 1 second (interrupt via alarm()). Initally I want to see how arm cache cleanup and task switch influences parallel memory access tasks. Result were surprising for me: OM: buffer_size average_number computed_throughput 128 1260880 153Mb/s 256 540900 132Mb/s 512 252399 123Mb/s 1024 121988 119Mb/s 2048 58827 114Mb/s 4096 29000 113Mb/s 8192 14000 109Mb/s 16384 3660 57Mb/s 32768 1105 36Mb/s 65536 553 34.5Mb/s 131072 274 34.2Mb/s 262144 135 33.7Mb/s 524288 69 34.5Mb/s I did same test on my very-old-Celeron 600 router: 256 2522958 615Mb/s 512 2088723 1019Mb/s 10241554162 1571Mb/s 20481019996 1992Mb/s 3072762667 2234Mb/s 4096109489 427Mb/s 16384 27389 427Mb/s 262144 318 79Mb/s 524288 151 75Mb/s 1048576 76 76Mb/s On desktop (xeon 2Gz): x64 binary: 26214400 74 1850 Mb/s 262144 31971 7992 Mb/s 256 5399451213232 Mb/s x32 binary: 2621440059 1475 Mb/s 262144 29068 7267 Mb/s 256 20810406 5080 Mb/s Old arm-based device at my work (at91rm9200, 180Mhz) 256 16 39Mb/s 256000 167 40Mb/s 256 418044 102Mb/s So, we can see that we have speed of 34Mb/s (it's ever only 5 times declared 7Mb/s for Glamo!) can someone comment? why memcpy is so slow - it is 2 times slower than ancient celeron, and on par with very old arm-based machine, it is not related to glamo anyhow! We can even skip results with cache, where om 10 times slower old machine. 3. ... e - every N seconds (see config dialogs for what it is set to there, but let's say 60 seconds) will flush caches. ... and things are having to be repopulated from disk ... From disk?! This is cost or having small memory footprint? This looks very wrong. 3. ... Actually, yes the GTA01 is very noticeably faster in graphics. ... Can you expose a bit more details: How much it is faster: x2 times, x3, x1.5, x1.2? 4. ... for every second spent uploading contents to glamo, you CANNOT spend it calculating a new fram. ... Yes, this is bad... But qt works :) 5. ... that's because you have 2 processes competing for the cpu to render. ... My measurements of parallel memcpy showed that this is neglibible. 6. ... you wont find routines for rendering faster in most of the world. ... I will. I can recall you previous posts on the topic. 7. but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. and these don't suck with EFL. i'd not compromise the future if i were smart. Frankly speaking you never developed for GTA02, yes? you aim seem always were in future, and this is ok. I am sure that for example scrolling area pre-rendering if good for future. 8. ... most games i know of are written to work on the highest end graphics cards at the time. why? ... Best games are written with other objectives in mind, this games are really interesting for anyone from time to time and for sure will live in ages (chess, nethack and so), our grandchilds will play nethack, be sure. Is it better to make pefrect things? And optimization is always good - you can feel that 10ms latency and 100ms latency is different even both are more than enoght for UI, but you feel that 10ms latency is much better. 9. ... BUSINESS CHOICE ... Everyone here follows it's goals. Carlsen make E. Other want to do hardware. Others want to use free hardware. Others want to increase development skills and hack that HW. Others just feel fun reading this book. Others have this job. Someone even makeing money from OM. ;) All this is ok, and I see nothing bad on making some great E developer to think a bit about optimizations - nobody loose from
Re: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) wrote: well as i said. it works fine and fluidly on many other devices. Even Windows Vista works fine and fluidly on 3000$ desktops this doesn't mean it's optimized ;) but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. and these don't suck with EFL. i'd not compromise the future if i were smart. Let me you know that in nowadays payments system about 70-75% POS terminals run on Z80 processor or Motorola 68k family...when you stripe your card the system reads the magnetic stripe/microchip (handling security encryption stuff) calls the banking server, communicates with the cash register shows you the PIN request and prints the receipt...there is no need for a quad core to do these things concurrently ;) Personally, before buying the Freerunner I had a Nokia 3650 for 4 years, so I'm not one of those who need the latest hardware to run the latest software which does nothing more than add fancy icons providing the same functionalities and costing double than the previous one...so when I'll have the need to buy a new device probably OM or someone else will provide me a new OPEN hardware (this is what I really need, nothing more) to develop, and use, OPEN software :) why are you not complaining that linux sucks on an 8086 on your desktop? Because Linux doesn't sucks on an 8086 ;) because Linux is well designed, is scalable, is optimized and can run even on a 8086...Desktop is another thing, I don't need compiz or E to show a window with two buttons to connect my wifi or calculate my monthly expenses, this is only a commercial stuff, not for me ;) because hardware moved on. most games i know of are written to work on the highest end graphics cards at the time. why? Because software houses and hardware manufacturers have to sell something to stay on business ;) we are talking about an open platform to develop and use open software on, not on selling an iPhone ;) by the time the game is out and is selling - everyone has finally upgraded to those cards. they were top end 3 years ago when game design started. now they are low to middle end. gta02 is a a middle end device that came out 4-5 years after its components were middle end - except the LCD. you have a 4-5 year old set of components driving a high end screen. you will pay a cost. the developers are smart if they look forward to where hardware will be in N years and make sure they are on the right path for that. if it works now with some tuning and simplification of things like themes - then great. their code, apis and logic dont need a rewrite every few years. This is only commercial stuff, I don't want to sell nothing to anyone, just develop for fun and use my Freerunner as a phone without the need to wait 3 seconds to answer a call... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Laszlo KREKACS ha scritto: Lets count the elementary apps here. How many of them written for the Freerunner? Sad true: almost all usable elementary app are written for the Freerunner. I think in a year or so we will grow out the Freerunner. But until then there is a lot of small usable apps to write!;-) Best regards, Laszlo +100 ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Christophe M wrote: Hi guys ! I don't want to feed the troll but lets compare what's comparable ... You compare Qt framebuffer with E over Xorg ... In one case you have a Xorg who is running in the other it's directly accessed ... Not true, because if Raster was right the only problem would be the Glamo chip so I would like to say why there are so many differences between Qt and E ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Al Johnson wrote: On Tuesday 27 October 2009, DJDAS wrote: Xavier Cremaschi wrote: - qt in qtmoko is very simple (for example no transparency, no fancy controls...) I prefer to not have transparency if this would result in more than 10fps in GUI responsiveness (not calculated but perceived which is what end user counts on) Then use a theme that doesn't use transparency! Bernd Prünster has done great work on producing themes that run much faster than the default while still looking good. They don't degrade with the 16 bit renderer either, and that runs even faster. The themes should be in the shr repos by now. I Fixed nEo theme bubbles, but i will have to write phoneui themes (saill waitin for mrmoku to implement themability in phoneui) gry* was adapted to work with new elm version. nEo and gry is in the mrmoku feeds, so just wait for the new unstable and you'll have fast themes in shr repo (i am going to ask mrmoku to put the current version of nEo and gry* theme into current shr-u feeds. the nEo theme has some problems (badly designed edc code to begin with, complicated installation because libframeworkd-phonegui-efl is not really themable.) by the way gry* is even closer to what raster said use rects without scaled images gry* doesn't even use images to render buttons, the are drawn on the fly and look better than anythign i ever seen using software_16. the default theme is simpyl nto optimized for slow devices like the freerunner (i think i counted 5 layers including text for something as simple as a button and not just 4 layers of somethung but 4 layers of which 4 use translucency, of which at least 1 is animated) if you want to know what happens if you kick all that stuff out try the nEo theme or the gry* theme, which both still can be optimized (current gry* version in development has even faster scrolling!) elementary apps are faster than gtk apps, the render faster, they scroll faster (using a proper theme), so i think i can say that raster cannot be talking plain bullshit! (although in the past i was really pissed at him for a couple of things he said and HOW he said it, so i am not his biggest fan, but i can only bow if i look at how powerful the tools are efl puts into my hands and how little ressources they use) and for xfce+compiz compared to efl: ever wondered why the rendering engines are called SOFTWARE? and why compiz requires opengl? go figure! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 17:11:08 +0300 Gennady Kupava g...@bsdmn.com said: I am sorry, but my letter is not about trolling and blaming but about optimization, qt and e, speed is interesting for me, not blaming. Calm down guys! I've numbered separate points overwise my letter will look endless :) 1. First, bit about qt scrolling - It's not so simple Carlsen want it to be. I see background image, rendered text and 1-2 relativaly small image each line. Apllications menu have ~40 entries. All scrolling very smooth, and no rectangles where. Carlsen, have you run qtmoko? Buttons are changing only then you press them. What prevents E from prerendering contents of scrollable area, it is not changing on the fly? Lack of this optimization makes menus and scrollable areas much slower. scrolling isnt any special operation in efl. it's moving some objects around. that's all it is. a scroller just moves its child around. moving an object queues redraws for previous and current positions. evas' merges all redraws at render time and just does them. it will avoid drawing things that will be later overwritten by solid pixels. as long as it knows that they are solid (eg solid rect, image without an alpha channel etc.) scrolling is done very differently. you can't pre-render as they get rendered on the fly. everythign does. evas has caches to save copies of scaled images (if smooth scaled) to save computation making the smooth when scaling on every redraw. but it's still a draw. this is done this way because it is increidbly flexible. you get the ability to have translucent items and all sorts of goodies. a draw in the end is a copy from some source and a write to a dest in evas. the more reads you do and writes - the worse it gets. worse is alpha blend as its read source, dest then write to dest (after some calculations). now... if your list in elementary had NO backgroun except the selecte item ALL it woudl do it draw the changes in test items - ie fill in the background (solid color would be writes onlt, image woudl be read then write) and then draw text on top (an alpha blend op with source data being only 8bit alpha). and this only for where the text is. for qte/qtopia/qtwhatever it is called now, if you have a background that moves with the text that scrolls, then it is a simple copy (copy current area up N pixels or down) thus a read and write, then draw new area. if the display is with a static bg and scrolling text - it's the same as evas. evas's scroling is ONLY this method. if you configured the theme to be the same as qt (from memory it was solid black bg's etc.) you'd end up with approximately the same speed. evas would do a bit more work as it'd alpha blend the text, but it would avoid copying areas of the list that didnt change (eg strings dont fill the entire line and only part of it). it's Carsten btw. t not l :) and i have run qtmoko... before the freerunenr was even out. i tememebr it being orange for selected list items (rectangle), empty if not (just text) and a greyish qt logo background with some visible dither patterns on scale up. 2. Second point of my letter was that Glamo seem should not be blamed for everything. I wrote simple program to measure simple memcpy speed on om... This program just allocates 2 buffers of defined size and outputs count of memcpys of defined size it did in 1 second (interrupt via alarm()). Initally I want to see how arm cache cleanup and task switch influences parallel memory access tasks. Result were surprising for me: glamo is one of the big problems. a write to video memory - eg a new screen fram is.. based on your numbers below, about 1/5h the speed. it is as IF you copied 5x the data from memory to memory. thats a heavy cost. OM: buffer_size average_number computed_throughput 128 1260880 153Mb/s 256 540900 132Mb/s 512 252399 123Mb/s 1024 121988 119Mb/s 2048 58827 114Mb/s 4096 29000 113Mb/s 8192 14000 109Mb/s 16384 3660 57Mb/s 32768 1105 36Mb/s 65536 553 34.5Mb/s 131072 274 34.2Mb/s 262144 135 33.7Mb/s 524288 69 34.5Mb/s only the last really counts. the first are just caching effects. I did same test on my very-old-Celeron 600 router: 256 2522958 615Mb/s 512 2088723 1019Mb/s 10241554162 1571Mb/s 20481019996 1992Mb/s 3072762667 2234Mb/s 4096109489 427Mb/s 16384 27389 427Mb/s 262144 318 79Mb/s 524288 151 75Mb/s 1048576 76 76Mb/s yes. better. the 2442 in the gta02 is an ooold arm cpu. it's not too modern. given when the gta02 was released... it'd like making a pentium4 laptop and releasing it and selling it as new in todays shops. On desktop (xeon 2Gz): x64 binary: 26214400 74 1850 Mb/s 262144 31971 7992 Mb/s 256 5399451213232 Mb/s x32 binary: 2621440059 1475 Mb/s 262144 29068
Re: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 15:51:48 +0100 DJDAS dj...@djdas.net said: Christophe M wrote: Hi guys ! I don't want to feed the troll but lets compare what's comparable ... You compare Qt framebuffer with E over Xorg ... In one case you have a Xorg who is running in the other it's directly accessed ... Not true, because if Raster was right the only problem would be the Glamo chip so I would like to say why there are so many differences between Qt and E ;) i never claimed the glamo was the only problem. get your facts right. try reading first. it's a handy skill. -- - 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: Centralization of graphical awesomeness
On Tue, 27 Oct 2009 15:47:02 +0100 DJDAS dj...@djdas.net said: Carsten Haitzler (The Rasterman) wrote: well as i said. it works fine and fluidly on many other devices. Even Windows Vista works fine and fluidly on 3000$ desktops this doesn't mean it's optimized ;) but.. if i were smart.. i'd not develop apps for the freerunner. it's a dead product. it has no more being produced. it has no evolution path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let go from om that worked on phones.. or worked on pretty much anything. your future is other devices.. and these don't suck with EFL. i'd not compromise the future if i were smart. Let me you know that in nowadays payments system about 70-75% POS terminals run on Z80 processor or Motorola 68k family...when you stripe your card the system reads the magnetic stripe/microchip (handling security encryption stuff) calls the banking server, communicates with the cash register shows you the PIN request and prints the receipt...there is no need for a quad core to do these things concurrently ;) Personally, before buying the Freerunner I had a Nokia 3650 for 4 years, so I'm not one of those who need the latest hardware to run the latest software which does nothing more than add fancy icons providing the same functionalities and costing double than the previous one...so when I'll have the need to buy a new device probably OM or someone else will provide me a new OPEN hardware (this is what I really need, nothing more) to develop, and use, OPEN software :) why are you not complaining that linux sucks on an 8086 on your desktop? Because Linux doesn't sucks on an 8086 ;) because Linux is well designed, is scalable, is optimized and can run even on a 8086...Desktop i think you just illustrated my point where i don't think you know what you are talking about. an intel 8086 can't run linux. a linux requires a minimum of an 386 with mmu. the 8086 was a 16bit precursor to it. is another thing, I don't need compiz or E to show a window with two buttons to connect my wifi or calculate my monthly expenses, this is only a commercial stuff, not for me ;) because hardware moved on. most games i know of are written to work on the highest end graphics cards at the time. why? Because software houses and hardware manufacturers have to sell something to stay on business ;) we are talking about an open platform to develop and use open software on, not on selling an iPhone ;) by the time the game is out and is selling - everyone has finally upgraded to those cards. they were top end 3 years ago when game design started. now they are low to middle end. gta02 is a a middle end device that came out 4-5 years after its components were middle end - except the LCD. you have a 4-5 year old set of components driving a high end screen. you will pay a cost. the developers are smart if they look forward to where hardware will be in N years and make sure they are on the right path for that. if it works now with some tuning and simplification of things like themes - then great. their code, apis and logic dont need a rewrite every few years. This is only commercial stuff, I don't want to sell nothing to anyone, just develop for fun and use my Freerunner as a phone without the need to wait 3 seconds to answer a call... ___ 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: [QtMoko] mediaplayer issue
On Tuesday 27 of October 2009 08:38:35 Gmail wrote: Hello, list! Nowdays I have some problems with mediaplayer on the QtMoko v14 image. I installed codecs package form the repository and set it up, but mediaplayer still cannot play mp3 files... Did you start the codecsinstaller app, hit the install mp3 codec button and restarted the phone? When I try to play ogg files - I receive a very bad performance, the music twitch every 2 seconds. Playing wav files is ok for now... It's known problem. If you need good quality playback, you can use qmplayer program. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Please wait... (WAS: [QtMoko] Calling problems)
On Tuesday 27 of October 2009 11:29:31 Atilla Filiz wrote: When I boot into QtMoko v14 without a sim card(and sometimes with a sim card) The home screen gets stuck at PIN dialog, saying Please wait... I can hold the AUX button and run applications by adding them to my favourites first, but when I try to go home, I go to the Please wait... screen. This sometimes happens on my phone too. I think it's because modem is somehow badly initialized. You can workaround it by longer POWER press and doing Restart QtExtended Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Launcher Release 0.39
On Tue, Oct 27, 2009 at 8:27 AM, c_c cchan...@yahoo.com wrote: Hi, vendion wrote: Yea the version that I have is libelementary-ver-svn-04.so.0 so I had to create the soft links to get it to work How did you get to svn-04? i've been updating regularly and I don't get any updates! Selective updating - that's a new one ;-) From what I know, the mrmoku testing images are using these libs - I haven't gotten around to using them with all the travelling I'm doing currently (hence the delays in replying too). So I really cant help you there - In fact there might be more regressions if opim has changed too. I was using the image that was posted up on the Unstable repo for this month, but I guess it was synced by mistake or taken down because it is no longer there, so I flashed the Sep 6 image and did a upgrade from that and now I am back to using svn-02. One problem that has been reported back to me, more like people complained about, is sometimes when I text someone all they get is a text with their number instead of the message that I sent them. I don't know if this is launcher or opimd doing this. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) wrote: Because Linux doesn't sucks on an 8086 ;) because Linux is well designed, is scalable, is optimized and can run even on a 8086...Desktop i think you just illustrated my point where i don't think you know what you are talking about. an intel 8086 can't run linux. a linux requires a minimum of an 386 with mmu. the 8086 was a 16bit precursor to it. Your mail client doesn't display smileys? :) :) :) :) :) Was joking just to calm souls :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
Hi everyone, great to hear many people are interested! Today I've entered openmoko on fosdem.org for a devroom and made some wikipages for it. If you're coming or want to do more (giving a talk/presentation, organizing a brainstorm session, ...), please add your name and/or idea to http://wiki.openmoko.org/wiki/Fosdem_2010 Pieter -- View this message in context: http://n2.nabble.com/FOSDEM2010-tp3895254p3900343.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: Centralization of graphical awesomeness
Carsten Haitzler (The Rasterman) ha scritto: On Tue, 27 Oct 2009 15:51:48 +0100 DJDAS dj...@djdas.net said: Christophe M wrote: Hi guys ! I don't want to feed the troll but lets compare what's comparable ... You compare Qt framebuffer with E over Xorg ... In one case you have a Xorg who is running in the other it's directly accessed ... Not true, because if Raster was right the only problem would be the Glamo chip so I would like to say why there are so many differences between Qt and E ;) i never claimed the glamo was the only problem. get your facts right. try reading first. it's a handy skill. Smiley even here ;) Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
New Release of xminimokostatus (Part of Minimoko)
i leaved just a new version of xminimokostatus. Improvements: now fully using dbus: - it doen't need external programs for getting status. - signal strenth and provider is now read from dbus-signals, no active poll == http://wiki.openmoko.org/wiki/Minimoko ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
:) :) seems there are at least three request for a Openmoko devroom!! :) Nikolaus do you agree to unify our efforts in one?, I propose use the PieterC request. mine at least I will send a a mail organizers retire mine and agregate to PieterC one. David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/10/27 PieterC freep...@gmail.com: Hi everyone, great to hear many people are interested! Today I've entered openmoko on fosdem.org for a devroom and made some wikipages for it. If you're coming or want to do more (giving a talk/presentation, organizing a brainstorm session, ...), please add your name and/or idea to http://wiki.openmoko.org/wiki/Fosdem_2010 Pieter -- View this message in context: http://n2.nabble.com/FOSDEM2010-tp3895254p3900343.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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
David, Am 27.10.2009 um 19:01 schrieb David Reyes Samblas Martinez: :) :) seems there are at least three request for a Openmoko devroom!! :) the more hunters the better the results :) Nikolaus do you agree to unify our efforts in one?, I propose use the PieterC request. mine at least I will send a a mail organizers retire mine and agregate to PieterC one. Yes, we should only have one request towards the organizers. They want to have a contact person anyway. If you will do it, I will be fine with it. Nikolaus David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/10/27 PieterC freep...@gmail.com: Hi everyone, great to hear many people are interested! Today I've entered openmoko on fosdem.org for a devroom and made some wikipages for it. If you're coming or want to do more (giving a talk/presentation, organizing a brainstorm session, ...), please add your name and/or idea to http://wiki.openmoko.org/wiki/Fosdem_2010 Pieter -- View this message in context: http://n2.nabble.com/FOSDEM2010-tp3895254p3900343.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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Mobile Office Solutions by Golden Delicious Computers GmbHCo. KG Buchenstr. 3 D-82041 Oberhaching +49-89-54290367 http://www.handheld-linux.com AG München, HRA 89571 VAT DE253626266 Komplementär: Golden Delicious Computers Verwaltungs GmbH Oberhaching, AG München, HRB 16602 Geschäftsführer: Dr. Nikolaus Schaller Digital Tools for Independent People ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness [ot]
Am Mittwoch, den 28.10.2009, 02:02 +1100 schrieb Carsten Haitzler: [...] why are you not complaining that linux sucks on an 8086 on your desktop? Because Linux doesn't sucks on an 8086 ;) because Linux is well designed, is scalable, is optimized and can run even on a 8086...Desktop i think you just illustrated my point where i don't think you know what you are talking about. an intel 8086 can't run linux. a linux requires a minimum of an 386 with mmu. the 8086 was a 16bit precursor to it. owned. scnr :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [gta02-core] FOSDEM2010
Dr. H. Nikolaus Schaller wrote: What about GTA02-core? Hmm, no plans from my side so far. I prefer to have something tangible to show when going to conferences :-) There are still a few months until FOSDEM - by when would a decision have to be made ? - Werner ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
fatfingershell V0.2
Hello people, there is a new version of fatfingershell (0.2). It is a virtual terminal for Openmoko mobile phones, with a fullscreen keyboard, and sound/screen/vibrator feedback. You can set the colors and the transparency, set new keyboard layouts (hard yet) and replace the sounds. The fullscreen keyboard aims to be complete and useful for sh/bash, vi and common console apps, like top, mocp, mplayer, mc, gnu tools, etc. Moreover it is comfortable for fat fingers. The new stuff : - better performance - scroll - vibration feedback - better sources - ipkg package Installing ffs : opkg install http://ffs.projects.openmoko.org/fatfingershell_0.2_armv4t.ipk Web page and documentation : http://ffs.projects.openmoko.org/ (check the TODO, we need useful scripts yet :-) ) Suggestions and feedback are always welcome. Enjoy, Rafa. -- Rafael Ignacio Zurita ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tue, 2009-10-27 at 20:21 +1100, Carsten Haitzler wrote: you show and immense amount of knowledge here, both of the hardware, of software and graphics in general. i'm amazed. i shall take your advice as you obviously are someone of massive experience. i see that people reporting that its faster and better on a gta01 @ 266 mhz (2/3 the cpu powerd), same screen and no glamo are obviously wrong. you indeed know much more. the smooth rendering on a 206mhz strong arm is obviously just incorrect and i'm a fool to think so. i shall be quiet and let your amazing skills make everything blindingly fast and smooth. lol... Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
On Tue, 2009-10-27 at 10:12 -0700, PieterC wrote: Hi everyone, great to hear many people are interested! Today I've entered openmoko on fosdem.org for a devroom and made some wikipages for it. If you're coming or want to do more (giving a talk/presentation, organizing a brainstorm session, ...), please add your name and/or idea to http://wiki.openmoko.org/wiki/Fosdem_2010 Pieter Are other communities that work on others FSO compliant phones welcome like: *palm pre *htc-linux ? Are people working to free phones regardless of the stack welcome? like a 100% free android on the htcdream for instance? Denis. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM2010
Sure! :) On Tue, 2009-10-27 at 14:43 -0700, GNUtoo [via Openmoko Public Mailinglists] wrote: On Tue, 2009-10-27 at 10:12 -0700, PieterC wrote: Hi everyone, great to hear many people are interested! Today I've entered openmoko on fosdem.org for a devroom and made some wikipages for it. If you're coming or want to do more (giving a talk/presentation, organizing a brainstorm session, ...), please add your name and/or idea to http://wiki.openmoko.org/wiki/Fosdem_2010 Pieter Are other communities that work on others FSO compliant phones welcome like: *palm pre *htc-linux ? Are people working to free phones regardless of the stack welcome? like a 100% free android on the htcdream for instance? Denis. ___ Openmoko community mailing list [hidden email] http://lists.openmoko.org/mailman/listinfo/community __ View message @ http://n2.nabble.com/FOSDEM2010-tp3895254p3901957.html To unsubscribe from Re: FOSDEM2010, click here. -- View this message in context: http://n2.nabble.com/FOSDEM2010-tp3895254p3902073.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: FOSDEM2010
great :) feel free to contact me at any time Pieter On Tue, 2009-10-27 at 11:02 -0700, David Samblas Martinez [via Openmoko Public Mailinglists] wrote: :) :) seems there are at least three request for a Openmoko devroom!! :) Nikolaus do you agree to unify our efforts in one?, I propose use the PieterC request. mine at least I will send a a mail organizers retire mine and agregate to PieterC one. David Reyes Samblas Martinez http://www.tuxbrain.com Open ultraportable embedded solutions Openmoko, Openpandora, Arduino Hey, watch out!!! There's a linux in your pocket!!! 2009/10/27 PieterC [hidden email]: Hi everyone, great to hear many people are interested! Today I've entered openmoko on fosdem.org for a devroom and made some wikipages for it. If you're coming or want to do more (giving a talk/presentation, organizing a brainstorm session, ...), please add your name and/or idea to http://wiki.openmoko.org/wiki/Fosdem_2010 Pieter -- View this message in context: http://n2.nabble.com/FOSDEM2010-tp3895254p3900343.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list [hidden email] http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list [hidden email] http://lists.openmoko.org/mailman/listinfo/community __ View message @ http://n2.nabble.com/FOSDEM2010-tp3895254p3900678.html To unsubscribe from Re: FOSDEM2010, click here. -- View this message in context: http://n2.nabble.com/FOSDEM2010-tp3895254p3902082.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
[QtMoko] [Debian] Which MicroSDHC card should I buy to install Debian onto?
Hello list, I have a buzz-fixed rev A6 US FreeRunner (FR). I am currently using QtMoko v11, which is installed in my FR’s onboard NAND. I need a MicroSDHC card on which to install Debian. I do not want to run out of disk space, so I probably need at least an 8 GB card. The Openmoko wiki claims “The Neo FreeRunner supports up to 16GB microSDHC cards.”. [1] Is this true? What is the fastest and highest-capacity MicroSDHC card known to fully work with Debian on the FR? I am currently using U-Boot, but can try Qi if necessary (as long as I can boot both QtMoko from the onboard NAND and Debian from the MicroSDHC card.). I live in Delta, British Columbia, Canada, so Canadian sources are preferred. Thanks, Brolin [1] http://wiki.openmoko.org/index.php?title=Supported_microSD_cardsoldid=76325 -- Sometimes I forget how to do small talk: http://xkcd.com/222/ “If you have to ask why, you’re not a member of the intended audience.” — Bob Zimbinski, http://webpages.mr.net/bobz/ttyquake/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fatfingershell V0.2
Rafael Ignacio Zurita rizur...@yahoo.com writes: Hello people, there is a new version of fatfingershell (0.2). It is a virtual terminal for Openmoko mobile phones, with a fullscreen keyboard, and sound/screen/vibrator feedback. You can set the colors and the transparency, set new keyboard layouts (hard yet) and replace the sounds. The fullscreen keyboard aims to be complete and useful for sh/bash, vi and common console apps, like top, mocp, mplayer, mc, gnu tools, etc. Moreover it is comfortable for fat fingers. Thanks for that, really usable shell. The keyboard lacks only small feature, I tried to run $ mdbus -s org.freesmartphone.otimed and made a typo, and I see right and left cursors (preferable on keys in FN mode) are a must. I can do well with C-p and C-n to browse shell history (as you hit them once or twice), but multiple C-b or C-f to move inside the line to edit it is a pain and unusable. The new stuff : - better performance - scroll - vibration feedback - better sources - ipkg package Installing ffs : opkg install http://ffs.projects.openmoko.org/fatfingershell_0.2_armv4t.ipk Web page and documentation : http://ffs.projects.openmoko.org/ (check the TODO, we need useful scripts yet :-) ) Suggestions and feedback are always welcome. Enjoy, Rafa. -- Rafael Ignacio Zurita ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness [ot]
2009/10/27 Marcel tan...@googlemail.com Am Mittwoch, den 28.10.2009, 02:02 +1100 schrieb Carsten Haitzler: [...] why are you not complaining that linux sucks on an 8086 on your desktop? Because Linux doesn't sucks on an 8086 ;) because Linux is well designed, is scalable, is optimized and can run even on a 8086...Desktop i think you just illustrated my point where i don't think you know what you are talking about. an intel 8086 can't run linux. a linux requires a minimum of an 386 with mmu. the 8086 was a 16bit precursor to it. owned. scnr :) have you googled linux 8086 ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness [ot]
On Wed, 28 Oct 2009 00:38:28 +0100 Michal Brzozowski ruso...@poczta.fm said: 2009/10/27 Marcel tan...@googlemail.com Am Mittwoch, den 28.10.2009, 02:02 +1100 schrieb Carsten Haitzler: [...] why are you not complaining that linux sucks on an 8086 on your desktop? Because Linux doesn't sucks on an 8086 ;) because Linux is well designed, is scalable, is optimized and can run even on a 8086...Desktop i think you just illustrated my point where i don't think you know what you are talking about. an intel 8086 can't run linux. a linux requires a minimum of an 386 with mmu. the 8086 was a 16bit precursor to it. owned. scnr :) have you googled linux 8086 ? with linux i'm not lumping in uclinux, elks, etc. as they do come under different names :) notice.. i included desktop... and at least i'd hope to imply that would be the desktop he speaks of... ie how great compiz is and so much better than e17. :) (just using context). -- - 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: [QtMoko] [Debian] Which MicroSDHC card should I buy to install Debian onto?
On Tuesday 27 October 2009, Brolin Empey wrote: Hello list, I have a buzz-fixed rev A6 US FreeRunner (FR). I am currently using QtMoko v11, which is installed in my FR’s onboard NAND. I need a MicroSDHC card on which to install Debian. I do not want to run out of disk space, so I probably need at least an 8 GB card. The Openmoko wiki claims “The Neo FreeRunner supports up to 16GB microSDHC cards.”. [1] Is this true? What is the fastest and highest-capacity MicroSDHC card known to fully work with Debian on the FR? I am currently using U-Boot, but can try Qi if necessary (as long as I can boot both QtMoko from the onboard NAND and Debian from the MicroSDHC card.). I live in Delta, British Columbia, Canada, so Canadian sources are preferred. The speed of the card won't matter as the Glamo interface will be the bottleneck even with Class 2 cards. The 8GB Sandisk works for me with uboot for multibooting. It looks like the Sandisk is the only 16GB card tested so far. In theory 32GB should work when they become available. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QtMoko] glamo mplayer
I want to use my FR to watch a stream from my MythTV recordings using http stream (I think it is mpeg 2) using my wireless. Is the glamo enhanced mplayer available in QtMoko/Denian ? cheers Denis ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] mediaplayer issue
On Wed, Oct 28, 2009 at 1:24 AM, Radek Polak pson...@seznam.cz wrote: It's known problem. If you need good quality playback, you can use qmplayer program. How does one play a mpeg stream uing a link from qmplayer such as http://192.168.0.105//mythweb/pl/stream/1003/1256644800 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fatfingershell V0.2
Il giorno mar, 27/10/2009 alle 16.37 -0300, Rafael Ignacio Zurita ha scritto: Hello people, there is a new version of fatfingershell (0.2). It is a virtual terminal for Openmoko mobile phones, with a fullscreen keyboard, and sound/screen/vibrator feedback. Nice work! Suggestions and feedback are always welcome. Would be possible keeping the same system but allowing an usage in 480x640 mode? Thanks... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: fatfingershell V0.2
Hi, Marco Trevisan (Treviño) wrote: Would be possible keeping the same system but allowing an usage in 480x640 mode? OT - but - what hardware are you talking about? ;-) -- View this message in context: http://n2.nabble.com/fatfingershell-V0-2-tp3901258p3903512.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
