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

List:       kde-devel
Subject:    Re: Detection of hibernation wake-up
From:       Sebastian =?iso-8859-15?q?K=FCgler?= <sebas () kde ! org>
Date:       2008-10-23 18:06:13
Message-ID: 200810232006.14339.sebas () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 22 October 2008 22:07:56 Aaron J. Seigo wrote:
> On Wednesday 22 October 2008, Thiago Macieira wrote:
> > I don't know what happens to the monotonic clock when the system
> > hibernates. But one has to wonder if a timer that expired during the
> > hibernation still makes sense...
>
> for dataengines in plasma it means "there's a pending data update request".
>
> for a trivial example of where this affects us, a clock that only shows the
> minutes only fires it's timer once a minute (and does drift correction at
> that point to keep it aligned, of course). so if you hibernate at second N
> in the minute, you have to wait for 60-N seconds for the clock(s) to show
> the new correct time. (of course, if the clocks are showing seconds, it's
> 1000-N ms instead, not nearly as bad =)

I think using timers for that is the wrong approach. Those problems would all 
be solved by hooking the dataengines up with an update on resume signal.

For the user, there's some information that's likely to change while 
suspended, things I can think of:

- time?
- system information (battery, new devices, ...)
- network
- new email
- GPS information

In all those cases, it doesn't make a lot of sense to wait until the timer 
kicks in to detect those, IMO it's much nicer to have that also signal-, 
rather than timer-based where we can.

> it's survivable, no doubt, but not great, and we run into this issue with a
> few engines in real-world practice already. so  a timer expiring during
> hibernation isn't completely meaningless.

With the bits we currently have in place in KDE, we'll catch at least the 
calls from ksmserver, kickoff, automatic suspend actions (lid, timeout) and 
the plasma applet so we could in all those cases emit a signal that things 
might have changed. If the suspend action is done from the commandline in a 
way that doesn't make it go through powerdevil, or for example in a 'broken' 
application, we'd still get the update when the next timer kicks in (so in 
that case, the clock could be off for up to a minute post-resume).

The same kind of problem exists with the setting "lock screen on resume", by 
the way. The screen will also not be locked post-resume when you suspend from 
the commandline last time I tested it (but people aren't supposed to do that 
anyway :P).
-- 
sebas

 http://www.kde.org | http://vizZzion.org |  GPG Key ID: 9119 0EF9 



["signature.asc" (application/pgp-signature)]

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


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