I have read in various threads that when running some apps, such as Xterm and Microb dyntick will not lower the' tick rate', thereby decreasing battery life when in 'lock screen and keyboard' mode.

To me that seems like a bug, but I can't find anything about this in Maemo bugzilla. Would this be a 'bug' in those specific apps or is something in the OS in need of fixing?

Well it's not disabling, it's that these tasks do thing that don't allow dyntick to take effect.

This may or may not be a bug - some applications require such behaviour (e.g. timers) while others do not (either unnecessary or could be done some other way).

In almost all cases though, when an application goes into the background, timers should be stopped, to allow battery saving behaviours to take effect.

What do you mean by 'into the background' ? Not as a background process I assume? Do you mean minimized? At any rate, If I tell my device to go into a power-saving mode I tink it is reasonable to expect that applications comply with that.

@iamthewalrus: So if you start a timer and then "lock screen and keys" what do you want it to do? Keep accurate time? or stop the timer to save power?

Well, technically you currently don't tell your device to go to power-saving mode. Device goes to power-saving mode automatically whenever possible.

I see what you mean but part of the problem is in fact lack of such explicit power-saving mode. there is offline mode, mode when screen is off, mode when touchscreen and keyboard is locked but no explicit 'please do really nothing and save power' mode.

Good example is media player, people want it to play even in offline mode, with screen, keyboard and touchscreen off. This is can of worms, random people want random set of features to work in such idle mode so there can't be one such mode.

You're right. You could say 'lock screen and keys' does exactly what it says. That that also can be used as a 'sleep' mode is more a happy coincidence. Maybe what we need is this explicit 'sleep' mode or even a real 'suspend to ram'.

I don't know enough about programming to understand how applications use this timer, but in case of the not yet existing 'sleep' mode I think we need to temporarily stop these timers or applications. Isn't there some standard for how applications should deal with power management in Linux?

The easiest solution is probably that if you minimise an app it should attempt to stop all dyntick-stopping behaviour. Do apps get a signal that the screen has been locked? If so, these apps should stop display routines/update timers anyway as the output is not being seen.

Applications with a user interface are usually event-driven and idle most of the time. Only when a user does something, an event is generated and handled by the application. Only when all applications are idle, the device can go into power-save mode.
Timers can be setup by applications to trigger actions without user input at regular intervals. Since these also run while the device is idle, they prevent the device from switching to power-save mode.
Good behaving applications never let timers be run when not needed. But many applications unfortunately do. Many applications were ported from desktop-Linux where extreme power-saving is simply not an issue.
Application programmers need to be made aware of power-efficient programming. This is relatively new.

I've noticed that when I'm in RSS and click on an article and it opens an Opera window (I'm an Opera/OS2007 person) then the browser appears to not be loading in the background if I minimise it and continue to read the RSS while waiting (that is, doing something else while waiting for the page to load doesn't really work..). Does that mean that Opera and MicroB behaves differently in this case? There's some conflict of interest here, even for the same individual.. I like the browser not to spend CPU on things while I'm not using it, on the other hand background loading would be useful now and then.

For the locked screen case I think I would like the application to be notified. In that case I would want the browser to heed it and not do anything.

Without thinking it through too much I see a couple of scenarios:
- Minimised mode: Browser should finish load the currently loading page, but stop any animations. My satellite tracking software (vaporware at the moment) will stop updating the tracking display while minimised.
- Screen locked: All updates of (the invisible) screen to stop.

Well, non-programmers may be confused by this. We are talking about microsecond precision here. And we are also talking about various parts of the device going independently into their power saving modes, not just the main CPU. In normal mode of operation even if device is (heavily) used, various bits go to power-saving mode every now and then. So there is no one power-save mode that such applications continuously prevent to enter. It is not black or white.

What matters is that applications do unnecessary work that consumes power. It is about ratio between sleeping device and active device (with microsecond precision) where 'sleeping device' consists of separate sleeping parts - CPU, wi-fi, bluetooth, audio/DSP, display, touchscreen, mmc cards, usb, ....

Once this ratio is bad enough you have dead device in few hours.

Some applications abuse CPU, some do network activity, some leave audio open, some scan mmc cards or read/write to files ...