Re: Seamless switching from gprs to wifi calling
On Thursday 07 June 2007 23:05:44 mathew davis wrote: Dear community, I am not sure if this is a widely known thing or not, but I just found out about it and had some questions about this working on the neo. T-mobile has hotspots all around my area, but have been experimenting with a new service called T-mobile HotSpot @Home. It uses a UMA (unlicensed mobile access) technology to allow phones to switch from cellular connection to Wi-Fi connection. And also makes it possible for VoIP calls. So this is something that is very interesting to me only I would like it to be a little different, I don't want to use T-Mobile's service I would like to use my Wi-Fi connection to my VoIP of choice. I know this has been talked about before with some options including an Astrex box forwarding the call to your cellphone until your in range then switching to Wi-Fi but that was not a very seamless transistion from my understanding. So I guess my question is could we impliment a UMA type of technology for the neo that is customizable to use our VoIP provider? Or since that particular part is locked we wouldn't have access to that part? Be careful. UMA is not VoIP as is usually meant. UMA is more like GSM over IP. Basically GSM signalling is carried by an IP network. So from the GSM network point of view, it's relatively easy to handle seamless handover. What you'd rather want would be more IMS alike, with SIP used as a common signalling protocol across a wide range of support networks (TDMA, W-CDMA, wifi, wimax...). Unfortunatly, it won't be rolled out massively before a few years. So our best bet, as of now, and since we don't have GSM carriers on the bandwagon (yet!), is probably to have SIP and GSM co-existing on the same handset in the best possible way. The best products of that kind I'm aware of are currently the wifi-enabled Nokia N- and E-Series phones. -- Nicolas Bougues Axialys Interactive ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Yet another contender in the market?
True. But there really is a marked beside the mainstream. The Nokia 770/N800 is the proof. This devices is not really cheap (about $400), has not many abilities (no GSM, no DVB, no keyboard, only WiFi) but it sold good enough to continue the productline. OpenMoko can do that better. Every linux-fan must have such a phone. Every opensource-fan, too. As soon there is some more additional software available for OpenMoko the Neo will probably be the most useful smartphone out there. The possibilities with the GTA02 hardware will be amazing. Let's hope FIC will release GTA01 for all developers and interested people soon - that definatly will cause a solid increase of available software. 2007/6/7, Tim Newsom [EMAIL PROTECTED]: You and *I* feel that way... But the general public will be taking stock of the appearance and ease of use etc... Besides.. I mentioned it so that we can take a look at the view some general person my have of a new device and see how we can improve upon any weaknesses. There will be no shortage of devices competing for the top spot... And against the iphone. Many, Many all touchscreen devices will be out there.. And we are not going to be first... So we can at least acknowledge the competition and work to improve what we can. --Tim On Thu, 7 Jun 2007 11:18, Thomas Gstädtner wrote: There already was Samsung phones with HSDPA support which was slower than normal UMTS phones of other manufacturers. Also flash lite might be good looking, but it is definately no smartphone platform. At least you cannot use the UI for additional apps (must be an overlay). The display resolution is very poor for a such big screen. For me this devices is pretty uninteresting, and even if it'd be able to run openmoko that wouldn't matter for me. Why should I give my money to a company that doesn't support opensource only to use their hardware with hacks and openmoko? Let's hope OpenMoko and the FIC Neo1973 will be successful and FIC produces more open phones in future. 2007/6/7, Tim Newsom [EMAIL PROTECTED] : Hmm... I thought it listed wifi and bluetooth on samsungs website... --Tim On Thu, 7 Jun 2007 8:57, Mark McClellan wrote: nice. very nice. i really hope this is close to the Moko v2 hardware. it's what i'm waiting for Mark On 6/7/07, Eric Heinemann [EMAIL PROTECTED] wrote: If I remember correctly, the F700 is using a Flash lite interface. Even though it does not have WiFi, it does have 7.2M HSDPA :) I am pretty sure it does have bluetooth though. Look here: http://www.gsmarena.com/samsung_f700-1849.php or here: http://www.phonearena.com/htmls/Samsung-SGH-F700-phone-p_1941.html -Eric - Original Message From: Steven ** [EMAIL PROTECTED] To: Openmoko community@lists.openmoko.org Sent: Thursday, June 7, 2007 9:44:30 AM Subject: Re: Yet another contender in the market? The wallpaper on the F700 from the first Google result ( http://gizmodo.com/gadgets/cellphones/apple-iphone-vs-samsung-f700-which-is-touchscreenier-235112.php ) is a total rip-off of the Ubuntu default theme. I doubt that they're actually running Ubuntu (although I think Ubuntu is getting into the mobile market). The features don't really seem comparable. No wifi and no bluetooth. And the screen is even smaller and lower resolution than the iPhone. -Steven On 6/7/07, Tim Newsom [EMAIL PROTECTED] wrote: Has anyone else seen the samsung F700? Its features are pretty nice... No idea on the OS but I would definitly take one over an IPhone... If it performs anything like it looks... Hehe. Its got very good specs. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. Check it out. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Dangling carrots usually contain a hook. 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 --Tim ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Seamless switching from gprs to wifi calling
To get back to what Mathew asked: I don't think a T-Mobile [EMAIL PROTECTED] is switching calls back and forth as you get in reach of a hotspot, and walk away from it. Secondly: this only works with T-Mobile! (for now) T-Mobile has probably set up a [EMAIL PROTECTED] call server near their GSM traffic backbone, on which your phone logs in, and through which your GSM traffic goes (with that UMA protocol) while you're logged in (in reach of a public (T-mobile) hotspot). Calls that already take place can't be re-routed I guess... Anyway, what I'm trying to say is that firstly: you need T-Mobile as your operator. Secondly: you need that T-Mobile HotSpot @home plan. Thirdly: you need a phone that's capable of routing your GSM traffic through UMA, to the T-Mobile UMA server/backbone/whatever they call it. As for the Neo1973 and OpenMoko: The phone can most likely do it, because the software just needs to know how to do it. BUT, I don't think T-Mobile will tell you how to log in. T-Mobile makes the phone software themselves for a reason. If they show you how to make a phone log in, you can make a program that logs your computer in too. So a FOSS solution for this probably won't come easily. -- Luit PS: sorry for the double post Johnson, it bounced because I mailed from the wrong account On 6/8/07, Al Johnson [EMAIL PROTECTED] wrote: Check the archives for a full discussion of this. In short GPRS is unsuitable for VoIP because of the high latencies, often in seconds. The GSM data mode is more suitable even though it's only 9600. It should be possible to have Asterisk route calls to the right VoIP endpoint, or to a GSM voice call if it can place calls to the PSTN. The trick comes in knowing when to hand over, and having a unified client that'll get Asterisk to do it. On Friday 08 June 2007 06:21, kenneth marken wrote: mathew davis wrote: Dear community, I am not sure if this is a widely known thing or not, but I just found out about it and had some questions about this working on the neo. T-mobile has hotspots all around my area, but have been experimenting with a new service called T-mobile HotSpot @Home. It uses a UMA (unlicensed mobile access) technology to allow phones to switch from cellular connection to Wi-Fi connection. And also makes it possible for VoIP calls. So this is something that is very interesting to me only I would like it to be a little different, I don't want to use T-Mobile's service I would like to use my Wi-Fi connection to my VoIP of choice. I know this has been talked about before with some options including an Astrex box forwarding the call to your cellphone until your in range then switching to Wi-Fi but that was not a very seamless transistion from my understanding. So I guess my question is could we impliment a UMA type of technology for the neo that is customizable to use our VoIP provider? Or since that particular part is locked we wouldn't have access to that part? Just curious. When I get the phone I will be playing with trying to find a solution to this problem. I have very limited knowlege about this kind of thing. I am not an experianced programmer yet. I only have about 3 yers of indestry experiance, but none of that is mobile development and almost none of it is linux related, so I have a bit of a learnign curve so that is why I am asking the question here. while not fully up to speed on how it all works, here is my quick take on it: as long as its a voip connection, and said voip service allows two ip's to share a account and call, there should be little to no problem having both a wifi and gprs connection open at the same time as one moves about (in my experience a gprs connection can be held open but not used). hell, one may even use bluetooth if it can handle the data transfer. the problem here is that ip thing. UMA has a normal mobile phone connections as one option so therefor dont have to think about multiple ip's. it just need to have a internet connected cell so to speak, and only hand the call over when the ip based connection is fully in place. however im guessing there are some issues with going between two wifi zones/networks or something similar... so mostly you need a voip service that allows you to log in from another ip without booting the old connection off or hanging up any calls. after that its mostly a case of the client software figuring out what of the two connections to send on. or maybe just send on both, expecting the service to throw away the data thats a duplicate. something that i think is a basic feature in mobile phone systems. one funny thing is that if your using voip, and have a flat rate data plan for your mobile phone, there is no need to go wifi anyways as the mobile data connection will probably be more reliable given that its already built to do what one is trying to make the wifi system do (handover, multiple connections and overlapping
Re: community involvement todo?
Hello. On Fri, 2007-06-08 at 02:41, Philippe De Swert wrote: So I would like to propose a todo list on the wiki. This should list a number of tasks which people can take up with a short explanation of what has to be done and what is expected. We already had some thoughts about such 'junior tasks'. I really like the idea to give interested people small tasks for a quick start. The real problem is to identify such tasks. Most of the stuff is still much work in progress. We should start such a list anyway. :) I'll see if I come up with some ideas in the next days. This coupled to a seperate email address or mailing list. After which the devs can add the patches I would vote against another ml. We already have enough. Just send the patch to the ml for the stuff you are hacking on: u-boot, kernel, application... Alternatively we can make sure that more bugs are filed in bugzilla with detailed explanations. This is of course always a godd idea. :) Any comments? People willing to take up co-ordinating, devs willing to check this out, ...? Please start the page in the wiki. You guys can already write down some tasks and I'll poke my colleagues to add some more. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
Stefan Schmidt wrote: We already had some thoughts about such 'junior tasks'. I really like the idea to give interested people small tasks for a quick start. Regarding quick starts, perhaps some sort of tutorial could be useful, e.g. - how to get the basic development/run-time environment - how to set up QEMU - how to add/change things to/in the run-time environment - step-by-step description for building a graphical hello world application (code layout, widgets, build process, packaging) - pointers to reference code for the most important widgets and/or use of infrastructure interfaces The real problem is to identify such tasks. Most of the stuff is still much work in progress. We should start such a list anyway. :) One problem is also that many small tasks involve a lot of context. So it's two weeks of learning, five minutes of coding, and even then you probably don't do it quite right. Of course, once the learning curve is mastered, things improve significantly. An example for an a bit meatier project, without too many dependencies may be the implementation of a working prototype of the finger splash input method: http://www.micropp.se/openmoko/ An example for a project with lots of cross-dependencies would be a cleanup of the u-boot build process. It would be great if the build process was non-verbose by default, like we have it for the Linux kernel. If anyone wants to tackle this, the best starting point would be u-boot upstream (and synchronize with the upstream developers). A build infrastructure idea: it would be great if BitBake would support entire quilt patchsets, e.g., by pointing to the series file. (Stefan, see yesterday's discussion on #openmoko-devel.) I would vote against another ml. We already have enough. Just send the patch to the ml for the stuff you are hacking on: u-boot, kernel, application... For reasonably self-contained small projects, we also have projects.openmoko.org - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
Hello. On Fri, 2007-06-08 at 07:01, Werner Almesberger wrote: Stefan Schmidt wrote: We already had some thoughts about such 'junior tasks'. I really like the idea to give interested people small tasks for a quick start. Regarding quick starts, perhaps some sort of tutorial could be useful, e.g. - how to get the basic development/run-time environment - how to set up QEMU Should be both in the wiki already, no? - how to add/change things to/in the run-time environment Hmm, do you mean before the buil with OE or working on the live system? - step-by-step description for building a graphical hello world application (code layout, widgets, build process, packaging) - pointers to reference code for the most important widgets and/or use of infrastructure interfaces That's indeed a big missing point. On the other hand two projects already found it way in our tree, rss-reader and calculator, which means it seems possible to learn how it works. ;) Anyway we should fill this gap even if I don't know when we have time for this. :( The real problem is to identify such tasks. Most of the stuff is still much work in progress. We should start such a list anyway. :) One problem is also that many small tasks involve a lot of context. So it's two weeks of learning, five minutes of coding, and even then you probably don't do it quite right. Of course, once the learning curve is mastered, things improve significantly. Good point. [Examples] So the wiki page should have the following for every single task: Description, needed skills, links to reference code... If nobody beat me, *hint*, I'll add these tasks and perhaps some more to the wiki tonight. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Iphone 3rd party development allowed...
I am sure Jobs and company are not blind to the strength of open source software and the boon it would provide if they made a freely available dev kit for the phone. As someone who worked at Apple for ten years, I can assure you that, for the most part, Jobs and company haven't got the slightest interest in open source software, other than a minimal amount of stuff available under a BSD-like license, allowing them to take it, do what they want with it, and then keep it to themselves. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
Stefan Schmidt wrote: Should be both in the wiki already, no? Yup, so the walk-through should just explain the easiest approach, and link to the more detailed background material for the rest. E.g., the QEMU part doesn't need all the background information from the QEMU page. Trimming the MokoMakeFile information may be a bit harder. - how to add/change things to/in the run-time environment Hmm, do you mean before the buil with OE or working on the live system? Pick one :-) The idea is to give an answer to how do I run my application on QEMU or my Neo, for testing. There are many possible answers. The getting started guide should give one that's reasonably efficient and reasonably fool-proof. That's indeed a big missing point. On the other hand two projects already found it way in our tree, rss-reader and calculator, which means it seems possible to learn how it works. ;) Yeah, but this should be really easy. Most beginners won't care to understand all the fine points of our build process, at least not initially. Anyway we should fill this gap even if I don't know when we have time for this. :( Perhaps this makes that one more item for the contributions we'd appreciate list. People who have gone through a certain learning experience recently are usually in the best position to describe it. Any bugs/inefficiencies can be filtered out through peer review. [ Tautology deleted ], I'll add these tasks and perhaps some more to the wiki tonight. Great ! :-) - Werner -- _ / Werner Almesberger, Buenos Aires, Argentina [EMAIL PROTECTED] / /_http://www.almesberger.net// ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Mono runtime port
As anyone tried to run mono on OpenMoko ? I'm really interested in this, and im already doing some work to see how much i can reduce it's footprint, but i don't want to reinvent the wheel and waste valuable time. So as anyone worked on this ? Regards, Daniel___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: UI ideas/questions or can we animate things as smooth as iPhone?
Imho the EFL are the best choise for a device like the Neo. But, which backend for evas ? Framebuffer ? X ? OpenGL (i don't think there's an evas Opengl ES implementation..) ? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: UI ideas/questions or can we animate things as smooth as iPhone?
Hi, We should try different options, do some serious benchmarks and based on the results we could choose the best solution. Some options would be: - X11/GTK - X11/EFL - DirectFB/GTK - DirectFB/EFL Both, GTK and EFL, have backends for X11 and DirectFB, so running demos and apps shouldn't be a problem. Running DirectFB/GTK works fine in embedded systems, I used it in a PNX8550 processor, but the Neo's processor doesn't have that processing power... According to the ELF doc, the Evas library with DirectFB backend is designed with embedded systems in mind, but I haven't tested it. At least in the i386 platform works great. One real problem I see is that for making some benchmarking we need the real hardware, an emulator wouldn't be reliable. Regards, -- Pedro Aguilar Imho the EFL are the best choise for a device like the Neo. I'm really looking forward to have a EFL-based gui as alternative to the GTK-gui. 2007/6/8, Florent THIERY [EMAIL PROTECTED]: Related tutorial : http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB_for_Embedded_Systems The choice should be driven by benchmarks results. EFLs are on the row too... Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Mono runtime port
All I've seen so far is this registered project. I too am very interested in getting Mono Up and running, as I am a .NET developer. I seriously doubt we'll see very good performance on the first generation Neo Hardware, but the next generation sounds very promising. http://projects.openmoko.org/softwaremap/trove_list.php?form_cat=271 On 6/8/07, Silva, Daniel [EMAIL PROTECTED] wrote: As anyone tried to run mono on OpenMoko ? I'm really interested in this, and im already doing some work to see how much i can reduce it's footprint, but i don't want to reinvent the wheel and waste valuable time. So as anyone worked on this ? Regards, Daniel ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Java (was: Re: OpenMoko - We Need HYPE, and we need it yesterday!)
please point your browsers to http://de.sun.com/ I am not sure how long it will be there - but to see is JavaFX Mobile - with a (slightly trimmed?) Neo1973 and you can see the FIC-Logo. I think the Neo _has_ some attention. The hardware in that demo is almost incidental. JavaFX Mobile is a complete alternate mobile stack based entirely on Java, and all the APIs are in Java. It has its own Linux port, based on work done by Savaaje, which Sun acquired a few months back. While this might initially position JavaFX Mobile as a direct competitor to OpenMoko, I've seen blogs in which Sun was quoted saying it would be GPL'd, so it should (might) be possible to blend them. Or, it might be better to do our own port of phoneME to OpenMoko. I don't know which approach is better in the long run. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: UI ideas/questions or can we animate things as smooth as iPhone?
The problem with evas as i see it, is the available developer pool. GTK as of now is more mature and has many more knowledged developers available. One other problem is that i don't see many language bindings for EFL ( at least mature ) other than Ruby, that could hinder a bit future development/support for more languages. Another option, i just thought it abiut it now, is to loose GTK and EFL altogether and use Cairo to render all the widgets, its has many backends already available including X, DirectFB and OpenGL so that wouldn't be an issue, it also has bindings for MANY languages so that isn't an issue either. It would require some initial work to program all the widgets, but i believe in the long run it would pay off. Regards, Daniel - Original Message - From: Pedro Aguilar [EMAIL PROTECTED] To: ThomasGstädtner [EMAIL PROTECTED] Cc: community@lists.openmoko.org; Florent THIERY [EMAIL PROTECTED] Sent: Friday, June 08, 2007 1:56 PM Subject: Re: UI ideas/questions or can we animate things as smooth as iPhone? Hi, We should try different options, do some serious benchmarks and based on the results we could choose the best solution. Some options would be: - X11/GTK - X11/EFL - DirectFB/GTK - DirectFB/EFL Both, GTK and EFL, have backends for X11 and DirectFB, so running demos and apps shouldn't be a problem. Running DirectFB/GTK works fine in embedded systems, I used it in a PNX8550 processor, but the Neo's processor doesn't have that processing power... According to the ELF doc, the Evas library with DirectFB backend is designed with embedded systems in mind, but I haven't tested it. At least in the i386 platform works great. One real problem I see is that for making some benchmarking we need the real hardware, an emulator wouldn't be reliable. Regards, -- Pedro Aguilar Imho the EFL are the best choise for a device like the Neo. I'm really looking forward to have a EFL-based gui as alternative to the GTK-gui. 2007/6/8, Florent THIERY [EMAIL PROTECTED]: Related tutorial : http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB_for_Embedded_Systems The choice should be driven by benchmarks results. EFLs are on the row too... Cheers Florent ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Java
Ian Darwin wrote: ... Or, it might be better to do our own port of phoneME to OpenMoko. I don't know which approach is better in the long run. Err, not to mention that there are already Linux/ARM binaries of phoneME available for free (GPL) from Sun at this page: https://phoneme.dev.java.net/downloads_page.html Might not need any porting for basic Java ME functionality (though this is a far cry from JavaFX Mobile support!). Has anybody that has GTA01 hardware tried running this? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Clarification Rant
Well since this was supposed to be available back in March, there was no immediate need. Now the pressure (for me) is starting to build. So it is more of a question of I've been waiting for ~3 months now and there is still no idea of when it is going to actually become available. Yes, I could go out and buy a cheap phone today. But then the Neo could be out tomorrow and I would have wasted my money. But its not even a money issue for me. Its a lack of communication issue. The original date was March. Sean clearly explained why they had to push back the date, but only said that new devices would be out soon. Then there was another production run and we all thought that THAT was going to be when they were available...but there were issues and we got bumped back to soon again. LCD shortages, bad production runs, whats next? Are they are going to scrap the GTA-01's in favor of ramping up production lines for the GTA-02 (since that will possibly be the mass-market hardware) but at a few months delay? So while I'm complaining, I'm also appreciative of the information that has been passed down to us. However, that doesn't erase the fact that they set a date and missed it only to be followed up with a soon response. It would be different if they had just said that it would be available in 2007, but to set an exact date then not come through? Then not even give a follow up date...it just seems a little off to me. So I know that I'm sounding really down on Sean and the bunch and that isn't my sentiment. I'm excited about what the platform has the potential to do. But its just deflating to see it failing at such an early point in the development cycle...I guess my optimism can only last so long. I guess what I'm getting at is if they can't get something out the door now (when it is arguably the most important time for the platform) then what is the future going to be like? I'm going to have to see some MAJOR progress to get my hopes back up to where they were when I first heard about and started following the project. Luit van Drongelen wrote: Well, if you can't live without a mobile phone until the Neo with WiFi comes available, why not buy a temporary 25 buck phone? That's what I'm doing now... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Clarification Rant
Agreed. I feel exactly the same way. I have said it before and I will say it again, the best part of being a COMMunity is COMMunication. In the first few months of development there was a great deal of communication, but it seems to have dwindled which makes me nervous to be honest. On 6/8/07, Jonathon Suggs [EMAIL PROTECTED] wrote: Well since this was supposed to be available back in March, there was no immediate need. Now the pressure (for me) is starting to build. So it is more of a question of I've been waiting for ~3 months now and there is still no idea of when it is going to actually become available. Yes, I could go out and buy a cheap phone today. But then the Neo could be out tomorrow and I would have wasted my money. But its not even a money issue for me. Its a lack of communication issue. The original date was March. Sean clearly explained why they had to push back the date, but only said that new devices would be out soon. Then there was another production run and we all thought that THAT was going to be when they were available...but there were issues and we got bumped back to soon again. LCD shortages, bad production runs, whats next? Are they are going to scrap the GTA-01's in favor of ramping up production lines for the GTA-02 (since that will possibly be the mass-market hardware) but at a few months delay? So while I'm complaining, I'm also appreciative of the information that has been passed down to us. However, that doesn't erase the fact that they set a date and missed it only to be followed up with a soon response. It would be different if they had just said that it would be available in 2007, but to set an exact date then not come through? Then not even give a follow up date...it just seems a little off to me. So I know that I'm sounding really down on Sean and the bunch and that isn't my sentiment. I'm excited about what the platform has the potential to do. But its just deflating to see it failing at such an early point in the development cycle...I guess my optimism can only last so long. I guess what I'm getting at is if they can't get something out the door now (when it is arguably the most important time for the platform) then what is the future going to be like? I'm going to have to see some MAJOR progress to get my hopes back up to where they were when I first heard about and started following the project. Luit van Drongelen wrote: Well, if you can't live without a mobile phone until the Neo with WiFi comes available, why not buy a temporary 25 buck phone? That's what I'm doing now... ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fwd: tomtom on the Neo1973
Hello, that is right, but only the Kernel and other GPLed Software is free to use. The TomTom Software is closed. TomTom musst optimize the software for the use on openmoko and the Neo1973. I hope they support the Openmoko platform in the future :) With kind regards Patrick Beck Am Freitag, den 08.06.2007, 17:54 +0200 schrieb Kero van Gelder: Now the answer from TomTom: Dear Mr. Beck, Currently TomTom has no plans to extend our navigation software to other platforms. However the Openmoko is an interesting development and we will keep an eye on it to see how this project evolves into the future. With kind regards, The TomTom PRO support team A friend of mine mentioned the TomTom GO is a linux device. FWIW: http://www.tomtom.com/page.php?Page=gpl Bye, Kero. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Clarification Rant
pe, 2007-06-08 kello 12:05 -0400, Alan Ide kirjoitti: In the first few months of development there was a great deal of communication, but it seems to have dwindled which makes me nervous to be honest. I'm sure the team is also quite honestly nervous to start talking expected shipping dates again after many false alarms. -- Mikko Rauhala - [EMAIL PROTECTED] - URL:http://www.iki.fi/mjr/ Transhumanist - WTA member - URL:http://www.transhumanism.org/ Singularitarian - SIAI supporter - URL:http://www.singinst.org/ ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Seamless switching from gprs to wifi calling
Thanks for all the input. Sounds very interesting. I didn't realize that UMA isn't VoIP. I don't want to use t-mobiles system. I was thinking of how I could do it without using their system, but the same idea. Sounds like I have got a lot fo reading ahead of me and that this problem is bigger than I thought it would be. Just to make sure I got every thing right GPRS is to slow. Inorder to get something like this to work you need the following: Client software capable of handling 2 streams sip and gsm. It also has to know when to hand over from one to the other. You also need a server that can handle the 2 streams and know when to throw away the extra data. Does that sound right? Just want to make sure I understand what you guys wrote. That IMS thing sounds interesting I will have to do some research on that. Thanks for the info. On 6/8/07, Luit van Drongelen [EMAIL PROTECTED] wrote: To get back to what Mathew asked: I don't think a T-Mobile [EMAIL PROTECTED] is switching calls back and forth as you get in reach of a hotspot, and walk away from it. Secondly: this only works with T-Mobile! (for now) T-Mobile has probably set up a [EMAIL PROTECTED] call server near their GSM traffic backbone, on which your phone logs in, and through which your GSM traffic goes (with that UMA protocol) while you're logged in (in reach of a public (T-mobile) hotspot). Calls that already take place can't be re-routed I guess... Anyway, what I'm trying to say is that firstly: you need T-Mobile as your operator. Secondly: you need that T-Mobile HotSpot @home plan. Thirdly: you need a phone that's capable of routing your GSM traffic through UMA, to the T-Mobile UMA server/backbone/whatever they call it. As for the Neo1973 and OpenMoko: The phone can most likely do it, because the software just needs to know how to do it. BUT, I don't think T-Mobile will tell you how to log in. T-Mobile makes the phone software themselves for a reason. If they show you how to make a phone log in, you can make a program that logs your computer in too. So a FOSS solution for this probably won't come easily. -- Luit PS: sorry for the double post Johnson, it bounced because I mailed from the wrong account On 6/8/07, Al Johnson [EMAIL PROTECTED] wrote: Check the archives for a full discussion of this. In short GPRS is unsuitable for VoIP because of the high latencies, often in seconds. The GSM data mode is more suitable even though it's only 9600. It should be possible to have Asterisk route calls to the right VoIP endpoint, or to a GSM voice call if it can place calls to the PSTN. The trick comes in knowing when to hand over, and having a unified client that'll get Asterisk to do it. On Friday 08 June 2007 06:21, kenneth marken wrote: mathew davis wrote: Dear community, I am not sure if this is a widely known thing or not, but I just found out about it and had some questions about this working on the neo. T-mobile has hotspots all around my area, but have been experimenting with a new service called T-mobile HotSpot @Home. It uses a UMA (unlicensed mobile access) technology to allow phones to switch from cellular connection to Wi-Fi connection. And also makes it possible for VoIP calls. So this is something that is very interesting to me only I would like it to be a little different, I don't want to use T-Mobile's service I would like to use my Wi-Fi connection to my VoIP of choice. I know this has been talked about before with some options including an Astrex box forwarding the call to your cellphone until your in range then switching to Wi-Fi but that was not a very seamless transistion from my understanding. So I guess my question is could we impliment a UMA type of technology for the neo that is customizable to use our VoIP provider? Or since that particular part is locked we wouldn't have access to that part? Just curious. When I get the phone I will be playing with trying to find a solution to this problem. I have very limited knowlege about this kind of thing. I am not an experianced programmer yet. I only have about 3 yers of indestry experiance, but none of that is mobile development and almost none of it is linux related, so I have a bit of a learnign curve so that is why I am asking the question here. while not fully up to speed on how it all works, here is my quick take on it: as long as its a voip connection, and said voip service allows two ip's to share a account and call, there should be little to no problem having both a wifi and gprs connection open at the same time as one moves about (in my experience a gprs connection can be held open but not used). hell, one may even use bluetooth if it can handle the data transfer. the problem here is that ip thing. UMA has a normal mobile phone connections as one option so therefor dont have to think about multiple ip's. it just need to have a internet
Re: Clarification Rant
I'm sure the team is also quite honestly nervous to start talking expected shipping dates again after many false alarms. Yeah, but if they would be totally open about the causes for delays, I'm sure the community will understand. Things are complicated, and unexpected happens. I dont care if there's false alarms, as long as they keep everyone posted. The worst is not to have any information. Carl ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Clarification Rant
I understand being careful with what you say, but even something like We've built X devices with a defect ratio of Y. We want that ration to be Z before we push the production line full steam ahead would be promising. That is unless X=0 Y=100 and Z is anything greater than zero, THEN we'd be a little disappointed. Just a quick blurb here and there go a long way, but there hasn't even been that. Also there is all of this talk about GTA-02 and how great and awesome it is going to be...but we don't even have GTA-01 out and available??? All I'm saying is that unless there is nothing positive to say, then something is better than nothing (and we used to get something a while back). So again, I apologize for negativity, but I'm finding it really hard to keep the faith and...keep waiting. Mikko Rauhala wrote: pe, 2007-06-08 kello 12:05 -0400, Alan Ide kirjoitti: In the first few months of development there was a great deal of communication, but it seems to have dwindled which makes me nervous to be honest. I'm sure the team is also quite honestly nervous to start talking expected shipping dates again after many false alarms. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: EFL/GTK UI
Hmm... this looks cool. I totally agree with the comments about WIMP (Windows Icon Mouse Pointer) interfaces. Especially for mobile devices. Thanks for pointing this one out. -Matt H. On Jun 8, 2007, at 6:15 AM, Florent THIERY wrote: I finally found this again: http://elevate.sourceforge.net/ It's an EFL-based UI, pretty interesting concepts. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: community involvement todo?
On 6/8/07, Stefan Schmidt [EMAIL PROTECTED] wrote: Hello. So the wiki page should have the following for every single task: Description, needed skills, links to reference code... If nobody beat me, *hint*, I'll add these tasks and perhaps some more to the wiki tonight. regards Stefan Schmidt Are we really suggesting that we manually maintain one set of information about all the tasks on the wiki, and another on the bugtracker? In my experience, it's hard enough to keep devs (myself included) documenting properly, and now we want to double the workload? What it seems you're saying is that the bugtracker isn't working for you, that's cool, but every red flag I have goes up when you're suggesting we duplicate the functionality across multiple systems. Looking at the bugtracker, I can see how it would be pretty daunting to start out, but I really think it would be a better call to fix that than try to keep them synchronized. I think doing anything more than keeping a list of possible first bugs on the wiki is just asking for trouble, but what do the rest of you think we could do to make the bug reports easier to get started on? -- Jeff O|||O ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Java
As one data point, I have managed to run phoneME Feature via qvfb inside OpenMoko inside Xephyr on Ubuntu. Tying together this thread with the UI thread, phoneME is one application that would benefit greatly from having a framebuffer interface available. It is designed to render to a frame buffer. There is a QTE build, but I have not gotten that to build yet. Ian Darwin wrote: ... Or, it might be better to do our own port of phoneME to OpenMoko. I don't know which approach is better in the long run. Has anybody that has GTA01 hardware tried running this? No hardware here, nor have I tried it in arm emulation--but they do have a Linux ARM build target and if qvfb can be built for Linux ARM, it should work. - John ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GUI and Energy
A bit of reading for taking patience ;-) Gilles * Energy-Efficient Graphical User Interface Design http://www.ruf.rice.edu/~mobile/publications/eegui_accepted.pdf * Graphical User Interface Energy Characterization for Handheld Computers http://www.ruf.rice.edu/~mobile/publications/zhong03cases.pdf -- Oralux.org http://association.oralux.org ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
cellphone-sized X86 PC motherboard potential OpenMoko platform?
This is rather cool. It still needs appropriate RF modules, but since it's a standard X86 PC motherboard, porting OpenMoko to it should be pretty easy. -- Forwarded message -- Date: Thu, 7 Jun 2007 19:18:36 -0700 From: Chris Palmer [EMAIL PROTECTED] To: SVHMPC [EMAIL PROTECTED] Subject: [SVHMPC] Mobile-ITX I've been pondering slapping down my pre-order dollars on a pico-ITX board, but a co-worker just showed me that VIA has just shown off a mobile-ITX that is even half the size of the pico-ITX. Its target market is x86-based smartphones with 256MB or 512MB of RAM soldered onto the 3 x 1.8 board. Article: http://www.linuxdevices.com/news/NS2010384636.html -Chris ___ SVHMPC mailing list [EMAIL PROTECTED] http://telefono.revejo.org/mailman/listinfo/svhmpc_telefono.revejo.org ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GUI and Energy
Hypermiling with the Neo? Nice :-) On 6/8/07, Gilles Casse [EMAIL PROTECTED] wrote: * Energy-Efficient Graphical User Interface Design http://www.ruf.rice.edu/~mobile/publications/eegui_accepted.pdf From the abstract -- We demonstrate that energy-efficient GUI (E2GUI) design techniques can improve the average system energy of three benchmarks (text-viewer, personnel viewer, and calculator) by 26.9%, 45.2% and 16.4%, respectively. Average performance is simultaneously improved by 23.7%, 34.6% and 19.3%, respectively. Some general points -- * proper selection of content placement can improve GUI interaction speed * GUIs with better color schemes and contrast ratios are easier to read * a GUI should present as few choices as possible * a GUI should utilize as much screen area as possible for widgets to be hit. Widgets that are supposed to be hit sequentially should be placed near each other. The examples that the authors give and test have a few new ideas and the rest feel like common sense. One new idea for reading text was neglecting scroll bars and instead using invisible half-screen buttons for page up and page down. The top half of the screen was a page up button, and the bottom half was a page down button. The power-saving color schemes were awful. It looks like the iPhone doesn't care to sip from its battery. Joe ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
