Re: A desktop environment[1] kernel wishlist

[Bastien Nocera <hadess@hadess.net>]

On Tue, 2014-10-21 at 12:10 -0700, John Stultz wrote:
> On Tue, Oct 21, 2014 at 11:09 AM, Bastien Nocera <hadess@hadess.net> wrote:
> > On Tue, 2014-10-21 at 11:00 -0700, John Stultz wrote:
> >> 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.
> >
> >>   What happens
> >> if the user starts to use their machine at 12:00:01?
> >
> > I would expect the backup to stop and be tried again later.
> 
> What "event" would you be using to trigger stopping the backup?
> 
> 
> >>   What about if
> >> the user walked away from their machine at 11:55:01, and the system
> >> would suspend at 12:00:01, should the backup commence at 12:00:00?
> >
> > That wouldn't happen because we'd set the wake up time when suspending.
> >
> >> Thus you probably want to have a "user present" status,
> >
> > We can do any sort of thing once the laptop is awake. But right now
> > there's no way to know whether the resume is due to a user action or
> > not.
> 
> I'm suggesting its best if you don't care which specific irq brought
> the device out of suspend mode.
> 
> You may want to monitor various events like the lid-open or
> power-button (as well as the timerfd for alarms), and use those for
> your logic, but again, because a number of different irqs might bring
> the system out of suspend and those irqs can possibly occur almost
> simultaneously, which specific one landed first and woke the system is
> really not that useful (and again prone to races).
> 
> Now, I do think knowing which IRQ did bring you out of suspend is
> useful, but mostly for power-debugging when you're trying to optimize
> battery life. But for userland logic, I think its far too prone to
> races.

I also cannot know, from user-space, whether Wake-On-LAN,
Wake-On-Wireless-LAN, or the Wi-Fi card's "network proximity" triggered
coming out of suspend for example.

I can certainly check for the status of the lid, but I wouldn't know
whether a button was pressed to turn the machine back on, as the
firmware would eat that.

To make it short, I don't have a way to know, from user-space, whether
the event that took it out of suspend was programmatic, or user action.
I would add that, even if we said that races can occur, I have no easy
way to know, from user-space, whether the last thing that occurred was
the Wi-Fi card waking the machine up or the power button being pressed.

I'm sure all that information is available inside the kernel, but the
user-space interface for it is lacking.

> >>  then use the
> >> timerfd() ALARM clockids to set any wakeups you'd like, and when they
> >> trigger (if the system was suspended or not), decide to do your backup
> >> based the conditionals you had above, using the user-present status in
> >> a similar way to how you use AC status.
> >>
> >> I'd suggest looking into some of the details on how Android does its
> >> wakelock logic, as well as the timerfd ALARM clockids, since I think
> >> this would provide what you need.
> >
> > It doesn't. There's still a whole class of hardware that isn't always on
> > as mobile SoCs are, and wakelocks aren't going to help if the kernel
> > isn't running and we don't know why it started running again.
> 
> I'm not sure I parsed this properly. Mobile SoCs are quite frequently
> in suspend and not always on. They frequently resume both due to
> wakeup alarms, modem call irqs, and as a result of user-interaction
> like button presses.
> 
> 
> >> My bigger concern here with your use case though, is that you might be
> >> able to use ALARM timers more commonly, but that for much existing
> >> hardware, corner cases like programmatic resuming of a laptop while
> >> its packed in a bag somewhere might have thermal risks.
> >
> > I'm pretty sure that Windows has done this for years before we did. If
> > the laptop cannot suspend reliably, then the user would disable it. We
> > cannot keep designing around broken software.
> 
> Sure. But its not reliably suspending I'm worried about, its
> accidentally resuming in an environment the hardware wasn't designed
> for. Its really more of a hardware design issue. I'm not suggesting
> you don't do it, but I just suspect you'll need to be careful about
> automatically enabling this on older hardware.

It could be opt-in if that's actually a problem.