Re: Om2009 testing release 4
On Sun, Jun 7, 2009 at 5:02 AM, Warren Baird wrote: > Hmm. In this thread: > http://n2.nabble.com/Buzz-fix-difficulty--was-Re%3A-US-Buzz-GPS-Fix--tp2679871p2733711.html > Joerg states that the -a7 version is the only 'real' state file. > > I also tried > http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset.state.new > and found I got a lot more static that with the -a7 file... > > *shrug* and here Joerg states being wrong: http://docs.openmoko.org/trac/ticket/2121#comment:3 (and AFAIK they're now working on removing the -a7 since - it's wrong :) 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: Om2009 testing release 4
Hmm. In this thread: http://n2.nabble.com/Buzz-fix-difficulty--was-Re%3A-US-Buzz-GPS-Fix--tp2679871p2733711.html Joerg states that the -a7 version is the only 'real' state file. I also tried http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset.state.newand found I got a lot more static that with the -a7 file... *shrug* Warren On Sat, Jun 6, 2009 at 4:30 PM, Sebastian Krzyszkowiak wrote: > On Thu, Jun 4, 2009 at 23:31, Warren Baird > wrote: > > I've had better luck starting with > > http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset-a7.state- > > it's one of several that I've seen identified as 'the one true > statefile'... > > > > If you still get buzz, then try dropping 'control.5' (Mono Playback > Volume) > > - to around 85 or 90. That might help - although you might find that > > people have trouble hearing you. > > > > I'm currently using the gsmhandset-a7.state unmodified and seem to get ok > > results. I've had one report of intermittent buzz during a call, but it > > wasn't super bad. > > > > Warren > > > The only one true statefile (TM) is > http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset.state.new > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Thu, Jun 4, 2009 at 23:31, Warren Baird wrote: > I've had better luck starting with > http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset-a7.state - > it's one of several that I've seen identified as 'the one true statefile'... > > If you still get buzz, then try dropping 'control.5' (Mono Playback Volume) > - to around 85 or 90. That might help - although you might find that > people have trouble hearing you. > > I'm currently using the gsmhandset-a7.state unmodified and seem to get ok > results. I've had one report of intermittent buzz during a call, but it > wasn't super bad. > > Warren The only one true statefile (TM) is http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset.state.new ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On June 5, 2009 02:31:16 am Patryk Benderz wrote: > Looks like these: > http://downloads.openmoko.org/distro/testing/NeoFreerunner/ > are the same images i downloaded last time, May 21st. > Am i looking for them at right place? > The testing images haven't changed but the unstable ones have had quite a bit of work done. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Do remember that each FR is a bit unique in the audio side -> it's possible that the best alsastate for YOUR fr isn't around and you have to make some adjustments yourself.. I think that every FR is possible to make sound good after the buzz fix but it might involve some playing with alsamixer. 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: Om2009 testing release 4
thanks, I'll try it tomorrow On Thu, Jun 4, 2009 at 11:31 PM, Warren Baird wrote: > I've had better luck starting with > http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset-a7.state - > it's one of several that I've seen identified as 'the one true statefile'... > > If you still get buzz, then try dropping 'control.5' (Mono Playback Volume) > - to around 85 or 90. That might help - although you might find that > people have trouble hearing you. > > I'm currently using the gsmhandset-a7.state unmodified and seem to get ok > results. I've had one report of intermittent buzz during a call, but it > wasn't super bad. > > Warren > > > > On Thu, Jun 4, 2009 at 5:22 PM, Rui Miguel Silva Seabra wrote: > >> On Thu, Jun 04, 2009 at 11:00:29PM +0200, tammaro pamdirac palombo wrote: >> > I try to use Om2009 but for me is unusable (call audio quality). I like >> > paroli but I must use FR like a phone. >> > I hope that the buzz fix solves this problem. >> >> While you don't get it, this alsa state file improves things a bit WRT the >> recent builds: >> >> http://www.kurppa.fi/freerunner/config_files/gsmhandset.state >> >> Just replace the one in /usr/share/openmoko/scenarios/ >> >> Rui >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > > > -- > Warren Baird - Photographer and Digital Artist > http://www.synergisticimages.ca > > ___ > 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: Om2009 testing release 4
I've had better luck starting with http://docs.openmoko.org/trac/attachment/ticket/2121/gsmhandset-a7.state - it's one of several that I've seen identified as 'the one true statefile'... If you still get buzz, then try dropping 'control.5' (Mono Playback Volume) - to around 85 or 90. That might help - although you might find that people have trouble hearing you. I'm currently using the gsmhandset-a7.state unmodified and seem to get ok results. I've had one report of intermittent buzz during a call, but it wasn't super bad. Warren On Thu, Jun 4, 2009 at 5:22 PM, Rui Miguel Silva Seabra wrote: > On Thu, Jun 04, 2009 at 11:00:29PM +0200, tammaro pamdirac palombo wrote: > > I try to use Om2009 but for me is unusable (call audio quality). I like > > paroli but I must use FR like a phone. > > I hope that the buzz fix solves this problem. > > While you don't get it, this alsa state file improves things a bit WRT the > recent builds: > > http://www.kurppa.fi/freerunner/config_files/gsmhandset.state > > Just replace the one in /usr/share/openmoko/scenarios/ > > Rui > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Thu, Jun 04, 2009 at 11:00:29PM +0200, tammaro pamdirac palombo wrote: > I try to use Om2009 but for me is unusable (call audio quality). I like > paroli but I must use FR like a phone. > I hope that the buzz fix solves this problem. While you don't get it, this alsa state file improves things a bit WRT the recent builds: http://www.kurppa.fi/freerunner/config_files/gsmhandset.state Just replace the one in /usr/share/openmoko/scenarios/ Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
I try to use Om2009 but for me is unusable (call audio quality). I like paroli but I must use FR like a phone. I hope that the buzz fix solves this problem. bye ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, 1 Jun 2009 11:12:41 +0100 Rui Miguel Silva Seabra said: > > My experience is that most applications become almost unusable because > > things are simply compressed beyond what is usable, so they need to do > > something themselves. > > > > Merely having the interface scaled down doesn't seem to work well enough > > (to me). > > Example: > > http://files.1407.org/2009/06/01/paroli_is_borked_on_landscape.jpg actually - that's more because paroly was designed for 480x640 only and has no concept of adjusting to another size that is not that :) ask mirko. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Hi Rask, I'm afraid I have no idea which X server and touch screen driver were in use. I was using OM2009 TR3 and hadn't modified the X server at all, if that helps. The behaviour was that sometime when I rotated the device with omrotatenew the touch pad response would be about 1.5cm to the left of where I pressed. Usually when that happened I could just rotate it to another position and back again, and it was usually fine. Warren On Sun, May 31, 2009 at 12:46 PM, Rask Ingemann Lambertsen wrote: > On Mon, May 25, 2009 at 05:20:08PM +0100, Rui Miguel Silva Seabra wrote: > > On Mon, May 25, 2009 at 12:08:33PM -0400, Warren Baird wrote: > > > I had another > > > experience with epdfview where when I held the FR horizontally I had to > > > click about 1.5 cm to the right of the 'next page' button to get it to > > > actually go to the next page. After holding it vertically and then > > > horizontally again, it was fine. > > > As for your problem with landscape vs portrait positions and GUIs... > well, that's > > a problem that's not easy to solve unless all applications pay attention > to > > a specific dbus signal which omnewrotate will send in the future. > >No problem as long as the X server and touch screen driver is working. > Which X server did it happen with (kdriver Xglamo, Xorg fbdev or Xorg > glamo)? > > -- > 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 > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, Jun 01, 2009 at 10:59:00AM +0100, Rui Miguel Silva Seabra wrote: > On Mon, Jun 01, 2009 at 07:24:22PM +1000, Carsten Haitzler wrote: > > On Mon, 1 Jun 2009 09:10:41 +0100 Rui Miguel Silva Seabra > > said: > > > On Mon, Jun 01, 2009 at 05:21:15PM +1000, Carsten Haitzler wrote: > > > > On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra > > > > > > > > said: > > > > > > > > > I'm sure it's not, AFAICT (since I don't know Parloi's internals) it > > > > > doesn't touch anything Paroli or anything related to calls. > > > > > > > > > > As for your problem with landscape vs portrait positions and GUIs... > > > > > well, > > > > > that's a problem that's not easy to solve unless all applications pay > > > > > attention to a specific dbus signal which omnewrotate will send in the > > > > > future. > > > > > > > > > > This signal can be used by apps so they adjust their UI according to > > > > > the > > > > > display mode, but other than that, they all think they're in the same > > > > > position. > > > > > > > > no dbus signals needed. when x rotates,you'll get a configurenotify on > > > > root > > > > AND an XRRScreenChangeNotifyEvent event (on root). These will also tell > > > > you > > > > your orientation and new size. The WM, if smart, will resize your app > > > > window anyway, so all you really need to do is, on resize, query x for > > > > the > > > > orientation, if orientation matters. if it doesn't just adjusting to the > > > > new size is what you should be doing anyway. > > > > > > Ah... so applicaitons like, say, paroli, mokomaze, etc... need to pay > > > attention to XRRScreenChangeNotifyEvent ? > > > > well they dont HAVE to - they simply should adjust to a new size (640x480 as > > opposed to 480x640). that is already done for them (if under a window > > manager > > that is sensible). they will get resized. > > My experience is that most applications become almost unusable because things > are > simply compressed beyond what is usable, so they need to do something > themselves. > > Merely having the interface scaled down doesn't seem to work well enough (to > me). Example: http://files.1407.org/2009/06/01/paroli_is_borked_on_landscape.jpg Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, Jun 01, 2009 at 07:24:22PM +1000, Carsten Haitzler wrote: > On Mon, 1 Jun 2009 09:10:41 +0100 Rui Miguel Silva Seabra > said: > > On Mon, Jun 01, 2009 at 05:21:15PM +1000, Carsten Haitzler wrote: > > > On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra > > > said: > > > > > > > I'm sure it's not, AFAICT (since I don't know Parloi's internals) it > > > > doesn't touch anything Paroli or anything related to calls. > > > > > > > > As for your problem with landscape vs portrait positions and GUIs... > > > > well, > > > > that's a problem that's not easy to solve unless all applications pay > > > > attention to a specific dbus signal which omnewrotate will send in the > > > > future. > > > > > > > > This signal can be used by apps so they adjust their UI according to the > > > > display mode, but other than that, they all think they're in the same > > > > position. > > > > > > no dbus signals needed. when x rotates,you'll get a configurenotify on > > > root > > > AND an XRRScreenChangeNotifyEvent event (on root). These will also tell > > > you > > > your orientation and new size. The WM, if smart, will resize your app > > > window anyway, so all you really need to do is, on resize, query x for the > > > orientation, if orientation matters. if it doesn't just adjusting to the > > > new size is what you should be doing anyway. > > > > Ah... so applicaitons like, say, paroli, mokomaze, etc... need to pay > > attention to XRRScreenChangeNotifyEvent ? > > well they dont HAVE to - they simply should adjust to a new size (640x480 as > opposed to 480x640). that is already done for them (if under a window manager > that is sensible). they will get resized. My experience is that most applications become almost unusable because things are simply compressed beyond what is usable, so they need to do something themselves. Merely having the interface scaled down doesn't seem to work well enough (to me). Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, 1 Jun 2009 09:10:41 +0100 Rui Miguel Silva Seabra said: > On Mon, Jun 01, 2009 at 05:21:15PM +1000, Carsten Haitzler wrote: > > On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra > > said: > > > > > I'm sure it's not, AFAICT (since I don't know Parloi's internals) it > > > doesn't touch anything Paroli or anything related to calls. > > > > > > As for your problem with landscape vs portrait positions and GUIs... well, > > > that's a problem that's not easy to solve unless all applications pay > > > attention to a specific dbus signal which omnewrotate will send in the > > > future. > > > > > > This signal can be used by apps so they adjust their UI according to the > > > display mode, but other than that, they all think they're in the same > > > position. > > > > no dbus signals needed. when x rotates,you'll get a configurenotify on root > > AND an XRRScreenChangeNotifyEvent event (on root). These will also tell you > > your orientation and new size. The WM, if smart, will resize your app > > window anyway, so all you really need to do is, on resize, query x for the > > orientation, if orientation matters. if it doesn't just adjusting to the > > new size is what you should be doing anyway. > > Ah... so applicaitons like, say, paroli, mokomaze, etc... need to pay > attention to XRRScreenChangeNotifyEvent ? well they dont HAVE to - they simply should adjust to a new size (640x480 as opposed to 480x640). that is already done for them (if under a window manager that is sensible). they will get resized. if you want to do something SPECIAL when in a particular rotation other than just adjust to the new size (i generally would advise this as a bad idea - in he case of the freerunner, i see no good reason to do anything special as there are no particular markings/buttons around the screen you may want to specially have your ui adjust to their new location relative to the pixels on the screen). as paroli is in python - there isn't much it can do. the python bindings, as best i know, don't export the Ecore_X_Event_Screen_Change, Ecore_X_Event_Randr_Crtc_Change, Ecore_X_Event_Randr_Output_Change and Ecore_X_Event_Randr_Output_Property_Notify events (these are more than you need though - you only need the first, the other 3 are for xrandr1.3+ where you can get events based on new outputs being added/removed (eg plug in an external monitor to a laptop). also other function calls to query: ecore_x_randr_screen_rotations_get(), ecore_x_randr_screen_rotation_get() etc. etc. so again - the only reasons i could think of for ACTUALLY wanting to know rotation (other than adjust to screen size change) are: 1. external input like camera image needs rotating (as the camera just rotated and the screen pixels did so you need to rotate the camera image back, but no camera on freerunner) 2. you have some special markers/buttons around the screen that you have buttons/indicators referring to these. (not on freerunner) other than that window resize events are all you need (and if you need a new custom layout - then choose it based on window size, not on rotation, as now you also work in devices with landscape displays - eg n800). -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, Jun 01, 2009 at 05:21:15PM +1000, Carsten Haitzler wrote: > On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra > said: > > > I'm sure it's not, AFAICT (since I don't know Parloi's internals) it doesn't > > touch anything Paroli or anything related to calls. > > > > As for your problem with landscape vs portrait positions and GUIs... well, > > that's a problem that's not easy to solve unless all applications pay > > attention to a specific dbus signal which omnewrotate will send in the > > future. > > > > This signal can be used by apps so they adjust their UI according to the > > display mode, but other than that, they all think they're in the same > > position. > > no dbus signals needed. when x rotates,you'll get a configurenotify on root > AND > an XRRScreenChangeNotifyEvent event (on root). These will also tell you your > orientation and new size. The WM, if smart, will resize your app window > anyway, > so all you really need to do is, on resize, query x for the orientation, if > orientation matters. if it doesn't just adjusting to the new size is what you > should be doing anyway. Ah... so applicaitons like, say, paroli, mokomaze, etc... need to pay attention to XRRScreenChangeNotifyEvent ? Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, 25 May 2009 17:20:08 +0100 Rui Miguel Silva Seabra said: > I'm sure it's not, AFAICT (since I don't know Parloi's internals) it doesn't > touch anything Paroli or anything related to calls. > > As for your problem with landscape vs portrait positions and GUIs... well, > that's a problem that's not easy to solve unless all applications pay > attention to a specific dbus signal which omnewrotate will send in the future. > > This signal can be used by apps so they adjust their UI according to the > display mode, but other than that, they all think they're in the same > position. no dbus signals needed. when x rotates,you'll get a configurenotify on root AND an XRRScreenChangeNotifyEvent event (on root). These will also tell you your orientation and new size. The WM, if smart, will resize your app window anyway, so all you really need to do is, on resize, query x for the orientation, if orientation matters. if it doesn't just adjusting to the new size is what you should be doing anyway. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, May 25, 2009 at 05:20:08PM +0100, Rui Miguel Silva Seabra wrote: > On Mon, May 25, 2009 at 12:08:33PM -0400, Warren Baird wrote: > > I had another > > experience with epdfview where when I held the FR horizontally I had to > > click about 1.5 cm to the right of the 'next page' button to get it to > > actually go to the next page. After holding it vertically and then > > horizontally again, it was fine. > As for your problem with landscape vs portrait positions and GUIs... well, > that's > a problem that's not easy to solve unless all applications pay attention to > a specific dbus signal which omnewrotate will send in the future. No problem as long as the X server and touch screen driver is working. Which X server did it happen with (kdriver Xglamo, Xorg fbdev or Xorg glamo)? -- 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: Om2009 testing release 4
2009/5/30 Ben Wong : > B also sounds like it'd be tricky to do correctly. What happens if > the user immediately tries to make another call (or use GPRS or SMS) > and the previous call hasn't yet finished? as it's unavoidable at this point to interfere with the user's time, a "please wait" message would be preferable to nothing happening. in the case of the user not making another call immediately, there's nothing lost in 'pretending' to finish the call whilst the hardware is still busy. here, however, it could cause a problem, so make them wait, but tell them what's happening ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, May 25, 2009 at 3:25 AM, Mirko Lindner wrote: > > Ben Wong wrote: >> >> 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? Yes, I believe so. As others have said, "honesty" includes not only the past but what is planned for the future. I think changing the gauge immediately (40%, 60%, 80%) but having it be grayed-out would be a good way to represent that the volume change is queued up for later action. >> 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 > > or > > b) closing the window right away and letting the user move on before the > call is actually finished Plan A would be acceptable, but B would be better. The user interface should waste as little of the user's time as possible. However, plan B also sounds like it'd be tricky to do correctly. What happens if the user immediately tries to make another call (or use GPRS or SMS) and the previous call hasn't yet finished? Thanks for your detailed response, Mirko. I look forward to testing your next release. --Ben ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Hi >> In addition to this, in some situations one could add to 0.5s: 'user >> presses AUX again since there was no response when he first pressed >> it' happens to me all the time :-) >>> 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? >>> >> After I read this about 2 days ago, I've been thinking about it and >> the conclusion is that yes, I think it should be changed. reading it very literally, I don't. I think paroli should "honestly" show what is happening, not what is supposed to happen; but that includes "receiving a ui event" or "starting a process". >> But as soon as Paroli & everything behind it are >> stable enough that we can trust that clicking a button does what we >> want it to do, I think the UI should make the change as soon as >> possible and do the actual work ASAP after this. No machine will ever be that stable - not if you spill a beer over it, drop it from the stairs or accidentally zap half the filesystem. Even then, I'd like to be able to trust the ui to tell me whats really going on, not what it thinks should be going on. >> Concerning this, I'd like to see a 'busy' light/icon/something to >> point out that work is being done, wait until it's finished before you >> try anything else. The icon would be shown when the processor load is >> 90% or more. Good idea; sounds like macs 'colored ball cursor'. But it doesn't replace the "watch cursor" - saying "we received your request, now please wait". Paroli doesnt have a cursor, but it could have an applet that applications can call, I guess ? Something like a watch ? start-watch; do stuff; stop-watch. The 'watch' (I imagine a rotating circle aka adobe flash loader) could turn into a "busyball" when the cpu reaches 90%, too. And it could also indicate a failure. I also like the idea of a buzz when an error occures. The buzz feels very erroneous. These things would only apply to paroli, though. I think lower levels could give some more feedback, too. Eg, the aux and power buttons send a dbus signal every second they are pressed, but that's counterintuitive to me - if it would flash or buzz every second too, i might be inclined to wait - and count. And even lower, when booting the phone, and during the boot process, there's not enough feedback for me. I never feel I can "trust" the thing. But maybe that's me :-) $2c, *-pike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Risto H. Kurppa schrieb: > On Mon, May 25, 2009 at 1:25 PM, Mirko Lindner wrote: > >>> 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? >> > > After I read this about 2 days ago, I've been thinking about it and > the conclusion is that yes, I think it should be changed. > > I appreciate it that the UI shows me what's happening, as you said > 'being honest'. But as soon as Paroli & everything behind it are > stable enough that we can trust that clicking a button does what we > want it to do, I think the UI should make the change as soon as > possible and do the actual work ASAP after this. This applies to > pressing AUX to change the profile, starting/disconnecting a call etc > etc: > > Here's a usercase where the different approaches have been compared > (action first, then UI vs. UI first then action) > 0s. user presses the AUX button to change the profile from 'silent' to > 'default' > 0.5s. Paroli works on the the change, no UI reaction vs. Text changed > from 'silent' to 'default' > 1s. Text changes from 'silent' to 'default' vs. Paroli works on the > profile change & the user puts the phone in the pocket > 1.5s user puts the phone in the pocket vs. user takes another sip of > his Dr. Pepper > > In addition to this, in some situations one could add to 0.5s: 'user > presses AUX again since there was no response when he first pressed > it' > > -> I think that immediate UI reaction gives the user the experience of > responsiviness and that the phone works faster. The same goes with > start/disconnect a call, loading Paroli & contacts&SMS from SIM etc. > Since the user is often slow, we should allow him to start thinking of > his next move as soon as possible and during that time do other stuff. > > Concerning this, I'd like to see a 'busy' light/icon/something to > point out that work is being done, wait until it's finished before you > try anything else. The icon would be shown when the processor load is > 90% or more. This would again give the user a better experience of > 'we're doing stuff for you' instead of 'hmm.. I wonder if this crashed > since it doesn't react to my actions...' > > or just change the text in the UI before start working and produce a little vibration & led-sign on failure and switch back to the former state. if everything worked well, there's no problem, if not, the user recognizes it immediately. (if the vibration is secure and reliable enough to do this job). but presenting an "loading" screen or light would be much closer to what really happens. i just really like the neo to vibrate, mayba that's all about my idea ;-) matthias ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, May 25, 2009 at 1:25 PM, Mirko Lindner wrote: >> 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? After I read this about 2 days ago, I've been thinking about it and the conclusion is that yes, I think it should be changed. I appreciate it that the UI shows me what's happening, as you said 'being honest'. But as soon as Paroli & everything behind it are stable enough that we can trust that clicking a button does what we want it to do, I think the UI should make the change as soon as possible and do the actual work ASAP after this. This applies to pressing AUX to change the profile, starting/disconnecting a call etc etc: Here's a usercase where the different approaches have been compared (action first, then UI vs. UI first then action) 0s. user presses the AUX button to change the profile from 'silent' to 'default' 0.5s. Paroli works on the the change, no UI reaction vs. Text changed from 'silent' to 'default' 1s. Text changes from 'silent' to 'default' vs. Paroli works on the profile change & the user puts the phone in the pocket 1.5s user puts the phone in the pocket vs. user takes another sip of his Dr. Pepper In addition to this, in some situations one could add to 0.5s: 'user presses AUX again since there was no response when he first pressed it' -> I think that immediate UI reaction gives the user the experience of responsiviness and that the phone works faster. The same goes with start/disconnect a call, loading Paroli & contacts&SMS from SIM etc. Since the user is often slow, we should allow him to start thinking of his next move as soon as possible and during that time do other stuff. Concerning this, I'd like to see a 'busy' light/icon/something to point out that work is being done, wait until it's finished before you try anything else. The icon would be shown when the processor load is 90% or more. This would again give the user a better experience of 'we're doing stuff for you' instead of 'hmm.. I wonder if this crashed since it doesn't react to my actions...' 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: Om2009 testing release 4
sweet - I'll check that out... I must admit that with the illume top bar, and the epdfview menu and toolbar, there wasn't much real-estate left... Thanks for the tip. Warren On Tue, May 26, 2009 at 2:44 PM, roby wrote: > On Mon, May 25, 2009 at 6:08 PM, Warren Baird > wrote: > >> to miss the call. I had another experience with epdfview where when I >> held the FR horizontally I had to click about 1.5 cm to the right of the >> 'next page' button to get it to actually go to the next page. After holding >> it vertically and then horizontally again, it was fine. > > > Regarding epdfview you should find a package on www.opkg.org with the > finger-scroll feature added. With that feature you can even hide the toolbar > and just use the finger to navigate. You will still need a way to exit the > full-screen view though. > > -- > roby > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, May 25, 2009 at 6:08 PM, Warren Baird wrote: > to miss the call. I had another experience with epdfview where when I > held the FR horizontally I had to click about 1.5 cm to the right of the > 'next page' button to get it to actually go to the next page. After holding > it vertically and then horizontally again, it was fine. Regarding epdfview you should find a package on www.opkg.org with the finger-scroll feature added. With that feature you can even hide the toolbar and just use the finger to navigate. You will still need a way to exit the full-screen view though. -- roby ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
I'm sure it's not, AFAICT (since I don't know Parloi's internals) it doesn't touch anything Paroli or anything related to calls. As for your problem with landscape vs portrait positions and GUIs... well, that's a problem that's not easy to solve unless all applications pay attention to a specific dbus signal which omnewrotate will send in the future. This signal can be used by apps so they adjust their UI according to the display mode, but other than that, they all think they're in the same position. Rui On Mon, May 25, 2009 at 12:08:33PM -0400, Warren Baird wrote: > Rui - I'm not sure if omnewrotate was causing the general unstability - but > I do think it was probably what caused me to miss the call. I had another > experience with epdfview where when I held the FR horizontally I had to > click about 1.5 cm to the right of the 'next page' button to get it to > actually go to the next page. After holding it vertically and then > horizontally again, it was fine. > > I think I might try TR4 again with a manual screen rotater and see if I have > better luck. > > Warren > > > On Sun, May 24, 2009 at 5:19 PM, Rui Miguel Silva Seabra wrote: > > > On Sun, May 24, 2009 at 05:14:01PM -0400, Warren Baird wrote: > > > I'm afraid my experience with TR4 wasn't that great. I installed it > > Friday > > > night, and played with it enough to make sure that I could make and > > receive > > > calls. I must admit that after using QtE it was nice to be able to > > install > > > software like a pdf reader and mokomaze. > > > > > > However, The first real call I got was from my wife heading over to the > > park > > > with our daughter. I heard the ringing, and the phone seemed to wake up > > > from suspend quickly (which puts it ahead of my experience from OM2008), > > but > > > when I pressed the answer button nothing happened. I had been running > > > omrotatenew, and I've noticed that it sometimes screws up the touch > > screen > > > calibration, so I don't know if this is actually a TR4 problem, or an > > issue > > > with the rotation. > > > > > > However, once I missed the call, I figured I'd use the call log to call > > her > > > back, so I went to the call log and clicked on the entry. It took me to > > an > > > empty dialer window - without a number entered. Since I know her > > number > > > I just typed it in, and clicked on the 'call' button. Nothing happened. > > > I clicked on the 'back button' - also nothing. I used the illume menu > > to > > > take me to the main paroli windows, but couldn't make anything work there > > > either. I ended up rebooting. > > > > > > After the reboot, I still couldn't get dialing to work, so I rebooted > > again, > > > and then was able to call my wife --- total time elapsed to make the call > > > was probably 20 minutes. When I did get ahold of her, she said that she > > > could barely understand me, since the audio was quite distorted - she > > > sounded fine to me, and probably a bit louder than I get with QtE. > > > > > > I might give TR4 another try without omreotatenew running and see if it's > > > any more reliable that way... > > > > Pretty sure omnewrotate ain't the problem, I've run into that before > > installing > > it. > > > > Right now I suspend manually in order to check it's working, but it seems > > to be triggered by missed calls. > > > > Rui > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > > > > -- > Warren Baird - Photographer and Digital Artist > http://www.synergisticimages.ca > ___ > 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: Om2009 testing release 4
Rui - I'm not sure if omnewrotate was causing the general unstability - but I do think it was probably what caused me to miss the call. I had another experience with epdfview where when I held the FR horizontally I had to click about 1.5 cm to the right of the 'next page' button to get it to actually go to the next page. After holding it vertically and then horizontally again, it was fine. I think I might try TR4 again with a manual screen rotater and see if I have better luck. Warren On Sun, May 24, 2009 at 5:19 PM, Rui Miguel Silva Seabra wrote: > On Sun, May 24, 2009 at 05:14:01PM -0400, Warren Baird wrote: > > I'm afraid my experience with TR4 wasn't that great. I installed it > Friday > > night, and played with it enough to make sure that I could make and > receive > > calls. I must admit that after using QtE it was nice to be able to > install > > software like a pdf reader and mokomaze. > > > > However, The first real call I got was from my wife heading over to the > park > > with our daughter. I heard the ringing, and the phone seemed to wake up > > from suspend quickly (which puts it ahead of my experience from OM2008), > but > > when I pressed the answer button nothing happened. I had been running > > omrotatenew, and I've noticed that it sometimes screws up the touch > screen > > calibration, so I don't know if this is actually a TR4 problem, or an > issue > > with the rotation. > > > > However, once I missed the call, I figured I'd use the call log to call > her > > back, so I went to the call log and clicked on the entry. It took me to > an > > empty dialer window - without a number entered. Since I know her > number > > I just typed it in, and clicked on the 'call' button. Nothing happened. > > I clicked on the 'back button' - also nothing. I used the illume menu > to > > take me to the main paroli windows, but couldn't make anything work there > > either. I ended up rebooting. > > > > After the reboot, I still couldn't get dialing to work, so I rebooted > again, > > and then was able to call my wife --- total time elapsed to make the call > > was probably 20 minutes. When I did get ahold of her, she said that she > > could barely understand me, since the audio was quite distorted - she > > sounded fine to me, and probably a bit louder than I get with QtE. > > > > I might give TR4 another try without omreotatenew running and see if it's > > any more reliable that way... > > Pretty sure omnewrotate ain't the problem, I've run into that before > installing > it. > > Right now I suspend manually in order to check it's working, but it seems > to be triggered by missed calls. > > Rui > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, May 25, 2009 at 12:25:09PM +0200, Mirko Lindner wrote: > > 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. Mirko, It seems to be related to missed calls. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Risto H. Kurppa schrieb: > On Mon, May 25, 2009 at 2:51 PM, Marc Bantle wrote: > >> How about new GTA01 images? A new >> kernel has been supplied, I see. >> > > You can start with > http://downloads.openmoko.org/distro/unstable/Neo1973/ and > http://downloads.openmoko.org/distro/unstable/daily/om-gta01/ :) > > Thanks for the pointer! I haven't given unstable a try - sofar :-) Cheers, Marc ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Mon, May 25, 2009 at 2:51 PM, Marc Bantle wrote: > How about new GTA01 images? A new > kernel has been supplied, I see. You can start with http://downloads.openmoko.org/distro/unstable/Neo1973/ and http://downloads.openmoko.org/distro/unstable/daily/om-gta01/ :) 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: Om2009 testing release 4
Angus Ainslie schrieb: > Hi All, > > As I think we've fixed more things than we broke it's time for another > testing > release. As usual there are additional instructions here. > > http://wiki.openmoko.org/wiki/Om2009 > How about new GTA01 images? A new kernel has been supplied, I see. Cheers, Marc ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Hi, 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 "out-of-the-box" solution. > > 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 not responsive. > 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 or 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! Thanks again, /mirko ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Sun, May 24, 2009 at 05:14:01PM -0400, Warren Baird wrote: > I'm afraid my experience with TR4 wasn't that great. I installed it Friday > night, and played with it enough to make sure that I could make and receive > calls. I must admit that after using QtE it was nice to be able to install > software like a pdf reader and mokomaze. > > However, The first real call I got was from my wife heading over to the park > with our daughter. I heard the ringing, and the phone seemed to wake up > from suspend quickly (which puts it ahead of my experience from OM2008), but > when I pressed the answer button nothing happened. I had been running > omrotatenew, and I've noticed that it sometimes screws up the touch screen > calibration, so I don't know if this is actually a TR4 problem, or an issue > with the rotation. > > However, once I missed the call, I figured I'd use the call log to call her > back, so I went to the call log and clicked on the entry. It took me to an > empty dialer window - without a number entered. Since I know her number > I just typed it in, and clicked on the 'call' button. Nothing happened. > I clicked on the 'back button' - also nothing. I used the illume menu to > take me to the main paroli windows, but couldn't make anything work there > either. I ended up rebooting. > > After the reboot, I still couldn't get dialing to work, so I rebooted again, > and then was able to call my wife --- total time elapsed to make the call > was probably 20 minutes. When I did get ahold of her, she said that she > could barely understand me, since the audio was quite distorted - she > sounded fine to me, and probably a bit louder than I get with QtE. > > I might give TR4 another try without omreotatenew running and see if it's > any more reliable that way... Pretty sure omnewrotate ain't the problem, I've run into that before installing it. Right now I suspend manually in order to check it's working, but it seems to be triggered by missed calls. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
I'm afraid my experience with TR4 wasn't that great. I installed it Friday night, and played with it enough to make sure that I could make and receive calls. I must admit that after using QtE it was nice to be able to install software like a pdf reader and mokomaze. However, The first real call I got was from my wife heading over to the park with our daughter. I heard the ringing, and the phone seemed to wake up from suspend quickly (which puts it ahead of my experience from OM2008), but when I pressed the answer button nothing happened. I had been running omrotatenew, and I've noticed that it sometimes screws up the touch screen calibration, so I don't know if this is actually a TR4 problem, or an issue with the rotation. However, once I missed the call, I figured I'd use the call log to call her back, so I went to the call log and clicked on the entry. It took me to an empty dialer window - without a number entered. Since I know her number I just typed it in, and clicked on the 'call' button. Nothing happened. I clicked on the 'back button' - also nothing. I used the illume menu to take me to the main paroli windows, but couldn't make anything work there either. I ended up rebooting. After the reboot, I still couldn't get dialing to work, so I rebooted again, and then was able to call my wife --- total time elapsed to make the call was probably 20 minutes. When I did get ahold of her, she said that she could barely understand me, since the audio was quite distorted - she sounded fine to me, and probably a bit louder than I get with QtE. I might give TR4 another try without omreotatenew running and see if it's any more reliable that way... Warren On Sun, May 24, 2009 at 5:46 AM, Hans Zimmerman wrote: > Hans Zimmerman wrote: > > 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. > >> > >> 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. > >> > > > > 1) I'm experiencing the same (according to the people I call). I however > > did not experience this with the previous images (I'll try to flash > > testing 3 back to see if the problem remains or is gone). > > > > I went back to the gsmhandset.state which worked for me (so reverted to > what was changed in http://docs.openmoko.org/trac/changeset/4968). The > contacts I called so far said they could understand me way better, I was > no longer "breaking up". > > > Hans > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Hans Zimmerman wrote: > 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. >> >> 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. >> > > 1) I'm experiencing the same (according to the people I call). I however > did not experience this with the previous images (I'll try to flash > testing 3 back to see if the problem remains or is gone). > I went back to the gsmhandset.state which worked for me (so reverted to what was changed in http://docs.openmoko.org/trac/changeset/4968). The contacts I called so far said they could understand me way better, I was no longer "breaking up". Hans ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
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. > > 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. > 1) I'm experiencing the same (according to the people I call). I however did not experience this with the previous images (I'll try to flash testing 3 back to see if the problem remains or is gone). 2) Additionally, my contacts list is empty (which neither was a problem in testing 3). http://www.paroli-project.org/trac/ticket/166 3) I do however seem to experience some other problem. I have a ext3 on my SD (/dev/mmcblk0p2 and mount it with bind-home), I also always link /var/log to the SD. Initially everything is ok but after a while I get read error: Input/output error I.e.: r...@om-gta02:/media/card/var/log# tail frameworkd.log tail: read error: Input/output error r...@om-gta02:~# tail paroli.log.20090509 tail: read error: Input/output error Any pointers for this last one? Hans ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Fri, May 22, 2009 at 05:38:35PM -0700, Ben Wong wrote: > Thanks for the update. Unfortunately Om2009 is still not a usable > 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. This happened to me a lot yesterday, but ending paroli and restarting was an inconvenient workaround (way faster than reboot, though). Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
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. 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. 2) There should be immediate feedback during all operations. 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. 2b) The suspend button should blink the LED immediately when waking up or suspending. Two seconds is too long to wait for feedback that a button has been pressed. 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. 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. 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. 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. 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. --Ben Wong Seattle, WA FreeRunner A6, T-mobile P.S. A quick message on interface design from Douglas Adams: "It's the wild colour scheme that freaks me," said Zaphod whose love affair with this ship had lasted almost three minutes into the flight, "Every time you try to operate one of these weird black controls that are labelled in black on a black background, a little black light lights up black to let you know you've done it. What is this? Some kind of galactic hyperhearse?" The walls of the swaying cabin were also black, the ceiling was black, the seats -- which were rudimentary since the only important trip this ship was designed for was supposed to be unmanned -- were black, the control panel was black, the instruments were black, the little screws that held them in place were black, the thin tufted nylon floor covering was black, and when they had lifted up a corner of it they had discovered that the foam underlay also was black. "Perhaps whoever designed it had eyes that responded to different wavelengths," offered Trillian. "Or didn't have much imagination," muttered Arthur. "Perhaps," said Marvin, "he was feeling very depressed." On Thu, May 21, 2009 at 12:34 PM, Angus Ainslie wrote: > Hi All, > > As I think we've fixed more things than we broke it's time for another testing > release. As usual there are additional instructions here. > > http://wiki.openmoko.org/wiki/Om2009 > > There is also a new page for community involvement. Many of these wishlist > items need someone to implement them. If you are interested in in owning one > of the wishlist items come and join #paroli or send me an email > > http://wiki.openmoko.org/wiki/Om_2009_get_active > > Don't bother trying to do an opkg update opkg upgrade to do the upgrade. > Chances are you won't get the dependencies right ( I know I didn't ). If you > want to preserve your settings use the bind-home method and flash the full > image. > > New in feeds > > callrec > claws-mail > dictator > dillo > midori > mokomaze > omnewrotate > pyring > sms-sentry > webkit-efl > > New features > > Improved call handling - should limit races in oeventsd > Better list handling > More consistent interface > New paroli-illume theme > - only change so far is to remove desktop switcher > - wanted volunteer to change analog clock to digital > - wanted different colour scheme ( maybe white on black to > match the rest of paroli ? ) > Static MAC addresses for usb devices > - usb networking will now show up as ethx on the host side please > check dmesg > on the host side > Ability to cut 30 seconds off boot t
Re: Om2009 testing release 4
2009/5/22 Jose Luis Perez Diez : > I was using the previous realease as a test-bed for a document I am preparing. > I want to show how to use the toolchain and distcc to develop on the neo, my > root fs is 0.5G without the swapfile, and runing the test suite of distcc3.1 > to see if pump mode could work so this morning I backuped my rootfs with > partimage on the pc and tried the upgrade. > > The first opkg upgrade warned me of paroli-elementary trying to overwrite > files that were of other packages. After "opkg install > paroli-elementary -force-overwrite" the opkg upgrade went well. > > I did not notice new issues. yep, had the same warnings here. no problems though, save from a segfault which reboot fixed ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
El Thursday, 21 de May de 2009 21:34:48 Angus Ainslie va escriure: > Don't bother trying to do an opkg update opkg upgrade to do the upgrade. > Chances are you won't get the dependencies right ( I know I didn't ). If > you want to preserve your settings use the bind-home method and flash the > full image. I was using the previous realease as a test-bed for a document I am preparing. I want to show how to use the toolchain and distcc to develop on the neo, my root fs is 0.5G without the swapfile, and runing the test suite of distcc3.1 to see if pump mode could work so this morning I backuped my rootfs with partimage on the pc and tried the upgrade. The first opkg upgrade warned me of paroli-elementary trying to overwrite files that were of other packages. After "opkg install paroli-elementary -force-overwrite" the opkg upgrade went well. I did not notice new issues. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Thu, 21 May 2009, Angus Ainslie wrote: > As I think we've fixed more things than we broke it's time for another > testing release. As usual there are additional instructions here. thanks to angus and all behind this. i note paroli goes to gitr46. initial impressions are very good, though i've only had it running for an hour. more feedback later. -- Tom Yates - http://www.teaparty.net ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Thu, May 21, 2009 at 04:16:23PM -0700, Michael Shiloh wrote: > Rui Miguel Silva Seabra wrote: > > On Thu, May 21, 2009 at 11:33:31PM +0100, Rui Miguel Silva Seabra wrote: > >> Problem at Display->Profile: can't get back to illume, illume, paroli > >> or paroli-illume all look exactly the same > > > > Mirko told me all you need is to reboot (first boot problems ... I really > > can't understand that) for it to work. > > > I added this to the wiki under known problems. Please check and correct > if I've misunderstood. It's OK! I should have added that but I was too tired to think straight. :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Rui Miguel Silva Seabra wrote: > On Thu, May 21, 2009 at 11:33:31PM +0100, Rui Miguel Silva Seabra wrote: >> Problem at Display->Profile: can't get back to illume, illume, paroli >> or paroli-illume all look exactly the same > > Mirko told me all you need is to reboot (first boot problems ... I really > can't understand that) for it to work. I added this to the wiki under known problems. Please check and correct if I've misunderstood. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Thu, May 21, 2009 at 01:34:48PM -0600, Angus Ainslie wrote: > - wanted volunteer to change analog clock to digital I just removed the analog clock, on the paroli-illume profile you still have the nice paroli clock and the analog isn't really very readable for me (due to size). Having a digital clock would be better though, speaking from my SHR tests runs, it's very readable and always present. Paroli's clock, of course, won't waste real estate on other paroli screens, but I still like to always be able to check the time at a glance on the phone, so I'd keep the paroli clock but also would like to have a digital clock on the menu bar. If you want a tester, I'm all for it :) > Ability to cut 30 seconds off boot time > - DO NOT use this if you use bind-home > - install udev-static-devices to get this speed boost > - any solutions on using bind-home and static-devices appreciated This I will do tomorrow. You could, although, just ln -s /media/card/home /home and this shouldn't then be a problem, right? > - suspend fails after a call http://trac.freesmartphone.org/ticket/435 This happened to me with SHR-unstable, and then calls would also be somewhat lost. I could understand a call was being made by the interference with the computer speakers at home, but the phone didn't do anything. I hope it's not the same since this, in effect, makes you loose calls. Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
On Thu, May 21, 2009 at 11:33:31PM +0100, Rui Miguel Silva Seabra wrote: > Problem at Display->Profile: can't get back to illume, illume, paroli > or paroli-illume all look exactly the same Mirko told me all you need is to reboot (first boot problems ... I really can't understand that) for it to work. Thanks Mirko! :) Rui ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Problem at Display->Profile: can't get back to illume, illume, paroli or paroli-illume all look exactly the same On Thu, May 21, 2009 at 01:34:48PM -0600, Angus Ainslie wrote: > Hi All, > > As I think we've fixed more things than we broke it's time for another > testing > release. As usual there are additional instructions here. > > http://wiki.openmoko.org/wiki/Om2009 > > There is also a new page for community involvement. Many of these wishlist > items need someone to implement them. If you are interested in in owning one > of the wishlist items come and join #paroli or send me an email > > http://wiki.openmoko.org/wiki/Om_2009_get_active > > Don't bother trying to do an opkg update opkg upgrade to do the upgrade. > Chances are you won't get the dependencies right ( I know I didn't ). If you > want to preserve your settings use the bind-home method and flash the full > image. > > New in feeds > > callrec > claws-mail > dictator > dillo > midori > mokomaze > omnewrotate > pyring > sms-sentry > webkit-efl > > New features > > Improved call handling - should limit races in oeventsd > Better list handling > More consistent interface > New paroli-illume theme > - only change so far is to remove desktop switcher > - wanted volunteer to change analog clock to digital > - wanted different colour scheme ( maybe white on black to > match the rest of paroli ? ) > Static MAC addresses for usb devices > - usb networking will now show up as ethx on the host side please check > dmesg > on the host side > Ability to cut 30 seconds off boot time > - DO NOT use this if you use bind-home > - install udev-static-devices to get this speed boost > - any solutions on using bind-home and static-devices appreciated > Keyboard goes away after use > Updated /etc/network/interfaces to give USB0 a metric > Added readahead to busybox to test speed increase > > Known issues > > Some oeventsd rules are ignored ( framework oeventsd problems ) > - don't suspend while plugged in > http://trac.freesmartphone.org/ticket/381 > - suspend fails after a call http://trac.freesmartphone.org/ticket/435 > > Bugs fixed > > 1 pixel wide illume exit menu > UTF chars in SMS's > - you must still install a keyboard to be able to write different > character > sets. > Keyboard collapses after use > > Angus > > > > > ___ > 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: Om2009 testing release 4
It is a midnight here, but I can't wait till tomorrow... flashing... :) 2009/5/21 Angus Ainslie > Hi All, > > As I think we've fixed more things than we broke it's time for another > testing > release. As usual there are additional instructions here. > > http://wiki.openmoko.org/wiki/Om2009 > > There is also a new page for community involvement. Many of these wishlist > items need someone to implement them. If you are interested in in owning > one > of the wishlist items come and join #paroli or send me an email > > http://wiki.openmoko.org/wiki/Om_2009_get_active > > Don't bother trying to do an opkg update opkg upgrade to do the upgrade. > Chances are you won't get the dependencies right ( I know I didn't ). If > you > want to preserve your settings use the bind-home method and flash the full > image. > > New in feeds > > callrec > claws-mail > dictator > dillo > midori > mokomaze > omnewrotate > pyring > sms-sentry > webkit-efl > > New features > > Improved call handling - should limit races in oeventsd > Better list handling > More consistent interface > New paroli-illume theme >- only change so far is to remove desktop switcher >- wanted volunteer to change analog clock to digital >- wanted different colour scheme ( maybe white on black to >match the rest of paroli ? ) > Static MAC addresses for usb devices >- usb networking will now show up as ethx on the host side please > check dmesg >on the host side > Ability to cut 30 seconds off boot time >- DO NOT use this if you use bind-home >- install udev-static-devices to get this speed boost >- any solutions on using bind-home and static-devices appreciated > Keyboard goes away after use > Updated /etc/network/interfaces to give USB0 a metric > Added readahead to busybox to test speed increase > > Known issues > > Some oeventsd rules are ignored ( framework oeventsd problems ) >- don't suspend while plugged in > http://trac.freesmartphone.org/ticket/381 >- suspend fails after a call > http://trac.freesmartphone.org/ticket/435 > > Bugs fixed > > 1 pixel wide illume exit menu > UTF chars in SMS's >- you must still install a keyboard to be able to write different > character >sets. > Keyboard collapses after use > > Angus > > > > > ___ > 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: Om2009 testing release 4
On May 21, 2009 01:48:44 pm Michael Shiloh wrote: > Angus Ainslie wrote: > > Hi All, > > > > As I think we've fixed more things than we broke it's time for another > > testing release. > > You've only updated the rootfs, right? So no changes in the wifi driver? > > M Right you could try the experimental kernel and modules. Angus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
fso-paroli-image-om- 8% |*** I'm waiting :) On Thu, May 21, 2009 at 10:58 PM, Risto H. Kurppa wrote: > Awesome Angus & Mirko - can't wait to get testing this :) > > 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 > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Awesome Angus & Mirko - can't wait to get testing this :) 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: Om2009 testing release 4
On Thursday 21 May 2009 20:34:48 Angus Ainslie wrote: > New features > > Improved call handling - should limit races in oeventsd > Better list handling > More consistent interface > New paroli-illume theme > - only change so far is to remove desktop switcher > - wanted volunteer to change analog clock to digital > - wanted different colour scheme ( maybe white on black to > match the rest of paroli ? ) Just a thought but would the serenity theme do perhaps? It has a white on black Illume bar at least. solar.george 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: Om2009 testing release 4
Angus Ainslie wrote: > Hi All, > > As I think we've fixed more things than we broke it's time for another > testing > release. You've only updated the rootfs, right? So no changes in the wifi driver? M ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Om2009 testing release 4
Congratulations! I'm downloading right now and will report back. I'm very impressed with the rate of revisions. Michael Shiloh Angus Ainslie wrote: > Hi All, > > As I think we've fixed more things than we broke it's time for another > testing > release. As usual there are additional instructions here. > > http://wiki.openmoko.org/wiki/Om2009 > > There is also a new page for community involvement. Many of these wishlist > items need someone to implement them. If you are interested in in owning one > of the wishlist items come and join #paroli or send me an email > > http://wiki.openmoko.org/wiki/Om_2009_get_active > > Don't bother trying to do an opkg update opkg upgrade to do the upgrade. > Chances are you won't get the dependencies right ( I know I didn't ). If you > want to preserve your settings use the bind-home method and flash the full > image. > > New in feeds > > callrec > claws-mail > dictator > dillo > midori > mokomaze > omnewrotate > pyring > sms-sentry > webkit-efl > > New features > > Improved call handling - should limit races in oeventsd > Better list handling > More consistent interface > New paroli-illume theme > - only change so far is to remove desktop switcher > - wanted volunteer to change analog clock to digital > - wanted different colour scheme ( maybe white on black to > match the rest of paroli ? ) > Static MAC addresses for usb devices > - usb networking will now show up as ethx on the host side please check > dmesg > on the host side > Ability to cut 30 seconds off boot time > - DO NOT use this if you use bind-home > - install udev-static-devices to get this speed boost > - any solutions on using bind-home and static-devices appreciated > Keyboard goes away after use > Updated /etc/network/interfaces to give USB0 a metric > Added readahead to busybox to test speed increase > > Known issues > > Some oeventsd rules are ignored ( framework oeventsd problems ) > - don't suspend while plugged in > http://trac.freesmartphone.org/ticket/381 > - suspend fails after a call http://trac.freesmartphone.org/ticket/435 > > Bugs fixed > > 1 pixel wide illume exit menu > UTF chars in SMS's > - you must still install a keyboard to be able to write different > character > sets. > Keyboard collapses after use > > Angus > > > > > ___ > devel mailing list > de...@lists.openmoko.org > https://lists.openmoko.org/mailman/listinfo/devel > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
