Re: A desktop environment[1] kernel wishlist

[Zygo Blaxell]

On Mon, Oct 27, 2014 at 03:28:04PM +0100, Bastien Nocera wrote:
> On Wed, 2014-10-22 at 13:04 -0400, Zygo Blaxell wrote:
> > On Tue, Oct 21, 2014 at 08:09:38PM +0200, Bastien Nocera wrote:
> > > On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
> > > > On Tue, Oct 21, 2014 at 10:14 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote:
> > > > >> As for: 'Export of "wake reason" when the system wakes up (rtc alarm,
> > > > >> lid open, etc.) and wakealarm (/sys/class/rtc/foo/wakealarm)
> > > > >> documentation'
> > > > >>
> > > > >> Can you expand more on the rational for the need here? Is this for UI
> > > > >> for power debugging, or something else?
> > > > >
> > > > > No, it would be used for automating backups, or implementing
> > > > > suspend->hibernation transitions. For example, right before the machine
> > > > > suspends, I would schedule it to wake up in a hour. If I get woken up by
> > > > > the rtc alarm (and not by the user through a lid open), I might:
> > > > > - check that I'm plugged into the AC, it's night, and in the vicinity of
> > > > > the server that handles my backups and so backup the system.
> > > > > - check whether the battery is low, and hibernate the machine (if it
> > > > > supports it, obviously).
> > > > >
> > > > > We cannot do that if we can't make out whether the wake-up came from a
> > > > > user action, or the alarm we set.
> > > > 
> > > > I suspect wakeup type reporting is maybe not the best way to go about
> > > > this, since there may be a number of causes for wakeups and they can
> > > > arrive closely together in different orders, which can result in
> > > > races.
> > > > 
> > > > For instance, if the machine suspends, and sets an alarm to be woken
> > > > up at midnight to do a backup, if the user resumes their laptop at
> > > > 11:59:59, should the backup still proceed at midnight?
> > > 
> > > No. And I would expect that we would get a wake up type of "power
> > > button" or "lid open" in this case.
> > 
> > I have been using something like this for the last 7 years or so.
> > The relevant inputs are:
> > 
> > 	1. is the user present (is there recent input on HID devices,
> > 	keyboard/mouse, but ignore devices like light sensors, 3D
> > 	accelerometers, and ACPI virtual keys)?
> 
> If the user woke the machine up through the power button, you wouldn't
> see that from user-space. You could detect that the lid was opened,
> because you have state.
> 
> > 	2. which network connection(s) are available to reach the
> > 	backup server?
> > 
> > 	3. how much power is available (if on battery, how much run
> > 	time left?)
> > 
> > 	4. what is the policy (do backups happen at a specific time
> > 	of day, or whenever they can?)
> > 
> > 	5. was a backup completed successfully in the last N hours?
> > 
> > Note the absence of any information about the cause of recent
> > suspend/resume activity, or any input from suspend/resume at all.
> 
> How do I tell my environment not to wake the screen up when the machine
> was woken up by an alarm I scheduled to launch a backup? 

Lid closed?  Screen off (nobody can see it, it wastes power on battery,
and lengthens charge time on AC).

Lid open and user input?  Screen on.

Lid open and user disabled time-based screen power saving?  Screen on.

These are not symmetrical.  To wake up the screen, the screen needs to
be visible, and the policy conditions to wake up the screen need to be
met.  Spontaneously firing up a backlight at full power in a dark room
in the middle of the night may not be appreciated by the system owner.

I could see the utility of capturing ACPI state here, but only as a way
to sense the "user present" condition.

> Or not to
> resume audio playback when I get woken up to handle network events
> (through connected suspend, or Wake-On-(Wireless-)LAN)?

Audio playback can wait for evidence of user presence too (unless we're
implementing an alarm clock, and need to wake up the audio ourselves--but
we'd know that because of the time).

Attachment: signature.asc
Description: Digital signature