Hi Tim! On Tue, 2007-01-09 at 19:07 +0100, ext Tim Teulings wrote: > Hello! > > > the apps you have installed are buggy and generate activity > > and i mean any type of activity, 1% CPU load is still too much: > > if the app is idle, it must have 0% CPU activity > > What does that exactly mean (especially for non GTK-based applications > like mine that cannot expect some GTK magic)? First of all my deepest and most sincere thanks for this question. So maybe for once it won't look like i just rant against application developers. > Say for example I have an editor with has a blinking cursor. The GUI > library internally uses select with a timer as main event loop. Does > above statement mean, that my application is still running and select > still lopping and timer can run out and the cursor still blinks while I > put the cover on the device? Let's take the editor example and see it throughthe whole sw stack. *First of all the timer you are using from userspace is mapped to a queue in the kernel, which in turns uses a hw timer. *The kernel has _NON_ periodic system tick timer, meaning that system ticks are skipped when there is no activity scheduled. (So that means that if nothing perturbs the state of the system, it won't wake up, even if the cover is not present and you are looking at a static image of the text in your editor. As a matter of fact it does wake up every now and then, but the number of times can be approximated with 0, when compared to a system where there is a interrupt every tick.) *select will be (hopefully) implemented in a sane way that doesn't busy loop, but rather relies again on asynchronous events (notification from the kernel that the timer has expired) and therefore the library code shouldn't generate unnecessary activity. *finally the editor application: personally i consider blinking cursors to be evil, however putting aside personal feelings, in general it makes sense to do screen updates only when they are visible. So if the cover is on, what good is to update the blinking cursor? Same applies to cover off (open) but screen blanked. Again nobody will enjoy your nice blinking effect but that will cause the processor to periodically wake up. Certainly not for long, but if I may quote Depeche Mode, "Everything Counts in a Large Amount" > I always assumed that it goes in some kind > of hibernate mode where machine state is (nearly) completely frozen, Yes and no: -yes because it does go to hw specific power saving states -no because it is transparent to sw (well, most of it and certainly user space stuff) and if the sw doesn't keep quiet, the power saving state won't be reached. (Actually there are significant differencies between omap1710 and omap2420, with the latter having finer granularity of what hw blocks can sleep and how.) > but > your statement sounds like it just switches of some stuff of while CPU > is still running? I consider the "OFF" button on your everyday PDA just smoke in the eyes. Many people have compleined for the absence of a hybernate functionality. They have not understood that we are already doing it dynamically. All the time, at _runtime_, not just when the user presses the "OFF" button. Of course it takes more effort, but that's the way to go, since modern mobile processors would have ridiculous use-times if they were running constantly at full power. Or the size of the battery would become incredibly large. > How can I work around this? *Don't do unnecessary stuff *Don't poll *Don't busyloop *Check system state (by listening for events, again, never poll) *Keep updates at minimum *Do updates only if your application is visible, otherwise completely stop updating the UI till you become again king of the hill > Do I need to catch DBus events to get > informed that I have to go in some application specific low power mode? Yes, screen blanked should be enough. Also because N800 doesn't have a cover, but certainly that doesn't prevent us to do the very same power saving that was already available on 770. :-D The cover would just be the cause for an _immediate_ rather than timed screen blanking. -- Cheers, Igor Igor Stoppa <igor.stoppa at nokia.com> (Nokia M - OSSO /Helsinki Finland)
