Re: [NEW DISTRIBUTION] Announcing NEOPhysis
Aditya Gandhi ha scritto: Yes please some screenshots On Mon, Mar 8, 2010 at 12:12 PM, Risto H. Kurppa ri...@kurppa.fi mailto:ri...@kurppa.fi wrote: 34sec bootup time sound's incredible compared to all other distros, WELL DONE!! Are there any screenshots available? Thanks! r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi Hi, you can find some screenshots in the Czech original review here[1], please consider in the new image Litephone and Linphone not present (they are only in OE image) so consider only launcher, power button and dialer screens only :) Thank you, bye. [1] http://translate.google.com/translate?hl=itsl=autotl=enu=http%3A%2F%2Fwww.openmoko.cz%2Findex.php%2Fblogs%2Fread%2F20 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [NEW DISTRIBUTION] Announcing NEOPhysis
Brolin Empey wrote: djdas wrote: What's next: who knows :P we're hardly working to achieve a stable phone system, there are lots of programs in our OE buildsys but we haven't provided a package manager yet (there is a script to simply install ipk packages in /opt/bin/ipkmgr.sh) Hardly working or working hard? They have opposite meanings. I think you meant working hard because hardly working means barely working. ;) EHEH Sorry, English is not my first language, yes we are working hard :) Thank you for correcting me. Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [NEW DISTRIBUTION] Announcing NEOPhysis
Neil Jerram wrote: On 6 March 2010 22:24, djdas dj...@djdas.net wrote: As the team leader of the Neophysis Dev Team I'm proud to announce you a new distribution for our loved(?) Freerunner. Well, of course it will be great to have another choice for the FR, if it is rock-solid and supports all the important phone functions. Yes it's our first target, a fully functional phone. - the phone stack should be oFono (reliable, multi-platform, fast) Is oFono already rock-solid as regards GPRS? i.e. - doesn't drop the GPRS connection prematurely - allows simultaneous use of GPRS and phone calls - deactivates GPRS cleanly (when requested) and can reactivate it later. Honestly we didn't try GPRS functions yet, because we focused on the phone part for the Armeniacum release, although oFono team implemented the GPRS functions and the Calypso plugin already works with multiplexing, so I assume there shouldn't be many problems. Also, is oFono better than FSO as regards - never missing incoming SMS messages? - handling split (CSM) messages? Yes and yes :) never missed any SMS and long ones are automatically handled by oFono: you can send/receive a string of whatever length (don't know what is the limit but at least with a 3 SMS long string, I had no problems) without taking care of the splitting/joining. - a completely cutomized boot sequence to start in 30-50 secs maximum Nice - but more for the implication that you have carefully considered all the daemons and cut out what you don't need, than for the actual boot time (which doesn't matter much if one rarely needs to reboot). I always turn off my phone at night so for me a fast boot is mandatory ;) and yes, we removed all the unuseful stuff (at least on a device like the FR) What you can expect: well, it's in alpha stage, the only working thing is the dialer for placing and answering calls (no contact-list, just numbers :P) no SMS (we're working on them ATM), no suspend/resume, it's a simple phone :D it boots in about 40 seconds with the modem registered (NO PIN SUPPORTED ATM!!!), it works only with moko11 firmware; to shutdown, simply push the power button for 8 seconds (read-only filesystem so you can't break anything). Are the limitations because of middleware problems (i.e. oFono) or just because you haven't written the UI yet? The second one ;) we are completing the SMS handling part these days and working on the contacts handling, the rest is because we didn't integrate FSO daemons yet but will get on soon :) Last but not least thanks to anyone who will believe in our project and will want to join us in this new adventure. I will believe in it if it produces a rock-solid and full function distribution soon. Soon is a word which fights with time and resources, we are doing our best and we are full of ideas but work on it on our spare time so please be patient :) and please let me be a bit ironic: in three years we didn't get a rock-solid full function distro yet, in 6 months you can almost phone ;) For me, it raises the question of why people feel that they need to start off their own thing, instead of contributing to an existing project. I think one justification for this is if the new project really produces a result quickly that is clearly better than the existing projects. If that doesn't happen, I'm afraid I don't see the point; the end result is only that we have N+1 not-quite-good-enough distributions, instead of N. looking at distrowatch.org it seems many people think differently :) joking apart... we started because we thought something faster and reliable than the current distros (almost for the phone part) could be possible by rethinking from scratch every single component of the system...future will say if we were right 6 months ago ;) FWIW, the same question obviously applies to oFono too (vs FSO). I read some of the IRC logs about that, and the oFono guys only seemed to have one technical reason for starting their own thing - because they thought the FSO D-Bus API was too complex and exposed too much unnecessary detail to applications/users. I think so and I agree with oFono guys. Furthermore oFono doesn't want to substitute or concur with FSO, it's just a phone middleware, while FSO is aimed at the whole system so I don't think we can compare them. Which on the one hand is not persuasive - because I'm sure it would have been possible for them to add their proposed simpler API to FSO, in parallel with the existing API - and on the other hand is a concern - because it makes me wonder if an oFono-based distribution would be able to support applications like Cellhunter? I think FSO is a great idea but I think a middleware should be optimized (read as: wrote in C and easy to handle). We will use FSO for the parts which do not need realtime handling and this is why, for the phone part, we choose
Re: [NEW DISTRIBUTION] Announcing NEOPhysis
Ed Kapitein wrote: Hi Djdas, Thanks for the new FR software. I did try it just yet and ran into some problems. Where am i supposed to put the software? SD card? Nand? doesn;t matter? I put it on the Nand and flashed the kernel to Nand as well, but it doesn't boot at all. I'm sorry to not explain the installation but simply forgot :) The file is the tar.gz archive of the root fie system, you can untar it on a SD partition to install and: 1) using u-boot copy the kernel in /boot/uImage-GTA02.bin in a vfat partition 2) using Qi select the SD card partition to boot Please see docs for the details especially for Qi as I don't use it and don't know how to configure it, sorry. If you want to install in your NAND you should boot another distro on SD, mount your NAND partition (mount -t jffs2 /dev/mtdblk6 /mnt/point) and then untar the file on the partition; kernel could be flashed as always. Jffs image will be provided soon but until then we will provide only tar.gz archives, sorry. Having a choice is a good thing and if this will be just a phone it is good enough for me. Having a functionally phone is our key target ;) I have always felt that 56 layers of abstraction before talking to the hardware is a mixed blessing. If you want to support different hardware i think it is a must, but if you want to make bleeding edge software just for the FR it is an overkill. Just my 2 cents. I definitely agree, we have only a layer (written in pure C++) which abstracts FSO and oFono APIs to achieve multi middleware (and so multiplatform) support without the needs of rewriting the applications APIs Kind regards, Ed Best regards, Dario. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [NEW DISTRIBUTION] Announcing NEOPhysis
Timo Juhani Lindfors wrote: djdas dj...@djdas.net writes: Honestly we didn't try GPRS functions yet, because we focused on the phone part for the Armeniacum release, although oFono team implemented the GPRS functions and the Calypso plugin already works with multiplexing, so I assume there shouldn't be many problems. Nothing on calypso is without its problems. I know :) but oFono guys are very kind and supported us very well on December so I assume they will if we will ask them on GPRS issues. I want to be honest and clear on this point: GPRS will be considered after the basic functionalities of the phone will be complete and stable so please don't count on it soon :) Bye :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[NEW DISTRIBUTION] Announcing NEOPhysis
Dear Community, yes, you discovered us :D As the team leader of the Neophysis Dev Team I'm proud to announce you a new distribution for our loved(?) Freerunner. We started working on it on last September, with the support of the Italian Telefoninux.org community, and after 6 months (thursday was our half-birthday :P) we want to share the effort of the 6 core members of the team with you. What is Neophysis? It's a sort of Linux from scratch for the Freerunner (although it could potentially run on any embedded system which runs a bit of daemons and has libraries as per the following notes), we re-thought the concept of “distro” aiming at boot speed and phone stability. To achieve these purposes we started with 3 key points: - the phone stack should be oFono (reliable, multi-platform, fast) - a completely cutomized boot sequence to start in 30-50 secs maximum - a fast and light windowmanager The first point was the easiest thanks to the oFono team support which in just 3 months from its born (June 2009) was able to run on the Calypso modem and, on December, helped us in solving an issue; the second point was solved thanks to the experience of our system engineers which customized the entire boot process and achieved a 12 second boot (from kernel loaded white flash until the X server starting without any window) on our first test release; third point is currently in hard development: our developers started taking a very simple WM (Echinus) and adapted it inside a first monolithic release of the desktop environment called NDE. NDE is Qt-based and ATM is a single daemon which consists of the parts you read in the great review done by the Czech community (thank you very much guys! :) ) I don't want to bore you with many details, the only thing I'd like to say is that the rootfs image showed in the review is only an OE build used for developing, where you'll find additional package previews that we are going to support in future. You can download the real image (first alpha version code name: Armeniacum) at this link: http://neophysis.sourceforge.net/images/armeniacum-nde_20100306.tgz you can find the kernel inside the /boot dir (the one named _old is a monolithic kernel which seems to work well) What you can expect: well, it's in alpha stage, the only working thing is the dialer for placing and answering calls (no contact-list, just numbers :P) no SMS (we're working on them ATM), no suspend/resume, it's a simple phone :D it boots in about 40 seconds with the modem registered (NO PIN SUPPORTED ATM!!!), it works only with moko11 firmware; to shutdown, simply push the power button for 8 seconds (read-only filesystem so you can't break anything). What's next: who knows :P we're hardly working to achieve a stable phone system, there are lots of programs in our OE buildsys but we haven't provided a package manager yet (there is a script to simply install ipk packages in /opt/bin/ipkmgr.sh) What we need: Testers, testers, testers and developers :D we have lots of ideas and very little time; source code of our libraries and daemons is not yet open to anonymous readers but only to active developers (C/C++ and Qt for the GUI, ATM) Well, this is all for now, just a BIG BIG THANK YOU to my team (in alphabetical order): - Arus (GUI, Development) - Djdas (me :) Development, System Engineering) - LeOS (System Engineering) - Monto (Development) - Nicola.mfb (GUI, Development, Brainfuc*ing :D) - Nippi (Kernel building, Development) Thank you very much to the Telefoninux Italian community for the ideas, support, testing, critics and joking. Last but not least thanks to anyone who will believe in our project and will want to join us in this new adventure. Bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness [ot]
Carsten Haitzler (The Rasterman) wrote: 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). Please don't lock on my comparing E vs. Compiz, it was just an example to show how things could be done in different manner, the same as you don't consider uclinux as linux... I didn't say Compiz is better than E per se, I just said on *my* desktop systems E never run as smooth as you claim (and show on your videos) BUT Compiz do. Given that I don't use compiz because simply I don't need fancy windows to browse the web, developing apps and see movies ;) ___ 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: 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. No and...NO I said I read too much bull**it regarding the approach used when users complains about graphic speed. I didn't say you are a liar or incompetent just your system is not the one, there are many different choices so if another system is faster than yours MAYBE there should be a reason and obviously it's not only Glamo issue. You said E does many more calculations than Qt not me so I simply pointed this doesn't mean me (as a user) MUST accept perfect-fancy-heavy background calculations at the cost of speed and responsiveness. And for this I pointed (yes I was rude but 2 years of the same shut-up you bought a looser device so don't complain messages altered my patience ;) ) that your approach of porting a desktop system to an embedded one it's not as easy as ./configure make make install cross compiling.and for this I talked as a bit competent in embedded devices (not on graphics) development. As a GUI designer and technician you should very well know users perceive responsiveness and usability not background calculation so *seeing from the end user point of view* I can tell Qt is way far faster than E (even if it does less things...) if you have something concrete to offer rather than being rude, insulting and simply rubbishing things you know little about, then contribute. I will ;) please give me and my staff a couple of months... 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. Several months ago I saw a rootfs image you provided as a proof-of-concept of you new gadgets (clock, buttons) and keyboard (IIRC) why simply you didn't ever provide a rootfs with a 240x320 configured screen to show the 4x speed enhancement? I am sure people trying the smoothness and responsiveness of Illume at 240x320 would never complain of a lower resolution! Furthermore I don't understand why a lower resolution (and in this I agree with you people are strange ;) ) would become in an unusable device while the iPhone at the same resolution is the best usable device ;) ... 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. Why don't you? You are the only one (and I sincerely believe this) who can know how to optimize things, why don't you show users what they can do instead of telling it's limited, stop? 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 start on it. so don't get me started in how wrong you are there. e runs on beagleboards (omap3 - 600mhz) just fine. this is roughly an equivalent machine to the netbook (give or take). I'll send you my desktop PC :P it is all factual and based on imperative results and engineering work. not being an it manager and being rude. you have implicitly called me a liar and have also implicitly claimed i know not of what i speak. No, please read my previous posts, I claimed your approach to end users complaints is of closure. Sorry if you interpreted this as a personal offense. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Xavier Cremaschi wrote: DJDAS a écrit : ri...@happyleptic.org wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) and be reactive to user finger pressures. If E, because of an ambitious design, is unable to perform this on the freerunner, then it's simply not a good fit. You can say that the hardware does not fit E or that E does not fit the hardware, the fact is we have much more free software to run on the freerunner that free hardware to run E. Finally! This was my point of view nothing else! :) Thank you for explaining in a simple manner :) Bye But E *is able to perform this*, in a better way than the other solutions. You seem to think E is an ambitious/too complicated/too slow piece of software. You are obviously wrong here. E is an optimized piece of software, probably the best one when you have hard constraints (like on mobile devices). Use a theme with -- as you wrote -- some simple widgets and you will see that E is the fastest one. And stop comparing E in SHR/Om2009 (complicated multi layer theme for a not so good look) with QtMoko (simple theme for a good look), because being 2x faster when you display 3x simpler widgets is not significant. Xavier :) Sorry but which part of from the user's point of view doing complicated calculations that result in a slower display is useless is not clear? I don't care E optimizations and beautiful algorithms if I simply CANNOT USE THEM or use them at the price of speediness and smoothness, they're simply useless! You can't tell me you've written the best software in the world if I can't use it or I have to limit it to the worst software, it's a loosing approach, you dropped your energy in something useless. This is what I claim Raster is wrong, nothing more (maybe using rude words ok, but this is the point). He says if you run on a limited hardware my software, to obtain the SAME results of Qt you cannot use my calculations and optimizations so what? This is equals to say you cannot use my software not my software is well written, do you agree with this? Bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Xavier Cremaschi wrote: No. From the user point of view, a recipe : - take SHR or Om2009 - put a simple theme instead of the default one - notice it's very fast Where is the part with the user who cannot use this or that ? That as Raster correctly said, default is something that should do everything as-best-as-possible, and default in all E distros is a pain-in-the-a** This is a distro maintainer issue ok but remember I'm talking from the user's point of view and from this point of view it's a matter of E not distro maintainer configuration (given both distros suffer the same problem). And until some months ago there wasn't a simple theme for Illume (and please don't tell me creating Illume's themes is as easy as Qt or GTK...) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Cedric BAIL wrote: Man, what didn't you understand in: YOU SHOULD WRITE A THEME THAT DON'T USE THAT MUCH FANCY STUFF ? ? The EFL are fast and optimised, but you should adapt the theme to what you ask. So write a theme that look like QtMoko and I bet you will have at least the same speed (My personal guess is that it will be faster, but I don't have time to do that). I don't have time too!!! I don't want to write a theme that REMOVES ALL THE FUNCY STUFF! I'd like (did I ever say that?) AS AN END USER to have something by default that demonstrates its capabilities. And at the moment it simply doesn't! As of you are beeing rude, you are not even reading what people are telling you. Stop yelling and start some real work. You already know what should be done to improve the situation. You will find edje doc here: http://docs.enlightenment.org/auto/edje/edcref.html . Now start your home work. Yes I'm rude because my approach is to solve the problems not shutting up people saying you have a shi++y hardware so don't complain and this alters my patience. If you are happy to be fooled after believing in this fantastic project, spending money, spending a lot of time you are welcome, I don't and I'll look for everything doable to make this device (and if ever will be another one in the future) better. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Cedric BAIL wrote: So either you have something like QtMoko without fancy stuff, and it will be faster, or you have some fancy effect, but slower fps. That's it. You can cry, you can yell, it will not be possible to do something more than that. Yes, it is frustrating, but the world is like that, you need to compromise. That's exactly what I said in my previous post it's not me that is saying E is the best piece of software, all the others are sh*t and I'm not crying, I worked to optimize my personal distribution based on an old FDOM and it's quite responsive and daily since september 2008, I try always to optimize things and some time share my knowledge with other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Did you see any other posts from me crying my FR is slow and unstable and unresponsive and shi**y and so on? No! I simply wrote yesterday because I saw since last year only messages like you have a bad hardware so what you want? and I don't think it's a good promotion to achieve new customers or developers to the community...so if you tell me that this is the approach I take it on account and will do my work for myself not trying to share my knowledge with a community which rounds only around Raster and SHR like Gods I want to be proactive not simple yell, but I see only people who say Raster is right not trying to study or thinking in a different way... Can you point me at someone who is different from this approach? Choice has been make that people prefer fancy stuff over speed, and you are one of them apparently, Maybe you missed my previous posts, I said exactly the opposite: I don't NEED nor want fancy stuff at the price of speed this is why I don't consider E *FOR ME* a good piece of softwarebecause I prefer to have something responsive and written to be to, especially if its aimed at an embedded device with low capabilities (in general but especially the FR). You don't want to solve the problem. You want the world to be like you dream it. I want a world in which a community shares its thoughts and discovers, not a community which depends on 3-4 people who say I'm right you're wrong, stop! and think them as God in EarthPassiveness is bad, EVER! But this hardware has limitation that you should take into account, if you don't, you will wast your energy and the energy of others for nothing. And yes, it costs to accept that the hardware we have is not as powerfull as we would like it to be. And yes, it costs to accept compromise. Welcome to the real world. I perfectly know this and if you read carefully my previous posts you see exactly what you're writing So now, I ask you, what do you propose ? At least raster give you a few possibility. I'm not a graphic expert, I'm trying to test some stuffs and looking for alternatives, when I'll reach a milestone if you'll be interested I'll share my thoughts... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Davide Scaini wrote: DJDAS i share some thoughts with you ideed... but: this is a community, why don't you share your work? Simply because ATM our work (it's not ONLY mine but we are a team of about 10 people) it's not more than a simple prototype, we are hardly working but obviously in our spare time so we prefer to achieve almost an alpha stage before sharing our ideas ;) they're too much a WIP... Sincerely, I'm interested in what works as an end user and as you already said. I'm not involved in this competition, and i just want to get out the most from this discussion to have a working brick. So please don't misunderstand me. (I'll try lowres tweaks asap, my fr is getting buzzfixed now) I'm too interested in what works but more in what we can do to let it work better, it's not a competition, it's a matter of research, sharing ideas and propose, not stopping at what we have here, whining and nothing more (otherwise I would by an HTC with Android if I only wanted a Linux-phone) So why don't we talk about future? What are we going to do with our brick? I think we could do very beautiful things, we need only a couple of months, as I said previously, and then we could speak about how push forward our work :) ps: I think that SHR is what now is working out of the box, is moving fast and imho is the best distro i tried (qtopia, debian, shr, om, hackable - i tried all of them); i hope that with this: http://blog.shr-project.org/2009/10/shr-theme-contest.html they'll find some fast and working theme. Personally I don't, but world is beautiful because it's various :P ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Sebastian Krzyszkowiak wrote: But I will. Creating Illume themes and even redesigning it completely is easier than for Qt or GTK+. I tried it (i'm author of Niebiee theme), so I know :P Really, you're annoying. Sorry other people, I don't agree with Raster and SHR maintainers simply because they don't care users but think about themselves and this is why I never installed SHR and won't never write a program using EFL. Now you showed that you shouldn't write anything in this topic. Sorry How the hell you can say SHR developers don't care about users, when you never used it? And without basic knowledge about what's going? (to explain: for some time there is launched contest for light, fast and good looking Illume and elementary theme in SHR, which will became default, as we wanted to change default theme for really long time. Maybe a contest asking if users wanted to launch opkg upgrade without messing their system at random one day yes and the following no? Maybe asking if the unstable or stable o testing branches could be useful for ALL instead of deciding to break things without any advice? I think community driven means we want to decide one thing do you agree with us or suggest something better? not we decide to do something and you are only passive testers simply because even the Freerunner is a high end user device, not every high end user is a Linux system expert or able to fix something...But maybe I'm wrong so sorry again... Really, calm down. You're using strange arguments, which don't cover reality at all. And it's really near to trolling (if it isn't already). It's not trolling, I never trolled or wanted to, but asked questions and told my opinion (I was rude in my first post but I explained why), if this is not acceptable only because I don't fully agree with Raster or SHR devs it's not my problem and I'll continue to work by myself and (if possible) share my results with anyone interested in, otherwise it's really not a problem and my life will go on as ever :) my way of thinking the Freerunner is written in the little green card I found in its box... So sorry again and good bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Bernd Prünster ha scritto: DJDAS wrote: FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... Yes I know, thank you :) but since then I noticed new versions were slower than the one I have, so maybe FDOM guys or that libraries version was more performant, I really don't know honestly... ___ 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
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: 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
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
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: 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
Re: Nokia N900
Rui Miguel Silva Seabra ha scritto: I don't care if that code breaks the GPL or not, what I care is that is 2% too much proprietary software because it's 2% VERY IMPORTANT software. Even 2% of Freerunner code is proprietary (Calypso and Wifi and it's VERY IMPORTANT too) why do we have to care if Nokia uses proprietary drivers on the N900? ;) Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Putting the *S*table back in *S*HR!
Warren Baird ha scritto: hey all, As I (and others) mentioned in the recent OM2009 thread - One of the great advantages of SHR is that it is being developed so quickly. However, I'd also say that one of the great *DIS*advantages of SHR is that it's being developed so quickly that it's often not very stable, and the 'testing' build is woefully out of date. This is why I never used SHR (and I won't for many time to come, I think) I don't have very much spare time in my life right now, so I unfortunately can't take it on myself, but I think it'd be very beneficial if someone was willing to step up and take charge of getting shr-testing updated periodically, and maybe even releasing an shr-stable that has at least some of the snazzy stuff from shr-u in it. Or rename it UHR (Unstable Hybrid Release) :P Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Spam in projects.openmoko mailinglist
arne anka ha scritto: Additionally I get Mails from that list with subject: � VIAGRA � Official Site openmokoder-commits-ow...@projects.openmoko.org to what address do you get that spam? faking the from-header is widely used -- i get a lot of spam sent allegedly from my address. simply ignore it. I received spam even from my project page (BlueMoko) same as Michael: The bluemoko-comm...@projects.openmoko.org mailing list has 1 request(s) waiting for your consideration at: http://lists.projects.openmoko.org/mailman/admindb/bluemoko-commits Please attend to this at your earliest convenience. This notice of pending requests, if any, will be sent out daily. Pending posts: From: bluemoko-comm...@projects.openmoko.org on Wed Jul 29 17:47:15 2009 Subject: Dear bluemoko-comm...@projects.openmoko.org 76% 0FF on Pfizer ! Cause: Post by non-member to a members-only list Bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Spam in projects.openmoko mailinglist
arne anka ha scritto: Pending posts: From: bluemoko-comm...@projects.openmoko.org on Wed Jul 29 17:47:15 2009 Subject: Dear bluemoko-comm...@projects.openmoko.org 76% 0FF on Pfizer ! Cause: Post by non-member to a members-only list so? what part don't you understand? the usual kind of spamming -- send to each and every address ever encountered you spam and hope for the best. it's an issue for years now, did you honestly never encounter that kind of spam? No, this seems a mail generated from the versioning system who alerts me of a pending commit request not a common spamming message. Furthermore my email address is not mentioned inside the message as the usual spam. It smells of security issue on the projects.openmoko site... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Spam in projects.openmoko mailinglist
arne anka ha scritto: No, this seems a mail generated from the versioning system who alerts me of a pending commit request not a common spamming message. ??? nothing's easier than spoofing the sent-from. just because it says it is sent from something-commits does in no way mean, it really is. Sorry but which part of the mail was sent from the versioning system you didn't understand? :) This is NOT spoofed but was sent form the projects server, please look at the headers: -- Return-Path: mailman-boun...@projects.openmoko.org X-Spam-Checker-Version: SpamAssassin 3.1.5 (2006-08-29) on djdas.djdas.net X-Spam-Level: X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_50,NO_REAL_NAME autolearn=no version=3.1.5 Received: from projects.openmoko.org (projects.openmoko.org [88.198.93.218]) by djdas.djdas.net (8.13.7/8.13.4) with ESMTP id n6Q9RPQ1012478 for dj...@djdas.net; Sun, 26 Jul 2009 11:27:25 +0200 Received: from localhost ([127.0.0.1] helo=projects.openmoko.org) by projects.openmoko.org with esmtp (Exim 4.63) (envelope-from mailman-boun...@projects.openmoko.org) id 1MWOjP-0005b0-KI for dj...@users.projects.openmoko.org; Thu, 30 Jul 2009 08:03:11 +0200 Received: from localhost ([127.0.0.1] helo=projects.openmoko.org) by projects.openmoko.org with esmtp (Exim 4.63) (envelope-from bluemoko-commits-boun...@projects.openmoko.org) id 1MWOjK-0005IK-SA for bluemoko-commits-ow...@projects.openmoko.org; Thu, 30 Jul 2009 08:03:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: 1 Bluemoko-commits moderator request(s) waiting From: bluemoko-commits-boun...@projects.openmoko.org To: bluemoko-commits-ow...@projects.openmoko.org Message-ID: mailman.241.1248933784.3962.bluemoko-comm...@projects.openmoko.org Date: Thu, 30 Jul 2009 08:03:04 +0200 Precedence: bulk X-BeenThere: bluemoko-comm...@projects.openmoko.org X-Mailman-Version: 2.1.9 List-Id: cvs commits bluemoko-commits.projects.openmoko.org X-List-Administrivia: yes Sender: mailman-boun...@projects.openmoko.org Errors-To: mailman-boun...@projects.openmoko.org X-Virus-Scanned: ClamAV 0.88.4/9634/Thu Jul 30 05:03:31 2009 on djdas.djdas.net X-Virus-Status: Clean -- It smells of security issue on the projects.openmoko site... still possible, if one take sthe password issue in account. but not from the quotes of spam. Maybe they were able to automatize the commit requests for all (o part of) the projects hosted in the site registering an account (or using an anonymous one if possible) that asks for commits and using the subject/notes field to add spamming messages... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: why openmoko is so slow? Is it a joke?
Joerg Lippmann ha scritto: When will that be? When the device is completely obsolete? Please see below... Sorry, but after a year of waiting I still have an expensive brick that I can neither use as a proper phone (speaker still WAY to low, too unstable, too slow, too battery-hungry) nor as a PDA (no usable software available). Which distribution did you try? Have you tried looking at the archives, wikis and suggestions to optimize phone stability? I use it as my daily phone since September 2008 and missed about 10 calls and a couple of messages since then (I think 10 months is quite a good statistics), no problems with speakers, NEVER, I just tuned my alsastates 2 times (one before the buzzing fix and one after) with my brother on the other side of a call and everything worked well, battery longs about 2 days which is quite good for a mini-pc capable of doing almost everything (obviously you have to turn off unused antennas and lower the display backlight, I use the mid setup). What do you mean with no usable software available? I use TangoGPS, and Navit for mapping and navigating, qtopia stack for phone, Minimo as web browser, Neon as picture viewer, ShortOM for system script launching, Mokoko as media player, Leafpad as text editor and a bunch of other apps which work very well. So I really regret my decision to buy it. But then again, it was touted as a real phone for end-users back then and being a happy Linux-User for 14 years, I thought that I could live with some minor flaws... Are you able to point me a link where the Freerunner was claimed as end-user phone? I follow the project since Neo1973 presentation and I never saw any message/announcement where the Freerunner was pointed as end-user device I'm really for the idea of freeing the phone (thats why I bought one), free hardware and the community. And I really loved to see this effort to succeed. But I came to realize that I start to hate this sluggish, instable device without good software. Well dirt your hands and write some software, don't wait someone does it for you complaining and whining it's too late and the device is becoming obsolete (consider some distros are still supporting the Neo1973 so the Freerunner will be supported for many years to come, I think). It's easy to complain, more difficult participate and become part of a dream and a way of think and live. Whining is useless, coding pushes things forward ;) I cannot help it. I haven't found a single distro that works well out of the box. The best ones so far were QTopia/QTe and Android. And neither are really community efforts. If you want to try a distro (it's not so updated but it works out of the box) contact me be email and I'll send you informations to download a rootfs So I consider my personal experiment (buying a community-driven phone for 300 EUR) as failed. Sorry. Well, the only thing I can complain is hardware bugs because not so many people are good with soldering and fix, but after the buzzing fix I can definitely say my Freerunner is a great device (calling a phone is reductive). I will for sure be a buyer (if possible) of the next generation device when the Glamo will be trashcanned because I think this is the only real bad stuff that limits usability but with a little workarounds and theming even this is a minor problem for me. And more important I believe in this dream and will never stop thanking Sean, Steve and the others for making it possible. Bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] Bluetooth and GSM... Again.
Paul Fertser ha scritto: The Digital Pioneer digitalpion...@gmail.com writes: Paul said that the connection for bluetooth runs straight from one chip to the other, without really involving ALSA at all. Is there a way we can make it involve ALSA, since bluetooth works perfectly through ALSA? Bluetooth for you works perfectly only one way most probably (A2DP). If you want to try to use SCO over HCI (bt usb interface) you'll face the same issue with everything works but no sound for unknown reason and even bluez devs say everything is ok judging by your hci dumps. :( Also it requires modifications to BT chip EEPROM. I did that myself and i had sound with working headset and had no sound with non-working (exactly the same software configuration worked with it just fine on my laptop where other brand of bt chip is used). And don't forget, A2DP - unidirectional audio, for conversations you need SCO. BTW, have you tried disabling esco or not? Well, this is partially true (even if I can't provide a solution, yet). During my researches before creating BlueMoko (I think I'll put my hands on it to port to bluez4 and new kernels starting from August), I did different tests with my 2 headsets, one (Nokia) which is only a simple headset, and the second (Calypso) is an AD2P+Headset type. The A2DP one works flawlessly with the A2DP profile and I use it for media playing, while the headset profiles (for both of them) worked some time and others no. Consider I didn't change anything in my distro (kernel, packages, libs, etc) but there were cases of both working (to be honest the Nokia one worked only two times and it isn't broken as I use it with my Nokia cell phone in some cases) and the audio is correctly routed (I tested by recording a call with another phone, so I'm sure they work). Even looking at the logs I wasn't able anymore to understand why this behavior but I had no time since then to do some checks, I suspect suspending the phone creates some strange things on the bluetooth stack but (again) A2DP is not affected and always works. If you want to contribute to BlueMoko by testing the headset functions, you can find the sources on the projects.openmoko site and I can provide even the distro which I use for my tests (my daily distro), I know it's a bit outdated but it works ;) P.S. I would like to be a Tom but I cannot guarantee so much time to develop due to my work, so please be patient :) Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] Bluetooth and GSM... Again.
Paul Fertser ha scritto: DJDAS dj...@djdas.net writes: Consider I didn't change anything in my distro (kernel, packages, libs, etc) but there were cases of both working (to be honest the Nokia one worked only two times and it isn't broken as I use it with my Nokia cell phone in some cases) and the audio is correctly routed (I tested by recording a call with another phone, so I'm sure they work). There's a kernel bug that makes loading gsmbluetooth state file not enough to actually work. One has to do amixer sset Capture Left Mixer Analogue Mix Right amixer sset Capture Left Mixer Analogue Mix Left after loading the state to workaround the bug. Thanks, I'll try :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: posting style preferences was Re: Why one cannot recommend the freerunner as a daily phone (was Re: Is a FreeRunner sufficient for me?)
FINALLY :) Thumbs up! arne anka ha scritto: any chance you fight that out somewhere else? the discussions about the prefered posting style (and no, there's no rule!) is as old as the internet -- and both positions still live and kick. that can only mean one thing: for both prefs good reasons exist and no party could ever convince the other one. if you, please, would stop to argue on that mostly religuous level and look to what you (hopefully) want to achieve? do not top post! is as stupid as do not bottom post!, and assumptions what users do, are always subjective -- if i receive a mail with bottom posting, i don not read the entire mail, but scroll to the part not cited (usually marked by different color or missing symbol at line position 0). simply always cut down the mail to tzhe neccissities, do not stupidly type either bottom or top. the realy annoyance is not top or bottom posting, the real annoyance are those stupid mails where simply everything everybody once saidf is included -- and even those fighting for nettiquette do that very often! a good rule _would_ be to imagine, that recipients _are_ reading the mails on their fr -- it easily reminds you to not live for dogms but for common sense. btw: those lengthy mails are annoying not only on the fr but even on my netbook with about 600px screen height! and that is use rather often to check mails. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community FINALLY :) Thumbs up! (To not hurt anyone :P ) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: new qwerty keyboard, Literki
Al Johnson ha scritto: On Tuesday 16 June 2009, Risto H. Kurppa wrote: True.. new ideas needed.. Block icon in one colour with a thin border in another colour. Capturing background color and filling the button with the inverse one? Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery ID chip - help needed
Laszlo KREKACS ha scritto: So inserting a nokia BL-5C battery is not complete solution. (because it lacks the coulomb counter), and freerunner cant charge it (currently) Not true, I asked my colleague to recharge my BL-5C battery with his FR while using my old Nokia some days ago and it completely charged. and cant display the remaining capacity. This is true :) Bye :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: intone a2dp (bluetooth) support
c_c ha scritto: Hi, The Digital Pioneer wrote: AFAIK, the only way to do it is to run mplayer with -ao alsa:device=bluetooth Ok. But what would be the best of doing so from intone :- 1. I stop the current process from Intone 2. Start new process with the -ao flag Or I can have 2 configurations in a file (normal / bluetooth) - I think .asoundrc and change output from intone somehow using that. I'm not all that clued up on alsa - so can someone with more knowledge than I throw some light? It's very simple: you have to pair to the device and create a .asoundrc file in $HOME. You can see a sample of it in the bluethooth.py module of BlueMoko[1] (look at the function connect_A2DP() ) After this the bluetooth headset will become the default alsa device so you won't need to change any configuration in mplayer but just start a new mplayer process which will play through the headset. To reset the alsa output simply remove the .asoundrc and disconnect from the headset. Bye! [1] http://bluemoko.projects.openmoko.org/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: intone a2dp (bluetooth) support
OpenMitko ha scritto: Hi to all, Sorry if this is out of topic. I want to ask those of you who already use a2dp, how is the sound quality? I tried to use my Neo as media player wit wired headsets, but it was almost a disaster, intone is great but the sound quality is bad. Not only the lack of bass … I was looking for solution but still can’t find something suitable. I was wondering if Bluetooth headsets offer better quality. Regards, Mitko Hi, to me it's very good, I use a Calypso headset and sound quality is great, I definitely recommend using a BT headset with A2DP for media playing. Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: intone a2dp (bluetooth) support
Michael Sheldon ha scritto: DJDAS wrote: It's very simple: you have to pair to the device and create a .asoundrc file in $HOME. Personally I don't think this should be implemented in intone, this sort of system-wide activity should be handled by FSO (and I believe there is work on-going towards this) and intone should just offer the option to make use of an already configured bluetooth device if it exists. I agree but as I hadn't the time to update BlueMoko to bluez4 and FSO, that was a suggestion to achieve A2DP output after pairing with other means (if FSO does the pairing with headset profiles you should have only to create the .asoundrc file waiting for a GUI ;) ) Also, IIRC, BlueMoko still uses bluez 3.3, while most images now use bluez 4 by default. So if you went down that path you'd probably end up having to support two different methods of pairing. A2DP is easier to use (didn't see bluez4 yet) than headset, because you just need to pair and configure the default main alsa device as the headset, while headset profiles need routing and configuring the secondary alsa device and I didn't find yet a clean way to do this, but as I mentioned I hadn't the time to look at bluez4 and newer kernels so maybe the situation became better in the meantime (I hope :P ) Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: LinuxTag 24-27 June Berlin
Giovanni ha scritto: You forgot Slackware, with ArmedSlack: http://www.armedslack.org/ :) Sorry for my ignorancebut either in the wiki or ML I read about this distro and subscribed to the armedslack ML but there is no place where Freerunner is considered to run it, can someone point me for an installer/howto? Thank you in advance ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: (Neovento) gprs ui bug
Sean holmes ha scritto: neovento 5 has the same bug as last time. The gprs ui has to few spaces to enter you APN sever name. keep up the good work. Could you please use a larger font as yours is unreadable? Thank you :D Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debuzzing
Marco Trevisan (Treviño) ha scritto: Dr. H. Nikolaus Schaller wrote: 2) Therefore we plan to offer this service to all Openmoko owners within the EU harmonized market / tax union (to avoid re-import/export hassle). Please note that there will be a rework fee. The final price is not yet clear (expected to be less than 30 EUR incl. shipment) because we are in intensive discussions with Openmoko how they can help to reduce this fee for you. Is this rework fee valid also for your customers? Don't you offer a kind of warranty? The same for me, I'm your customer too. Thank you in advance for your answer. Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets in FSO
Paul Fertser ha scritto: DJDAS dj...@djdas.net writes: Franky Van Liedekerke ha scritto: Framework already supports BT headsets. The fact GUI is missing shows the lack of interest from end-users, well, i think it'll change soon. hmm ... I thought end-users were people actually using the phone, not unix-hackers ... That's why I wrote it ;) It's very nice you work on it. Too bad you use a dead-born deprecated distro ;) Well, to be honest I'm a maintainer of a distro called FDTF based on Om2008.9+FDOM(September version) I customized for the Italian community at http://forum.telefoninux.org. I still use it because it's quite stable, telephony works (little qtopia bugs but it's daily usable) and with the community suggestions I added various customizations in the startup scripts, keyboards, themes and so on. I'm stuck with it because I have no much time to re-test everything in FSO-based distros and I don't like their telephony-PIM (qtopia IMHO still rocks hard). So this is my development environment with pros cons obviously, but I think it's better to have a daily quite stable phone rather than something updated but quite unusable, I'll wait for real stable releases with no one who wants to recreate the wheel from scratch after something goes wrong at the end of the job ;) As Franky already mentioned, bluez3 and bluez4 interfaces are completely different, so porting won't be that easy :-/ No probs ;) It's just a matter of code One of the reasons FSO integrates functionality of powering and resetting devices is exactly that. Higher level app devs shouldn't be bothered with kernel changes, FSO quickly adopts to it and you receive all updates free. In fact, you might like the idea of FSO, take a look at specs ;) Oh, I know and appreciate FSO way but I need something really stable and working, not something randomly working after an update :P Seriously: as I said above I'll make BlueMoko compatible with FSO but for my daily use I'll stick with my FDTF until a real stable working out-of-the-box distro will be released ;) Thanks you, bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[Om2008.x] Announcing BlueMoko 1.0b1
Dear list, this is for announcing the first beta release of BlueMoko, a PyGTK GUI handler for the bluetooth stack. ATM the program handles powering on/off, mode setting (visible, invisible, connectable), scanning for devices and pairing (with PIN too) but only with headset devices (pc, smartphone and others are planned in future versions). What works: A2DP support, connects with headset (tried with a Calypso) and routes default PCM audio to it so players can output directly without any modifications Partially working: headset profile, I have still some issues (I think depending on ALSA configuration but can't find an always reproducible way to handle it) so sometimes it works other time not...plus, after pairing with the headset you have to manually (ATM) handle the alsa state loading during the call (using the alsa state provided by Angus in the Wiki) Not working: connecting with other BT devices but audio. I still don't support FSO based distributions as I have no time to install them but some friends will help me (or anyone who want to participate is welcome ;) ) and there is no opk package yet (hope during next weekend after some code fixing). You can grab the sources at the project CVS here[1]: you only need these 3 files: bluemoko-bin, bluemoko.py and bluetooth.py, simpyl copy in a folder and launch the bin. The sources are based upon the older scripts provided by Angus several months ago (thank you very much for the starting point) and I learned to program python since January so don't expect good code ;) by reading the ShortOM source code (useful for training with PyGTK too, thanks to Luca :) ) Dependencies: PyGTK, Bluez-3.33 Final note: if the program complains about not running on a Neo, probably your /sys files to access powering and resetting bluetooth are different from mine, so you can modify their path on rows 29 and 30 of the bluetooth.py source. Thank you in advance, bye! [1] http://projects.openmoko.org/projects/bluemoko/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets in FSO
Paul Fertser ha scritto: Franky Van Liedekerke liede...@telenet.be writes: And BTW, FSO-based distros should now support bluetooth headsets out of the box, one needs to follow instructions from [1]. [1] http://wiki.openmoko.org/wiki/Manually_using_Bluetooth#Once_Again.2C_Bluetooth_Headset_on_Freerunner I beg to differ, but if those instructions mean out of the box, then all commandline things are out of the box as well. Commandline instructions are very nice, but when you're in a car and try to pair with the car bluetooth, this is not practical at all. You need a gui there... You Qtopia guys seem to have a quite unusual (for a unix hackers) POV ;) Framework already supports BT headsets. The fact GUI is missing shows the lack of interest from end-users, well, i think it'll change soon. The fact stable telephony is still missing since 2 years doesn't seem lack of interest :P Seriously: BlueMoko is intended mainly as GUI for Bluetooth because every 20€ phone has its own... I started as proof-of-concept with those dependencies as they are the most stable to my daily use distro and working properly for my experiments, but consider it uses only DBUS calls to Bluez so if APIs don't change too much (I have to verify) it should work with Bluez4 too and for FSO I plan to integrate compatibility with it to let it work with every distro (except qtopia based obviously, but they should still have their BT GUI). Furthermore I didn't read of A2DP support in FSO and BlueMoko started with it in mind ;) If FSO team agrees too, they can integrate my future plans (file exchange, AVRCP, networking...) and we can work together to provide full BT support, provided I'd like to customize GUI handling to achieve compatibility with different toolkits (GTK, Elementary, console, etc..) Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets in FSO
Franky Van Liedekerke ha scritto: Framework already supports BT headsets. The fact GUI is missing shows the lack of interest from end-users, well, i think it'll change soon. hmm ... I thought end-users were people actually using the phone, not unix-hackers ... That's why I wrote it ;) but I saw the announcement of a bluetooth gui for Om2008, aboeit for bluez3. Well those are minimum requirements as I couldn't test other distros but, as I wrote in the last post, I use only DBUS calls to Bluez so maybe it should work on other distros (probably in FSO to given I don't use FSO calls yet...). The only userspace dependency is PyGTK but I think almost every distro has it installed. I think the only real issue could be the power and reset /sys files which change between different kernel versions... I accept suggestions and patches too :P Thank you, bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debuzzing
Dr. H. Nikolaus Schaller ha scritto: Dear community, 2) Therefore we plan to offer this service to all Openmoko owners within the EU harmonized market / tax union (to avoid re-import/export hassle). Please note that there will be a rework fee. The final price is not yet clear (expected to be less than 30 EUR incl. shipment) because we are in intensive discussions with Openmoko how they can help to reduce this fee for you. ... 4) If you are interested, please register yourself and your device at the following link. We will then follow up with details about handling, address to send to, time schedule, final pricing etc. http://www.handheld-linux.com/wiki.php?page=Buzz-Rework So stay tuned, Nikolaus Hi, are there particular offers/facilities for Golden Delicious customers? Thank you in advance, bye. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FatFingerShell vt with fullscreen keyboard
The Digital Pioneer ha scritto: Hey, this is great! Best FR terminal I've seen. I do have a question though... In the output, it says ./fatfingershell: can't access font 8x13, trying fixed just before creating its GUI. That doesn't seem to be a problem, but I don't like rogue error messages, so where can I get that font? Hi, I get the previous error and then this message, after GUI creation, and the program quits: ./fatfingershell: select failed Using Om2008.9+FDOM, any suggestion? Thank you very much for this great idea! :) Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FatFingerShell vt with fullscreen keyboard
Rafael Ignacio Zurita ha scritto:
Hello,
--- On Fri, 3/27/09, DJDAS dj...@djdas.net wrote:
Hi,
I get the previous error and then this message, after GUI
creation, and
the program quits:
./fatfingershell: select failed
Using Om2008.9+FDOM, any suggestion?
No idea, could you trace the fatfingershell binary with strace -f?
If so, send me the output so I can check a bit more..
Thanks
Hi,
these are the last lines printed by strace (didn't know I had it
installed :P):
gettimeofday({1238166214, 933399}, NULL) = 0
ioctl(255, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbed86a9c) = -1 EIO
(Input/output error)
rt_sigaction(SIGINT, {0x4bc18, [], 0x400 /* SA_??? */}, {0x4bc18,
[], 0x400 /* SA_??? */}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD TSTP TTIN TTOU], [], 8) = 0
ioctl(255, TIOCSPGRP, [3249]) = -1 ENOTTY (Inappropriate ioctl
for device)
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
setpgid(0, 3249)= -1 EPERM (Operation not permitted)
rt_sigaction(SIGHUP, {SIG_DFL}, {0x4b9dc, [HUP INT ILL TRAP ABRT BUS FPE
USR1 SEGV USR2 PIPE ALRM TERM XCPU XFSZ VTALRM SYS], 0x400 /* SA_???
*/}, 8) = 0
kill(3249, SIGHUP) = 0
--- SIGHUP (Hangup) @ 0 (0) ---
Process 3249 detached
If you would like to have the complete trace, I'll send you privately as
I think list people don't want to download/read kilobytes of stuff :P
If it could help you, as tracing slows the execution, I saw the image
showing the keyboard and the transparent panel, but it seems to stop and
quit before getting the bash prompt.
Thank you in advance, bye.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: List of OpenMoko distributions
Ron K. Jeffries ha scritto: Q1: Where does one find a list of all current OpenMoko distributions? Q2: Is there an effort to make one of these distributions THE production version that ships on new phones after some date? Is that date established or up in the air? Q3: if one orders a Freerunner today, what code does it ship with? Observation: GTA02 has been shipping for about 9 months. It's not unreasonable to expect that stable, fully functional code will be available Real Soon Now. --- Ron K. Jeffries http://blog.eronj.com A1: http://wiki.openmoko.org A2: http://wiki.openmoko.org A3: http://wiki.openmoko.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner GSM Buzz fix, warranty and hopes...
Helge Hafting ha scritto: As for the buzz, it depends on how bad it is. If the other end can't hear you properly then it is a defect. If they get some background noise that don't prevent the use as a phone, then it merely is a phone of low but useable quality. Helge Hafting The buzz is very bad! There are situations in which the other party shouts me he/she can't hear nothing but the buzz... It's definitely a defect IMHO, not only a matter of quality, in some situations it prevents communication to continue... Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] ButtonPress event for button 3 (right mouse button)
Matthias Apitz ha scritto: Hi, The question is seriously, so please don't respond with 'use the right finger': How can I generate the X11 event ButtonPress/ButtonRelease for button 3, i.e. the right button of the mouse, with the touchpad of the FR? Thx Sorry for that, I was in funny humor yesterday :) Normal use in touch screen devices is to catch the long touch as right mouse, Qtopia does this, in fact if you open notes in Om2008.x distros create a note and then on that one you click and hold your finger you'll see a popup menu. I think the same could be implemented by frameworks or by daemons but unfortunately I don't know how. This could solve almost the right-click I think mid click could be solved with a button (AUX?) and left click or right click as suggested by Risto Bye :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] vncviewer vnc_3.3.7-r0 but scrolling does not work
Max Giesbert ha scritto: I know this behavior from the desktop. There you have to use a right mouse click to scroll backwards... Dunno how to get a right click on the Freerunner though... Use your right finger :P ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.x] UMTS based on USB adapter
Matthias Apitz ha scritto: Hello, Is anybody using UMTS connections with the FR based on USB connected modem devices like the USB HSDPA Huawei E220 one? Any other ideas as devices? Thx matthias Yes, I do and it works pretty well (not considering battery drain ;) ) You can find some informations here [1]. I'm sorry they're in Italian as they're some little guidelines to achieve HSDPA connection given to a forum user, I hadn't time yet to put up a how-to, but just following the scripts and using an automatic translator should help you. :) P.S. where you see FDTF consider it a distro built onto an FDOM version of September with some customizations (themes, some progs and Italian keyboards) so consider it an FDOM ;) Have fun! Bye! [1] http://forum.telefoninux.org/index.php/topic,1035.msg10579.html#msg10579 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.x] UMTS based on USB adapter
Matthias Apitz ha scritto: El día Tuesday, February 03, 2009 a las 02:35:06PM +0100, DJDAS escribió: Thanks for the pointer. I do Spanish and so I can read the page. :-) Your modem is as well Huawei E220? I have had one borrowed by Vodafone and it worked well on my FreeBSD laptop too; but I was asked to return it :-( Yes it's exactly an E220 do you have an idea where to buy one in EU without a contract of UMTS? I have an UMTS SIM but only a PCMCIA card :-( Well, I bought on ebay by an italian user, try there, I think you can find modems without the needing of a contract. is there any way to use something like an USB-splitter to connect the USB of the FR to the modem and at the same time to a laptop? matthias Uhm, IIRC there is a wiki page with some explanations on connectors to achieve this. Bye :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QWO (was Re: handwriting recognition)
Josh Thompson ha scritto: Nope, look at this: http://www.nongnu.org/qwo/ Bye :) On what distro are you using QWO? I just tried it on SHR, and nothing ever shows up. If I ssh in to my FR with my display forwarded to my desktop and run it, it seems to work ok. Anyone know how to make it show up in SHR? There is a problem with localization variables, you should add in your profile scripts (you can use /etc/profile or create an executable script in /etc/profile.d) the following command: export LC_ALL=C Furthermore if you want to use special characters like accented or similar, you have to do some magic stuff :P to configure the xmodmap settings to enable the key codes, you can find some info (in Italian sorry, but you can use an automatic translator as it's not so complex speaking) here [1], you also will find a tar file containing all the files referenced in the post which let you use accented characters. [1] http://forum.telefoninux.org/index.php/topic,935.msg9276.html#msg9276 Bye :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: handwriting recognition. was:Re: Dual touch display
arne anka ha scritto: there's rosetta http://www.handhelds.org/project/rosetta/ another attempt is cellwriter http://risujin.org/cellwriter I use QWO since December and I feel very nice with it, forgot any other keyboard and dictionariesvery good input method. Bye :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: handwriting recognition. was:Re: Dual touch display
arne anka ha scritto: I use QWO since December and I feel very nice with it, forgot any other keyboard and dictionariesvery good input method. what's qwo? the qtopia one? _ Nope, look at this: http://www.nongnu.org/qwo/ Bye :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: handwriting recognition. was:Re: Dual touch display
arne anka ha scritto: Nope, look at this: http://www.nongnu.org/qwo/ quikwriting (qwikwrite?). yes. i've seen that before. is it really that good? IMHO the best one I've never seen I became very fast after few days (now I have a counter problem, as I'm too fast doing gestures that I make much mistakes :P) It's very customizable and (almost for latin people) you can add accented letters and other key codesUsing it in terminal too with no effort...try it ;) Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM 2008.12] Enlightenment Drop Shadow Performance
Carsten Haitzler (The Rasterman) ha scritto: Billk I've seen Enlightenment running between 18% and 30% most of the time lately, with SHR. And I just discovered I am able to drop it to 3%-5% and bring it back through a single change: I've been tweaking some Oxygen icons and using them under SHR - 256x256 png versions. (Why? Well, I like my icons big, but I hate them pixellated) Anyway, changing from the 256x256 Oxygen icons to the 86x86 SHR icons dropped me from 30% to 5%, restoring the big Oxy's brought me right back to 30%. icons include battery too? Hi! Same problem here with a fresh installed (onto SD card) SHR (snapshot of 16 December w/ kernel of 14 December). Enlightenment takes 40-60% CPU but I was not able to find a solutions, will try this icon trick and let you know. Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stage of GTA03 development?
Michael Zanetti ha scritto: As It seems this thread is becoming more and more some sort of a whish-list, I will put my 2ct here also: - Please don't add a camera: Has ever anyone made a picture with a mobile phone camera that doesn't suck? Get a real camera if you want to make some nice pictures! There is just one way to get a useful camera within a mobile phone: Using very expensive optical lens and zooming technologies. But in that case, I'd prefer to use the money for a 3G modem which brings me to the next point in my whishlist. - 3G connectivity: Although it is very expensive, I think we _really_ need this one. I know so many people who would like to buy a Freerunner, but they don't do so because of the missing UMTS connectivity. - The rest could stay just as it is in GTA 02. Im perfectly happy with it. Perhaps the slow Glamo could be exchanged... But afaik this is done already... Cheers, Michael +3! (me, myself and I :P) Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: case manufacturing
rakshat hooja ha scritto: ponoko.com http://ponoko.com would do it for you, or emachineshop.com http://emachineshop.com if you get some pricing, could you let us know -- even your desgin? i am still pondering the idea of a new casing ... Thanks. will update when I get pricing. My design is still at the idea stage - add a USB keyboard (qwerty) into the case design itself. Will make it heavier but helps my use case as I want to stop carrying my laptop with me when I have the Freerunner and the onscreen kb (illume), though good, is slightly small when typing out documents. (Guess I am looking for a Blackberry equvalent) Rakshat Great idea :) What about adding an HSDPA modem like Huawei's Internet keys (adding only the board, not the full external modem) connected via a bypass to the USB port (to achieve charging even in host mode)? This could be useful too as we could have a dual SIM phone ;) Bye :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Switching the orientation of the screen
Robin Paulson ha scritto: 2008/12/11 Clemens Dörrhöfer [EMAIL PROTECTED]: I am starting to learn pygtk and my helloworld Project is this primitiv gui, which lets you switch the orientatin of the screen. I don't like the automatic switching and with the help of this, I can do it manually. It's not pretty, but it works. If you find it usefull, feel free to use. The tar archive contains a mercurial repository so don't hesitate to send me changelogs if you come along big programming sins. does it cure the problems that are present when this is done from the commend-line, with xrandr? i've been using a shell script, but find switching orientation more than about 3 times will give problems like a misaligned screen and Sorry for being a little OT, but what do you mean with problems that are present when this is done from the commend-line, with xrandr? If you mean the mess after the rotation (strange lines/graphic that fixes after a refresh) I noticed this doesn't appear using the gestures rotation, anyone knows why? If you mean misalignment of the touchscreen calibration, I noticed (speaking about gestures rotation) that this appears only when the screen is rotated upside down (phone oriented vertically with hole on top ;) ), while the remaining three positions are well calibrated. Is there an explanation about this? Thank you in advance, bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Android] Converting a brick into a phone
Andreas Fischer ha scritto: I totally disagree. First, I do not think that phones age that quick. I used an age-old Nokia phone (I think it was a 3510 - ca. 2002) until I got my Freerunner this summer. Unless something unforeseen happens, next summer the two Neos will _still_ be the only fully opensource smartphones out there. Outdated or not - there is no competition. Second, my understanding was that GTA03 is not yet created but only planned at this stage. Hearing that not even the OM engineers have it yet, I'd not expect gta03 before the next stable release. Third, the statement that nobody really used it, yet is wrong unless I am nobody. I am using it on a daily basis and from what I am reading on this list, others are too. Finally, we are not talking here about a release of a first working software stack but about a switch to a different software stack from an already working (though with several shortcomings) software stack. Totally agree with you! :) I use my FR since September (bought in July but was a very pain until September) as a daily phone with FDOM and I have no problems except the following two: 1) buzzing noise (always when GSM signal strength becomes lower than half scale); 2) can't use bluetooth headset (according to wiki I'm able to pair and connect but I don't hear any audio) For all the remaining features I think it's a great device and I'm a very proud owner :) Great job guys! Go on! ;) Bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Funding Global Domination
Arigead ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Minh Ha Duong wrote: Le mercredi 03 décembre 2008, arne anka a écrit : The second option is more like it. It takes a few hours to design a T-Shirt and upload it to an online store where everybody else can go and buy it. So just do it: the entry costs are so low that there is no real need for a formal market study ! Rui: There are lots of cool artwork under a Cc: license on the wiki including the hardware schematics and What about making a T-shirt with the hardware schematics? ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Funding Global Domination
Steve Mosher ha scritto: please do. DJDAS wrote: What about making a T-shirt with the hardware schematics? ;) Well :) I'm a bit practical with The Gimp, I'll try to do something in the weekend, in the meantime I accept suggestions for the file format, size, color numbers and so on so I'll have some guides before doing any work...Never made a T-shirt before :P Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
OMoney? :O
Hi all, I was thinking about an expense handling program (like HandyExpenses on Symbian phones), I have many ideas in mind but didn't write anything yet, but looking at some screenshots at linuxtogo I saw these: http://scap.linuxtogo.org/index.php?page=6 I didn't find such an application (tried googling and at opkg.org)...Does anybody knows where to find and try it? Thank you in advance, bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Survey about the Touchscreen
Al Iasid ha scritto: IMHO having to dig out a stylus (pen) or use my fingernail is not nearly as convenient or enjoyable as a finger-friendly interface. I don't min hi res or low res - or big or small screen size - as long as the interface is finger-friendly. The cell phone is our most intimate personal device. There should be no intermediary in the user interface. Aliasid +++ definitely agree :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[OM2008.9 - FDOM] Re: Will there be a hardware revision for the buzzing issue?
Dear members, I follow the list since October, although I own my Freerunner since July. I owned a A5 before I needed its substitution from my seller because the handsfree speaker stopped working so now I own a A6 revision. I live in Italy and my carrier is Vodafone. I noticed this (appeared in both hardware revisions): during a call, if the signal strength becomes lower than midrange (looking at the top icon, can't know exactly the level) the buzz appears, while in the middle-high levels I have no buzzing at the other side. Furthermore, when the signal is around the mid range, if I put my hand on the bottom side of the phone (I remember the GSM antenna is located in the arc under the hole) the signal increases a bit its level and the buzz disappears (not always but in a sensible number of situations it does). Maybe the buzz is relative (or not only) to the GSM signal strength so via software is it possible to amplify it or issue some commands to the modem to avoid it? My 2 cents :) Thank you for your great work from a proud Freerunner user ;) Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Minty Boost FreeRunner
Cédric Berger ha scritto: I did not have a look at neo's circuitry. But whatever the method it uses, it cannot force 1A if 1A is not available (wall charger unplugged from the wall won't give 1A :-p ) ? Uhm...not exactly true... Ohm Law says: V = R * I - I = V/R, and if R-0 then I-oo In practice if you power a load with a little impedance (in real systems the load is not always only resistive) the current requested will grow and the source could be damaged (try to short circuit a normal battery, you'll see a flash and if you maintain the circuit closed you'll meld the battery). This is why you should not ask 1000mA from the USB port (for example) unless you're sure the hardware could give it. Bye :) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
Sarton O'Brien ha scritto: Speaking of formatting ... I imagine there's a reply in there somewhere :P On Tuesday 21 October 2008 01:31:21 DJDAS wrote: !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN html head /head .. /body /html Sorry :P Sent in HTML. I simply suggested a man indent ;) Bye! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One more rotate version
Rui Miguel Silva Seabra ha scritto: On Mon, Oct 20, 2008 at 01:33:20PM +0200, Fabian Henze wrote: On 20.10.2008 at 12:00:36, Rui Miguel Silva Seabra wrote: On Mon, Oct 20, 2008 at 01:37:33AM +0200, Fabian Henze wrote: As it seems popular these days to publish a custom version of the rotate program, I am also going to do it. heh, you could've just sent a patch :) Then I would have to write in your style, which I am not used to :p It would be easier than fixing the indent in order to join the patch and have you as a co-author :) I'm not prickly about any style, that's just my default and it's manually done. If someone can cookup indent recipes for converting between one and another I'd gladly use it to facilitate integration :) "man indent"? ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: console command history
Carsten Gerlach ha scritto: Hi, Am Dienstag 14. Oktober 2008 3:13:14 am schrieb Joel Newkirk: On Mon, 13 Oct 2008 22:26:10 +0100, Stroller wrote Isn't it in .bashrc or .bash_profile? Stroller. it is for bash, but OM distros are using an sh/ash replacement builtin to busybox. ~/.bashrc is for bash. What is the corresponding file for sh/ash? ~/.ashrc? or ~/.shrc? Greetings, Carsten I use ~/.profile and it seems to work :) My 2 cents ;) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concept arts. Interface - how I would like it to see.
Daniel Hedblom ha scritto: Expanding capabilities with gestures is nice and can add usability to a device. Using them as the default way of accomplish things makes the device very hard to use for a beginner. That is why configuration dialogs were invented ;) there could be an option which let you choose to slide menus and shelves (or anything else) by click or gesture (or both :P ) Having the only way of opening a menu or something only possible if you already know exactly what to do is a killer for usability. I think the main goal should be that anyone can pick a device up and use it without prior knowledge. Sad to say but iPhone/iPodTouch teach this (I don't want to say it's the ONLY way to do GUIs, and for something I don't like them, but I saw a colleague of me using it as he was using a notepad or photo album in a very user friendly way...) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Concept arts. Interface - how I would like it to see.
wp wrote: What is your opinion? Say what you like, and what you don't? Make your own pics, share it with us. Free the imagination! Very very nice :) Why not substitute the touch for the left panel with an accel gesture that slides the panel tilting the phone? This could lock the panel and using other accel gestures like up or down (to speak like accelgest language) slide the application panels or something else like paper sheets. Touching the icons could launch the application or (in some point of the screen) unlock the panel and go back to the main screen. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
