[Kde-hardware-devel] Review Request: Add suspend-signal to powerdevil and make plasma time dataengine detecting clock skrews

[Björn Ruberg]

> On 2010-09-13 16:44:03, Dario Freddi wrote:
> > First of all, thanks for looking into this and most of all for submitting a patch.
> > 
> > Unfortunately, just like Sebastian said, I'm afraid I'm not willing to let this patch in. However, in the upcoming solid sprint I plan to address this. Luckily, UPower has a signal which does exactly what you tried to achieve here. I will get in touch with you as soon as I will implement the needed part in PowerDevil/Solid so you can code another patch against the new method. How does this sound to you?
> 
> Björn Ruberg wrote:
>     That's sounds good. But this patch does not mean that the problem can never be fixed correctly.
>     Maybe this can be seen as a fix for the 4.5 branch while you add the correct functionality for 4.6?

Mail from Sebastian Kügler:
> I'd rather not have it in high-level Plasma components since it's
> essentially working around a limitation in HAL. There are a couple of
> problems with putting it in powerdevil as is:
> 
> - the DBus method you expose is only valid for the HAL backend, if someone
> uses the (future) upower backend, you'd still use this workaround. Also,
> app developers might start to rely on this behaviour.
> - DBus interfaces are to be regarded as public API, therefore we cannot
> just change them
> - the workaround is in the wrong layer of the stack, the app (timeengine in
> this case) shouldn't work around limitations which we need to fix below in
> the stack (i.e. in Solid)
> 
> Maybe we can put this workaround into the hal backend itself, and have it
> emit resumed() when it detects this clock skew. The upower backend would
> then emit the same signal, but triggered in the correct way. The
> applications get the hotness in a transparant manner and can adapt (i.e.
> our timeengine fires updates).
> 
> This doesn't solve the problem that we're adding public API (the DBus
> method in powerdevil), but doing it in this future-proof (yey, right!) way
> would make it more acceptable IMO. You'll need to get it past Kevin,
> though. >:)

I would be fine reworking the patch in that manner IF it will be accepted then. May be I get some stubs provided so that I know where I have to go into powerdevil/solid.

But concerning your dbus-concerns: I'm inventing a signal standbyRequested(). I can rename it awaitingStandby() or whatever. Important thing is, I don't see a reason why such a signal should not be in the public API. I can imagine different usages for it, i.e. applications gracefully closing network connections before standby. 

The whole polling stuff is there to work around the missing "resumed" signal. Surely that can be moved in the lower layer. The main benefit of this that there will actually be an "resumed()"-signal that other applications can catch. But as there will come a correct signal for this with the 4.6 release (I hope so :)), the patch might even stay as it is for the 4.5 line.


- Björn


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/5320/#review7579
-----------------------------------------------------------


On 2010-09-13 11:20:38, Björn Ruberg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/5320/
> -----------------------------------------------------------
> 
> (Updated 2010-09-13 11:20:38)
> 
> 
> Review request for Plasma and Solid.
> 
> 
> Summary
> -------
> 
> NOTE: This a little bit ugly as I have to workaround the missing "going to suspend"-signal in the linux userland
> 
> This patch adds a signal to powerdevil that is emitted when a suspend/hibernate/standby is requested there. The signal is caught by the time engine what starts to look for an unexpected change in system time for two minutes by polling. If a clock skrew is detected, all sources are updated immediatly.
> 
> This fixes the bug that the plasma clocks are showing old time after suspending your machine up until 59 seconds (whenever the normal update is scheduled). This is not exactly a patch for bug 181380. But the clock skrew detection code can be used quite similar for detecting normal time changes. I'll look into that as soon this is accepted.
> 
> Please tell me whether I can commit this to 4.5 trunk as it is a bugfix for a nasty glitch.
> 
> 
> This addresses bug 181380.
>     https://bugs.kde.org/show_bug.cgi?id=181380
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.h 1166313 
>   /trunk/KDE/kdebase/workspace/plasma/generic/dataengines/time/timeengine.cpp 1166313 
>   /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.h 1166313 
>   /trunk/KDE/kdebase/workspace/powerdevil/daemon/PowerDevilDaemon.cpp 1166313 
>   /trunk/KDE/kdebase/workspace/powerdevil/daemon/org.kde.PowerDevil.xml 1166313 
> 
> Diff: http://svn.reviewboard.kde.org/r/5320/diff
> 
> 
> Testing
> -------
> 
> Suspended machine, waited three minutes, woke up again - and noticed that all clocks on screen showed the correct time almost immediatly :)
> 
> 
> Thanks,
> 
> Björn
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-hardware-devel/attachments/20100913/4cd42cf1/attachment-0001.htm