backlight device, suspend/resume...

Mike (mwester) mwester at dls.net
Tue Jul 8 20:31:57 CEST 2008


Carsten Haitzler (The Rasterman) wrote:

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

In principle I agree completely.

In practice, compromise is necessary.  Can we at least let the kernel
bring the backlight up to a level that would allow the user to see vague
outlines of something on the screen?  Or failing that, can we make the
backlight level on resume configurable in some way?

Until we write bug-free code, we need to be defensive about some of
these things.  Let's consider the failure mode where for one of about 10
million possible reasons, the user-space daemon that Raster describes
fails to do its job.  How does the failure manifest itself to the user,
and what sort of bug reports do we get back?

"Phone randomly turns itself off"

Not a very useful bug report.  But if we don't let the kernel give the
user *some* small ability to improve the bug report, we're only hurting
ourselves.  If the screen is somewhat legible, or if this can be
configured so that the screen will unblank on resume, perhaps we'll get
more useful information from the user:

"Phone fails to resume correctly; message on screen says: 'libabcxyz: no
space on device'"

I'd much rather have the latter bug report, and I'd hate to have to
maintain another custom community patch in order to be able to get that.

Regards,
Mike (mwester)




More information about the openmoko-kernel mailing list