backlight device, suspend/resume... / Suspend during calls

[Carsten Haitzler (The Rasterman)]

On Wed, 9 Jul 2008 11:50:00 -0300 Werner Almesberger <werner at openmoko.org>
babbled:

> Carsten Haitzler wrote:
> > yeah. it'd be nice to have this. this would make so many things simpler, but
> > then we REALLY need userspace actively aware of power saving.
> 
> Raste^H^H^H^H^HPandora's box is open now ;-) I think this is where
> we ultimately have to go. In some cases, we'll be able to hide power
> state in a layer below the application, but in some cases, this isn't
> a good model, and trying to forcibly fit everything into that model
> just causes confusion, bugs, and pain (not the pleasurable one meted
> out by Andy's leather-clad design dominatrix ;-)

yah. ultimately we must go there... and i guess to some extent this is a step
on the way... but until we have "zero clock" i can safely assume its "in the
future" and for now have to just wrestle out suspend/resume into behaving as
transparently and reliably as possible so we have a phone that works and gets
some decent battery life. :)

we indeed may need a fallback for some apps. i have been mulling, but this
userspace daemon can set the kernel scheduler to FIFO mode, walk the process
table before issuing a "go into zero clock", and then SIGSTOP any process it
thinks is not "power-mode-aware". we'd need some way for a process to mark
itself as aware (links a dummy library in, sets some environment var,
dunno...), and these are left alone (well they are just issued a "time to go
into powersave mode" message). it can SIGCONT all processes it SIGSTOP'd coming
out of zero-clock...

but this is just a thought... for now it doesnt need to be reality, but it'd be
a way of providing suspend/resume-like behavior for "legacy apps" and for "new
gen power aware" apps, they can be left to their own conscience... :)


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>