Review Request 126078: [OS X] modernising the KIdleTime plugin (WIP!)

Boudhayan Gupta bgupta at kde.org
Thu Nov 19 15:39:31 UTC 2015


Hi all,

On 19 November 2015 at 15:06, René J.V. <rjvbertin at gmail.com> wrote:
> On Thursday November 19 2015 08:10:08 Martin Graesslin wrote:
>> the code else where, but because the issues pointed out would be unresolved
>> giving users of your code a bad framework and thus harming both your users as
>> well as the frameworks project for distributing bad code. The problem of
>> polling is real. Please accept this feedback.
>
> Now it's just bad code, eh?

Thou shalt not poll.

This is for one reason and one reason only - polling causes wakeups,
which consumes both power and processor resources. You're running
warmer, slower and consuming more energy. Microwatts count, because
they add up.

The irony here is that you're polling in a library with the purpose of
increasing power usage efficiency.

That said, here's a concrete way for you to detect both Idletime and
catch resume events:

For idletime, run a QTimer with the interval set to the idle timeout.
Poll the HID time since last event twice - once at timer start and
once at timer end. Check the difference. If it's round about the same
as the timer difference, the system has been idle. Trigger the idle
signal. If the difference is significantly less, adjust the QTimer
interval to check again at a shorter interval - the time at which you
expect the HID time since last event to be the expected value.
Basically, do some math, keep adjusting the timeout value everytime
you reach the timeout.

Now once you're in idle mode, you'll need some way to resume from
idle. This needs a high-precision event source. Not a timer, an event
source. For this, get a keylogger, like the one here -
https://github.com/caseyscarborough/keylogger/blob/master/keylogger.c
- and adjust it so that it responds to key as well as mouse events.
Instead of actually logging the key though, make it emit a tick
through a socket pair or a named pipe, with KIdleTime on the listening
end. Or just use QProcess - start the process when you enter idle, end
the process on the first instance you get some output from the stdout,
which is in response to an input event.

Let's hope this helps you out.

-- Boudhayan


More information about the Kde-frameworks-devel mailing list