backlight device, suspend/resume...

[Carsten Haitzler (The Rasterman)]

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

> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> 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... :)
> 
> 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.

well we already have a problem with the way things are. let me explain. it's a
bug no one has noticed... but i've been wrestling with.

x blanks the screen. it does this by setting backlight level to 0, but backlight
is still logically on. now while level is at 0, something decides to suspend.
well - there is a nasty screen flicker (backlight comes back on, u can see the
glamo shut down and screen lcd contents go ugly) then systsem is suspended. if
the kernel didn't try and second guess userspace, we wouldnt get the flicker of
the screen the system would nicely suspend quietly on its own. that's what i
see in front of me right now - latest stable kernels.

anyway - the real problem comes next. you press power to resume. ok. resume
happens backlight it on and screen is active. the xserver has NO idea you
suddenly turned the backlight level back to 63 behind x's back. it set it to
level 0 because it was inactive. no mouse or key event has told it otherwise
and no software has told x "come out of blank". but now u see the screen
contents, as a bi-product of setting backlight on, but x THINKS it is still
blanked. it is sheer luck that x didn't try and do something even smarter like
pause/defer all screen updates while blanks (so screen wont update). since its
being dumb we have the illusion of x coming out of blank and the screen
updating, but unless u press a key (aux/power) or touch the screen x wont go
back to blank again as it never thought it came out of blank. so now we have a
problem. we came out of suspend, the userspace that requests a suspend on a
screen blank event, doesn't get sch an event as x doesn't think its un-blanked,
ans so the system never re-suspends on its own without human intervention AND
the screen is on.

all in all we NEED that usespace daemon. it has to implement policy. kernel is
there just to implement the nuts and bolts of drivers and everything working.
imho the kernel is not theplace for this and should just resume with devices in
exactly the state they were found on suspend.

it is NOW the task of such a userspace daemon to implement policy. determine
why we came out of suspend (a button press? a gsm interrupt? wifi interrupt?)
and then it may or may not turn the screen back on depending on reason - but
all this is now implementing higher-level policy and knowledge the kernel
doesn't have. IMHO it's only fair for the kernel to do what is most logical -
leave everything exactly as it found it when it resumes, regardless of that
state. let userspace handle the rest. :)

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