backlight device, suspend/resume...

[Sean McNeil]

This is an area I have a strong opinion about...

Chris Ball wrote:
> Hi,
>
>    > Mike (mwester) wrote:
>    >> 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?
>
>    > If you need this, why not set the backlight to "dim" instead of
>    > "off" before requesting the suspend ?
>
>    > The secret about successful kernel programming is to do as little
>    > as possible in the kernel :-)
>
> At OLPC, we're using a small userspace policy daemon called OHM¹ to make
> decisions like these -- when to dim, when to suspend, how to tell if the
> user is "idle".  I'd be happy to help get it running on the FR if it's
> wanted.
>   

IMHO, OLPC is doing the right thing here as an application. The kernel 
provides functionality and does things at a very low level. You do not 
want it to be providing any utilitarian functionality. I would disagree 
that there is compromise necessary. Sure, one can have debug code that 
turns on the display coming out of sleep, but a release should do the 
right thing and leave the display in exactly the same condition it was 
in when it entered suspend.

This is the same reasoning I don't want any of the LEDs to be doing 
utilitarian things like being changed when external power is 
applied/removed - the kernel is not an application. I would be surprised 
if application capabilities such as these manage to make it upstream 
into the main kernel tree.

Cheers,
Sean