backlight device, suspend/resume...

[Carsten Haitzler (The Rasterman)]

On Tue, 8 Jul 2008 21:34:17 -0300 Werner Almesberger <werner at openmoko.org>
babbled:

> Mike (mwester) wrote:
> > So what then, when the user reports that "the phone randomly powers
> > off"?  Do the hardware/kernel folks just tell the user to go away, and
> > bother the application folks?
> 
> Ah, but we have that problem anyway. Since it's user space that
> triggers all that, users are at the mercy of it, no matter how hard
> the kernel tries to know better. And bug reports will often come in
> the form of user perception, not in terms of what happens in any of
> the underlying mechanisms.
> 
> In this context, it would be interesting to have a general panic or
> watchdog handler that resets the system to a know to be good state
> (which is a lot more than the backlight - e.g., what good is the
> backlight if the LCM controller isn't configured ?) and then dumps
> its report somewhere.
> 
> There is actually a project that aims to do this. It's called kdump,
> and it just kexec's a secondary system stowed away in memory. It's a
> radical approach, but you can't argue with its power. It might be
> interesting to see if something along these lines could also be done
> on our platform.
> 
> > The secret to customer satisfaction is proactively thinking about what
> > might go wrong, and providing the user with information that might be
> > helpful.  Sometimes that goes in a different direction from expending
> > minimal effort in the kernel.
> 
> This time we're lucky - all it takes is to ask Carsten to make his
> daemon set the backlight to not-quite-pitch-dark. Everybody wins:

yup... i would consider this a possible "Debug mode". not default operation,
but if the user notices bizarre things going on around blanking/suspend/resume,
i would say having some configration where you can enable system-wide "debug
mode" and all software that understands this enables verbose logging,
reporting, and "Safe mode" operation settings. we need this much more in things
like qpe and gsm modem interaction right now than in a screen blanking daemon.
this is really a minor thing compared to the other major bug hunting work we
have ahead of us - and a general debug/logging mode you can boot the phone into
would be great for this.

> you get the user feedback, Carsten gets a kernel that always does
> what he tells it to do, Andy can avoid yet another "your policy
> patch is oh so wrong" flame war, and Sean and I get a kernel not
> cluttered with policy ;-)

aye. a kernel cluttered with policy is a bad thing.

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