Re: qtmoko v26 bluetooth headset
Well I have played with the BT operations on qtmoko and here are my results... 1. With a plantronics headset once paired, it will work if you tell it to connect as a headset, the buttons work, and audio is ok. However when the bluetooth headset is subsequently turned on or comes in range of the FR, it seems to connect briefly automatically then disconnect, and you have to go in and connect as headset again from the UI. If you connect as handsfree the buttons no longer work for hangup and accept calls. 2. The Bluetooth is very flaky, while testing I had it lock up on me, or the bluetooth UI just would not come up without a reboot. 3. With one of my handsfree devices (the VR3 car speakerphone) if I connect as handsfree device, it actually works very well, the buttons accept and reject calls, and the incoming number shows on the devices LCD. This is surprising as the qt implementation of the handsfree profile looks incomplete, but I may be looking in the wrong place. 4. With my preferred device the Motorola T505 handsfree device, it has trouble connecting on occasions. If connecting as a handsfree device, the devices buttons do not accept or hangup a call, and the incoming number is not detected. But it does seem to work, although not in a usable way. If I try to connect as a headset it does not seem to work at all. Conclusions are that the system needs to be made more sturdy (maybe upgrade to bluez4, which would be a lot of work). The Handsfree profile code needs to be looked at closely and made to work with more devices. We need to make it automatically connect to a preferred device when in range with the preferred profile (headset or handsfree), having to go to the UI to connect everytime is not very usable. However I am impressed with how far Radek has got with this so far, especially as he doesn't use BT much :) I'll see if I can fix some of these issues, time permitting. (Special thanks to Paul Fertser for helping me out on IRC last night, it really helped to get me started on this). Thanks Jim -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v26 bluetooth headset
Jim Morris wrote: 4. With my preferred device the Motorola T505 handsfree device, it has trouble connecting on occasions. If connecting as a handsfree device, the devices buttons do not accept or hangup a call, and the incoming number is not detected. But it does seem to work, although not in a usable way. If I try to connect as a headset it does not seem to work at all. After rebooting and unpairing and repairing with the motot505, it did in fact work, the button accepted the incoming call and hangup again when pressed again. I did see the incoming number being sent to the device in hcidump, but the device did not recognize it. When I powered off the bluetooth device and started it up again the bluetooth daemon died, when started again I failed to be able to connect getting authentication errors. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Anyone ever fixed the from 129 SMS on any distro?
Having recently come back to my FR after a year or so, I find it still gets the from 129 SMS after calling the voicemail. (I know what it is, I just want to fix it ;) I was wondering if anyone ever fixed this on any distro, and if so how? I want to fix the problem on qtmoko, and copying what others have done would make it much easier. Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v26 bluetooth headset
Christ van Willegen wrote: On a related note, I have a car with integrated BlueTooth support. Recently, I tried pairing my FR with it. At some time in that process, the car displays a PIN that should be entered on the phone to complete the pairing, but there is no PIN dialog showing on the FR. Is there support for pairing w/ a PIN? If I can only pair it with my When I paired with my headset, it asked for a PIN and there was a screen that I was able to type in which is the default for most headsets. When you pair with the car there should be two options to connect, connect headset and connect handsfree unit, I got the PIN screen when I clicked the connect handsfree unit. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v26 bluetooth headset
Thanks for the pointers Paul. Paul Fertser wrote: This [1] page and this guy might help. Also feel free to ping me or him on irc, we do know some bluetooth tricks :) Unfortunately frameworkd and the dbus stuff does not appear to be relevant for qtmoko. However those pointers did explain what the start gsm bt audio fix does which is hidden in the tools menu on qtmomo. I guess I can sniff around what you guys did for the other dists, and try to do the equivalent here, seems Radek got most of it working, but going into a shell and typing stuff to connect and disconnect would probably make the California Highway Patrol come down on you like a ton of bricks, especially since texting while driving is illegal (although it doesn't say typing shell commands is illegal ;) Anyway the main point is I need to integrate all this into the system so it all happens automatically, like on most other phones, otherwise it defeats the object of having a handsfree device. Has this been automated on the other dists, or do people still need to setup everything manually? Does qtmoko use the same version of bluez as the other dists? Do those dists handle the buttons for answering and hanging up calls? If so I can probably port some of that over unless it all uses frameworkd and dbus commands. If nothing else I can use it as a pointer to how to do it. Also keep in mind that if you've got an ordinary (non-stereo, non-A2DP) headset, it's not supposed to work with mplayer and such. See [2] for the reference. Ok that makes sense, I do have another A2DP headset, I'll see if that works differently. Thanks Jim -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v26 bluetooth headset
Jim Morris wrote: Also keep in mind that if you've got an ordinary (non-stereo, non-A2DP) headset, it's not supposed to work with mplayer and such. See [2] for the reference. Ok that makes sense, I do have another A2DP headset, I'll see if that works differently. Holy crap it worked! I paired with an a2dp headset and it asked to install the bluez audio via apt, then after a restart plays though the headset, Radek you are a genius ;) -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v26 bluetooth headset
Jim Morris wrote: Jim Morris wrote: Also keep in mind that if you've got an ordinary (non-stereo, non-A2DP) headset, it's not supposed to work with mplayer and such. See [2] for the reference. Ok that makes sense, I do have another A2DP headset, I'll see if that works differently. Holy crap it worked! I paired with an a2dp headset and it asked to install the bluez audio via apt, then after a restart plays though the headset, Radek you are a genius ;) Actually all you guys that figured out the blue tooth stuff are geniuses, Radek gets special Kudos from me for getting it to work relatively seemlessly on qtmoko... Now can I get handsfree to work seemlessly? Still working on that. Sounds like it does though from Alfa21's comments. I have several handsfree devices to test it out on. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v26 bluetooth headset
Hi Radek, Great job, I have been away from the FR for a while, but I am back to see if I can finally use it as a phone, and it looks like I may be able to now with this bluetooth stuff. Its nice to see that my qtpedometer (with car finder) still works, which is just as well as I have totally forgotten how to build apps for qtmoko ;) I have several bt headsets and handsfree devices, so this is what I have found so far My plantronics earpiece works great, automatically connects when it is on, and the button accepts and hangs up calls. My Motorola T505 handsfree device also works, but the button does not accept or hangup calls, ditto with the VR handsfree device I have. (This is a serious problem for me when in the car). My IOGear stereo headset connects via A2DP, and works with mplayer (although rather choppy), and only appears to be mono. I have an in-car builtin bluetooth, which I haven't tried yet, it has buttons on the steering wheel to accept and hangup calls. I'll do some research to see why the headset button works but the handsfree doesn't, unless someone can point me to the problem. Its amazing that you were able to integrate all this into qtmoko! The incoming call first is a bit of a problem but I can live with that for a while. Thanks Jim Radek Polak wrote: On Thursday 16 September 2010 07:44:41 Jim Morris wrote: I have not tried to make a GSM call yet using the headset, but was wondering how far the BT integration has gone? Once you connect to the headset (which looks is working for you) it should work automatically. But there is problem with 2.6.29 kernel - you will have no sound until you get first incoming call. Then it should work good. Gabrys (who did all the hard work to make it working) said that with newer kernels this problem is fixed. I am now testing qtmoko v27 with 2.6.34 kernel but i have my headset at home, so i cant try right now. 1. Should it work with a GSM call? If so what else has to be done to make it work? 2. Will the headset button answer an incoming call? Yes. For me also the button was working. But beware some headsets which do not work well with freerunner [1] - i have Jabra which is ok, but motorola does not have sound. 3. Do I have to manually connect everytime I want to use the headset? or will it automatically connect when in range (like my other cells phones). My jabra connects automatically to Freerunner when it's turned on. 4. I notice in the tools there is a start gsm bt audio fix, what does that do? does it need to be done every time I start up the phone or connect to the BT headset? It's called automatically after connecting to the headset. I have it there for debugging purposes. Thanks all for the great work, this looks very good at last, maybe after waiting several years, if the BT headset stuff works, I can start using my FR as a phone ;) (BT handsfree is a legal requirement here). I am not using headset for calls so i cant tell if it's daily use ready, but it would be interesting to hear some experience... I did contribute way back to the power monitoring for qtmoko and fixing some bugs in that code, and can contribute to making BT work seemlessly, if that is possible, but I need to know how far the current integration has gone, and if anyone is actually using BT for phone calls. You are already in the hall of fame [2] :) I do not really need BT to work for the media players, or voice recording but it would be nice. It works in qtmoko too - if your headset supports it. You will have to select something like available services from device context menu and then there should appear connect A2DP button. It's bug that the button does not appear automatically but then it should work. Regards Radek [1] http://wiki.openmoko.org/wiki/List_of_bluetooth_headsets [2] http://activationrecord.net/radekp/qtmoko/ -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v26
Ori Pessach wrote: Again, I don't expect to get GPS fix indoors, or underground, in instantaneously. I would expect to get a fix after 15-20 minutes in my back yard or outdoors in an area with low buildings and a clear view of the sky. I live in Colorado - that's what we have here. Try getting qtpedometer, it can be installed via the qt package manager. It will give a simple fix with coords. I found that sometimes I need to leave the FR standing upright outside and do not move it for 2-5 minutes to get a fix. The reason is that initially it needs to download the entire ephemeral, and everytime it drops a byte it has to start again, So leaving it stationary while it is downloading helps. Once it gets the entire ephemeral the next fix should be very quick, especially with the new save of agps. I was surprised that I actually got a fix indoors and instantly got them again after the first one after upgrading to v26. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v26
Ori Pessach wrote: I didn't mention it, but I did just that. I stood in a field, looking at grasshoppers for 5 minutes. That's when I decided to take a walk. Â This weekend, I left my FR on a table in the back yard for 20 minutes. Still no fix. Ok, so a couple of things you can try... take out the memry card if you have one in, on older models having that in could cause enough interference to stop the gps getting a fix, The other thing to try is check the gps external antenna connector, sometimes it can come loose and stop the signal. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v26
Ori Pessach wrote: Hi, I installed v26 over the weekend and had some time to try and use it. I've seen a few serious issues, and some improvements. * The software has an ongoing problem processing T-Mobile's (USA) text messages that are sent when calling voice mail. A message from 129 is delivered as soon as I call voice mail, and the software insists on displaying a dialog right away. The stacking order for dialogs appears to be arbitrary, sometime making it impossible to dismiss the dialog while in the dialer with the numeric pad active. This can make it impossible to use the voice mail voice prompts. Ideally, the messages should be filtered and not delivered to the text message inbox at all - instead, they should be used to flip an indicator in the UI that voice mail is available. I have this same issue, its been there since day one. I'd be happy to fix this issue if someone can point me in the rough direction of where in qtmoko you would handle these messages. I think this was fixed in the other dists, but every carrier has different codes for different things, so handling it in a way that does not break other carriers will be the challenge. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
qtmoko v26 bluetooth headset
Hi, I upgraded to v26 of qtmoko and it looks pretty darn good! Wifi worked out of the box with wpa/psk which is an awesome feat! Anyway I tried to get my bluetooth headset to work, and I am not sure exactly what needs to be done to make this work seemlessly. I paired OK, I connected as handsfree, and the headset beeped. Clicking the headset button did not do anything, it should usually recall the last number or bringup the dialing screen. Neither of the media players (mplayer and the other one) played through the headset, and voice record did not record or playback through the headset either. I have not tried to make a GSM call yet using the headset, but was wondering how far the BT integration has gone? 1. Should it work with a GSM call? If so what else has to be done to make it work? 2. Will the headset button answer an incoming call? 3. Do I have to manually connect everytime I want to use the headset? or will it automatically connect when in range (like my other cells phones). 4. I notice in the tools there is a start gsm bt audio fix, what does that do? does it need to be done every time I start up the phone or connect to the BT headset? Thanks all for the great work, this looks very good at last, maybe after waiting several years, if the BT headset stuff works, I can start using my FR as a phone ;) (BT handsfree is a legal requirement here). I did contribute way back to the power monitoring for qtmoko and fixing some bugs in that code, and can contribute to making BT work seemlessly, if that is possible, but I need to know how far the current integration has gone, and if anyone is actually using BT for phone calls. I do not really need BT to work for the media players, or voice recording but it would be nice. Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v24
Thanks Radek, This is looking great, and pretty fast too. I did notice that a quick click of the power button used to put the FR into suspend, but that no longer seems to work, is that by design or not? Thanks Jim Radek Polak wrote: Hi, new QtMoko images v24 are out! You can download from our sourceforge [1] or visit our homepage [2][3]. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v24
Jim Morris wrote: I did notice that a quick click of the power button used to put the FR into suspend, but that no longer seems to work, is that by design or not? Never mind, it seems to work after a fresh reboot. Thanks again. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ericsson releases free cell-id lookup API
Alex (Maxious) Sadleir wrote: https://labs.ericsson.com/apis/mobile-location/documentation/cell-id-look-up-api Limited to 100 requests per day. Perhaps I'm getting the syntax wrong (made sure to use hex like their example does) but when I tried to compare it to cells in the openmoko cellid databases, I got back 404 - The requested resource () is not available. According to the API that means the cellid was not in the database. you would get a 400 if the parameters were wrong. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v13
Erik Lundin wrote: Hi, I installed v12 a couple of days ago and like it. Is there a way to upgrade to v13 without losing my settings? I backup the home directory to sd card... tar cvzf /media/card/backup.tar.gz /home/root Then flash, then restore... cd / tar xvzf /media/card/backup.tar.gz This will reserve settings, and any new qtmoko packages you installed. It will not preserve any changes to /etc or anything installed with apt-get -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
No screen input after suspend
I am using qtmoko, but I don;t think this is related as restartinf qpe does not solve the problem. We are using the latest andy tracking. Occasionally after waking up from suspend everything works except the touch screen input, I can ssh and all seems ok. The side buttons work, but the touch screen input does not. Has anyone seen this happening on other dists? It could be qtmoko, but it is suspicious that a qpe restart won't fix screen input. Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v12
Paul Fertser wrote: Radek Polak pson...@seznam.cz writes: Also battery indicator should be now fixed. It was showing wrong values after a few suspend cycles because of incorrectly reported value in sysfs. Do you mean it's the same issue with reading nonsense from sysfs nodes when battery driver returns -ENODEV? I wonder if it's already filed on OM trac... Actually it may be related to that, but this was a QtExtended bug, if it ever got a 0 returned for the battery capacity, rather than ignoring it as a transient error, it presumed the battery was a dumb battery, and switched forever to a mode that no longer exists in the kernel for detecting the voltage of a dumb battery. I don't know why capacity returned 0 once then went back to normal, but it usually happened after waking up from suspend. So now the QtExtended battery driver ignores a zero return. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets
Paul Fertser wrote: Kahless ha...@gmx.li writes: - Which Headset do you use? My Headset (Bluetrek Tattoo) does not give me any sound. I can pair and connect it, but while phoning, theres just a (like no line) Buzz/Static-Noise. Hm, sounds just like the one i tried to use. Please read the wiki page Manually_using_bluetooth, the section where it talks about bluez4 and GSM headsets. Then borrow another headset and try with it. If it works, please add information about both to the list of bluetooth headsets [1]. It'd also be interesting to try disable_esco=1 but i doubt it will help. [1] http://wiki.openmoko.org/wiki/List_of_bluetooth_headsets As far as I know QTMoko/QTE currently has no support for the bluez4 stuff that is needed to connect gsm audio to bluetooth. I think that is what Radek needs to add, right now it seems to totally ignore the audio state for bluetooth, it can just pair. (I may be wrong as I have not looked at the bluetooth code for qt in a while). -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko - screen undims every minute or so?
Torfinn Ingolfsen wrote: Hi, When my FreeRunner is connected via usb to my laptop, the screen un-dims ever minute or so. Screen dim is set to default (20 seconds?), ut every minute the screen goes back to un-dimmed again, without me doing any activity on the FreeRunner. Why does it do that? I just found the bug in QtMoko for this, and will submit the patch to Radek. Basically it was not detecting the not charging but plugged in correctly and someone had added a hack to turn off charging that was causing it to restore the screen every time it sampled the battery state. It also wrote the power settings to the config file every time too, that is every few seconds. BTW it only happened when it was plugged in but fully charged. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets
Paul Fertser wrote: Jim Morris m...@e4net.com writes: As far as I know QTMoko/QTE currently has no support for the bluez4 stuff that is needed to connect gsm audio to bluetooth. There's nothing bluetooth-specific about loading a statefile (and applying some workarounds). And the only bluez4-specific call to actually activate the headset is one simple dbus Play(). True if you are on FSO or equivalent, but the OP was referring to QTMOKO, there is no dbus i/f to BT yet as far as I know. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Arora web browser
ANT wrote: Hello, everybody, First release of Arora [1] web browser for QtMoko is online! Check the package feed. Absolutely wonderful!! It works like a charm, just add my auto rotate and we will be golden ;) I'll post the code on github ASAP. It does seem to forget it is in full screen mode sometimes, and an easier way to zoom in would be awesome, I don't think there is any need for me to continue working on the webviewer!! Thanks for some great work. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[qtmoko] [ANN] auto rotate example program and library
Hi, I have uploaded to http://github.com/wolfmanjm/qtrotate an example program using my RotateHelper class that auto rotates the screen based on the device orientation. The two files rotate.h and rotate.cpp are designed to be self contained, so it is easy to add auto rotate to any qtmoko program, with a few lines of code. See the README and included here... A simple self contained routine that will enable a QTE app to rotate the screen depending on orientation To use... #include rotate.h // create an instance of RotateHelper RotateHelper *rh= new RotateHelper(); // then start it off.. rh-start(); // the default sample rate is 500ms // to stop it... rh-stop(); // to restore to upright... rh-restore(); The only files you need to put in your project are rotate.h and rotate.cpp -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] battery level indicator
Jim Morris wrote: It looks like the battery indicator does not work, at least after a suspend, maybe these errors have something to do with it, they appear after coming out of the first suspend, after that the battery always looks full, unless its charging which does indicate. [ 814.75] Restarting tasks ... done. [ 814.87] bq27000-battery bq27000-battery.0: battery service reschedule failed [ 817.695000] pcf50633 0-0073: usb curlim to 500 mA [ 3254.28] HDQ error: 1 [ 3254.295000] HDQ responds again [ 3254.435000] power_supply battery: driver failed to report `temp' property [ 4977.83] HDQ error: 1 [ 4977.845000] HDQ responds again [ 5129.84] HDQ error: 1 [ 5129.855000] HDQ responds again [ 5129.995000] power_supply battery: driver failed to report `temp' property [ 5712.895000] HDQ error: 1 [ 5712.915000] power_supply battery: driver failed to report `voltage_now' property [ 5737.91] HDQ responds again [ 6929.315000] HDQ error: 1 [ 6929.33] HDQ responds again [ 7005.32] HDQ error: 1 [ 7005.335000] HDQ responds again [ 7005.585000] power_supply battery: driver failed to report `charge_full' property [ 7664.26] HDQ error: 1 [ 7664.275000] HDQ responds again [ 7664.52] power_supply battery: driver failed to report `charge_full' property Ok I have done some research, and the above messages do come from the kernel, but may be transient errors, and not affecting this bug. The battery indicator showing full when it should show 75% does not always happen, but after a few suspend/resume cycles I can make it happen. When it does happen I can cat /sys/class/power_supply/battery/capacity and get the correct answer of 75. but both the value space /Hardware/Accessories/QPowerSource/DefaultBattery/Charge (which is what the battery indicator uses) and the QPowerSource::capacity() calls return 100, which is obviously wrong. This points to a bug in QtMoko (actually Qt Extended). It is odd because tracing the calls they ultimately just read /sys/class/power_supply/battery/capacity, so I suspect the QPowerSource service is dying or something like that. I'll continue to track this down, as it is quite a serious bug. I also got a dialog pop up saying the battery was critically low, when in fact it was at 75%. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[qtmoko] what sets up the kernel killing machine?
Hi, I added a swap file to my qtmoko v11 setup, but somethign inthe kernel still tries to kill stuff off, like qdsync (why is that running anyway?) and mediaserver. So I suspect that there is a setting somewhere that tells something to look for processes to kill off if memory gets short, but I cannot find it anywhere. With swap enabled I should be bale to disable that feature. While I'm at it I'd also like to stop qdsync from running, so any ideas are welcome. Thanks Jim -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] what sets up the kernel killing machine?
Jim Morris wrote: Hi, I added a swap file to my qtmoko v11 setup, but somethign inthe kernel still tries to kill stuff off, like qdsync (why is that running anyway?) and mediaserver. So I suspect that there is a setting somewhere that tells something to look for processes to kill off if memory gets short, but I cannot find it anywhere. With swap enabled I should be bale to disable that feature. While I'm at it I'd also like to stop qdsync from running, so any ideas are welcome. Thanks Jim I think the answer maybe... echo 2 /proc/sys/vm/overcommit_memory -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] what sets up the kernel killing machine?
Jim Morris wrote: Jim Morris wrote: Hi, I added a swap file to my qtmoko v11 setup, but somethign inthe kernel still tries to kill stuff off, like qdsync (why is that running anyway?) and mediaserver. So I suspect that there is a setting somewhere that tells something to look for processes to kill off if memory gets short, but I cannot find it anywhere. With swap enabled I should be bale to disable that feature. While I'm at it I'd also like to stop qdsync from running, so any ideas are welcome. Thanks Jim I think the answer maybe... echo 2 /proc/sys/vm/overcommit_memory Nope it still started killing off processes, I wonder if it is the kernel oom or the qtopia oom? -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[qtmoko] battery level indicator
It looks like the battery indicator does not work, at least after a suspend, maybe these errors have something to do with it, they appear after coming out of the first suspend, after that the battery always looks full, unless its charging which does indicate. [ 814.75] Restarting tasks ... done. [ 814.87] bq27000-battery bq27000-battery.0: battery service reschedule failed [ 817.695000] pcf50633 0-0073: usb curlim to 500 mA [ 3254.28] HDQ error: 1 [ 3254.295000] HDQ responds again [ 3254.435000] power_supply battery: driver failed to report `temp' property [ 4977.83] HDQ error: 1 [ 4977.845000] HDQ responds again [ 5129.84] HDQ error: 1 [ 5129.855000] HDQ responds again [ 5129.995000] power_supply battery: driver failed to report `temp' property [ 5712.895000] HDQ error: 1 [ 5712.915000] power_supply battery: driver failed to report `voltage_now' property [ 5737.91] HDQ responds again [ 6929.315000] HDQ error: 1 [ 6929.33] HDQ responds again [ 7005.32] HDQ error: 1 [ 7005.335000] HDQ responds again [ 7005.585000] power_supply battery: driver failed to report `charge_full' property [ 7664.26] HDQ error: 1 [ 7664.275000] HDQ responds again [ 7664.52] power_supply battery: driver failed to report `charge_full' property -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
Jim Morris wrote: I have checked in my very recent attempt to write a GPS based pedometer for Qtmoko. It is at http://github.com/wolfmanjm/qtpedometer I have completed this project (I think), short of fixing any bugs. It seems to work pretty well now, especially with the final method of accumulating Trip distance, see the new settings dialog for setting that up. Final feature list includes... * Position and speed and bearing * Trip time, distance and average speed * Waypoint distance and direction * Compass showing where north is and where the waypoint is * Metric or US units * Suspends sleep while running Thanks to Anton for the Icon and the package feed. The new version will be up on the feed pretty soon I hope :) -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
Radek Polak wrote: Jim Morris wrote: I tried to build a package but I get the following error, if anyone knows how to fix it please let me know and I'll build a package. myapps/qtpedometer $QPEDIR/bin/qbuild packages mkpkg qtpedometer You must run configure before you can run mkpkg at /aux/Stuff/qtmoko/build/sdk/src/build/bin/mkpkg line 25 *** Error /myapps/qtpedometer/packages: Prerequisite failed /myapps/qtpedometer/package_pkg: Command execution failed $$path(QtopiaSdk:/src/build/bin/mkpkg,generated) $$shellQuote($$path(/bin/qbuild,existing)) $$shellQuote($$(FORMAT)) $$shellQuote($$path(.package_pkg,generated)) $$shellQuote($$arch) $$shellQuote(unused) $$shellQuote($$LANGUAGES) $$shellQuote($$PKG_PATH) $$shellQuote($$path(.,project)) $$shellQuote($$path(.,generated)) $$shellQuote(qtpedometer) $$shellQuote(A GPS based pedometer) $$shellQuote(untrusted) $$shellQuote() $$shellQuote() $$shellQuote(1.0) $$shellQuote(Untrusted) $$shellQuote(GPL) $$shellQuote(Jim Morris mor...@wolfman.com) $$shellQuote(Anonymous2 install_target install_desktop) $$shellQuote(0) $$shellQuote($$(SPLIT_I18N)) You must run configure before you can run mkpkg at /aux/Stuff/qtmoko/build/sdk/src/build/bin/mkpkg line 25 I found the problem it is related to taht sdk/sdk bug it appears that gets put in a lot of files, rather than trying to fix that, I simply do this and it fixes the problem.. cd build/sdk ln -s ../sdk sdk -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v11
Radek Polak wrote: Hi, i have just uploaded QtMoko on debian v11 images to Is it my imagination or does the battery indicator not work properly? It shows charging OK when USB is plugged in, but when not charging, it always shows full, even when it is about 50%. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v11
Radek Polak wrote: My favourite one is links2. Fast, stable, fixed size fonts. Yes I like links2 but how do you set it up to run from the FR when it is a console app? Do you have a way to add desktop icons or something for launching it? Long term plan is to use arora. Looks very nice and uses QtWebkit so it shouldnt be that hard to port it. I'll take a look at it, is it being ported? if not I can try to port it. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v11
Jim Morris wrote: Radek Polak wrote: Long term plan is to use arora. Looks very nice and uses QtWebkit so it shouldnt be that hard to port it. I'll take a look at it, is it being ported? if not I can try to port it. Looked at it they dropped support for qte 4.4, it only supports qt4.5 now, I'll see if I can get an older version, and build that. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v11
Fabio Locati wrote: I guess QtMokov11 works with 4.5 ;) Yea I wish :) Has anyone started a port of 0.8.0 to qtExtended 4.4? ie created the qbuild.pro files etc? Is it worth starting a fork from 0.8.0 (the last version to support 4.4) and move forward with porting it to qtextended? -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
ANT wrote: I've just updated the package according to your commit ad0ac0ea. when you'll achieve new milestone or fix major bug, let me know. BTW, please add an icon for desktop entry. Thanks Anton, I'm not very good at icons, but I put one in pics, and updated the desktop file and qbuild file. It'll do as a placeholder. Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
I have updated this since the initial announcement. Added metric option for the Europeans :) Added a compass display to show where North is relative to motion. Added waypoint, will show distance from waypoint and the compass will show the direction to the way point. Now suspends suspend when running. Numerous fixes, and some improvement of the accuracy of the trip distance in some cases. As I still can't seem to build a package I would appreciate if ANT could update the package for me. (TIA). the latest binary and source is on GITHUB http://github.com/wolfmanjm/qtpedometer Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v11
Radek Polak wrote: Hi, i have just uploaded QtMoko on debian v11 images to Excellent,Thanks Radek. Seems to work ok so far. Is there a better web browser though? The one in the menu still gets killed when I try to load say http://wolfman.com, and http://dogz.us just shows a blank screen. The fonts are so small on most other sites it is impossible to read without a magnifying glass :) I think this one was a demo they put there to show webkit in action. Thanks Jim -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
ANT wrote: Hello, Jim, Thanks for the apps. I added QtPedometer package to QtMoko feed. Small patch was applied to the .desktop file to make the package installable. You can pull changes from [1]. This is an intermediate place between your repo and qtmoko-apps [2]. As for QtopiaGPS, it would be nice if the app could start/stop required services by itself (which is impossible just now becouse it is needed to modify gpsd config file). [1] http://github.com/radekp/qtpedometer/ [2] http://github.com/Sektor/qtmoko-apps/ Regards, Anton Thanks Anton, Yea qtopiagps is more of a testing app, and requires GPSD as the Whereabouts API in Qt does not provide satellite info. It is easy enough to start and stop gpsd from the app, but as you say out of the box that won;t work as the configuration file needs to be modified. One solution is for me to eliminate gpsd, and talk directly to the chip as qtpedometer does, but that is not the right way to do it either as you can only have one gps app running. I think the long term solution is to copy FSO, and use DBUS. What do you think? Thanks Jim -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
Vincent Meurisse wrote: I added QtPedometer package to QtMoko feed. Great idea. two suggestions: - disallow the phone from suspend - http://en.wikipedia.org/wiki/Metre_Convention Next on my list is to allow switch to metric or US system. (Its relatively easy). I'll see how to stop the phone from suspending. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
Radek Polak wrote: It would mean, that whereabouts server has to open socket at the same port as gpsd does and emulate it. Actually the default built-in plugin for the Whereabouts API does use GPSD, and if you run my app with the parameter gpsd, it will use gpsd instead of opening the serial port directly. However GPSD has been deprecated in favor of ogpsd in FSO, which provides the same functionality. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
ANT wrote: Jim Morris wrote: I'll see how to stop the phone from suspending. Tips: #include QtopiaApplication QtopiaApplication::setPowerConstraint(QtopiaApplication::DisableSuspend); //prevent suspending QtopiaApplication::setPowerConstraint(QtopiaApplication::Enable); //restore power saving settings Already done and checked in :) -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
Vincent Meurisse wrote: On Friday 18 September 2009 21:31:57 Jim Morris wrote: I'll see how to stop the phone from suspending The best would be to have this included in Whereabouts so any application using GPS automatically benefit from it. If it also let the screen blank, it would be perfect for battery life. I don't think changing the Whereabouts API is an option, technically we could do it for qtmoko, but then any app written would only work on qtmoko and not other qtextended device. Which defeats the whole purpose of using Qt. Right now I temporarily disable suspend, ut the screen will still blank if the global options are set accordingly. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QTMOKO] GPS pedometer app up on github
Jim Morris wrote: I have checked in my very recent attempt to write a GPS based pedometer for Qtmoko. It is at http://github.com/wolfmanjm/qtpedometer There is a serious accuracy problem with determining the distance traveled during a trip. I did some research, and there does not seem to be a consensus on how to do it, and the GPS device manufacturers obviously have proprietary solutions they do not disclose or discuss. All the open source programs I looked at do it the simple but very inaccurate way I first tried. They basically calculate the distance between successive fixes (segments) and accumulate that as the distance. This has about a 20%-50% error (estimated). The next attempt I discovered on the web (and how I do it now) is non-intuitive, but basically you take the current speed, and multiply it by the delta time since the last update. This is much more accurate, but still accumulates errors even if you are standing still it accumulates a small error. It works really well when driving though, but for walking (and I suspect biking), it is still inaccurate. Next I added a speed threshold, which you must go over before the distance will accumulate, for walking I set that to .4 miles per hour or 0.1788159993648455703 meters per second. This works well if you are standing still, as it does not accumulate any distance, but it increased the error significantly on a driving trip, when I compared the trip distance of my cars GPS with my version. I haven't tried a walking test yet. So if anyone has any ideas how to make this more accurate I would welcome suggestions. Thanks Jim -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[QTMOKO] GPS pedometer app up on github
I have checked in my very recent attempt to write a GPS based pedometer for Qtmoko. It is at http://github.com/wolfmanjm/qtpedometer I also updated qtopiagps (an xgps clone) to run on qtmoko: http://github.com/wolfmanjm/qtopiagps There is a binary there too if you don't want to compile it. The only way to make it run at the moment is scp it to your device and run it from file manager. I tried to build a package but I get the following error, if anyone knows how to fix it please let me know and I'll build a package. myapps/qtpedometer $QPEDIR/bin/qbuild packages mkpkg qtpedometer You must run configure before you can run mkpkg at /aux/Stuff/qtmoko/build/sdk/src/build/bin/mkpkg line 25 *** Error /myapps/qtpedometer/packages: Prerequisite failed /myapps/qtpedometer/package_pkg: Command execution failed $$path(QtopiaSdk:/src/build/bin/mkpkg,generated) $$shellQuote($$path(/bin/qbuild,existing)) $$shellQuote($$(FORMAT)) $$shellQuote($$path(.package_pkg,generated)) $$shellQuote($$arch) $$shellQuote(unused) $$shellQuote($$LANGUAGES) $$shellQuote($$PKG_PATH) $$shellQuote($$path(.,project)) $$shellQuote($$path(.,generated)) $$shellQuote(qtpedometer) $$shellQuote(A GPS based pedometer) $$shellQuote(untrusted) $$shellQuote() $$shellQuote() $$shellQuote(1.0) $$shellQuote(Untrusted) $$shellQuote(GPL) $$shellQuote(Jim Morris mor...@wolfman.com) $$shellQuote(Anonymous2 install_target install_desktop) $$shellQuote(0) $$shellQuote($$(SPLIT_I18N)) You must run configure before you can run mkpkg at /aux/Stuff/qtmoko/build/sdk/src/build/bin/mkpkg line 25 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko images V9
Excellent work Radek, this is definitely the best release so far, I love the speed ups too. I finally got around to trying my Buzz fixed FR in a real call, and the volume was so low I couldn't hear it. I used the http://docs.openmoko.org/trac/raw-attachment/ticket/2121/gsmhandset.state.new and stuck that into /usr/share/openmoko/scenarios/gsmhandset.state, and it was much better. Still rather low but tolerable. I noticed that if I enabled speaker during the call, then there was no sound at all, so I guess the speaker alsa state needs working on? A major problem though is that whenever I run the web browser (and other programs) they get killed at random times, usually within the first few seconds. The browser seems to be killed off as I see this in dmesg... [ 2200.955000] select 2460 (webviewer), adj 15, size 7812, to kill [ 2200.955000] send sigkill to 2460 (webviewer), adj 15, size 7812 Any idea what is killing it off and why? So far I haven't been able to keep the web browser running long enough to visit a page. I am running in flash (not sdcard), and using the latest version V9. I think this is getting close enough to being stable I could use it as a phone, I just need bluetooth headsets to work :) Thanks Jim Radek Polak wrote: Hi all, i have just uploaded new QtMoko debian images. You can download as usually from: -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-U] Bluetooth and GSM... Again.
The Digital Pioneer wrote: Well, as yet another Jerry, I don't need a GUI for bluetooth. I'm perfectly happy to edit configs and run commands all day long, so long as at the end of the day (or week... Month... Year) it works. Only once we've gotten that far do I see a point in creating a GUI. I can't believe BT headsets still don't work! My FR has been sitting collecting dust because no BT headset is a show stopper for me (living in California where handsfree is mandatory when driving). Now if I could get a recipe that actually works I'd be happy to try to put a GUI together to make it work easily, like every handset I have ever had does! All the WIKI instructions end up with either no sound, no mic or really bad sound. (I can pair though). I have several BT headsets and BT handsfree devices to test with and none of them work yet. So here is a +1001 for some of these excellent experts to give us a recipe to get it to work manually, and then us less expert types can cobble together a GUI or technique to make it just work out of the box like it should have a year ago when I got my FR. Thanks guys. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtExtended] Latest and greatest, progress mail 12
Franky Van Liedekerke wrote: On Tue, Jun 2, 2009 at 2:07 AM, Jim Morris m...@e4net.com wrote: Franky Van Liedekerke wrote: (install instructions and script updated on 2090601: see below) It's been a while, but we haven't been sleeping :-) FYI... I followed the instructions, and ran the script from ssh using the install option and it runs out of memory... lib/fonts/dejavu_sans_condensed_36_75.qpf2 lib/fonts/dejavu_sans_condensed_10_50.qpf2 lib/fonts/dejavu_sans_condensed_21_75.qpf2 tar: write error: No space left on device if this happens, it doesn't mean out of memory, but out of disk space, which means you have many things installed that are not required. Probably you're using another kernel/rootfs and extra stuff. Simple action: clean up ... Yes I know that, but this was a clean install from the images I downloaded with no extra stuff installed, I couldn't install anything as only the kernel was running anyway. Have you tried the full install? The problem looks to me like having the tar file on the device uses too much room and you cannot de-tar it. I got around it by piping the tar over ssh. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtExtended] Latest and greatest, progress mail 12
Franky Van Liedekerke wrote: yes, I try that all the time. The tar.gz file is only 23 MB, so it should be no prob ... Ok well I tried again with exactly the same results... does your system have more disk? or are you using an sd card? I monitored the disk usage while it was untarring and it did run out of disk space... Just before it ran out... Filesystem 1K-blocks Used Available Use% Mounted on /dev/root65536 64248 1288 98% / /dev/root65536 64248 1288 98% /dev/.static/dev udev 204840 2008 2% /dev tmpfs6038036 60344 0% /var/volatile tmpfs60380 0 60380 0% /dev/shm 1.2Mb left.. it started out at 39Mbytes before downloading qtmoko /dev/root65536 26304 39232 40% / /dev/root65536 26304 39232 40% /dev/.static/dev udev 204840 2008 2% /dev tmpfs6038036 60344 0% /var/volatile tmpfs60380 0 60380 0% /dev/shm Here were the steps... /qtmoko sudo dfu-util -a rootfs -R -D fso-paroli-image-om-gta02.jffs2 /qtmoko sudo dfu-util -a kernel -R -D uImage-2.6.28-andy-tracking+gitr6+9c4451ff31b937a478f3d3eabef30b71cbe12b12-r3-om-gta02.bin qtmoko scp qtmoko_install.sh om: ssh om sh ./qtmoko_install.sh install Just a sanity check, after a clean installation I have 39Mb free after downloading a 23Mb file we have 16Mb left, then we try to de tar that compressed file which has to be over 23mb, and of course we run out of disk space. I am wondering why I am the only one with this problem? I have an original gta02 which appears to have 65Mb of disk/flash Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtExtended] Latest and greatest, progress mail 12
Franky Van Liedekerke wrote: (install instructions and script updated on 2090601: see below) It's been a while, but we haven't been sleeping :-) FYI... I followed the instructions, and ran the script from ssh using the install option and it runs out of memory... lib/fonts/dejavu_sans_condensed_36_75.qpf2 lib/fonts/dejavu_sans_condensed_10_50.qpf2 lib/fonts/dejavu_sans_condensed_21_75.qpf2 tar: write error: No space left on device I'll do the install manually for now. Thanks for your work on this. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS wrong longitude
Yes I get the same problem from the trip menu on Tangogps only. I get the correct lat/long from my other GPS device and also from agpsui on the freerunner. Looks like it is a bug in TangoGPS. Nicolas Laurance wrote: hi all, I've tried several distrib (FSO, SHR) and I have an issue with the GPS maybe more specifically TangoGPS, don't know the symptom is : After the fix, Tango shows me on the correct position on the map but in the Trip tab the latitude data is completely wrong, more than 1 degree west Does anyone have the same issue ? any idea on how to fix ? -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Report] - Buzz fix
Michael Zanetti wrote: Hi! I just wanted to let you know that I have applied the Buzz fix to my Freerunner revision A5 according to this [1] paper and indeed the buzz is completely gone. Including the echo fix my Neo converted from the coolest toy to the coolest _phone_ I've ever had. Ok, so how/when will OM offer a fix for end users? This fix is way beyond my skills to do. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Cédric Berger wrote: Here we are http://google-opensource.blogspot.com/2008/10/android-open-source-cell-phone.html time to port to Neo ! At last maybe we will get a stable, usable O/S for the Neo (which I have shelved until such a thing exists). I was using Qt but QtExtended was a step backwards in stability. I am very happy to see Android available for development, I may un-shelve my Neo blow off the dust and help port it! -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Cédric Berger wrote: Here we are http://google-opensource.blogspot.com/2008/10/android-open-source-cell-phone.html time to port to Neo ! Maybe we should setup a Neo branch on Androids GIT, and start to collaborate on the port? Anyone else interested? -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Jim Morris wrote: Cédric Berger wrote: Here we are http://google-opensource.blogspot.com/2008/10/android-open-source-cell-phone.html time to port to Neo ! Maybe we should setup a Neo branch on Androids GIT, and start to collaborate on the port? Anyone else interested? Ok well I have started :) the repo sync fails as the webkit repo appears to be down, so I'll try again later. I suspect there will be kernel work required, I'm more comfortable with Java so will work on that end, any volunteers to work on the kernel part of Android? -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Rui Miguel Silva Seabra wrote: On Tue, Oct 21, 2008 at 11:52:02AM -0700, Jim Morris wrote: Cédric Berger wrote: Here we are http://google-opensource.blogspot.com/2008/10/android-open-source-cell-phone.html At last maybe we will get a stable, usable O/S for the Neo Ya t'ink? exists). I was using Qt but QtExtended was a step backwards in stability. I am very happy to see Android available for development, I may un-shelve my Neo blow off the dust and help port it! Let's hope that when you remove the proprietary crap you don't end up with a console prompt (or not much more...) Rui ps: yes, I'm not very hopeful of Google Android as a Free Software phone, it doesn't look very much like one... Ya know I don't really care if it is open source or free source or commercial, so long as it is stable and actually works as a phone! I have a $400 toy at the moment which I would like to use as a phone one day. I'll use anything that gets me closer to that goal. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Rod Whitby wrote: I have owned the android-internals.org and android-linux.org domains since last year, waiting for this day, and the former has a wiki already set up and available to be used for porting information (dunno whether Openmoko would or would not want Android porting info on wiki.openmoko.org ...). -- Rod Great trying to go there now, just seems to hang Was on IRC and someone said they had already ported the kernel, and was working on a forum, just FYI. We should all coordinate so there are not 10 different porting efforts :) -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Rui Miguel Silva Seabra wrote: On Tue, Oct 21, 2008 at 01:41:20PM -0700, Jim Morris wrote: Ya know I don't really care if it is open source or free source or commercial, so long as it is stable and actually works as a phone! I have a $400 toy at the moment which I would like to use as a phone one day. I'll use anything that gets me closer to that goal. For 100 EUR I'll send you my 10 EUR commercial value Nokia :) Rui Actually I just bought a Nokia e62 unlocked phone so I had a reliable phone to use, other than being a tad slow it works great everytime. Thats the kind of thing I expect one day from the FR. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Ken Young wrote: Jim Morris wrote: [...] Ya know I don't really care if it is open source or free source or commercial, so long as it is stable and actually works as a phone! I have a $400 toy at the moment which I would like to use as a phone one day. I'll use anything that gets me closer to that goal. Does anyone really think that porting Android is going to magically fix the problems that prevent the Freerunner from being a useful phone? How likely is it that things like suspend/resume problems will go away if you port Android? Aren't those problems apt to be very closely tied to the particulars of the Freerunner hardware? Porting Android sounds to me like a way to spend a huge amount of time to produce another distribution for the Freerunner which will be no more reliable (at best) than the others ones are. Ken Young No magic, I suspect the kernel will be the same, and have potentially the same bugs, however I think the apps will be more stable. By the time Android is ported over, I am hoping there will have been significant progress on the kernel in the other dists, which android and qtextended etc will benefit from. For my part I am very comfortable writing Java, so being able to write apps in Java is a plus for me, and none of the current dists really support Java well (ok it is supported but have you tried writing a good app with that support?). Of course the H/W bugs such as GSM buzz won't get fixed, but I'm still hoping there will be a H/W fix for that which Openmoko will support for GTA02. Besides it seems people love to have several choices ;) -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Android open sourced
Lorn Potter wrote: Jim Morris wrote: Cédric Berger wrote: Just because 4.4.1 might be unstable doesn't mean qt extended will always be that way. It just means that 4.4.1 was buggier than expected. Oh I know it will get better, I was just disappointed it was less stable than the previous version. which I had blown away to try 4.4.1 I couldn't really use 4.4.1 of QtEtended as it seemed to hang all the time as well as other issues which I'm sure you are aware of. (Scrolling through lists usually thinks you are selecting something you don't want etc). I'll continue to try the new versions of 4.4 as they come out, but in the meantime playing with Android seems like a good use of my time ;) I'll use whichever one ends up being a usable phone soonest. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to build qt-extended?
Cédric Berger wrote: OpenSSL support . no Is the SSL support activated in the released image on qtextended.org ? I guess it is still needed for ie. encrypted IMAP ? It is activated in the released image. At least I can set the encryption on my email account. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia 4.4 ?
Lorn Potter wrote: 4.4 is right around the corner. It has dynamic rotation, webkit/example browser, a location API/example gps apps, Gtalk jabber thingy. and I cannot remember what else. Will you be able to integrate the bluetooth headset stuff into the UI by 4.4? Seems someone has got it working on the Wiki, it just requires the terminal right now. It would be nice if you could hook up those menu items when in a call, that routes to bluetooth, speaker or handset. Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: (Some?) 3G support for Linux from Nokia - relevant for future models?
Mikko Rauhala wrote: Sure Nokia has some products which happen to be free software. That doesn't make them committed to free software, what with being eg. hostile to free formats, a strong opponent of independent software development in general through their patent lobby, very much clueless in top level press comments about these subjects, and in general not being very consistent in what they're up to in this area. .. The tablet OS has significant proprietary portions, both third party and in-house - the latter having insiders commenting that it's difficult (when at all possible) to get the go-ahead to free the code properly. Not to mention the target hardware platform pretty much requires binary blob kernel code and such (last I checked anyway). To be honest even though I love open source/free software my experiences with OpenMoko Freerunner has soured me a little bit. I bought a phone that was supposed to be usable as a phone and as of today still is not usable as a phone. (and don't flame me about you should have known what you were getting, check the Wiki and purchase site back in July and there is no mention of how unstable it is, it is better documented now). The Trolltech Qtopia release is the closest thing to a stable environment for the phone (still not quite usable as a phone though, but closer than anything else currently available). Needing a phone I could actually use as a phone I had to go buy a new cell phone, so I picked up an unlocked Nokia E62 relatively cheap. This is a totally proprietary phone, but it works really well, has a ton of apps on it that also all work, and the bluetooth works exactly as expected with handsfree and headset devices. GPRS works well, and there is a working J2ME stack on it. (so google maps works etc) My point is I'd gladly give up some open source rights in exchange for a phone that works as expected. I'll continue playing with my FR, but I suspect it'll be another 6 months before I can start using it as my primary phone. So there are pluses and minuses to open source, yes you can do whatever you want on it, but the time line to getting a stable environment is pretty long, especially as OM seems to be relying heavily on the community to provide stable core features for the phone. Whereas the non open source stacks out there seem to be very stable and work pretty darn well today. A good trade off IMHO would be to allow a closed but working GSM stack, and leave all the other applications stuff open. That way you get a good stable phone but can still write apps for it in whatever language you desire. Just my 2c :) -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Dareus wrote: I had to configure the deamon and it worked well in the end. I was thinking if you could add the option to write a gpx track using gpxlogger or cgpxlogger. That would be very useful in various use cases (http://wiki.openmoko.org/wiki/GPS_applications). There are plans to add more features to this app, either by me or another person who has cloned the tree, he will be working on it in a few weeks I think. Adding tracks is definitely something he is planning to do. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Dareus wrote: Jim Morris wrote: Radek Barton( wrote: 1. Download lastest gpsd source code at http://download.berlios.de/gpsd/gpsd-2.37.tar.gz and unpack it somewhere. 2. Add line #include linux/limits.h to gpsd.h-head file. 3. Modify line 15 of gps.h file from limits.h to linux/limits.h 4. configure with command: PATH=/opt/toolchains/arm920t-eabi/bin: $PATH ./configure --host=arm-angstrom-linux-gnueabi 5. Then make, make install, etc. I can confirm that the method works well, maybe you should add in your blog post that libgps16, gps-utils and gpsd are needed. Done Another issue: qtgps keeps on saying that there an 'error opening gpsd', then i tried a low level access to gps, nothing worked (i already tried before flashing and it worked well). gps is power on # gpspipe -r gpspipe: could not connect to gpsd 127.0.0.1:2947, Connection refused(111) Make sure gpsd is instaled and running... /etc/init.d/gpsd start Also make sure there are no other gpsd daemons running hogging the serial port. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Qtopia 4.3.3
Paul Buede wrote: if I notice anything wierd there I will report back. Anyone tried bluetooth headset with this new version to see if the files that were not there in 4.3.2 are there now? I can try tomorrow if nobody else has yet. You can pair with a bluetooth headset, but no one has managed to get the audio to work, on any of the distributions. The solution (if there is one) will be the same I suspect for all the dists, including Qtopia. Check out the bluetooth related wiki entries for what has been done so far. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtopia update
Michael Zanetti wrote: On Tuesday 02 September 2008 02:30:14 Lorn Potter wrote: I have updated qtopia at qtopia.net What feeds should I use to update? The preinstalled ones for buildhost.openmoko.org don't seem to work and I couln't find a qtopia repos on downloads.openmoko.org. Yes that would be good to know. I use the update method, and I updated the kernel from the last release, but knowing what versions of all the libraries etc you use would help to keep in sync. Thanks it is looking really good. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[qtopia] How to add to applications launcher
Hi, Is there an easy way to add an icon to launch say a script to the UI, either in the applications or higher. Something like the devtools page, where it allows you to turn on/off stuff? I'd like to add some scripts that manage things like switching to mass storage mode and back, and other system level scripts. Running the terminal to do these things is a real pain. Adding scripts to devtools would be great too, but I looked at the source code and couldn't figure out where that app even was. BTW this is for Trolltechs Qtopia, we need a way to distinguish from OM Qtopia/X11 Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Images
Michael Zanetti wrote: On Tuesday 02 September 2008 14:02:01 arne anka wrote: with the buzzing still unsolved that's at least a way to use a headset to make calls. how do i use headset/handsfree? To be honest I do not have much experience with BlueZ. This is what I know: First of all, the BlueZ wiki page about audio: http://wiki.bluez.org/wiki/Audio Probably you will find some information here: http://gentoo-wiki.com/HOWTO_use_a_bluetooth_headset Some years ago I got it running on my PC using this guide (could be outdated): http://forums.gentoo.org/viewtopic-t-238510-highlight-iscan.html If you combine the above information with the following you will be probably able to get your Bluetooth Headset working: http://wiki.openmoko.org/wiki/Manually_using_Bluetooth Unfortunately that is not the case, I've been playing with BT headsets for weeks, and have not got a peep out of one (I've tried several), I have not even got a2dp working either. I did get it all working on my desktop so I could understand Bluez, however it seems it is easier on a desktop because it is all S/W, the FR routes BT audio directly into the audio chip and bypasses S/W altogether, at least that is the theory, but no one has yet been able to get that audio path to work, or get a combination of audio pathway and bluez configuration. I'm glad more people are asking, because there has been ZERO response from OM on this issue and there has been a ticket on this issue for 20 months! http://docs.openmoko.org/trac/ticket/113 If someone does get this working please update the wiki. I have given up I've spent way too much time on this issue, and to be honest I think OM needs to investigate why it is so hard... Is it even possible? Good Luck You will need it. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Images
Warren Baird wrote: On Tue, Sep 2, 2008 at 4:50 PM, Jim Morris [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Unfortunately that is not the case, I've been playing with BT headsets for weeks, and have not got a peep out of one (I've tried several), I have not even got a2dp working either. Based on the comments for http://docs.openmoko.org/trac/ticket/1656 it sounds like some people have managed to get BT audio working with a2dp, albeit with some signal strength issues. This is on my list of things to try, but I haven't gotten around to it yet... Warren I tried exactly the same thing, but was unable to get anything to play using asound. However the A2DP uses a different path, it sends system PCM into the audio chip and then routes it to the PCM out which goes directly to the BT chip. It is nice to know they heard something, however there are other issues with this path that are hinted at on the wolfson site,there maybe a clocking issue between the i2c input and the pcm output, at least that seems true for the reverse direction. BT headset to/from GSM is yet another path, and should not involve the CPU at all (other than for setup). -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AT%N0187 openmoko echo patch?
[EMAIL PROTECTED] wrote: Cesar Eduardo Barros wrote: NeilBrown escreveu: On Mon, September 1, 2008 6:59 pm, Yorick Moko wrote: On Mon, Sep 1, 2008 at 10:43 AM, Lorn Potter [EMAIL PROTECTED] wrote: They certainly are not in our copy of the calypso spec's that we got directly from TI. If it is, I must be missing it, and haven't found it. But couldn't both of those have been documented? And if they have not been, might be classed as incompetent. They are after all just part of the modem instruction set. To not release the entire lot is a bit lame. Using an undocumented feature in a chip is very dangerous. Minor changes to the fab, even though the chip has the same number may change or remove that undocumented feature that the phones now rely on. If this is going to be adopted in builds, then someone at OM needs to get TI to officially support that feature so that it does not disappear later. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Cesar Eduardo Barros wrote That's because the Bluetooth is in another chip. For that, you need the full schematics: http://downloads.openmoko.org/schematics/GTA02/Schematics_Freerunner-GTA02_A5-A7cumulative_public_RC0.pdf I looked at the schematics, and the BT chip is directly connected to the audio chip. The BT chip setup is done by bluez, and it appears pcm in/out is always on and no additional setup required (other than pairing and setting up the headset). The very first diagram (page 2) shows how the chips fit together. There you can see how the bluetooth chip is connected to the codec: the PCM pins. There seems to be a comment saying something about BT Codec DAI on neo1973_gta02_wm8753.c, which seems related. If it is it is totally beyond me to see where and how this would be setup So, you just need to find out: - How to switch bluetooth audio I/O to these PCM pins (should be something in the HCI-USB standard). I think bluez driver already does that. I made it work on my PC for instance. - How to route within the codec between the PCM pins and the pins which are connected to the GSM chip (these pins are also shown in the diagram). That also seems to be set in the .state files which are GTA01 specific, I created some GTA02 ones but no hint of audio thru BT. (I probably missed something like the Neo Mode setting, but wait.. they took that out and did not document what it was replaced with!) I officially give up on this, as I simply cannot make any further progress, I have uploaded the gta02 compatible state files to the wiki, and I hope someone with more patience than me can guess the rest, because guessing is about all that is left. I am totally frustrated by this, and the total lack of interest by anyone at OM to get this working. I am very close to sending the FR back under false advertising laws, as no working BT headset makes it useless as a GSM phone in the state I live in, and it is advertised as having BT headset capability and I have spent a lot of time filling in for OM to try to get this to work. If OM can give me at least a time frame when they can look into this I'd appreciate it, because I am starting to think that BT headset will not work in GTA02, like it didn't work in GTA01, and OM is avoiding having to admit that publicly. All other conspiracy theories are welcome ;) A VERY frustrated user! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
I notice there is a bug filed against this issue... http://docs.openmoko.org/trac/ticket/113 It was filed 20 months ago! I guess that says what the priority of this is. If anyone else is as pissed as I am about the lack of BT support, please hassle OM management to get this priority raised. Thanks Jim ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Marco Trevisan (Treviño) wrote: Jim Morris wrote: I notice there is a bug filed against this issue... http://docs.openmoko.org/trac/ticket/113 It was filed 20 months ago! I guess that says what the priority of this is. If anyone else is as pissed as I am about the lack of BT support, please hassle OM management to get this priority raised. Am I wrong or someone got it working in qtopia? If it is true, maybe you could get some infos from their sources... Qtopia allows you to pair from the GUI, I got that working, however once paired the audio does nothing as Qtopia does not load the alsa state. Basically the situation is the same across all dists, and the solution will be the same for all dists AFAIK. We need a working alsa.state file (I think I may have one, or at least one that is pretty close), and we need to understand how alsa and bluez work together to make the PCM from the bluetooth chip interact with the wolfson audio chip. and whatever else used to be done if you set the Neo Mode in alsa to bluetooth. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Fredrik Wendt wrote: Jim, Just wanted to say that your efforts on making bluetooth headsets usable is highly appreciated! A question: I guess you're trying to route the GSM audio to bluetooth, is this right or are you looking at routing generic audio (from mplayer) to bluetooth? Will you also be able to choose between SCO A2DP then in anyway? (obviously A2DP won't make it for GSM phone calls - unless you're the silent type) I'm just trying to get the BT to GSM path and GSM to BT path in the chip to work. A2DP for stereo (CPU to BT) is a different path, and apparently people have been able to get that to work, although with mixed results. Check the Wiki for a recipe to make that work. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Lorn Potter wrote: bluetooth audio on the gta01 will never work, even with that bluetooth alsa state. Ok so where did that gsmbluetooth.state come from and why did someone do it if it never worked? Unfortunately I was only partially able to generate a gta02 version of the state file, as many of the controls have no equivalent in gta02. I guess I should try what I have it may work. I'll report back. Then the question for you is if it does work, how do we get Qtopia to load the state file automatically on a gsm call when BT is enabled? -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Lorn Potter wrote:
Jim Morris wrote:
Cesar Eduardo Barros wrote:
Jim Morris escreveu:
One thing that may help, is if someone could provide a mapping of
the wolfson registers as documented in the WM8753L pdf to the alsa
controls. Someone had to have written the code that twiddles the
registers in that chip, and would know which also control matches
which register.
That would be sound/soc/codecs/wm8753.c and
sound/soc/s3c24xx/neo1973_gta02_wm8753.c on the kernel source code.
Take a look:
http://git.openmoko.org/?p=kernel.git;a=blob;f=sound/soc/codecs/wm8753.c;hb=stable
http://git.openmoko.org/?p=kernel.git;a=blob;f=sound/soc/s3c24xx/neo1973_gta02_wm8753.c;hb=stable
The mapping is there, you only have to find out how it's described.
Thanks for the pointers. Thats 2,000 lines of code that is about as
clear as mud! (and I've written audio drivers before).
There is no mention of Bluetooth in these drivers, and no indication
how to switch into bluetooth mode.
Obviously gta01 was very different, and it is not even clear that the
gsmbluetooth.state even worked on a gta01, at least I've never seen
any gta01 user claim they had it working.
bluetooth audio on the gta01 will never work, even with that bluetooth
alsa state.
Ok well it didn't work, attached is the gsmbluetooth.state file I am trying to use if anyone is
interested and wants to try it. I set this as best I could from comparing the differences between
the gsmhandset.state and gsmheadset.state for the gta01 and transcribing to gta02 as best as
possible given the undocumented differences between the two.
After calling the cell phone I did an alsactl -f gsmbluetooth.state restore.
In the process I just discovered the Qtopia (this is for you Lorn ;) did not load
/usr/share/openmoko/scenarios/gsmhandset.state when the call was answered, I had to do it manually,
I'm pretty sure this is a regression.
Also the options available in the menu when in a call to set speakerphone handset or bluetooth do
not seem to do anything.
I'm pretty much out of ideas on how to get a working gsmbluetooth.state file for gta02, so someone
else chime in if you think of anything.
I see this as a show stopper for the unit being usable as a phone so if anyone at OM cares I'd get
on it ASAP.
--
Jim Morris, http://blog.wolfman.com
state.neo1973gta02 {
control.1 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 255'
iface MIXER
name 'PCM Volume'
value.0 0
value.1 0
}
control.2 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 255'
iface MIXER
name 'ADC Capture Volume'
value.0 0
value.1 0
}
control.3 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 127'
iface MIXER
name 'Headphone Playback Volume'
value.0 96
value.1 96
}
control.4 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 127'
iface MIXER
name 'Speaker Playback Volume'
value.0 0
value.1 0
}
control.5 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 127'
iface MIXER
name 'Mono Playback Volume'
value 103
}
control.6 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 7'
iface MIXER
name 'Bypass Playback Volume'
value.0 7
value.1 7
}
control.7 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 7'
iface MIXER
name 'Sidetone Playback Volume'
value.0 0
value.1 0
}
control.8 {
comment.access 'read write'
comment.type INTEGER
comment.count 2
comment.range '0 - 7'
iface MIXER
name 'Voice Playback Volume'
value.0 0
value.1 0
}
control.9 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Headphone Playback ZC
Re: QtGps for Trolltechs Qtopia
Radek Barton( wrote: Dne Saturday 23 of August 2008 02:25:25 Jim Morris napsal(a): Please could someone point me to some tutorial or basic steps how to most easily crosscompile libgps for Qtopia/arm and/or where to download compatible libgps.a and libgps.la? Thanks. You should be able to install it directly without needing to compile it. opkg install libgps16 If it wasn't installed with gpsd You should see a /usr/lib/libgps.so.16 file If you need it to build qtopiagps then let me know, I need to add that to the blog entry. I used Mokomakefile to build it, then copied the results to the toolchains lib directory. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Radek Barton( wrote: Tanks, I'll look what Mokomakefile provides and how it's used. I'm trying to compile qtopiagps to learn how to crosscompile software for Qtopia. Then I would want to create ipk/opk package with qtopiagps and create an icon in applications menu. But I have to learn all that first. Then I could help to improve qtopiagps with some GPS control (power on/cold/warm/hot reset etc.). I would really invite compact GPS application with tangogps and agpsui funcionality for Qtopia so I can try to implement map display, download and tracking support too (steeling part of tangogps code :-)). Well this page should help you get started, you may not need mokomakefile at all. http://blog.wolfman.com/articles/2008/08/27/porting-xgps-to-qtopia-for-the-freerunner The second part of the page shows how to get started with qtopia development. I'll add details on how to add the libgps to it later today. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Aaron Sowry wrote: I get this: # ./qtgps ./qtgps: error while loading shared libraries: libQtSvg.so.4: cannot open shared object file: No such file or directory Are you running Qtopia? Are you running from the FR console or from an ssh terminal? If the latter then you need to do this... . /opt/Qtopia/env.sh ./qtgps This sets up the environment and in particualy LD_LIBRARY so it can find the libraries. I usually run it from the file manager which you can get from the trolltech feed. Remember you also need gpsd. opkg install gpsd -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GsmBluetooth state file for gta02
I am still trying to get a bluetooth headset to work with the GTA02. I found on the Wiki a pointer to this state file http://opensource.wolfsonmicro.com/~gg/neo1973/gsmbluetooth.state however it is gta01 specific, and around control 51, all the control numbers change as gta02 seems to have an additional control there. So I am slowly going through all the controls from 51 onwards and trying to see what changed between gta01 and gta02. Hopefully at the end I will have a gsmbluetooth.state file that will work with gta02. If someone else has already done this please let me know, as this will be pretty tedious. Thanks Jim -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Jim Morris wrote:
I am still trying to get a bluetooth headset to work with the GTA02.
I found on the Wiki a pointer to this state file
http://opensource.wolfsonmicro.com/~gg/neo1973/gsmbluetooth.state
however it is gta01 specific, and around control 51, all the control numbers
change as gta02 seems
to have an additional control there.
So I am slowly going through all the controls from 51 onwards and trying to
see what changed between
gta01 and gta02.
By going through line by line I see the differences that the old gta01 state
files had between bt
and headset states, so fixing them up in a newer gta02 state file was ok until
gta01 control 87
upwards. None of these controls appear in a gta02 state file, so there seems to
be no equivalent
settings. Especially control 90, which seems pretty important for bluetooth but
has no equivalent in
the gt02 state file.
So can someone please explain what is going on here? Thanks
Here are the gta01 controls that do not fit into gta02 state files...
control.87 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 31'
iface MIXER
name 'Amp Right Playback Volume'
value 0
}
control.88 {
comment.access 'read write'
comment.type INTEGER
comment.count 1
comment.range '0 - 31'
iface MIXER
name 'Amp Mono Playback Volume'
value 0
}
control.89 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 Off
comment.item.1 'Call Speaker'
comment.item.2 'Stereo Speakers'
comment.item.3 'Stereo Speakers + Headphones'
comment.item.4 Headphones
iface MIXER
name 'Amp Mode'
value Off
}
control.90 {
comment.access 'read write'
comment.type ENUMERATED
comment.count 1
comment.item.0 Off
comment.item.1 'GSM Handset'
comment.item.2 'GSM Headset'
comment.item.3 'GSM Bluetooth'
comment.item.4 Speakers
comment.item.5 Headphones
comment.item.6 'Capture Handset'
comment.item.7 'Capture Headset'
comment.item.8 'Capture Bluetooth'
iface MIXER
name 'Neo Mode'
value 'GSM Bluetooth'
}
control.91 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Amp Spk 3D Playback Switch'
value false
}
control.92 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Amp HP 3d Playback Switch'
value false
}
control.93 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Amp Fast Wakeup Playback Switch'
value false
}
control.94 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 1
iface MIXER
name 'Amp Earpiece 6dB Playback Switch'
value false
}
--
Jim Morris, http://blog.wolfman.com
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Jim Morris wrote: Jim Morris wrote: I am still trying to get a bluetooth headset to work with the GTA02. I found on the Wiki a pointer to this state file http://opensource.wolfsonmicro.com/~gg/neo1973/gsmbluetooth.state however it is gta01 specific, and around control 51, all the control numbers change as gta02 seems to have an additional control there. So I am slowly going through all the controls from 51 onwards and trying to see what changed between gta01 and gta02. By going through line by line I see the differences that the old gta01 state files had between bt and headset states, so fixing them up in a newer gta02 state file was ok until gta01 control 87 upwards. None of these controls appear in a gta02 state file, so there seems to be no equivalent settings. Especially control 90, which seems pretty important for bluetooth but has no equivalent in the gt02 state file. One thing that may help, is if someone could provide a mapping of the wolfson registers as documented in the WM8753L pdf to the alsa controls. Someone had to have written the code that twiddles the registers in that chip, and would know which also control matches which register. I looked at the obvious choice which would be a 1:1 mapping of also control number to register number, but that doesn't match even closely. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GsmBluetooth state file for gta02
Cesar Eduardo Barros wrote: Jim Morris escreveu: One thing that may help, is if someone could provide a mapping of the wolfson registers as documented in the WM8753L pdf to the alsa controls. Someone had to have written the code that twiddles the registers in that chip, and would know which also control matches which register. That would be sound/soc/codecs/wm8753.c and sound/soc/s3c24xx/neo1973_gta02_wm8753.c on the kernel source code. Take a look: http://git.openmoko.org/?p=kernel.git;a=blob;f=sound/soc/codecs/wm8753.c;hb=stable http://git.openmoko.org/?p=kernel.git;a=blob;f=sound/soc/s3c24xx/neo1973_gta02_wm8753.c;hb=stable The mapping is there, you only have to find out how it's described. Thanks for the pointers. Thats 2,000 lines of code that is about as clear as mud! (and I've written audio drivers before). There is no mention of Bluetooth in these drivers, and no indication how to switch into bluetooth mode. Obviously gta01 was very different, and it is not even clear that the gsmbluetooth.state even worked on a gta01, at least I've never seen any gta01 user claim they had it working. I really don't see how we are supposed to figure this stuff out, without any help from Openmoko. This is a core piece of functionality for a GSM phone guys! Especially in a state where handsfree devices are required whilst driving. I would appreciate a little help from Openmoko to provide a working example of routing the audio to/from a BT headset during a call. I think they may need some help from Wolfson to figure it out! As I said there seem to be no equivalent functions in gta02's alsa settings to match the ones in gta01 that were used to switch into BT mode. Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Radek Barton( wrote: Do anyone have compiled package for share? Otherwise I would need to make one just to try an application :-). Thanks. Yes if you go to the blog, and download the tar file, there is an executable called qtgps, you just copy that to your FR, and run it on the FR. http://blog.wolfman.com/articles/2008/08/27/porting-xgps-to-qtopia-for-the-freerunner http://blog.wolfman.com/files/qtgps.tar.gz -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtopia 4.3.2 release
Lorn Potter wrote: Jim Morris wrote: Lorn Potter wrote: Hi all, Trolltech released Qtopia 4.3.2 this week, and the GPL sources hit the ftp server recently. ftp://ftp.trolltech.com/qtopia/source/qtopia-opensource-src-4.3.2.tar.gz I did a build from the Qtopia snapshot last night, does this mean I will already have gotten the updates? You should be good to go! Great thanks, I also noticed that ssl and tls were now enabled on email. Is there a reason that handwriting recognition input is not in the snapshot sources? -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fourth Request: What is the warranty for the FreeRunner?
Leonti wrote: In my opinion having only DOA right now is a good thing. Right now Freerunner is a phone for developers and they should accept the fact that it can have some imperfections. I want this project to grow. Do you imagine what would happen if everyone had warranty and discovered gps fix issue? Openmoko would broke on repairs (more on shipping costs). But when it will be in a mature stage I thing we will need a warranty of some kind. I have to disagree, this phone was sold as a GSM phone, if for instance the GSM buzzing issue needs a repair that cannot be done by the end user then I think OM is responsible for fixing that issue, otherwise (at least in the US) they can be held accountable for false advertising, as with the buzzing the phone is unusable as a GSM phone which was its primary purpose. I am sure they will take care of this issue though, and do the right thing. When the first batch of gta02 phones were sold, the Developer only and not usable as a primary phone issues were not well spelled out (if at all), and not spelled out at all on the OM store front. They have done a better job now of informing potential buyers, but there were an awful lot of phones sold initially without that disclaimer. I for one would have waited for GTA03 or later if it had been spelled out, just as I skipped GTA01 because it was well spelled out it was an alpha prototype for developers only. IMHO GTA02 was initially sold as Ready for end users or at least Usable as a primary phone, which turned out to be incorrect. I think the endless discussions on this list are due to that mis perception by many of the people who bought the first batches of GTA02's. I only partially regret my early purchase though. I can afford to have a $400 play toy, it has kept me busy for hours on end trying to get it to work the way I want, however that will change if I can't fix the GSM buzz issue, the way I have been able to fix many of the other issues. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WLAN troubles
Derick Rethans wrote: I do, and that's the weirdest part - the rx packet count increases too even. I also checked whether it could be a broken resolver, but pinging to an IP adres doesn't work either. Check your AP's firewall is not blocking TCP/IP from the FR, or any other firewall you may have. Also check the routing upstream of your AP and make sure it can route back to the FR. If you have mac address filtering enabled on the AP it may also cause problems, although I suspect that is not the case as you do get DHCP responses. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Now with github goodness ;) I have created a github repository for this, in the hopes we can grow it into a useful tool. http://github.com/wolfmanjm/qtopiagps I have also written a blog entry on ho wto setup the toolchain for Qtopia.. http://blog.wolfman.com/articles/2008/08/27/porting-xgps-to-qtopia-for-the-freerunner Oh and the name is now qtopiagps, as there was already a qtgps. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Michael 'Mickey' Lauer wrote: Sounds like a good plan. Let me note that by just using ogspd from the FSO framework, you could skip 1)-3) and go right to 5) (dunno about 4). I just ported xgps to Qtopia, this was of course using the client for gpsd. Qtopia does not currently use frameworkd, do you know if there are plans for qtopis to use it? (I'm not switching to FSO yet) If not can I install ogpsd standalone? I'd be happy to port my qtgps test app to use that instead of gpds, although the only thing I like about gpsd is the ability to connect to it from my destopk so I can develop the UI there, but I guess I can do an tcp daemon that talks to dbus, unless there is already one. The code and executable for the current qtgps which seems to gun on Qtopia ok with gpsd is here, if it helps anyone. http://blog.wolfman.com/files/qtgps.tar.gz -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Abdelrazak Younes wrote: IMO, just use the raw Ublox binary format. It's rather simple to decode. I have already implemented a binary decoder for the Ublox binary format based on Ublox open documentation of the protocol. My plan is to release this code under the GPL at some point. I agree if there is already a compact binary format then we should use that. Is there currently a way to capture that raw format? Here is my roadmap more or less: 1) port my Ublox decoder to linux and openmoko. I plan to use CMake as the build system. 2) add some logger functionality to the program above so that some Ublox logs can be requested. 3) implement an ephemeris and almanac saving and restoring solution 4) do the same as above for some SBAS messages if possible (not sure it is) 5) implement a simple Qt4 navigation program using openmap. Sounds good, I made a start with a Qtopia port of xgps, the fact it gets its data from gpsd at the moment is irrelvant as it could just as easily get the raw data and parse it. Code is here... (Its needs a bit of work to replace the sprintfs xpgs used to the equivalent Qt, but I simply copied/pasted that code from xgps). http://blog.wolfman.com/files/qtgps.tar.gz -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Marco Trevisan (Treviño) wrote: Jim Morris wrote: Attached is the source and binary, if you have Qtopia, just copy the binary qtgps to your FR, and run it from the file manager or terminal. (I'll figure out how to package it soon). Oh you also need to install gpsd (opkg install gpsd). If you have problems let me know, I'll put up a blog entry on how to compile this with Trolltechs toolchain. Launching it from the filemanager I get an error saying Can't open gpsd, while gpsd is installed, configured and running correctly in my phone. :o Hmm, can you do a gpspipe -r from the command line and see what happens? You may need to install gpsd_utils. I'll add some logging so we can see what is going on. By default it connects to gpsd at localhost, any parameters passed in will be taken as a different host to connect to. You could also try running it from the terminal and see if anything more useful is printed out. Thanks for trying it. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Marco Trevisan (Treviño) wrote: Jim Morris wrote: Launching it from the filemanager I get an error saying Can't open gpsd, while gpsd is installed, configured and running correctly in my phone. :o Ok I uploaded a new version, now with logging :) Run it, then ssh in and do a logread, copy paste the relevant parts of the log in an email to me, make sure you get the start and stop of the launch. There are a lot of weird log entries I don't understand from Qt, like this one... QTimeLine::start: already running But they don't look fatal. Also make sure that using host name localhost actually connects to 127.0.0.1 Thanks Jim -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Debian Install.sh error when run under Qtopia
I installed OK under Qtopia. I ssh'd in over USB. did /etc/init.d/qpe stop then the ./install.sh then reboot. Ganesha Krishna wrote: Hi, I tried Debian install.sh under Qtopia and hit this brick wall. (Nandfash = Qtopia 08.08 + kernel from the same package) -- ./install.sh all .. P: Configuring package apt P: Configuring helper cdebootstrap-helper-apt E: Internal error: install [EMAIL PROTECTED]:~# - The debian wiki ( http://wiki.debian.org/DebianOnFreeRunner) clearly says that install.sh is tested only under 2008.08, FSO and 2007.2 and doesnot mention Qtopia. google for cdebootstrap-helper-apt and you get numerous reports on similar install failures on desktops, it seems to be a (well) known bug. I could not find a work around for it though (have not tried too hard), is there one ? Thanks -GK ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko @ Linuxworld
Steve Mosher wrote: Ken was great. when I first thought to have the community help staff the booth, i had no idea how well it work out. the community speaks better for the product and the ideals than anyone can. Michael Shiloh wrote: Nice work Ken, one of our community volunteers! Yep he did a great job, pity he ended up selling his FR :( -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtGps for Trolltechs Qtopia
Hi, I ported the xgps program from the gpsd dist, to Qtopia (Trolltechs) as there was no GPS there yet and of course no X11 programs run on it. It is still a bit crude, but it works, and lets you at least see if your GPS works or not :) It is for testing like the OM one was for. Attached is the source and binary, if you have Qtopia, just copy the binary qtgps to your FR, and run it from the file manager or terminal. (I'll figure out how to package it soon). Oh you also need to install gpsd (opkg install gpsd). If you have problems let me know, I'll put up a blog entry on how to compile this with Trolltechs toolchain. Basically just qtopiamake, make then copy resulting binary to FR, oh and you need to add the gpsd client library libgps.so to the trolltech toolchain lib. Enjoy. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Lorn Potter wrote: Jim Morris wrote: Hi, I ported the xgps program from the gpsd dist, to Qtopia (Trolltechs) as there was no GPS there yet and of course no X11 programs run on it. It is still a bit crude, but it works, and lets you at least see if your GPS works or not :) It is for testing like the OM one was for. Attached is the source and binary, if you have Qtopia, just copy the binary qtgps to your FR, and run it from the file manager or terminal. (I'll figure out how to package it soon). no attachment, mate! Yea it turns out if you add an attachment it goes for moderator approval. It can be downloaded from here... http://blog.wolfman.com/files/qtgps.tar.gz Hey Lorn I'd be really interested in your opinion of the code, as my Qt programming is very rusty. One thing I was going to do was run the gps code in a thread so the UI comes up faster. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtGps for Trolltechs Qtopia
Lorn Potter wrote: One thing I was going to do was run the gps code in a thread so the UI comes up faster. One thing you could try, is only setupUi in the constructor, and then delay the other stuff in another slot with a singleshot timer. Yep that helped a little on the FR, helped a lot on my Desktop version! Thanks -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth on om 2008.08
Paul Buede wrote: Anyone know how to pair a bluetooth headset? I was able to do it on the Qtopia release, but don't see an app to do it on ASU. Is there a package I need to install? Am I just blind? You can pair with a headset, but to date no one has figured out how to get the audio to and from it. If you do let us know, it is the one thing blocking me from using it as a phone. (Plus the GSM buzzing of course). -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: date/time
William Kenworthy wrote: On 2007.2 from the 2008.8.11 image - I installed ntpdate and ran it. Now the date/time in the terminal is correct, but X clock and calendar are showing UTC. My location is +8 and the timezone is set according to the docs, but X is showing 8 hours behind the terminal time (therefore in UTC) which is weird. Where else can I look? BillK did you link /etc/localtime - /usr/share/zoneinfo/PST8PDT Or whatever your timezone is? This seemed to work for me, after restarting. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GPS logger / field data collection
Jim Morris wrote: Brian Wilson wrote: Jim wrote: I tried to used gpsd with my GPS base station my recollection was that it was totally useless for that. I assume that it will be useless for this project too but it's a starting point. gpsd seems to work fine for me, and I can develop my app on my host, and connect to it over the USB connection, or over the wifi. Other than the documented problems with the 5 reads to get the fix. Hmm I am losing faith in gpsd, I've run into the problem where it seems to be running and I can connect to it but there is no fix data. Restarting it doesn't fix it but poweroff and on the gps, and I get fixes again. Not sure if that is gpsd or the gps itself. -- Jim Morris, http://blog.wolfman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
