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
