inhibiting suspend via dbus

Mikus Grinbergs mikus at bga.com
Sat Aug 9 19:35:39 EDT 2008


> We shouldn't be patching every program to "avoid suspending" at various
> times.  We should be improving the heuristic that the system (Ohm) uses
> to decide when to suspend.  Once we have better information from the
> kernel about what the running processes are doing, we'd just have to
> rip out all the little kludges inserted into every program.

Currently no good definition of criteria exists.

I've seen two situations where I need 'inhibit-idle-suspend'.  My 
current attitude is -- I'll set that "flag" manually when I'm doing 
these things, and will clear that "flag" when I can again tolerate 
suspend:

(1) While downloading.  I use ethernet, and it has been explained to 
me that this uses *less* CPU than the "keep-alive" processes for 
which Ohm makes an allowance.

(2) While running a background computation.  It has been suggested 
that I should use a "wrapper",  which sends notifications to Ohm. 
But this is someone else's binary, and uses dynamic dispatching of 
executables.  I really really don't want to monkey with it.


--------

One possibility -- OFW already tests for "is the XO plugged in?". 
Maybe Ohm can test for that, and decide that suspend is not needed 
when the battery is fully charged, and is not being drained.


mikus




More information about the Devel mailing list