Re: [SHR-testing] Problems with battery

[Rask Ingemann Lambertsen]

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

Re: Fennec Beta 1 Released

[Rui Miguel Silva Seabra]

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  
> ."  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

shameless plug

[Steve Mosher]

http://esc-sv09.techinsightsevents.com/freerunner_giveaway




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

[SHR] Fennec web browser recipe

[Arne Brasseur]

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

Re: Google Summer of Code

[Yorick Moko]

i think there is none
shr (or fso?) got rejected

On Wed, Mar 25, 2009 at 1:21 AM, The Digital Pioneer
 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

Re: Linball game 0.2 version

[Yorick Moko]

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
 wrote:
>
> Hello,
>
> --- On Tue, 3/24/09, Will Siddall  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

Remoko/Bluez 4

[The Digital Pioneer]

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: Is "SIM Toolkit" possible to support on the freerunner?

[Mike Crash]

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

Re: Back to the Basics plan: Andy left

[Steve Mosher]

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: shr- avoid suspend and dim screen

[Fernando Martins]

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: Bluetooth headsets to the rescue

[Steve Mosher]

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: Bluetooth headsets to the rescue

[Steve Mosher]

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: linphone 3.1.0

[Al Johnson]

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: Back to the Basics plan: Andy left

[Steve Mosher]

  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 mai

Re: shr- avoid suspend and dim screen

[ANT]

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: Data call (aka CSD) with QtExtended

[Tuan TRINH]

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  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   
> ]
> sent [LCP ConfAck id=0x0]
> rcvd [LCP ConfReq id=0x1   
> [local:61.72.31.2e.6e.69.6b.2d.61.73.64]> < 17 04 59 3d>]
> sent [LCP ConfRej id=0x1  < 17 04 59 3d>]
> rcvd [LCP ConfAck id=0x1   
> ]
> rcvd [LCP ConfReq id=0x2   
>   ]
> sent [LCP ConfAck id=0x2   
>   ]
> sent [LCP EchoReq id=0x0 magic=0x34d2bbd3]
> sent [PAP AuthReq id=0x1 user="isp_user_n...@your.isp.dom"
> password=]
> rcvd [LCP EchoRep id=0x0 magic=0x148b1bd]
> rcvd [PAP AuthAck id=0x1 ""]
> PAP authentication succeeded
> sent [CCP ConfReq id=0x1  
>  ]
> sent [IPCP ConfReq id=0x10.0.0.0> ]
> rcvd [IPCP ConfReq id=0x1 ]
> sent [IPCP ConfAck id=0x1 ]
> 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 ]
> sent [IPCP ConfReq id=0x20.0.0.0>]
> rcvd [IPCP ConfReq id=0x2 ]
> sent [IPCP ConfAck id=0x2 ]
> rcvd [IPCP ConfNak id=0x2  
> ]
> sent [IPCP ConfReq id=0x3  
> ]
> rcvd [IPCP ConfAck id=0x3  
> ]
> 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

[SHR-testing] Problems with battery

[Francesco de Virgilio]

-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: "Multitouch" on FR ... imho should be possible to mimic

[The Digital Pioneer]

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

Re: [SHR] vim, ntpclient... a repository ?

[Stefan Fröbe]

>
>
> 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

[Risto H. Kurppa]

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: Is "SIM Toolkit" possible to support on the freerunner?

[Michael 'Mickey' Lauer]

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: [SHR] vim, ntpclient... a repository ?

[Helge Hafting]

giacomo "giotti" mariani wrote:
>> Date: Sun, 22 Mar 2009 09:51:56 +0100
>> From: Xavier Cremaschi 
>> Subject: [SHR] vim, ntpclient... a repository ?
>> To: community@lists.openmoko.org
>> Message-ID: 
>> 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: "Multitouch" on FR ... imho should be possible to mimic

[Helge Hafting]

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: Is "SIM Toolkit" possible to support on the freerunner?

[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?

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: Is "SIM Toolkit" possible to support on the freerunner?

[Helge Hafting]

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]

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: qt extended stops receiving sms

[Chris Samuel]

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: Back to the Basics plan: Andy left

[arne anka]

>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: Bluetooth headsets to the rescue

[arne anka]

> 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: Is "SIM Toolkit" possible to support on the freerunner?

[giacomo "giotti" mariani]

> 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: linphone 3.1.0

[Paul Fertser]

Hi,

Al Johnson  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: Openmoko meeting Stuttgart (Wed 25.03.2009)

[vale]

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=13&t=978&start=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: Bluetooth headsets to the rescue

[ezuall]

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: shr- avoid suspend and dim screen

[Christ van Willegen]

On Wed, Mar 25, 2009 at 3:10 AM, W.Kenworthy  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: qt extended stops receiving sms

[Glen Ogilvie]

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: Bluetooth headsets to the rescue

[Christ van Willegen]

Steve, all,

On Wed, Mar 25, 2009 at 7:50 AM, Steve Mosher  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: Back to the Basics plan: Andy left

[Gunnar AAstrand Grimnes]

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