backlight device, suspend/resume...

Andy Green andy at
Tue Jul 8 16:54:57 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

|> as such - i am writing a userspace daemon to handle powering on/off
of things -
|> ans co-ordinate suspend/resume and for just this reason it needs
backlight to
|> stay where it was for me to do anything more with it than i currently
|> this daemon basically issues the suspend request and as a result
knows when we
|> come back from suspend - i was looking into getting resume reason -
but i may
|> need to reflash my u-boot. i'll try that. but even so - we want
backlight (and
|> for that matter pretty much every single device) to be restored in
exactly the
|> state it was found on suspend... thus need brightness and bl_power to
|> as found... :)

It forces it up right now to avoid things timing out on backlight, going
to suspend and apparently not resuming because the backlight is down
then, because there has been nothing dealing with enforcing that any
better in userspace.

Now it looks like we come to a point that the userspace guy wants to hit
it with the userspace hammer and the kernel guy thinks it better to
whack it with the kernel hammer.  I don't mind overmuch if you want to
take care of it :-) but it'd be unfortunate if when we considered more
contexts that want to be part of it we found we started down a less than
ideal path.  It's worth having a muse about all the things plugging into
this and just checking it is the best way.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the openmoko-kernel mailing list