backlight device, suspend/resume...

Andy Green andy at
Tue Jul 8 16:10:49 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

|>> * backlight is ON and:
|>> # cat bl_power
|>> 0
|>> 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
|>> 21
|>> # cat actual_brightness
|>> 63

Yes, is it in fact at max brightness then?

|>> never seems it indicate the resume reason - no entry has an '*' next
to it
|>> 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
heavily limits
| my ability to sensibly handle things like "we resumed, but PLEASE
leave the
| 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.

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


More information about the openmoko-kernel mailing list