This sounds like a good idea. I can't readily find any information about how to use rtc_wake - the only mentions are about direct interrupt register access, which an application program won't be able to do. Can you give me some pointers, e.g. to library calls, existing code, or to applications which already use the feature?

Created attachment 38116 [details]
code doing rtc alarm

...oops, sent attachement before writing text. 

Hi David, 
I'm glad you like the idea :) 
I did search really hard but none gui program seems to implement this feature. 
and, possible commands are rtc and apmd. 
but I have found this http://www.openpsion.org/howtos/series5mx_new/x243.htm
!:) see section 9.9 - /dev/rtc

Form this (src/rtc.c) and man rtc I've learned how to do the task with
/dev/rtc. 

It should allow setting alarm time as dd:mm:yyyy hh:mm (pendling) ..as in cron. 
wake from ram, hibernation & even power off ! (just ram works for me - bios
issues i guess)...thi s seems to solve our problem :) 

Multiple scheduled alarms must have been queued by kalarm and just the first
written to /dev/rtc. 

I think now I can help you fiddle with the code for editing /dev/rtc a bit if
you like. 
I can see two scenarios. 1/ rtc.c writes settings to /dev/rtc and quits. when
machine is suspended, it would wake up and kalarm could normally trigger the
alarm date. 
2/rtc.c keeps running till the time and kalarm could use it as a normal command
alarm: rtc +8:00 && mplayer morning.mp3

which one do you like better?

limitatons:
*need to que multiple alarm times
*should wake from suspend-to-disk work, linux has to be 1st os booting.

Is something from this useful to you? 
bye

i can soon provide the polished code of rtc_alarm, how does it look, would somebody be interested in implementing it to kalarm? maybe for kde4.4?:)

If you can provide code for KAlarm, it would be welcome. Unfortunately, the deadline for new features for KDE 4.4 was a week or two ago, so it will have to wait for KDE 4.5. Apart from the actual rtc code and integrating it into KAlarm, there would be an issue about root permissions to allow the rtc wakeup to be set up. Because rtc alarms need root permissions, it might be necessary to prompt for the root password every time KAlarm was run, if there was an rtc alarm in its calendar.

Perhaps accessing the rtc could be permitted via PolicyKit? I would also love that idea, since this is (besides gaming) the very last thing I still use Windows for - to wake up and open a music playlist in Winamp, which gives it the role of a radio clock. I tried nvram-wakeup for this, but my board is not supported.

Hi, I'm glad you like the idea :) 

The Policykit seems like a good solution to me too. 

As for the status of things: 
I've pushed a code to rtcwake's git that allows for disabling any previously set alarms and hopefully I'll add a support for pretty print of set alarms soon. 

To sum up, rtcwake - part of util-linux-ng package (I believe this is very widespread among almost all distributions) now supports methods to wake from suspend/hibernate state, time can be specified -s <seconds to wait> or -t <time as in format for date command> and current info can be obtained from cat /proc/driver/rtc 

