Re: Centralization of graphical awesomeness
On Wednesday 28 October 2009, DJDAS wrote: Bernd Prünster ha scritto: DJDAS wrote: FDOM uses illume, the launcher is efl, the settings app is efl... strange world we live in... Yes I know, thank you :) but since then I noticed new versions were slower than the one I have, so maybe FDOM guys or that libraries version was more performant, I really don't know honestly... FDOM display is faster mainly because it uses a relatively simple theme. Bernd's lightweight themes should give a similar speedup. Another factor is that some iterations of the fso daemons have been occasional resource hogs, causing display slowdowns whichever toolkit you use. This has been addressed partly by bugfixes in the python implementations, and for the future by the ongoing move to vala implementations of the daemons, starting with the most resource-hungry. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Wednesday 28 October 2009, Petr Vanek wrote: I meant that it ought to behave that way in future, not that it would in the current version. I don't care if the phone goes to sleep during the snooze interval so long as the alarm goes off again five minutes later! :) sure, now it didn't wake up itself and me neither :)) what if the unlocking 1-2-3-4 pattern is configurable, how would snooze get in then? How about puzzle to stop the sound, display the message and show the ACK slider? If you don't ACK then there's another alarm after the snooze interval. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ffalarms 0.3 -- recurring alarms
On Tuesday 27 October 2009, Petr Vanek wrote:
||
| Message|
|
|
| [Turn off slider] |
| [ACK slider] (*) |
|
| {Close button} (*) |
|
||
don't forget to fit in the Snooze slider too, please :)
It shouldn't need a separate slider. If you turn off but don't ACK it should
be equivalent to a snooze.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Centralization of graphical awesomeness
On Tuesday 27 October 2009, DJDAS wrote: Xavier Cremaschi wrote: - qt in qtmoko is very simple (for example no transparency, no fancy controls...) I prefer to not have transparency if this would result in more than 10fps in GUI responsiveness (not calculated but perceived which is what end user counts on) Then use a theme that doesn't use transparency! Bernd Prünster has done great work on producing themes that run much faster than the default while still looking good. They don't degrade with the 16 bit renderer either, and that runs even faster. The themes should be in the shr repos by now. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] [Debian] Which MicroSDHC card should I buy to install Debian onto?
On Tuesday 27 October 2009, Brolin Empey wrote: Hello list, I have a buzz-fixed rev A6 US FreeRunner (FR). I am currently using QtMoko v11, which is installed in my FR’s onboard NAND. I need a MicroSDHC card on which to install Debian. I do not want to run out of disk space, so I probably need at least an 8 GB card. The Openmoko wiki claims “The Neo FreeRunner supports up to 16GB microSDHC cards.”. [1] Is this true? What is the fastest and highest-capacity MicroSDHC card known to fully work with Debian on the FR? I am currently using U-Boot, but can try Qi if necessary (as long as I can boot both QtMoko from the onboard NAND and Debian from the MicroSDHC card.). I live in Delta, British Columbia, Canada, so Canadian sources are preferred. The speed of the card won't matter as the Glamo interface will be the bottleneck even with Class 2 cards. The 8GB Sandisk works for me with uboot for multibooting. It looks like the Sandisk is the only 16GB card tested so far. In theory 32GB should work when they become available. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] Accelerometers
On Sunday 25 October 2009, Ivo van den Maagdenberg wrote: 2009/10/25 Frederik Sdun frederik.s...@googlemail.com * Iain B. Findleton ifindle...@videotron.ca [25.10.2009 13:19]: Where is the device control for the accelerometers on SHR? Was /sys/bus/platform/devices/ls302dl.1/2 or some such on the OM distros. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community here's an overview of the sysfs paths: http://wiki.openmoko.org/wiki/GTA02_sysfs#Accelerometers No luck. The paths specified on the page you refer to do not exits on the SHR release. r...@om-gta02 ~ $ ls -a /sys/devices/platform/ .physmap-flash.0 s3c2440-sdi s3c-ohci .. powers3c2440-uart.0 soc-audio gta02-led.0 s3c2410-iis s3c2440-uart.1 uevent gta02-pm-wlan.0 s3c2410-wdt s3c2440-uart.2 neo1973-memconfig.0 s3c2440-i2c s3c2440-usbgadget neo1973-version.0s3c2440-nand s3c24xx_pwm.0 http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval#The_.2Fsys_inter facedoes neither point to the right direction in the SHR case. Any other suggestions how to manipulate the accelerometers? This is a case of a wiki page in need of an update because it only makes sense if you already know what it means ;-) Note the first line on the page: NOTE: These only apply to Linux kernel 2.6.24, 2.6.28 has different paths (see below) The #Accelerometers link you were given points to the paths for 2.6.24 which have explanations, but aren't used by any current distro. Below that is a section that says what each path from 2.6.24 changed to in 2.6.28 and later, and are used by all current distros. Scroll to the very end of the page and you'll find the answer you were looking for. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: /usr/lib/lib** svn .so.0 problem in shr
On Friday 23 October 2009, Pieter Colpaert wrote: Hi, Many applications (such as elmdentica, intone, ...) need the -ver-svn-02.so.0 version of the libs, so I just link them. Should tis not be automatically integrated into SHR? No, it shouldn't. If the packages are expected to run on shr they should link to the correct libs. The easiest way to make sure this happens is to get a recipe added to shr so that they are automatically updated when the library version changes, and people can install them directly from the shr repository. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Increasing GPS accuracy with EGNOS
On Wednesday 21 October 2009, Ed Kapitein wrote:
Baruch Even wrote:
SNIP
I found this in the source of ogpsd on my Freerunner:
def initializeDevice( self ):
# Use high sensitivity mode
#self.send(CFG-RXM, 2, {gps_mode : 2, lp_mode : 0})
# Enable use of SBAS (even in testmode)
self.send(CFG-SBAS, 8, {mode : 1, usage : 7, maxsbas : 3,
scanmode : 0})
So it seems that SBAS has always been enabled even in test mode. Does
anybody know where we can get information if sbas is really active and
used by the chip?
The comment is wrong, the mode value of 1 means that it uses SBAS but
not if its in test mode. The comment is a left over from the time the
value was 3, but then the whole line was commented out.
You can get SBAS status messages if you set it in the debug interface
with: mdbus -s org.freesmartphone.ogpsd /org/freedesktop/Gypsy
org.freesmartphone.GPS.UBX.SetDebugFilter NAV-SBAS True
and then listen to the signals with:
mdbus -l -s rg.freesmartphone.ogpsd /org/freedesktop/Gypsy
Look for DebugPacket signals.
I tried it for other signals, didn't have time yet to test if it works
for NAV-SBAS.
Baruch
I did to enable the debug packet and although i was receiving data from
PRN120, i never got any
NAV-SBAS packets in the debug output.
Acording to [1] it should be enabled in the framework, so i am wondering if
anyone had more luck than me.
I found the same as you, but probably forgot to report it. I believe the
reason is that by default the NAV-SBAS messages aren't enabled, and we don't
explicitly enable them in configuration. I didn't get round to checking the
message format required to enable it though.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: #1024-Fix in switzerland
On Friday 16 October 2009, Alexandre Ghisoli wrote: And about the other fixes as well ? (buzz, bass and GPS / SDIO issue) How many times does it need to be said? THERE IS NO GPS/SDIO ISSUE ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: voice calls with 3G USB dongle
On Wednesday 14 October 2009, Nicola Mfb wrote: On Wed, Oct 14, 2009 at 12:58 PM, Timo Juhani Lindfors timo.lindf...@iki.fi wrote: William Kenworthy bi...@iinet.net.au writes: So the FR is now obsolete - but is it possible to use the FR with an external 3G dongle? - I know it works for data from previous posts here, but can you make voice/sms calls from an external 3G dongle? Yes, chan_sebi module of asterisk can do voice calls with my huawei E169 3G USB dongle. Nice! how is the audio routed to the host? is it possibile to make the same on the freerunner? It looks like audio is going over one of several usb serial interfaces. For the Freerunner's GSM interface we would use chan_alsa, but it might need modification to treat left and right as separate interfaces if you want to use the handset mic and earpiece. There would also be some script glue between FSO and asterisk for call handling. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: voice calls with 3G USB dongle
http://lists.elastix.org/pipermail/beta-testers/2009-May/000517.html It looks to me like calls go from the dongle to the operator as normal, but that not all dongles are capable of this. On Wednesday 14 October 2009, William Kenworthy wrote: Maybe too hasty, does chan_sebi talk sip to the dongle (or maybe send gsm coded audio) so calls go from the dongle to the operator as per normal? - google isnt helping ... BillK On Wed, 2009-10-14 at 19:29 +0800, William Kenworthy wrote: Sorry, thats not what I am asking - can I make normal voice calls like a standard 3g phone, not have to set up a private VoIP system that connects over a data link. BillK On Wed, 2009-10-14 at 13:58 +0300, Timo Juhani Lindfors wrote: William Kenworthy bi...@iinet.net.au writes: So the FR is now obsolete - but is it possible to use the FR with an external 3G dongle? - I know it works for data from previous posts here, but can you make voice/sms calls from an external 3G dongle? Yes, chan_sebi module of asterisk can do voice calls with my huawei E169 3G USB dongle. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: new Android Cupcake release for Freerunner
On Tuesday 13 October 2009, Jim Ancona wrote: On Mon, Oct 12, 2009 at 8:36 PM, Al Johnson openm...@mazikeen.demon.co.uk wrote: On Monday 12 October 2009, Levy wrote: On Sat, Oct 10, 2009 at 20:34, Aditya Gandhi aditya...@gmail.com wrote: That is so sad to hear google android without maps, gmail, etc... is there anyway to get those binaries and have them run on freerunner?? One time I made a test with Gmail.apk that I got from a G1 and did not work! ! :-( No surprise there. The G1 has a later family of ARM cpu with instructions the FR doesn't support. No, that's not the reason. With the exception of those built with the new native development kit, apk's (the Android application packaging format) run in the Dalvik VM and are processor independent. AFAIK, the issue with is only missing APIs. Of course, that doesn't make Gmail run any better, but it does mean that apps that are developed using the public APIs and don't use the NDK should run across Android platforms regardless of the underlying processor. And in fact, almost all of the (non-Google) apps I've tried seem to run on my Freerunner. Should have known. That's what happens when I post past my bedtime ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [fso based] Simplified mixer app
On Tuesday 13 October 2009, Evgeniy Ginzburg wrote: On Tue, Oct 13, 2009 at 2:10 PM, Patryk Benderz patryk.bend...@esp.pl wrote: Hi Al, do you want me to add it to CU, or is it too early to show this app to average user? It's newer to early, add it. I agree. It's on the community list so it's fair game for the community update. The only cautionary note is to remember to back up any modified state files since there is a report of a messed up state that we haven't got to the bottom of yet. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: HOWTO: Sharing SHR-U GPRS to *buntu laptop
On Sunday 11 October 2009, Jeffrey Ratcliffe wrote: On Thu, Oct 08, 2009 at 03:51:21PM +0200, Michael 'Mickey' Lauer wrote: As per mdbus --help, you need a busname and an objectname before the method -- you can gather these by recursively calling mdbus -s ... OK. Got it working: $ mdbus -s org.freesmartphone.onetworkd /org/freesmartphone/Network org.freesmartphone.Network.StartConnectionSharingWithInterface usb0 I was able to access the DHCP server from my Eee PC running Jaunty by copying the MAC address from the static entry in network-manager, and created a new entry with the same MAC but DHCP rather than a static IP address. It seems very slow. ping www.google.com directly from the FR is ~750ms, from the Eee PC via the tether started on 2000ms and settled on 950. Is a 200ms difference to be expected? Latency on GPRS is big and highly variable. That's the nature of GPRS, and one of the things that makes it unsuitable for VoIP. These numbers don't look unusual. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: new Android Cupcake release for Freerunner
On Monday 12 October 2009, Levy wrote: On Sat, Oct 10, 2009 at 20:34, Aditya Gandhi aditya...@gmail.com wrote: That is so sad to hear google android without maps, gmail, etc... is there anyway to get those binaries and have them run on freerunner?? One time I made a test with Gmail.apk that I got from a G1 and did not work! ! :-( No surprise there. The G1 has a later family of ARM cpu with instructions the FR doesn't support. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 1024#
On Wednesday 07 October 2009, Christ van Willegen wrote: Hi, On Wed, Oct 7, 2009 at 10:50 AM, Ivan Shirokov ivanshirok...@gmail.com wrote: I've been wondering if all the freerunners are affected by bug #1024? I've been wondering the same thing... It would seem that the extra current draw in suspend would affect all FRs, so having a #1024 fix-party would be a good idea in any case (?). All are potentially affected as they all have nominally the same capacitor value. Not all of them actually suffer from it though, probably due to component variation. Dieter found that on his he could start the problem by heating the chip by a few degrees, and stop it by letting it cool. Depending on how lucky you are you may have #1024 always, never, or only when the phone's in your pocket. There are two sources of extra current draw: recamping and not being in deep sleep mode. Recamping is the symptom of #1024 so is only an issue on phones suffering from it. Deep sleep mode is a config option in /etc/frameworkd.conf so if you don't suffer from #1024 you can always use deep sleep mode. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Universal Remote for CE/HA? (openmoko)
On Friday 02 October 2009, Jed wrote: I glued a infrared led into the aux key for this purpose. Did someone already try to compile lirc for the FR? My attempt to just 'bitbake' it failed (missing kernel configuration). Hmmm, wonder if some of the other hand-held platforms do have IR? Surely there's at least one device?! Lets see there's: Android devices, Maemo devices, Axim x5xx (kinda), any others? Last crack ;-) Does anyone know of any OSS supported devices that do have IR integrated? Wifi would get most use in my intended application but IR would be handy! According to one review [1] the n900 has IR, and there's a universal remote app for it [2]. We'll have to wait and see exactly how open it is though. [1] http://my-simbian.com/other/preview_n900.php [2] http://irreco.garage.maemo.org/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 1024#
On Wednesday 07 October 2009, Christ van Willegen wrote: Hi, I've read the earlier-mentioned blog post, and have checked on IRC as well. #1024-fixed devices have a smaller current drain. Battery time can rise from 70h to 140h, even with deep_sleep=always already in the config file. From the blog post: DocScrutinizer-with sleep=4 you either get 140h, or problems on recamping when out in the cold. In other words if you set deep_sleep=always you will either see the full battery life, or you will get recamping, which will reduce battery life. Fixed devices see more battery life after the fix than before because they suffered from recamping before the fix. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 1024#
On Wednesday 07 October 2009, George Brooke wrote: On Wednesday 07 Oct 2009 10:36:01 Thomas HOCEDEZ wrote: David Garabana Barro a écrit : If you have something like [2009-09-09 12:36:09.189663] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:36:15.088936] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:38:10.442808] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:38:13.020126] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:40:25.772918] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:40:28.620096] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:41:17.557676] Signal : cid=3BB3, lac=0D48 [2009-09-09 12:41:20.404582] Signal : cid=3BB3, lac=0D48 Then you have the bug (trying to connect to GSM every second!) What would be considered a normal rate of connections? Under normal circumstances you would only see these messages with a change of cell, so cid would be different. The only time I know of that you might legitimately see repeated reconnection to the same cell is if you've got very low signal and it's the only cell visible. I get intermittent reconnection problems where the gap between reconnections is between 15s and several hours. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [fso based] Simplified mixer app
On Friday 02 October 2009, Laszlo KREKACS wrote: On Fri, Oct 2, 2009 at 4:17 PM, Laszlo KREKACS laszlo.krekacs.l...@gmail.com wrote: But there is so many things what changed, that Im completely lost. Just wanted to notice you, that restoring the original gsmhandset.state file (and rebooting) does solve my problem. Im able to take call, and hear the other party. (and he able to hear me). Although your program was nice. It changed the mic way better, what I had. Other party said, its much louder and clearer. Hope you can sort out, why the broken .state file is broken. And where the bugs comes from ... Updated version now available: http://www.mazikeen.demon.co.uk/openmoko/fso-simplemixer.py I can't reproduce your problem with faulty saves. You should find some extra debug output if you start it in a terminal, and message boxes so you know something has happened. This will show which scenario it asked fso to save, so you can check whether is asked to save the right one. It's possible we have different versions of frameworkd. I'm testing with: r...@om-gta02 ~ $ opkg list_installed frameworkd frameworkd - 0.9.5.9+gitr1697+ed29786daceccefe918ce3911e3b6fb7f2efb08c-r0 - Other changes: * More scenarios simplified. * With unhandled scenarios there is a message instead of a blank screen or crash I looked into adding the alsa channel number to the name in the advanced view, but pyalsaaudio doesn't make it available. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No wireless in Debian Sid
On Monday 05 October 2009, Esteban Monge wrote: Hello Again... I found this command, I think is the correct way to enable the wireless: mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/PowerControl/WiFi org.freesmartphone.Resource.Enable And to turn off: mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/PowerControl/WiFi org.freesmartphone.Resource.Disable I going to make the little gui based in this commands... You should not use this interface! From the docs[1]: Applications usually are not allowed to use this interface directly, they will solely interact using the org.freesmartphone.Usage API. The Resource Handling introduction[2] describes how you're supposed to control resources. In short you should be using: mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy WiFi enabled The valid states are enabled, disabled and auto, with auto being the default. Auto will enable the resource only when at least one application has requested it. [1] http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Resource.html;hb=HEAD [2] http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/usage- intro.html;hb=HEAD [3] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [pkg-fso-maint] WiFi-Tool (or GPRS-Tool modified)
On Tuesday 06 October 2009, Esteban Monge wrote:
Hello Al Johnson recommends use the next command:
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage
org.freesmartphone.Usage.SetResourcePolicy WiFi enabled
But send the next error:
ERROR:dbus.connection:Unable to set arguments ('WiFi',) according to
signature
u'ss': type 'exceptions.TypeError': More items found in D-Bus signature
than in Python arguments
The command listed above works for me. If I remove the 'enabled' argument I
get the error you quote.
SetResourcePolicy takes two arguments. The first is the resource, in this case
'WiFi'. The second is the policy you want to set, in this case 'enabled'.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [fso based] Simplified mixer app
On Tuesday 06 October 2009, Mikhail Umorin wrote: Thanks for the app, Al (see below) On Monday 05 October 2009 19:43:37 Al Johnson wrote: On Friday 02 October 2009, Laszlo KREKACS wrote: On Fri, Oct 2, 2009 at 4:17 PM, Laszlo KREKACS laszlo.krekacs.l...@gmail.com wrote: But there is so many things what changed, that Im completely lost. Just wanted to notice you, that restoring the original gsmhandset.state file (and rebooting) does solve my problem. Im able to take call, and hear the other party. (and he able to hear me). Although your program was nice. It changed the mic way better, what I had. Other party said, its much louder and clearer. Hope you can sort out, why the broken .state file is broken. And where the bugs comes from ... Updated version now available: http://www.mazikeen.demon.co.uk/openmoko/fso-simplemixer.py In simple view if I slide volume all the way to the right, it goes to 101 (not 100) is that correct? That depends which slider it is ;-) It is correct. I map the alsa channels to a single slider giving equal increments covering the full range possible from those channels. For the outputs this is usually gives steps 0 to 101 while for the mic it is usually 0 to 119. If you uncomment self.gta02mixer.PrintGains() and start it from the cli it will show you the gain setting in dB for each step in the debug output. Unfortunately pyalsaaudio only accepts integer percentages when setting volume, so there are rounding errors when actually setting the volumes. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [fso based] Simplified mixer app
On Wednesday 07 October 2009, Mikhail Umorin wrote: On Tuesday 06 October 2009 12:28:37 Al Johnson wrote: On Tuesday 06 October 2009, Mikhail Umorin wrote: Thanks for the app, Al (see below) On Monday 05 October 2009 19:43:37 Al Johnson wrote: On Friday 02 October 2009, Laszlo KREKACS wrote: On Fri, Oct 2, 2009 at 4:17 PM, Laszlo KREKACS laszlo.krekacs.l...@gmail.com wrote: But there is so many things what changed, that Im completely lost. Just wanted to notice you, that restoring the original gsmhandset.state file (and rebooting) does solve my problem. Im able to take call, and hear the other party. (and he able to hear me). Although your program was nice. It changed the mic way better, what I had. Other party said, its much louder and clearer. Hope you can sort out, why the broken .state file is broken. And where the bugs comes from ... Updated version now available: http://www.mazikeen.demon.co.uk/openmoko/fso-simplemixer.py In simple view if I slide volume all the way to the right, it goes to 101 (not 100) is that correct? That depends which slider it is ;-) It is correct. I map the alsa channels to a single slider giving equal increments covering the full range possible from those channels. For the outputs this is usually gives steps 0 to 101 while for the mic it is usually 0 to 119. If you uncomment self.gta02mixer.PrintGains() and start it from the cli it will show you the gain setting in dB for each step in the debug output. Unfortunately pyalsaaudio only accepts integer percentages when setting volume, so there are rounding errors when actually setting the volumes. I was talking about Stereo Out for Speaker (when not in call). Sorry to be unclear. So, how does the simple slider correspond to Bypass and Headphone in the advanced view? Or are those things all different controls? Moving the simple speaker slider seem to change Bypass and Headphone, but at different rates for different ranges of the simple slider. When I max out the simple slider (to 101), bypass and headphone are at 100, but at lower simple slider settings they change very non-linear. The 'simple' slider controls all the sliders in that group in the 'advanced' view to give smooth control of the overall volume. In this case that's Bypass and Headphone. The changes in individual controls may look nonlinear, but their combination produces even steps while avoiding combinations likely to cause distortion. That's the idea anyway. You can see the combinations in the lookup tables in the top 3/4 of the script if you're interested. This was probably discussed numerous times. But your visual application makes the channels easier to control and I finally feel that I have a chance to get the volume I want during calls. Great! That was the intention. It's all so confusing So people tell me ;-) Compared to most instrumentation systems it's a breeze! What's a good place to learn the relations between all the channels/controls/bugs that make sound? Start with the wiki. The Neo1973 page has an annotated block diagram that's actually for the Freerunner. Both pages give some info on which volume settings affect what in different alsa states. With the information there, and by looking at the alsa state files, you will be able to see how the switch settings route audio signals through the mixer chip. You can then refer to the Wolfson datasheet. http://wiki.openmoko.org/wiki/Neo_1973_audio_subsystem http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Increasing GPS accuracy with EGNOS
On Sunday 04 October 2009, Erik Lundin wrote: Good news, indeed. Does the Neo FreeRunner support EGNOS signals? Both the hardware and software? http://www.u-blox.com/en/download-center.html?task=view.downloadcid=83 According to this the Antaris 4 is capable of using WAAS, EGNOS and MSAS, collectively known as SBAS, and the signal is received through the GPS antenna. By default it is enabled, with one search channel, although this can be configured through the ubx protocol. The status can also be shown in ubx messages. This is probably worth checking to see what is actually happening when in Europe, as when it was written EGNOS was in test mode, and its use was disabled by default. It is unclear whether this was because of a 'test mode' flag in the signal or hardcoding in the firmware. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Increasing GPS accuracy with EGNOS
On Monday 05 October 2009, Joseph Reeves wrote: This is probably worth checking to see what is actually happening when in Europe, Someone tell me what command to run on what distro and I'll let you all know... If it was going to be that easy I'd have done it myself ;-) AFAIK there isn't a simple ubx utility that would allow us to send parameters to the GPS and watch for the returning messages, so adding a few lines to ogpsd is probably the easiest approach. For anyone who knows their way around ogpsd and ubx it should be quick and easy ;-) I'm not that person, so if I get round to it it may take a little longer... 2009/10/5 Al Johnson openm...@mazikeen.demon.co.uk: On Sunday 04 October 2009, Erik Lundin wrote: Good news, indeed. Does the Neo FreeRunner support EGNOS signals? Both the hardware and software? http://www.u-blox.com/en/download-center.html?task=view.downloadcid=83 According to this the Antaris 4 is capable of using WAAS, EGNOS and MSAS, collectively known as SBAS, and the signal is received through the GPS antenna. By default it is enabled, with one search channel, although this can be configured through the ubx protocol. The status can also be shown in ubx messages. This is probably worth checking to see what is actually happening when in Europe, as when it was written EGNOS was in test mode, and its use was disabled by default. It is unclear whether this was because of a 'test mode' flag in the signal or hardcoding in the firmware. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Universal Remote for CE/HA? (openmoko)
On Friday 02 October 2009, Jed wrote: I glued a infrared led into the aux key for this purpose. Did someone already try to compile lirc for the FR? My attempt to just 'bitbake' it failed (missing kernel configuration). Hmmm, wonder if some of the other hand-held platforms do have IR? Surely there's at least one device?! Lets see there's: Android devices, Maemo devices, Axim x5xx (kinda), any others? Last crack ;-) Does anyone know of any OSS supported devices that do have IR integrated? Psion 5, 5mx, Ericsson mc218. Slow cpu, limited memory, monochrome and old kernel, but excellent battery life on a pair of AAs. Probably not the form factor you're after though. Neuros OSD - for a low power consumption ethernet to IR gateway and standard def media player. Again probably not what you're after. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [fso based] Simplified mixer app
Thanks for the feedback. The local beer festival may slow down the fixes though. I'll try to pull everything into one reply... On Friday 02 October 2009, Laszlo KREKACS wrote: There have been many attempts to implement volume control;) Angus looked into it, did two versions (gtk, and after elementary) This one is derived form Angus's fso-mixer.py, and the Advanced view should look and behave almost identically. The novel part is bringing several alsa controls into one slider, so I was hoping for feedback on how well that worked at avoiding distortion on the gsm mic or the earpiece. Having said that I can see that I may need to improve the GUI to get more people testing it, and to make it more useful for people :-) I have also researched some of the things. Nice to see, that there is an another attempt. I hope you will done it right;) I have only one suggestion: Please implement a help button on every near every group, where you explain shortly the most essential infos about the options. That seems reasonable. The aim is to have a single slider for each group in the simple view. Showing multiple sliders in the simple view is the fallback for where there isn't a lookup table for mapping them to a single slider yet. If I do it then it would appear for individual sliders whichever view they were in though. I just launched your program and it picked up the stereout .state file, and displayed the sliders. Screenshot: http://laszlo.krekacs.googlepages.com/fso-mixer-screenshot.png The screenshot is a bit wrong, because it does show the Stereo Out string, in the middle (above Microphone). So it looks normal in real life, dunno why the screenshot didnt included it. (maybe it was rendering while captured the screen) I would like see the following help buttons: Stereo Out [help] Microphone [help] Speaker [help] I would like you to see only one slider in the simple view ;-) I just need to assemble the lookup table. I should have done that before release since it's the first one people will see. Help of the Stere Out page should be something similar: Stereo Out state is corresponds, when the phone is idle (ie waiting for incoming call, or playing music). Microphone is disabled in this state, and Speaker corresponds to the speaker at the bottom near to the Neo text. [Should show a picture with a neo indicating where the microphone and the speaker are.] Help of Microphone page should be something similar: Mic2 corresponds to XXX alsa settings (or group of alsa settings) Mono corresponds to XXX alsa setting Mono Sidetone corresponds to XXX alsa setting. Microphone can be altered also by this alsa settings: XXX,YYY, ZZZ However it is strongly discouraged to touch them. The names are those returned by pyalsaaudio for that channel, and match the ones in alsamixer. I'll see if it can give me anything else like channel number though, or perhaps code it into the lookup. I sense some refactoring coming on... Advices: The monoside tone is used for XXX. You should hear XXX, when you raise it. Highest state does not automatically means better/louder voice transmitted. Also some other advices how to correctly adjust the sliders. Like on the wiki page: reduce #5 by some 15..30 steps do testcall: you get very low volume at far end. but tone should be clear, no clipping (sharp agressive noise) if there is clipping: reduce #48 by one step (i.e. to 2) then adjust #5 to your preferences and taste Keep in mind that your program should be self-explanatory and useful for even for the first time user. That's the aim. If you want the explanatory pictures, Im sure somebody can draw it for you. If nobody step up, I look into what can I make;) There is also some AT command to affect the voice quality. Mickey told me, that on his freerunner, value 4 works better then value 5 (the default). I think it should also be included in your program, to give the ability to play with it... (if the user are still not satisfied with the result). There is an AT command for the gsm playback volume, and an fso call to adjust it. I haven't found anything that gives a setting to dB mapping for this function though, so I can't easily include it in the gain mapping. The best I could do at the moment is to add an extra slider for it in the GSM states. If I do that I should probably add sliders for the bluez headset controls too. Usability reports: IT is nice, that your program switch the display automagically when the incoming call happens. You can thank Angus for that. I'm just building on his foundations. However I think these are defectives: 1. when clicking on save there is no report what you did exactly, and was it successful. I think on shr, you should save the .state file to /usr/share/shr/scenarii/ dir. So I expect something similar: Copying /usr/share/shr/scenarii/stereout.state to
Re: Qi doesn't read my /boot/append-GTA02
On Thursday 01 October 2009, Vasco Névoa wrote: I'm booting from Flash, not SDcard. Shouldn't the /boot/append file work the same? No. Qi can read fat and ext2/3 but not jffs2, reiserfs and so on. Since flash uses jffs2 Qi can't read the /boot/append file. If it doesn't, where are the kernel parameters defined? In the Qi source. You would have to change the defaults and recompile. Or add jffs2 support to Qi. Paul Fertser escreveu: Vasco Névoa vasco.ne...@sapo.pt writes: I'd like some help here, please. dmesg doesn't give me any clues. I removed the quiet splash from /boot/append-GTA02 and added glamo_mci.sd_drive=5, but none of it is sticking. It's ignoring the file altogether, AFAICT. Are you sure you're booting from SD? And that all you parameters are on the first line in that file? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [fso based] Simplified mixer app
On Friday 02 October 2009, Michele Brocco wrote: cool idea! would be nice if through this App we could finally make sound coming through earpiece with the voip-handset state file. Still struggling with it This app has nothing to do with that I'm afraid. It should eventually give a slider each for mic and earpiece, but that'll just tweak the settings in voip- handset.state slightly. It won't do state switching on answer or hangup, or sort any fundamental issues with the sound config. Problems with voip config are for another thread though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[fso based] Simplified mixer app
I've made mixer app that maps a single slider to multiple alsa channels, so you can have one slider for 'Mic' and another for 'earpiece'. It's based on Angus Ainslie's fso-mixer, but using lookup tables for which channels to show in which scenario, and for mapping the single slider to multiple channels. It's at proof of concept stage now, but should be as functional as fso-mixer. I hope. If you aren't using stock ones it would be a good idea to back them up before using it just in case! Feedback would be welcome. http://www.mazikeen.demon.co.uk/openmoko/fso-simplemixer.py Known bugs and missing features: * I haven't done mapping tables for all the mixer scenarios yet. Where they aren't done you will see the individual sliders as you would in fso-mixer. * Sometimes when the state changes a setting will be shown as 0 when it is in fact non-zero. If anyone spots why this happens I would love to know! * The volume sliders cover the whole possible range, while most people probably only ever need the top half or third. * pyalsaaudio only accepts integer percentages when setting volumes, not the actual mixer hardware values used in the lookup tables. This may give some uneven steps in volume. * When individual alsa channels are shown they use the alsa names. This is fine if you know that the 'headphone' mixer controls the speaker, and the 'speaker' control is for the earpiece, let alone some of the more obscure names. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] Offline SHR Manager - First Release 0.1
On Wednesday 30 September 2009, Stroller wrote: On 30 Sep 2009, at 14:32, Christ van Willegen wrote: On Wed, Sep 30, 2009 at 3:08 PM, Stroller strol...@stellar.eclipse.co.uk wrote: I used to be able to do this by Bluetooth, on my Mac using a previous phone. I rather assumed there was a standard Bluetooth framework for this? When I did this with my previous phone and my Mac, the SMS message never made it to the phone's memory. Since we're talking a different phone here, we can do with the message whatever we want, but it was still annoying! I don't care about this myself, but if there's a standard way for the PC phone to talk over bluetooth then that feature would be part of the phone's implementation of the protocol. I can't remember if active pairing was necessary (on each occasion), but I really liked the way the phone alerted the computer of incoming calls SMS. That was really nice. A phone may expose some or all of the modem AT functionality via the Serial Port Profile, Dial-up Networking Profile or Fax Profile. None of the profiles mandate support for the SMS commands, but they don't stop it either. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Universal Remote for CE/HA? (openmoko)
On Wednesday 30 September 2009, Jed wrote: Al Johnson, did you get my last response? below It was waiting for me, along with this one, when I finally got round to checking my mail today. Hi All, I was wondering if there's any good Universal Remote software for CE or HA being developed in this ecosystem? Does anyone know of anything under way or a related Linux project that could be re-adapted to it? I have something roughly like this visualised... (see attached txt file) I have an old Axim X50v which android is being ported to atm... But progress is slow so I may have to find a better supported device soon. Any thoughts/ideas/advice greatly appreciated! Can't control the TV or whatever without the HTPC being powered up. Many would see that as core functionality in a universal remote. If you don't then the Freerunner may be what you're looking for. Sorry if I'd sent my diagram through properly you'd have understood why it's not that imperative for me. The idea is to have a dedicated CE/HA controller/bridge. It will ideally be relatively low power/profile. [I've attached the diagram again in case you didn't see it when I re-sent it earlier, tis very basic] Yes - if that had been attached in the first place my responses might have been slightly different! How would BT be better than using Wifi as the medium to the controller PC? Do none of the openmoko hardware devices have wifi integrated? It was just a suggestion as to how you could get infrared functionality with an existing BT remote app. There's no reason not to use WiFi if it suits you better - the Freerunner has both. BT uses less power, especially if your WiFi access point doesn't support the power saving mode. WiFi is faster and has longer range. K cool, I just thought you might know something I didn't, thanks! [1] http://wiki.openmoko.org/wiki/ReMoko [2] http://n2.nabble.com/Auto-home-revision-1-1-td3698124.html I've also come across this and am quite impressed thus far! http://openremote.org/display/orb/Boss+Overview Last time I looked many of the features turned out to be intended but not implemented, but that may have changed by now. You might also like to check out LinuxMCE, PlutoHome, MisterHouse and Minerva. Isn't LinuxMCE just the non-commercialised version of PlutoHome? As I understand it LinuxMCE is a fork of PlutoHome, but they've been separate long enough for things to have diverged a bit. I've not tried either of them. Coolness, never heard of those other two, thanks! I've not tried them either, just seen them when looking at what's available. I also found xAP interesting as it has a plugin for SqueezeCenter which I already use. It's more of a building block than a system though. It might be worth checking the source for Logitech's Squeezebox Controller as an open modular remote running in linux on a small Arm device. They use Poky for building the images, so it should be relatively easy to bring into OE. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Universal Remote for CE/HA? (openmoko)
On Tuesday 29 September 2009, Jed wrote: Hi All, I was wondering if there's any good Universal Remote software for CE or HA being developed in this ecosystem? Does anyone know of anything under way or a related Linux project that could be re-adapted to it? I have something roughly like this visualised... (see attached txt file) I have an old Axim X50v which android is being ported to atm... But progress is slow so I may have to find a better supported device soon. Any thoughts/ideas/advice greatly appreciated! I couldn't understand your plans from what I saw in the text file. Since we don't have an infrared port we can't do a direct Universal Remote app. ReMoko[1] lets the Freerunner act as a configurable bluetooth human interface device, essentially a universal bluetooth remote. If you have a linux box with bluetooth and a lirc transmitter you could use the combination as a universal infrared remote. Sriranjan has announced 'Auto home revision 1.1' on this list recently[2]. Most HA projects have a web interface which you could use, probably without modification as they often have themes for small screens such as the iPhone or n800. If they have a native linux client then that may run with a simple recompile, or with a little porting. Java clients are another option. [1] http://wiki.openmoko.org/wiki/ReMoko [2] http://n2.nabble.com/Auto-home-revision-1-1-td3698124.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Universal Remote for CE/HA? (openmoko)
On Tuesday 29 September 2009, Jed wrote: Hi All, I was wondering if there's any good Universal Remote software for CE or HA being developed in this ecosystem? Does anyone know of anything under way or a related Linux project that could be re-adapted to it? I have something roughly like this visualised... (see attached txt file) I have an old Axim X50v which android is being ported to atm... But progress is slow so I may have to find a better supported device soon. Any thoughts/ideas/advice greatly appreciated! I couldn't understand your plans from what I saw in the text file. What didn't you get? I saw: *** find out if our aircon network can also be used as a gigabit LAN. griffin total remote AMD Radeon HD 58xxx (mid range) UR OEM's urc phillips nevo rti creston control4 http://vip.asus.com/eservice/techserv.aspx manager_t...@asustek.com.cn *** It's a list of things bits with no indication of how they may be connected. It's probably one of these things that's obvious when you understand it, and totally opaque when you don't ;-) Since we don't have an infrared port we can't do a direct Universal Remote app. IR directly from a hand-held isn't imperative, I don't see any real loss in not having do you? Can't control the TV or whatever without the HTPC being powered up. Many would see that as core functionality in a universal remote. If you don't then the Freerunner may be what you're looking for. ReMoko[1] lets the Freerunner act as a configurable bluetooth human interface device, essentially a universal bluetooth remote. If you have a linux box with bluetooth and a lirc transmitter you could use the combination as a universal infrared remote. How would BT be better than using Wifi as the medium to the controller PC? Do none of the openmoko hardware devices have wifi integrated? It was just a suggestion as to how you could get infrared functionality with an existing BT remote app. There's no reason not to use WiFi if it suits you better - the Freerunner has both. BT uses less power, especially if your WiFi access point doesn't support the power saving mode. WiFi is faster and has longer range. Most HA projects have a web interface which you could use, probably without modification as they often have themes for small screens such as the iPhone or n800. If they have a native linux client then that may run with a simple recompile, or with a little porting. Java clients are another option. [1] http://wiki.openmoko.org/wiki/ReMoko [2] http://n2.nabble.com/Auto-home-revision-1-1-td3698124.html Awesome thanks, I'll look into it! I've also come across this and am quite impressed thus far! http://openremote.org/display/orb/Boss+Overview Last time I looked many of the features turned out to be intended but not implemented, but that may have changed by now. You might also like to check out LinuxMCE, PlutoHome, MisterHouse and Minerva. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GSM roaming question
On Tuesday 29 September 2009, Mikhail Umorin wrote: Hello -- I cannot access network in certain locations (in Texas, USA) on my FR using ATT SIM card. However, when I use the same SIM in the ATT GoPhone that came with the card, I have access to a network. Operators button in the phone settings in SHR-U shows only Automatic and T-Mobile. So, is this roaming problem a bug? misconfiguration? not implemented? not possible? It could be as simple as the GoPhone being more sensitive than the Freerunner. Which network does the GoPhone connect to? The Freerunner should default to Automatic mode. You can find this if you press the Modem information button in the settings app and scroll down a little. It should also tell you the network it's registered with (if any) and whether it's your home network or not. Signal strength should be in there too with more detail than bars/blobs. Automatic mode means the gsm firmware is in control of which network it registers to. This should be the home network if available, or any other allowed network if not. There is an AT command to list the order of preference for picking other networks, but I don't remember what it is, or whether it is provided by the SIM. It's not something you should normally need to touch though. If it says T-Mobile instead of T-Mobile [forbidden] you should be able to click on it to register with T-Mobile. I don't know enough about the US GSM market to know if this is likely though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: recommendations for headset or 3.5mm adapter
On Monday 28 September 2009, Stefan Buschmann wrote: I also thought about soldering my own adapter, although my soldering skills are near to zero, but that might also be good for practicing :-) So, would it be possible to solder a wire like this? - 1 x 2.5mm to - 2 x 3.5mm (one for standard earphone, one for standard microphone) That way I could use standard earphones or a PC-headset, which would be very nice. And given the configuration of the pins, it should not be too hard to make. So, would this approach work, or is there something else to consider which I as a software-only geek don't think of? That will work. Remember the headset mic isn't helped by the buzz fix. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
On Thursday 24 September 2009, Torfinn Ingolfsen wrote: Hi, On Thu, Sep 24, 2009 at 4:02 PM, Rask Ingemann Lambertsen ccc94...@vip.cybercity.dk wrote: On Tue, Sep 22, 2009 at 11:11:04PM +, Niels Heyvaert wrote: The idea of having a simple GUI boot loader could be very useful... We have one. It's called U-Boot. Or am I missing something? Apart for a fact that it has problem loading kernels over a certain size? The default is 2MB, but it's a config option. Or that it requires the kernel on a separate partition (which must be fat?)? No, I don't think so. Where did you get that idea? My kernels live in /boot on the ext3 partition I'm booting. They can live on a separate partition, and it can read from fat, but neither are requirements. But this begs the question: could U-boot be improved to deal with the current requirements of the users? The two issues above could be solved by providing a more friendly configuration tool. The slightly slower boot and resume probably can't be changed due to the different philosophy. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [debian] e and illume: how to configure launcher icons?
On Thursday 24 September 2009, arne anka wrote: I'm pretty sure Illume does not have support for categories or the ability to hide apps (especially not through a menu). Workarounds: If you delete the .desktop file from /usr/share/applications/, it won't be displayed. If your .desktop file doesn't contain Type=Application, I don't think it'll be displayed. i remember distinctly a dialog popping up first time with a listing of apps and a checkbox for every app, to enable it. can't get to that dialog again. additionally: i want to add my very own apps to the launcher -- and that as _normal_ user. since linux is a _multiuser_ operating system with separation of rights, it's unreasonable to expect _normal_ users to create/modify _global_ files (which the .desktop files in /usr/share/applications/ are). I think that selection dialog is for the enlightenment menu or something. It has no effect on what apps appear on the illume launcher as far as I can tell. The illume launcher is rather lacking in functionality as you have found. I'm sure Raster will gladly accept patches to improve the situation, but afaik nobody has written any. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mount NAND partitions from Linux?
On Thursday 24 September 2009, tingox wrote: Hello, Can I find out what partitions I have on NAND in my FreeRunner, and mount them from Linux? (I am currently running QtMoko v11, booted from p2 on a SD card) mount -t jffs2 /dev/mtdblock6 /some/suitable/target ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QI boot order
On Wednesday 23 September 2009, Jan Henkins wrote: Hallo Christ, On Wed, September 23, 2009 13:31, Christ van Willegen wrote: What did the trick for me, although it's not in the Wiki, is this: - Press and hold AUX - Press power - Let go of AUX - Let go of power That should skip 1 partition on SD, hope that's enough for you... Note that this key order is not as it should be! So no guarantees. Pressing the AUX in the brief time that the LED flashes RED _should_ do it, but I've never reliably been able to do that. Thanks, this is one step closer, but still not ideal. I was sort of hoping that one could control QI with some form of configuration method, kinda like grub or lilo. I'll play a bit more. There's no one configuration file to use, but some level of control is available using files in /boot on each partition, as described in the wiki. It would be quite easy to write a script or gui to manipulate these, but so far nobody has afaik. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
On Tuesday 22 September 2009, Torfinn Ingolfsen wrote: Hello, Is there any specific reason why Qi[1] only tries to boot from partition 1 - 3 when ther csn be 4 (four) primary prtitons on a SD card? Or is it just developer eccentrics or programmer laziness? :-) References: 1) http://wiki.openmoko.org/wiki/Qi I believe it's an arbitrary limit based on the assumption that with no gui it would be hard to select the intended partition. Given the touble people have with only 3 partitions it seems well founded. This limitation is one of the reasons I'm still using u-boot. The other is the inability to pass optional kernel parameters when booting from NAND. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qi - why only 3 partitions on SD card?
On Tuesday 22 September 2009, Paul Fertser wrote: Torfinn Ingolfsen tin...@gmail.com writes: Qi _will_ need to be improved until it is usable for end users, or it will fade away I really can't understand the desire to multi-boot. And btw the recent poll proved that most users use Qi IIRC. A clear evidence it's already usable for them. Most people use Windows, but that doesn't meet my needs either ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: mplayer?
On Friday 18 September 2009, Robin Paulson wrote: 2009/9/17 David Garabana Barro da...@garabana.com: So have ext2/3 with the upcoming btrfs [1]. ext2/3 were good on 90's, but they are absolutely outdated, slow and featureless. For example, Tail packing and good small file performance is a must with OSM tiles. You don't have any of two with ext2/3... Another good alternative would be JFS (although I don't know how it performs with many small files), but there is not jfs module on om kernel. i wouldn't say featureless, exactly anyway, how would i go about changing to something more modern? say ext4 or btrfs? root partition, or another one? remember you need the kernel in ext2/3 or fat for the bootloader to be able to read it, or in NAND. Also remember btrfs on- disk format is still subject to change, so a kernel upgrade may mean you can't read it. is possible without a format/reinstall? http://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Only one chance to enter PIN?
On Friday 18 September 2009, Mikhail Umorin wrote: Hello -- I have enabled PIN for my SIM (rhymes, ah?). As I turn FR on it asks me to enter it. However, it takes awhile and I usually forget to wait for the PIN dialogue to come up. After a while, either due to suspend, or due to accidentally pressed buttons, the PIN entry dialogue vanishes and I am left with No service. Is there a way to enter the PIN at this time? What is the original GUI app that asks for the PIN in the first place? That depends on the distro. Which one are you using? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] kernel config and how to build modules
On Thursday 17 September 2009, Radek Polak wrote: Radek Polak wrote: Hi, anybody knows how is kernel built for SHR? I am interested in kernel config and in knowing how to build modules for the resulting image. I can see that modules in SHR are around 6MB, while gta02_packaging_config produces about 30MB of modules (after doing ./build GTA02 dummy in andy tracking git). Ping... or is it secret information? The whole of SHR, including the kernel, is built using OpenEmbedded. Packages are compiled according to bitbake recipes which have a .bb extension. These are equivalent to spec files for rpm, or gentoo ebuild files. If you have the shr build environment installed you can look at shr-unstable/openembedded/recipes/linux/linux-openmoko* to see exactly what they do. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Phonelog: missed call NULL name and number
On Thursday 17 September 2009, Niels Heyvaert wrote: - Why is the number/name equal to NULL? - Why didn't the phone do anything (ringing/vibrating, missed call notification) when apparently somebody tried to call? NULL means hidden number. Kind of expected that one :-) A programmer can understand this, obviously, but from an end user perspective it is not very meaningful. Could we replace NULL by something self explanatory like [Hidden number] or [No caller ID] or [Private number]...? So long as it's done by the app at runtime. The daemon shouldn't storing things in a language-specific way. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] wakeuptime, was Re: 2.6.31 is out, where is my ultimatekernel?
On Wednesday 16 September 2009, Steven ** wrote: I'm using SHR-Unstable (updated/upgraded this morning). I hear 3 rings on the sending line before the Neo rings if it is suspended. Even when it's awake, the Neo doesn't ring/vibrate until shortly after the second ring on the sending line. This is all with the debugfs tweak (which I don't think sped anything up for me). Perhaps this delay is caused by my network though? Possibly. I've heard such a delay when calling a friend's phone to find out where he left it, and that was a Nokia or S-E. You may be able to enable logging of the messages from the GSM module, and keep an eye on them as the call is received. That way you can see how much delay there is between call notification being received and the ringing starting. It could be related to system load and/or memory usage too of course. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dbus api for gta2 accelerometers
On Wednesday 16 September 2009, Ed Kapitein wrote: Rask Ingemann Lambertsen wrote: On Sat, Sep 12, 2009 at 07:50:26PM +0200, Ivo van den Maagdenberg wrote: The use case is as follows: take the openmoko and make it a cycleway shock measuring platform, utilizing the accelerometers. So, direct reads from the are going to be needed. The gps unit is of course of interest to make the measurements location-based. I've had an idea along the same lines: Use accelerometer data to log the position of points during a train ride. Only, I'd need GPS readings that are accurately timestamped, i.e. not rounded to whole seconds. Since a train has a large mass and a reasonable speed, why not use the whole second readings of speed and heading and use interpolation/extrapolation to determine the actual time and location? It should be rather accurate i guess. We would want to interpolate anyway, but the error bound is set by the rounding error introduced by using integer seconds. Even at relatively low vehicle speeds this may be greater than the error in the reported GPS position. 100km/h is just under 30m/s. Ideally I would like to see ogpsd extended to provide more accurate timestamps and more control over the gps. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] wakeuptime, was Re: 2.6.31 is out, where is my ultimate kernel?
On Tuesday 15 September 2009, Russell Dwiggins wrote: I'm still a bit confused. I'm in the same boat with others here where it takes between 3 and 4 rings before I can take any action on the incoming call. (shr-u and u-boot, both recently updated) What is the condition that allows one to take action on a call ~1 ring, and how does the end user get to that point? I think there are some who will point to Qi as a part of the solution, but I understand that this is a faith-based discussion. ;) I'd prefer to remain with u-boot for now until the suggested kexec kernel shows up to allow me to directly select the partition I wish to boot from. You need to reduce the log level. The best way is to do it in the kernel parameters as this will also help with the boot time, but it can be done at runtime as well, so you could add it to an init script. Log level 4 gets rid of almost everything but should still give something useful with errors, while 0 will stop it entirely. You could pick something in between too. For the kernel parameters you need to edit your uboot environment. Add either 'quiet' or 'loglevel=n' where n is the desired loglevel. quiet gives loglevel 4. See: http://wiki.openmoko.org/wiki/Bootloader_commands#Environment The runtime method is described on the shr tweaks page: http://www.shr- project.org/trac/wiki/Tweaks#majorreallymajorspeedupofsuspendandwakeup ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dbus api for gta2 accelerometers
On Tuesday 15 September 2009, Rask Ingemann Lambertsen wrote: On Mon, Sep 14, 2009 at 01:36:35PM +0100, Al Johnson wrote: Out of interest why you want to know the position of the points, For simulation purposes. Aerial photographs can be used too, of course, but it is quite time consuming to measure the distances that way. Curves are also an issue that I hope the GPS will do away with. If you're lucky it'll be in openstreetmap already. I was surprised by the level of detail on some of the railways while using navit on holiday recently. Even if they're not there already the OSM tools should make it relatively easy to get positions in from aerial photos, and the data into a vector format. and how do you intend to distinguish them from a lateral track defect? I don't know if it can be done automatically. The idea is to detect the common crossing as the wheels pass over it, and maybe you can tell from the accelerometer readings that only wheels on one side ran over something or perhaps the data show a particular signature from the common crossing that a lateral track defect doesn't have. For simple crossings look for a lateral acceleration in one direction, followed by a damped rebound and overshoot, a short gap, then a lateral acceleration in the opposite direction with damped rebound and overshoot. You will probably see some peaks in vertical acceleration on the crossings too. If you're lucky lateral defects won't occur in pairs, and they may have more overshoot. Aim to sit close to the bogie centre near the end of the carriage as you will get about double the signal that you would in the middle of the carriage. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner in real world
On Wednesday 16 September 2009, Alexander Lehner wrote: On Tue, 15 Sep 2009, Cry wrote: BTW: Next gen freerunner should use OLPC style screen. Low power digital ink screen would be perfect for daytime phone use. Thats perfectly true. I've got one OLPC and the screen is really amazing. Unfortunately, the lady who did the screen development, Mary Lou Jepsen, has left the OLPC project as far as I know. Too bad that good things seem to die too early... She's continuing development at PixelQi and they're supposed to be releasing netbook size screens shortly. I would love to see this technology in an open phone, but in the meantime a transreflective screen like the one on the Flow would be good. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dbus api for gta2 accelerometers
On Sunday 13 September 2009, Rask Ingemann Lambertsen wrote: On Sat, Sep 12, 2009 at 07:50:26PM +0200, Ivo van den Maagdenberg wrote: The use case is as follows: take the openmoko and make it a cycleway shock measuring platform, utilizing the accelerometers. So, direct reads from the are going to be needed. The gps unit is of course of interest to make the measurements location-based. I've had an idea along the same lines: Use accelerometer data to log the position of points during a train ride. Only, I'd need GPS readings that are accurately timestamped, i.e. not rounded to whole seconds. I think you can get the more accurate timestamp if you talk to the GPS direct in UBX format as omgps can. I don't remember whether the NMEA output uses integer or fractional seconds on this unit. Gypsy uses integer seconds since epoch as its timestamp, and I think this is where the rounding occurs. fso- gpsd reads from gypsy so inherits the rounding. Out of interest why you want to know the position of the points, and how do you intend to distinguish them from a lateral track defect? As a former railway test engineer I'm interested. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: For all ya BFS (brain fuck scheduler) lovers out there
On Monday 14 September 2009, Paul Fertser wrote: Hi, Thanks to LKML discussion there's an interesting switch found that reportedly makes CFS behave as good as BFS for typical desktop workloads. Read all the details at [1] and to try it on your devices, simply do: mkdir /debug mount -t debugfs none /debug echo NO_NEW_FAIR_SLEEPERS /debug/sched_features It will magically solve all the problems but i hope it can improve experience at least somewhat. [1] http://marc.info/?l=linux-kernelm=125260838709566w=3 According to a later post[2] the mounting should be unnecessary, and this should be sufficient: echo NO_NEW_FAIR_SLEEPERS /sys/kernel/debug/sched_features [2] http://www.gossamer- threads.com/lists/linux/kernel/1128181?do=post_view_threaded#1128181 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debian first experience made a bit easier...
On Monday 14 September 2009, Nikita V. Youshchenko wrote: Not for arm but for fso-controlled device. Or more precisely, for $DISPLAY on fso-controlled device at runtime, not installation time. Cant think out a use case when same device will run a window manager (or whatever component that uses .desktop files) sometimes with fso and sometimes not ... Eh? $DISPLAY can point to another device than the one running the window manager and/or launcher, this setup is standard practice in the X world. Sure. I use such configurations heavily myself. But doing so from a phone-like device is a very strange idea IMO. Could you find a useful use-case for that? Nice as the FR screen and illume keyboard are, I sometimes wish I had a bigger screen, or a real keyboard. Or a mouse. Navit and tangogps in particular benefit from a bigger screen. Until recently neither were on my netbook, but a quick bit of display forwarding took care of that. I've also used it while developing python apps because it's more convenient to have app appear on the screen where I'm doing the editing. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] first impressions
On Friday 11 September 2009, William Kenworthy wrote: On Fri, 2009-09-11 at 10:35 +0100, Rui Miguel Silva Seabra wrote: On Fri, Sep 11, 2009 at 09:21:31AM +0800, W.Kenworthy wrote: On Thu, 2009-09-10 at 19:12 +0100, Rui Miguel Silva Seabra wrote: On Thu, Sep 10, 2009 at 07:39:02PM +0200, arne anka wrote: Then where do you have any OK button? ok, it's called quit. And it's utterly useless, in fact I'm thinking of writing up a few small-screen usability recommendations for our friendly apps. One of them is: don't use quit/close/... buttons, they waste valuable eral estate and you can close the windown easily in an alternative way (panel, click on close). Rui Hooray - sense at last. Coming up with a user oriented interface, not a programmers idea of what he personally likes will be a great step forward. I like close buttons, but consistency is more important I think. And please, please get rid of those dumb sliders used where radio buttons are used :) A slider makes more sense (at least to me) than a radio button with two options :) Rui Might be cultural preference perhaps? To me a slider means an analog value, on/off and similar are discrete, unconnected values so should be represented as such. I remember physical slider switches with 2 to 4 discrete positions, so perhaps it seems more natural to me. The same goes for 3-position toggle switches and multi-stop rotary switches. Also, I cant remember any other HCI interface that uses sliders like this. The iPhone is the obvious one, though I first remember seeing them on audio software that was trying to look like a physical effects unit and/or synth. I am also biased in that the slider designs used in shr dont work well - when using a finger they often require multiple swipes before they work, or you miss the active area all together - especially when moving and you are trying to set a slider while walking/carrying other items, ... Are you thinking of the buggy wifi switch in shr-settings? You'd probably be just as upset with the same code on a checkbox when it refused to change state when you clicked on it. I suspect the intent behind the slider is to get around the unintended button clicks when trying to drag-scroll, but it may just have been cosmetic. I don't have the same trouble you do operating them in the absence of bugs, but that comes down to preference, habit and finger size I guess. I don't know if E is sufficiently flexible to theme around the problem. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] wakeuptime, was Re: 2.6.31 is out, where is my ultimate kernel?
On Friday 11 September 2009, Matthias Huber wrote: Today i did another test, because i patched qi with ghex for giving the kernel loglevel=0, and my result today (look at the bottom for version) was: ONE Ring until i get shr-todays slider to see. That is ok for me. On that there is the question: Why is qi delivered on the repo with debuglevel 4 ? Because it's a fair tradeoff between speed and getting some debug information if something goes wrong? If booting from SD the loglevel is easily changed anyway. It would be just as easy for NAND if Qi could read jffs2. You can also change the loglevel at runtime as suggested in the shr tweak/customisation guides. This will be just as effective for resume, but not as fast for boot. Warren Baird schrieb: On Thu, Sep 10, 2009 at 2:15 PM, Matthias Huber matthias.hu...@wollishausen.de mailto:matthias.hu...@wollishausen.de wrote: Hmmm it takes three rings until i can get the call (heear a ring and get a GREEN Button. Don't think, this is fast. Which distro? I used to have this problem with OM2008 - I missed a bunch of calls because of it and then switched to QTEI. I've since tried OM2009 and am now using SHR-U, without this issue. If I call myself from a land line using SHR-U, I see the screen turn on at exactly the same time as I hear the ring on the land-line, and the FR starts to ring before the first ring on the landline finishes. I don't have a stop-watch, but it certainly seems fast enough. Distro is shr-u, with all updates of yesterday ~17:00h GMT with my GREEN BUTTONS and my own Ringtone. What firmware do you use ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Web site promoting open hardware?
Short answer as an end user: because I want to be able to fix or modify stuff I buy, not rely on the whim of the manufacturer. Longer answer: Products are rarely exactly what I want, and I'm not afraid to modify them to get what I'm after. Access to mechanical and electrical dessign documentation makes this both easier and more effective. With software-based products the openness is more necessary. My TV contains some GPL software, but nobody has worked out how to build a complete firmware image, let alone load one, so I can't readily fix any of the niggles or add features. Also I hate arbitrary limitations and designed obsolescence. Phones are a good example; why should I need to buy a new handset to get a feature the existing hardware is capable of, and supposed to have, but doesn't because of botched firmware the manufacturer has decided not to fix? Why is this simple software feature only available on the 'pro' model at 3 times the price, or not available at all? Finally I find the faults somehow less irritating when I know I could fix them if I could be bothered. Small scale commercial answer: because custom software on an existing open platform can make small market niches commercially viable when they wouldn't be otherwise. On Friday 11 September 2009, Wolfgang Spraul wrote: Stefan, what would drive someone to this site/list and what are the criteria people are looking for? I think at some point I will start to work on a table of 'hackable' hardware, because at least technically it's relatively easy to pin down features: Reflashable, unbrickable, all drivers in source form or some in binary, toolchain open, schematics/datasheets/layout/BOM published or not, etc. But this is only interesting to hackers, not normal users. What if a company supports the free software scene covertly (quite a few do because the reason they fear openness are patents, not hackers)? Who should 'rank' or 'qualify' hardware makers for how 'open' they are? I think we first need to define why someone is looking for openness, and what they expect from it. Can you explain your motives? What makes you interested in Openmoko, Qi, OpenPandora, etc.? Thanks, Wolfgang On Thu, Sep 10, 2009 at 11:00:49AM -0400, Stefan Monnier wrote: While looking for new hardware, I noticed that all the open hardware I know, I discovered it by accident while reading some mailing-list. Is there a web site somewhere that kind of centralizes this info to try and make it easier for openness-conscious consumers to find appropriate hardware? Of course, there are various notions of open hardware, so there might be parts of the site for hardware-hackers, for example, but I'm more interested in a web-site for end-users. Also it might include hardware that is not itself open source, but where the company states a clear commitment to Free Software principles. I.e. a site that links to things like Openmoko, Qi, AlwaysInnovating, maybe Lemote, OpenPandora, ... Any hint? Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: udev rule for the freerunner or make usb networking enduser friendly
On Wednesday 02 September 2009, Olivier Migeot wrote: On Wed, Sep 2, 2009 at 6:41 AM, c_ccchan...@yahoo.com wrote: Hi, Same here - just a static ip for the fr's mac address on ubuntu works great for me. I've been on static IP for quite a while, but between work and home it was starting to get messy. With udhcpd, it's now much more convenient. I could even decide to change the Moko's network for something less common than 192.168.0.0 at no cost. The best would be to have a very light dhcpd daemon who only runs on USB insertion, serves only one address with a very long lease, and then dies after a few minutes. But maybe I'm dreaming there ;) Check dnsmasq which is available in OE, and provides a lightweight caching DNS server and DHCP server. I don't know if it's in the SHR feeds or not, but it worked well when I tried it a while back. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Litephone 0.1
On Thursday 10 September 2009, Michal Brzozowski wrote: 2009/9/10 Arigead captain.dea...@gmail.com Thanks a million for the update. I tried litephone on SHR-U for the first time yesterday and tried to send a text message test message hello. That got displayed in litephone as ttes meessag hello which I thought was funny as. I was going to ask if there were any updates or where the repository was today. You beat me to it downloading now ;-) Can you go to sent messages and see what has been sent? My guess is that you typed in the misspelled message using the predictive illume keyboard. Someone has already reported this, and my guess is the bug is somewhere between illume and qt (maybe the fakekey events get swapped because illume sends them all without a delay or something). Sounds to me like the Qt input event reordering bug, but I thought it would be fixed by now. http://lists.trolltech.com/qt-interest/2008-10/thread00773-0.html ___ 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
On Thursday 10 September 2009, Olivier Migeot wrote: On Thu, Sep 10, 2009 at 1:26 PM, Al Johnson openm...@mazikeen.demon.co.uk wrote: Check dnsmasq which is available in OE, and provides a lightweight caching DNS server and DHCP server. I don't know if it's in the SHR feeds or not, but it worked well when I tried it a while back. How lighter could it be than a /bin/busybox symlink? ;) I thought busybox only did the client end. Good to know I was wrong :-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: vi vs. nano in shr user manual (was Re: SHR first experiences user manual)
On Friday 28 August 2009, William Kenworthy wrote: On Fri, 2009-08-28 at 11:00 +0300, Risto H. Kurppa wrote: see http://wiki.openmoko.org/wiki/SHR_User_Manual#Audio:_Volume ... Wait a sec - did I understand correctly that you want to tell people to use vi in the user manual? So I take you expect that people going through the manual are skilled enough to use vi and if not, they'll be smart enough to use nano instead? Maybe the manual should explain how to use vi: how to save, exit etc.. I have no idea how to use it. Maybe a link to vi howto? I have no problems accepting that some prefer more vi than nano but I have hard time accepting it being suggested in a manual where you can't be sure people know how to use it as it isn't as self-explanatory as nano, no matter how much Ctrl you have to use. r I would agree with Risto here - vi is great for experienced users, but for the inexperienced or pure user - it can be a nightmare experience that provides detractors with plenty of ammunition that linux is hard to use, for geeks only and not for serious use ... Agreed. Even the Gentoo install guide uses nano for its examples. The inexperienced can use it, and the experienced will just substitute their preferred editor anyway. Idea, have guides for both (if not nano then something similarly easy to use - a dos edit clone of some kind for compatibility, nedit?) - linked from the manual. There are plenty of vi guides out there, and probably for most other apps as well. The idea should be to guide and inform, catering for both experienced and inexperienced (to both the FR and linux) users. It seems rather out of scope to me, as well as fertile ground for 'why isn't app x included whey you include app y' arguments. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-Devel] New features in opimd queries
On Thursday 27 August 2009, Thomas Zimmermann wrote:
Am Donnerstag 27 August 2009 00:08:44 schrieb Kero van Gelder:
If you set _at_least_one to some non-false value, opimd will switch
into at least one field mode. Query {'Name':'dos', 'Content' :
'Test', '_at_least_one': True} will return entries with Name = dos
*or* Content = Test. Without '_at_least_one', opimd checks if entry
matches to all fields in query (so Name = dos *and* Content = Test) .
Now you can also query values greater or lower than specified. To do
that, you can use '_gt_Timestamp' or '_lt_Timestamp' fields (replace
Timestamp with whatever you want). Those field names are equal to
'_float_gt_Timestamp', '_float_lt_Timestamp'. There are also
'_int_gt_Timestamp' and '_int_lt_Timestamp' fields which you can use
with integer values, when you don't need float. Maybe it gives some
performance speed-up ;)
Is that _gt_20090101: birthday or _gt_birthday: 20090101 ?
(and if the latter, I think _birthday_gt: 20090101 reads better since
it is infix notation; I find prefix notation ambiguous to read)
I have no idea why you want to make a distinction between floats and
int on dates. Either your underlying format is based on floats, or it
isn't. and I would need to know whether your int is a day, or a second.
Instead, I'd like you to convert my query to the underlying format, so I
do not have to worry about it, ever.
In my experience, using OS native time is no too bad. -131 is
December 1901, there are not too many things I'd like to put in a
pim suite, that happen(ed) before that. And I guess anything non OS
native is likely slower than OS native. That's assuming the comparison of
timestamps is taking more CPU cycles than parsing my timestamp-string in
the first place.
Bye,
Kero.
I think Sebastian implemented these gt and lt functions because of me. I
need them for opimd-dates.
The Problem with a timestamp string is: what format does it have? In this
case we have to include the format defenition into the API. Then it's a lot
easier to use unix-timestamps they are easy to parse and compare...
Is there any documentation for date related opimd entries? I'm worried that if
timestamps are being used for date/time storage there will be no way to store
timezone.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] How to hold my FreeRunner so the other end can hear me clearly?
On Wednesday 26 August 2009, Brolin Empey wrote: Is there any way to make this position practical, other than using a headset? Increase the mic gain. http://wiki.openmoko.org/wiki/SHR_User_Manual#Audio:_Volume http://wiki.openmoko.org/wiki/Neo_Freerunner_audio_subsystem#Alsamixer_channel_controls ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all / linux] neo as gps unit?
On Saturday 22 August 2009, Stroller wrote: On 21 Aug 2009, at 16:15, Al Johnson wrote: On Friday 21 August 2009, 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... ). Then block it in the default iptables rules Is iptables sure to be running by default? If it isn't already then it should be, with some sensibly safe defaults. Since we're talking about changing default settings I don't see why we shouldn't consider the default state of iptables too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Getting location info from cell tower
On Friday 21 August 2009, c_c wrote: Hi, Going to a different geographical location gives me the location string of the new cell for the first time. But, re-starting launcher doesn't. Something to do with the calypso? Or the cell tower. Have you tried unregistering then reregistering, or shutting down then restarting the GSM module? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all / linux] neo as gps unit?
On Friday 21 August 2009, 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... ). Then block it in the default iptables rules ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what recamping rate is considered normal, if any?
On Friday 21 August 2009, Nathan Kinkade wrote: I'm running SHR unstable. A number of days ago I decided to try to turning ti_calypso_deep_sleep to adaptive to see what would happen. Everything *seems* okay, and though I haven't done any formal test of battery life some anecdotal evidence would seem to indicate that battery life has gone up significantly. I turned on DEBUG level logging for ogsmd, and I *do* see the messages about checking for TI Calypso recamping bug..., but they aren't all that frequent. Sometime it detects an unexpected recamp in as few as 5 minutes, but it usually seems to be once every 10 to 20 minutes. In total the phone recamped 19 times in 9998 seconds, which is very roughly once every 9 minutes on average. So my question is whether some recamping is normal, or if it should really not happen at all when a phone is stationary? If some is normal, what might be considered an acceptable rate, without much risk of randomly loosing calls or missing SMS? Recamping is only normal for buggy hardware ;-) It sounds like you have the intermittent recamping I often experience, which is too slow to trigger the automatic detection. Note that it is temperature sensitive, so if it gets warmer you will probably see the rate increase. What's acceptable is up to you, and how your network responds to it. It seems to cause problems for me with O2 but not with t-mobile or orange in the uk, but I may just have been lucky with them and unlucky with o2. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bugfix for #1024 (gsm modem re-camping) done
On Friday 21 August 2009, Fox Mulder wrote: Now i only need a reliable testcase where i can see if the rework helped or not. Is there any scenario i can try to find out if #1024 is fixed or not? Good to see the pics. All I can suggest is to enable deep sleep, enable logging to file on SD, and use the phone. If after a week you don't have any recamping instances in the log file then it's probably fixed. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner audio channels
On Tuesday 11 August 2009, David Fokkema wrote: On Mon, 2009-08-10 at 20:06 +0400, Paul Fertser wrote: David Fokkema dfokk...@ileos.nl writes: On Sat, 2009-08-08 at 15:05 +0400, Paul Fertser wrote: Unfortunately, there's no way to find out which devices are affected by this bug judging only by revision and serial number as BOMs were lost due to an incorrect file format conversion, one needs to actually try and see for himself. If I open up my phone (have to do it someday, right?) how can I distinguish a 0R from a 1uF? Unlikely since those caps are under a can and dismounting it requires extra effort and you can damage something doing it. How many cans are there inside a freerunner? I'll have to study the schematics and really have to open this thing. Three, but only the two larger ones have potential hardware fixes under them IIRC. The can for the audio fixes has the bluetooth flexi glued to it, so it needs very careful treatment. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: enlightenment still crashing
On Tuesday 11 August 2009, Michal Brzozowski wrote: 2009/8/11 Al Johnson openm...@mazikeen.demon.co.uk On Tuesday 11 August 2009, Michal Brzozowski wrote: Enlightenment is still crashing. Very easy to reproduce. Set the keyboard to none, run any application full screen. Is there a chance anyone will fix it? I'm suffering for over 2 months from this already (when I forget not to touch the fullscreen button). All distros. Do you have a link to the bug report? No, it's been discussed a few times on this list. Then please file a bug report. The devs can't keep track of everything mentioned on the list, but can easily get a list of outstanding bugs on the tracker. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [shr-u] wifi timeout with mokonnect
On Wednesday 12 August 2009, Paul Fertser wrote: Adolph J. Vogel ajvo...@tuks.co.za writes: Im sorry if this is an obvious question, but what kernel is wifi bug free? There's no such kernel in existance. And wifi firmware is not bugfree and most probably will never be. Blame Canada^W Atheros. Or buy a decent usb wifi dongle. :( Given that 2.6.28/9 has had at least one kernel bug with wifi support on the FR it isn't unreasonable to ask whether the currently distributed kernels have all the known bug fixes applied. It wouldn't be the first time that known bug fixes haven't been applied in the shipping kernel. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: enlightenment still crashing
On Tuesday 11 August 2009, Michal Brzozowski wrote: Enlightenment is still crashing. Very easy to reproduce. Set the keyboard to none, run any application full screen. Is there a chance anyone will fix it? I'm suffering for over 2 months from this already (when I forget not to touch the fullscreen button). All distros. Do you have a link to the bug report? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner audio channels
On Monday 10 August 2009, David Fokkema wrote: On Mon, 2009-08-10 at 15:53 +0400, Paul Fertser wrote: Alexander Shulgin alex.shul...@gmail.com writes: On Sat, Aug 8, 2009 at 14:05, Paul Fertserfercer...@gmail.com wrote: David Fokkema dfokk...@ileos.nl writes: The fact that Freerunners differ in audio quality and settings has been stated on this list and on support. And going by the last paragraph, this is true. So, _why_ are Freerunners different? One of the problems is that some freerunner revisions are in fact different in hardware. Most devices have 1uF capacitors instead of R3004/R3005 (which should be 0R), and that's not a joke. That is earpiece path and not surprisingly that devices that have those capacitors have considerably lower sound volume from the earpiece. And what do I do if I happen to have one? Tweak alsa state files appropriately. There's a routing diagram on the wiki that explains everything needed. If that doesn't really cut it, is it possible to swap the 1uF for a 0R? Gotta make a list of hardware fixes to perform, ;-) If you need to ask you probably can't do it yourself ;-) Schematics and component layout are available, and shorting a cap shouldn't be too hard. The components are small, and not far from the headset coupling caps. See sheet 3 of the component layout under the bottom right corner of U3001. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Screen in FR goes black and white after resume from suspend
On Monday 10 August 2009, Paul Fertser wrote: Rask Ingemann Lambertsen ccc94...@vip.cybercity.dk writes: Do you know any system-level dev who's interested in supporting u-boot? I am. Cool, good to know. I was under the impression everyone's abandonded it on FR. No. There are a few things that uboot can do that Qi can't yet, and some of us need them. There was a thread about it not long ago. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner audio channels
On Friday 07 August 2009, David Fokkema wrote: Hi list, I finally took a lunch break to check out the various alsa channel settings. Angus's mixer scripts rock, BTW! Trying to track down the input for the handset, I've looked at the wolfson schematic, browsed through the handset state file and can only come to the conclusion that the audio path is completely circumventing the digital filter module. Why is that? We're only using the sidetone path and mixing that as the only channel into the output. The rest is disabled (volumes set to 0 and switches set to False). Reading up on what sidetone actually is (wikipedia) I get the feeling that we're not supposed to do this. Ok, it works, but the sidetone path was never intended for this purpose, I gather, but rather to provide feedback to the speaker's earpiece. I tried to decipher the various wiki pages dealing with audio and the conflicting posts on alsa settings and played with Angus's mixer during a phone call (FR in my one hand, landline with covered up mouth piece in my other) and noticed that setting Mic2 Capture Volume to 0 does _not_ mute the Mic. It _does_, however, enable me to set the Mono Sidetone Playback Volume quite high (6 / 7) as well as the Mono Playback Volume (100 / 127). This post is not intended to start another discussion on 'best' settings, but maybe some of you know the answer to these questions: - Why exactly are FR's different while I've never heard of Nokia users needing to tweak mixer settings. Most phones have a simple volume up/down control, often a pair of buttons on the left side of the handset. They hide most of the functionality of the mixer chip which is fine so long as it what you want and what they chose to implement are the same. So far nobody has written a similarly simple volume control for the FR. - Why does setting Mic2 Capture Volume to 0 _not_ (almost) mute the mic? Mic2 has four fixed gain settings of +12dB, +18dB, +24dB and +30dB which are represented by 0, 1, 2 and 3 in the alsa driver. Mute is not an option, though IIRC you could switch that amp off. See page 20 of the Wolfson datasheet. - Why do we bypass the digital filters by using the sidetone path? The digital filters are for ADC and DAC which we aren't using in phone calls. We are passing analogue signals through to the Calypso which has its own filters, ADC and DAC. The only possibly useful bit there is the AGC/Noise Gate, but AFAIK nobody has managed to get it to do anything useful so far. Apps which record the phone call, or play sound into the call, will be using the ADC and DAC, so will include the filter blocks. Remember that our use of the chip is not typical. Most would probably be using the digital voice interface to connect to their GSM chipset instead of using an analogue passthrough as we are. We use the voice interface for a digital connection to the bluetooth module instead. Maybe this information is buried somewhere but I can't unearth it. Thanks! David PS: It seems that I can now use my FR to actually make phone calls, ;-) PPS: If these questions are answered, maybe I'll stick my neck out and delete all conflicting information on the wiki and write a small 'How to set your mixer settings appropriately?' PPPS: I'll not do anything rash, I promise. However, it would be nice to reach some kind of consensus and clean up the wiki. It took me far too much time to tweak my phone to make calls without noise, echo etc. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
On Thursday 06 August 2009, Michal Brzozowski wrote: 2009/8/5 Sebastian Krzyszkowiak seba.d...@gmail.com This way you could have for instance voip:d...@shr.com voip%3a...@shr.com, skype:dos or something else. But of course it would be nice to discuss it with FSO guys. You suggest 'Peer' : 'tel:+xxx' or 'Peer' : 'voip:a...@bbb'. How about putting the prefix in the attribute name. 'Peer_tel:' : '+xxx' or 'Peer_voip' : 'a...@bbb'. Now it's like nesting attributes in attributes. Why force people to additionally parse the data. If the content is a proper URI then we shouldn't have any trouble parsing it. tel: is the right way to start a phone number URI. See RFC3966. voip: is probably wrong, but sip: or h323: are well defined. The problem here is having two fields but at least three independent properties. We have at least: * Communication medium (voice, text, video, etc.) * The URI which gives protocol and address * Disambiguation of more than one of the above, possibly indicating association (Home, Office1, Office2, Mobile etc.) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OPIMD: List of available attributes documented?
On Thursday 06 August 2009, Sebastian Krzyszkowiak wrote: On 8/6/09, Al Johnson openm...@mazikeen.demon.co.uk wrote: On Thursday 06 August 2009, Michal Brzozowski wrote: 2009/8/5 Sebastian Krzyszkowiak seba.d...@gmail.com This way you could have for instance voip:d...@shr.com voip%3a...@shr.com, skype:dos or something else. But of course it would be nice to discuss it with FSO guys. You suggest 'Peer' : 'tel:+xxx' or 'Peer' : 'voip:a...@bbb'. How about putting the prefix in the attribute name. 'Peer_tel:' : '+xxx' or 'Peer_voip' : 'a...@bbb'. Now it's like nesting attributes in attributes. Why force people to additionally parse the data. If the content is a proper URI then we shouldn't have any trouble parsing it. tel: is the right way to start a phone number URI. See RFC3966. voip: is probably wrong, but sip: or h323: are well defined. The problem here is having two fields but at least three independent properties. We have at least: * Communication medium (voice, text, video, etc.) * The URI which gives protocol and address * Disambiguation of more than one of the above, possibly indicating association (Home, Office1, Office2, Mobile etc.) That's what we need :) Home, Mobile, Office etc. is done by prefixing field name (Home phone, Mobile phone). URI is also there, but I don't have idea how to indicate and use communication medium. Does someone have any idea? The medium and disambiguation parts are properties of the URI, and could have multiple entries which may be interdependent. A SIP address is a fine example of how it could get tricky since it could be used for voice, video or text, but you may not have video capability on your phone SIP client like you do on the PC at home. There may be other properties you want to associate too. vCard partially expresses this with its TYPE= entry, and we could express it something like: X-FSO-VOICE;TYPE=home,cell:sip:usern...@example.com X-FSO-TEXT;TYPE=home,cell:sip:usern...@example.com X-FSO-VIDEO:TYPE=home:sip:usern...@example.com It's a pain for interoperability though, like all vCard extensions. Trying to squeeze this sort of data into two fields sounds like a bad idea to me, but I'm not familiar enough with what's allowable in dbus to suggest anything better. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Fun] Have you ever wondered of the GPS chip accuracy?
On Tuesday 04 August 2009, Laszlo KREKACS wrote: I got two questions regarding the gps chip, maybe someone can answer me: - is there some settings, where I can fine-tune the gps chip? (I think what is the method to calculate the average speed? Is it adjustable?) If you talk to the GPS directly using the UBX format you can change the mode to match your vehicle/usage type. This changes some of the assumptions it makes in location estimation. This isn't available through the FSO interface, but at least ome app (omgps?) is using it. Links to the UBX docs were in the wiki last time I looked. Remember you will have to disable ogpsd before you use it this way. - Is there a way to ask for gps coordinates faster then one second? (for running 0.1 sec would be awesome). And why the time is only reported in sec unit? (not fraction of the second) 1249424982.764385 vs. 1249424982 Is it a limitation of the gps chip? This came up on the list before. IIRC you can ask the GPS for more or less frequent reports, and the integer seconds are due to the FSO implementation rather than the GPS. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [all] gui development for several platforms
On Tuesday 04 August 2009, Petr Vanek wrote: hi, i am working on a real simple real time tracker program (mainly aprs) , in python. although primarily targeting freerunner, therefore will be using most probably Elementary, i have another friend running G1. could someone recommend GUI libs that would make this possible? GTK? or not possible at all? AFAIK you can't use any other gui libs with android. I think the best you can hope for is a common backend with separate gui code for android and non- android. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Home automation with Open moko
On Friday 31 July 2009, sriranjan wrote: Patryk Benderz wrote: Will a dongle that attaches to FR and an embedded system that connects to home grid and then be able to control your home appliance from FR be a product worth a consumer market? Yes, but i would prefer to control such a grid by wifi or bluetooth, without wireing/connecting any dongle to FR. But bluetooth is of a limited range.Say you are in you car and coming home and you want to get your heater up and running so that you can have a hot bath.Now if you have an Xbee say 500 m or 1km you are from your home you can switch it on and by the time you get there it will be hot. Poor choice of example - if I had a heating system that needed such a trigger it would take longer to get up to temperature than the travel time from 1km away, even by foot. For long range control I would be looking at internet or phone based systems like asterisk or CSD dialin connection. There does seem to be a market for wireless touchscreen home remotes, many of them very expensive. I doubt this market would accept a dongle - it just wouldn't look cool enough. If you can build it into the FR, or recase it to enclose the dongle, you may be able to sell into that market. You probably won't find any overlap between that market and this list though - we're by definition internet-centric and likely to build our own solution. There may also be some resistance to ZigBee's GPL incompatibility and IP policies. http://freaklabs.org/index.php/Blog/Zigbee/Zigbee-Linux-and-the-GPL.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: testing Litephone, new phone interface
On Monday 03 August 2009, Michal Brzozowski wrote: 2009/8/3 Helge Hafting 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. 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. That sounds much better than popping up the phone window. Remember to make sure these appear somewhere other than where the keyboard is though! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Document with answers to most popular battery-related questions is ready
On Monday 03 August 2009, Timo Juhani Lindfors wrote: Timo Juhani Lindfors timo.lindf...@iki.fi writes: Could the capacity measurement get confused during long storage? Answering to myself here: When I charged the battery capacity increased steadily but when it reached 67% it suddenly jumped to 100% in one minute. I think this concludes that the capacity reported by Linux is not always correct. Where exactly is this figure from? Are you looking at the battery monitor sysfs entry, or something that gets the incorrect figure from hal? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: List of bluetooth headsets
On Saturday 01 August 2009, fredrik normann wrote: Does headset with jackout exist as well, would be cool to have a jack out on the headset for connecting to a HiFi Stereo... :) Jabra BT3030, and at least one Motorola model. Both are small units with built in mic and 3.5mm headphone socket, and have buttons to control media playback via AVRCP. I think the Motorola has an LCD too, for display of track info and caller id. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [fso] rules for bluetooth headset: BTHeadsetIsConnected() is always true
On Saturday 01 August 2009, arne anka wrote: the rules listed for bt headsets http://wiki.openmoko.org/wiki/Manually_using_Bluetooth#Once_Again.2C_Blue tooth_Headset_on_Freerunner use a filter BTHeadsetIsConnected() which seems to me quite unreliable. where does fso get its ideas from about connected headsets? - even if i disable bluetooth, still the filter applies - even if the headset ist off, the filter applies - even if Headset.Disconnect returns a Disconnect failed: org.bluez.Error.NotConnected, the filter applies that means, that gsmhandset.state never is loaded again, making it impossible to make or answer calls. At present the headset connection seems to be read from the config file at daemon startup, and doesn't seem changeable without editing the config file and restarting the daemons. I can only assume the plan is to make these changes in response to bluez signals, but that it hasn't been implemented yet. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Home automation with Open moko
On Friday 31 July 2009, sriranjan wrote: Hi all, Will a dongle that attaches to FR and an embedded system that connects to home grid and then be able to control your home appliance from FR be a product worth a consumer market? I'm not sure I understand exactly what you are proposing. Most (possibly all) the home automation systems I'm aware of have IP control interfaces either by default or as an option, usually through a browser. The FR should be able to control those already via WiFi, and would probably be very good at it. Or are you proposing adding a dongle to connect directly to one of the wireless home automation protocols like ZigBee or LonWorks? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone 0.61 Almost Stable ;-)
On Wednesday 29 July 2009, c_c wrote: Hi, Al Johnson wrote: You may be able to sidestep this by using the org.bluez.audio.Control dbus interface, but documentation seems somewhat lacking. Thanks for your offer. Actually, I'm not so clued up on bt - not having been able to even get any sound out of my bt (Jabra 125) handsfree. The lack of documentation is quite awkward for something that seems this popular. Do let me know if you find anything. The best docs I've found so far are in the bluez source tarball. They actually have a description of what each dbus call is supposed to do, but not how everything is supposed to fit together. It looks like the plan is now different to the one in the wiki, and that the org.bluez.Control interface which my BT3030 seems to have is intended to control things on the device, not the other way around. It looks like I may be able to access the headset's volume control through it though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone 0.61 Almost Stable ;-)
On Tuesday 28 July 2009, c_c wrote: Dan Staley wrote: Occasionally the key presses from my headset stop being picked up by intoneit looks like they are being sent to the phone because the screen will turn on, but intone doesn't respond Well, can you run intone from the terminal and see if it prints the keypress it receives? If it prints the keypress intone should respond to them. If it doesn't print - that could be because the keypresses are not getting through either because of :- * a locked screen * some other app gaining focus (like if you receive a message etc) Can you confirm this? You may be able to sidestep this by using the org.bluez.audio.Control dbus interface, but documentation seems somewhat lacking. I'll try poking it when I get my headset going. This seems to be all the documentation there is at the moment: http://wiki.bluez.org/wiki/Audio ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Seeking Extra Packages for FSO Milestone 5.5
On Tuesday 28 July 2009, Jeff Rush wrote: In case the answer is opkg.org, I'm puzzled by that site. It doesn't have indicators or a way to search by OM distribution, eg. SHR, FSO, DEB, etc. I'm sure every package is not OM distribution agnostic, so how are people managing this kind of compability? Is opkg.org actually the official place to obtain solid, tested packages for an FSO Milestone? You've correctly identified the main drawback of opkg.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: battery not fully charging
On Monday 27 July 2009, pike wrote:
Hi
Since this week, my battery isnt charging to the fullest anymore.
mdbus -s org.freesmartphone.odeviced \
/org/freesmartphone/Device/PowerSupply/battery \
org.freesmartphone.Device.PowerSupply.GetInfo
after loading a full night:
{ 'capacity': '96',
'charge_full': '1121337',
'current_now': '29437',
'health': 'Good',
'online': '1',
'present': '1',
'status': 'Charging',
'technology': 'Li-ion',
'temp': '313',
'time_to_empty_now': '138840',
'time_to_full_now': '3932100',
'type': 'Battery',
'voltage_now': '4128000'}
Your battery is ok, it reports 96% of charge ('capacity').
is it charged ? the icons say its at about 50% ?
its been on juice for near 12 hours.
You didn't mention the distro (or I missed it), but the illume battery icon
has been known to report wrong values. IIRC this is because it gets the battey
info via HAL, and reports the average if more than one battery is found. HAL
sometimes reports the USB connection as an empty battery, effectively halving
the charge level shown by the battery icon.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Reducing resume verbosity with Qi
On Friday 24 July 2009, William Kenworthy wrote: I am using Qi to boot a gta02 to a flashed shr-unstable (not on SD) It works ok, but after a few resumes it slows dramaticly due to verbose printing to the screen. Is there a way to fix this? With u-boot, I reduced the kernel verbosity to get a happy medium, but it looks like Qi cant do this unless you are booting from SD. That's correct as I understand it. Qi doesn't understand jffs2 so it can't read the usual file where the extra options would live. You should be able to drop the loglevel at runtime using: dmesg -n 4 This sets the console log level to warnings and above. It won't help with the boot time, but does a lot for the resume time. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Open Hardware company
On Friday 24 July 2009, Christoph Pulster wrote: 3. the PDA clam-shell form factor is obsolete Not a single one commented negatively about the clamshell. Psion Plc. invent the clamshell and set the top-level of usable keyboard verses form-factor with Series 3 twenty years ago. Then raised it again a few years later with the Series 5 We are in the SMS/twitter age now. Some vitual keyboard with multi-touch usability is sufficient. People who want to write full sentences buy a pencil with white paper. If that were true RIM wouldn't be doing so well. I still want a Series 5 with modern hardware inside and a screen from PixelQi, and I know several former Psion and Nokia Communicator owners who would agree. It may be a niche market, but it's a reasonably large niche that's currently unserved. The quality of the keyboard is critical here. In general, what advantage does the NanoNote have to an Iphone with Linux installed ? Price. Keyboard. Not having a capacitive touchscreen. No problem with scratched or broken screen because the clamshell provides protection. But they really aren't comparable devices anyway. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Open Hardware company
On Friday 24 July 2009, Tony Berth wrote: I wouldn't care about Sisvel. Let them try to sue you in ... China :) What Sisvel 'defines' is useless and they know that. How may chinese companies were sued anyway? :) Christoph's problem is that as a reseller he's the one that gets sued, or has his stock seized by customs. It's no good being right if you can't afford to take it through court, and Sisvel know that too. On Fri, Jul 24, 2009 at 10:41 AM, Christoph Pulster openm...@pulster.dewrote: 3. you got no MPEG-patent licences. We don't need them. Nobody needs them, but you have to pay them anyway. (Sisvel definition: any piece of HW who can decode MPEG algorith) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [TI Calypso] I know it's NDA'ed but ...
On Friday 24 July 2009, Nekron wrote: I wonder what will happen to the TI Calypso stuff inside the Freerunner? Now that OM stopped business who will take care of the GSM modem part and fix issues if they are found? As a now full community supported mobile hardware platform wouldn't it be possible to contact TI and release the Calpyso SDK under some community license? I mean the GSM modem is an old one and why can't it be de-NDA'ed by TI? It probably wouldn't hurt to ask, but don't get your hopes up. TI have little to gain, and a release will cost them at least the time taken to ensure they are allowed to release the information. They may not be allowed to release it, even if they wanted to, for a number of reasons including third party rights holders and regulatory rules. Could someone of the former OM staff try to contact them and explain our situation for this or must we live forever with the current state of the GSM firmware as a black box which would be really sad. As for #1024 there is that hardware fix but we will never know if by chance it could be software fixed (I know that the former OM developers had inspected the calypso firmware, however the more ppl would analyse the code the chances are higher that some fix could be possibly found). A good chunk of the code in that area is a binary blob even to Openmoko, which is one of the reasons the problem was difficult to debug in the first place. You are asking for more access than even Openmoko had. Please don't let the calypso stuff be a dead end for us! Opening this part of the device would make the Freerunner even more interesting for developers since it would be (except the glamo *) a truely open phone by then. I think you stand a better chance of getting the Glamo opened than the Calypso! I assume you would like Atheros to open the WLAN firmware too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: om2009 activating wifi
On Thursday 23 July 2009, pike wrote: Hi Is there a way to request WiFi activation from FSO straight from the command line ? Yes, if you search the archive you'll find some mdbus or dbus-send examples, or as saied you may use fsoraw. Sorry, I found none. I'm sure I just dont really know what I'm looking for. Anyway, mdbus helped me out: alltogether this is my way to get wifi from scratch that doesnt die every 20 secs : # keep the screen alive mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \ org.freesmartphone.Usage.SetResourcePolicy \ Display enabled # power up wifi mdbus -s org.freesmartphone.odeviced \ /org/freesmartphone/Device/PowerControl/WiFi \ org.freesmartphone.Device.PowerControl.SetPower True This one would be better: mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage \ org.freesmartphone.Usage.SetResourcePolicy \ WiFi enabled # bounce eth0 ifdown eth0; ifup eth0 # more custom stuff thanks, *-pike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [fso] disable led blinking?
On Thursday 23 July 2009, arne anka wrote: while true ; do sleep 15 ; mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/IdleNotifier/0 org.freesmartphone.Device.IdleNotifier.SetState idle ; done snip... my idea was, that 15s are too long and the fr nevertheless enters lock, but idle_dim+idle_prelock alone account for 32s -- thus the fr should never hit lock. but having a close look at the frameworkd log shows, that indeed 15s are to long. apparently dbus needs far more time and thus the fr hits lock frequently. changing to 10s seems to fit. It's not dbus that's slow, but mdbus which is a python app and takes a while to load. dbus-send is a much better option for scripts as it is faster and uses fewer resources. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om 2008] Re: fixing bug #1024 successful reports?
On Thursday 23 July 2009, Lothar Behrens wrote: Hi, I am also interested to get my daily phone :-) Why not just soldering another 10uF capacitor on top of the other. As I think soldering the capacitor to the shielding on the right yet requires an insulator. I don't think there's enough space under the can. If there had been I doubt people would have been using the methods in this thread: http://lists.openmoko.org/pipermail/hardware/2009-June/001230.html That way no long extra wires may be needed and no unsoldering is required. The method in the post above avoids the long wire and unsoldering, but still needs insulation above and below. Some questions: I have read that making phone calls is impossible with that recamping, but I am able to do phone calls. You can't make or receive the call when the phone isn't registered, and in worst case the phone will spend ~1/3 of the time reregistering. Networks seem to handle reregistrations differently though - O2 UK sometimes thought the phone was switched off when I called it, while Orange and t-mobile always connected. This may have been luck though... I tried to start logging the battery with r...@om-gta02 ~ $ while true; do date mdbus -s org.freesmartphone.odeviced /org/freesmartphone/Device/ PowerSupply/battery org.freesmartphone.Device.PowerSupply.GetInfo sleep 5 done battery-data to compare the data, but I do not have mdbus command and it seems not to be installable with opkg (OM 2008). Where do I get it? It wouldn't help on om2008.x as it isn't using FSO. You should be able to use apm or the sysfs battery entry to get similar information though. See: http://wiki.openmoko.org/wiki/GTA02_sysfs ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: keeping om2009 awake
You can also request the CPU and/or Display resources, or change their policy from auto to enabled. Apps can do this themselves, or use the fsoraw wrapper program when starting the app if it doesn't support it natively. This will request the resource at app start, and release it at exit. On Wednesday 22 July 2009, jeremy jozwik wrote: etc/frameworkd.conf suspend and idle timoutes On Wed, Jul 22, 2009 at 1:31 PM, pikepike-openm...@kw.nl wrote: Hi does anyone know how to keep the om2009 awake ? the related settings in paroli and illume both dont seem to do much on my moko. There must be a Greater Force falling asleep, too. I'm sure its simple and I just missed the writing on some wall. But I cant find it. It annoys me so much that i'm afraid i will hurt its display one of these days :-/ thanks! *-pike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Do I need a FAT SD card? Do I need OM? Do I need... ? Choices, Choices, Choices...
On Monday 20 July 2009, Chris Samuel wrote: On Mon, 20 Jul 2009 02:53:03 am li...@kitepilot.com wrote: Can I just ext3 the SD card ? Be warned, there have been some reports of the journal of ext3 wearing out its part of the SD card. I tend to use ext2 instead. Real reports, or just my card broke and I don't know why, so I'll blame journalling? If there's an its part of the SD card then the wear levelling in the card is broken. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Do I need a FAT SD card? Do I need OM? Do I need... ? Choices, Choices, Choices...
On Sunday 19 July 2009, li...@kitepilot.com wrote: Can I just ext3 the SD card ? I'm not very fond of FAT... You can format it in any thing your kernel will support. ext3 is fine. Also, as of: http://wiki.openmoko.org/wiki/Booting_from_SD It says: WARNING: Booting from SDHC may cause problems at this time (see below). Works fine for me. This may refer to the Neo1973, or to old bootloader versions. Should I even try to boot from the SD card? Are there outstanding issues that I should know of? Some cards don't work reliably at the default clock rate, so you may need a kernel command line switch adding to change it. You may need to change the uboot parameters for kernels 2MB, or use Qi which handles large kernels and boots faster. How small of a card is too small? Will 2GB be usable/enough or should I plan on something bigger/smaller? Depends on what you're doing with it. 512MB is fine for most distros, but 2GB is probably more appropriate for debian or gentoo. You may want more space if you plan to use it for audio. video or maps. Finally, should I Om 2009 or SHR ? Thanks! ET PS: This flashing thing ain't easy... For dumb people like me anyway... :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
