No need to involve upower or systemd. You can just use Linux APIs directly.

It's just a matter of use CLOCK_REALTIME_ALARM with timerfd(). See this for details, the section about "Posix Alarm Timers":

https://lwn.net/Articles/429925/

AFAIK using CLOCK_REALTIME_ALARM timers might require privileges, but that shouldn't be too difficult to handle with a tiny suid helper that checks PK and then allocates the timerfd and passes it through STDOUT back to gnome clocks

What if the laptop is in a bag?

We are currently using the WallClock class which is in gnome-desktop which internally uses timerfd(). We need to check if this belongs there or if we roll our own thing... 
Actually if the new notification system goes in gtk, this probably belongs there: the notification system described on gtk-devel is responsible for keeping the notification alive even when the application exits and then of restarting the application once the notification is displayed...

Allan, well, make it something people have to explicitly ask for.

Paolo, if the timerfd for CLOCK_REALTIME_ALARM really requires privs (as i expect) and thus needs to involve a SUID binary plus PK integration, then I don't think gtk/glib are the best place for it... Dunno...

(In reply to comment #5)
> Allan, well, make it something people have to explicitly ask for.

People will inevitably forget that it has been set. Honestly, this seems like a really bad idea. We shouldn't make it possible for people to melt their laptops.

There are two solutions to this imaginary problem (it is really hard to find a laptop without emergency thermal shutdown):

- interim solution - provide a checkbox "Wake computer for alarm", maybe with some warning message 

- proper solution - implement selective wake in Linux kernel; other systems already have it on x86 hardware, calling it "darkwake" or similar. The idea is not to wake full system, but only selected components. For alarms, you need only to wake CPU and audio device. No need to wake HDD, network hardware or GPU (especially when the lid is closed).

(In reply to comment #6)

> People will inevitably forget that it has been set. Honestly, this seems like a
> really bad idea. We shouldn't make it possible for people to melt their
> laptops.

Allan, I have been hearing this for a long time and it's still pretty much a bogus argument. 

I mean, first of all, not all machines are laptops, there are other types we should care too, like desktops or tablets and where waking up from suspend is not only a non-issue, but especially in the tablet case where suspending is a much more common state a quite desirable thing, i.e. something that is done all the time, automatically, and without user intervention. 

Secondly even for most laptops the overheating thing is non-sense. Sure there were laptops like that, but they were the exception, not the common case. And we already except a few cases from the logic that the machine shall suspend when the lid is closed, for example GNOME recognizes if a second screen is plugged in and then doesn't do the automatic suspend.

Then, all new laptops are nowadays explicitly designed in a way that the suspend state is handled much more automatically, so that the machine can wake up from suspend on its own, and get back into it automatically. This is at the core at Apple's "darkwake" technology and also what Windows 8 is doing with what they call "connected standby". With other words: Windows and MacOS both can do this thing, and its an entirely artificial limitation to say that Linux shouldn't.

The focus clearly should be on making system suspend transparent and seamless, so that it is not that clearly part of the user interaction anymore as it used to. That's what GNOME should design for. But just sticking the head in the sand and saying that in the 1990s there were laptops where resuming from suspend could make them overheat and that's why we should never do any kind of automatic resume is a really bad idea.

Laptop power management is becoming a lot more like the power management of smart phones. On your smartphone, are you actually aware when the system is suspended or not? No you aren't, you can only guess that if the screen is off the thing might be suspended, but most likely you are mistaken, since they first power off the screen and only much later the CPU, and they wake it up all the time without having that reflect on the screen. And newer laptops are designed for the very same thing.

So, really, let's design GNOME for more than just some specific 1990s laptops. Let's design implicit power management into it, put some focus on automatic, agressive, granular suspend, and conversely on automatic, granular resume.

Just a note to say that the vala rewrite landed on master, which makes it easier to experiment with this low level C api

Created attachment 242186 [details]
CLOCK_*_ALARM timer test.

Hi all,
I wrote a small program to test the CLOCK_*_ALARM functionality and it actually wakes up the computer.

Just some notes:
* it requires root privileges
* the application that creates the timers must be running, otherwise the timers are destroyed
* the timers don't survive to reboots

About the Lennart post, it's possible from the control center to configure the computer to automatically go to sleep state after a certain amount of time of standby, so the overheating or the excessive power consumption should not be an issue.

Another solution should be to detect we are coming from a sleeping state and come back in it after a configurable amount of time.

*** Bug 756164 has been marked as a duplicate of this bug. ***

(In reply to Lennart Poettering from comment #8)
> So, really, let's design GNOME for more than just some specific 1990s
> laptops. Let's design implicit power management into it, put some focus on
> automatic, agressive, granular suspend, and conversely on automatic,
> granular resume.

I actually did set my laptop to do these things:

  - Automatically *suspend* after 30 seconds of inactivity (the minimum 
    setting in Settings is 15 minutes(!) but it looks like you can set
    a lower value via dconf-editor: org.gnome.settings-daemon.plugins.power.

  - Require a password from blank screen only after 60 minutes

I have a SSD disk, so waking up is reasonably fast, so I would totally use this, I imagine even with the current (on/off) level of granularity it would boost my battery life nicely. 

However I noticed that this does not work so well in practice:

 - Waking up from suspend *always* drops you into screenlock. The "Lock 
   screen after blank for.." -time limit should apply to suspended state too,
   wouldn't it?

 - Suspending seems to shut down input methods so I need to poke at the power
   button to wake the computer up. It would be nice to poke a key or move the
   mouse to wake up.

 - The notification about "computer will suspend because of inactivity" is
   persistent and requires you to click the "X" to make it go away, it really
   should realize when we are not idling anymore, and close itself.

 - VPN connection drops when the computer suspends.

I think an important side to the automatic suspend is the user experience. For example, my software engineer colleague often stands up and walks a bit to think of an issue he is trying to solve. He then sits down and hacks away. At least I find it very distracting if you have to stop your thoughts to type your password after getting back to the computer. 

You can always lock the screen manually if you walk away (and there's the timeout if you forget it)

(In reply to Tuomas Kuosmanen from comment #13)
> I think an important side to the automatic suspend is the user experience.
> For example, my software engineer colleague often stands up and walks a bit
> to think of an issue he is trying to solve. He then sits down and hacks
> away. At least I find it very distracting if you have to stop your thoughts
> to type your password after getting back to the computer. 
> 
> You can always lock the screen manually if you walk away (and there's the
> timeout if you forget it)

I would argue that screen locking before suspend is pretty important. Things like the Secret Service API uses screen locking as an opportunity to dump keyring encryption keys out of memory (or such is my understanding from the probably outdated wiki pages). I can imagine this being leveraged by chat applications too. Maybe this could be configurable, but I feel like anything that can be done to increase security whilst a device is unattended ought to be done.

Superseded by https://gitlab.gnome.org/GNOME/gnome-clocks/-/issues/1