Om2009 testing release 4
mirko at openmoko.com
Mon May 25 12:25:09 CEST 2009
Sorry for the delay in answering, I was at a conference over the weekend.
Ben Wong wrote:
> Thanks for the update. Unfortunately Om2009 is still not a usable
> phone out of the box for me. I realize that this is probably my fault
> for not persevering, but I will be reverting to SHR since this is my
> only phone.
That is sad, that we still didn't reach that, I had high hopes :) But
thatnks for the observations and I hope we can turn OM09 into an
> Here are my issues, in order of importance:
> 1) Horrible audio distortion during calls. People tell me that I
> sound like I'm being played back over a blown-out speaker. I tried
> calling +1800GOOG411 (google's speech recognition phone directory) and
> it was unable to understand me. I bet this is something tweakable
> with the ALSA settings, but I'm surprised that Om2009t4 gets the
> default wrong when SHR-testing works fine. I don't know if it's
> relevant but I have an A6 model of the Freerunner.
I believe Angus is more qualified to say sth about this.
> 2) There should be immediate feedback during all operations.
Agreed. We are currently working on this. Thanks to Laszlo the design
files get more attention now and we are straightening out certain
problems. Having a response on button click is a high priority.
> 2a) When searching for a GSM signal, the Paroli interface is presented
> but frozen and there is no notification which is quite frustrating.
> Even just the simple word "searching..." would have helped.
Will try to create a way to show status messages when the interface is
> 2c) From the contacts menu, when clicking on a phone number, a call is
> made but there is no visual indication of this until the Dialer
> program appears. The number should at least light up when clicked.
I just uploaded changes that enable just that. I hope this is what you
meant. (it also works for items in SMS and Call-Log)
> 2d) There is too much latency between pressing the AUX button during a
> call and any indication that the system is working on changing the
> volume. Ideally, what I'd like the GUI to show me is not what the
> current volume is, but what it will be once it has finished processing
> all the button presses.
This is an issue happening in several places in paroli. The interface is
very honest in the sense that it only shows what actually happened. Of
course this means that changes are visible a bit later than in other
interfaces. Should this paradigm be changed?
> 2e) When ending a call, pressing END CALL does light up the button,
> but then it unlights before the call is actually ended making one
> think it needs to be pressed again. I suggest changing the text to
> "ENDING" after the button has been pressed.
The relates to the last point. Paroli could remove the call window as
soon as the user ends the call and it could also stop all sounds and
just don't worry whether or not the call is actually ended.
I agree sth has to change here, which way is better
a) showing that the call is ending and keeping the call window until the
call is actually ended
b) closing the window right away and letting the user move on before the
call is actually finsished
Is there a c) ?
> 3) There is no way to reset Paroli if it gets wedged. At one point,
> it refused to allow me to make a call because it thought there was
> already one in progress. Not only was there not one, but the Dialer
> program didn't have the red END CALL button so I had no recourse but
> to reboot.
That one goes on my black-list. I brought some odd behavior back into
paroli over the last few weeks. I will focus on getting rid of those again.
> I should mention that there are many things that I rather like about
> Om2009t4. I hope you find my comments constructive. I look forward
> to trying the next release of Om2009.
Thanks a lot, these helped. I hope we can continue on these discussions
and get it right or at least "righter" for the next release :)
Until then enjoy SHR, these guys are doing a good job!
More information about the community