backlight device, suspend/resume...

[Carsten Haitzler (The Rasterman)]

On Tue, 08 Jul 2008 15:10:49 +0100 Andy Green <andy at openmoko.com> babbled:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> decided
> |> they want to have it that way and now we have to cope with it in
> userland.
> 
> 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?

yes. actual_brightness is displaying the correct value. the problem is that
brightness is not restored :)

> |>> 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.

oooh. u-boot! i'll have to... look at that then.

> | 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
> handle
> 
> 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.

here's the problem. we will get wakeups from gsm for things like cell broadcast
messages (change of location etc.). we dont want the screen coming on. we just
want cpu up - do some processing, go back to sleep. if userspace doesnt handle
the backlight itself, and if the kernel doesnt leave the backglight on resume
exactly as it found it on suspend... this is simply not possible without the
backlight flickering on whenever these wakeups happen. we need this (imho) to
be entirely in userspace.

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 have.
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 restore
as found... :)


> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkhzdWkACgkQOjLpvpq7dMr0uQCgjNRh8zhSVamkqniByMqkJBTR
> QkcAn1E31vG4TL1biYIsfxAMR7f+7iDJ
> =nAwx
> -----END PGP SIGNATURE-----


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