backlight device, suspend/resume...

Carsten Haitzler (The Rasterman) raster at
Wed Jul 9 14:09:56 CEST 2008

On Wed, 9 Jul 2008 08:09:48 -0300 Werner Almesberger <werner at>

> Carsten Haitzler wrote:
> > just what i'm doing... which is why i'm asking for the kernel to "please
> > just leave the device just as you found it on suspend.. i left it in that
> > state for a good reason!" :)
> By the way, since your daemon project is news to most of us, could
> you please post a brief description of where this is heading ?
> E.g., whether it's more like a system daemon (udevd, etc.), or part
> to a specific GUI framework, how it communicates with applications,
> how policy choices (such as the backlight intensity on resume) are
> configured, etc.
> (Maybe start a new thread for it. Those 1kmails+ threads get a
> little unwieldy ;-)

it's to solve a simple problem:

1. qpe is in the middle of a phone call
2. e/illume dont know or care about this
3. screenblank kicks in during call
4. system suspends.. during call.

now user can't hang up - no screen to interact with until they come out of
suspend. also audio and all sorts of gsm stuff gets broken if this happens, so
simply - we can't go suspending during calls. there would be other times we
can't suspend (eg during the time a voip client is active and making/receiving
calls or just waiting for incoming calls, etc. etc.), so there needs to be a
way to say "hey - block suspends for now until i say otherwise".

this same daemon also handles the "please suspend now" requests and basically
evaluates the list of blocks on suspend vs the list of requests to suspend, and
when it is safe to suspend (ie all the blocks are cleared) AND there is still a
"please suspend" requests there, it then suspends. as such it can also handle
wakeup and since it does this it needs to know wake up reason - if the reason
is that a user pressed the power button, the screen must come on on wake,
otherwise it should not come on - not until a client asks x to come out of
screenblank and actually display something (eg an incoming call).

it's 400 lines of C as a dbus daemon. its a system session daemon so a system
service. right now it is very limited - it only understands the concept o the
cpu, it suspending and resuming and the fact hat x exists and has a screenblank
thing happening and it appropriately resets the screensaver timeout on resume
right now to ensure blanking happens again so u can suspend again (before this
would never happen due to the above bugs unless u pressed a button or the

it can be extended to understand more devices (gps, wifi, etc.) with the
current dbus api. so it sits in a middle land - a system level daemon that also
understand a little bit of the raw basics of the gui. if the kernel left
backlight alone it could understand even less and just play with backlight
on/off as needed (ie turn off just before suspend, and on resume turn on ONLY
if u need it - i.e. power button pressed on resume).

we've spent more text talking about this than the daemon source code size... :)

Carsten Haitzler (The Rasterman) <raster at>

More information about the openmoko-kernel mailing list