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