backlight device, suspend/resume...

[Carsten Haitzler (The Rasterman)]

On Tue, 08 Jul 2008 13:31:57 -0500 "Mike (mwester)" <mwester at dls.net> babbled:

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

good point.. BUT...  you make an even bigger leap of faith that software will
display some kind of dialog and user-readable information on the screen that
diagnoses such a problem. even less likely imho than such a daemon not doing
its job :) i am happy to allow for there to be config for how to bring up
backlight on resume, (leave as is) (use the following levels), but you also
assume the kernel is infallible too here.

imho we don't need this. we can know it suspends and isnt coming back with
backlight on by some other means - eg. usb connection and ssh... remember that
is we have usb, network and ssh still to get info as to what's up here. we dont
have a completely unusable dead device. all that will happen here is bug report
will go from "screen stays black after trying to wake up device" to "screen
comes up very dim" (or chances are they dont even notice that).

in the end weneed to try and make a production-level device and software stack.
we can't keep obvious debug things like this in. while we do development -
fine, but i think this is something we can very safely slicken up as we always
have usb left for debugging. maybe we should quickly blink one of the LED's on
wakup to know its waking up (even if screen is blank)... this is much less
obtrusive than the screen backlight being on in any way (just a quick 100ms
flash of an led).

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

at some point you need to remove all those debug wires and deliver a product
and not have it tied to the debug board on your desk - or in this case this is
just the software equivalent. imho this is a really innocuous thing to have
just work without special probes/hacks/modes.

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