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)
