Different hardware in the future?
Hi everyone! I'd first like to say how excited I am about the Freerunner. I am an enthusiastic linux user who likes to customize every aspect to create a workflow that just fits. So a customizable phone is what I have been looking for. A big thanks to all involved in the project, you are doing something important. It is about time that man reclaims machine. But now my question: As I understand, the software right now is not fully evolved. I would be interested in experimenting and testing, but I also would like to have a fully functional phone in the long run. Will I have one with the Freerunner once the software development reached a certain stage? Or will there be another hardware iteration then, eventually making it necessary to change the hardware? I read, it is intended for end-users but not yet quite end-user-capable. I wasn't sure whether this is a question of software only, or one of hardware too. Best regards, Ole PS: I hope this is not a double post now. But I did not receive my message on the list and could not spot it in the archive either. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Different hardware in the future?
I read, it is intended for end-users but not yet quite end-user-capable. I wasn't sure whether this is a question of software only, or one of hardware too. Software only. Freerunner is supposed to be the final design. That's exactly what I wanted to hear. :) pgpYR0VLswxvI.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Different hardware in the future?
On Mon, Jul 07, 2008 at 10:44:16PM +0200, Jay Vaughan wrote: Or will there be another hardware iteration then, eventually making it necessary to change the hardware? .. the interest in the older platforms and the newer platforms is only going to pale as newer platforms are introduced, and in fact this is needed, because the momentum towards a few hundred thousand to a million users requires frequent hardware revisions. we should count on it, as developers, in fact. That is a good point. My question was more about whether the intention of the Freerunner hardware was towards end-users. As I now understand, it is. About the software... we'll see. Today I flashed the daily of the GTK version. I'm quite optimistic now. :) pgp7pe1Cheb5x.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
On Fri, Jul 11, 2008 at 01:36:11PM +0200, Alexander Paersch wrote: Hi, I have the same problem that my Freerunner can't acquire a fix without a external GPS antenna. Just today I stumbled upon a page on the openmoko wiki: http://wiki.openmoko.org/wiki/FreeRunner_GPS_antenna_repair_SOP Anybody tried this fix and can report whether this realy fixes the issue? Greetings Alexander Yesterday I tried GPS for the first time. With gpssight and tangogps I got a fix within minutes when holding the FR out of the window. The fix remained when moving around my home. Then I installed gpsdrive and did some other things I don't remember anymore. When trying with gpsdrive I could not get a fix. With gpssight and tangogps it wasn't working either. Today I tried outside with no result. I reflashed rootfs to rollback software and only installed gpssight and tango again. No fix. It never worked again so far. So the idea of a loose contact at the antenna sounds somewhat plausible. I looked at this: http://wiki.openmoko.org/wiki/FreeRunner_GPS_antenna_repair_SOP But I don't want to open the FR right now. The connector is visible right under the battery. I can move it with my fingernail a little, really not much. Don't know if it is loose... pgpmuOBHGXp0G.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: warranty issues
On Sat, Jul 12, 2008 at 11:42:26AM +0200, simarillion wrote: Hello, can somebody tell me if I will lose my warranty when I open my Freerunner. I don't know if I am allowed to remove the seal which is on one of the two torx screws. I don't want to solder just check the connection plug of the GPS antenna. Does it depend on the distributor or the country? I'm located in germany. Greets Michael Take a look here: http://freeyourphone.de/portal_v1/viewtopic.php?f=13t=251p=2614#p2614 But it still might depend on your distributor. pgpaUOsXEbuta.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
On Sat, Jul 12, 2008 at 08:11:45PM +0800, William Kenworthy wrote: Does it make any difference to leave the gps running 15 minutes plus (probably a few multiples of 15 minutes is best) then power off for a few minutes and then back on? My freerunner isnt here yet, but my experience on a cheap bluetooth gps that I though just had occasional conniptions was actually operating according to design On the first fix (or a fix after a few weeks on the shelf powered off), it would take some time (once being over a day with poor signal) to get a fix, after which it would be fine getting a nearly instant fix on startup. Turns out the device needs information downloaded from a satellite and can take ~13 minutes to do so. And at least one article mentioned that any problem/lost/corrupted data caused it to start again at the next start point. So if you have a poor signal, something blocks it at a critical point, you can scratch that 15 minutes. As the freerunner has come straight from the factory, probably with none of this data, it will need at least 15 minutes with a good signal to get its data up to date. This data is also valid for 6 weeks which explains the erratic operation after extended periods of non-use of my bluetooth unit. Learnt a lot reading up on this :) A good thread! BillK Funny... my experience has been completely contrary to this. When I first tried GPS, it got a fix within minutes at the open window. I then installed gpsdrive and did some other stuff. I did not get a fix anymore. I undid the software changes by starting from a fresh reflash. But i never got a fix again. Today I tried outside 15min with antenna faced skywards. agpsui signal strength display did not show any activity. Don't know it made it work the very first time. pgpG3771cBXwq.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS
On Sun, Jul 13, 2008 at 03:48:14AM -0700, Russell Sears wrote: Yes, there is still hope. The current software drivers do not save any state between GPS locks, so the GPS device is needlessly re-downloading information from the satellites each time it turns on. Downloading the data seems to require a much better/more consistent signal than calculating the phone's current position. It sounds like a (partial?) fix is in the works. There were some links to scripts posted to this mailing list a few days ago, but they came with copyright restrictions that prevent redistribution... My phone sometimes takes 10 minutes to get a fix, but can track its current position from a car seat (not just near the window), and indoors in my pocket. It's good enough for in-car navigation, and for use as a speedometer, though with a couple of seconds delay added in. Also, I see a few meters of jitter when the device is not moving. After losing signal in a tunnel for 15-30 seconds, it restored its fix immediately after I left the tunnel. Not counting the time to get the initial lock, this behavior is better than what I've seen from some inexpensive name brand gps devices, suggesting the antenna is good enough, assuming saving and restoring the chip's state works. I read about this idea in the wiki and posted a comment there. Here's what I wrote. I tested the FR outside with internal antenna and did not see a single sat for 15min. With external antenna I have a TTFS of 33s. If I plug out the external after the fix is stable, it almost instantly gets lost. I still see one to three sats but get no fix. So apparently the information obtain through the external antenna is not enough to assist the internal antenna in getting a fix. Orbit and positon data should be known to the device by then? If you download this data from the internet or recalculate it locally, in what way would this be superior to what I tested? pgpIpUipwT2K1.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
On Tue, Jul 15, 2008 at 01:52:36PM +0200, Marcus Bauer wrote: who needs SD cards anyway ;-p I need it for one single reason... to store map data for gps... o_0 pgpP87gy2VgHR.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found!
On Tue, Jul 15, 2008 at 12:42:07PM +0200, thomasg wrote: Hi ppl, I write this to community, not to devel or owners because everyone should know: *sbeh*, one of the people in #neo1973-germany IRC-channel found the reason for the GPS problems. The problem only occurs if a SD card is set in. Doesn't matter if it's mounted or in use, it just has to sit in the socket. The TTFF went from no fix at all to TTFF 120 seconds indoor(!!!), and about 40 seconds outdoor. Two other people could verify this with about the same results. We'll do more tests later, but for now we surely know what's causing the problem (and it seems to be a EMC problem). First results show at the same devices, even outdoor, that there is no fix in over 400 seconds with SD card, the signal seems to be at least 10 to 20 dB worse (so bad, that most satellites don't even appear). Testresults from other people appreciated. thomasg Unfortunately I cannot confirm this for my FR. Without SD I do not see a single satellite on internal antenna. Same spot with external antenna I have TTFS 55s. pgpBTXvFNkkJl.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proper mixer settings for music playback, or hardware fixes?
On Fri, Jul 18, 2008 at 02:17:05PM +0300, Timo Jyrinki wrote: I had heard about some resistor in wrong place resulting in high-pass filter and basically making music listening unbearable. Do you still remember where you read it? I have some problems with the output of the headphone jack too. But to me it sounds mostly distorted. The initial sound quality indeed lacks all bass. However, there's a gigantic amount of alsamixer settings available - would these be documented anywhere, or has anyone been thoroughly going through those? I found that Bass Filter has a scale going from most normal (200Hz @ 8kHz) to most thinny voice (130Hz @ 48kHz), but how those settings should be interpreted? The whole range is, in order: 200Hz @ 8kHz 100Hz @ 8kHz 400Hz @ 48kHz 100Hz @ 16kHz 200Hz @ 48kHz 130Hz @ 48kHz Sounds weird to me. Additionally there is a Bass settings, initially 0. And Bass Boost, with either Linear Control or Adaptive Boost. With Bass set to 100 and Bass Boost set to Adapative Boost, together with 200Hz @ 8kHz setting, the sound is starting to resemble something of a normal, though quite far from ideal. Linear Control is probably better, Adaptive Boost seems to clip sometimes with heavy bass. It seemed to me the bass problem could be solved by mixer setting. But I could not remove the distortion in the mid to higher frequencies. pgpxbWlEmQ3ot.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Import contacts qtopia
Not sure whether I missed something. I am looking for a way to import VCF into qtopia. I could only find the discussion on this list, which, as far as I understand, covers importing VCF to the GTK addressbook only. There is also a howto on importing Blackberry contacts to qtopia. It could be helpful if one were able to convert VCF to sqlite. Any hints appreciated. Best regards, Ole pgpNCE4wRc1ti.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import contacts ASU
On Fri, Jul 18, 2008 at 06:32:50PM +, Ole Kliemann wrote: Not sure whether I missed something. I am looking for a way to import VCF into qtopia. I should clarify this. I mean the qtopia-based ASU. pgpe7B4ygRCrR.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Exposure not starting on latest ASU
I am using the daily ASU image from 20080715 having updated with opkg today. As I understand, exposure is the app to change settings like profiles, etc... But exposure does not start. It shows in the status line `Starting Exposure' but nothing happens. Isn't it implementated yet? pgpLx3aMnIT7R.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: suspend and immediate wake-up
On Sat, Jul 19, 2008 at 11:35:23AM +0200, julien cubizolles wrote: Le vendredi 18 juillet 2008 à 13:39 +0100, Al Johnson a écrit : It's getting woken by a message from the GSM. Mine does it on reregistration at variable intervals, maybe 3 times an hour. If it happens much more often it's worth reporting. I've not properly measured how frequently it does it but for me it's very often less than 5 seconds after it goes to suspend mode... Is there a message in dmesg that indicates the waking is indeed due to reregistration ? I have a log saved I could check. I can confirm this. I haven't run exhaustive tests, but almost whenever I tried the FR woke up just seconds later. That was using GTK branch. I can't test this further right now as I moved to ASU. pgpTemA6U1JY3.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proper mixer settings for music playback, or hardware fixes?
On Fri, Jul 18, 2008 at 02:50:18PM +0100, Al Johnson wrote: On Friday 18 July 2008, Ole Kliemann wrote: On Fri, Jul 18, 2008 at 02:17:05PM +0300, Timo Jyrinki wrote: I had heard about some resistor in wrong place resulting in high-pass filter and basically making music listening unbearable. Do you still remember where you read it? I have some problems with the output of the headphone jack too. But to me it sounds mostly distorted. http://lists.openmoko.org/pipermail/community/2008-June/019938.html http://lists.openmoko.org/pipermail/openmoko-kernel/2008-March/001994.html I noticed the high-pass, but came to acceptable results using alsamixer's bass-boost options. My main concern is with the distortion in the mids to highs. As far as I understand, the above mentioned postings only cover the high-pass problem. But I certainly don't understand all the technical stuff. Does anyone else experience distortion? pgpneYSgTyy4B.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: openmoko-qtopia Error Loading module
On Sun, Jul 20, 2008 at 04:53:53AM -0600, michael irons wrote: I tried flashing my freerunner with the image openmoko-qtopia-x11-image-om-gta02.jffs2 from 07-20-2008 and After booting it got to what looks like a desktop (with nothing on it) except for the test or Loading Module. I assume the is error, but it is off the left hand side of the screen. I tried rolling back to the 7-18 openmoko-qtopia image and it works fine, except I of coures up grade and upon rebooting I get the same error. I can confirm this. So something is up with the 7-20 jffs2 image I can still ssh into the freerunner although there is an error. DMESG shows near the end: Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 ASoC version 0.13.1 wm8753: WM8753 Audio Codec 0.16 asoc: WM8753 HiFi - s3c24xx-i2s mapping ok asoc: WM8753 Voice - Bluetooth mapping ok pcf50633 0-0073: PCF_TIME: 20.06.08 04:23:59 pcf50633 0-0073: RTC_TIME: 20.6.108 4:23:59 pcf50633 0-0073: RTC_TIME: 20.6.108 4:24:7 pcf50633 0-0073: PCF_TIME: 20.06.08 04:24:07 modem wakeup interrupt and then stops Any ideas? I guess it's one of the enlightenment modules. But I'm not familiar with anything of this, so I'm just rolling back and wait for the pros to tackle it. ;) It would still be interesting to know, where logs are stored. /var/log is pretty empty. Where can one find logs to X, enlightenment, ... ? Ole pgpK8nNVSLWit.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: headset with qtopia
On Mon, Jul 21, 2008 at 05:34:47AM +, thewtex wrote: Has anyone got the headset that comes with the Freerunner group purchase working with the qtopia.net images? There seems to be a small amount of sound coming out somewhere. And speakerphone goes wacky. Maybe alsamixer settings? I am using this version: qtopia-4.3.2-gta02-flash-07172049.tgz When I plug in the headset while playing something with mediaplayer, I only get sound on one channel on the headset, speaker still sounds normal. There is a alsamixer control `Amp Spk'; if you turn it off, speaker goes off and headset has both channels. Now question would be, how to make qtopia to recognize the headset has been plugged in and change mixer settings accordingly. The .state files in /usr/share/openmoko/scenarios are in place but don't seem to be used. Ole pgpZR83fArJD1.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Proper mixer settings for music playback, or hardware fixes?
On Mon, Jul 21, 2008 at 12:31:44PM -0400, Dylan Reilly wrote: On Fri, Jul 18, 2008 at 02:50:18PM +0100, Al Johnson wrote: I noticed the high-pass, but came to acceptable results using alsamixer's bass-boost options. My main concern is with the distortion in the mids to highs. As far as I understand, the above mentioned postings only cover the high-pass problem. But I certainly don't understand all the technical stuff. Does anyone else experience distortion? I have also noticed some heinous distortion in the mid to high range through the media player in the latest 2007.02 builds. However, it is not present under Qtopia. Just today I tried Qtopia. Did not do much listening, but I think I can confirm there were no distortions with Qtopia. pgpyaxlG2T0zy.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FR - ASU image - keyboard with wrong characters
On Wed, Jul 23, 2008 at 12:12:18PM +0200, Torfinn Ingolfsen wrote: More info. On Wed, Jul 23, 2008 at 12:04 PM, Torfinn Ingolfsen [EMAIL PROTECTED] wrote: Anyway, today I did a 'opkg update' followed by a 'opkg upgrade'. The upgrade went fine, and I rebooted my FR. I repeated 'opkg update' and 'opkg upgrade' The upgrade part produced some errors, but I don't know if they are important or not: [EMAIL PROTECTED]:~# opkg upgrade Upgrading e-wm on root from 0.16.999.042+cvs20080710-r10 to 0.16.999.042+cvs20080722-r10... Downloading http://buildhost.openmoko.org/daily-feed/armv4t/e-wm_0.16.999.042+cvs20080722-r10_armv4t.ipk Installing efreet (1:0.5.0.043+cvs20080722-r0) to root... Downloading http://buildhost.openmoko.org/daily-feed/armv4t/efreet_0.5.0.043+cvs20080722-r0_armv4t.ipk Upgrading illume on root from 0.0+svnr133-r6 to 0.0+svnr152-r6... Downloading http://buildhost.openmoko.org/daily-feed/armv4t/illume_0.0+svnr152-r6_armv4t.ipk Installing efreet (1:0.5.0.043+cvs20080722-r0) to root... Downloading http://buildhost.openmoko.org/daily-feed/armv4t/efreet_0.5.0.043+cvs20080722-r0_armv4t.ipk Upgrading libefreet-mime0 on root from 1:0.5.0.043+cvs20080710-r0 to 1:0.5.0.043+cvs20080722-r0... Downloading http://buildhost.openmoko.org/daily-feed/armv4t/libefreet-mime0_0.5.0.043+cvs20080722-r0_armv4t.ipk Installing efreet (1:0.5.0.043+cvs20080722-r0) to root... Downloading http://buildhost.openmoko.org/daily-feed/armv4t/efreet_0.5.0.043+cvs20080722-r0_armv4t.ipk Collected errors: * Package efreet wants to install file /usr/lib/libefreet.so.0.5.0 But that file is already provided by package * libefreet0 * Package efreet wants to install file /usr/lib/libefreet.so.0 But that file is already provided by package * libefreet0 * Package efreet wants to install file /usr/lib/libefreet.so.0.5.0 But that file is already provided by package * libefreet0 * Package efreet wants to install file /usr/lib/libefreet.so.0 But that file is already provided by package * libefreet0 * Package efreet wants to install file /usr/lib/libefreet.so.0.5.0 But that file is already provided by package * libefreet0 * Package efreet wants to install file /usr/lib/libefreet.so.0 But that file is already provided by package * libefreet0 You can work around this by running `opkg upgrade -force-overwrite'. This file seems to have moved from one package to another. The error above results in certain packages not to be installed (especially illume). Your problems probably result from some packages being a newer version now and some not. But besides this, for me the latestes ASU version has no keyboard at all. Already posted this on the support list. So as long as yours is still usable, I would not upgrade further until this is solved. Unless you want to increase the pool of testing data. ;) Ole pgpFqEiUawSIt.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Import contacts qtopia
On Mon, Jul 21, 2008 at 07:46:42PM +0200, Holger Freyther wrote: On Friday 18 July 2008 20:32:50 Ole Kliemann wrote: Not sure whether I missed something. I am looking for a way to import VCF into qtopia. I could only find the discussion on this list, which, as far as I understand, covers importing VCF to the GTK addressbook only. There is also a howto on importing Blackberry contacts to qtopia. It could be helpful if one were able to convert VCF to sqlite. Any hints appreciated. Unofficial answer (as this is not tested by us... it is the code from trolltech as is so is likely to have issues) 1.) copy the the file vcf to the device 2.) /opt/Qtopia/bin/addressbook /path/to/vcf-file (will get deleted) 3.) GUI makes some stuff... asks you to import.. 4.) You might need to restart afterwards This works fine. Thanks! :) Ole pgprDVwWktI4D.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[qtopia] german dictionary for predictive keyboard
The predictive keyboard using the german dictionary does not accept `ss' for sharp S `ue' for u-umlaut `ae' for a-umlaut `oe' for o-umlaut When writing the german word `weiß' with a sharp S at the end, `weiss' will not be accepted. You will get `weise', etc... because `weiss' is actually no german word at all. But to reach for the sharp S, you have to move two keyboards further. Same problem for words with umlauts. So good would be if either the system would recognize `ss' as correct wherever a sharp S is in a word (same for ue, ...). In an SMS most people won't complain about lousy orthography. ;) Or if the system would understand that `ss' can mean sharp S and writes the word properly. Ole pgpfFC2g9W7xr.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtopia] german dictionary for predictive keyboard
On Thu, Jul 24, 2008 at 03:49:14PM +0200, arne anka wrote: `weiss' is actually no german word at all. how's that? it's both a verb (from wissen) and and adjective/adverb (color)! and it's correctly spelled (as far as correctly is a category because only officials are compeled to use the afficial orthography). instead of simply killing that stupid ligature wrongly called sharp s (and even more wrong sz in german) the new german orthography included a really stupid rule when to write ss and when ß .. so nobody is really able to figure out what why. anyway, i wander off ... I don't care for normative debates on orthography. I simply stated that `weiss' is no german word as my assumed explanation of why it is not recognized. My problem is not that my `weiß' isn't spelled correctly. The problem is, with prediction not recognizing `weiss', this input method is barely usable right now. the prediction should be based on simple ss==ß Yes, just like i wrote. Ole pgpHKceb9drnq.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtopia] german dictionary for predictive keyboard
On Thu, Jul 24, 2008 at 02:40:49PM +, Ole Kliemann wrote: So good would be if either the system would recognize `ss' as correct wherever a sharp S is in a word (same for ue, ...). It can be done this way: I took the qtopia sources and compile them. A tool named `qdawggen' will be build in the process. The word lists qtopia uses are stored as DAWGs in .dawg files. qdawggen creates these .dawg files form plaintext word lists. Unfortunately the source word list for german was not included in the qtopia source snapshot. So I got igerman98 [1] and created a word list. A simple sed script translated every ö, ä, ü, ß into oe, ae, ue, ss. qdawggen then built a DAWG from it. [1] http://www.j3e.de/ispell/igerman98/dict/igerman98-20071211.tar.bz2 Ole pgpAHwHEZa6VB.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: power management/wakeups with qtopia vs 2007.2
On Sat, Jul 26, 2008 at 04:54:16PM +0200, arne anka wrote: yesterday in installed qtopia to an sd card to check it out, tried the phone (worked) and went to bed. the 2007.2 uses to resume frequently w/o any apparent reason -- as far as i can tell the qtopia does not. yet, it responses to incoming calls and resumes. I can confirm this. Still there are issues too. Sometimes after long suspend the display is all white. Sometimes the picture comes back after ~20secs, sometimes not. And if suspended for long, SMS don't wake it up. But in fact Qtopia makes the FR very well usable even on a long day without charger. A night on suspend drains maybe 20% of the battery. Ole pgpIrubkrLuOC.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Qtopia: GPRS
I'm trying to send an MMS with Qtopia. I set up GPRS and WAP through the GUI, but it did not work; the network interface failed to start when sending. A look into the log shows this: Jul 27 09:57:37 om-gta02 user.notice Qtopia: Network : Creating network session for qtmail on /home/root/Applications/Network/config/dialupGPRS0.conf Jul 27 09:57:37 om-gta02 user.notice Qtopia: Network : starting pppd (non-demand) : /usr/sbin/pppd nodetach debug call dialup1217032395 password simyo logfile /tmp/qtopia-0/qpe-pppd-log-dialup1217032395 connect /opt/Qtopia/bin/qtopia-pppd-internal active /home/root/Appl Jul 27 09:57:37 om-gta02 user.notice Qtopia: QServiceDeviceBase::run: could not find a pseudo-tty Jul 27 09:57:37 om-gta02 user.notice Qtopia: Network : QModemDataCall::dial - could not start pppd Now question is on the second line: is the log message cut off or is the command issued like this. In the latter case the reason for failure is obvious. In the first case the log would need fixing before further debugging can take place. Hard to find the problem if it is unclear what actually is done. Ole pgpgTrhmMpJsS.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia: GPRS
On Sun, Jul 27, 2008 at 12:13:05PM +, Ole Kliemann wrote:
I'm trying to send an MMS with Qtopia. I set up GPRS and WAP through the
GUI, but it did not work; the network interface failed to start when
sending. A look into the log shows this:
Jul 27 09:57:37 om-gta02 user.notice Qtopia: Network : Creating network
session for qtmail on
/home/root/Applications/Network/config/dialupGPRS0.conf
Jul 27 09:57:37 om-gta02 user.notice Qtopia: Network : starting pppd
(non-demand) : /usr/sbin/pppd nodetach debug call dialup1217032395 password
simyo logfile /tmp/qtopia-0/qpe-pppd-log-dialup1217032395 connect
/opt/Qtopia/bin/qtopia-pppd-internal active /home/root/Appl
Jul 27 09:57:37 om-gta02 user.notice Qtopia: QServiceDeviceBase::run: could
not find a pseudo-tty
Jul 27 09:57:37 om-gta02 user.notice Qtopia: Network : QModemDataCall::dial -
could not start pppd
Qtopia launches pppd without a device parameter and redirects the modem
device through a pseudo-tty to the stdin/out of the pppd process. Qtopia
assumes BSD-style /dev/pty*, but on my FR I only got /dev/pts.
So I patched it for /dev/pts. Not sure how correct I have done this.
Anyway it's not working yet:
Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : starting pppd
(non-demand) : /usr/sbin/pppd nodetach debug call dialup1217032395 password
simyo logfile /tmp/qtopia-0/qpe-pppd-log-dialup1217032395 connect
/opt/Qtopia/bin/qtopia-pppd-internal active /home/root/Appl
Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : Call state: 2
Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : Data state: DataCall
started dataInactive
Jul 28 16:29:29 om-gta02 user.notice Qtopia: /usr/sbin/pppd: unrecognized
option '
Jul 28 16:29:29 om-gta02 user.notice Qtopia: '
Jul 28 18:29:29 om-gta02 daemon.err pppd[2905]: unrecognized option ' '
we'll see ...
Ole
--- src/libraries/qtopiacomm/serial/qserialiodevice.cpp_orig2008-07-28
17:12:31.0 +0200
+++ src/libraries/qtopiacomm/serial/qserialiodevice.cpp 2008-07-28
18:15:29.0 +0200
@@ -251,25 +251,20 @@
// We would like to use openpty, but it isn't in libc on some systems.
static bool createPseudoTty(int masterFd, int slaveFd, char *ttyname)
{
-static char const firstChars[] = pqrstuvwxyzabcde;
-static char const secondChars[] = 0123456789abcdef;
-const char *first;
-const char *second;
-char ptyname[16];
-for ( first = firstChars; *first != '\0'; ++first ) {
-for ( second = secondChars; *second != '\0'; ++second ) {
-sprintf( ptyname, /dev/pty%c%c, *first, *second );
-sprintf( ttyname, /dev/tty%c%c, *first, *second );
-if ( ( masterFd = ::open( ptyname, O_RDWR | O_NONBLOCK, 0 ) ) = 0
) {
-if ( ( slaveFd = ::open( ttyname, O_RDWR | O_NOCTTY, 0 ) )
-= 0 ) {
-return true;
-}
-::close( masterFd );
-}
-}
+masterFd=::open(/dev/ptmx, O_RDWR | O_NONBLOCK);
+if (masterFd0)
+return false;
+if (::grantpt(masterFd)0)
+return false;
+if (::unlockpt(masterFd)0)
+return false;
+ttyname=::ptsname(masterFd);
+slaveFd=::open(ttyname, O_RDWR | O_NOCTTY);
+if (slaveFd0) {
+::close(masterFd);
+return false;
}
-return false;
+return true;
}
#endif // USE_POSIX_SYSCALLS
pgpe7Oeg2Labd.pgp
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia: GPRS
On Mon, Jul 28, 2008 at 06:32:18PM +, Ole Kliemann wrote: Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : starting pppd (non-demand) : /usr/sbin/pppd nodetach debug call dialup1217032395 password simyo logfile /tmp/qtopia-0/qpe-pppd-log-dialup1217032395 connect /opt/Qtopia/bin/qtopia-pppd-internal active /home/root/Appl Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : Call state: 2 Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : Data state: DataCall started dataInactive Jul 28 16:29:29 om-gta02 user.notice Qtopia: /usr/sbin/pppd: unrecognized option ' Jul 28 16:29:29 om-gta02 user.notice Qtopia: ' Jul 28 18:29:29 om-gta02 daemon.err pppd[2905]: unrecognized option ' ' Problem is that Qtopia launches pppd with garbage in the first arg and without properly quoting. I made a blunt workaround using a shell script. Still that wasn't all... not yet sure what the next problem is. Ole #!/bin/sh shift args= while [ $# -gt 0 ] ; do if [ $1 == disconnect ] ; then args=$args' $1 ' else args=$args $1 fi if [ $1 == connect ] ; then args=$args ' fi shift done /usr/sbin/_pppd $@ pgpVAEK6Any9T.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia: GPRS
On Mon, Jul 28, 2008 at 07:57:01PM +, Ole Kliemann wrote: On Mon, Jul 28, 2008 at 06:32:18PM +, Ole Kliemann wrote: Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : starting pppd (non-demand) : /usr/sbin/pppd nodetach debug call dialup1217032395 password simyo logfile /tmp/qtopia-0/qpe-pppd-log-dialup1217032395 connect /opt/Qtopia/bin/qtopia-pppd-internal active /home/root/Appl Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : Call state: 2 Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : Data state: DataCall started dataInactive Jul 28 16:29:29 om-gta02 user.notice Qtopia: /usr/sbin/pppd: unrecognized option ' Jul 28 16:29:29 om-gta02 user.notice Qtopia: ' Jul 28 18:29:29 om-gta02 daemon.err pppd[2905]: unrecognized option ' ' Problem is that Qtopia launches pppd with garbage in the first arg and without properly quoting. I made a blunt workaround using a shell script. Still that wasn't all... not yet sure what the next problem is. Ok. The script was completely broken. I didn't notice. :/ GPRS was really working one time now. But after disconnecting again things are broken: Jul 28 21:37:39 om-gta02 user.notice Qtopia: AtChat : F : Bn×ÿÿÚ)ðy~~ÿ^C!E4¶@:^FËWÔ^Wa Jul 28 21:37:39 om-gta02 user.notice Qtopia: AtChat : F : }^º^SظÔ5b^E+ Jul 28 21:37:39 om-gta02 user.notice Qtopia: AtChat : F : *^Q1²^A^A^H Sure doesn't look healthy... There is also one pts still open, seems like things don't get cleaned up properly. #!/bin/bash shift args= while [ $# -gt 0 ] ; do if [ $1 == disconnect ] ; then args=$args\ $1 \ else args=$args $1 fi if [ $1 == connect ] ; then args=$args \ fi shift done args=$args\ eval /usr/sbin/_pppd $args pgpJOh29FjbBE.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia: GPRS
On Tue, Jul 29, 2008 at 12:39:32PM +1000, Lorn Potter wrote: Qtopia runs the /opt/Qtopia/bin/ppp-network script. Ok, now I know where to look. I have fixed a few things I could see, but haven't yet tested: //depot/qtopia/main/devices/ficgta01/src/devtools/scripts/ppp-network#2 (xtext) 24c24 RESOLVCONF=/mnt/user/etc/resolv.conf --- RESOLVCONF=/etc/resolv.conf 68c68,70 mkdir /etc/ppp/peers --- if [ ! -e /etc/ppp/peers ]; then mkdir /etc/ppp/peers fi 100c102 $PPPD $* --- $PPPD $* Just from looking at it: it must be $PPPD $@ http://osr507doc.sco.com/en/OSUserG/_Passing_to_shell_script.html $* will not fix it, the concat of all arguments will be passed as the first and only. Had to look up these things myself again. ;) Ole pgpG9wsRQYf22.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia: GPRS
On Tue, Jul 29, 2008 at 12:24:50PM +1000, Lorn Potter wrote:
Ole Kliemann wrote:
On Sun, Jul 27, 2008 at 12:13:05PM +, Ole Kliemann wrote:
I'm trying to send an MMS with Qtopia. I set up GPRS and WAP through the
GUI, but it did not work; the network interface failed to start when
sending. A look into the log shows this:
Jul 27 09:57:37 om-gta02 user.notice Qtopia: Network : Creating network
session for qtmail on
/home/root/Applications/Network/config/dialupGPRS0.conf
Jul 27 09:57:37 om-gta02 user.notice Qtopia: Network : starting pppd
(non-demand) : /usr/sbin/pppd nodetach debug call dialup1217032395
password simyo logfile /tmp/qtopia-0/qpe-pppd-log-dialup1217032395 connect
/opt/Qtopia/bin/qtopia-pppd-internal active /home/root/Appl
Jul 27 09:57:37 om-gta02 user.notice Qtopia: QServiceDeviceBase::run:
could not find a pseudo-tty
Jul 27 09:57:37 om-gta02 user.notice Qtopia: Network :
QModemDataCall::dial - could not start pppd
Qtopia launches pppd without a device parameter and redirects the modem
device through a pseudo-tty to the stdin/out of the pppd process. Qtopia
assumes BSD-style /dev/pty*, but on my FR I only got /dev/pts.
So I patched it for /dev/pts. Not sure how correct I have done this.
There is similar code in 4.4, I just added it to 4.3
Thanks
I missed something with this patch. The ttyname is used later and was
not returned by createPseudoTty. That explains the garbage in the first
arg when launching pppd.
Funny thing is, a connection worked, although the device was not passed
to pppd. But I really don't understand yet how this whole thing works.
--- src/libraries/qtopiacomm/serial/qserialiodevice.cpp_orig2008-07-29
14:27:05.0 +0200
+++ src/libraries/qtopiacomm/serial/qserialiodevice.cpp 2008-07-29
14:29:21.0 +0200
@@ -249,27 +249,22 @@
#ifdef USE_POSIX_SYSCALLS
// We would like to use openpty, but it isn't in libc on some systems.
-static bool createPseudoTty(int masterFd, int slaveFd, char *ttyname)
+static bool createPseudoTty(int masterFd, int slaveFd, char **ttyname)
{
-static char const firstChars[] = pqrstuvwxyzabcde;
-static char const secondChars[] = 0123456789abcdef;
-const char *first;
-const char *second;
-char ptyname[16];
-for ( first = firstChars; *first != '\0'; ++first ) {
-for ( second = secondChars; *second != '\0'; ++second ) {
-sprintf( ptyname, /dev/pty%c%c, *first, *second );
-sprintf( ttyname, /dev/tty%c%c, *first, *second );
-if ( ( masterFd = ::open( ptyname, O_RDWR | O_NONBLOCK, 0 ) ) = 0
) {
-if ( ( slaveFd = ::open( ttyname, O_RDWR | O_NOCTTY, 0 ) )
-= 0 ) {
-return true;
-}
-::close( masterFd );
-}
-}
+masterFd=::open(/dev/ptmx, O_RDWR | O_NONBLOCK);
+if (masterFd0)
+return false;
+if (::grantpt(masterFd)0)
+return false;
+if (::unlockpt(masterFd)0)
+return false;
+*ttyname=::ptsname(masterFd);
+slaveFd=::open(*ttyname, O_RDWR | O_NOCTTY);
+if (slaveFd0) {
+::close(masterFd);
+return false;
}
-return false;
+return true;
}
#endif // USE_POSIX_SYSCALLS
@@ -304,8 +299,8 @@
// Create a pseudo-tty to manage communication with the process.
int masterFd = -1;
int slaveFd = -1;
-char slaveName[BUFSIZ];
-if ( !createPseudoTty( masterFd, slaveFd, slaveName ) ) {
+char *slaveName;
+if ( !createPseudoTty( masterFd, slaveFd, slaveName ) ) {
qWarning( QServiceDeviceBase::run: could not find a pseudo-tty );
return 0;
}
pgp8Q2HxwGBDj.pgp
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia: GPRS
On Tue, Jul 29, 2008 at 12:39:32PM +1000, Lorn Potter wrote: Ole Kliemann wrote: On Mon, Jul 28, 2008 at 07:57:01PM +, Ole Kliemann wrote: On Mon, Jul 28, 2008 at 06:32:18PM +, Ole Kliemann wrote: Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : starting pppd (non-demand) : /usr/sbin/pppd nodetach debug call dialup1217032395 password simyo logfile /tmp/qtopia-0/qpe-pppd-log-dialup1217032395 connect /opt/Qtopia/bin/qtopia-pppd-internal active /home/root/Appl Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : Call state: 2 Jul 28 16:29:29 om-gta02 user.notice Qtopia: Network : Data state: DataCall started dataInactive Jul 28 16:29:29 om-gta02 user.notice Qtopia: /usr/sbin/pppd: unrecognized option ' Jul 28 16:29:29 om-gta02 user.notice Qtopia: ' Jul 28 18:29:29 om-gta02 daemon.err pppd[2905]: unrecognized option ' ' Problem is that Qtopia launches pppd with garbage in the first arg and without properly quoting. I made a blunt workaround using a shell script. Still that wasn't all... not yet sure what the next problem is. Ok. The script was completely broken. I didn't notice. :/ GPRS was really working one time now. But after disconnecting again things are broken: Jul 28 21:37:39 om-gta02 user.notice Qtopia: AtChat : F : Bn×ÿÿÚ)ðy~~ÿ^C!E4¶@:^FËWÔ^Wa Jul 28 21:37:39 om-gta02 user.notice Qtopia: AtChat : F : }^º^SظÔ5b^E+ Jul 28 21:37:39 om-gta02 user.notice Qtopia: AtChat : F : *^Q1²^A^A^H Sure doesn't look healthy... There is also one pts still open, seems like things don't get cleaned up properly. Qtopia runs the /opt/Qtopia/bin/ppp-network script. But only for setting DNS and default gateway, at least on my system. pppd is not run from ppp-network. And setting DNS is not done correctly. The script is supposed to be called: ppp-network install dns NAMESERVER1 NAMESERVER2 It then writes NAMESERVER1 and NAMESERVER2 into /etc/ppp/resolv.conf and links that file to /etc/resolv.conf. But ppp-network is called only with `install dns' not specifying any servers thus /etc/ppp/resolv.conf is not even created. pppd itself writes nameservers into /var/run/ppp/resolv.conf. So a workaround for this is to link /var/run/ppp/resolv.conf to /etc/ppp/resolv.conf. This is the one problem; not so big. Big problem is that after first connection with GPRS, I cannot make any phone calls anymore. Restarting qpe fixes this. After some more connections with GPRS, GPRS itself cannot connect anymore, phone calls not working. Restarting qpe does not help, UI shows `No Network'. Modem seems to be dead. Only reboot helps. Maybe I should wait for 4.4 ... ;) Ole pgp53usPrUki0.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia: GPRS (fwd)
On Wed, Jul 30, 2008 at 06:38:15AM +1000, lpotter wrote:
The patch I backported to 4.3 in Qtopia is this:
// try opening Unix98 pseudo tty
if ((masterFd = ::open(/dev/ptmx, O_RDWR | O_NONBLOCK, 0)) = 0) {
if (grantpt(masterFd) == 0) {
if (unlockpt(masterFd) == 0) {
ptsname_r(masterFd, ttyname, BUFSIZ);
if ((slaveFd = ::open(ttyname, O_RDWR | O_NOCTTY, 0)) = 0)
return true;
}
}
::close(masterFd);
}
But it's not in the 20080730 snapshot. Depends on the function
prototype. If third argument is reference to pointer to char. Otherwise
ttyname is not available outside createPseudoTty() although it is used
later to be passed to pppd.
Anyway, so many things regarding GPRS beyond this are not working
properly. Would be interesting to know what has been done in 4.4. ;)
It's just no use looking into this in 4.3 now, when things might have
been corrected already in 4.4.
Ole
pgpnf9k5UWV3I.pgp
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Suspend / Resume
On Wed, Jul 30, 2008 at 04:42:52PM -0400, Matthew Lane wrote: When suspending, GSM calls DO wake the phone up, but SMS does not? Also, when I resume from a suspend, I cannot send/receive SMS? Qtopia also seems to have this problem..once I suspend I cannot receive SMS, and I'm not even sure if sending works either. Is this common? On Qtopia SMS do not wake up my phone. I haven't noticed that SMS is broken completely after resume, but SMS that were send to me during suspend I often received hours later. That was probably then, when I rebooted the device. So I guess I can confirm SMS is broken after resume. pgpoCR2Ye8Eik.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner GPS not working
On Fri, Aug 01, 2008 at 10:23:30AM +0200, Jan Keymeulen wrote: Hi, I'm unable to get a GPS fix on my Freerunner, S/N 8A8602882. I'm using a Linux om-gta02 2.6.24 #1 PREEMPT Wed Jul 30 11:56:48 CEST 2008 kernel with the stock 2007.2 that came with the Freerunner. After trying agpsui as descibed in the wiki for about an hour - without any satellites seen and trying the instructions given in http://lists.openmoko.org/pipermail/support/2008-July/000899.html I still don't get squad. Of course, tangogps and the lot don't work either. For those who understand NMEA, I'm seeing the following sequence in a apparently endless loop: $GPRMC,,V,,N*53 $GPVTG,N*30 $GPGGA,,0,00,99.99,,*48 $GPGSA,A,1,99.99,99.99,99.99*30 $GPGSV,1,1,00*79 $GPGLL,,V,N*64 $GPZDA,00,00*48 For as far I can see, the internal antenna connector is seated well. I have the same problems. Tried with SD removed but makes no difference. Sometimes when I get a fix with external antenna and unplug it then, the internal is able to hold the fix; but not always. Internal never gets a fix on its own. I had the FR open once. I think the internal connector sits fast. I haven't tried to unplug and replug it because the cable that runs from the plug to the antenna scared me. At the point where it is soldered to the antenna it is so thin and looked so fragile and worn off, I was afraid it would fall off any second. But I am not experienced enough to say whether this is normal. pgp640RUWnDkB.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: /qtopia/ how to upgrade without reflashing?
On Fri, Aug 01, 2008 at 03:32:52PM -0400, Yaroslav Halchenko wrote: Is there an easy way to upgrade qtopia installation without reflashing whole rootfs? since /opt/Qtopia is not a part of any package according to opkg search, thus is not 'opkg upgrade'able. 1 possibility I see is to keep /home/root on a flash and manually mount it to preserve at least personal settings and aphone book, but that would require manual remounting after flashing. May be there is a better way?? You can upgrade Qtopia like this: shutdown Qtopia (/etc/init.d/qpe stop) remove /opt/Qtopia copy new Qtopia to /opt/Qtopia (via scp) That's pretty straight forward. Tricky part is where to get new Qtopia as tarball or whatever to copy it. One possibility is to compile yourself. It's not difficult and you are always up-to-date. The precompiled images are not so often updated. Get the Qtopia toolchain for FR [1]. Unpacking it to / will install into /opt/toolchains/arm920t-eabi/ Get the latest snapshot [2]. Create a build dir and run configure -device ficgta01 then build it. Ole [1] http://www.qtopia.net/modules/mydownloads/singlefile.php?lid=38 [2] ftp://ftp.trolltech.com/qtopia/snapshots/ pgphJj3W7zDIL.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: /qtopia/ hard to Answer
On Fri, Aug 01, 2008 at 03:29:14PM -0400, Yaroslav Halchenko wrote: Although the rest seems to be working quite fine, and even battery life is tolerable, with pure qtopia I am experiencing 1 unpleasant effect (which while writing this email unrolled a bit ;-) I am running: [EMAIL PROTECTED]:~# cat /etc/version 200807100425 [EMAIL PROTECTED]:~# cat /proc/version Linux version 2.6.24 ([EMAIL PROTECTED]) (gcc version 4.1.2) #71 PREEMPT Wed Jul 16 13:45:35 CDT 2008 not sure where to look for qtopia image specific version, but I believe I burnt images from the latest tarball qtopia-4.3.2-gta02-flash-07221045.tgz NB you might recall my earlier reports about kernel oopses Whenever I receive a call, screen changes to nice choices to accept or not the call, but there is 2-4 seconds delay after I press Answer and anything actually happens. I experienced that as well. Maybe more like 2 secs on my device. On my first reboot I got white screen and phone was stalled... had to keep power button pressed for quite long before it shut down on the next boot it got into QT, showed No network and didn't react to any buttons on the screen (Although they blinked while being pressed, nothing happened. Unlock item in the bottom left didn't react to presses). I had this too one or two times. Could be that it improved with newer versions but not sure. I'm currently using latest kernel through opkg upgrade and Qtopia snapshot 20080801 [1]. Then it suspended and when I resumed it back -- again white screen. in a few secs suspended again and then didn't react to any buttons (ie pow, aux) -- I had to take battery out to power it to shut it down to power it up again. Could be that you suffer from the `white screen of death' [2]. I sometimes have it when resuming from long suspend. Ole [1] ftp://ftp.trolltech.com/qtopia/snapshots/qtopia-opensource-src-4.3.2-snapshot-20080801.tar.gz [2] http://lists.openmoko.org/pipermail/openmoko-kernel/2008-July/004098.html pgpJcCTXeepkA.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: /qtopia/ how to upgrade without reflashing?
On Fri, Aug 01, 2008 at 04:52:04PM -0400, Yaroslav Halchenko wrote: indeed I could just extract opt/Qtopia from a fresh .jffs image whenever new one becomes available, BUT that would not give me easy way to upgrade the rest of the packages (non-qpe) to the same state as in that image... I am not sure how much that is important though... (events/avahi/mediaserver or whatever else qpe relies on). Ah, good point. I just update the rest through opkg upgrade and don't care for consitency between non-qpe and qtopia. So far things only got better from update to update. ;-) Ole pgpd4nvOPPXr0.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: /qtopia/ how to upgrade without reflashing?
On Fri, Aug 01, 2008 at 05:11:31PM -0400, Yaroslav Halchenko wrote: On Fri, 01 Aug 2008, Ole Kliemann wrote: Create a build dir and run configure -device ficgta01 then build it. just want to confirm -- for freerunner should it remain ficgta01 (I don't see any other suitable under devices but usually there are 2 separate images for gta01 and 2 on qtopia's download page) I build with ficgta01 because - as you said it - there not much choice. Worked ok so far. pgpTga72G8Cvz.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: /qtopia/ how to upgrade without reflashing?
On Sun, Aug 03, 2008 at 01:01:19PM -0700, Jim Morris wrote: Did you have to set any special Environment variables or paths to get this to work? I have installed the toolchain on a Ubuntu Linux system, and it gets quite a long way through, but end up getting this error eventually... ../../include/QtCore/../../../../../qtopia-opensource-src-4.3.2-snapshot-20080801/qtopiacore/qt/src/corelib/tools/qlist.h:355: error: no matching function for call to ‘operator new(unsigned int, QListbool (*)(void**)::Node*)’ built-in:0: note: candidates are: void* operator new(unsigned int) Is there by any chance an error further above about not finding the include `new'? Looks like the placement new operator is not available. This can be from not finding g++ includes. pgpQy3Rrowl6A.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Usable Keyboard
On Sat, Aug 09, 2008 at 08:08:13PM +1000, Carsten Haitzler wrote: please check the mail list archives about terminal and asu, and check the keyboard in FSO. the keyboard in ASU is the qtopia keyboard. for better or worse. illume has it's own internal keyboard that does give you all these things, but it was decided that this was not what was wanted. i've participated in long threads on the topic of the keyboard in ASU. :) you're repeating what a lot of people keep saying. as i've said before - i intend to fork and do my own ui (as opposed to the ASU you see) that actually has a lot of the things everyone is clamouring for (more configuration, different/better/more configurable keyboard, different launcher setup etc.). a lot of these features already lurk under the hood in the code and are simply configured to be off and/or inaccessible. unfortunately - this is going to have to sit on a backburner and await whatever spare time i find for it as i have resigned from openmoko (effective end of august). i'll do what i can over time, but my priorities will be to keep myself fed and housed :) I didn't have time to follow this discussion on the keyboard in ASU. But as I wrote in the other list: a customizable keyboard is the only right keyboard - no matter how one argues. ;) I'm looking forward to see your own work on this. Ole pgpBLwyekXuAi.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Any progress on the white screen of death problem?
On Tue, Aug 12, 2008 at 07:43:11PM +0200, Rorschach wrote: I installed: http://buildhost.openmoko.org/daily/freerunner/200808/20080812/uImage-2.6.24+git33+88bf43840b9df0eb0a077a1394eb564be80a412e-r2-om-gta02.bin First good news: * the battery-indicator is now fully working, showing if charging/discharging and the degree of fullness of the battery Now the bad news: * WSOD is not fixed with this, I'm filing a bug tomorrow about this issue although it longer known on the ML I think, there already is a bug filed. http://docs.openmoko.org/trac/ticket/1621 Ole pgpIGHUr06ypk.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Official update feeds testing on downloads.openmoko.org
On Wed, Aug 20, 2008 at 03:23:34PM +0200, Kevin Zuber wrote: Hi, I've just noticed on a new testing repository on downloads.openmoko.org [1]. Are that the official update feeds for ASU or another distribution? Is the merge of the two branches finished? Should I use this repo instead of the zecke repo now? Thanks for answers. Kev [1] http://downloads.openmoko.org/repository/testing/ It's there for a few days already. Didn't break anything for me. But it does not seem to include a new kernel yet. I was hoping to find a remedy for WSOD. Ole pgpYeknvPK9y4.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Om2008.8: execute script on incoming call
Hi everyone! I'd like to have a file where I put in phonenumber /path/to/shellscript Everytime an incoming call matches one of the numbers in this file, the device just hangs up and executes the corresponding script. Does anyone have an idea how to do this? I guess it will require modifications in qpe ... Perhaps someone familiar with the sources could point out where the best place would be to hook into? Or someone has a completely different idea that is a lot simpler? ;-) Ole pgp7nw480yPA3.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2008.8: execute script on incoming call
On Thu, Aug 28, 2008 at 01:10:25AM +0200, Michael 'Mickey' Lauer wrote: If it doesn't need to be 2008.8, then you might want to give the frameworkd a try, which has been written for exactly these things. There, it would be as simple as (python example, but works with all kinds of languages of course): [ code example ... ] Hey Mickey, thanks a lot for the example. Looks like it's eventually gonna be FSO for me. Good to know someone is supporting the ol' script-it-yourself style. :) Ole pgpTnKQHf5ii1.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
On Wed, Aug 27, 2008 at 04:20:38PM -0700, Michael Shiloh wrote: Ole Kliemann wrote: Hi everyone! I'd like to have a file where I put in phonenumber /path/to/shellscript Everytime an incoming call matches one of the numbers in this file, the device just hangs up and executes the corresponding script. Cool application. This plus Arduino could be the bases of some nice remote control. What I was planning to do: I have VoIP for telephony at home and asterisk running on my server. A script on the server checks my email. If it finds new mail it calls the FR. The FR does not accept the connection, instead it connects to the internet and gets the email. It does not cost anything as no phone connection is established. And I have immediate notification on new mail. pgpsli2ko5Nax.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
On Thu, Aug 28, 2008 at 04:17:56PM +0200, Linus Gasser wrote: Ole Kliemann a écrit : What I was planning to do: I have VoIP for telephony at home and asterisk running on my server. A script on the server checks my email. If it finds new mail it calls the FR. The FR does not accept the connection, instead it connects to the internet and gets the email. It does not cost anything as no phone connection is established. And I have immediate notification on new mail. Some operators block such numbers that are just called and never answered. I had my number banned from the network for a similar application! I thought about this too. Guess it could happen, I will see. ;-) pgpI3izyk3iTh.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
On Thu, Aug 28, 2008 at 03:29:32PM +0100, Joseph Reeves wrote: 2008/8/28 Ole Kliemann [EMAIL PROTECTED]: I have VoIP for telephony at home and asterisk running on my server. A script on the server checks my email. If it finds new mail it calls the FR. The FR does not accept the connection, instead it connects to the internet and gets the email. It does not cost anything as no phone connection is established. And I have immediate notification on new mail. We have a Asterisk/FreePBX combination at work. My account is setup to email me any voicemails I receive as wav files. I can't help but think that an IMAP client on the phone would be an easier solution to the one you've proposed. I think it depends on the amount of mail and what you want to do. I thought of it as a kind of MMS replacement. The ability to send larger messages with possible multimedia content and having immediate notification. If you have some friends who are willing to use a system like that, then message can be passed with notification within this group for a very low price. I pay 24euro-ct/MB and only for every started 10kb. On the other hand the amount of messages passing through this system will be low. AFAIK to have immediate notification with IMAP you have to either keep a connection open or check for new mails in intervals. Both will cause costs. pgptMB2TiVWrC.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
On Sat, Aug 30, 2008 at 02:04:37PM +0930, Rod Whitby wrote: Stroller wrote: I thought the standard now was unlimited data plans. ... You have my sympathies if you're not on an unlimited data plan, Ole, but I would see unlimited data use as the long-term expectation of OpenMoko projects. Please don't assume that everyone has unlimited data plans. It is not as common in many parts of the world as it is in your part of the world. I expect the IMAP client on my openmoko phone to be able to download all my email for offline reading, deleting, and replying on the bus with *no* internet connectivity, and then sync all those changes seamlessly to the server as soon as I get the next internet connection. This sounds like a reasonable way to handle it. But the email traffic I have to handle on the road is really rather low volume. My idea of VoIP notification certainly isn't very useful for someone who gets several mails an hour. In this case IMAP-idle or with interval checking is probably better. I was more looking for a way to pass signals to my mobile without having to pay for it. For £20 this includes unlimited texts and one of the following free bolt-ons: unlimited texts (WTF?), unlimited O2 to O2 Calls, unlimited Web Bolt On, unlimited weekend calls, unlimited landline calls, unlimited Wi-Fi, 200 extra anytime minutes. https:// shop.o2.co.uk/tariffs/simonly I don't have unlimited data plan. But if I assume 20 pound per month for my mobile bill, I practically have unlimited data too. ;-) Ole pgp88EM2rJHLS.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
On Sun, Aug 31, 2008 at 06:37:05AM +0100, Stroller wrote: As the son of Lancastrian blood, I can sympathise with parsimoniousness, but right now Ole's suggestion appears penny- pinching to me, rather than practical prudent economising. Are you by any chance associated with a VoIP company and afraid of people making no-connect/no-cost calls all the time? ;-) I am just exploring the range of possibilities. Whether they are practical or hypothetical. Probably you are right in this case. But it is still an interesting point that you can by this way send signals to your mobile. Especially since you can alter the number the caller is transmitting thus enabling for a nearly unlimited number of signals. Ole pgpcxIRl35pXE.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
With my prepaid I have to pay traffic for every 10kb at 24ct/mb. On Sun, Aug 31, 2008 at 06:44:31AM +0100, Stroller wrote: I meant to ask in my previous email: Anyone know what is the overhead of IMAP-idle? Probably very low as long as the connection is stable. Every reconnect due to connection loss will cost 10kb. This won't happen so frequently - let's say in average every 30 minutes. This will be about 3.5 euro per month with my card. Pretty cheap indeed. Just one issue. Right now muxing does not work with 2008.8. Another issue: even when muxing will work in the future, I don't know whether my provider supports both a voice and a data channel open. (or however interval checking on IMAP works?) With interval checking I assume the traffic per check not more than 10kb. If you check every 5 minutes - which is not what I call `immediate notification' - it will cost 20 euro per month. Just for the checking. o_0 If you want to get closer to `immediate notification' and check every 3 minutes, costs go up to 35 euro a month. So if I get IMAP-idle working in a stable way and with muxing, it's the thing to go with. Interval checking is no choice at all. Ole pgpavXC2hdNP8.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
On Sun, Aug 31, 2008 at 12:30:23PM +, Ole Kliemann wrote: With my prepaid I have to pay traffic for every 10kb at 24ct/mb. On Sun, Aug 31, 2008 at 06:44:31AM +0100, Stroller wrote: I meant to ask in my previous email: Anyone know what is the overhead of IMAP-idle? Probably very low as long as the connection is stable. Every reconnect due to connection loss will cost 10kb. This won't happen so frequently - let's say in average every 30 minutes. This will be about 3.5 euro per month with my card. Pretty cheap indeed. Just one issue. Right now muxing does not work with 2008.8. Another issue: even when muxing will work in the future, I don't know whether my provider supports both a voice and a data channel open. (or however interval checking on IMAP works?) With interval checking I assume the traffic per check not more than 10kb. If you check every 5 minutes - which is not what I call `immediate notification' - it will cost 20 euro per month. Just for the checking. o_0 If you want to get closer to `immediate notification' and check every 3 minutes, costs go up to 35 euro a month. So if I get IMAP-idle working in a stable way and with muxing, it's the thing to go with. Interval checking is no choice at all. Ah, I'm stupid. I calculated for a 24hour day. It could even be more reduced as not always GPRS is required. I may be at home at USB or have Wifi. So with 6 hours on the road and 3 minutes checking I am at 8 euro per month just for the checking. For a low volume mailbox this would be still quite a waste. pgpHzzrYRGlG1.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2008.8: execute script on incoming call
On Fri, Aug 29, 2008 at 10:21:13AM +0200, Florian Hackenberger wrote: On Thursday 28 August 2008, Marco Trevisan (Treviño) wrote: Is there a way to use this in om2008.8? If you have a look at the qtopia documentation at [1], you'll notice that their design is quite similar to FSO. They provide you with some interface classes and you can request an object which implements such an interface from a service. You can then use this object to interact with the service. There is for example the QPhoneCallManager interface which has a signal 'newCall'. This signal is emitted whenever a call comes in. Have a look at [2,3] for further details. Cheers, Florian [1] http://doc.trolltech.com/qtopia4.3 [2] http://doc.trolltech.com/qtopia4.3/phonelibrary.html [3] http://doc.trolltech.com/qtopia4.3/qphonecallmanager.html Thanks Florian! I will have a look at these. Ole pgpc4VkodxVVW.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2008.8 - latest update - FR suspends after 30 secs - unconditionally
On Sun, Aug 31, 2008 at 03:27:41PM +0200, Torfinn Ingolfsen wrote: Hello, On Sun, Aug 31, 2008 at 3:16 PM, Michael Zanetti [EMAIL PROTECTED] wrote: If you are just working over ssh I have a small workaround for you. Most of Ah - very useful - thank you. :-) the time, before the Neo suspends, the X-Screensaver comes up. If you wake the Hmm, perhaps the xscreensaver is involved in this? Does anyone know where the suspend parameters (for lack of a better term) is stored? Or which command is used to change them? Yes, seems to be the screensaver. Switch it off with `xset s off'. But it seems to disable suspend completely, no matter what you set in settings. Ole pgptHF6pYQCEf.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
On Mon, Sep 01, 2008 at 03:27:27PM +0100, Stroller wrote: On 31 Aug 2008, at 12:46, Ole Kliemann wrote: Are you by any chance associated with a VoIP company and afraid of people making no-connect/no-cost calls all the time? ;-) No, not at all. But I figured that since you're going to have to pay to fetch the data anyway, I couldn't see much saving with this drop-calling shenanigans. You appear to have proved me right with your subsequent calculations. If IMAP-idle works in a stable manner with muxing. Otherwise the interval checking will add considerable extra costs. Right now there is no muxing as far as I know. What relevance does VoIP have here - if you run VoIP on your Freerunner you're going to have to pay data rates on that. I think I wasn't clear about my idea. The VoIP is just a contingent factor here. It's just about making a call to the FR with a certain number transmitted as the caller's number. This number is interpreted by the FR as a certain signal. Consequently the call is not accepted and an action associated with the signal is executed. You could make these signalling call from any phone, using any infrastructure you like. But using VoIP gives you a good interface between a computer and the calling device. If you would use a normal phone to call the FR, you would need to interface it with a computer. Using VoIP on the calling side it's easy to check for mails and a server and then call the FR from the server. VoIP is not running on the FR in anyway. Or are you thinking I'm a VoIP exec protesting against your use of a VoIP provider for making drop-calls? Actually I'm not quite sure what your motivation is - except that you just don't like my idea. ;-) Ole pgpewt1iEMcqj.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
On Mon, Sep 01, 2008 at 03:27:27PM +0100, Stroller wrote: On 31 Aug 2008, at 12:46, Ole Kliemann wrote: On Sun, Aug 31, 2008 at 06:37:05AM +0100, Stroller wrote: As the son of Lancastrian blood, I can sympathise with parsimoniousness, but right now Ole's suggestion appears penny- pinching to me, rather than practical prudent economising. Are you by any chance associated with a VoIP company and afraid of people making no-connect/no-cost calls all the time? ;-) No, not at all. But I figured that since you're going to have to pay to fetch the data anyway, I couldn't see much saving with this drop-calling shenanigans. You appear to have proved me right with your subsequent calculations. I just realised why my drop-call solution is so much superior to any IMAP-idle or interval checking. It's funny no one thought about this yet. When using IMAP-idle you can hardly suspend, can you? At least it would be necessary to keep the connection open, handle incoming traffic and wake in case of new mail. I guess to do so will require the whole system to be running. When using interval checking you have the extra costs and extra battery drainage because of resuming every 3 minutes. If you use notification by drop-call, the FR can sleep through - the modem handles the wakeup. Ole pgpgXQx6aPPg2.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Email notification by VoIP. Was: Re: Om2008.8: execute script on incoming call
On Tue, Sep 02, 2008 at 07:49:25AM +0100, Stroller wrote: An application should be able to wake up the phone from suspend (or rather add an entry to the `at` queue saying wake me at this time) and it should be able to fire up a GPRS connection. How long will it take to check for new mail? 15 seconds? In that case you're effectively going to lose 15 seconds of battery talktime for every check. If you check every 5 minutes then for every hour suspended you'll use additional battery at a rate equivalent to 3 minutes of talktime. Checking every 5 minutes means that you get a message on average within 2.5 minutes of it hitting your mailbox; checking every 15 minutes means that you get a message on average 7.5 minutes after it hits your mailbox, which is probably a better battery compromise. The N95 manages this, why shouldn't the Freerunner? I did ask in one of my previous posts whether the Openmoko work on dbus will accommodate a program sleeping (suspending?) the phone /or initialising a GPRS connection, but I got no reply (because I waffled too much in that post, apparently). Some kind of standard method is surely needed, because I could see it being quite complicated (and quite Freerunner-specific) to do this stuff otherwise. Yes, but when talking about elegance, I don't claim drop-calls to be elegant. But imagine the FR's plop sound when it wakes up every 5 minutes in your pocket. The costs of interval checking maybe not very high and the battery loss irrelevant. Just elegant it is neither. If you use notification by drop-call, the FR can sleep through - the modem handles the wakeup. I'll be honest, I just don't personally like drop-calling. I dislike it when a girl does it to you because she's too tight to buy minutes (irrespective of the number she's wasted already this month and because she knows a guy will always return a pretty girl's call) and I find it a little inelegant for this application. Okay, i can understand that. But be assured, I will only drop-call myself. ;-) Another poster mentioned that some cell companies may block the number of frequent drop-callers. Presumably it costs one of the call-providers money to initiate a call which you are not then billed for? So it does seem to be slightly naughty, too. Yes, slightly. You're right, though - ideally this should be handled by the phone's modem (or by the phone's phone (??)) hardware, because that's already handling incoming radio and sleep / wake-up. If only there were a way to send a text message to a phone freely over the internet - we could use that far more effectively for pushing our mail (or anything else). The money mobile phone companies make from SMS messages, however, I suspect this is a forlorn hope. So I'm gonna annoy them with my drop-calls until they give us free text messages over internet. Still maybe one could ask on the HW list what the capabilities of the modem are in regard to GPRS connections when the FR is suspended... That would be an elegant solution: FR sleeps, modem handles GPRS traffic from IMAP-idle server until he signals new mail. Ole pgp3oI5QiJVRd.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ASU Illume Tango Theme
On Fri, Sep 05, 2008 at 08:15:34PM +0200, Marco Trevisan (Treviño) wrote: Ole Kliemann wrote: Has anybody ever tried to change the qtopia appearance? It's a bit out of tune now. I've tried it. But changing the Orange.conf color scheme doesn't seem to affect its appearance. I must study it a little more... Changes you make to /opt/Qtopia/etc/default/Trolltech/qpe.conf are being honoured. Wonder what these colour schemes are good for then... Perhaps someone of you guys can come up with a fitting qpe.conf appearance for the tango theme. I myself seem to be a bit dumb concerning colour compositions. :) Ole pgpiAHt8MpTpf.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The Lost Openmoko Community
Hi Vasco, On Sat, Oct 04, 2008 at 04:42:02PM +0100, [EMAIL PROTECTED] wrote: To all, but especially OM. I felt a little cheated when I saw the FR I had bought was not ready to be used as a daily phone. This had in fact been the publicity by OM at the time - GTA01 was for tinkerers, and GTA02 was for the public. Then people said no, it was clear that GTA02 was also for tinkerers only... I experienced it the very same way. If you looked just at www.openmoko.com, you would think GTA02 was a ready phone for end-users. I can be blamed for not informing myself enough. But I think OM at least tolerated the possibility of users being misinformed. Otherwise they should have put a clear warning on openmoko.com. Dear OM team, such a warning is even missing today. Instead I read: ``If you plan on using your FreeRunner for everyday use, then we would recommend Qtopia. While it doesn't utilize all the the new hardware features of the phone, it is reliable and stable.'' May be that Qtopia is stable, alas the kernel and hardware are not. WSOD and GSM buzz is my everyday reality. But honestly, I still love this project. OM after all is providing the first free phone. It is about time that man reclaimed machine. And this is a very important step towards it. Still there is a lot of disappointment. And that certainly comes from a lack of communication and information. I experience an unopenness concerning things that don't work yet. When people complain about their FR not being usable as a phone, they get answers like this one: ``I appreciate that many of you purchased the FR to use as your daily phone. But I really believe that the magic of Openmoko comes from what we do with this platform that is different from, and way beyond, a mere phone.''[1] Exaggerating just a bit, it sounds like: ``My FR is not working as a phone!'' - ``Well son, it was never meant to be a phone.'' That's just one random example but to me it feels like the general direction of many OM staff postings. So to pick up my earlier point: Why does openmoko.com not explicitly state that the phone's software is not ready for reliable daily use? There should also be a note about the possibility that the FR with your provider in your region will be suffering from GSM buzz. Thus being unusable as a phone. Ole [1] http://lists.openmoko.org/pipermail/community/2008-September/031063.html pgp0AGfBgnTdA.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
``Freerunner reliable and stable''?!
Hi to everyone. I already posted my point in an earlier discussion but didn't get much of a reaction. The original post was this[1]. I will shortly reproduce my main point here: Me as well as several others - as I read here on the lists - have bought our FR when it was released somehow expecting it being consumer-ready. It was the general notion that GTA01 was for developers, GTA02 for end-user. I certainly can be blamed for not gathering enough information before buying an FR. But then again if you just look at openmoko.com, you get a lot of fancy design but not one hint that the FR is not ready for everyday use. Instead I read: ``If you plan on using your FreeRunner for everyday use, then we would recommend Qtopia. While it doesn't utilize all the the new hardware features of the phone, it is reliable and stable.'' Which is simply not true. Qtopia of course suffers from the same hardware and kernel issues as just any other distro. So my question to OM is: Why does openmoko.com not explicitly give a warning concerning the current state of maturity of both the hardware and the software? (As it was btw. the case with GTA01. There was a big warning.) Ole [1] http://lists.openmoko.org/pipermail/community/2008-October/032531.html pgpgBd3sydCaV.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ``Freerunner reliable and stable''?!
On Sun, Oct 26, 2008 at 10:19:22AM +, Rui Miguel Silva Seabra wrote: Right now a lot of positive action is needed. If OpenMoko dies the hardware problems will NEVER be fixed, and the Free Software phone fails totally (Google Android is fake Free Software if you don't have phones into which you can exercise your rightful freedoms because they are locked with DRM, as is the HTC G1). Full ack. As I wrote in my original post: But honestly, I still love this project. OM after all is providing the first free phone. It is about time that man reclaimed machine. And this is a very important step towards it. Still I think it is a legitimate question to ask why OM on their openmoko.com appearance claim that GTA02 is reliable and stable. Openness means being open about mistakes too. pgpl4cYVe0Pvg.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ``Freerunner reliable and stable''?!
On Sun, Oct 26, 2008 at 11:44:35AM +0100, Matthias Apitz wrote: Hello, I'm a bit tired of all those (useless) threads like this. I DO USE the FR with Om2008.9 for everyday use, I do not even own any other cellphone. We should improve what we have and stop useless discussions, as well about Google's trick of Android which has nothing todo with free software. Thx matthias Sorry for asking, but have you actually read my post? All these useless discussions arise from the discrepancy between what people expect and what OM delivers to them. A clear warning about GTA02 on openmoko.com and the annouce mail could have saved us a lot of useless discussions. Certainly no use crying over spilt milk now. Just the problem remains. If you are into the community and the wiki and you just look at openmoko.com, you still think you get a usable and reliable phone. Judging just from openmoko.com, which I understand is the official company's website, there is a problem with OM's self-perception. Ole pgpAduSDi8IrO.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ``Freerunner reliable and stable''?!
On Sun, Oct 26, 2008 at 12:12:42PM +0100, Paul wrote: On http://wiki.openmoko.org/wiki/Neo_FreeRunner everyone can read: The FreeRunner can be purchased from the Online Store http://www.openmoko.com as of July 3, 2008. The software available on the phone makes it suitable for power users and developers only -- it is not yet ready for the general consumer. I was talking about openmoko.com, not openmoko.org. So whining that it is not ready for the regular user is kind of sad. There is a difference between a regular and a power user, and that is not only the letters it takes to write the words. I was not whining at all and specificly not about the FR not being ready for regular users. I was merely pointing out in which way OM did and still does support the notion that the FR would be ready for regular users. It seems to have become a forgotten virtue to actually read a post before replying to it ... Ole pgpz5CbskWFNG.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ``Freerunner reliable and stable''?!
On Sun, Oct 26, 2008 at 02:12:18PM +0100, Yorick Moko wrote: On Sun, Oct 26, 2008 at 1:58 PM, Iain B. Findleton [EMAIL PROTECTED] wrote: Sorry to disagree. There was lots of info about how the FR was not ready for prime time available when I bought mine. I think it is pretty clear Don't get me wrong (I love my FR) I do too. :) but when I bought it (preordered it very soon) it was still marketed as a working phone, not a developper phone. Not only on openmoko.com, but also on openmoko.org. (And yes I informed myself very good, I read almost every mail). Thank you. That's exactly my point. that this machine is a hackers box that makes phone calls, and that is what I bought. I use the thing for phone calls and it works just fine. But that is the problem, it still can't make reliable phone calls (echo has been partly fixed, gsm buzzing sound still around and I havent tested the latest image but until recently the calypso chip keeps re-registering). I have tried everything a thousand times, 2007.2, ASU, 2008.8, 2008.9, FDOM, FSO, Qtopia... and never have gotten a working phone Quite the same for me. a lot of problems like thelimited bus (glamo's fault) were told, but everything you could read said it would be a working phone I vote in favour of editing openmoko.com, at least for now Yes, that's it. Ole pgpY8qKwXW4AU.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ``Freerunner reliable and stable''?!
On Sun, Oct 26, 2008 at 02:22:08PM +, Stroller wrote: So whining that it is not ready for the regular user is kind of sad. ... A new purchaser might not know to read the wiki. Such a notice should also be on the Openmoko.com site, too, particularly pages around the online store. Openmoko have been advised about this on a number of occasions, and I thought they had even agreed to post such a notice. At present it seems quite easy to go to Openmoko.com, click on Products Buy now USA Store Buy now and not see such a notice. Once again: I didn't mean to whine/rant or do anything alike on my post. I just wanted to point out exactly this. I wasn't aware of the fact that they already been advised several times about this. But that only makes my question more legitimate. Why does OM refuse to fully disclose the state of maturity on openmoko.com? Otherwise I do generally agree with you that these threads are unproductive. But the best way to deal with them is to remove all excuses to whine about Freerunner stability - by posting such a notice. See above. Ole pgp7IYf1kQKn5.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
WSOD
Hi everyone! I have not been reading the lists lately, so I don't know if this is an old one. I have been suffering badly from WSOD. This means, often when I resumed from suspend the screen showed all white while other things still worked. Sometimes it recovered after some minutes and screen worked again, sometimes I waited for maybe 10 minutes then switched off the device. I had this problem since I got the device in July and I always thought this was a kernel problem. I tried about every kernel version so far but it was always the same. Now, GPS was not working on my device, so last week I finally returned it to my distributor and he sent me a new one. I am using the exact same kernel and distribution[1] that was giving my WSOD all the time on the old device (just like every kernel and distribution was given WSOD). But suspend/resume is now working flawlessly. No white screen ever! So this bug is highly hardware related after all? Replacing the hardware fixed it for me. Ole [1] http://qtextended.org/modules/mydownloads/visit.php?lid=98 pgp3fTH3NgAAK.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
2008.12 illume theme
If I change /etc/enlightenment/default_profile to use the illume theme instead of ASU, enlightenment segfaults only seconds after displaying the pin dialog. But I don't know if this way changing profiles is even supposed to work. Ole pgpGm2xjYlkWr.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2008.12 illume theme
On Fri, Dec 19, 2008 at 10:28:23PM +0800, John Lee wrote: try disable qtopia under /etc/X11/Xsession.d first, restart X, finish the config, move qtopia back... Thanks all. This way it works. Ole pgpda5Ck6wBcw.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, Oct 28, 2009 at 08:45:08PM +0300, Paul Fertser wrote: Marcel tan...@googlemail.com writes: - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode Where would I have to put that? A mode for xrandr I guess, but how do I teach it to use that? Nah, just use fbset utility. Following the instructions in this thread gives me a somewhat graphically intact screen. But the touchable area is -- like stated before -- reduced to the upper left quarter of the screen. But this quarter scales to the whole screen: touching upper left corner is a click in the upper left corner, touching the lower right corner of the upper left quarter results in a click on the lower right corner of the whole screen. Is this the problem with the touchscreen driver mentioned by Raster? And how could this be resolved? I still consider speed one of the usability issues of the FR. And I think it is responsiveness shiny things. ;-) pgpzz9EqQ3Gyf.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Wed, Nov 04, 2009 at 03:41:47PM +0100, Sebastian Krzyszkowiak wrote: On 11/4/09, Ole Kliemann ole-om-community-2...@mail.plastictree.net wrote: On Wed, Oct 28, 2009 at 08:45:08PM +0300, Paul Fertser wrote: Marcel tan...@googlemail.com writes: - graphics in general are far too light, most colors become whiteish - colored stripes horizontally over the whole display, but are invisible on screenshots (naturally) - the same as above, but photographed: http://d-a300.selfip.net/files/shr-today-qvga.jpg Known problem, try these timings for fbset: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 rgba 5/11,6/5,5/0,0/0 endmode Where would I have to put that? A mode for xrandr I guess, but how do I teach it to use that? Nah, just use fbset utility. Following the instructions in this thread gives me a somewhat graphically intact screen. But the touchable area is -- like stated before -- reduced to the upper left quarter of the screen. But this quarter scales to the whole screen: touching upper left corner is a click in the upper left corner, touching the lower right corner of the upper left quarter results in a click on the lower right corner of the whole screen. Is this the problem with the touchscreen driver mentioned by Raster? And how could this be resolved? I still consider speed one of the usability issues of the FR. And I think it is responsiveness shiny things. ;-) If you're using Xglamo, then it's known and it's already fixed in Xorg. I see. Well... how do I get Xorg then? ;-) I am using the latest SHR-unstable image with latest updates from the feeds. I cannot find Xorg in the unstable feeds. I read that it was so far only integrated into some other branch of SHR? But I cannot find anything more recent than the unstable, although it hasn't been updated for over a month now as far as I can see. pgpy6J4a8A12a.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR] QVGA and WSOD
Trying to switch resolution to 240x320 on shr-unstable or shr-testing I get the following problem. /etc/fb.modes is: mode 240x320 geometry 240 420 240 320 16 timings 10 8 88 2 2 8 2 accel false endmode With X running I do: # xrandr -s 240x320 # fbset 240x320 Now two things can happen. 1) the display works ok, just with some horizontal stripes. 2) the display fades to all white and stays like that. Case 2) can be easily produced by just calling # fbset 240x320 a second time, after the first call produced result 1). This almost always works. The screen can be all white after suspend/resume too. Sometime an all white screen can be fixed by suspend/resume. But the timings are back to previous state then and a call to fbset is inevitable. This mostly results in 2) again. When suspending/resuming sometimes there was the console visible before X got back. There was a repeated message, I think it was glamofb cmd_queue never got empty pgpg5Tp0LeWPv.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] QVGA and WSOD
I figured it out this far: The problem is independent of X. If you stop the Xserver and do # echo qvga-normal /sys/bus/spi/devices/spi2.0/state # fbset 240x320 with /etc/fb.modes as follows mode 240x320 geometry 240 320 240 320 16 timings 10 8 88 2 2 8 2 endmode then there is a high probability that the screen will fade to WSOD. This is on latest shr-unstable. If I flash this kernel [1] from September, keeping the rootfs at latest shr-unstable, the problem does not occur. You can then start X and have 240x320 resolution, suspend works without problems. Just there are still some horizontal stripe like from bad timings. What could be the right timings? I have so far encounter no problems from using the older kernel. [1] http://buildhost.shr-project.org/shr-obsolete/images/om-gta02/uImage-2.6.29-oe11+gitr119844+a3587e4ed77974adfb057af261aaeea4022018e8-r3.5-om-gta02.bin pgp4BhiKbvEpK.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] QVGA and WSOD
On Sat, Jan 02, 2010 at 11:38:28PM +, Ole Kliemann wrote: I figured it out this far: The problem is independent of X. If you stop the Xserver and do # echo qvga-normal /sys/bus/spi/devices/spi2.0/state # fbset 240x320 with /etc/fb.modes as follows mode 240x320 geometry 240 320 240 320 16 timings 10 8 88 2 2 8 2 endmode then there is a high probability that the screen will fade to WSOD. This is on latest shr-unstable. If I flash this kernel [1] from September, keeping the rootfs at latest shr-unstable, the problem does not occur. You can then start X and have 240x320 resolution, suspend works without problems. Just there are still some horizontal stripe like from bad timings. What could be the right timings? I have so far encounter no problems from using the older kernel. [1] http://buildhost.shr-project.org/shr-obsolete/images/om-gta02/uImage-2.6.29-oe11+gitr119844+a3587e4ed77974adfb057af261aaeea4022018e8-r3.5-om-gta02.bin Problem remains with kernel-image-2.6.29-rc3_2.6.29-oe11+gitr119861+b90406de472c1aa5371ab593a2bb79136d5de658-r7.4_om-gta02.ipk from the unstable feed. Reflashing [1] fixes it again. pgpRxmnOTWr8i.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] QVGA and WSOD
On Wed, Jan 06, 2010 at 02:00:22PM +0100, Radek Polak wrote: Ole Kliemann wrote: with /etc/fb.modes as follows mode 240x320 geometry 240 320 240 320 16 timings 10 8 88 2 2 8 2 endmode Hi, i am using this setup together with: echo qvga-normal /sys/bus/spi/devices/spi2.0/state mode qvga geometry 480 640 480 1280 16 timings 10 8 16 2 16 8 2 rgba 5/11,6/5,5/0,0/0 endmode Works for me quite good. I have this in my docs[1] [1] http://github.com/radekp/qtmoko/blob/master/doc/txt/debian_rootfs_howto.txt Thanks for the answer! At what point in the process do you start X? And how and when do you tell X which resolution to use? pgpgTIwzkOTd7.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
On Fri, Jan 08, 2010 at 08:23:00PM +0200, Timo Jyrinki wrote: Hi, Just FYI to the community list, as slowness has been one of the biggest problems with Neo. Quite nice speedups are coming: This is the single most incredible speedup so far! Big thanks to anyone involved! I'm running shr-testing with neo-theme and at resolution 240x320. Even scrolling the contact list etc. is quite smooth now. And the interface is as responsive as it has never been before. pgpCjstFf5XIT.pgp Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
