Re: Freerunner - small and fast distribution only for GPS
On 28. aug. 2010 00:33, Timo Juhani Lindfors wrote: Carsten Gerlachdaswaldh...@gmx.de writes: does someone know a small distribution which is only made for GPS usage? For I don't really see the point in having a yet another distribution. Just take an existing distribution and configure it to fit this task. Optionally contribute back some new packages. Configuring a system for GPS-only use is an interesting challenge. 1) The filesystem probably should be read-only so that you can turn the power off at any time, right? Set it up so you suspend it, instead of turning off. Unsuspend is much faster than boot. I wonder: For such a simple setup, could unsuspend be used instead of booting? I.e. if you lost power, you unsuspend into some saved image, instead of waiting for a cold boot. 2) The only volatile part of the filesystem would then be the gps tracks? To be completely power-proof, use a synchronously mounted sdcard. Slow fs, but gps logging is low volume anyway. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some questions to new SHR images (ubifs, gps)
On 26. juli 2010 20:43, David Garabana wrote: O Luns, 26 de Xullo de 2010 11:13:09 Helge Hafting escribiu: On 23. juli 2010 21:43, David Garabana wrote: O Venres, 23 de Xullo de 2010 21:25:50 Sylvain Paré escribiu: I take this thread about GPS to give my feed back too. From my personal feedback I will not speak about half a year but since March or so And I do make it works but it takes more time the first time after a fresh flashed image PLUS the gps is less sensitive like the signal was weak ( It fixes less satellites) Also, with latest images, I cannot get a fix after a suspend. Do you suspend with the gps active, (i.e. tangogps running) or do you have this problem after any suspend? It's after *any* suspend. Even after a clean boot, if I suspend before doing anything else, GPS doesn't work. [...] I use shr unstable. I upgrade now and then, but haven't flashed for a long time now. That's the only difference I see between your installation and mine. I flashed a new image on NAND when SHR jumped to 2.6.32. It was then when GPS started to fail. I upgraded, against the advice given, because I did not want to re-do my customizations. (Reinstall software, set up tangogps and kayboard layouts,...) I figured I could always reflash _if_ the upgrade failed. You can get the same kind of setup by flashing an old image, and then upgrade shr. No guarantee that it'll help though. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
2+4+2 timing seemed to disrupt access to the sdcard
I have been using the qi with 2+4+2 timing over the weekend, and noted two problems. (This with shr unstable and its 2.6.32 kernel.) First, lots of WSODs. This required lots of suspending (or reboot) without seeing the screen. This is not always possible, so lots of battery removal. All this crashing caused some filesystem trouble. And then the second problem showed up. I got i/o errors reading from the sdcard. Sometimes, I didn't get tiles for tangogps or pictures for my contacts. Unmounting the sdcard and running fsck ought to fix this. But the fix was temporary. fsck would claim to fix some issues, and when I remounted the card, I had normal access to the files. But it was all in the page cache - it wasn't real. Reboot, and exactly the same errors came up again. fsck would give exactly the same messages while running. And things would work for a while, but another reboot would always bring the same problems back. It was as if writes to the sdcard failed - but failed silently. So the kernel didn't notice. But nothing actually got written, it just stayed in the page cache so everything seemed ok. I also had a lot of hangs - probably because I have swap on the sdcard. If swapping to the card silently fail, then surely there is trouble when the stuff is swapped back in. Do the sdcard and the glamo share a bus? Maybe glamo can handle a speed that the sdcard cannot? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
My guess about the WSOD
On 21. juli 2010 10:25, Petr Vanek wrote: With the 2+4+2 qi, WSOD seems to happen more often. And curiously enough, removing power (as in pulling the battery out), doesn't help. It is then guaranteed to reboot into WSOD. Strange that the phone is capable of keeping this state over poweroff - do qi and uboot write state into flash? The solution is to boot into NOR flash, and then select Poweroff from the menu. After that, I get a normal reboot without the WSOD. Graphics indeed seems a bit faster with this qi. :-) I hope the WSOD problems can be fixed in the kernel and/or the xserver. It happens without this qi too - perhaps not as often. i can confirm exactly the same findings. as JaMa stated, perhaps this will help to find the cause of WS altogether... A WSOD was always a possibility. But in older images, it was rare. I saw it occationally with duke nukem - Duke changes resolution and orientation of the screen. The 2.6.32 kernel brought nice speedups. But WSODs happens now and then. The qi that changes glamo timing from 4+4+4 to 2+4+2 brings even more speed, and much more WSOD trouble too. At least when combined with 2.6.32, I haven't tried it with 2.6.29 or older kernels. It seems to me that the WSOD happen only when the display is turned on, or the resolution and/or orientation is changed. So I guess the programming of resolution and/or orientation is timing-sensitive. Existing code worked reasonably well with old kernels and 4+4+4 timing. But speedups break it. Maybe someone with a compiler could try adding delays between hardware operations in the modesetting code? (Preferably both the kernel modesetting, and any screen-on operation the bootloader might do. And if there is any modesetting left in Xorg these days.) Extra delays (or longer delays) should compensate for unknown timing sensitivities in the hardware. Maybe evn 1+4+2 timing can be used eventually. The video mode change is a rare operation - it won't matter much if it gets slower. Not if graphics painting operations gets faster. :-) Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flashing qi broke my freerunner - SOLVED
On 20. juli 2010 16:52, Helge Hafting wrote: [...] On reboot, the screen went white, and nothing more happened. Solution for bricked phone: Somehow, the kernel partition got wrecked during flashing. So, reflashing the kernel brought the phone back to life. (No, I did not make the mistake of flashing qi into the kernel paritition. But it got broken anyway.) Solution for recurring WSOD: With the 2+4+2 qi, WSOD seems to happen more often. And curiously enough, removing power (as in pulling the battery out), doesn't help. It is then guaranteed to reboot into WSOD. Strange that the phone is capable of keeping this state over poweroff - do qi and uboot write state into flash? The solution is to boot into NOR flash, and then select Poweroff from the menu. After that, I get a normal reboot without the WSOD. Graphics indeed seems a bit faster with this qi. :-) I hope the WSOD problems can be fixed in the kernel and/or the xserver. It happens without this qi too - perhaps not as often. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flashing qi broke my freerunner - SOLVED
On 21. juli 2010 10:25, n...@el-hennig.de wrote: Solution for recurring WSOD: That was no *OD, as the freerunner boots normally, except for not showing a display. So halting the system vie USB/ssh still works The solution is to boot into NOR flash, and then select Poweroff from the menu. After that, I get a normal reboot without the WSOD. Graphics indeed seems a bit faster with this qi. :-) I don't see a performance gain on my freerunner (latest SHR-U, 2.6.23.13). How do you all test this? I mean not becnhmark-wise but with a real-usage-example 2.6.23? You meant 2.6.32? The performance gain is only for graphics operations, not for computation or filesystem activity. (This qi improves timing for the glamo graphics chip.) So try booting with normal qi and enhanced qi. In either case, look at operations that paints or scroll large parts of the screen. Get a feel of how much time is used - maybe you notice the difference. Or play videos, and check how high framerate you can get before the player drops frames. Or play graphics-intensive game like linball or duke nukem. If you can get them to work on today's SHR, that is. Currently, the necessary screen rotation does not seem to work well. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On 03. mai 2010 11:10, Jeffrey Ratcliffe wrote: On 3 May 2010 11:04, Dr. H. Nikolaus Schallerh...@goldelico.com wrote: Having navigation work inside tunnels would allow mapping them accurately for openstreetmap. And also have underground navigation - some tunnels have got intersections/roundabouts inside, with several possible exits. Would navit, tangogps, etc. need a new interface to access the sensors, or could the existing libraries be adapted to correct the GPS data with additional information from the extra sensors before handing it on to the GUI? The natural place for such software seems to be in gpsd itself - it already supports having several gps (position) devices. (Or possibly in a front-end to gpsd - depends on what the gpsd developer wants.) But too many processes / software layers is not good - it causes delays. navit, tangogps etc. should of course not need reprogramming, you can't fix every program out there. Especially not the proprietary ones. The software should simply pass through gps data as long as it arrives, and the precision is sufficient. This data can be used for continous calibration of the magnetic/inertial/odometer inputs. When gps precision drops below intertial precision, or when gps drops out completely, the software should keep sending position updates based on inertial data. On your display, the map software will then tell you that you have 0 satellites, but still update your location on the map. Another use: interpolate position between gps updates, so you can have a 10 FPS map if you like. As the software auto-calibrates the inertial system, it can know its precision. So it can report how the gps-less position data deteriorate over time, and perhaps stop when precision gets so bad that the inertial data is no better than assuming you just stopped at the point where you lost gps coverage. An inertial system with only accelerometers will go bad quickly, unless you have some really good accelerometers. A system with odometer and magnetic compass can keep you going for a long time and do better than the simple stopped due to missing gps signal. In particular, the odometer will know when you are standing still - you can only loose precision when moving. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
On 03. mai 2010 13:05, Michele Brocco wrote: On 5/3/10, Helge Haftinghelge.haft...@hist.no wrote: [...] For cars, one can get USB equipment to read the odometer pulses (and lots of other stuff besides that.) A similiar sensor can be made for bicycles - having an input for that on the board would be very useful. (And given the slow cpu, a pulse counter so the software won't have to rely so much on pulse timing.) This is great for driving in tunnels. There are many mountains and tunnels where I live. Having navigation work inside tunnels would allow mapping them accurately for openstreetmap. And also have underground navigation - some tunnels have got intersections/roundabouts inside, with several possible exits. And then there are cities with too many tall buildings, and things like parking houses. In principle that would work. In practice I am afraid that will work for only short distances due to the noise of the sensors. In my opinion we should first focus on use cases in which short distance tracking is required. I think the success rate there may be higher and we can the build on our findings more complex applications. Personally, I will focus on that. I would be interested in seeing also other use cases implemented though. I think one approach can work for all. Software that auto-calibrates the other inputs while the gps signal is good, will know the precision of the other inputs. When gps drops out, it can provide location data until precision deteriorates into uselessness. This may not take long with a cheap accelerometer - but the software will automatically work for much longer if more precise equiopment is connected. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Flashing qi broke my freerunner
On 20. juli 2010 09:17, ghislain wrote: I've applied the glamo patch to the qi-bootloader I use for the QtMoko installer-images. You can download the qi-bootloader here [1]. It replaces the qi.img file in the installer image so you can reflash with this new bootloader. It is, of course, also possible to flash this new bootloader using dfu-util I tried this. Downloaded qi-s3c2442-master_c38b062a609f1442.udfu, flashed it with dfu-util. Command: dfu-util -a u-boot -R -D qi-s3c2442master_c38b062a609f1442.udfu On reboot, the screen went white, and nothing more happened. Unfortunately, there seems to be no way of fixing it. I can download other qi versions and flash them. But none works. The screen just goes black. For some versions, the vibrator will sound every 10s or so. Booting through NOR doesn't work, probably because the kernel is bigger than 2M. So qi is needed, but seems impossible to get working. Am I doing this wrong? One of my qi files is the one that worked before. But not now. Is there hope of using this device any more? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The Phoenux is coming: Openmoko Beagle
Dr. H. Nikolaus Schaller wrote: We can soon provide a printed circuit board (Openmoko Beagle) that can carry a Freerunner display module (incl. touch screen) and is connected to a Beagleboard. It fits into a (slightly cut) Freerunner case (although you can do everything without destroying a Freerunner; only the buttons are a little more difficult to use). Nice. Combining the FR display with a faster processor is interesting. It'd be even better if it either fit in the FR case, or some alternative case can be ordered instead. Expanding the FR case by making it thicker is also an option. Is the touchscreen the only FR component that can be reused? The gps unit is rather good - could it be connected to the new board with only simple soldering? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Introducing the Freerunner Navigation Board
Christoph Mair wrote: Dear community, we are proud to release a hardware extension for our beloved Freerunner: a navigation board! What is it? The Freerunner Navigation Board is a small PCB which is able to measure rotations as well as the magnetic field in 3D respectively (i.e. compass and gyroscopes integrated). The navigation board can be integrated in the existing Freerunner case. Will the magnetic sensing work with any orientation of the FR? One use for this is to help the GPS in difficult places. The FR is usually placed with the GPS antenna facing up. When the gps signal is good, this can be used to calibrate intertial eqipment. (I.e. automatically figure out what orientation the FR has with respect to the vehicle, how much the vehicle magnetic field distorts the earths field, and how much the local magnetic field deviates from true north.) For cars, one can get USB equipment to read the odometer pulses (and lots of other stuff besides that.) A similiar sensor can be made for bicycles - having an input for that on the board would be very useful. (And given the slow cpu, a pulse counter so the software won't have to rely so much on pulse timing.) This is great for driving in tunnels. There are many mountains and tunnels where I live. Having navigation work inside tunnels would allow mapping them accurately for openstreetmap. And also have underground navigation - some tunnels have got intersections/roundabouts inside, with several possible exits. And then there are cities with too many tall buildings, and things like parking houses. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: little question about navigation board
Alfa21 wrote: 2010-05...@23:31 Christoph Mair why to add two more gyroscope sensors (so now we have 4 of them in our FR O_O) The Freerunner has two accelerometers, but no gyroscope. I tough 2 accels + 1 compas could act as gyros... (not the greek similar of the kebab) maybe I have to reopen my physic books ^_^' Partially so. A compass only gives you *some* of the direction. Particularly, the compass won't notice if the device spins around the north-south axis. Do it slowly, and the accelerometers may be too limited to notice. Of course, such a movement doesn't normally happen in a car. But you do want to notice if this happens to your plane . . . Helge hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Now someone REALLY has to help me!!
Märta wrote: As I’ve understand you can modify the Frerunners code by writing scripts into the phones terminal. Is that correct, you don’t need a linux computer to be able to do these tweaks (for example setting the time)? While a linux computer is nice to have, it is not necessary. There are several other ways: * Use the phone itself. Run the terminal program and use the tiny on-screen keyboard. You can do anything, but that keyboard is perhaps too small for doing much. Setting the time should be ok. * Use the phone itself and the terminal program, and a real keyboard. The keyboard can connect via usb or bluetooth. This require some configuration first. * Use a computer that don't run linux. Using windows and putty: http://wiki.openmoko.org/wiki/Neo1973_and_Windows Using a mac: http://wiki.openmoko.org/wiki/MacOS_X ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Buzz is not Fixed
Toni Mueller wrote: Hi, after getting my device back (months ago) and putting the first semi-working distro on it (SHR unstable from Feb. 24th this year), sound has improved from pure buzz to semi-intelligible buzz like on an old military short-wave walkie-talkie. It's very hard to use if there are also environmental noises, which there usually are. I verified that the buzz fix hardware is there. Turn the mic volume down. (Recent SHR shows a mic volume slider while the call is in progress.) Even my non-bussfixed phone gets (almost) buzz-free when I turn the mic volume down. Don't go too far, or nobody will be able to hear you though. Fine-tune the mic volume while calling yourself on another phone. Then terminate the call and reboot. When you reboot, the volume settings from the last call is saved. If you don't do this, then the next call will reset the mic volume to 100%, and that doesn't work well. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] gsm doesnt work after upgrade
Christ van Willegen wrote: On Sun, Feb 28, 2010 at 2:10 PM, Davide Scaini dsca...@gmail.com wrote: [...] we discussed about this (or something very similar) yesterday... right now I managed to get connected switching frameworkd loglevel to debug (see /etc/frameworkd.conf). Reboot and it should work... Something that needs to be fixed indeed :) What _might_ work is, after a reboot, _not_ letting the FR fall asleep... What do you mean here? Not letting it sleep _ever_ is not an option, suspend is a necessary feature. I usually keep the phone awake until it connects to the gsm network - is that what you mean? I do my upgrades using usb power, so the phone doesn't get a chance to sleep until I leave the pc anyway. Maybe that masks such problems for me. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debian - issues
omcomali@porcupinefactory.org wrote: Hi, I just installed Debian to be able to use some packages from the repos, and I need help to get it to behave. It's installed on SD card with multiple partitions, but how to mount the other partitions? I couldn't find the relevant device files in /dev, Files in /dev can be made as needed. Maybe your udev doesn't. Try cat /proc/partitions to see what ought to exist. These are the partitions the kernel has noticed, whether or not they actually appear in /dev. You probably want a better solution, but missing /dev files can be created with mknod. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: tangoGPS 0.99.3 is out
Marcus Bauer wrote: Hi, tangoGPS is out with lots of speed improvements and a lot less of CPU usage. Moreover the speed display is now set in pixels and no longer in points - especially on SHR that should result in lot smaller digits. Very nice! The smaller speed digits is much better on this display.:-) I have one wishlist item still: Tangogps remembers the last position and zoom level. And it remembers if it was logging to a file the last time it was running. It'd be very nice if tangogps also remembered the status of the center on gps position setting, instead of always defaulting to not follow the gps around. So if I quit tangogps while the map is centering on current position, then it will keep sentering on the gps position when tangogps is restarted. That way, it won't be necessary to press that button everytime I restart tangogps as a map display in the car. Helge Hafting winmail.dat___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AW: What to do with a broken touchscreen?
Neil Jerram wrote: On 10 February 2010 11:57, Helge Hafting helge.haft...@hist.no wrote: [...] That did the trick! Thanks for the tip - an easy repair when one knows. Could you explain more, because I think I have this problem too. How do you make a suitable glue strip, and how and where do you apply it? If you think it would help, could you take a photo? The fix is easy. The glue strip is ordinary transparent tape. Any supermarket or office supply shop should have it. Get a roll of tape, tear off a short strip, press it down on the bad part of the touchscreen where it will stick. Then tear it slowly off again. My touchscreen became unstuck at the first try. If yours doesn't, try a few times more. Note that the dent in the screen does not go away, but the troublesome behaviour ends. If you want to see what exactly the touchscreen is doing, then turn on the X mouse cursor. Open /etc/X11/Xserver in an editor. Search for GTA02. In that section, you'll find -hide-cursor. Remove that word. (You may want to make a copy of the original file first, so you can restore normal behaviour later.) Then restart X ( /etc/init.d/xserver-nodm restart) or reboot. if the cursor don't show up after that, start the terminal app and click in the middle of the terminal. The cursor should show after that. The visible mouse cursor should stay under your finger whenever you press the screen. If you have a dented bad spot on the screen, then the cursor will jump to that place all the time, and cause fake mouseclicks there which can be extermely annoying. Apparently, a dent in the screen compresses the touch-sensitive layer. Pulling out with some tape seems to fix that. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Alternatives to FR
Margo wrote: The Officer S101 seems interesting: http://www.road.de/en/handypcs/officer.html http://blog.hackable1.org/2009/08/running-hackable1-on-the-road-officer-s101.html Wow. At least a _useable_ hw keyboard. That is, one that has a couple of keys to the right of 'p' and 'l'. Which is necessary for so many non-english languages. A top row ending in 'p' is useless. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Latest SHR-?
Neil Jerram wrote: On 29 January 2010 02:15, William Kenworthy bi...@iinet.net.au wrote: shr-testing is probably the most usable out-of-the-box at the moment. Only a few annoyances rather than show stoppers. I tried shr-t again a couple of days ago (after getting annoyed with the unreliability of my Debian...). I thought the integration of the phone apps, including the great today/locking screen, is now quite slick. And aesthetically it's now starting to look nice too. But - I found that I very quickly ran into system freezes, and/or weird graphical effects. E.g. after only a couple of minutes of panning and zooming the maps in tangogps. Am I the only one seeing this kind of problem? You may want to run filesystem checks, a bad filesystem on flash or sdcard can cause all sorts of weird problems. I run shr-unstable. I upgrade often, get various improvements, and the occational breakage as well. But no freezes, just particular apps/functionality that fail Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian/fso] phonefsod: unpredictable pin dialog and questions abot config options
arne anka wrote: within normal operation (runlevel) phonefsod does not work predicatble. small changes in the phonefsod.conf made it stop entirely (w/o any useful info in the log despite DEBUG) and small changes in eg fsodeviced seemed to fix that ... what looks far more confusing to me is, that phonefsod always gets a lower pid than fsodeviced, fsousage or frameworkd -- despite being started later according to the number assigned in /etc/rc3.d: S01dbus ... S02fso-deviced S02fso-frameworkd ... S03phonefsod I don't know if it applies here, but unusual PIDs can happen as some daemons fork in order to run in the background, while others don't fork. Instead, they rely on start-stop-daemon or the startup script to put the process in the background. The FR is kind of slow, so apps that fork might take some time getting to the first fork. since accessing (activating?) the gsm means, one of the otheres has to be activae already. Not necessarily that active. init runs the fso-deviced script, which launch the daemon and quits. Then init launch the fso-frameworkd script, and so on. Generally, one script quits before the next starts. But that doesn't mean the launched daemon is actually ready for a connection. It may still be running early initialization code, such as resolving dynamic linking or parsing the config file. The next daemon to start may get through its initialization much faster, and try to contact an earlier daemon before it is ready. Which is why it is so necessary to have good retry logic. For example: 1. try to access resource 2. if not ready yet then sleep 1s, then try (1) again. It may still be necessary to abort/give up on other kinds of errors, but not ready is best handled by sleeping a little so the others can catch up before the next retry. The sleeping is necessary to avoid busy waiting. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: digital audio paths (Was: Re: Experimental technique for testing call audio quality? )
Stefano Cavallari wrote: On Friday 22 January 2010 20:13:58 Timo Juhani Lindfors wrote: Helge Hafting helge.haft...@hist.no writes: the same quality as this, by tweaking volume settings. Calls are digital The audio data is fed to the GSM chip in analog form however. If the FR sound quality is too bad, consider a BT headset. Sound quality should then depend on the BT headset only. The FR's problems with buzz, bad bass, and possibly other analog issues shouldn't matter at all. Even in this case the audio is fed in analog form to the GSM chip. Why on hell GSM chips are still done this way? Good question. Don't touch what works maybe? I hope whatever next open phone comes around it's totally digital. Audio lines maybe were a good idea for phones with few cpu power available, but now it's only a waste of PCB space I think. CPU isn't much of an issue for playing (uncompressed) digital sound. A small buffer and a DAC is all you need. I guess they put that stuff into the GSM chip, to avoid an extra audio chip. The most common use for GSM audio is to send it to the speaker, so the design makes sense. The hardware becomes more flexible and maybe you can do some DSP to enhance the voice. Or implement an answering machine inside the phone. Do anyone know about recent GSM chips? I'm still dreaming a up-to-date open phone :) Is there a standard to do voice-audio-codec over multiplexed AT channel? There is a standard for digital voice over an AT channel. The modems we used before ADSL took over had this - and so you could implement an answering machine on your PC. Or even menu systems with press 1 to leave a message, press 2 to ... It wasn't multiplexed though. The AT command set is documented and can probably be found on the net. So you could try some commands with a terminal emulator program on the FR. GSM supports data calls, maybe you can get digital voice too. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: debian/fso on freerunner
Neil Jerram wrote: 2010/1/20 arne anka openm...@ginguppin.de: not exactly. zhone as such has been updated only to ensure compatibility with current e, but someone (neil? timo?) offered to take care of patching zhone to enhance functionality. Yes, that's me. I'm accumulating zhone patches here: http://gitorious.org/stuff-for-openmoko-freerunner/debian-usr-bin Even I look at leading figures debian pass programs shr))) IMO Debian will eventually assimilate everything, including SHR. (Unless there is some major advantage of the OE build and packaging system that I haven't understood yet...) It's the best combination of free software focussed build, tracking and package management that there is, and I really don't understand why anyone persists with other systems... Debian is definitely great, but it has a big disadvantage on the FR: Size matters. Last time I checked, you couldn't even install debian on the internal flash. You had to use a rather big SDcard. I use shr-lite instead. With phone gps software and a couple of games, I still only use 42% of the internal flash. The SDcard I use is for roadmaps and music only. I don't need it just to make calls. I can replace that card whenever I want to. Debian is perfect when you have a few gigabytes, or more. I use it on servers, big laptops and tiny minimalist laptops. But debian is not what you want to cram into 100MB, at least not today. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Experimental technique for testing call audio quality?
Neil Jerram wrote: From the recent survey, it seems that several people are still experiencing bad call audio quality; and I've personally had some bad reports of this recently (and my phone has been buzz-fixed). One of the problems, with trying to work on this, is finding a way to test audio quality repeatedly without spending lots of money on call charges and without taking up a lot of someone else's time (as the callee). Can anyone suggest an experimental technique that is reliable - in the sense of being close enough to what really happens on a call - and that doesn't take a lot of money or someone else's time? The best I've found so far is to call my work voicemail, speak to it, and get it to play my recording back to me. But that's still costing a bit. Any better ideas? To test the quality of analog components (mic, amplifier, speaker): * Record voice (or test tones) to a file. Transfer the file to a computer with a good soundcard, to check quality. * Get a sound file of known quality, transfer it to the FR. Play it (alsaplayer or some other audio player) and check the quality. With this, you should get an idea of what sound the FR is capable of. Tweak relevant volume settings; too little is hard to hear, too much may clip and distort. Calls will surely not be better than what you can get this way. Ideally, you should be able to get calls up to the same quality as this, by tweaking volume settings. Calls are digital and shouldn't have sound distortion of its own. At least not worse than other phones. The current default call volumes in SHR-U are quite bad, which may be the reason for many recent reports of audio problem. Anyone installing SHR-U should call themselves (on some other phone) and adjust both mic volume and speaker volume. (And then reboot the phone, so the settings are saved.) If the FR sound quality is too bad, consider a BT headset. Sound quality should then depend on the BT headset only. The FR's problems with buzz, bad bass, and possibly other analog issues shouldn't matter at all. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Niels Heyvaert wrote: It may be some kind of race condition in the SHR software, that gets trigged much more often with the faster kernel. We found this race condition in Debian, too - even before using a faster kernel by lowering the framework's log_level. So it appears the symptoms have been tracked: http://docs.openmoko.org/trac/ticket/2327 (also see post by Timo). That ticket seems to describe a similiar problem with wifi, it doesn't mention GSM. Or are both handled by a common piece of hardware? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
David Garabana Barro wrote: On Monday 18 January 2010 16:52:11 Helge Hafting wrote: [...] Too bad this kernel didn't work, it seemed very interesting. I don't know what is causing gsm to not register, but it's not kernel, for sure. It may be some kind of race condition in the SHR software, that gets trigged much more often with the faster kernel. Still, the solution for now is an old kernel, for I need the phone to work as a phone. Fixing SHR shouldn't be hard, once the race condition is found. If one program depend on another, then start them in sequence instead of simultaneously. Or have the dependant program issue sleep 1 and then retry whenever the other program isn't there. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Encryption, Cameras and Games
Rashid wrote: Hi guys, I'm going to need a very safe smart phone for using it for investigative reporting. So I have some questions before I'm going to get a Freerunner: 1. Can you encrypt a LVM with luks like in Ubuntu? 2. Can you encrypt the whole phone / file-system? If not will it be possible in futere and is someone working on it? It runs linux, so it is able to do anything you can do with linux. (Within the limited processing power of the device.) You may have to set this up yourself though, I am not aware of anyone experimenting with encrypted filesystems. 3. Can you plug in an USB Cam (Like a Webcam) and use it to film (extremly important) on the crypted LVM? You can plug in any USB device that linux supports. I don't know if the device is fast enough to actually encrypt and store a video stream though. You might want to consider a really small PC like an acerONE. It even has a built-in webcam. 4. Mobile internet over GSM is working I think, or? Yes, this works fine. GPRS isn't very fast though. 5. Can you send the videostream / the videofile while you are recording via SSH (or something similar safe) to a server? The idea is, that when your phone is destroyed while filming you have at least the video until this moment. Probably not over GPRS - not enough bandwith for video! Wifi has enough bandwith, if you are within range of an access point. 6. With Hackable:1 Rev5 Chuck you can easily turn down GSM. Your location can't be found when its turned of, or? Can you force the GSM to connect to a random, far away GSM tower/connection-station to confuse the observers about your position? Turning off GSM means they can't find your position using the GSM network any more. They still know where you were, when you turned it off though. I am not sure you can force a connection to a faraway tower, and it certainly won't help you. The other towers still see the better signal strength, so your location is still known. We have serious problems in Europe with the freedom of the press so it would be great to use the freerunner with openmoko for helping freedom of the press. What part of Europe would that be? Definitely not western Europe. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] Screen Calibration
Iain B. Findleton wrote: Anybody know how to verify screen calibration on SHR-U? I need to check that the X server is returning reasonably accurate pen touch locations. You can turn the X11 mouse cursor on, by changing /etc/X11/Xserver You can then see how well the cursor track your pen. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Some questions about TangoGPS
Noel wrote: I'm the only one who sees the **big** advantage of navit over tangogps, as being able to work **offline**, with very-easy-to-get maps? You said that tango is very fast and very efficient at displaying your position. What's the use if the position is displayed on an empty map? Download all the maps you need once when you're online. Tangogps will work fine offline after that. (The same goes for navit - you have to give it a map to work with. Tangogps merely has the option of downloading maps when needed.) Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New significant speedups coming to FreeRunner
Radek Polak wrote: Radek Polak wrote: Here are mine numbers on QtMoko: kernel size: old: 1 833 952 new: 1 660 364 boot time old: 1min 58s new: 1min 30s Btw if someone wants to try here is new kernel with modules: http://activationrecord.net/radekp/qtmoko/download/experimental/ Installed the kernel, and the modules. It did not work. Well, X came up and was nice and snappy, but the phone never connected to the GSM network. I tried shr-settings, and GSM could not be turned on! I tried booting several times, I tried restarting various fso daemons that seemed phone-related. Nothing helped. In the end, I flashed the latest shr-unstable kernel, booted, and got a GSM connection just fine. (I use shr-unstable of today.) Too bad this kernel didn't work, it seemed very interesting. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Quick e-mail poll: Still using your Freerunner?
Sebastian Krzyszkowiak wrote: AFAIR there was some problem like that with GSM firmware. Do you have it upgraded? Yes, but I upgraded it long before the first time I tried GPRS. So perhaps there were problems before that. The phone functionality improved with the GSM firmware update - no more people complaining they called me while nothing happened on the device. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: [Shr-User] Quick e-mail poll: Still using your Freerunner?
Does anyone else have trouble doing opkg ugrade over gprs? mine hangs after a bit. I never tried that - but make sure the thing doesn't suspend. The problem happens somewhere between the wget application and the kernel stack. It shows up with larger files being downloaded. Not too large, a few dozen kB is enough. When I see it happening, I repeat the wget download that opkg was trying to do, and I can see that wget is actually in stalled state after the first kB. If I retry the download with the continue option, it eventually downloads the whole file, retry after retry, chunk by chunk. This only happens with GPRS, so I assume it is related to kernel or pppd or around this... Have you tried a different kernel? The kernel is in a separate flash, so upgrading the root filesystem doesn't change the kernel, it must be installed separately. It could help - if it is a kernel problem. If nothing helps, consider trying a different phone company. The problem could be there too. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: [Shr-User] Quick e-mail poll: Still using your Freerunner?
Do you use FR as your daily/primary phone? Yes Do you use FR as your primary PDA? Yes What distribution you run most of the time? SHR-unstable. I upgrade often, except that I wait when others run into some new problem. Then I wait for resolution, which normally don't take long. If you don't use FR as your daily phone/PDA, what phone did you change over to, and why? If I change, it will be to correct various problems: * Buzz and bass problems. Can be fixed with capacitors, but that won't be free and it won't help with the slowness problem. A BT headset will probably solve my sound issues, and can be carried over to future phones. But it means an extra device to bring, and another battery to charge. :-/ * Slowness. Of course, the new SHR-U helped. And we may still see improvements in X and elsewhere. Still, it seems the device has a slow memory bus, a slow connection to its SDcard, and slow graphics. It is useable, but a really snappy phone could be tempting. IF it runs a user-modifiable linux, that is! Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: [Shr-User] Quick e-mail poll: Still using your Freerunner?
-Original Message- From: shr-user-boun...@lists.shr-project.org on behalf of Vasco Névoa Sent: Thu 12/31/2009 7:20 PM Cc: List for Openmoko community discussion; shr-u...@lists.shr-project.org Subject: Re: [Shr-User] Quick e-mail poll: Still using your Freerunner? [...] Adjusting the call volume is a sorely missed feature, though. The new SHR-U has that for you. :-) [...] GPRS and WIFI are too unstable for any real connection, so no web or email. My experience is that GPRS has been stable for a long time, and WIFI is fine _if_ the phone don't suspend. So keep it on, either by plugging in power, or by turning suspend off in shr-settings. There is one annoying problem if several of GPRS/USB/WIFI is used - the last one to be used changes /etc/resolv.conf, and if that connection quits then the remaining ones may fail to look up names. Can be fixed by restarting the remaining connection. And bluetooth is just not there (no GUI == not there for the user). Does anyone else have trouble doing opkg ugrade over gprs? mine hangs after a bit. I never tried that - but make sure the thing doesn't suspend. Plug in power, or turn suspend off. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Xorg Glamo
Thomas White wrote: On Thu, 19 Nov 2009 12:09:32 +0100 David Garabana Barro da...@garabana.com wrote: I know the bandwith handicap, and I know it's not possible to improve that, but having free CPU time while Glamo is drawing should allow to calculate things (as next frames) instead of waiting glamo to finish. Shouldn't it? That's right. All I was saying is that the improvement only applies for accelerated operations, and that (at the moment) we don't ask it to do very many of those. At least, not operations that are large enough to be worth accelerating. The operation I seem to wait most for, is sluggish scrolling. Is that accelerated, or at least possible to accelerate? I don't worry so much that a complex window might render slowly. I can go for software with simple fast layouts. But a little more snappiness when dragging/scrolling might be very noticeable. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Rui Miguel Silva Seabra wrote: On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote: But there is a problem. The user may switch between several apps with different rotation needs. (xmahjongg needs landscape, tetris needs portrait, ...) How will omnewrotate be notified about this? The proper way is to define a set of DBUS signals. Of course conflicting signals need to be ignored. What conflicting signals? A proper implementation won't have conflicts? The normal freerunner usage is to maximize the foreground app, so there is only one app that need its rotation preference obeyed at any time. The user may run both some portrait apps, some landscape apps, and some don't care at all apps and some use the accelerometer orientation apps all at the same time. All of them can state their preferences, only one need to be obeyed at any time. So, when the user uses the arrows to flip form app to app, the orientation stays the same if a don't care app is selected, or some app that wants the current orientation. If an app with a different orientation is selected, the display should change _before_ the new app gets painted. It is a huge waste of time if the app first shows in the wrong orientation, and then quickly changes. (Or if the previous app is repainted in the new orientation before the new app is brought to the surface.) There are no conflicts, but whatever software you have managing the display must be able to change orientation at exactly the right moment. Merely setting the orientation when an app is launched (like we do for backlight) is no good - the user can switch apps at any time. Good orientation management must therefore be a part of the app switching mechanism. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ideal screen rotation
Neil Jerram wrote: Having just written an automatic screen rotation program (like omnewrotate), I'm now wondering about the best way of using it, so that everything Just Works the way that it should. In particular, I've realized now that - for many apps there is a preferred orientation (e.g. zhone and hex-a-hop), and the best thing is to rotate the screen to what is best for each app, regardless of how the phone is being held - for some apps you definitely don't want the screen to be rotated underneath them, e.g. mokomaze - for the apps where autorotation makes sense, you want the control to be easily accessible - certainly a lot easier than switching back to the launcher or an xterm and doing something there :-) Have others already thought about this and devised solutions? I think a good solution might involve the window manager - since the window manager knows which app is at the front of the screen and so could rotate the screen correctly for it (including enabling autorotation for the apps where that makes sense). Alternatively - at least for e17 - an easily accessible gadget in the top shelf could make it very simple to choose a specific orientation and to enable and disable autorotation. The software that control rotation need to know if the foreground app should run in landscape, portrait or auto mode. (And perhaps the upside-down variants as well.) There are many ways to do this. For example: 1. Add this to enlightenment. Advantages: e already knows at all times which app is in the foreground. The .desktop files in /usr/share/applications/ can specify rotation preferences. You can also have rotation gadgets on the top shelf, for overriding when necessary. Disadvantage: Works only with e - obviously. 2. Give omnewrotate (or similiar rotation app) a list of apps and their preferred rotation. Advantage: works for all window managers disadvantage: overriding the rotation could be trickier, and omnewrotate will need a way to get notified about focus/foreground changes. Fast polling will slow down the phone, slow polling will be too slow. So notification is necessary. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
Evgeniy Karyakin wrote: 2009/10/26 Carsten Haitzler ras...@rasterman.com: you want speed? you will need to give up something. if you still want it to look nice, then drop pixels. its the simplest and easiest solution. its the right resolution for that cpu anyway. the glamo will still hurt you, but not as much. I'm sure everybody who has any professional connections with Freerunner+Glamo development already took all possible measures to solve this problem. But what concrete steps were taken to ease Glamo bottleneck? If its throughput is so narrow, can we lower amount of data flowing through it? Sure you can lower the amount of data flowing through it. Lowering the resolution is one option that several has mentioned. Another way is to draw less stuff overall: * Don't draw anything that need several passes, i.e. transparency * Don't draw anything unnecessary, i.e. cute animations * Don't ecen think of 3D. * Optimize the user interface. Never redraw the screen when drawing a smaller portion will suffice. Don't highlight an icon by changing the background color. (Lots of pixels).- Just draw a 1-pixel wide square around it, for example. (And make sure your drawing library doesn't do anything excessive behind your back, such as drawing the entire icon with that border - because that was simpler to implement. The situation is not hopeless. The entire 640x480 16-bit display is 614400 byte, or 0.6MB. 7MB/s means the entire display can be updated 11 times per second if need be. In theory, anyway. Anything updating a smaller portion of the screen could be even more responsive. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Thanks for good work on the WIFI driver
Sander van Grieken wrote: Yeah, I haven't seen SHR-U updates for a while. Helge, is this with a self-built image? This kernel is not that new. I think I got it in an opkg upgrade session. SHR-U has not updated in a while, so I think it is simple the latest SHR-U kernel. I have been using it for a while, and wifi has been useable instead of dies randomly all the time, only comes up now and then. # uname -a Linux om-gta02 2.6.29-rc3 #1 PREEMPT Tue Sep 1 23:03:59 CEST 2009 armv4tl unknown It is definitely not built by me. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Thanks for good work on the WIFI driver
Michal Brzozowski wrote: does the wifi antenna keep eating power while suspended or does it turn off? I have no way of measuring that. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Thanks for good work on the WIFI driver
Christ van Willegen wrote:
Helge,
On Wed, Oct 14, 2009 at 1:29 PM, Helge Hafting helge.haft...@hist.no wrote:
Wifi used to be very unstable and quirky, but is much improved now.
I agree!
I can now run a script that powers up wifi, loads the kernel
driver module, and then runs wpa-supplicant and udhcpc. And it
works - everytime!
Could you share this script with us? Or put it on the WIki?
Here is the script. Made so it will work from /etc/init.d/
#!/bin/sh
#Start wireless using wpa_supplicant and udhcpc
#
#Contains a sleep, not meant to be run as a starupt script.
#works great interactively, or from SHR settings
PATH=/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin
case $1 in
start)
#Get rid of any old daemons:
killall wpa_supplicant
killall udhcpc
echo Power up!
#Power up WIFI, in case it is off
mdbus -s org.freesmartphone.odeviced \
/org/freesmartphone/Device/PowerControl/WiFi \
org.freesmartphone.Device.PowerControl.SetPower 1
#Work around bugs:
echo Reload!
#The driver is borked after suspend, so
#reload it:
#(not sure if this step is still necessary,
#it definitely was before.)
rmmod ar6000 ; modprobe ar6000 ; sleep 2
#Run wpa_supplicant, it will look for known networks
#and associate to one of them. You need your own
#/etc/wpa_supplicant/wpa_supplicant.conf
echo Starting wpa_supplicant
wpa_supplicant -i eth0 -Dwext \
-c/etc/wpa_supplicant/wpa_supplicant.conf
#give it a little time (no ifplugd yet)
#My phone needs 12-14 seconds before it associates.
sleep 20
#Attempt dhcp
udhcpc eth0
;;
stop)
killall udhcpc
killall wpa_supplicant
#Save power by turning the interface off
ifconfig eth0 down
rmmod ar6000
#Power down the hardware too:
mdbus -s org.freesmartphone.odeviced \
/org/freesmartphone/Device/PowerControl/WiFi \
org.freesmartphone.Device.PowerControl.SetPower 0
;;
restart)
$0 start
;;
*)
echo Usage: /etc/init.d/wpa {start|stop|restart}
exit 1
;;
esac
exit 0
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-Fix in switzerland
Petr Vanek wrote: [...] As mentioned previously, we would test on one piece first, confirm, then we would run the test script on all three pieces done. BTW, you can see how he has done the buzz fix for us (sleek design in placing the cap) and has taken a few shots on his work photo microscope: http://vanous.penguin.cz/files/om/SOP/ Assuming this works out well - what fixes are you going to offer? All 3 (buzz, #1024, bass)? Or the first two? Will it be possible to send in a phone from Norway? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Thanks for good work on the WIFI driver
Wifi used to be very unstable and quirky, but is much improved now. (I use the latest shr-unstable kernel) I can now run a script that powers up wifi, loads the kernel driver module, and then runs wpa-supplicant and udhcpc. And it works - everytime! I can even suspend and resume, and wpa-supplicant keeps managing the connection after resume. I had to restart udhcpc, but that is of course not a driver problem. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps 0.9.7 release
Joseph Reeves wrote: You may instead always have the track logging switched on - so you will always have all information. And maybe in twenty years time it is funny to see where you were ;) And, of course, there's no harm in uploading a track to OSM even if someone has been there before Actually, I got a mail once telling me not to do that. Seems there were limited room on servers, and too much of my tracks were known stuff. So now I only edit with josm, I don't upload tracks. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner in real world
Michael Pilgermann wrote: Dear all, last weekend I went for a small cycling tour and I thought, with gps in my Freerunner and track load capabilities of tangogps there is no need anymore for physical maps - I took the Freerunner with me. I was really impressed, how smoothly the whole thing was working. No problems with the GPS; no problems with tangogps either. However, two small problems: - I could not attach the phone properly to my bike; had to put it in a front bag and this was somehow a pain; I bought a generic phone holder for cars. They are adjustable to fit many phones, so you can find one that fits the FR. It wasn't that hard to attach the holder to the bike. It was meant to be glued to the car window, I glued it to the gearshifter cover on the bike. And secured it with cable ties, in case the glue doesn't hold. - The power capacity was just enough to bring me from A to B; another (longer) trip might result in troubles / me getting lost :( If you can't find a battery, get a generic USB power supply. The FR is fortunately not the only phone that is charged via USB. So there are many generic USB chargers around. I would not be surprised if you can find one that contains plain AA batteries. Such devices certainly exists for nokia and ericsson phones. You can save power by letting the display turn off - just tap it when you actually need to see the map. Lower backlight intensity at night also saves power. So my question: has anybody got any experiences with - attaching a Freerunner to a bike (maybe even incl. sun protection) The sun is tricky - polarized sunglasses may remove reflected light though. The same problem exists in boats, have a look at sun covers for boat instruments. Might need some work though. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Device Orientation API
Michael 'Mickey' Lauer wrote: Hi folks, I'm sketching a simple device orientation API for FSO. The purpose is to be informed about changes in the physical device orientation. My first take is at http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Device.Orientation.html;hb=HEAD Basically, it's sending you a string whenever the orientation changes. Valid substrings contain portrait, landscape, faceup, facedown. Good idea. I assume orientation changes is only reported to apps that actually ask for them? So that the accelerometers can be turned off to save power whenever no apps happen to be interested. And of course, apps that can't use the information shouldn't need to use the cpu time either. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR] Default routes - gprs have priority over usb :-(
I like to have gprs connected. (auto-download map tiles on the road, possibly also agps) But gprs is slow and may cost, so I want usb networking to take precedence when possible. And wifi over that, when it is available. Now, wifi takes precedence over usb, because the default route for usb networking has metric 8. And the wifi default route has no penalty at all. But it looks like gprs also don't have a penalty, so it is preferred over USB. I can work around by shutting down gprs, but that is inconvenient. Is there a simple way to permanently give the gprs route a metric of more than 8? Looks like this has to be done in the route command, but I have not found where gprs actually sets its default route. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Nokia N900
yangm wrote: I agree, I think Nokia don't care the driver code is open or close, because it's not the value of nokia, Maybe it's chipset productor's value. Maybe the operator required. Anyway, if you don't plan update update the drvier, you need not care it. I may very well want to upgrade the *kernel*. With that, I need every driver as well. If they aren't provided because they aren't open and Nokia didn't bother with some new kernel release . . . :-( Ordinary users gets this sort of problem too, merely some time later than the power users. Want this interesting piece of software? It needs some new ALSA functionality of 2.6.3x. Plenty of people might be interesting in making that kernel. Some will even package it in some user-friendly package management system. But they can't - because of proprietary concerns. And so the end-user misses opportunities. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: udev rule for the freerunner or make usb networking enduser friendly
Radek Polak wrote: Laszlo KREKACS wrote: I would like to use my freerunner in a plugplay mode. Just attach to the computer, and simply ssh in using terminal or nautilus. You have to setup dhcp server on your freerunner. E.g. on debian: Seems like a lot of effort, I find it easier to set up static 192.168.0.200 for eth1 on the computer. This avoids running a dhcp server on the rather limited phone. Still, the dhcp server may be easier if you regularly connect to many different computers. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all] Don't answer a call by turning FR upside down..
Risto H. Kurppa wrote: [...] If the phone is not upside down, alert as predefined. Continue sniffing: if the phone is turned upside down, go silent, stop vibra. And reject the call too, I guess? Possibly but I wouldn't do that - to the caller it's like I don't want to talk with him instead of not available.. (compare it to action when the phone's in silent mode) If I turn the phone upside down while it rings, then surely I meant to reject the call. I.e. I want the sound to stop, and not by picking up. Very similiar to reject. The nice thing about reject is that you don't waste the other persons time. If you just let the phone ring, perhaps with the sound off, then they will be waiting hoping that you eventually pick it up. Well, perhaps we want that when the call is IDed as a telemarketer . . . Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Freerunner Owner wants to help out!
Alex Teiche wrote: Hello Everyone, I have had my Freerunner for 2-3 Months now(A6 no buzzfix), and I feel like I finally have the time to help out:) I sent an email a while ago asking about peoples recommendations for developing a new chat app, but I never found the time to get started. I am 100% self taught, but I consider myself proficient in Python and most C. I have done quite a bit of work with embedded electronics(Mostly AVRs and ARM7s, and some FPGA stuff), but definately not enough to be of much help on the GTA02-Core project. Can you guys recommend the best way for me to help out? I would love to learn about and work on the kernel level, but I know next to nothing regarding this. Can you suggest a way that I could learn short of asking a lot of dumb questions on IRC?:P If you want to learn to work on the kernel, there is the linux-kernel mailing list. Have a look at the archives, to see what that is like. There are various driver problems on the FR, for which help would be useful. Such as failure to set up the screen right when resuming with the screen rotated. The kernel is all C. Coordinating effort with other Fr kernel developers would be a good idea. I have written some of my own things with Python and Elementary, which projects need the most help/what important applications are we lacking the most? If you decide to work on apps instead, consider this: What do you yourself want on the phone? Do you miss functionality in some existing app? You can fix that. Something that looks ugly or is unnecessary cumbersome? Fix that. Is there an existing linux app you would like to see on the FR, something currently only available for PCs? Port it. The point of working on something you will want to use, is that you won't get tired of it. Also, you will be a competent tester, so the implementation will be good. People making features they don't use themselves, sometimes make quirky stuff that needs further fixing. Still, better than nothing, of course. The SHR project (and others too I guess) have bug databases. There you can find bugs to fix, and wishlists of features to implement. Some old ones: * Support for long SMS. (Implemented by chaining several short messages.) Currently, the FR receives a long message as several _unrelated_ short messages - not ideal. And of course long messages cannot be written at all. * Support for receiving MMS. When you get a MMS, the phone first gets a SMS with an WAP URL for the content. (Picture, or perhaps a ringtone or something.) The FR can open a GPRS internet connection, but it there is currently no software for actually fetching the image/ringtone/whatever. That'd be nice to have. Others now and then send images to FR owners, not knowing that it isn't implemented. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner wireless internet
Rui Miguel Silva Seabra wrote: On Wed, Aug 26, 2009 at 01:19:52PM +0200, Helge Hafting wrote: 1. The wireless does not work after the phone wakes from suspend. [...] Just this morning, with SHR 2009/08/08: 1. resume 2. enable wifi in shr-settings 3. use mofi to connect 4. profit Could it be that mofi uses some of the workarounds? Possible, or maybe you got lucky. Bugs are not always reliable. The problems I see does not have to happen on every suspend/resume cycle. They merely happens often enough to be a nuicance. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all] Don't answer a call by turning FR upside down..
Risto H. Kurppa wrote: Hi! There's been this rumor about using accelerometers of Freerunner to ignore a call around. At the moment there are no useful applications for gestures, only (great!) games: mokomaze, doom etc. Someone wrote the framework for gestures but it's not been actually integrated in any(?) distro. From what I heard the issue is that reading accelerometers is very CPU-intensive. Phone (framework, something?) sees a call coming in It starts to sniff the accelerometers If the phone is already upside down (on a table), don't alert (or maybe with vibra or something) Can you check that is is exactly upside down, and ring anyway if it is a few degrees or more off from completely flat? People put phones is pockets. Women put them in handbags, even. So the phone may end up upside-down, but rarely completely flat. If the phone is not upside down, alert as predefined. Continue sniffing: if the phone is turned upside down, go silent, stop vibra. And reject the call too, I guess? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Free runner opened up
Ben Wilson wrote: I dunno about the freerunner but with gta01 it shipped with a guitar pick to be used to pry the case open without damaging the plastic :) The freerunner is easy enough to open with a fingernail. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner wireless internet
Juan Lucas Dominguez Rubio wrote: Hello, list: has anyone ever accessed the internet via wifi from the Freerunner? If so, which distro was it? Does it work only with some particular (few?) routers? I have done it, with SHR. There are a few quirks. work around them, and it is no worse than any other linux distro. The quirks I have seen: 1. The wireless does not work after the phone wakes from suspend. And I don't mean it lost the association, wifi cannot be brought up at all. Very irritating, for wpa_supplicant can re-associate automatically _if_ the chip driver itself works. Workaround: unload the ar6000 module and reload it. Then it works as usual. The problem is, it has to be done manually and the phone is almost always sleeping (as it should), so this workaround has to be done all the time. which is why I don't normally use wifi. :-( Considering that the workaround is so simple, fixing the kernel should be simple too. Drivers have hooks for suspend/resume. So just make the resume handler do exactly the same initialization as when the module is loaded. wpa_supplicant can then do the rest, any association will be lost anyway after a long sleep. 2. When the module is freshly loaded, setting the essid is unsupported until an encryption key has been set. (iwconfig returns with an error message if I try setting the essid first.) This probably cause trouble for any sw that tries to set the essid first. My workaround is to set the encryption key first. The simplest (but not necessarily the best) kernel fix would be to have driver initialization explicitly set some key as the last step. Then users wouldn't have to. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all / linux] neo as gps unit?
Olivier Migeot wrote: On Fri, Aug 21, 2009 at 4:44 PM, Helge Haftinghelge.haft...@hist.no wrote: Could that be the default configuration? That would also listen on ppp0. Which could be problematic if - dunno if many operators do that - its IP is directly reachable from the Wild (i.e. anybody could be able to know where you are... ). That is something I can prevent if I want to. (Have iptables block incoming SYN+ACK packets on ppp0) Or perhaps I want some friends to be able to see this. However, I don't think there are any operators that do this. IP addresses are expensive, so they surely don't want to hand them out to phones - almost none of the net surfing phones can run any server software anyway. The FR can, and perhaps you can hack it on a few others. The rest merely runs browsers... To check: open one of those webpages that show you your own IP address. Then try shh to that address. I cannot imagine this working... Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: One second Openmoko boot?
Michael 'Mickey' Lauer wrote: On Friday 21 August 2009 06:21:52 Wolfgang Spraul wrote: Not really. Reloading (in the worst case) 128MB from an SD is not exactly fast either. The only sane way to substantially improve booting time is to stop booting like a desktop PC, that is move away from starting all services just because you can. Start them on demand and bring only the bare necessities up on boot (filesystems, dbus, X). Not sure. What I have seen working usually required much more aggressize optimization, all the way into hardware. Of course. I have been referring to the FreeRunner though, i.e. what can we do on already existing hardware with pure software. No doubt that hardware, especially considering this right from the start, makes a much more substantial difference. The FR wakes up fast enough from sleep. (suspend-to-RAM) Now, implement suspend-to-disk (SD-card), and you can start reasonably quick after changing the battery. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all / linux] neo as gps unit?
Patryk Benderz wrote: [cut] DAEMON_OPTS=-S localhost:gpsd -P $PIDFILE r...@om-gta02 ~ $ fso-gpsd -? [...] -S integer (default 2947) Set port for daemon [...] so you could provide just -S gpsd so daemon listen an all IPs... Could that be the default configuration? A laptop display is bigger, which is convenient for looking at maps. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all / linux] neo as gps unit?
jeremy jozwik wrote: morning all. i was just sitting here on my debian laptop, poking around with tango gps. now my laptop does not have any sort of gps so i get the no gps found deal at the bottom. that got me thinking, has anyone setup there freerunner to act as a gps device for there laptops? if so, is there a wiki about it? if not, is it possible to do? It is simple, because sharing a gps unit over the network is an old feature of linux. The freerunner makes its gps available on port 2947. So, just connect your laptop and phone. If you use the usb cable, the phone will have ip address 192.168.0.202 Set up your laptop gps software to use the gps unit at 192.168.0.202:2947, instead of the default localhost:2947. It worked well last time I tried it. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reading binary messages
Sebastian Krzyszkowiak wrote: On 8/4/09, Brock awwa...@thelackthereof.org wrote: this actually difficult or is it a matter of nobody having the time / care to do it? I think noone cares. I don't need MMS at all, Yes, we care. I don't send MMS myself, but others send me pictures occationally - it'd sure be nice to see them on the excellent display... Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing Litephone, new phone interface
Michal Brzozowski wrote: 2009/8/3 Helge Hafting helge.haft...@hist.no mailto:helge.haft...@hist.no Michal Brzozowski wrote: Litephone beta1 is available here: http://pvtrace.com/litephone/litephone_0.0.1-r2_armv4t.ipk Beta impressions: * When the phone rings, please have litephone jump to the foreground. Currently, I have to wade through several other running apps in order to pick up the phone. I was wondering when someone brings this up :-). Actually I don't like the idea of poping up the phone window when the user is doing something. Normally, I am very much against popups, because they interrupt other work. A ringing phone is different. It is already an interruption, and one that has to be handled in real-time too. If I don't want to answer, I still want to reject the call. So I need some sort of UI when it rings, and it had better not be cumbersome just because some other app was on top. Of course, a popup is not the only way. I have been thinking that since this is a _phone_, then perhaps the AUX button should pick up the phone whenever it rings, and hang up whenever there is a call in progress. That would get rid of many problems. In particular, one doesn't even have to look at the screen at all. Other popular uses for AUX could still work - when there isn't a call in progress. It is not as if I tend to lock the screen while talking... I have a plan to show a little xshape gadget on the bottom of the screen on incoming call or sms. On call it would probably show accept/reject/mute buttons, the first one additonally bringing up the phone window on click. On sms it would display the content in a one line pager style, and have show/hide message buttons. I wonder what you think about this idea :-) That seems ok too. * Deleting a message (up-to-date SHR unstable) gives a screenful of error messages. But the message was deleted. Yes, although I think deleting did work for a while. Here's the error (for Sebastian :-)): http://pvtrace.com/litephone/delete_errors.txt The message was probably not deleted, you will notice on restarting litephone (it just deleted it from cache) I noticed it showed up in shr messages. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps : updating tiles ?
Rask Ingemann Lambertsen wrote: On Tue, Jul 28, 2009 at 06:06:55PM +0200, Helge Hafting wrote: Go to their website - read their policy. tile.openstreetmap.org is not to be used for bulk downloads. URL? http://wiki.openstreetmap.org/index.php/Tile_usage_policy I can understand this, they probably have a bandwith problem. Although you'd think that if they were trying to save bandwidth, they'd support the If-Modified-Since HTTP header which has had wide spread server and client support for what, more than ten years. Find another repository that don't have such limitations. Again, URL? That is exactly the problem! There are many online maps, but few tile servers around. tah.openstreetmap.org lets you download all you want, but it does not support md5sums so you cannot use yaouh. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing Litephone, new phone interface
Michal Brzozowski wrote: Litephone beta1 is available here: http://pvtrace.com/litephone/litephone_0.0.1-r2_armv4t.ipk Beta impressions: * When the phone rings, please have litephone jump to the foreground. Currently, I have to wade through several other running apps in order to pick up the phone. Also, if some other program were in the foreground, remember that. Litephone should then reinstate the previous foreground app when the call ends. This is what you want if you use the phone as a gps map display, or play some game. You want to pick up the phone, but when you hang up, you want to continue with whatever you were doing. * Similiar for SMS. Bring litephone to the foreground, if necessary. If the user just close/delete the message, then reinstate the previous foreground app. (But if the user do anything else in litephone, assume he/she wants to keep litephone in the foreground from now on. We don't want to do all sorts of work and suddenly have litephone disappear upon deleting the particular message that trigged the jump to the foreground. :-) * Deleting a message (up-to-date SHR unstable) gives a screenful of error messages. But the message was deleted. * When I answer the phone, it rings and vibrates for a while after I pressed answer, before the call comes through. That is annoying. I don't know if this can be improved in litephone, or if the problem is in the framework or something. * The contact list has a second column, with 8 names. This allows quick jumping through the list to various positions. Excellent! * Strange SMS view. Before, I could see who sent the message, and the first part of the text. And often enough, the first part is all I need to see. Some messages are short, just call me and such. Now, I see who sent the message, and a strange number. (database key???) This number is not useful, please bring back the text snippet. * Really long messages support scrolling. This is better than SHR. :-) * When the user closes litephone, consider informing that no further calls or SMS will be received. This may not be obvious to all users, and phone functionality is an important part of the device. Still, if you make such a dialog, also add the don't show this warning again button for the expert users. I might add this to the wiki - when/if the email address confirmation comes through. :-/ Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing Litephone, new phone interface
KaZeR wrote: [...] I believe that the style_sheet part isn't needed anymore, and instead you can use other parameters (like demo, etc). I simply ran litephone, in my case and it worked. Thanks, that worked. My impressions after testing a bit: * Looks good, is responsive * The contact list doesn't have finger scrolling. It jumps when I select a message close to the bottom though. Finger scrolling is even easier. Just put the finger on the screen and drag up or down as necessary. * Calling and receiving works, but is fragile. Once, litephone didn't notice that the other end hung up. The call was terminated, and when the other side called back, litephone still was stuck with the screen for the previous call. I could not reproduce this though, further calls worked as expected. * Entering unicode text into a message doesn't work, I get garbage text instead. Strange, because stored unicode messages show up fine in the viewer. Most of the world uses more than ascii. The shr messaging app has no problems with this. * There seems to be no way to forward a message to others. Shr messaging also lack this, you have the chance to be first. :-) * Messages cannot be deleted. (Not implemented yet?) Please note that the inbox can accumulate lots of messages quickly. Deleting one-by-one is fine for deleting a few messages, but cumbersome for many. This is a typical problem with many phones - click once to select, click once to delete, then wait as deletion happens, then click to select, click to delete, wait ... Still - you're better than shr with its 3-click deletion. Mass deletion is very useful. One way is to have a little checkbox at the end of each message in the list. One can then check several messages quickly, and hit delete to get rid of them all. This way, the user don't have to wait for each deletion. If deleting 50 messages is slow, then the user simply pockets the phone or play a game while waiting. :-) === Crashes: I tried to save my changes to a contact, and litephone died. (The contact name contained parentheses, I hope that didn't crash it.) Restarting it worked. After sending myself some messages, litephone crashed and can no longer be started on my phone. I get: INFO: refresh msgs FATAL: main.cpp: 236 : void PhoneWindow::refreshMessages(): check failed: messages.getRow(i).getValue(Content, content): Deleting the messages through shr-messages did not help. I'll try again when there is an updated version. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing Litephone, new phone interface
Michal Brzozowski wrote: Hi, I gave it a try and wrote an FSO based phone app in Qt. It's using the new PIM service, and since that's not completely stable yet, there are a few problems. I'm releasing this anyway, to help test FSO, and meanwhile get some feedback on the gui and general idea. Consider it an alpha release. There might be little bugs here and there. I installed on shr-unstable, killed ophonekitd, ran the registration script and started litephone like this: $ litephone style_sheet.conf This resulted in tons of error messages. Lots of these: QDBusArgument: write from a read-only object Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged And it ended with these messages: QDBusArgument: write from a read-only object QDBusArgument: write from a read-only object INFO: New dbus call: org.freesmartphone.opimd /org/freesmartphone/PIM/Messages/Queries/2 org.freesmartphone.PIM.MessageQuery GetResult; Using **pending_return in dbus_connection_send_with_reply_setup() without pending_setup is deprecated and strongly discouraged QDBusArgument: write from a read-only object QDBusArgument: write from a read-only object INFO: before 19 FATAL: data.cpp: 76 : void Data::sort(const QString, bool): check failed: row.getValue(column, value): It did not get to the GUI. The basic idea on the GUI is that it is packed in one window, the various 'modules' (contacts, messages, dialer, etc) placed into tabs. No popup windows. I like the idea, and the screenshots looked fine too. A phone app that runs all the time can respond quicker. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tangogps : updating tiles ?
William Kenworthy wrote: Is there any advantage (to the server) of using curl? - is there a reason why openstreetmap would ban one and not the other (or is it just someone(s) using wget beating up their server? Go to their website - read their policy. tile.openstreetmap.org is not to be used for bulk downloads. I can understand this, they probably have a bandwith problem. This rules out any app that actually do bulk downloading, they detect and block as needed. Find another repository that don't have such limitations. Changing the user agent string will work - for a little while. Then the new string goes on the block list - or perhaps your IP address. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: touchpad on OM
Michal Brzozowski wrote: Hi, I'm not sure if anyone has ever tried this. I thought it would be handy to have a mouse pointer on the phone, driven by a touchpad area in the lower part of the screen. To click you just hit an appropriate button. This way you can do left click, right click, and any other mouse buttons you want. It should be useful for apps unsuited for finger use. Here's a graphical explanation: http://pvtrace.com/moko-touchpad.png Why have that touchpad area??? I understand why you have the L and R buttons. It allows right and left clicks, which is nice. But why waste area on a touchpad ? Just enable the X mouse pointer - which is easy enough. The touchscreen _is_ a touchpad already, so no need for a separate pad. Then you can put the L and R buttons at the bottom of the screen, and have much more room for the app itself on the screen. Or am I missing something? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Anti-Whining: Happy Moko Moments
Warren Baird wrote: I like to try turning that around and start a thread for people to talk about their successes. Maybe if we get enough good ones we can push it onto the wiki. It is a nice gps device, with its high-resolution screen. Good for OSM mapping, good for having a map display in the car, powered from a generic USB car charger. Also a nice gps to have on the bicycle. When I want a larger map display, I use a laptop, and lets the pc use the freerunner's gps via usb networking and the gpsd protocol. And it is a nice phone too, of course. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Sms-sentry patch : call me back
Petr Vanek wrote: You register a known sim with SMS-sentry and if it gets changed the phone sends it's location to a predefined number. Ha ! Neat solution to the problem. Hope you add that soon. great! it would make sense to have more SMS on the list so when testing and swapping SIMs we don't send out too many SMS. Also, if at that moment of SIM swap there is no GSM signal, the SMS sending will fail, or not? It will fail, the FR does not seem to queue up unsent SMS. It certainly fail for sms sent through the sms app at a time of bad gsm coverage. But sms-sentry can be coded to send a new sms every 5 min or so, until you recover the stolen phone and reconfigure it. :-) Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all] call for configurations
William Kenworthy wrote: Two reasons - here in Australia using a prepaid card you can run up a huge bill making test calls. Is making testcalls _to_ the phone expensive too? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-unstable] phone profile
Joshua Judson Rosen wrote: jeremy jozwik jerjoz.for...@gmail.com writes: is there a config file that i can alter to make my shr-settings phone profiles stay put even after a shutdown? it i set to vibrate, shutdown and turn on at a later time phone settings will always default back to default Isn't that why it's called default? Default is what you get after flashing. default is what you get when you don't customize. And that is fine. The phone is not supposed to revert back to default just because the user boots it. If you make _changes_, they should stick! Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Background amplification and voice blur on phone call
Shashank Bharadwaj wrote: Hi list, I created a new topic cause I think this question is slightly different from the one being discussed in the Rustling noise on phonecalls thread. Well I just installed OM2009 (and updated via opkg update opkg upgrade) and then tested on paroli on a call. Weird thing happened. The background sounds (like of the traffic, keyboard strokes or somebody else far off talking) are highly amplified. But my own voice is highly marred with noise. My voice sounds like it's being mixed by a dj to produce a kind of recursive-echo effect! Any ideas? Too much microphone gain explains all of this. That's why background noise gets amplified too much. Your voice may get too loud and ruined by saturation. If your voice comes back through the loudspeaker (or a nearby test-phone's loudspeaker) then the overly sensitive mic pics it up again and you get echoes too. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Hello world. Is the Neo Freerunner dead?
li...@kitepilot.com wrote: THANKS! :) I did read it: It says the the successor of the the Freerunner is canceled, but what about the Freerunner itself? Is it still in production? They are for sale still. and while HW development has stopped, software is still being developed for it. If alive, can the Freerunner be used reliably for business on a day to day basis? Under what system? I use the freerunner as my daily mobile phone, using the SHR unstable software. The phone and gps parts works flawlessly. I have some problems with wifi, but that can be solved by installing a different linux kernel. Will it talk to the ATT's US network? Assuming that is a GSM network. There certainly are other americans using the freerunner. What do I tell them? ATT? Tell them you have a gsm phone and need a SIM card from them. The Developers only ubiquitous tag seems to suggest that it may not just work. Or does it? If I can reliable place and receive calls, attach a REAL keyboard to it, and open an SSH shell to my server, I want one! :) You can attach a real USB keyboard to it - sure. Connect to a network using wifi or gprs, and then you can indeed use ssh to your server too. Most of the reason for developer phone is that it doesn't all work out of the box: * The phone comes with very old software, the first thing you want to do is to upgrade to a modern linux distribution. There are several to choose from. Flashing isn't that hard, but is not for _everybody_. * You can attach any USB device that linux supports. This is a lot, and definitely includes keyboards. However, you may have to change some settings to turn the phone into a usb host instead of being the usb device it usually is. Some distributions makes this easier than others. You may also need a powered hub - I believe the phone won't provide power to your keyboard. Alternatively, make a cable that can power both the phone and the keyboard at the same time. Don't think you can buy those anywhere, but there is documentation. ssh is standard software, included in most distributions. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: External GPS antenna question
Tomasz Suchan wrote: Hi Armin, I use the atenna for GPS Tracking during biking and car tours. As the FR is always running (no sleep) and with activated GPS module - the battery last about 4h - then it's empty. Is accuracy much better with external antenna? If the external antenna can be placed in a better location than the internal one - or if it gets better signal strength. An external antenna on the car roof may see more satellites than the FR sitting on the dashboard, because that metal roof block radio transmission. Now, the FR will see many satellites even inside a car, but those signals cannot penetrate directly through the roof. Some satellites will be seen directly through windows. Signals from the rest may bounce off the hood and come in through windows, or diffract (bend) around the roof edge. Such redirected signals are weaker, and they give greater position error. The latter because they really give the position where your FR would have been, _if_ the signal had not been diffracted or reflected. The GPS receiver is smart, and will discard data from satellites that seem to disagree with the rest. But there are two problems with this: * An extra satellite that gets discarded no longer helps improving accuracy. * If two groups of satellites seems to disagree on position, then the receiver could lock onto the wrong group for a while. An external antenna see all the satellites directly, and don't suffer such problems. Unless you are near tall buildings or mountainsides, which cause the same kind of problems. So an external antenna is great if you have a roof above you. Such as in a car or boat. The problems above don't happen on a bike. Still, an external antenna might help, it may be bigger/better than the internal antenna and get more from a weak signal. For example, if you move around in heavy rain in a forest. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
kimaidou wrote: Hum... speaking as a OpenStreetMap user, it would be great to merge the functionalities of omgsp with those of a tool like http://wiki.openmoko.org/wiki/Mokomapper meaning big buttons (9 per full-screen) allowing to store preset OSM data such as shop=bakery, highway=residential, amenity=pub, etc.. and be able to export directly in osm format. Nice idea. And if I export GPX instead of OSM, include all that pub/bakery/... stuff as comments. (The gpx format support comments) These comments then show up in JOSM - very useful. I usually add detail (housenumbers etc.) to areas that are already well mapped, so making OSM directly won't work for me. The road is already there, for example. GPX comments makes it easy to add only the stuff that is new. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [omgps] collect feature requests
Marcel wrote: Am Dienstag, 30. Juni 2009 13:48:05 schrieb Patryk Benderz: make it track-friendly for OSM map and JOMS application. Please feel free to comment or add new feature requests here. Feature request: add support for vector/binary maps. That would be really nice. Problem might be the low render speed for vector maps though which navit suffers from... Maybe there are ways to speed it up? For the freerunner, make sure you do all tour drawing calculations with integer math only. No floating point coordinates. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: which gps app can do this?
lanzo wrote: Hi! I'd like to be using my FR on my little boat as marine GPS. I was curious if, in your opinion, it could be possible to constantly show the distance between me and the nearest point on the coast line. This would be important because in my country (and i guess everywhere) there are rules about the little boats distances from the coast and I cannot overcome 3 nautical miles. If this is a safety feture, take care to use map data that is sufficiently accurate for your use. Also, the freerunner is not built to withstand salt water, so make sure it won't get wet. I know it should be possible to show the distances between my present position and any given point, but what about something always displaying the distances between my position and the nearest point on the coast? I don't know any such app, the use seems a bit special to me. So you may have to use an existing app, and add code to it for your use. An approach using navit - requires programming: I guess navit is a good choice. It has maps in vector format, including coastline. So you could add some code that periodically checks that at least some coast points are within 3 nautical miles. An approach using tangogps - no programming at all: Tangogps performs better than navit on the freerunner, it is faster. Tangogps uses a map made from png tiles. So there is no way to find the distance to the coast. However, you can make your own map (based on openstreetmap tiles) that includes the 3 mile border. You could have a line in the water, or color the forbidden regions differently. Then, you simply look at the map display now and then to check that you are within the allowed zone. The absolutely simplest way is to edit the png tiles with an image editor, and just draw the border line/area yourself. Openstreetmap has the information you need about scale. (How big regions the tiles cover.) This way require no programming at all, you just draw the (rough) limits onto the existing map. The tiles are small - you might have to edit lots of them depending on what zoom level and how big an area you need maps for. Better approach for tangogps - requires some software and configuration: A more elegant way is to render the tiles for your region yourself. openstreetmap.org has information on how you download software to do this. It is some one-time work downloading and installing the software. After that, you need to modify the rules for rendering, so that allowed and disallowed water is rendered with different color. (Or a borderline 3 miles outside the coast). Then, run the software so it renders maps for your region. This approach has the advantage that you can update with new data from openstreetmap now and then, and have your map improve with time. Perhaps you won't need to do actual programming, but you will have to work with rendering rules (and install some software). is there maybe any more in-topic forum where i can ask this? Your question is definitely on-topic, because you are using a freerunner. Don't worry about that. :-) For detailed help, note that navit has a mailing list, and openstreetmap has several mailing lists/forums where they can help you with rendering questions and other tech stuff. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is a FreeRunner sufficient for me?
Brolin Empey wrote: 1. Are there applications with all of the specific features I listed, though? My Nokia 6103b has some basic organiser applications, such as for calender and task lists, but it does not have all of the features I listed. Depends on what linux distro you choose to run. There are several. Some are optimized for running on the phone, but may or may not have all the features you want. Then there is debian and gentoo that have more apps than you could possibly install, but they are not made specifically for the phone. You can test these distros on a PC, in order to test the software. If you want to try freerunner-specific software before buying, set up phone emulation with vmware or similiar virtualization software. The simulated phone will be slow, but you can at least test app features this way. I can live without PC sync as long as my information is safe in my FreeRunner (stored in non-volatile memory in case the battery dies). I have never lost data, my experience is that everything is stored in non-volatile memory. The internal flash memory, or the microSD card. 2. Is the FreeRunner’s display readable without a backlight? My Nokia 6103b’s display has a backlight, but the backlight turns off after a few seconds of inactivity. I do not find it readable without a backlight, but you can set the backlight timeout as long as you like. So if you want a few minutes, you can have that! 3. I leave my Nokia 6103b on for about 16 hours or less per day. I do not use it for most of that time. When I do use it, it is usually for SMS or organiser applications, not for voice calls. Will the FreeRunner’s battery life be OK for my usage? When not in use, the phone suspends automatically and uses very little power. It wakes up automatically if a call or sms comes in - or if you touch the power button. It should wake up in under 2s, at least with the SHR distro. To be on the safe side, I charge the phone every day. this is not as necessary as it used to be - suspending didn't work well in the beginning but this is fine now. It will not last 16 hours if you don't let it suspend though - for example if you do gps logging all the time. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why one cannot recommend the freerunner as a daily phone (was Re: Is a FreeRunner sufficient for me?)
mobi phil wrote: no offense, but thinkin only about yourself, what you want, is probably the cause nr. one for openmoko company/project failing. If you want a company to sponsor the development of the project, they need to have benefit. They can generate benefit by selling devices. But if you fail to put on the device minimal usability only a small amount of the potential customers will consider buying the device. By providing a bit more usability openmoko would have been able to sell more phones. Lot of IT friends laughed at me when I tried to show them the phone... actually I could show nothing. If I was able to show a bit more... these guys would have probably considered buying the phone etc... If you want to show off, install some apps. For game players: Linball and mokomaze looks good. Tangogps with some maps, and one of the audio players. Set up wifi and surf the web on the 640x480 screen, which really is better than the 320x240 or so found on many other phones. And then stuff that is hard to do on other phones because they don't have linux. ssh into some other machine, for example. Or in a windows-only place, show how you can log onto the file server directly and browse your files. Because the thing is a computer too. Look at images and documents. Developing only for your own satisfaction and thinking zero about giving back as usability helps less than zero! Many developers develop only for their own satisfaction - but happily share the stuff. And this helps, for generally, lots of people wants the same stuff. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2009] airplane mode
jeremy jozwik wrote: window seat makes no difference : ) in fact for several minuets i was holding my freerunner against the window and got nothing... My experience is that a window seat is necessary. If I have a fix, I loose it by moving the phone half a meter away from the window. So it almost have to touch the glass all the time. To get the fix quickly, aquire a good fix outside the plane shortly before you board it. Then, stop the gps software. It will save satellite ephemeris information so it can be reused when you're inside the plane. Without this, ephemeris has to be downloaded from the satellites before the first fix - but downloading requires better signal quality than merely tracking. You may or may not get the better quality signal inside the plane. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [OM2009] airplane mode
Petr Vanek wrote: - FSO is quite unable to get a fix while in 1m altitude and (or) high speed. it sees the satelites, get's a fix and then for some reason something happens and no satelite is being seen anymore. this will repeat fo as long as you leave it. Huh? My freerunner reported 10038 meters and 740 km/h last saturday. I got the first fix at about 9km height, and tracked the plane as it went up. Then i had to stop due to the battery running out. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tango and the missing map tiles
Rask Ingemann Lambertsen wrote: On Thu, Jun 25, 2009 at 12:08:54PM +1200, Robin Paulson wrote: 2009/6/25 Tim Abell t...@timwise.co.uk: I've found that if tango doesn't have a working net connection available when you pan around it will generate empty files for the map images and then never attempt to re-download them leaving nasty gaps in your coverage. [snip} Feel free to stick this on the wiki or something. I don't know if this needs a bug report. IMHO it does. will yaouh perform a similar task? i assume even though they are blank, they will have a date and time, thus when yaouh is run, it will see they are old/the hash is wrong, and replace them? No, Yaouh! (version 0.5.1) doesn't update empty map tiles. Strange - the hash for an empty file will be wrong. Maybe yaouh gives up when nothing can be read from the file. In that case, consider making a script that copies some particular tile (or other png image) over any size=0 file. Yaouh will then notice the wrong hash and fix it. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: a new keyboard - discuss and critique
Robin Paulson wrote: apparently, triangular buttons produce less errors. http://www.reghardware.co.uk/2009/06/02/crocodile_keyboard/ i'm not totally convinced, but it would be worth a go, i think now, is it possible to coerce raster's keyboard into using anything other than square keys? Not sure if that is needed. The patented triangular keyboard reduces mis-typing by having unresponsive areas around each key. The same can be achieved by having unresponsive area around rectangular keys too. Easily done by making said rectangular keys smaller, without moving them closer together. Of course, the keys are already very small, so this is problematic. They could get harder to hit. But triangles have the same problem, although they may look cooler to some. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Power dongle
The Digital Pioneer wrote: Yeah, I'd kinda prefer one that's nigh unto infinitesimal and only lasts a few seconds, but I'll search for emergency phone chargers. I guess the market for 15s power supplies is too small for anyone to make a product. You may want to improvise something like this: * Get a usb connector that fits * Stack up enough button-size batteries to get between 4.0 and 5.0 volts * Cut most of the wire off that usb connector. Bare the two wires needed for power, and tape them to opposite sides of the stack of batteries. * More tape around everything, for electrical insulation. This is about as small as it gets. Probably over 15s of phone power, in a package not much bigger than the tiny batteries. Exact size depends on how good you are at cutting down the usb connector, and how small batteries you can find. When the batteries run out, get new ones and more tape. :-) Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Tangogps or navit with prepackaged Europe map
Laszlo KREKACS wrote: Dear List, Is anyone aware of any images, with prepacked maps with tangogps or navit? Im going to travel in the next days across Europe, and a gps device would be handy. I have a spare 2G uSD card. So some ready-made uSD image would be extremely cool. I only need the map and gps, no phone functionality is required. don't know any such package, but downloading maps for tangogps is easy enough: 1. connect the phone to the internet somehow. (wlan or usb) 2. start tangogps 3. zoom in on an area you want maps for, such as somewhere in Europe. Note that tangogps downloads and stores map tiles as you do this. 4. If you want detail maps for an area and don't want to move around a lot in the detail maps, just click the screen and download a few extra zoom levels. This is the way to get detail maps for an entire city, for example. Note that downloading detail maps for all of europe will simply be too much. So go for the places you actually will be going. Navit maps are much more compact, so all of europe is realistic on a large SDcard. Whether navit will perform fast enough on a FR is another problem. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: DON'T PANIC
Johny Tenfinger wrote: DON'T PANIC uBoot splashscreen If you are using SHR from microSD an Qi, you can use that bootsplash when whole system is booting just in just 2 steps: Is it necessary to boot off the microSD? I have SHR in the internal flash, as it fits nicely there. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [FSO/SHR] ogpsd/fso-gpsd: can't get 4Hz sample rate
Jozef Siska wrote: On Wed, May 13, 2009 at 04:58:20PM +0100, Vasco Névoa wrote: I've tried configuring (via frameworkd's om.py) the chip with a 3000ms period between samples, and sure enough gpspipe is outputting only one set of messages per every 3 seconds - so this proves my CFG-RATE message is correctly delivered. However, I also see that the gpspipe output is... chaotic. Although the NMEA timestamps are always correct (they skip 3 seconds), sometimes the messages are delayed and then delivered in batches. For example, there is nothing for 6 seconds, and both messages are delivered together. If I set the period to 5.25 seconds, I can see that all the timestamps coming out of gpspipe end with .00, which is obviously wrong. Many of the sentences are repeated, like the SW couldn't wait for the next UBX data block and just repeated the last data block. Who is doing this sample mangling? fso-gpsd creates new (fake) NMEA messages from data that it gets throug DBUS from frameworkd... My gues is that frameworkd would not send the data more often that once per second. Ouch. Having the framework _managing_ the gps (turn on/off, configure,...) is fine. But why regenerate the data, what is wrong with pass-through? The more cpu work, the more delays. And the gps may very well be used for real-time purposes. And of course, 100% of the cpu is not available, so it is hard to know how much extra work is too much. You could try uninstalling fso-gpsd, installing normal gpsd and somehow persuading frameworkd to not touch the gps (don't konw if setting the GPS to off is enough...) And the ideal fix would be framework support, so you just tell it you want 4HZ updates and from then on you get that. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Battery meter not reading battery life correctly
Adam Jimerson wrote: Has anyone noticed with the 05/02/2009 release of SHR-Testing that the battery meter is not reading correctly? While taking a hike and doing some OSM tracking I received a Low battery warning, thinking it was real I put an early stop to it so I could get it charging before the battery dies but a minute after I received that warning the battery life jumped back up to 92% and it was saying I had over 4 hours left. Has this happened to anyone before, and if so is it fixed in Unstable or does it need reported? There has always been trouble with battery readings. Illume has a battery warning of its own, which hangs around for a long time. I have often found that warning combined with an ok battery reading. Illume read the battery at a bad moment, and put up its annoying little box. Any battery-reading gadget will see the same problem, but it is not as noticeable without a dialog box. the place to fix this is probably the kernel driver that reports these oddities. There could be an error there. Or perhaps the hardware is flaky and occationally misreports status. In that case, the kernel driver should reject an abrubt drop in voltage unless it persists. I.e. report the last good value for a while until it can be sure that a drop isn't just a fluke. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Battery only charger
Christian Rüb wrote: Hi, does anyone know a good charger for the battery only? The wiki page about the battery [1] tells that you cannot charge the Freerunner battery in a Nokia phone or with original Nokia chargers. Does anyone know a working charger and a source where to get it (preferably in Germany). Has anyone tried the Nokia DT-14 [2] in any combination with or without success? Well, it is a lithium battery. Charging it wrong is bad, as lithium can explode and burn. But I have the impression that just about any charger made for lithium batteries of similiar capacity should work safely. A normal lithium charger should monitor the voltage and stop when the battery gets full. A charger made for much bigger batteries could charge too fast and be dangerous. You have to figure out the battery terminals, but that should be possible as FR schematics is available. There is a ground terminal, a terminal that the phone draws power from, and a third terminal that is used for charging. Make sure any charger you try to use is made for charging batteries only. Many phone chargers are cheap devices made for connecting to a phone, and the phone's electronics will limit charging for you. such a charger can not be used for a battery without a phone. If you can get your hands on one of those freerunners with a broken display, then that can be used as a charger too. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to use Google Map on tangoGPS
Fernando Martins wrote: Joseph Reeves wrote: I've found that it's very enjoyable to travel somewhere not on OSM and add it later ;-) SHR + TangoGPS seems stable enough, and kind enough on the battery, to let me walk around for a whole day (or rather, walk as much as I'd want to in a day) and log everywhere I go. How about quality of data, I mean, for instance if you have to backtrack in a road, will you have to delete the log and restart all over? How This is not how it works. You don't turn a tracklog directly into a OSM street, so this problem is avoided. 1. Walk around, with gps tracking on. 2. Using one of several possible apps, display the track on the PC, and download whatever OSM data there is for the region already. 3. So now you see some OSM data (if there were any) and your gps track on the screen. The next step then, is to draw roads using your track as a guideline. You will see where you backtracked, but you will of course draw that road only once. Your track will curve at intersections, but if you remember that the roads met at 90 degrees, then you draw them that way. 4. You also add any other information that you remember or wrote down. Such as street names, type of road, and so on. If you had several logs, then you just load all of them at the same time and draw more road lines. Essentially I'm trying to understand how burdensome (or not) it can become for a simple sightseeing to also do tracking. OSM mapping isn't complicated. You decide how much time you want to spend on it. You can draw just roads, roads with names, or even add all sorts of features like mailboxes, housenumbers, parks, parking lots... If drawing road lines becomes too much of a burden for you, just upload the traces to osm and hope that someone else will use them for drawing. A problem with this approach is that others won't know how the track was recorded, so they might make a wrong road where you crossed a lawn and things like that. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko and LCD TV
roby wrote: sorry for continuing the ot, but.. i always dreamt of a tv adblocker, anybody know of some project in this direction? The easy way is to get a harddisk recorder/receiver, capable of pausing tv. When your movie/show/sport event begins, just pause it. Then, wait about as long as a commercial breaks usually is, before resuming and watching the movie slightly timeshifted. When an ad comes, just fast-forward past it. :-) An additional advantage is that you can pause the tv anytime, if you get a phonecall for example. And of course, recording stuff to watch at a completely different time. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: PS3 Linux [was - Re: OpenMoko and LCD TV]
roguem...@roguewrt.org wrote: On 6/05/2009 6:39 PM, Yorick Moko wrote: have you tried pairing yourn FR to the ps3 to use it as a controller/keyboard/music(or picture)streamer/whatever ? Since I left my FR out in the rain, I haven't done much with it. Surprisingly, it still works ... but the touch area of the shelf doesn't function. So I can boot, take a call but as soon as I load an app I can't go back etc. I've been meaning to throw the debian sd card back in Just turn the display upside down using xrandr, then the shelf is placed in a touch area that works. Or perhaps 90 degrees. Try it out with the terminal. If it works well, add the command to some startup script so it happens automatically. It is still fully useable if you connect a usb mouse (and enable the X cursor, which is easy.) But you probably don't want to use a phone with a mouse. :-) Also consider taking the display apart for cleaning. Water quickly cause corrotion wherever there is electricity. Might be worth a try taking the display off and cleaning with something like alcohol. Alcohol dissolves any water left over, it doesn't conduct electricity, and lefover alcohol evaporate quickly. If you get rid of any trapped water and corroded gunk, then the touchscreen might improve. There is the risk of breaking the thing further, but it seems sufficiently broken alredy. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-testing] kernel with working g_ether to Windoze connection?
Vasco Névoa wrote: I would, but I don't think my employer would agree. :) I use nothing but FLOSS everywhere, except of course at work, where I have to use the official workstation software... :P And it is very handy to hack the latest tweaks on my neo while waiting for a compilation to finish... ;) Right now, the Neo is networkless with SHR-testing in a Windows environment: - wifi is no good; - bluetooth way too complicated; - USB doesn't work; - GPRS stalls and doesn't allow opkg update, so forget upgrade SO GIMME THE WORKIN KERNEL ALREADY!!! :D I just find it strange all this back and forth, one version it works, the next it doesn't, then it works again, then not is that patch so difficult to keep alive?? When you use testing/unstable, you are part of the development. You are using stuff that is *not* regression tested before releasing. The stable distribution will likely be better in this respect, but stable hasn't happened yet. You can at least get wifi back by using a 2.6.28 kernel (available as older kernel images). This apparently works well with the latest testing, - if you also install the package with modules for that kernel. If you skip the modules, some other things (sound++) will fail. wifi will be back regardless. Also, USB networking works fine with the later kernels that break wifi, so any networking fix will need to be done on the windows machine. Linux (on the PC) also needed a change in the usb networking setup when the phone got a 2.6.29 kernel. So I expect that windows users need to do something too. This will likely not be reverted. As explained elswhere, the phone is now reporting the correct assigned MAC address for its usb network interface, it was wrong before. A networking setup that expects the old mac address will fail, so just change it! I guess other windows users can help you out with the details on how this is done? Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Wireless Frustration - definitely a kernel problem
Nelson Castillo wrote: On Wed, Apr 29, 2009 at 3:16 AM, Helge Hafting helge.haft...@hist.no wrote: Nicola Mfb wrote: 2009/4/28 Helge Hafting helge.haft...@hist.no: Helge Hafting wrote: [..] It is a kernel problem, because going back to the older kernel uImage-2.6.28-oe1+gitr34240a1c06ae36180dee695aa25bbae869b2aa26-r3-om-gta02.bin fixes the WIFI problem. Unfortunately, using this older kernel with SHR testing of april 22. means no usb networking instead. And no sound, so no phone either. Did you installed modules too? it works for me, I do not know if there are some changes that breaks frameworkd, but audio and usb works fine. I didn't think of that, the point was to see if WIFI would work again, and it did. So, a 2.6.29-rc3 bug was proved. But thanks for the tip, now I know what to try if the 2.6.29 wifi problem takes time to fix. Could you please report a bug? The steps to reproduce it would help a lot. Just flash shr testing of april 22., and the accompagnying kernel. WIFI will be totally broken. Reflash a 2.6.28 kernel, and WIFI will work normally again - at least WEP connections will be fine. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Wireless Frustration - definitely a kernel problem
Nicola Mfb wrote: 2009/4/28 Helge Hafting helge.haft...@hist.no: Helge Hafting wrote: [..] It is a kernel problem, because going back to the older kernel uImage-2.6.28-oe1+gitr34240a1c06ae36180dee695aa25bbae869b2aa26-r3-om-gta02.bin fixes the WIFI problem. Unfortunately, using this older kernel with SHR testing of april 22. means no usb networking instead. And no sound, so no phone either. Did you installed modules too? it works for me, I do not know if there are some changes that breaks frameworkd, but audio and usb works fine. I didn't think of that, the point was to see if WIFI would work again, and it did. So, a 2.6.29-rc3 bug was proved. But thanks for the tip, now I know what to try if the 2.6.29 wifi problem takes time to fix. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Wireless Frustration (was: Re: [SHR-Testing] /etc/network/interfaces edit question)
George Brooke wrote: Having low-level stuff like iwconfig fail is what makes me suspect a kernel problem. Try rmmod a6000 (I think thats the correct module) them modprobing it again as that some times works for me. I might try. But if it helps, then it is still a kernel bug that needs fixing. Messing around with modprobe commands is too cumbersome on such a device, slightly more tolerable on PCs that have real keyboards. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.2.1 and atd-over-fso (now works on SHR-testing)
W.Kenworthy wrote: Configurable, configurable, ... Everyones use case is different! - I usually wake with the click and display glow when the FR comes out of suspend, even before the alarm starts to sound, so I find the very low start fine as do the rest of the household (see next). I would also like to have a setting to remove the puzzle as I cant even see the buttons, let alone the tiny numbers without glasses. Ended up hacking the code to remove it and print a large ACK on the first button as the puzzle makes the FR unusable as an alarm clock (you DO have to be able to turn the alarm off before it wakes the rest of the household you know :) Maybe a config setting? The puzzle is kind of cool, it means I have to be awake enough to push the buttons in sequence. As opposed to turning a regular alarm clock off without actually waking up. And then oversleep. :-( Colours for the clock display - I changed mine to a dim amber - much better in a dark room. Also, does the green cause problems for the colour blind? (something to think about) - but the green is much better in daylight. Again, would be nice if its both configurable and/or selectable from the display. Colors are not a problem for the color blind, if there is sufficient intensity contrast. I.e. combine dark green with bright red or vice-versa. Varying the blue intensity also helps, as most color blind only are red-green blind. They usually see the difference between blue and the reddish-green. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debuzzing
Dr. H. Nikolaus Schaller wrote: Dear community, it is the philisophy of Golden Delicious Computers to find solutions for important topics that the community has and can't solve alone. Therefore, we (Golden Delicious Computers and TRIsoft) have worked behind the scenes and are close to offer a Buzz rework solution that can in principle serve all Freerunner Owners in the EU harmonized market. 1) We have identified a very good professional SMD rework company in Munich, Germany who are capable and willing to do the rework at low cost and high quality, but only if we deliver batches of collected devices. Since we are experienced in collecting incoming and outgoing shipments, the combination is the solution. Will they do the bass fix too? For an extra fee probably, as the weak bass isn't really a defect. The bass fix (bigger capacitors) was published here, can they take a look at that too? I hope doing both fixes at once will be economical, as most of the work is common to both jobs. (Ship the phone only once, take it apart only once, reassemble only once, ship it back only once.) If they verify the buzz fix with a test call, then they'll even verify the bass fix didn't break anything at the same time. 2) Therefore we plan to offer this service to all Openmoko owners within the EU harmonized market / tax union (to avoid re-import/export hassle). What is the problem with a country outside EU? If the Norwegian government adds a tax or fee, as they usually do, then the payment is my problem. Not yours. They post office simply notify me and hold the returning package back until I sort it out. All they need to calculate tax is the receipt for the repair fee. I guess this is provided anyway, as businesses normally provide a receipt. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Detecting headset button press
Ruben Leote Mendes wrote: Hi, I followed the Freerunner schematics and the heaset button seems to be connected to EINT7/GPF7 so it seems it is possible to find out in software if the button is pressed. What is the best way to do it? Check to see if it is interpreted as a normal key already. enlightenment can assign some actions to keys, that is how the two regular buttons are handled. Go into that setup, press the key and see if you get a keycode. If so, you can assign an enlightenment action. If you want to use it outside of e, run something like xev to check what keycode is produced. Then write software to listen for it. If you don't get any keycode at all (in xev), try talking to kernel developers about fixing that. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Wireless Frustration (was: Re: [SHR-Testing] /etc/network/interfaces edit question)
Adam Jimerson wrote: Well it is nice to see that I am not the only person with this problem, for me Mofi doesn't even load, I am installing the one from opkg.org http://opkg.org to see if I have any better luck with it. I have trouble with wifi in SHR testing too. I suspect a kernel problem. I usually run wpa_supplicant. Failing that, I connect to WEP networks using iwlist iwconfig commands directly. Even these low-level tools fails most of the time. Occationally iwlist eth0 scan will work, but repeat the command and eth0 suddenly doesn't support scanning. And of course it won't ever connect to any access point. Similiarly, iwconfig may claim there is no support for setting the essid. Having low-level stuff like iwconfig fail is what makes me suspect a kernel problem. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
