[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Detection of hibernation wake-up
From:       "David Jarvie" <djarvie () kde ! org>
Date:       2008-10-22 12:33:28
Message-ID: 0459dfdeb5be676b6d19294e748e938d.squirrel () www ! sensical ! net
[Download RAW message or body]

On Wednesday 22 October 2008 9:39, Thiago Macieira wrote:
> On Wednesday 22 October 2008 10:17:30 David Jarvie wrote:
>> On Wednesday 22 October 2008 8:31, Kevin Ottens wrote:
>> > Le Wednesday 22 October 2008, Thiago Macieira a écrit :
>> >> Kevin Ottens wrote:
>> >> >> Check if HAL emits any interesting signals.
>> >> >
>> >> >It doesn't
>> >>
>> >> Can't we ask them to do that?
>> >
>> > It's kind of in maintainance stage. Feel free to try though.
>>
>> This would be the best solution. The alternative, if it is to work on
>> all
>> systems, would be to regularly recalculate the timers, in case the clock
>> has jumped due to hibernation. That means waking the program up
>> frequently, which is probably not ideal on a laptop.
>
> In order to calculate how long the system was in hibernation, you need to
> know
> when it entered that mode. That means you need another signal too. And you
> must be able to process that signal *before* your process is frozen by the
> kernel, which is not guaranteed at all.
>
> Furthermore, the clock may jump around, both during hibernation and during
> normal system operation.

Daylight saving time changes are already taken care of. The only other
likely causes of a jumping clock which I can think of are hibernation or
NTP adjustments. I suppose that NTP adjustments may also require timers to
be corrected.

> So, I have to ask: what problem are you trying to solve? Are you sure
> adjusting alarm times is the correct thing to do?

Currently, the application calculates the time at which the next alarm is
due, sets a QTimer to expire at that time, and waits until the QTimer
expires to trigger the alarm. This obviously assumes that the system time
doesn't jump unpredictably. If the system time isn't predictable (as
indeed seems to be the case), it will have to check every minute whether
the next alarm time has been reached.

-- 
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/kalarm

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]