Re: Bluetooth headsets to the rescue
Perhaps I can clear up some of the confusion about the official fix. What we have is this as a rough timeline etc. 1. We have Joerg's SOP. Joerg, Werner, Tony Tu and I worked to get this document reviewed and out to the community. At that point I wasnt apprised of any wired headset mic issue. Joerge put out a draft. I Wasnt aware of any wired headset mic issue. I think even if I had been I still would have let the document out. 2. We asked if engineering had verified the change and they had. However, We wanted to insure that the SOP could actually be followed by somebody in the feild. That it was it good enough to pass out to the community and tell people to just follow the instrcutions. 3. Several individuals in the field followed the instructions and reported back that the fix worked. ( I dont recall any of the early reports back indicating issues with wired hreadset mics. Nobody tested it I suppose ) 4. We asked for a test proceedure that would indicate whether the fix actually succeeded. The answer was our standard audio test. I'm pretty certain that it doesnt test a wired headset mic. 5. Engineering approved the SOP. 6. Now we need to actually test the yeild rate. One individual in the feild had screwed up his phone. I replaced it free of charge. And so we contacted a rework house to bid on fixing the remaining stock of A6 we have. They took the SOP, reworked some boards and gave us a quote. Given that the yield rate was unknown we planned to do sample rework of a couple hundred to see what the actual cost is. Since A7 is fairly close to shipping, it made more sense to the team to hold off on the rework and focus on getting A7 shipping. Now thats just the process for OM to fix the phones it has in store. What about those in the feild? Which is what the list really cares more about. What is our official position and Policy? Well, first and foremost we tend toward solutions that involve the community. Volunteers. We do it in software by having write code, we do it in marketing by having community members man trade show booths, we did it in sales with the group purchase, so when it comes to fixing the A6 in the field we are going to start with a volunteer approach. I think the actual idea came from somebody in the community who suggested that people bring their FR to a local show and they get somebody to fix phones. Building on that idea we throw in the party idea. So first and foremost this is going to be a community effort. We are just in the process of working out those details. I've shipped the parts to fix phones to a few individuals and disty who have asked. and spare phones for those that get borked up ( how many should that be??) There are some volunteers with soldering irons ready to do their best. Will there be a program beyond this? I don't know. It depends on how well the volunteer fix it approach goes. But we've got other ideas that we will test out there as well. Right now We ae doing what we can with the people have and the resources at hand. Is it going to take longer than we like? yes. will everyone on the list be happy? no. Paul Fertser wrote: ezuall ezu...@gmail.com writes: Would it be worth while to start a petition for the official fix in the wiki No. They obviously know that community is extremely irritated about it and want to hear _any_ official statement. But they prefer being silent. I guess we'll need to wait for another month for the final clarifications. And btw, in case you missed it, there're already 2 officially (OM-the-company) supported buzz rework parties planned. And don't forget that the proposed rework doesn't fix wired headset mic, it will still produce a lot of buzz. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the Basics plan: Andy left
Thanks for the reply Steve, and sorry that I am being a bit confrontational! Of course I do not expect you to do your dirty laundry in public (but it was those lunchtime magnum bottles of champagne on the expense account, wans't it?), but since Andy did make a lot of good and very visible changes, a quick We are sorry to see him go, wish him all luck in his future endeavours and Werner will take over kernel patch management message would have been nice! Thanks, (also for the in buzz fix thread reply - cleared it up for me!) - Gunnar Steve Mosher wrote: Thanks Gunnar, There is one thing we tend to be very tight lipped about. HR issues. That is its very rare that you will find any employee commenting on why a particular individual is not with the company anymore. Some people are let go for performance. Some are let go due to cost cutting. Some choose voluntary separation. Some request to be let go. This is highly personel data, so we try to avoid at all costs talking about these issues. As to the other issues, there are some cases were the situation is so fluid and still in process that commenting really isnt possible. I'll relook at the official buzz fix thread and see if I can add anything helpful. Gunnar Aastrand Grimnes wrote: I love these threads where we talk about company things, like the recent official buzz fix thread, or the secret UI design team IRC conversation, and there is NEVER any response from OpenMoko. I wonder if they see the community mailinglist as COMMUNITY ONLY, i.e. no employees allowed? :) Cheers, - Gunnar Laszlo KREKACS wrote: Dear List, I can't express how sad I'm when I read Andy Green left Openmoko. I do not know why he left (and it is not my business anyway), but I know since Andy was at Openmoko the kernel side began to form shape, and got things work. (suspend? anyone?) I know that every people is replacable at a company, but show me at least two people who made as much commit/day (and code quality) what Andy did. You cant, because there is no black magic here, no marketing mantra, it is all public and we can see who commits what into the git tree. So you just let go the single most valuable people at kernel side. Nice try. I do not know who is responsible for this desicion but I hope they are not the same design team who had fired Rasterman. Oh, and Harald Welte had left Openmoko too, but we never knew the exact details. Who left? At the hardware side: Werner and Joerg at the software side: Mirko and hmm, nobody? Im counting... How long will they stand? If I had enough money I would just hire those people and form a new company and outsource the fabrication to a chinese company (that's exactly what everyone does including apple) and forget about Openmoko (the name was a bad choice anyway ;) I know this letter a bit harsh, but it is intented to address to whom is concerned: Get your head out of your @ss, sit down and think about a bit. You must honor those people who gets the job done! The best would be just hire back those valueable people, and work out how they want to work. Even if they want to form a new (software) company, to make sure this situation will never happen again. I always wanted to buy the next model of openmoko, but I know exactly, if it has bugs (and surely it will), never or really slowly will be fixed (as the current(=everyone gets fired) situation shows). And if it will have hardware bugs, they will be never fixed by Openmoko (as the company), and I can just hope that some people offer *their free time and knowledge* and fix the problem UNOFFICIALLY (unless they did not get until fired). Can you imagine where we were today without Andy and Rasterman? I surely can: an unofficial/unsupported qtextended with an unoptimized 2.6.22 kernel. All those nice things came from these (fired) people. I'm afraid of the future. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
Steve, all, On Wed, Mar 25, 2009 at 7:50 AM, Steve Mosher st...@openmoko.com wrote: Perhaps I can clear up some of the confusion about the official fix. What we have is this as a rough timeline etc. [Big snip] Steve, thanks for the official words on this. I assume (yes, I know about assumptions) that people tend to get unhappy if they don't hear anything 'official'. I guess people get impatient if there is nothing they can do. It's a community effort after all, as you said. Christ van Willegen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qt extended stops receiving sms
Hi, Tried fscking and it didn't seem to fix the problem. Any other idea's? Glen On Tuesday 17 March 2009, giacomo giotti mariani wrote: Hi, I've been having a problem with QT Extended not receiving txt messages. Any suggestions? When I restart qtopia they seem to arrive, or if I boot into om 2008.12 they arrive. Regards Glen Ogilvie I had a similar problem with OM2008.12 installed on the uSD card. It was caused by file system fragmentation. If it is the same for you (I mean you use QText from uSD) try fsck. By Giacomo signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr- avoid suspend and dim screen
On Wed, Mar 25, 2009 at 3:10 AM, W.Kenworthy bi...@iinet.net.au wrote: [Snippage] /usr/bin/xrandr -o 1 [Snippage] I usually use -o 3 to get the usb connector on top, so I can attach a usb cable to attach to a cigarette lighter... Christ van Willegen ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
Thank you for the feedback Steve, Please note that this was never meant to be an attack on Openmoko, just a question that was nagging me for a while there. I really meant what I said when saying I am a fanboy. Now I have nothing left to winge about, and I've used up my last questions. Am I happy now? Yes, just the feedback is enough. I don't ask questions so people can say what I want to hear, I ask them for the real answers, and that's what you gave us. Thanks again and all the best ezuall -- View this message in context: http://n2.nabble.com/Buzz-Issues---Last-Questions%2C-I-promise-tp2509041p2531122.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko meeting Stuttgart (Wed 25.03.2009)
Hi, a bad notice i got ill and are lying in my bed with fever, so that i won't be able to take part this evening I hope you still have a nice meeting there and that we can repeat it soon, so that i am able to join. You should be 7 people as far as i know. More info: http://freeyourphone.de/portal_v1/viewtopic.php?f=13t=978start=15 Yes i am also sorry for the short notice, i had forgotten to post it on the mailing list when we decided it on the freeyourphone board. Okey hope you enjoy the meeting then. Greetings vale -- View this message in context: http://n2.nabble.com/Openmoko-meeting-Stuttgart-%28Wed-25.03.2009%29-tp2525313p2531233.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: linphone 3.1.0
Hi, Al Johnson openm...@mazikeen.demon.co.uk writes: Here's a preliminary bitbake recipe for the latest linphone release. Binaries for fso-milestone5 are in: http://openmoko.truebox.co.uk/repos/mazikeen/fso-milestone5/ipk/armv4t/ Great thanks for working on that! :) Problems: * I haven't got it to do sound yet - it seems unhappy with the alsa device capabilities. I don't know if this is a configuration issue or a fundamental problem. I guess you face the same issue with borked /etc/asound.conf as others. It has dmix as the default device, and dmix obviously doesn't support recording. Probably you can remove /etc/asound.conf altogether or try to mimic configuration of any desktop distro. Or just configure linphone to use hw:0,0 by default. Also, don't forget that a special voip.state should be loaded before trying to input/output sound. It uses DAI mode 10 and arecord -D hw:0,0 | aplay -D hw:0,0 is known to work. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is SIM Toolkit possible to support on the freerunner?
My vote: implement it, banking is part of mobile communication like calls and sms with the same relevance, for me it is the one and only thing, that make me not use neo as phone but PDA only I agree. -- /_\ The ASCII Per comunicare in modo riservato: \_/ Ribbon Campaign gpg --keyserver pool.sks-keyservers.net \ X Against HTML--recv-keys 20611EAD /_\ Email! -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
3. Several individuals in the field followed the instructions and reported back that the fix worked. ( I dont recall any of the early reports back indicating issues with wired hreadset mics. Nobody tested it I suppose ) well, i asked for it a long time ago, long before the buzz was fully identified. the answer i got was to try a ferrite bead around the headset's wire, which did not help at all. then the the buzz issue gained a lot of momentum, but nobody ever mentioned it to be different from the buzz with the wired hs -- so i simply assumed it to be the same issue and thus to be fixed with the sop available. from somebody in the community who suggested that people bring their FR to a local show and they get somebody to fix phones. Building on that idea we throw in the party idea. So first and foremost this is going to be a community effort. i have no problem with volunteer work and the party idea either (at least it allows to show up in person and have it fixed almost immediately, and not having it posted somewhere and being days w/o phone). but so far there was no definite answer about what happens in a case of mors in tabula, ie the fr is dead afterwards -- the best was something like maybe om will replace those. if om is willing to state that they are to replace phones killed by applying the fix according to the sop, my concerns are resolved. according to the latest news on the headset buzz i don't think there will ever be a sensible field applicable fix, so i would have to live with the internal buzz fix and the workarounds sketched out. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the Basics plan: Andy left
There is one thing we tend to be very tight lipped about. HR issues. nobody expects to hear internals, but visible information about staff changes, at least when it affects people being some kind of om's face to community, would help. As to the other issues, there are some cases were the situation is so fluid and still in process that commenting really isnt possible. I'll relook at the official buzz fix thread and see if I can add anything helpful. of course it is problematic. but communication is an important part of community building and community relations. we got those montly community updates, a section like from om, the company, noticing about ongoing issues would be highly apprecaited, i think. there, in short, could be mentioned that important, community visible members of staff are leaving or hired or what you wrote regarding the buzz: tests going on, procedure has been etablished, bids are requested, pondering ways of fixing in field ... so we could rest assured that those things are not forgotten but being worked on (and maybe the wired headset buzzing would have come up again earlier). the heated debates when rasterman left or about the way to handle th buzz fix could maybe have been a lot cooler with a constant flow (or trickle) of information, even if it says we hear you, but we're not quite sure yet, how to procede. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qt extended stops receiving sms
On Wednesday 25 March 2009, Glen Ogilvie wrote: Hi, Tried fscking and it didn't seem to fix the problem. Any other idea's? Given I've only had this happen recently once, and it's been fine ever since, I'm not sure.. :-( I guess you could try updating your Calypso firmware to moko11 if you've not already done so, don't know if that will help with this though.. http://wiki.openmoko.org/wiki/GSM/Flashing I did mine with the uSD image, worked nicely (even if the screen blanker gave me a fright at first!). cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP signature.asc Description: This is a digitally signed message part. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is SIM Toolkit possible to support on the freerunner?
Sorry, but voting doesn't really help. If I get a reasonable patch against the framework, I will let it go in -- whether disabled or not by default is a completely different issue. If not, it's going to be left out. Cheers, Mickey. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is SIM Toolkit possible to support on the freerunner?
Joerg Reisenweber wrote: Am Di 24. März 2009 schrieb Michael 'Mickey' Lauer: Technically, SIM toolkit support is possible with the Calypso. I have commented previously about this, so please look my older posts up; In a nutshell, STK is a heavy cross-layer spec, so adding it would need quit some thought. FSO will not work on it, but appreciate patches. My vote: don't implement STK, or at least disable it by default. I don't like my SIM to do any program execution I don't believe the choice is yours to make. The SIM card contains a (small) microprocessor, and the telco is able to update its software at will. You have full control over the ARM processor that runs Linux, and full control over how it interacts with the SIM card. But not what goes on in the SIM card itself. The SIM card part of STK is in that card already. The part I would like to have is mostly a communication layer. To be useful, a STK app (like that banking stuff) need to: * alert you, possibly with a ringtone * display text/icons stored in the program or receiced from the bank * collect input (in this case, a PIN code) to send back to the bank. The SIM card processor have only two channels of communication - it can deal with the telco, and it can communicate with the ARM processor through the gsm modem. It can't access the display on its own. The part of STK that I'd like to see is just a communication layer. Probably a part of the framework that listen to requests from STK, and spawns a STK app when needed. Very similiar to how it already listens for SMS messages, and launch the message reader when something comes in. This only need to display stuff and play sound, present input fields and send the input back to the SIM card program. I don't see such a STK app taking control of the phone or lock it down. If I have to write it myself it'll be open source, so you can see what it do. And all it will be is a GUI+soundplayer for software already running on the SIM card. It'll be able to open a window asking for input - that's it! In particular, it won't need to access the filesystem so there is very little potential for damage. And of course - you won't have to use an STK app - similiar to how you can choose to not use the phone's sms capability. (You can delete the SMS app if you hate messaging, the same will be possible with a STK app.) This sort of thing can only lock down proprietary phones _because_ you don't control the host processor software. On the freerunner you do. A proprietary phone can have a music player that won't start unless it receives a paid activation code from the telco. On the freerunner, you install whatever music player you like. Most likely one without artifical limitations. And so on for everything else this device can do. The way I see it, STK is optional stuff. I didn't have to use this banking app, but I'll make things easier for me if I do. I'd be able to do internet banking from any computer, without having to install one-time certificates. Of course the telco _can_ install a hostile program in the SIM card, but they can do that anyway - they just don't get a GUI for it right now. If STK pops up something you don't like, you'll be able to close the window on a freerunner :-) Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is SIM Toolkit possible to support on the freerunner?
Michael 'Mickey' Lauer wrote: Technically, SIM toolkit support is possible with the Calypso. I have commented previously about this, so please look my older posts up; In a nutshell, STK is a heavy cross-layer spec, so adding it would need quit some thought. FSO will not work on it, but appreciate patches. Is there hope of getting the necessary documentation for the gsm device in the freerunner? With a license that doesn't stand in the way of making a open-source app based on it? STK itself seems to be documented on the net, but each gsm device seems to do this differently. There is no standard on how to communicate STK to/from a gsm device. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Multitouch on FR ... imho should be possible to mimic
The Digital Pioneer wrote:
It's tough to say until someone tries it. I don't have the GUI expertise
to do anything of the sort, but I'd love to see someone try it.
Testing is easy - no expertice needed.
Edit /etc/X11/Xserver
You'll find the parameter list for the xserver under a GTA02 (or GTA01)
heading. Currently, it is:
ARGS=$ARGS -dpi ${DPI} -screen ${SCREEN_SIZE} -mousetslib -hide-cursor
-root-ppm /usr/share/pixmaps/xsplash-vga.ppm vt1
Remove the -hide-cursor, then restart X or just boot the thing.
You will now get a visible mouse cursor, shaped like a X. It always move
to wherever the touchscreen driver believe you're touching the screen.
Touch the screen, the X moves under your finger. Lift your finger, and
you'll see it. Touch or drag with a stylus, and you'll see the mouse
cursor move around. Just like on a PC screen.
Now touch down with two fingers, and see the mouse cursor move/jump to
somewhere inbetween. That is what the touchscreen driver sees, that is
what software can _try_ to interpret as a gesture.
Try it, see for yourself. Do the midpoint seem stable enough to resize
a window? If not, is it at least stable enough to detect a rough
gesture? Do it slide wildly as you move your fingers?
I just tested myself.
With firm pressure, the cursor stays between my fingers. There is some
hight-frequency jitter as firmly pressed fingers slide - this can
probably be filtered out.
With normal light pressure and one moving finger, the cursor slides back
and forth between the midpoint and the stationary finger. Apparently,
the moving finger almost disapper at times. The cursor is always closer
to the stationary finger. No surprise - it is natural to apply more
pressure with a stationary finger. Especially if the device is hand-held.
If I hold two fingers on the screen, I can move the cursor back and
forth between the two positions with precision, by varying finger
pressure. One could control a 2D sidescroll game this way, except it'd
be way easier to just use the stylus for direct control.
Helge Hafting
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] vim, ntpclient... a repository ?
giacomo giotti mariani wrote: Date: Sun, 22 Mar 2009 09:51:56 +0100 From: Xavier Cremaschi omega.xav...@gmail.com Subject: [SHR] vim, ntpclient... a repository ? To: community@lists.openmoko.org Message-ID: gq4u7d$gb...@ger.gmane.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi folks, does someone know how to install vim (not vi) in SHR ? I think there is one repository I don't have, I can't believe vim to be not available :P Xavier. Hi Xavier, you can find vim (in my case worked in both OM2008.x and SHR) here: http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/vim_7.0-r1.1_armv4t.ipk And obviously it works perfectly! Works, but not perfectly for me. In particular, when i SSH into my freerunner from a linux laptop, the cursor keys don't work in vim insert mode. They insert C and D and such instead. They only work in command mode. The vi supplied with SHR has no problems with cursor keys in insert mode. They do the expected - they move the cursor in all modes. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is SIM Toolkit possible to support on the freerunner?
Am Mittwoch, den 25.03.2009, 14:13 +0100 schrieb Helge Hafting: Michael 'Mickey' Lauer wrote: Technically, SIM toolkit support is possible with the Calypso. I have commented previously about this, so please look my older posts up; In a nutshell, STK is a heavy cross-layer spec, so adding it would need quit some thought. FSO will not work on it, but appreciate patches. Is there hope of getting the necessary documentation for the gsm device in the freerunner? With a license that doesn't stand in the way of making a open-source app based on it? If you're interested in doing this, I'm sure we can work this out. STK itself seems to be documented on the net, but each gsm device seems to do this differently. There is no standard on how to communicate STK to/from a gsm device. Correct. While the STK commands are thorougly documented in the specs, the AT commands are device-specific. I can collect the Calypso-specific information you need -- if you want to work on that. :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Multitouch on FR ... imho should be possible to mimic
You saw this, didn't you: http://lists.openmoko.org/pipermail/community/2009-March/044481.html r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR] vim, ntpclient... a repository ?
Works, but not perfectly for me. In particular, when i SSH into my freerunner from a linux laptop, the cursor keys don't work in vim insert mode. They insert C and D and such instead. They only work in command mode. adding set nocompatible your ~/.vimrc file should fix this ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Multitouch on FR ... imho should be possible to mimic
That's an excellent point, Helge. I just tried it, and it works quite well. The cursor doesn't go exactly to the midpoint, but I would say it's definitely usable data. It moves almost exactly as expected. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR-testing] Problems with battery
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi list, a small problem: I use my Nokia 6630 compatible battery (BL-5C) in the Neo with SHR-testing, but Neo doesn't recognize the battery chip, so it says that it is empty even it is full. I've edited /etc/freesmartphone/opreferences/rules.yaml and commented the section that powers off the phone with low battery level. But, it still remains a problem: the battery doesn't charge, why? Here is my rules.yaml[1]. This is making my phone unusable, and on 27 March I'll travel far away: I need the battery for OpenStreetMap on the Neo!!! :| Also: could someone explain me the differences in lock, idle_prelock, idle and idle_dim in Timeouts settings? Thanks [1] http://pastebin.com/m51227e19 - -- Francesco de Virgilio *Ubuntu-it Member and Wiki Editor* mailto:frad...@ubuntu-it.org http://wiki.ubuntu-it.org/FrancescoDeVirgilio *Wikimedia projects contributor* http://en.wikipedia.org/wiki/User:Fradeve11 *OpenStreetMap Mapper* http://www.openstreetmap.org/user/Fradeve11 *Blog* http://fradeve.netsons.org Love - Peace - Freedom - Free Software GPG 0x6482E056 (FP B996 A12C BD52 2A9B CDD3 812D 462D 93B0 6482 E056) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAknKWz0ACgkQRi2TsGSC4FYhQwCfcMbPaHqzzqA+Y7asugi818xs gc4AnimDqbtYEAhgIBSl2G4sdinVQ1wo =0eUf -END PGP SIGNATURE- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Data call (aka CSD) with QtExtended
Thanks for the update. I will manage to test on my FR soon.
Cordially,
Tuan
On Wed, Mar 25, 2009 at 3:33 AM, Ed Kapitein e...@kapitein.org wrote:
Hi Tuan,
I was able to make a datacall to a landline modem :-)
So you can use your freerunner to dial in to an ISP if you like.
i wil paste the proof of my success below.
Now i just need to find a way to make it less expensive...
Kind regards,
Ed
MODEM=$(dbus-send --system --print-reply --type=method_call
--dest=org.pyneo.muxer /org/pyneo/Muxer
org.freesmartphone.GSM.MUX.AllocChannel string:$identvar | grep string |
awk -F '' '{ print $2 }')
pppd nodetach debug call inbel ${MODEM}
timeout set to 25 seconds
send (ATE0^M)
abort on (BUSY)
abort on (DELAYED)
abort on (NO ANSWER)
abort on (NO DIALTONE)
abort on (VOICE)
abort on (ERROR)
abort on (RINGING)
expect (OK)
^M
OK
-- got it
send (AT+CBST=0,0,1^M)
expect (OK)
^M
^M
OK
-- got it
send (AT+CR=1^M)
expect (OK)
^M
^M
OK
-- got it
send (atdt 1234567890^M)
expect (CONNECT)
^M
^M
+CR: REL ASYNC^M
^M
CONNECT
-- got it
send (^M)
expect (Login)
^M
^M
Login
-- got it
send (isp_user_n...@your.isp.dom^m)
expect (Password)
: isp_user_n...@your.isp.dom^m
Password
-- got it
send (your_isp_passwd^M)
expect (L2TP)
: ^M
^M^M
L2TP
-- got it
send (/n/d^M)
Serial connection established.
using channel 11
Using interface ppp0
Connect: ppp0 -- /dev/pts/4
rcvd [LCP ConfReq id=0x0]
sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0x34d2bbd3 pcomp
accomp]
sent [LCP ConfAck id=0x0]
rcvd [LCP ConfReq id=0x1 asyncmap 0xa auth pap magic 0x148b1bd
pcomp accomp mrru 1524 endpoint
[local:61.72.31.2e.6e.69.6b.2d.61.73.64] 17 04 59 3d]
sent [LCP ConfRej id=0x1 mrru 1524 17 04 59 3d]
rcvd [LCP ConfAck id=0x1 asyncmap 0x0 magic 0x34d2bbd3 pcomp
accomp]
rcvd [LCP ConfReq id=0x2 asyncmap 0xa auth pap magic 0x148b1bd
pcomp accomp endpoint [local:61.72.31.2e.6e.69.6b.2d.61.73.64]]
sent [LCP ConfAck id=0x2 asyncmap 0xa auth pap magic 0x148b1bd
pcomp accomp endpoint [local:61.72.31.2e.6e.69.6b.2d.61.73.64]]
sent [LCP EchoReq id=0x0 magic=0x34d2bbd3]
sent [PAP AuthReq id=0x1 user=isp_user_n...@your.isp.dom
password=hidden]
rcvd [LCP EchoRep id=0x0 magic=0x148b1bd]
rcvd [PAP AuthAck id=0x1 ]
PAP authentication succeeded
sent [CCP ConfReq id=0x1 mppe -H -M -S -L -D -C deflate 15
deflate(old#) 15 bsd v1 15]
sent [IPCP ConfReq id=0x1 compress VJ 0f 01 addr 0.0.0.0 ms-dns1
0.0.0.0 ms-dns3 0.0.0.0]
rcvd [IPCP ConfReq id=0x1 addr 213.53.28.122]
sent [IPCP ConfAck id=0x1 addr 213.53.28.122]
rcvd [LCP EchoReq id=0x1 magic=0x148b1bd c0 23 05 06]
sent [LCP EchoRep id=0x1 magic=0x34d2bbd3 00 00 00 00]
rcvd [LCP ProtRej id=0x3 80 fd 01 01 00 15 12 06 00 00 00 00 1a 04 78 00
18 04 78 00 15 03 2f]
rcvd [IPCP ConfRej id=0x1 compress VJ 0f 01]
sent [IPCP ConfReq id=0x2 addr 0.0.0.0 ms-dns1 0.0.0.0 ms-dns3
0.0.0.0]
rcvd [IPCP ConfReq id=0x2 addr 213.53.28.122]
sent [IPCP ConfAck id=0x2 addr 213.53.28.122]
rcvd [IPCP ConfNak id=0x2 addr 217.149.216.138 ms-dns1 217.149.196.6
ms-dns3 217.149.192.6]
sent [IPCP ConfReq id=0x3 addr 217.149.216.138 ms-dns1 217.149.196.6
ms-dns3 217.149.192.6]
rcvd [IPCP ConfAck id=0x3 addr 217.149.216.138 ms-dns1 217.149.196.6
ms-dns3 217.149.192.6]
replacing old default route to usb0 [192.168.0.200]
local IP address 217.149.216.138
remote IP address 213.53.28.122
primary DNS address 217.149.196.6
secondary DNS address 217.149.192.6
Script /etc/ppp/ip-up started (pid 1992)
Script /etc/ppp/ip-up finished (pid 1992), status = 0x0
Terminating on signal 2
Connect time 0.6 minutes.
Sent 874 bytes, received 1113 bytes.
restoring old default route to usb0 [192.168.0.200]
Script /etc/ppp/ip-down started (pid 2005)
sent [LCP TermReq id=0x2 User request]
Script /etc/ppp/ip-down finished (pid 2005), status = 0x0
rcvd [LCP TermAck id=0x2]
Connection terminated.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: shr- avoid suspend and dim screen
What I would like to see is the disabling of screen dimming while (for instance) a game such as MokoMaze is running, which has no screen touching. It's a huge pain when you're about to win, and the screen blacks out and you die. Mokomaze has already got this feature. As is said on its page on opkg.org, you need a new config file [1]. The effect is the same as creating a launching script, but you need less manupulations to set it up. Anyway, the best way to resolve the problem is to have a daemon which automatically disables auto-suspend and display dimming when any program from the list of known ones is running. [1] - http://projects.openmoko.org/frs/download.php/674/avoiding-suspend-and-dim.tar.gz -- View this message in context: http://n2.nabble.com/shr--avoid-suspend-and-dim-screen-tp2528525p2533957.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the Basics plan: Andy left
Gunnar, I didnt consider your post the least bit confrontational. You should see some of the mails I send to folks. I like your suggestion about some sort of farewell announcement. Gunnar AAstrand Grimnes wrote: Thanks for the reply Steve, and sorry that I am being a bit confrontational! Of course I do not expect you to do your dirty laundry in public (but it was those lunchtime magnum bottles of champagne on the expense account, wans't it?), but since Andy did make a lot of good and very visible changes, a quick We are sorry to see him go, wish him all luck in his future endeavours and Werner will take over kernel patch management message would have been nice! Thanks, (also for the in buzz fix thread reply - cleared it up for me!) - Gunnar Steve Mosher wrote: Thanks Gunnar, There is one thing we tend to be very tight lipped about. HR issues. That is its very rare that you will find any employee commenting on why a particular individual is not with the company anymore. Some people are let go for performance. Some are let go due to cost cutting. Some choose voluntary separation. Some request to be let go. This is highly personel data, so we try to avoid at all costs talking about these issues. As to the other issues, there are some cases were the situation is so fluid and still in process that commenting really isnt possible. I'll relook at the official buzz fix thread and see if I can add anything helpful. Gunnar Aastrand Grimnes wrote: I love these threads where we talk about company things, like the recent official buzz fix thread, or the secret UI design team IRC conversation, and there is NEVER any response from OpenMoko. I wonder if they see the community mailinglist as COMMUNITY ONLY, i.e. no employees allowed? :) Cheers, - Gunnar Laszlo KREKACS wrote: Dear List, I can't express how sad I'm when I read Andy Green left Openmoko. I do not know why he left (and it is not my business anyway), but I know since Andy was at Openmoko the kernel side began to form shape, and got things work. (suspend? anyone?) I know that every people is replacable at a company, but show me at least two people who made as much commit/day (and code quality) what Andy did. You cant, because there is no black magic here, no marketing mantra, it is all public and we can see who commits what into the git tree. So you just let go the single most valuable people at kernel side. Nice try. I do not know who is responsible for this desicion but I hope they are not the same design team who had fired Rasterman. Oh, and Harald Welte had left Openmoko too, but we never knew the exact details. Who left? At the hardware side: Werner and Joerg at the software side: Mirko and hmm, nobody? Im counting... How long will they stand? If I had enough money I would just hire those people and form a new company and outsource the fabrication to a chinese company (that's exactly what everyone does including apple) and forget about Openmoko (the name was a bad choice anyway ;) I know this letter a bit harsh, but it is intented to address to whom is concerned: Get your head out of your @ss, sit down and think about a bit. You must honor those people who gets the job done! The best would be just hire back those valueable people, and work out how they want to work. Even if they want to form a new (software) company, to make sure this situation will never happen again. I always wanted to buy the next model of openmoko, but I know exactly, if it has bugs (and surely it will), never or really slowly will be fixed (as the current(=everyone gets fired) situation shows). And if it will have hardware bugs, they will be never fixed by Openmoko (as the company), and I can just hope that some people offer *their free time and knowledge* and fix the problem UNOFFICIALLY (unless they did not get until fired). Can you imagine where we were today without Andy and Rasterman? I surely can: an unofficial/unsupported qtextended with an unoptimized 2.6.22 kernel. All those nice things came from these (fired) people. I'm afraid of the future. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: linphone 3.1.0
On Wednesday 25 March 2009, Paul Fertser wrote: Problems: * I haven't got it to do sound yet - it seems unhappy with the alsa device capabilities. I don't know if this is a configuration issue or a fundamental problem. I guess you face the same issue with borked /etc/asound.conf as others. It has dmix as the default device, and dmix obviously doesn't support recording. Probably you can remove /etc/asound.conf altogether or try to mimic configuration of any desktop distro. Or just configure linphone to use hw:0,0 by default. Also, don't forget that a special voip.state should be loaded before trying to input/output sound. It uses DAI mode 10 and arecord -D hw:0,0 | aplay -D hw:0,0 is known to work. I suspected as much, but couldn't confirm at the time. I had only given it a cursory check with the config that used to work for me with v1.6 and 2007.2. Now I can confirm it works using Brian Code's asound.conf and the voip- handset.state that comes with milestone5. Brian's config is available at: http://www.koolu.org/asound.conf ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
thanks ezuall, I never took it as an attack on OM. There are some things we never counted on in building a business. Things you learn over time. Like doing field repairs. It involves whole departments and staff that are simply not present at OM. In Marketing we are only a couple people deep. Me the VP and a couple others who also have sales duties. Still, we picked up this task and will drive it forward at the best pace we can. ezuall wrote: Thank you for the feedback Steve, Please note that this was never meant to be an attack on Openmoko, just a question that was nagging me for a while there. I really meant what I said when saying I am a fanboy. Now I have nothing left to winge about, and I've used up my last questions. Am I happy now? Yes, just the feedback is enough. I don't ask questions so people can say what I want to hear, I ask them for the real answers, and that's what you gave us. Thanks again and all the best ezuall ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth headsets to the rescue
arne anka wrote: 3. Several individuals in the field followed the instructions and reported back that the fix worked. ( I dont recall any of the early reports back indicating issues with wired hreadset mics. Nobody tested it I suppose ) well, i asked for it a long time ago, long before the buzz was fully identified. the answer i got was to try a ferrite bead around the headset's wire, which did not help at all. then the the buzz issue gained a lot of momentum, but nobody ever mentioned it to be different from the buzz with the wired hs -- so i simply assumed it to be the same issue and thus to be fixed with the sop available. I suppose it also didnt get on our radar screen because we dont supply or test any wired headset mic. from somebody in the community who suggested that people bring their FR to a local show and they get somebody to fix phones. Building on that idea we throw in the party idea. So first and foremost this is going to be a community effort. i have no problem with volunteer work and the party idea either (at least it allows to show up in person and have it fixed almost immediately, and not having it posted somewhere and being days w/o phone). but so far there was no definite answer about what happens in a case of mors in tabula, ie the fr is dead afterwards -- the best was something like maybe om will replace those. Assuming a good tech the yield rate should be very high and I would replace phones killed in action. I've already done that for one guy who tried and failed. The key is getting a good tech you can trust. If we can assure he knows what he is doing, then those killed in action would be replaced. In one case I think we just handled it by paying the tech in phones. Say, he gets 5 phones for a fix it party. If he's good he walks away with 5 phones to sell. If he's bad, he has to use his pay of 5 phones to replace the ones he breaks. if om is willing to state that they are to replace phones killed by applying the fix according to the sop, my concerns are resolved. The key points here would be determining that the SOP was followed by a competetent technician, then yes. according to the latest news on the headset buzz i don't think there will ever be a sensible field applicable fix, so i would have to live with the internal buzz fix and the workarounds sketched out. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr- avoid suspend and dim screen
W.Kenworthy wrote: Ah! What a relief!! :-) so, mdbus is what I was looking for! Many thanks for the script. Fernando ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the Basics plan: Andy left
Inlines below. arne anka wrote: There is one thing we tend to be very tight lipped about. HR issues. nobody expects to hear internals, but visible information about staff changes, at least when it affects people being some kind of om's face to community, would help. A couple other have made this suggestion. I would put it on the responsible manager to announce the changes in his departments coordinated with the person who has a change in status. In Sales and Marketing We had the following changes: 1. Ailsa is no longer with the company 2. Ijen is no longer with the company. 3. Tony Tu is no longer reporting to me. So for right now Sales and Marketing is: 1. Steve 2. Chelsea 3. Jollen and we get assistence from liane who works the web shop. As to the other issues, there are some cases were the situation is so fluid and still in process that commenting really isnt possible. I'll relook at the official buzz fix thread and see if I can add anything helpful. of course it is problematic. but communication is an important part of community building and community relations. we got those montly community updates, a section like from om, the company, noticing about ongoing issues would be highly apprecaited, i think. there, in short, could be mentioned that important, community visible members of staff are leaving or hired or what you wrote regarding the buzz: tests going on, procedure has been etablished, bids are requested, pondering ways of fixing in field ... so we could rest assured that those things are not forgotten but being worked on (and maybe the wired headset buzzing would have come up again earlier). We dont disagree. The issue is always priorities. A while back when we were more heavily staffed in sales and marketing I made it a point to read the community list everyday; however, more and more of my time is now taken up by other matters; At some point I look at my community list and say 600 mails, i never get through that then it goes to 800, then 1000. Luckily, there a few folks who will mail me directly when they see that some big fire needs my attention. You can do that if you like Just dont make it an everyday thing. the heated debates when rasterman left or about the way to handle th buzz fix could maybe have been a lot cooler with a constant flow (or trickle) of information, even if it says we hear you, but we're not quite sure yet, how to procede. understood. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Is SIM Toolkit possible to support on the freerunner?
Am Mittwoch, den 25.03.2009, 14:13 +0100 schrieb Helge Hafting: Michael 'Mickey' Lauer wrote: Technically, SIM toolkit support is possible with the Calypso. I have commented previously about this, so please look my older posts up; In a nutshell, STK is a heavy cross-layer spec, so adding it would need quit some thought. FSO will not work on it, but appreciate patches. Is there hope of getting the necessary documentation for the gsm device in the freerunner? With a license that doesn't stand in the way of making a open-source app based on it? If you're interested in doing this, I'm sure we can work this out. STK itself seems to be documented on the net, but each gsm device seems to do this differently. There is no standard on how to communicate STK to/from a gsm device. Correct. While the STK commands are thorougly documented in the specs, the AT commands are device-specific. I can collect the Calypso-specific information you need -- if you want to work on that. :M: May be there should be some daemon to STK - like fso-stk and runnable GUI for menu, because it should respond to STK events - incoming message from bank etc what we need is documentation, how restricted is NDA - and for who? people outside of company? -- View this message in context: http://n2.nabble.com/Is-%22SIM-Toolkit%22-possible-to-support-on-the-freerunner--tp2519985p2534451.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Remoko/Bluez 4
Hey, is anyone working on porting Remoko to Bluez4? I moved to Bluez4 and I want my Remoko back! :P -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Linball game 0.2 version
i had the same problem this fixed it i added those two lines to linball.sh On Tue, Mar 24, 2009 at 9:29 PM, Rafael Ignacio Zurita rizur...@yahoo.com wrote: Hello, --- On Tue, 3/24/09, Will Siddall will.sidd...@gmail.com wrote: I know it's been a while since anyone last wrote, but I just thought I would try it on SHR-testing (20080303). When it starts up, it rotates the screen, flashes a couple of times then returns to the window. The bash script is doing it's job, but the exectuble is returning with a: Warning: Audio could not be setup for 22050 Hz 16-bit stereo Reason: There's no reason for running the application. Would you be able to debug this. I'd really like to check this out. I would try it myself, but I am using my phone for daily use now so I want to stay away from it right now. some user reported a similar problem. You need to have the oss-alsa modules loaded. Try with: modprobe snd_pcm_oss modprobe snd_mixer_oss cd /usr/share/linball-openmoko export DISPLAY=:0 /usr/bin/linball Regards, Rafa ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Google Summer of Code
i think there is none shr (or fso?) got rejected On Wed, Mar 25, 2009 at 1:21 AM, The Digital Pioneer digitalpion...@gmail.com wrote: Hey, I'm just wondering if there are any cool FR-related projects in GSoC this year. Anyone know? -- Thanks, The Digital Pioneer ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR] Fennec web browser recipe
This worked on a recently installed and upgraded SHR testing.
opkg install -nodeps
http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/fennec_0.9+1.0a2-r2.1_armv4t.ipk
\
http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/sqlite3_3.6.5-r0.1_armv4t.ipk
\
http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libsqlite3-0_3.6.5-r0.1_armv4t.ipk
\
http://www.angstrom-distribution.org/feeds/2008/ipk/glibc/armv4t/base/libgcc1_4.2.4-r5.1_armv4t.ipk
opkg install libgio-2.0-0 libxt6
echo '
/usr/lib/fennec/xulrunner
/usr/lib/fennec/xulrunner/plugins
/usr/lib/fennec/xulrunner/components' /etc/ld.so.conf
ldconfig
DISPLAY=:0 /usr/lib/fennec/fennec
The UI is designed for a 800*480 screen, not a 480*640. You can unzip
/usr/lib/fennec/{classic,browser}.jar , play around with the css/xml/png
files and zip it again.
I only played with it for a couple of minutes, I doubt it's very useful
as-is but I'm sure some of you are curious as well.
bon apetit,
(ab)
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
shameless plug
http://esc-sv09.techinsightsevents.com/freerunner_giveaway ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Fennec Beta 1 Released
Thanks for the clarification! Rui On Fri, Mar 20, 2009 at 10:56:37AM -0400, Brad Lassey wrote: Yes, I suppose that would be a bit of a misprint, which I have corrected to read If you want to cross-compile Fennec and XULRunner for Maemo, you should first set up scratchbox https://wiki.mozilla.org/Mobile/Build/cs2007q3. The mozilla build process handles gcc style cross compiles out of the box. -Brad On 3/20/2009 10:04 AM, Rui Miguel Silva Seabra wrote: Really? Because it says If you want to cross-compile Fennec and XULRunner for ARM devices, you should first set up scratchbox. r...@om-gta02:~# grep Processor /proc/cpuinfo Processor: ARM920T rev 0 (v4l) Rui On Fri, Mar 20, 2009 at 09:29:11AM -0400, Brad Lassey wrote: Rui, Those instructions are for setting up a Maemo development environment, which wouldn't be applicable to someone trying to build for Openmoko. -Brad On 3/20/2009 4:50 AM, Rui Miguel Silva Seabra wrote: You're oversimplifying a bit. You're forgetting https://wiki.mozilla.org/Mobile/Build/cs2007q3 Rui On Fri, Mar 20, 2009 at 01:05:45AM -0700, blassey wrote: Out of curiosity, what part of the build process is giving you trouble? It boils down to this: -Pull the code hg clone http://hg.mozilla.org/mozilla-central cd mozilla-central hg clone http://hg.mozilla.org/mobile-browser mobile -Create configuration file (an example is provided, just copy and paste) -Build make -f client.mk build Daniel Benoy wrote: Looks like the hell on drugs according to their wiki. https://wiki.mozilla.org/Mobile/Build/Fennec ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- Fnord. Today is Prickle-Prickle, the 11th day of Discord in the YOLD 3175 + No matter how much you do, you never do enough -- unknown + Whatever you do will be insignificant, | but it is very important that you do it -- Gandhi + So let's do it...? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-testing] Problems with battery
On Wed, Mar 25, 2009 at 05:26:40PM +0100, Francesco de Virgilio wrote: Hi list, a small problem: I use my Nokia 6630 compatible battery (BL-5C) in the Neo with SHR-testing, but Neo doesn't recognize the battery chip, so it says that it is empty even it is full. Reporting that the battery is empty is an FSO bug. The 2.6.24 kernels do report battery voltage for all batteries, including alien ones, but that has disappeared in the 2.6.28 series. It's on my TODO list to get it back in. I've edited /etc/freesmartphone/opreferences/rules.yaml and commented the section that powers off the phone with low battery level. Definitely a silly bug - for instance, how are you supposed to be able to charge a depleted battery in the Neo, then? But, it still remains a problem: the battery doesn't charge, why? How do you know it doesn't charge the battery? Which kernel are you using? -- Rask Ingemann Lambertsen Danish law requires addresses in e-mail to be logged and stored for a year ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
