Re: [SHR-Testing] Slow response when answering a call
W.Kenworthy wrote: I found this is mainly due to enlightenment using too much cpu - a workaround was posted a couple of weeks back. copy a desktop file from /usr/share/applications to /tmp, wait a few seconds and copy it back. Yes, I know it is black magic, but ... it works! Not nearly enough, unfortunately. This gets rid of some enlightenment cpu wasting, so yes - it responds somewhat quicker. But while 2-3s beats 8s, it is still not acceptable. What is so hard about cutting the ringtone in 0.1s or so? The latency must go. The pythm music player does much better, so this is clearly possible. The current phone app works, and that is good. But I am happy I don't get that many calls a day - the waiting is rather irritating. Helge Hafting ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
Hi all I just made up a small script here : #!/bin/sh cp /usr/share/applications/openmoko-dialer.desktop /tmp/openmoko-dialer.desktop sleep 5 cp /tmp/openmoko-dialer.desktop /usr/share/applications/openmoko-dialer.desktop Is it ok ? If so, how can automatically load it after startup ? For now, I am loading it with shortom. Kimaidou 2009/3/13 Cameron Frazier frazier.came...@gmail.com On Thu, 2009-03-12 at 22:07 -0500, The Digital Pioneer wrote: Well, that was almost more than I had dared hope for! This begs the question, how best to I set it up to run a script as soon as the GUI is done loading? It would probably be best to put a sleep 5 or so at the beginning, but I'd rather have it run after E is initialized. I too agree, having this voodoo incanted shortly after e init would be rather handy. I just tried it, and the delay dropped to only a second or two total, so a vast improvement. I suppose it will get better when the framework moves to a compiled language for FSO M6 (IIRC). Thanks for the info guys, Kind regards, Cameron ___ 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-Testing] Slow response when answering a call
On Thu, 12 Mar 2009 23:30:47 -0400 Cameron Frazier frazier.came...@gmail.com wrote: I just tried it, and the delay dropped to only a second or two total, so a vast improvement. I suppose it will get better when the framework moves to a compiled language for FSO M6 (IIRC). Just to clarify and not get any hopes up: We have a long way to go until the framework moves to a compiled language. It will definitely not be MS6. Regards, Daniel Willmann signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
Just to clarify and not get any hopes up: We have a long way to go until the framework moves to a compiled language. It will definitely not be MS6. Regards, Daniel Willmann Understood and apologies. I probably misunderstood a portion of an FSO update. Regardless, when it happens, I imagine it would greatly help this issue. Kind regards, Cameron ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
Regardless, when it happens, I imagine it would greatly help this issue. i doubt it. i use fso on debian for several months now and since a long while back there's no remarkable delay anymore. maybe some shr specific stuff causes your delays? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
On Fri, Mar 13, 2009 at 11:39 AM, arne anka openm...@ginguppin.de wrote: Regardless, when it happens, I imagine it would greatly help this issue. i doubt it. i use fso on debian for several months now and since a long while back there's no remarkable delay anymore. maybe some shr specific stuff causes your delays? That's what my thinking is. In my initial e-mail I was contrasting the delays between the previous SHR releases. Kind regards, Cameron ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
1) Create a .desktop file for your script (e.g., /home/root/fix-e.desktop). 2) Tell E to run that .desktop file on startup by adding its path to ~/.e/e/applications/startup/.order. echo /home/root/fix-e.desktop /home/root/.e/e/applications/startup/.order I am using a script that does not require having a dummy .desktop file lying around and seems to do the trick: #!/bin/sh FILENAME=/usr/share/applications/_fudge.desktop APP=[Desktop Entry] Name=fudge Encoding=UTF-8 Type=Application Comment=Fudge to make enlightenment not take such CPU time. Exec=/bin/false Categories=Applications echo $APP $FILENAME sleep 10 rm $FILENAME On Fri, Mar 13, 2009 at 4:31 AM, kimaidou kimai...@gmail.com wrote: Hi all I just made up a small script here : #!/bin/sh cp /usr/share/applications/openmoko-dialer.desktop /tmp/openmoko-dialer.desktop sleep 5 cp /tmp/openmoko-dialer.desktop /usr/share/applications/openmoko-dialer.desktop Is it ok ? If so, how can automatically load it after startup ? For now, I am loading it with shortom. Kimaidou 2009/3/13 Cameron Frazier frazier.came...@gmail.com On Thu, 2009-03-12 at 22:07 -0500, The Digital Pioneer wrote: Well, that was almost more than I had dared hope for! This begs the question, how best to I set it up to run a script as soon as the GUI is done loading? It would probably be best to put a sleep 5 or so at the beginning, but I'd rather have it run after E is initialized. I too agree, having this voodoo incanted shortly after e init would be rather handy. I just tried it, and the delay dropped to only a second or two total, so a vast improvement. I suppose it will get better when the framework moves to a compiled language for FSO M6 (IIRC). Thanks for the info guys, Kind regards, Cameron ___ 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 -- Dylan Maxwell Reilly ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
Ugh, my E seems to be broken. It no longer detects when something in /usr/share/applications changes. What now?? :( ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
On Fri, 13 Mar 2009 11:59:50 +0900 W.Kenworthy bi...@iinet.net.au wrote: Just once, I do it straight after boot - lasts through suspend etc. The original called for move and I wrote copy - sorry - not sure if copy works as well, or it has to be move (mv vs cp) BillK What works is anything that causes E/Illume to reload. Any change to a .desktop file will do it. What I've used for a while now when editing edje themes and icons is killall -HUP enlightenment. Save the lines below as Relite.desktop and it will work. (the icon is extracted from default.edj, it's also at http://newkirk.us/om/icon_applications_restart.png ) I think I'd find it irritating, but I suspect this can be 'automated' by sticking the killall command in /etc/X11/Xsession.d/99relite - maybe with a 20 second delay. j [Desktop Entry] Name=Relite Comment=Elightenment reload Exec=killall -HUP enlightenment Icon=icon_applications_restart.png Terminal=false Type=Application Categories=Application;Utility; ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
[SHR-Testing] Slow response when answering a call
Hello List I'm running an up-to-date SHR-Testing image. Upon receiving a call, I answer it, but the phone continues to ring/vibrate for about 8-10 seconds after I accept the call, then there is another second or two of delay before audio commences. These delays are rather problematic as the caller has no idea if I've picked up or if the call was dropped. I know there is some delays in the system, but earlier SHR images (the old testing and the older per-new-testing unstable releases) were much quicker when responding to a call. I'm writing this to see if there are any other users in List-land that have similar issues and any suggestions you may have. Right now I'm not sure if this is a localized (re: user) issue or not. Kind regards, Cameron signature.asc Description: This is a digitally signed message part ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
I found this is mainly due to enlightenment using too much cpu - a workaround was posted a couple of weeks back. copy a desktop file from /usr/share/applications to /tmp, wait a few seconds and copy it back. Yes, I know it is black magic, but ... it works! A few minutes later cpu will drop back to zero if nothing else is going on. BillK On Thu, 2009-03-12 at 21:48 -0400, Cameron Frazier wrote: Hello List I'm running an up-to-date SHR-Testing image. Upon receiving a call, I answer it, but the phone continues to ring/vibrate for about 8-10 seconds after I accept the call, then there is another second or two of delay before audio commences. These delays are rather problematic as the caller has no idea if I've picked up or if the call was dropped. I know there is some delays in the system, but earlier SHR images (the old testing and the older per-new-testing unstable releases) were much quicker when responding to a call. I'm writing this to see if there are any other users in List-land that have similar issues and any suggestions you may have. Right now I'm not sure if this is a localized (re: user) issue or not. Kind regards, Cameron ___ 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-Testing] Slow response when answering a call
I'll second this. It's always annoying, since the caller probably hears my ringtone still going which has to be odd for them... W.Kenworthy: Does that need to be done periodically, or just once after the phone has been running for a while? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
Just once, I do it straight after boot - lasts through suspend etc. The original called for move and I wrote copy - sorry - not sure if copy works as well, or it has to be move (mv vs cp) BillK On Thu, 2009-03-12 at 21:23 -0500, The Digital Pioneer wrote: I'll second this. It's always annoying, since the caller probably hears my ringtone still going which has to be odd for them... W.Kenworthy: Does that need to be done periodically, or just once after the phone has been running for a while? ___ 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-Testing] Slow response when answering a call
Well, that was almost more than I had dared hope for! This begs the question, how best to I set it up to run a script as soon as the GUI is done loading? It would probably be best to put a sleep 5 or so at the beginning, but I'd rather have it run after E is initialized. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [SHR-Testing] Slow response when answering a call
On Thu, 2009-03-12 at 22:07 -0500, The Digital Pioneer wrote: Well, that was almost more than I had dared hope for! This begs the question, how best to I set it up to run a script as soon as the GUI is done loading? It would probably be best to put a sleep 5 or so at the beginning, but I'd rather have it run after E is initialized. I too agree, having this voodoo incanted shortly after e init would be rather handy. I just tried it, and the delay dropped to only a second or two total, so a vast improvement. I suppose it will get better when the framework moves to a compiled language for FSO M6 (IIRC). Thanks for the info guys, Kind regards, Cameron 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