I think the background is now complete, if someone could implement a graphical interface into KAlarm to handle this, it would be great! :) --this would mostly be adding a checkbox 'wake from suspend' and if checked, executing 'rtcwake -m no(=continue running, but set the alarm, so if user suspends, alarm will trigger anyways) -s <time_to_sleep> '. That's it. I unfortunately don't know enough about programming for KDE :( 

For more info, please see man rtcwake or ask me, I'll help if I can. 

PS: the workaround solution I use now is: 
sudo rtcwake -m mem(=suspend) -s $((hours * 3600)) && mplayer ~/music/*
works great! 

Thank you, Marek

I'll try to add this feature for KDE 4.6 (there is a feature freeze for KDE 4.5 by now). It's definitely a feature which KAlarm would benefit from, and it shouldn't be too difficult to implement with the information you've supplied.

One thing I'll also need to know is how to cancel an alarm. The version of rtcwake on my system doesn't have that new feature, so 'man rtcwake' doesn't help. Can you please tell me the option to use for this?

Hello David, 
it would be awesome, if you implement that feature! :) 

To cancel alarm, it will be: rtcwake -m disable

If you want, you can obtain latest git tree from:  git clone git://git.kernel.org/pub/scm/utils/util-linux-ng/util-linux-ng.git util-linux-ng
Than just ./autogen.sh; ./configure; make
and it is in sys-utils/rtcwake

I was thinking about the implementation, you will know better which choice to use. I came with these: 
* rtcwake -m no(=set alarm  to ensure PC wakes up at the time, then exit) -s <time minus 'some time to wake up'> and then set a normal alarm using KAlarm. 

* or in a separete thread: rtcwake -m on(=this blocks until required time) -s <time> && commands you want

Also, to get the alarm time, one can cat /proc/driver/rtc (times in UTC) but i'm working on 'rtcwake -m show' to pretty print just the alarm time and convert it to localtime. I have some troubles there, but if you don't want to bother with converting from the /proc/driver/rtc, you can probably rely on this. 

Thank you very much for interest in this. 
Greetings, Marek

I gave it a short brainstorming and came up with the following. First, I made it over-complicated with an own suspend-scheduler, but then it popped to my head:

only add a checkbox "Wake up from suspend" to the Time groupbox and let the suspending itself be done somewhere else. There are already good solutions for this, namely

- KShutdown (scheduled suspend)
- Powerdevil (manual suspend)
- echo mem > /sys/power/state (scriptable suspend)
- etc...

KShutdown, for instance, can put the computer to sleep when a process has ended. That allows the machine to compile over night, get some sleep and then wake me up in the morn'. :-)
So whenever something in the wakeup schedule changes, KAlarm just would need to write the change to the clock immediately (for instance the next recurrence, deletions etc), nothing more.

When an alarm with wake-from-suspend enabled is disabled or deleted, it would be desirable to cancel the wakeup. But it just occurred to me that if KAlarm cancels a wakeup, it could by coincidence be the same wakeup time as already set by some other application. In that case, it wouldn't be desirable for the wakeup to be cancelled. I wonder if there is any way of cancelling a wakeup without this possible side effect? For example, does rtcwake implement a count of how many times a particular wakeup has been set, so that cancelling the wakeup simply decrements that count (and only actually cancels the wakeup if the count reaches zero)?

David: 
good point, unfortunately there is no way to ensure this with rtcwake, it stores only a single wake up time/date, nothing else. 

A solution that came on my mind would be: keep a sorted list of alarms, earliest on the top. when adding a new alarm, just insert a new date to the list, deleting would be the same logic. /dev/rtc would then hold the time of the topmost alarm or disabled if empty. 

Why I wouldn't care much for this: 
*I don't know (m)any apps that use rtc wakeups, and if they exist, they would probably screw our KAlarm's wake up times too. So this is more or less just for multiple alarms in KAlarm. 
*general rtc's functionality is limited. Here is a snip from kernel's documentation: 

Documentation/rtc.txt:

        Programmers need to understand that the PC/AT functionality is not
        always available, and some systems can do much more.  That is, the
        RTCs use the same API to make requests in both RTC frameworks (using
        different filenames of course), but the hardware may not offer the
        same functionality.  For example, not every RTC is hooked up to an
        IRQ, so they can't all issue alarms; and where standard PC RTCs can
        only issue an alarm up to 24 hours in the future, other hardware may
        be able to schedule one any time in the upcoming century.

it varies from PC to PC, I can for example set alarms to any time, day, month, but not year. 
You can try for yourself: 
rtcwake -m no -s 2000000; cat /proc/driver/rtc
and 
rtcwake -m no -s 200000000; cat /proc/driver/rtc

So for a start I suggest only a single alarm at a time, to a time <= 24h. Maybe add recurrent alarms-just add another when waken-up, and a button 'erase all alarms'. 
But if you feel you want to play with the list of alarms, it would definitely be uber-cool :) // I'd add it maybe later.

Maybe we could make a code to test RTC's functionality on users system(setting alarm to <24h, next day, next month, next year) - determine this functionality and warn the user, if he/she sets an alarm to an unsupported date. (this could be just: set the alarm & check, if the stored value is equal to the one passed by the user).

So..what do you think about that? :)

Frank: 
I definitely agree on keeping it as simple as possible. Just a checkbox 'allow wake from suspend', maybe a button 'clear all alarms' would be fine. Users have their own methods of suspending (powerdevil etc, as you said). And code for triggering an alarm is already in KAlarm, just let's ensure system is up in time for KAlarm to be able to ring the alarm.

Cheers, Mark

Well, I know of no other KDE userland tool that would use wakeup features. And if $user does use another such application, I impute to him that he knows what it does. (Perhaps, upon enabling the wakeup feature, a popup could be shown describing the possible conflict, along with [ ] don't show again).

Managing the wakeup times is a simple "state-machine": KAlarm would only need to store the very next wakeup event and ensure that the RTC is up to date. Then, there are only four (six) possible things that could change the state:
- deleting an event
- adding a new event
- changing an event
- execution of an event
- (re-evaluate upon application startup, in case the data file was changed externally)
- (changing the host time and date)

Things in parenthesis are not necessary, but will prevent unexpected behavior.

After one of such things occured, KAlarm only needs to re-determine for every stored item, when it will fire next, remember the earliest of those times and update the RTC accordingly.

Ah yes, not to forget: if KAlarm is exited, then I think it should cancel the wake-up. Because since it is responsible for setting it up, I can image that $user will expect that wake-up only works when KAlarm is actually running.

Hello everyone, 
after a long time, but happy to announce that everything needed is now upstream in util-linux. 
git clone git://git.kernel.org/pub/scm/utils/util-linux/util-linux.git util-linux
 to obtain the devel version with patches. 

So: 
* rtcwake -m show -l // (local) prints current alarm settings 
As someone pointed out, we would need root priviledges for calling /usr/sbin/rtcwake but for this time-check a bash script file with a suid bit can be made. 

* rtcwake -m disable // cancels an alarm, needs root
* rtcwake -m no -t <secs since begining of unix time> // will set the alarm, also needs root

What I suggest, let;s make things simple but atleast something at the begining. 
Allow just 1 alarm for time <=24h (alarm pools can be added later), I imagine just a check box 'wake from suspend?' that will bring the machine up, say 5 mins before alarm rings. 
If kalarm is quited, cancel all alarms, if a new alarm is added, rewrite the prev. one (a pop-up info window?)

That could be reasonable to implement at start and would provide the basic 'notebook as an alarm clock' feature and allow us some testing. 
Later on, more mature features can come. 

What do you think about that? 
Cheers, Mark

Requiring root access to set and cancel alarms does limit this facility. It has the following implications:

- It is probably only feasible to allow one alarm at a time to have the 'wake from suspend' option.

- For recurring alarms, the user would need to be prompted for the root password each time the alarm triggered to make the next recurrence 'wake from suspend'.

- When KAlarm quits, a 'wake from suspend' alarm could only be cancelled if the user entered the root password. This would be an unacceptable block to quitting the program (e.g. on logout), except where it it quit by direct user action.

These limitations might be able to be overcome by using KWallet - I'm not sure whether it can help or not.

I'm not sure why you suggest that the alarm must be within 24 hours - is this because some systems only provide hardware wakeup up to 24 hours ahead?

I have partially coded this feature, and hope to have it implemented for KDE 4.7. The migration to Akonadi has taken too much coding time to get it done for KDE 4.6.

Hi Dave, 

sorry for replying so late. That's great you've done some code! I'd love to use it with 4.7. 

Yes, the <=24 hours alarms are pointed out in kernel documentation for rtc but I believe most machines today really support that. And KAlarm could test it potentially on the first run by setting an alarm say 1y ahead and then retrieving and checking the date. 

The root-only privileges you described are a problem. But I think KWallet should be able to serve the task. Eg. it's possible to change time/date from kde settings so it should be basically the same. User would need to enter the root password once, remember it by kwallet and 'Always allow' KAlarm to access this password and all should run smooth. 

Is there a code in trunk to try out? 
Thanks, Marek

I'm afraid this is still only partially done - migrating KAlarm to Akonadi has taken priority in the last few months, but hopefully this will be done soon and I can work on wake from suspend again. The code isn't in a state to commit to trunk yet, but any offers to help with the coding would be welcome - I could put what I've done into a scratch repository in git.

I'm looking at this again - it might get in for 4.7 after all. If only one alarm is allowed to be wake-from-suspend, it might be better to have a separate dialog to control the wake-from-suspend function. This would allow the currently highlighted alarm in the alarm list to be selected for wake-from-suspend. It would also enable the user to identify the current wake-from-suspend alarm, and to cancel wake-from-suspend. It could also configure how long before the alarm time the computer should be woken up.

The idea of this is that wake-from-suspend is a special feature, so it is accessible from a separate dialog, not from the alarm edit dialog. An additional point to note is that the wake-from-suspend attribute would not be stored in the alarm calendar, but in the user's config, since if the calendar was accessed on another computer the wake-from-suspend function should probably not be transferred to there, certainly not automatically.

Hey, that'd be cool! 

1/ I don't see improvements about the new separate dialog window, in contrast to check box for each alarm entry (that could fire a dilalog window to set time,etc).. but if you think it may simplify things, it looks just fine :) 

2/ some time to wake before actual alarm, to let the machine boot: yes, this could be just in a config file, or if you code gui to set it too.. And I think this is hw specific, so it's not needed to be set per alarm, just globally. Like eg 3 mins seems reasonable default. 

3/ good catch, the wake-up time should really be stored in different config from other alarms that can be accessed from another machine. 

Thanks a lot for coding this feature! :)
mark

This has now been implemented for KDE 4.7. If you are able to build it from the KDE master sources and let me have any comments on the implementation, please do so before Thursday, because user-visible strings for 4.7 are frozen on that day so can't be changed until KDE 4.8.

Git commit bdc4d3b4d4a3a8b6bf52fde06e88f1f946ddd1dd.

I'll definitely have a look, thanks a lot! I'm now ill so unfortunately not before Thur.