backlight device, suspend/resume...
andy at openmoko.com
Tue Jul 8 16:10:49 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
|>> * backlight is ON and:
|>> # cat bl_power
|>> this seems reversed logic here. shouldn't 1 == on, 0 == off? the logic
|>> seems to continue its inversness when u:
|> Been ranting about this for years now -- back then kernel developers
|> they want to have it that way and now we have to cope with it in
What happens if we reversed this then, anything blow up?
|>> * now resume (press power)
|>> #cat brightness
|>> # cat actual_brightness
Yes, is it in fact at max brightness then?
|>> never seems it indicate the resume reason - no entry has an '*' next
|>> ever... :(
|> D'oh, that's wrong.
It's not wrong, it just means you need a U-Boot version recent enough to
capture and store the resume reasons. Update your U-Boot.
| yup. so i can never figure out what triggered the resume.. which
| my ability to sensibly handle things like "we resumed, but PLEASE
| screen off and backlight off on resume as the phone simply woke up to
I'm not sure userspace should take that on. Have a think about what a
kernel API there also dealing with suspend reason and stacking wake
requests for future could do for you and what it would look like.
Kernel is always "limiting [userspace] ability to [do everything
itself]" and sometimes that's a sign what you want should be in the kernel.
We clearly need a "resume reason handler" who operates before backlight
comes up at least and can fire some kind of event to userspace apps
blocked until they fire, even decide to go back to suspend afterwards if
if the app waiting on the event handled it and said it was OK.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel